Re: Bug in image code ?

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:
> 
>> On Wednesday 17 August 2005 11:06 am, Hans-Bernhard Broeker wrote:
> 
> 
>>> Not really.  It's the same problem in a different dress.  Terminal
>>> coordinates are really only valid in some interval.  That interval 
>>> always has one endpoint at zero, by design, so it makes sense for the 
>>> coordinates to be unsigned.  It being unsigned even helps generate 
>>> faster code: a single test for (x < term->xmax) will detect points 
>>> that are off to the right or the left.
> 
> 
>> Detect, yes.  But it does not allow you to clip the line segment.
> 
> 
> That's OK --- clipping should not be done in the terminal driver anyway.
> 
>> For that you need the "true" negative coordinate so that you
>> can interpolate the intersections with the plot borders.
> 
> 
> More to the point, you need the original input, i.e. the floating-point
> numbers that the plot elements are all specified in.
> 
>> I agree that the core routines should clip before sending to the
>> drivers. Fine.  The problem is that the core routines *themselves*
>> use unsigned integers, which they should not.  
> 
> 
> Agreed, up to a point --- the key issue is that they have to clip
> before converting any coordinates to integers, be those signed or 
> unsigned.  For the classic plot styles, it's done by checking the data 
> points' validity flags (INRANGE/OUTRANGE/UNDEFINED).  The 'with image' 
> implementation, in particular, never checks these flags.  Odds are 
> that's exactly the root of the bug the OP found.

The image drawing routine does not use INRANGE.  Originally I intended that.  There is an in range test in a way, however.

Here is the issue.  When we speak of a *point* being in range, that is one thing.  But consider that the pixel of an image has a non-negligible width.  So, there can be pixels for which its centers are just outside the viewable border.  They'd be classified as OUTRANGE, but really a portion of the pixel would be visible.  Agreed?  When pixels are very small, it is not a big deal to leave out a portion of a pixel.  But when resolution is low, it's noticeable.

But, unlike pm3d, there is no easy way for the core to create portions of a pixel because of the nature of image data.  I think that clipping has to be done at the terminal level because every utility has it's own way of handling a portion of an image being viewable.  (For example, the X11 code I wrote has as part of its algorithm something that creates portions of a pixel.)  In summary, the image code tosses out all pixels that are clearly out of the viewable range, but keeps those just on the exterior of the boundary if they exist.

This is why I said a portion of a pixel might be extending off the viewable boundary.  Also it's why I'm asking whether the terminal should take care of boundary checking.  Have I just given an argument why a signed number passed to the terminal driver, as Ethan suggests, would prove better than unsigned?  (Not sure myself.)  That is, this may be a case where it is worth being able to tell in which direction something has gone out of range, rather than being able to test out of range with a single unsigned test?

Dan