Re: alignment of pixels with coordinates

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

 



On Thu, May 14, 2009 at 4:57 PM, Nicolas Robidoux
<nrobidoux@xxxxxxxxxxxxxxxx> wrote:
>
> My working assumption is that GEGL should be as consistent as possible
> with GIMP.
>
> gegl/gegl/buffer/gegl-sampler-cubic.c, for example, contains the
> following code:
>
> ----------------------------------------------------------------------
>
> ...
> gegl_sampler_cubic_get (GeglSampler *self,
>                        gdouble      x,
>                        gdouble      y,
>                        void        *output)
> {
>  ...
>  gint              dx,dy;
>  ...
>  dx = (gint) x;
>  dy = (gint) y;
>  sampler_bptr = gegl_sampler_get_ptr (self, dx, dy);
>  ...
>
> ----------------------------------------------------------------------
>
> Ignoring the issue of the asymetric behavior of int casting when one
> crosses 0 vs the "right boundary" (see gegl-sampler-linear.c or
> gegl-sampler-sharp.c for a fix) I want to double check that pixels are
> understood to be centered at points with integer coordinates (for
> example (0,0) is a possible pixel location, but not (.5,.5) throughout
> GEGL and GIMP (excluding plug-ins, of course). If there are
> exceptions, are they relevant to resamplers and abyss policies?
>
> If there is a discrepancy between GEGL and GIMP, I will have Adam and
> Eric align GEGL with GIMP as much as possible.

I agree that the convention should be that pixel sampling sites are at
integer coordinates. I also feel it would be natural to let the extent
of a pixel be half way towards the neighbour pixel sites, this however
has the issue of not matching the display GIMP provides when zoomed
into the image.

At the moment the display code in GIMP assumes that we want to see big
pixels when zooming in and hence uses nearest neighbour interpolation
for zoom levels > 100%. The pixels themselves are displayed as squares
that extend to the right and down from the pixel. This is useful for
some tasks, like for instance filling subpixel bezier curves based on
analytical geometric coverage.

GEGL might in the future also offer other resamplers for blitting /
display purposes, the best would of course be if all resamplers could
be plugged in and interchangeably used for different purposes, at the
moment the resampling that happens in gegl_node_blit does not use the
resamplers to do its job for the general cases it probably shouldn't
either since it needs to be as fast as possible.

/Øyvind K.
-- 
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer


[Index of Archives]     [Yosemite News]     [Yosemite Photos]     [gtk]     [GIMP Users]     [KDE]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux