Re: computing image axis limits

[Ben Abbott]

On Oct 2, 2010, at 8:58 PM, Ben Abbott wrote:

> On Oct 2, 2010, at 4:55 PM, Ben Abbott wrote:
> 
>> On Oct 2, 2010, at 3:34 PM, Shai Ayal wrote:
>> 
>>> On Sat, Oct 2, 2010 at 5:08 PM, Ben Abbott <address@hidden> wrote:
>>>> On Oct 2, 2010, at 1:31 AM, Shai Ayal wrote:
>>>> 
>>>>> Hi all.
>>>>> 
>>>>> Images with a width and/or height of 1 do not display correctly in the
>>>>> fltk backend as reported in the following bug report:
>>>>> https://savannah.gnu.org/bugs/?31093
>>>>> 
>>>>> The problem turned out to be bugs with the way image axis limits were
>>>>> calculated for images where width and/or height was 1.
>>>>> Axis limits for images are a bit tricky as they have to take the image
>>>>> pixel size into account. It turns out that today the image pixel size
>>>>> is be calculated in 4 different places:
>>>>> 1) opengl_renderer::draw_image
>>>>> 2) image::properties:update_{x,y}data
>>>>> 3) image.m: __img__
>>>>> 4) axis.m: __get_tight_lims__
>>>>> 
>>>>> As far as I could see, the calculation in (1) is correct. The attached
>>>>> patch (not a changeset yet!) fixes a bug in (2) and also adds a small
>>>>> fix for (3). with it, the following commands:
>>>>> backend fltk
>>>>> h=image (ones (1,8));
>>>>> 
>>>>> does not set the axis right, The image is clipped and so nothing shows
>>>>> up (this can be verified by set (h , "clipping" , "off")).
>>>>> 
>>>>> I am not sure how to approach the fixing of (3) and (4). Maybe we
>>>>> should consolidate the calculation for 3,4? maybe we should
>>>>> consolidate 1,2,3,4?
>>>>> 
>>>>> Shai
>>>>> <image1.patch>
>>>> 
>>>> I like the idea of consolidating the calculation for all cases.
>>>> 
>>> OK. How do we do I do it then?
>>> IMHO The best way would be to add a property to the image object which
>>> would hold this data, but it would have to be hidden since there is no
>>> equivalent matlab property.
>>> Another way would be to create a function which accepts the image
>>> handle and returns the pixel size
>>> 
>>> Shai
>> 
>> 
>> I have a copy of ML to play with. I'll need to experiment with various image 
>> sizes and values or xdata/ydata before I can offer an informed opinion on 
>> the detail.
>> 
>> I hope to have time for that later today.
>> 
>> Ben
> 
> For me this is another example of "What Was MathWorks Thinking?". Knowing the 
> "pixel" size isn't enough.
> 
> The following script produces no errors for ML R2009b.
> 
> for m = [-1, 1]
>  for N = 1:10
>    clf
>    img = 1 ./ hilb (N);
>    xdata = m*dx*N * sort (rand (1, N) - 0.5);
>    ydata = -1:1;
>    h = image (xdata, ydata, img);
>    actual_xlim = get (gca, 'xlim');
>    actual_dx = diff (actual_xlim) / N;
> 
>    if (N > 1)
>      dx = (xdata(end) - xdata(1)) / (N-1);
>    else
>      dx = (xdata(end) - xdata(1));
>    end
> 
>    xdata = [min(xdata), max(xdata)];
>    if (dx > 0)
>      xlim = sort (xdata ([1, end])) + dx * [-1, 1] / 2;
>    elseif (dx < 0)
>      xlim = mean (xdata) + m*N*dx * [-1, 1] / 2;
>    else
>      dx = m;
>      xlim = mean (xdata) + m*N*dx * [-0.5, 0.5];
>    end
>    assert (all (abs (dx) - abs(actual_dx) < 10*eps), 'Bad dx')
>    assert (all (abs (xlim - actual_xlim) < 10*eps), 'Bad xlim')
>  end
> end
> 
> Ben

I hit <return> to fast ... it looks to me like we'll need a function which 
calculates the axis limits.

Ben