Adam Turcotte and Eric Daoust are implementing samplers (alternatives to nearest neighbour, bilinear, bicubic, lanczos... interpolation), names snohalo1 (tuned for upsampling) and nohalobox (tuned for downsampling), which both have a natural parameter. This parameter is basically the amount of extra antialiasing which is applied. The way the extra antialiasing is done is with a customized blurring operator in the case of snohalo1, and by enlarging the integration box (like for exact area box filtering) for nohalobox.

Adam is nearly done (fingers crossed) implementing the paramter so that it is settable through xml commands.

My question:

We've settled on the name "blur" for this paramter, because for most people this is the visible effect, and I think most people understand that blurring can be useful to smooth out "jaggies."

Would you guys prefer another name for this visible parameter? "Antialiasing," for example, seems like a good candidate, although it sounds a little too technical to my taste.

Nicolas Robidoux Laurentian University

On Tue, Jul 7, 2009 at 10:25 AM, Nicolas Robidoux wrote:

Adam Turcotte and Eric Daoust are implementing samplers (alternatives to nearest neighbour, bilinear, bicubic, lanczos... interpolation), names snohalo1 (tuned for upsampling) and nohalobox (tuned for downsampling), which both have a natural parameter.  This parameter is basically the amount of extra antialiasing which is applied. The way the extra antialiasing is done is with a customized blurring operator in the case of snohalo1, and by enlarging the integration box (like for exact area box filtering) for nohalobox.

Adam is nearly done (fingers crossed) implementing the paramter so that it is settable through xml commands.

My question:

We've settled on the name "blur" for this paramter, because for most people this is the visible effect, and I think most people understand that blurring can be useful to smooth out "jaggies."

Would you guys prefer another name for this visible parameter? "Antialiasing," for example, seems like a good candidate, although it sounds a little too technical to my taste.

I would feel more comfortable if this parameter was not exposed, but rather that sane presets were added and given names. In most cases the additional properties of for instance a displacement map operation might be visual and conceptual clutter getting in the users way. When it comes to naming it; I think perhaps smoothing is a good candidate.

Øyvind Kolås writes:
>
> I would feel more comfortable if this parameter was not exposed, but > rather that sane presets were added and given names. In most cases the > additional properties of for instance a displacement map operation > might be visual and conceptual clutter getting in the users way. When > it comes to naming it; I think perhaps smoothing is a good candidate. >

You mean, like the "type" for gegl-sampler-cubic, which sets the B and C values based on named bicubic variants?

For example, nohalo1 (same result as snohalo1 with smoothing = 0, but runs faster) would be "sharper", snohalo1 with smoothing = 1 would be "smoother", and snohalo1 with smoothing = .5 would be "halfandhalf," or something kind of like that?

Likewise with nohalobox (the scheme tuned for downsampling)?

You can see samples of what "sharper" and "smoother" would be at http://gsoc.rivetsforbreakfast.com/enlargements.html

Note that because s/nohalo is nonlinear, smoothing = .5 does not give the average of the sharper and smoother results.

(Note that levels more or less correspond to quality level. Higher levels are not yet implemented.)

----------------------------------------------------------------------

This was my vision (hubris?) or where this would all eventually go (keeping the smoothing parameter visible):

There would be a slider corresponding to the amount of custom smoothing being applied (of course, this would do nothing to nearest neighbour and bilinear) for s/nohalo and nohalobox.

