[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: computing image axis limits
From: |
Ben Abbott |
Subject: |
Re: computing image axis limits |
Date: |
Sat, 02 Oct 2010 21:01:17 -0400 |
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