"Sigmoidal" minimization of resampling filter haloing & blur

[NicolasRobidoux]

...
Perserving the "mass" of a grey impulse on a black (or white) background leads to a value that's just above 6.5987.

This particular value is incorrect because I computed it expecting 16 bit grey to be 65535/2 rounded up or down (that is, 32767 or 32768). It's not. Neither is grey50 which turns out to be 127 * 257, a sensible value but nonetheless not what I expected.

[anthony]

Note that gray50 (as you found out) is like all 'named' colors an 8-bit color value. It is correct but only to 8-bit places.
the mathematically correct value for Q16, Q32, Q64, or HDRI versions of IM is to use 'gray(50%)' as this is a calculated value.

Note also that gray50 is sRGB, while gray(50%) is linear-RGB (gray)

Code: Select all

convert xc:gray50 txt:
# ImageMagick pixel enumeration: 1,1,65535,srgb
0,0: (32639,32639,32639)  #7F7F7F7F7F7F  grey50

convert xc:'gray(50%)' txt:
# ImageMagick pixel enumeration: 1,1,65535,gray
0,0: (32768,32768,32768)  #800080008000  gray(50.0008%,50.0008%,50.0008%)

[NicolasRobidoux]

Thank you Anthony.

[NicolasRobidoux]

I am starting to think that, at least when downsampling, sigmoidization should be done in a perceptual (e.g. sRGB or L*a*b*) color space. With a mild (<10) contrast value.

[NicolasRobidoux]

Separately from the question of whether sigmoidization should be done through a perceptual color space instead of linear light, I see that, when downsampling, sigmoidization gives better results that downsampling sRGB directly. For example,

Code: Select all

convert input.jpg -colorspace RGB +sigmoidal-contrast 6.4797 -distort Resize 200x200\> -sigmoidal-contrast 6.4797 -colorspace sRGB output.jpg

gives pretty good results.
Better than downsampling through linear light (without sigmoidization)? Probably not. But it has a different character: small dark and light features are "highlighted", at the expense of midtones. That is, it gives a somewhat more "punchy/contrasty" image without affecting the tone of large enough patches (that is, it preserves colours, but highlights dark and light small details on midtone backgrounds at the expense of midtone details on dark or light backgrounds).
For some types of images, this may be a good thing.
This work well with EWA LanczosSharp as well (not only the default EWA filter, namely Robidoux).

[NicolasRobidoux]

Downsampling "straight through sRGB" wipes out small light details. Which is totally unsurprising.

[anthony]

using a 'DIY sigmoidal colorspace' while in a perceptual colorspace to me does not make any sense at all.

However using a colorspace like LAB ro LUV but with the 'L' replaced with the linear intensity, That is a sort of
linear IAB and IUV colorspace. This may actually work well, if a little difficult to get setup in a current version of IM.

The 'clipping' problem is being caused by intensity getting clipped unequally as it is spread over three color channel.
LAB and LUV separates intensity from the color, so if intensity gets clipped, the color does not get distorted.

This would mean extracting intensity and LAB as seperate images, then replacing L with I to create a IAB type
colorspace. After the resize the I has to be extarcted and converted back to L to re create LAB, for conversion back to sRGB for output.

Hmmm... lets see If I can convert to and from this proposed 'IAB' colorspace...

Code: Select all

  convert rose:  \( -clone 0 -colorspace gray \) \( -clone 0 -colorspace Lab \) \
              -delete 0  -separate -delete 1-3 -combine \
              -noop \
              -separate \( -clone 0 -set colorspace RGB -colorspace LAB \) -swap 0 +delete \
              -combine -set colorspace Lab -colorspace sRGB rose_distort_iab.png

The 'noop' should be where the resize goes, but my attempt to do a round-trip of a IAB colorspace failed.
Can you see where it fails? Result should be exactly as original.

C
Reporting in Bugs.

[NicolasRobidoux]

Anthony: Have you tried running this in HDRI?

[NicolasRobidoux]

