"Sigmoidal" minimization of resampling filter haloing & blur

[NicolasRobidoux]

...
To me, downsampling in linear RGB with sigmoidal minimization looks much like downsampling in sRGB plus cooked highlights. I think it is better suited for upsampling.

Case closed: Don't use sigmoidization for downsampling.
(Thank you Henry.)

[NicolasRobidoux]

Anthony and Cristy: I'm adding comments to the enhance.c code making clear what the broken and functioning code is.
(Apologies: With IM7 svn, I forgot to use svn changelist to narrow my commit to enhance.c and no more. Won't forget with IM6.)

[anthony]

Updated the sigmoidal resize variation example. Give it an hour or so (three images instead of four)
http://www.imagemagick.org/Usage/resize ... _sigmoidal

Removed the 'special' filter in favour of a standard "Lanszos", for better comparison between linear colorspace resizing of using tensor (to pass 1-d), cylindrical (2-d), and sigmoidal (2-d).

Also changed the value from 6 to 6.5 to clear show that that value is a floating point value!!! That can be important to other users wanting to try this out, without explicitly emphasising that fact in text they often don't read!

Added notes about how this is 'similar' to resizes in sRGB colorspace, though not the same, and HenryWho's comment about it being more suitable for enlargements only.

Nickolas, I prefer not to include very large images in the example pages, which has an extreme number of images already. However the example is now quite clearly showing the resulting benefit of a sigmoidal modification to the colorspace.

ASIDE: I also added a new example in Ringing Artifacts
http://www.imagemagick.org/Usage/resize/#ringing
This clearly shows how different resize vs distort is with regards to the ringing artifacts produced by Sinc/Jinc filters.

[anthony]

...
To me, downsampling in linear RGB with sigmoidal minimization looks much like downsampling in sRGB plus cooked highlights. I think it is better suited for upsampling.

Case closed: Don't use sigmoidization for downsampling.
(Thank you Henry.)

Note sRGB is similar to a sigmoidal function but with a mid-point (knee) of 0% It does not treat dark and light ringing effects equally. sigmoidal also give you far more control (intensity and light/dark difference).

Try sRGB and sigmoidal on a image of near pure white and black colors..
for example on this (linear RGB) image...

Code: Select all

-size 10x10 xc:'gray(10%)' xc:'gray(90%)' +append

For example...

Code: Select all

convert -size 10x10 xc:'gray(10%)' xc:'gray(90%)' +append \
            -set colorspace RGB -resize 800% -colorspace sRGB show:

and this

Code: Select all

 convert -size 10x10 xc:'gray(10%)' xc:'gray(90%)' +append \
             -set colorspace RGB +sigmoidal-contrast 6,50% -resize 800% \
             -sigmoidal-contrast 6,50% -colorspace sRGB show:

the first has a very dark 'ring' but not much white. While the second is much more moderated.

[anthony]

Hmmm I may have found a better solution to prevent most ring-clipping problems....

It was with regards to color drift, and using LAB colorspace to avoid it (now that LAB is stored as a linear colorspace)...
viewtopic.php?f=22&t=21435&p=87862#p87862

[NicolasRobidoux]

The overall image will become darker too, not just halos. Try downsizing a photo of cactus.

Henry: I did not pick up when I read this the first time that you were referring to downsampling. And we now both know that "sigmoidalization" should not be used when downsampling.

[NicolasRobidoux]

Try sRGB and sigmoidal on a image of near pure white and black colors..
for example on this (linear RGB) image...

This is an excellent example. The following variant makes it really clear what sigmoidization does:

Code: Select all

convert -size 10x10 xc:'gray(10%)' xc:'gray(90%)' +append \
  -set colorspace RGB +sigmoidal-contrast 20,50% -resize 800% \
  -sigmoidal-contrast 20,50% -colorspace sRGB show:

Keep in mind that our eye is much more sensitive to slight variations in darks than in lights.

[NicolasRobidoux]

Following comments by Anthony Thyssen (but not necessarily agreeing?), I would recommend that if your final image is going to be sRGB, you use "sigmoidal" enlargement through linear RGB with sRGB primaries, but if your final image is not sRGB (or linear RGB with sRGB primaries), you try to figure out a (physically, not perceptually) linear colourspace that has a matching, or close to matching, gamut to your output colourspace and use sigmoidal enlargement through that. Not sure if linear RGB with sRGB primaries is good enough for ARGB, for example, but this would seem likely.

[NicolasRobidoux]

Much discussion of this topic happened here: viewtopic.php?f=22&t=21435#p87630.

[NicolasRobidoux]

Very preliminary tests suggest that it does not make a huge difference whether one sigmoidizes through linear RGB or XYZ.
-----
Maybe XYZ could be a way of working,possibly with a higher contrast value, in a space which is more resilient with respect to gamut over and undershoots in the input image when the raw material is something else than sRGB or linear RGB with sRGB primaries?

[NicolasRobidoux]

Ah! This is probably the solution to my dilemma RE: "what do we do when the input image, say, has negative transparency, or under- or overshoots the nominal gamut because of, say, conversion between colourspaces that don't fit together quite right?".

Possible solution:
1. At each input pixel location, find the local min/max over a support larger than the filter stencil.
2. Reconstruct a surface that interpolates these min and max using something like LBB (Locally Bounded Bicubic, which is programmed in GEGL and VIPS).
3. At each sampling point of the enlarged image, use the min and max as the "bounds" of the sigmoidal.

The hope is that these reconstructed local min/max are smooth enough that they will not introduce their own artifacts (most likely, aliasing). This approach, however, should suppress haloing even more than the current sigmoidalized upsampler versions.
This is also a substantial programming project: The sigmoidal transformation is applied in a locally data-dependent manner.
If you are someone who would be interested in helping program this (even as a MATLAB straw man, say), please contact me: I'm about to graduate my last grad student, and consequently manpower for experimental projects will take a nose dive! (Warning: I have no money.)
I am also starting to wonder whether, instead of working in linear RGB, one should reconstruct a local linear colourspace (with the singular value decomposition) which is aligned with the colour axes along which there is the most variation, and then clamp in an aligned way. The trouble, of course, is that one then wonders what to you do when the SVD ellipsoid has axes of equal length. One would need to make sure that the affine transformation to the locally defined "colourspace" is smooth... (This is starting to look kinda like a structured grid generation problem.)
(Apologies for the rather opaque comments.)

[fmw42]

I am also starting to wonder whether, instead of working in linear RGB, one should reconstruct a local linear colourspace (with the singular value decomposition) which is aligned with the colour axes along which there is the most variation, and then clamp in an aligned way.

The IM OHTA colorspace is an approximation of the Principal Components Transformation.

see
http://en.wikipedia.org/wiki/HSL_and_HS ... e_analysis and references 33,34

[NicolasRobidoux]

viewtopic.php?f=22&t=21575&p=88457#p88457

[NicolasRobidoux]

Sigmoidization also works well with smoothing filters, like Quadratic and Cubic (orthogonal or not).

[NicolasRobidoux]

Here is a pragmatic way of setting the contrast value for sigmoidization to be used for a specific resampling filter with negative lobes, based on the idea that if text looks good in sRGB 8-bit (which is a reasonable approximation of our perception, and is also widely used) and natural images also look good, then we have a winner:
Surround a large enough (width=height larger than the window extent) black square by white. Enlarge a lot with the filter of your choice. A good choice of contrast value ("a" in the source code) is one that ensures that there is no halo whatsoever inside the enlarged square (in 8-bit sRGB).
I'll document such values (approximately at first) in this thread.