The user would look at the results (depends on noisiness of resampled image, whether there is much warping going on or only up/downsampling, whether there are a lot of text/perfectly horizontal/vertical lines, amount of visibly annoying aliasing, whether it's for print or the web, etc) and adjust the slider until, hopefully, she are happy.

Comments?

Nicolas Robidoux University Laurentienne

Nicolas Robidoux writes:
>
> For example, nohalo1 (same result as snohalo1 with smoothing = 0, but > runs faster) would be "sharper", snohalo1 with smoothing = 1 would be > "smoother", and snohalo1 with smoothing = .5 would be "halfandhalf," > or something kind of like that?

If there were only four named presets, I supposed they could be

sharpest, sharp, smooth, smoothest

corresponding to smoothness = 0, 1/3, 2/3 and 1.

with the added bonus that smoothness = 1/3 kind of corresponds to the Mitchell-Netravali choice of smoothing/interpolation balance.

Øyvind:

Does the above seem like a good choice, or did I change your mind with my "smoothness slider" idea (or do you like neither)?

Nicolas Robidoux Laurentian University

Suggestion implementing the s/nohalo family and the nohalobox family without an explicit, visible, parameter:

Would it be possible/desirable to use the current code (which has a parameter) as some sort of template?

Then, the nohalobox code would produce four independent samplers:

sharperbox -> smoothing = 0 sharpbox -> smoothing = 1/3.
smoothbox -> smoothing = 2/3.
smootherbox -> smoothing = 1.

which could be called like, say, linear.

And the s/nohalo code would produce four independent samplers:

sharper -> nohalo (nohalo produces the same results as snohalo with smoothing = 0, just faster) sharp -> snohalo with smoothing = 1/3. smooth -> snohalo with smoothing - 2/3. smoother -> snohalo with smoothing = 1.

Nicolas Robidoux Universite Laurentienne

On Wed, Jul 8, 2009 at 8:43 AM, Nicolas Robidoux wrote:

Suggestion implementing the s/nohalo family and the nohalobox family without an explicit, visible, parameter:

Would it be possible/desirable to use the current code (which has a parameter) as some sort of template?

Sure, for most uses both developers and users will desire a default sampler that just works and needs no tweaking. Additional properties to configure some of the samplers will make it harder both for users of GUIs as well as developers implementing or using operations that use the samplers. Fewer presets that cover normal use cases is probably better than many; this trimming down of the presets might be done in GUI layers code as well.

The names for samplers would need some serious thought, linear, cubic and lanczos in current GIMP is already too techical for many users, most people would have no clue what "box" refers to in the suggested names. When exposes as for instance a drop down in the GUI these names need to be translatable into other languages as well.

Øyvind Kolås writes:
>
> The names for samplers would need some serious thought, linear, cubic > and lanczos in current GIMP is already too techical for many users, > most people would have no clue what "box" refers to in the suggested > names. When exposes as for instance a drop down in the GUI these names > need to be translatable into other languages as well.

My first suggestion was

sharperbox sharpbox
smoothbox
smootherbox

for the samplers (distinct by values of parameters) which are tuned for downsampling (because these schemes are relatives of exact area box filtering) and

sharper
sharp
smooth
smoother

for the samplers which are tuned for upsampling. (Note that the former will do an OK job at upsampling, and the latter, esp "smoother," will do an OK job at downsampling: I'm talking about "tuning" here.)

----------------------------------------------------------------------

Let me guess that you don't want 8 variants in total. So, how about only using parameter values 0 and 1 (skipping intermediate values) for each, for a total of four methods? Does this sound preferable?

With this in mind, here are some suggestions for the "tuned for downsampling" sampler:

sharpdown and smoothdown

or

sharpthumb and smooththumb

For the ones "tuned for upsampling:"

sharp and smooth

or

sharpup and smoothup

(or

sharper and smoother)

----------------------------------------------------------------------

Can you (yes, I mean you) think of better names?

Basically, there are two pairs of samplers to name.

One pair is tuned for downsampling (e.g., producing thumbnails, that is, producing a smaller version of the original) and the other pair is tuned for upsampling (enlarging the image), although they both do an OK job for all warps.

Within each pair, there is an interpolatory one (a "sharper" version of the scheme) and one which has stronger antialiasing by way of "special" smoothing (a "smoother" version of the scheme).

Nicolas Robidoux Laurentian University

hi,

Nicolas Robidoux schrieb:

Can you (yes, I mean you) think of better names?

uh, what, me?

i wouldn't want to be bothered with choosing different samplers for up/down-scaling.

So just let me choose from matching pairs of samplers. You know them better than i do...

greetings, peter

Is it "decided" that there will be only two versions of the "good for upsampling" sampler, and only two versions of the "good for downsampling" sampler as well?

Because if it is, Eric's nohalo1 and snohalo1 patches could be made "ready to push" in very little time, and the preliminary version of Adam's nohalobox could be split into two immediately useable versions, hence pushed. (All that would be needed is better handling of very high downsampling ratios.)

Nicolas Robidoux Universite Laurentienne

yahvuu writes:
>
> uh, what, me?
>
> i wouldn't want to be bothered with choosing different samplers > for up/down-scaling.

(I'm surprised. You are always happy with the thumbnails you get? Result after rotating an image? Maybe I'm too invested in this field to know what matters and what matters not.)

Peter just gave me more ideas of how it could look in a menu:

bigger (sharp) and bigger (smooth)

and

smaller (sharp) and smaller (smooth)

The fact that bigger can be used for arbitrary warps (including downsampling) and smaller can be used for arbitrary warps (including upsampling) should not confuse anyone. (I think.)

Keep the ideas coming!

Nicolas Robidoux Laurentian University

sharpEnlarge and smoothEnlarge

and

sharpShrink and smoothShrink (or sharpReduce and smoothReduce)

?

PS

Let me know if you'd rather I think about all this off list.

sharpsmall and smoothsmall

and

sharpbig and smoothbig

?

In a "scale image" menu, the most likely appropriate method could be chosen automatically (depending on the requested resizing), with an "extra smoothing" toggle set by default to off.

Nicolas Robidoux Universite Laurentienne

On Wed, Jul 8, 2009 at 1:08 PM, Nicolas Robidoux wrote:

PS

Let me know if you'd rather I think about all this off list.

I dislike writing email, and you are almost using email like IRC, feel free to continue but do not expect much response from me in particular :d

/pippin

Most likely names of the resamplers at this point are either:

upsharp and upsmooth

or

sharpupsize and smoothupsize

for the samplers tuned for warps in which upsampling is more typical than downsampling (e.g., for image enlargement), and either

downsharp and downsmooth

or

sharpdownsize and smoothdownsize

for the samplers tuned for warps which mostly downsample (e.g., for producing thumbnails).

-----

It turns out that the above schemes have cheap/less cheap versions. What I am thinking of doing is either prefixing or suffixing the above names with the word "fast" for the faster/lower quality versions, for example

fastsharpupsize and fastsmoothupsize

which would correspond to nohalo level 1 and snohalo level 1, while sharpupsize and smoothupsize would correspond to s/nohalo level 2.

Feedback welcome.

Nicolas Robidoux Laurentian University

On 10-07-09 16:39, Nicolas Robidoux wrote:

Most likely names of the resamplers at this point are either:

upsharp and upsmooth

or

sharpupsize and smoothupsize

for the samplers tuned for warps in which upsampling is more typical than downsampling (e.g., for image enlargement), and either

downsharp and downsmooth

or

sharpdownsize and smoothdownsize

for the samplers tuned for warps which mostly downsample (e.g., for producing thumbnails).

-----

It turns out that the above schemes have cheap/less cheap versions. What I am thinking of doing is either prefixing or suffixing the above names with the word "fast" for the faster/lower quality versions, for example

fastsharpupsize and fastsmoothupsize

which would correspond to nohalo level 1 and snohalo level 1, while sharpupsize and smoothupsize would correspond to s/nohalo level 2.

Feedback welcome.

Nicolas Robidoux Laurentian University

Geert Jordaens writes:
> I do not see any reason why one would have to specify up or downsize in > the parameter since this can be determined from the in and output size, > what about translations?

All the "to be named" samplers can be used for arbitrary warps, and all can be used for upsampling, downsampling and everything in between (stretch in one direction and shrink in the other). However, the "down" ones will do better at minimizing the undesirable artifacts generally apparent when performing (heavy) downsampling, and the "up" ones will do better at minimizing artifacts generally apparent when performing (heavy) upsampling. For plain translation (parallel to the axes or not), any of them would work well; my hunch is that the "upsharp" ones would do better.

> > If the difference between FastSharpUpsize and SharpUpsize is qualty then > it should not be named "Fast",
>

I take note.

I also note that using a quality level parameter (inherited from calling operations or the "enviroment") may be the way to make the "fast" methods "invisible" to the users.

-----

Thank you.

Nicolas Robidoux Laurentian University

Let me try to explain the motivation for having different methods for transformations which are tuned for upsampling on the one hand, and downsampling on the other, and why a "one size fits all stylishly" scheme is neither easy to put together nor likely to be fast.

Practical explanation:

If one wants a "cheap upsize," bilinear is acceptable, and bicubic/lanczos are better. However, when used to downsample, these schemes behave almost like nearest neighbour, which sucks for producing thumbnails, for which variants of box filtering are way better. On the other hand, box filtering behaves like nearest neighbour when upsampling. This suggests that getting a single scheme which is great in both situations is not so easy.

One can actually implement a more refined box filtering which is less nearest neighbour-like when upsampling. An example of such a scheme is nohalobox (see bugzilla) = downsharp/smooth. It's a good all around scheme, and it's reasonably cheap, but when upsampling it can't compete quality and speed wise with, say, Lanczos or upsharp.

Bit more math:

Locally, one can characterize transformations pretty well by considering the singular values of its Jacobian matrix (think of them as the absolute values of eigenvalues of the affine transformation which is the best approximation to the transformation at the point under consideration).

Suppose now that one wanted to construct a scheme which does well in all circumstances. When both singular values are larger than 1: Use a good upsampling scheme. When both singular values are smaller than 1: Use a good downsampling scheme. What about all the other cases? Although it is possible to "blend" schemes, if the warp has a lot of variability accomodating both schemes will introduce artifacts and, more importantly, is likely to lead to a scheme which is slow in all circumstances.

Hence, in my opinion, the need for a choice.

------

Now:

A GUI with the purpose of image resizing could keep this issue invisible to users:

If enlarging in both directions -> "upsharp" or "upsmooth" (a "smooth" toggle could do)

If shrinking in both direction -> "downsharp" or "downsmooth"

If enlarging in one and shrinking in the other: Either make an educated guess based on which one is most representative, or use the "up" scheme first, and then the "down" scheme.

However, the point of the samplers is that if and when perspective and complex warping are implemented in gegl, they won't skip a beat.

Nicolas Robidoux

On 11-07-09 03:47, Nicolas Robidoux wrote:

Let me try to explain the motivation for having different methods for transformations which are tuned for upsampling on the one hand, and downsampling on the other, and why a "one size fits all stylishly" scheme is neither easy to put together nor likely to be fast.

Practical explanation:

If one wants a "cheap upsize," bilinear is acceptable, and bicubic/lanczos are better. However, when used to downsample, these schemes behave almost like nearest neighbour, which sucks for producing thumbnails, for which variants of box filtering are way better. On the other hand, box filtering behaves like nearest neighbour when upsampling. This suggests that getting a single scheme which is great in both situations is not so easy.

One can actually implement a more refined box filtering which is less nearest neighbour-like when upsampling. An example of such a scheme is nohalobox (see bugzilla) = downsharp/smooth. It's a good all around scheme, and it's reasonably cheap, but when upsampling it can't compete quality and speed wise with, say, Lanczos or upsharp.

Bit more math:

Locally, one can characterize transformations pretty well by considering the singular values of its Jacobian matrix (think of them as the absolute values of eigenvalues of the affine transformation which is the best approximation to the transformation at the point under consideration).

Suppose now that one wanted to construct a scheme which does well in all circumstances. When both singular values are larger than 1: Use a good upsampling scheme. When both singular values are smaller than 1: Use a good downsampling scheme. What about all the other cases? Although it is possible to "blend" schemes, if the warp has a lot of variability accomodating both schemes will introduce artifacts and, more importantly, is likely to lead to a scheme which is slow in all circumstances.

Hence, in my opinion, the need for a choice.

------

Now:

A GUI with the purpose of image resizing could keep this issue invisible to users:

If enlarging in both directions -> "upsharp" or "upsmooth" (a "smooth" toggle could do)

If shrinking in both direction -> "downsharp" or "downsmooth"

If enlarging in one and shrinking in the other: Either make an educated guess based on which one is most representative, or use the "up" scheme first, and then the "down" scheme.

However, the point of the samplers is that if and when perspective and complex warping are implemented in gegl, they won't skip a beat.

Nicolas Robidoux