Anthony:
As soon as you have negative lobes (actually, as soon as you do weighted averages of values, so this goes with, say, the Triangle filter, as well), you "distort" colours. But this is most pronounced with negative lobes (specifically, with filters which are not "locally bounded").
IMHO, the key issue is how to minimize the negative side effects of the colour blending, given that it is there no matter what (in various amounts, of course).
Also: My gut feeling is that differential treatment of a luma or luminance channel is generally going to be a disaster (this is a theoretical gut feeling: I'm not talking about implementation). But I would not be surprised if my gut is wrong. There is something smart to do in this business, and I do like the use of a colour space with a luma and luminance channel. What I think is most likely a mistake even though it is conceptually attractive is the idea of filtering individual channels differently. This is a bit like dealing with an alpha channel: You'd think that filtering it differently than the other channels is a good idea, but the best is using pre-multiplied light and using the same filter for all channels, luma, chroma and alpha.

[NicolasRobidoux]

I don't have time for experimentation that's not directly tied to income generation these days, but when I have a minute, I'll try sigmoidizing through sRGB and Lab instead of linear RGB or XYZ. For example, if the input image is sRGB (like pngs are supposed to be),

Code: Select all

convert INPUT.png +sigmoidal-contrast CONTRAST -filter Lanczos -define filter:blur=.9891028367558475 -distort Resize WIDTHxHEIGHT -sigmoidal-contrast CONTRAST OUTPUT.png

or

Code: Select all

convert INPUT.png -colorspace Lab +sigmoidal-contrast CONTRAST -filter Lanczos -define filter:blur=.9891028367558475 -distort Resize WIDTHxHEIGHT -sigmoidal-contrast CONTRAST -colorspace sRGB OUTPUT.png

P.S. Just tried them quickly. Too fast to know if this is a great way to enlarge, but long enough to know that it's not bad. Sigmoidization with straight sRGB, in particular, seems promising when the source and target are sRGB. And sigmoidization within Lab seems to change the character of the "colour bleed". Which is, of course, unsurprising.
P.S. Sigmoidization through Lab appears to do quite well at preserving colours. In my very limited testing, "colour bleed" is nicely contained. I'm impressed.

[NicolasRobidoux]

Anthony:
What's the sense of this?
Over and undershoot artifacts are a nuisance no matter what type of colorspace one uses.
Sigmoidization is a way to tame them no matter the context (provided the colour space can reasonably be treated like it's a cube; otherwise, the sigmoidal conversion cannot treat the channels separately: one would need to use balls or ellipsoids or radial wedges or ...).

[anthony]

The point is though the Intensity may get clipped.. it is separate to the color channels (A,B) so does not general color skew, only an intensity limitation. As such while the image still has proper linear resizing, we should not be getting the distortion seen when we do the resize in RGB or XYZ space due to different color channels being clipped differentially.

Basically I am trying to reduce color skew for a linear resize. LAB and sigmoidal are not linear resizes.

I am not saying we will not get some distortion but only from intensity clipping, not unequal color clipping.

[NicolasRobidoux]

Anthony:
My gut feeling:
Your idea is fine in theory.
In practice, however, I expect that you will find out that no colour space "perfectly" separates intensity from colour, and the "unevenly applied" limiting will leave artifacts, esp. when the source and final product are in a rather small color space like sRGB.
I don't mind being proven wrong. I'm just communicating what I think will happen.
This stand is taken without experimentation to back it up.

[anthony]

Which is what I am trying to do.

But I first have to get a 'no-op' round trip working before I can try resizing the image!
But we now have bug fixes for separate and that should 'fix' the problem.

This converts the image to Lab, seperates the channels
reconverts the 'L' channel to linear intensity without color channels
combines, resizes, seperates
the reverses the intensity channel back to a 'L'
and combines it back into a sRGB image

Code: Select all

convert rose: -colorspace Lab -separate \
            \(  -clone 0 -channel GB -evaluate set 50% +channel \
                -set colorspace Lab -colorspace Gray \) -swap 0 +delete \
            -combine \
            -filter Lanczos -distort Resize 600x \
            -separate \
            \( -clone 0 -set colorspace Gray -colorspace LAB -separate -delete 1,2 \) -swap 0 +delete  \
            -combine  -set colorspace Lab -colorspace sRGB show:

The result showed no color skew, but intensity was clipped and teh halo effect is much more pronounced. Basically we still ended up with a very dark ringing effect, that looks worse than the linear RGB color skewed result. I think havng all the clipping in the one channel rather than spread over three channels was the reason for the increased effect.

Hmmmm.. repeating this with a resize 50% on the rules-sucks image shows it is basically a linear resize, though with some very minor 'yellowing'. So at least the above is a linear resize!

Still it was a interesting experiment.

[NicolasRobidoux]

Which is what I am trying to do.

Proving me wrong?