Øyvind Kolås writes: > I forgot to add one more item to my list of potential/desired > enhancements of GeglBuffer and that is to make the extent (width and > heights) of the buffer be updated on demand when tiles are changed, > allowing automatically growing buffers that are "auto-clipped" to the > bounding box of content that differs from the configured background > color. Do I gather correctly that this is related to the possible solution you gave for http://bugzilla.gnome.org/show_bug.cgi?id=549999 namely, > The bug is manifest because the different interpolation methods have > different sampling footprints. The resulting image size is computed > based on the size of the kernel, this is similar in behaviour to the > gaussian blur which increases the size of the input image as well by > smearing it out. The upper left corner of the bounding box is stored > to be in negative coordinats so sampling from 0,0 would yield the > upper left sample anyways. One way to work around this would be to > crop the image to the original bounding box. > Not completely sure if this is a bug or not, I guess it depends on > what types of behavior we want to support for the edges of > transformed buffers. Please let me know if I am completely off track, but there are some issues which I want to understand if possible (even though you may have explained it to me already) in order to guide Eric and Adam: Question 1: If my memory is good, samplers in GIMP use the "center" image size convention, which means that the centers of the boundary pixels "creep in" when downsampling, but "creep out" when upsampling, because what is kept fixed is the position of the corners of the areas implied by the boundary pixels, which are half a pixel width out from their centers. The most common alternative is the "corner" convention, which anchors the positions of the centers of the boundary pixels. I am omitting discussion the pros and cons for each. (Generally, "center" is better for downsampling, and "corner" is better for upsampling, so no single convention works best for all situations.) However, it is my opinion that "corner" convention is generally better. Do you have a preferred "implied" convention for GEGL? Should it comply with what is generally the "implied" convention in GIMP? This matters, because if the abyss policy is "no blending: image goes to the boundary ignoring the abyss, and the abyss is constant whatever (0, say, but one of your requested features is that this be configurable), we need to know where the boundary is. Question 2: Do you want resampled image sizes to be enlarged by the size of the footprint (more specifically, by the size of smallest rectangle which contains the footprint, since, for example, the footprint of nohalo is not a rectangle), or do you want the resampled image size to be cropped, in accordance with the image size convention (in the corner convention, the image ends right at the center of the boundary pixels, in the center convention, it ends one half pixel past it). Prior to our conversations last week, I was sure that cropping should be done. however, now that I have been exposed to the "wonderfulness" of GEGL buffers, I have the impression that the buffer should be extended by this footprint so that the "blending" implicit in most abyss policies be applied not only inside the extent of the original image, but also outside. A consequence is that the bounding box will depend on the abyss policy, which is the case now. In other words, this would be a feature, not a bug. Question 3: Because the footprint of the samplers is often asymetrical (for example, for bicubic, the "anchor" is the second pixel from the left, out of the four positions which make up the footprint in the horizontal direction; this breaks left/right symmetry) the number of pixels by which the image is extended at the top and left is often not the same as the number by which it is extended at the bottom and right. Of course, symmetry is resolved in that "extra" ones are set to the background abyss colour (0). Again, I previously saw this as a bug, which in principle could be avoided using some logic or cropping. However, at this point, I am enclined to treat it as a quirky feature which is a side effect of a sound design decision. Is this agreed? ---------------------------------------------------------------------- I hope that I am not making my confusion too manifest here. Cheers, Nicolas Robidoux Universite Laurentienne _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
