Enlarge with sRGB, RGB, LAB, LUV, XYZ, sigmoidal,... gamma?

[NicolasRobidoux]

Here is the code (bash *nix shell):

Code: Select all

magick input_small.png -filter Point -resize 800% nearest.png
magick input_small.png -define filter:filter=Sinc -define filter:window=Jinc -define filter:lobes=3 -resize 800% sRGB.png 
magick input_small.png -colorspace RGB -define filter:filter=Sinc -define filter:window=Jinc -define filter:lobes=3 -resize 800% -colorspace sRGB RGB.png 
magick input_small.png -colorspace LAB -define filter:filter=Sinc -define filter:window=Jinc -define filter:lobes=3 -resize 800% -colorspace sRGB LAB.png
magick input_small.png -colorspace LUV -define filter:filter=Sinc -define filter:window=Jinc -define filter:lobes=3 -resize 800% -colorspace sRGB LUV.png
magick input_small.png -colorspace XYZ -define filter:filter=Sinc -define filter:window=Jinc -define filter:lobes=3 -resize 800% -colorspace sRGB XYZ.png
magick input_small.png -colorspace RGB +sigmoidal-contrast 9.520945 -define filter:filter=Sinc -define filter:window=Jinc -define filter:lobes=3 -resize 800% -sigmoidal-contrast 9.520945 -colorspace sRGB Sig9p520945.png
magick input_small.png -colorspace RGB +sigmoidal-contrast 11.6933 -define filter:filter=Sinc -define filter:window=Jinc -define filter:lobes=3 -resize 800% -sigmoidal-contrast 11.6933 -colorspace sRGB Sig11p6933.png

To keep the files smallish, I postprocess with

Code: Select all

pngcrush input_small.png c.png
mv c.png input_small.png
pngcrush sRGB.png c.png
mv c.png sRGB.png 
pngcrush RGB.png c.png
mv c.png RGB.png 
pngcrush LAB.png c.png
mv c.png LAB.png
pngcrush LUV.png c.png
mv c.png LUV.png
pngcrush XYZ.png c.png
mv c.png XYZ.png 
pngcrush Sig9p520945.png c.png
mv c.png Sig9p520945.png
pngcrush Sig11p6933.png c.png
mv c.png Sig11p6933.png

(Yes, I know this is pretty ugly scripting.)
Note: I use bleeding edge ImageMagick 7 compiled in HDRI mode.

[NicolasRobidoux]

The small dragon from http://www.imagemagick.org/Usage/images: . Below, I show the results of enlarging it 8x.
Nearest neighbour:

Straight sRGB:

Linear RGB:

LAB:

LUV:

XYZ:

"Safer" sigmoidal:

"Less safe" sigmoidal:

[NicolasRobidoux]

(SPOILER ALERT: Don't read this if you don't want the way you look at the images to be influenced.)
Generally, the linear light colour spaces (linear RGB and XYZ) produce exaggerated dark halos, and the "perceptual" colour spaces (sRGB, LAB, LUV) produce exaggerated light halos.
If you think about it for a minute, this makes complete sense, because the perceptual colour spaces pack lots of bits at the darker end of the intensity spectrum, and "hollow out" the lighter end, so as to mimick the HVS (Human Visual System). So, 1 unit of dark overshoot gets you less "far" in sRGB than in linear RGB, but 1 unit of light overshoot gets you less "far" in linear RGB than sRGB.
Sigmoidization treats dark and light overshoots equally, and generally dampens both.

[NicolasRobidoux]

These tests confirm something I've been suspecting for a while: The "safer" sigmoidal contrast value may not be quite as safe as I want it to be.

[fmw42]

Nicolas,

Please explain a bit more what you mean by "interpolatory".

Fred

[NicolasRobidoux]

@Fred: Here is Anthony's quick and dirty summary:

It means (that) if an image is resampled without resizing (a "no-op" resize) the image remains completely unaffected by the filter.

My explanation:

Instead of writing a bunch of equations, let me explain it using a greyscale image as example.

