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
[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
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
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. === DETAILED DISCUSSION ===
