octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: computing image axis limits


From: Shai Ayal
Subject: Re: computing image axis limits
Date: Sat, 2 Oct 2010 21:34:04 +0200

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]