Re: computing image axis limits

[Shai Ayal]

On Sun, Oct 3, 2010 at 3:01 AM, Ben Abbott <address@hidden> wrote:
> 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.
>
changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/b748b86cb8c1

consolidates 2 & 3 from above. As far as I can see it fixes the bug
https://savannah.gnu.org/bugs/?31093

Shai