Re: [Gegl-developer] new GEGL samplers: what they are and where they are going
On Sep 17, 2009, at 6:51 PM, Nicolas Robidoux wrote: But I am wondering if for GEGL's target user base an "always pretty good" default is preferable to "choose your poison." Well, if all GEGL ever has is a "always pretty good" default and you never get to pick your poison, you are making your decision for your users. And frankly, "always pretty good" is not as cut and dry and you'd like to think, off the top of my head here are some image processing applications I can think of that have dramatically different requirements in a resize operation (I speak from experience here, I've been involved with most of the items on this list): High throughput print on demand rendering services. (Think snapfish.com and their ilk.) medical research. (MRI, CT, PET, ultrasound scanners) astrophysics research. general physics experimentation (anyone using a camera for measurements) embedded systems (printers, kiosks, etc) real time video processing And of course applications like The GIMP. All of these require different tradeoffs for their resamplers. I've seen downsamplers that preserve bluriness so you can show a thumbnail that is representative of the bluriness you see in a printed product. Rescaling text, it's often important to worry less about aliasing and more about blur. Nearest neighbor is actually a perfect resize operation for a large class of artificial images. Medical scientists are much more worried about introducing artifacts that could be misinterpreted as disease, or potentially blurring away evidence of such. Anyone using a camera for measurements is (depending on the measurement) often more interested in geometric stability, regardless of blur or aliasing. Real time video is often about speed. I think a better question is to ask, are you going to limit GEGL to being used solely by The GIMP, and then, only the subset of GIMP users you think exist, or are you going to allow your users to create the facilities to use GEGL is applications you did not originally envision. For me the obvious choice is the latter. Making GEGL suitable for as broad a range of applications as possible gets you a larger user base and, if done right, higher quality code. The Linux kernel is a great example of this. -- Daniel___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] new GEGL samplers: what they are and where they are going
On 09/18/2009 03:51 AM, Nicolas Robidoux wrote: > But I am wondering if for GEGL's target user base an "always pretty > good" default is preferable to "choose your poison." > > Comments? As long as there is good general-purpose resampler (which could possibly use different algorithms depending on if it is dealing with downscaling or upscaling) I'm happy. Everything else is bonus to me. BR, Martin -- My GIMP Blog: http://www.chromecode.com/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] new GEGL samplers: what they are and where they are going
Question about future direction for resamplers: Would it be better if there was only one sampler tuned for upsampling, and one tuned for downsampling? My previous vision for GEGL was that my research group would contribute TWO resamplers tuned for upsampling and TWO resamplers tuned for downsampling. The four new samplers would (eventually) integrate the best of the 16 resamplers programmed by Eric and Adam for GSoC 2009. Within each of the two pairs of resamplers, one was to be "interpolatory" (and more aliased) and the other would minimally blur (and be less aliased). Now: I just figured out how to use the Jacobian matrix information so that the sampler only add noticeable antialiasing blur when the operation is performing significant upsampling or downsampling. What this means for the resamplers tuned for upsampling, for example, is that we could seamlessly integrate Nohalo and Snohalo in such a way that the sampler behaves like Nohalo when translating and rotating (hence is "blur free") but behaves increasingly like Snohalo as the transformation (locally) deviates from being distance preserving (hence is more anti-aliased), resulting in one single sampler which would please everyone and their father. I imagine that a few people would want the added control over the aliasing vs blur trade-off which having pairs of methods would provide (also, methods can be faster if they are not jack of all trades). But I am wondering if for GEGL's target user base an "always pretty good" default is preferable to "choose your poison." Comments? Nicolas Robidoux Universite Laurentienne ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] new GEGL samplers: what they are and where they are going (REVISED)
On 09/01/2009 04:22 PM, Nicolas Robidoux wrote: > > > Abstract > > > 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 they are going (most likely: feedback > would be nice). > > I also briefly 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 (for example, thumbnail > production) with maximal benefit. Thanks a lot for this detailed info I'll make sure that your work is merged to master sooner or later (but it could take a while before I find the time to do it) BR, Martin ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] new GEGL samplers: what they are and where they are going
RE: > === > Upsharp sampler > === > ... > Future improvements: ...Finally, current research > suggests that the co-monotonicity enforcing derivative clamping is > overkill and that the result would be less aliased without a > noticeable increase in haloing if it only enforced strong boundedness. More current research suggests that the standard "three times the difference" rule (Fritsch and Carlson et al) is just about as good as it gets, so this future improvement won't be. Nicolas Robidoux ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] new GEGL samplers: what they are and where they are going (REVISED)
On Tue, Sep 1, 2009 at 6:22 PM, Nicolas Robidoux wrote: > > Abstract > > > 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 they are going (most likely: feedback > would be nice). One thing most of your mails need is a section which states that it would be legal to use any part of the text in the user manual :) Alexandre ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
[Gegl-developer] new GEGL samplers: what they are and where they are going (REVISED)
Abstract
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 they are going (most likely: feedback
would be nice).
I also briefly 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 (for example, thumbnail
production) with maximal benefit.
=
QUICK SUMMARY
=
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
production):
downsize, downsharp, downsmooth and their simplified/faster versions
downsizefast, downsharpfast and downsmoothfast
and
six samplers tuned for transformations in which good upsampling is
more important than good downsampling (for example, image enlargement
and rotation):
upsize, upsharp, upsmooth and their simplified/faster versions
upsizefast, upsharpfast and upsmoothfast
(Note: Perspective transformations often are both upsampling and
downsampling, depending on the location and even the direction.)
Every sampler can be used for any resampling task (enlarging,
shrinking, rotating, perspective, warping...). "Sampler tuned for X"
means that the sampler is built to excel at task X. It does not mean
that it does poorly at other tasks.
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
for downsampling,
"*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.
The distinguishing feature of the methods (except upsharpfast) is that
they do not introduce any haloing artifacts, and yet do well at
antialiasing (esp. upsize, upsmooth and the future version of
downsmooth).
Relevant patches
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 add upsharp)
http://bugzilla.gnome.org/show_bug.cgi?id=588193
(add upsharpfast, upsizefast and upsmoothfast)
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, downsmooth)
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 here.)
Where this is going?
If it is felt that GEGL does not need "pretty good fast samplers," the
"*fast" methods could simply not be integrated into GEGL (or made
"public"). 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).
Downsampling schemes: 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). Note that I am not 100% sure that users will prefer
the downsize method to the downsharp method: it depends on whether
they dislike aliasing (jaggies) more than than blur. (I dislike
aliasing, hence my preference for downsize.)
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 up
[Gegl-developer] new GEGL samplers: what they are and where they are going
Abstract
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.
=
QUICK SUMMARY
=
(Warning: I wrote this document in a hurry: Hopefully, it contains no
significant inaccuracy.)
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
production):
downsize, downsharp, downsmooth and their simplified/faster versions
downsizefast, downsharpfast and downsmoothfast
and
six samplers tuned for transformations in which good upsampling is
more important than good downsampling (for example, image enlargement
and rotation):
upsize, upsharp, upsmooth and their simplified/faster versions
upsizefast, upsharpfast and upsmoothfast
(Note: Perspective transformations often are both upsampling and
downsampling.)
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
for downsampling,
"*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.
Relevant patches
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
add upsharp)
http://bugzilla.gnome.org/show_bug.cgi?id=588193 (add upsharpfast, upsizefast
and upsmoothfast)
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,
downsmooth)
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
above.)
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.
===
DETAILE
