Re: computing image axis limits

[Ben Abbott]

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