You can understand a greyscale image as being a sampled surface: the pixel value p_ij is the height of the surface at the pixel location (i,j). (I'll gloss over the various image geometry conventions.)

One way to understand resampling (image enlargement, for example), is that we'll reconstruct a continuum surface from the samples, and then we'll evaluate the reconstructed surface at the new sampling locations (the pixel centers of the enlarged image, for example). Consequently, a resampling scheme is completely defined by the reconstructed continuum surface.

Definition: A resampling scheme is interpolatory if the reconstructed continuum surface interpolates the input data, that is, if every input point (i,j,p_ij) is right on the surface, not above or below.

Interpolatory IM -resize methods (when not downsampling): All the windowed Sincs (including Lanczos), Catrom, Triangle, Point, Hermite, cardinal BC-splines (with B=0), Lagrange.

Non-interpolatory IM -resize methods: Mitchell, Gaussian, Quadratic, Cubic, BC-splines with B different than 0.

[anthony]

But EWA methods (and the default mitchell -resize filter) change images under "no-op".

If IM did not 'short-circuit' the resize no-op, which it does. So it is had to see this no-op effect of tensor filtered images.

The worse non-interpolative filter however are the Gausiian and Gaussian-like filters. But even a no-op resize using those filters will be short-circuited showing no effect. But you can fake it using a -blur 0x0.5, if you like to see it!

A non-interpolating tensor filter (bets are off for cylindrical) has a non-zero value at integer distances in the filter weighting function. This is explained in opening remarks for Gaussian filters...
http://www.imagemagick.org/Usage/resize ... r_gaussian

Sinc and Sinc Windowed filters have that zero at integer distances property, so are true-interpolatory filters.

Note not even all interpolation methods have that property! (average, Spline, etc)

[anthony]

Generally, the linear light colour spaces (linear RGB and XYZ) produce exaggerated dark halos, and the "perceptual" colour spaces (sRGB, LAB, LUV) produce exaggerated light halos.
If you think about it for a minute, this makes complete sense, because the perceptual colour spaces pack lots of bits at the darker end of the intensity spectrum, and "hollow out" the lighter end, so as to mimick the HVS. So, 1 unit of dark overshoot gets you less "far" in sRGB than in XYZ, but 1 unit of light overshoot gets you less "far" in XYZ than sRGB.
Sigmoidization treats dark and light overshoots equally, and generally dampens both.

Nice summary... I have added it to the resize page in
http://www.imagemagick.org/Usage/resize ... ce_summary
(when it updates)

[fmw42]

Correct me if I am wrong, but I think you guys are saying that the interpolatory filters have zero (crossings?) at integer pixel values.

[anthony]

Yes... As such if the sample point hits a pixel exactly (well that pixel's center point), that pixel will have some weight (any weight) but all of its orthogonal neighbouring pixels (1 pixel away at unity scaling) will have a weight of zero. The result of the averaging weighting by the filter will then be just the pixel that was hit, with no blending (blurring) with any of the other neighbours. Thus the 'image surface' will be reproduced exactly when a no-op distortion is applied.


In EWA, the distances are not just to orthogonal neighbours, but also to diagonal and all other neighbours in the 'support circle/cylinder/ellipse). A filter weighting scheme can not then assign a zero weighting to neighbouring pixels.

In another scheme Area Weighting Scheme that I and Nicholas discussed, uses either distorted parallelograms, or diamonds rather that ellipsis. In this technique interpolatory filters could be made to assign a zero weight all neighbours for no-op distortions. However such a technique has not been implemented or trialled to see how well it would work, or what sort of performance penalty it would have. I think it could do better that EWA in many situation, especially for small scale distorts, while producing equivalent results for large scale 'horizon' distortions.

[fmw42]

Questions:

1) Do you find certain conditions that you would process in some linear space (RGB or XYZ) and others where you would process in non-linear space (SRGB or LAB, etc)?

2) Do you find that white overshoots are better processed by linear vs non-linear colorspace and that black overshoots are better processed by the opposite colorspaces?

If this is the case, you can create a lookup table sigmoidal function that is a ramped blend of applying the sigmoidal function to linear and non-linear gradients. Would that help in any way? You thus can generate a non-symmetric sigmoidal function that might work better for both dark and light overshoots.

Or one might determine the amount of contrast in an image and adjusting the sigmoidal function from working in a linear space or a non-linear space by the amount of contrast.

Just some brainstorming ideas.

Fred

[NicolasRobidoux]

1) Do you find certain conditions that you would process in some linear space (RGB or XYZ) and others where you would process in non-linear space (SRGB or LAB, etc)?

Downsample in linear light (RGB or XYZ).

2) Do you find that white overshoots are better processed by linear vs non-linear colorspace and that black overshoots are better processed by the opposite colorspaces?

When not downsampling: If there are lots of light halos, go for linear light. If there are lots of dark halos, go for sRGB.
I'll be able to say more once my student Adam Turcotte's thesis is officially published.

If this is the case, you can create a lookup table sigmoidal function that is a ramped blend of applying the sigmoidal function to linear and non-linear gradients. Would that help in any way? You thus can generate a non-symmetric sigmoidal function that might work better for both dark and light overshoots.

Yes it would. But what this would do is trade off light for dark halos, without minimizing both.
Sigmoidization minimizes both.
I'm still trying to find a better sigmoidal. The logistic one is good. But it leads to too much colour separation IMHO. (You may not have noticed it, but it's there. It's insignificant with the other spaces.)
At this point, I think that deviating from Weber's Law (which one can use to justify the logistic sigmoidalization) and using a symmetrized cubic or gamma with one of the usual gammas (2.18?), or the second component of Ferwerda et al's model of the HVS JND may do the trick. Or just use a square (root) http://www.stanford.edu/class/ee368b/Ha ... eption.pdf.

[NicolasRobidoux]

The algebra on these newly suggested sigmoidal variants (if I want to use an S curve which is infinitely differentiable in the interior of the key interval, and I want both the S curve and its inverse to have a reasonable closed-form formula) is a mess.
The other thing is that colour separation is the price paid for the "sharpening" effect of the logistic sigmoidal. (Of course if you lower the contrast value, it goes away.) So maybe it's OK.
I'll give this a rest for a while. So: The logistic sigmoidal (which is the same one obtained with the hyperbolic tangent) is it for sigmoidization for now.

[fmw42]

I was more curious about enlarging as that was the topic here regarding my suggestions of combining two kinds of sigmoidals, one for the overshoots and one for the undershoots (lights vs darks). Thus a smooth but asymmetrical sigmoidal

[NicolasRobidoux]

@Fred: Here is an related to your idea, a simplified version of something I tried at the very beginning of my sigmoidization experiments viewtopic.php?f=22&t=21415:
Suppose that you want to enlarge an sRGB image.
Do reverse video on it, tag is as (linear) RGB, and convert to sRGB.
Now, enlarge with your favorite linear filter.
Undo the last RGB to sRGB conversion.
Convert to reverse video (which undoes the original reverse video).
Tag as sRGB.
You're done.
The above is not heavily asymmetrical w.r.t. light and darks (if your original and final images are interpreted as sRGB), but it is asymmetrical.
-----
Another simple idea: You could blend the result of enlarging straight through sRGB with the result of enlarging through RGB. More sRGB -> more light halo. More RGB -> more dark halo.
-----
These are just simple ideas along the lines of what I understand you are suggesting.