On 10/16/06, geert.jordaens@xxxxxxxxxx <geert.jordaens@xxxxxxxxxx> wrote:
The change below i think would complicate the usage.
Since every time accessing the interpolator the coordinates for
accessing should be ajusted by the value of x, y.
*GeglSampler *sampler = g_object_new (GEGL_TYPE_SAMPLER_CUBIC,
"input", src,
"format", babl_format ("RaGaBaA float"),
"x", 50,
"y", 50,
"width", 200, /* or a rect could be passed, or a subbuffer of
"height", 200, buffer expected to be created before making a sampler */
NULL);
The purpose of this change would be to indicate which window
within the buffer needs to be prepared for access (the specific
sampler would then need to know exactly which data must be prepared).
But as I wrote in my comment to those API additions relying on the
buffer to be pre-clipped is probably better.
The api below would introduce more complexity because each
implementation would need other arguments.
gegl_sampler_get_quad (sampler, xc-0.5, yc-0.5,
xc+0.5, yc-0.5,
xc+0.5, yc+0.5,
xc-0.5, yc+0.5,
buf);
The curren API proposal works on the complete passed buffer and should alos work for scaling and transforming.
Since the fractional part of x,y determines the offset.
Nope, the point is that interpolation is wrong when scaling down you
as will happen when scaling down using an affine transform or a
perspective transform. By transforming the corners of a pixel, one
would get an idea about the size needed for the resampling kernel.
If you scale a image to 10% of the original size using cubic, you have
a situation where the data for each destination pixel is taken from a
region of 4x4pixel, whilst it should at least be taken from a region
of 10x10pixels, 84% of the image data is thrown away.
/Ø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
