Eric Daoust and Adam Turcotte are about to wrap up a pair of Google
Summer of Code 2009 projects having to do with new samplers. In this
document, I explain what the samplers do, how they (may) fit within
the GEGL library, and where (most likely) they are going.
I also indicate what will need to be done when non-affine
transformations (perspective, warp) are implemented in GEGL so that
they use the samplers tuned for downsampling with maximal benefit.
(Warning: I wrote this document in a hurry: Hopefully, it contains no
In total, twelve new samplers were programmed:
six samplers tuned for transformations in which good downsampling is
more important than good upsampling (for example, thumbnail
downsize, downsharp, downsmooth and their simplified/faster versions
downsizefast, downsharpfast and downsmoothfast
six samplers tuned for transformations in which good upsampling is
more important than good downsampling (for example, image enlargement
upsize, upsharp, upsmooth and their simplified/faster versions
upsizefast, upsharpfast and upsmoothfast
(Note: Perspective transformations often are both upsampling and
The naming convention which Adam, Eric and I used (which could be
changed) is as follows:
up* samplers are tuned for upsampling, down* samplers are tuned
*sharp* samplers maximise sharpness at the expense of increased
aliasing (jaggies); *sharp* samplers behave more like nearest
neighbour than the other methods. *smooth* samplers minimise
jaggies at the expense of additional blur. *size* samplers are a
compromise between the two.
*fast are simplified/faster versions. If fast is omitted, the
corresponding method is the higher quality/slower version.
As implemented for GEGL, none of the above methods are parameterised.
http://bugzilla.gnome.org/show_bug.cgi?id=588336 (remove the yafr sampler)
http://bugzilla.gnome.org/show_bug.cgi?id=588180 (remove the sharp sampler, and
http://bugzilla.gnome.org/show_bug.cgi?id=588193 (add upsharpfast, upsizefast
http://bugzilla.gnome.org/show_bug.cgi?id=592498 (add upsize)
http://bugzilla.gnome.org/show_bug.cgi?id=592515 (add upsmooth)
http://bugzilla.gnome.org/show_bug.cgi?id=588016 (add downsharp, downsize,
http://bugzilla.gnome.org/show_bug.cgi?id=592349 (add downsharpfast,
downsizefast and downsmoothfast)
(Non-sampler patches which Eric and Adam produced are not included
Where this is going?
(Feedback welcome and actually sought.)
If GEGL does not need pretty good fast samplers, the *fast methods
could simply not be integrated into GEGL. If and when GEGL has
quality levels, one could write a driver which selects the fast
method when the chosen quality level is low. In any case, programming
the *fast methods was not a waste: The s/nohalo family of methods is
multi-stage, hence the cheaper versions are used as stages for the
non-fast ones; in addition, the improved fast versions programmed
for GSoC will be ported to VIPS. This being said, it would be nice if
they could be merged into GEGL trunk and then removed, so that the git
repository have a record of them.
Keeping the *fast methods private (or not merging them at all) would
reduce the total number of public GEGL methods from twelve to
six. The following would further reduce the total number of methods to
four (or eight if *fast samplers are kept).
The downsize and downsharp samplers are very similar. For this
reason, it would make sense to only keep the downsize and downsmooth
samplers (same with downsizefast and downsmoothfast).
The upsize and upsharp samplers are very different from each other,
but research performed by Chantal Racette as part of her Laurentian
University Honours Thesis during the Summer suggests that the method
underlying upsharp should be used as a final stage for the
multi-stage methods upsize and upsmooth, yielding superior methods
which would replace the current upsize and upsmooth and make the
current upsharp obsolete.
So, in the end, there could only be four new additional GEGL samplers:
Two samplers tuned for downsampling: downsize and downsmooth (with
fast versions downsizefast and downsmoothfast if desired)
Two samplers tuned for upsampling: upsize and upsmooth (with fast
versions upsizefast and upsmoothfast)
Every one is a good general purpose sampler. The downsize method, in
particular, will be found to give acceptable results in all
situations (generally better than bilinear when upsampling, and much
much better than bilinear when downsampling). For this reason, I think
that downsize may be a good candidate for default GEGL sampler.