Legacy ImageMagick Discussions Archive

Yes. And Jinc as a window for Sinc in the orthogonal case.

So, I may get a worthwhile scheme to call "Ginseng" after all. The earlier, abandoned, candidate was EWA Sinc-windowed Jinc. Today's one is orthogonal (tensor) Jinc-windowed Sinc.
P.S. The critical contrast value for the Ginseng scheme is just under 21.0645.

Preliminary: XYZ, a linear light colourspace with a luminance channel (Y), appears to be a better colourspace to sigmoidize through than (linear) RGB (with sRGB primaries). Makes me wonder if sigmoidization should only be used on the luminance channel.
P.S.... and when going through XYZ, there is not as great a difference between Lanczos 3 and Jinc-windowed Sinc 3.
P.S. Sigmoidization through XYZ is definitely worse if the image is sRGB or RGB binary (pure black and pure white, like text), at least with IM and (orthogonal) Lanczos.

Contrast in the ballpark of 20 appears to be too high for an "all purpose" setting. Works well with subcritical images with a "bell curve" histogram, no so well when there are sharp extremes.

Embarrassing: I was comparing 4-lobe Jinc-, Cosine- and Welsh-windowed Sinc to Lanczos 3. Hence the nice "sharpness" and additional halo.
P.S. In terms of visual quality with 3 lobes, Lanczos still wins.

I put a quick "how to" summary here: viewtopic.php?f=1&t=21660.

To see if I can throw a 'spanner in the works'... And Nicholas... Think things through for an hour or so before actually answering

LAB and LUV are really 'perceptual' colorspace like sRGB. In fact it produces the same results (using a flicker comparison of images) as resizing in sRGB colorspace. Also LUV is perceptually linear along the color axises, which is not the case with sRGB.

Which brings me to a point I made before. The weighted average filtering is designed to work on 'linear' data. But should the linear data be 'linear light levels' or 'linear perceptual levels'. I'm starting to think that resizing in perceptual colorspace (LAB or LUV) is far better than in a linear colorpsace (RGB, XYZ). Even though the intensity mixing result you get when merging neighbouring light and dark pixels is not quite the same as when simply looking at those pixels from some 'distance' from a monitor.

Bringing this back to the topic at hand. Is the use of a sigmoidal modification to the colorspace really that useful? It adds a major non-linear component, that is not even perceptually linear. In fact it does not have any real world equivalent to image processing that I can see. Also if it is only for 'intensity' problems. why not limit it to intensity in LAB and LUV colorspace?

@Anthony:

I am not sure that sigmoidization---or at least the current version of sigmoidization---is "the final word" when dealing with negative lobe filter artifacts, but it seems pretty good.
Applying it, or something like it, to a luminance or luma channel only is very reasonable. But I believe that, at least with sRGB images, linear RGB is best when used with sigmoidization, because my intuition is that it is preferable not to involve colourspace transformations which themselves have overshoots and undershoots ("negative matrix coefficients") in the forward or backward direction, and I have reasons to want the sigmoidal to be "tight" w.r.t. the gamut. sRGB <-> linear RGB with sRGB primaries does not introduce over or undershoots, or clipping.

Sigmoidization is a way to take the edge off artifacts introduced by negative lobe filters. Strong halos have nothing "physical" about them. So I have no qualms using a "nonphysical" transformation to control them. One may argue that halos make the Mach bands, an optical illusion, "real", so that, in a way, they are "perceptual". I find that to be a poor rationalization.

It is also reasonable to select a "standard" colourspace other than, say, XYZ, as a good candidate for "where the filtering is done", without involving sigmoidal-contrast at all.

The key question to me is: Does sigmoidization produce better enlargements (or warps) than the alternatives, or not? Proof in the pudding, that is.

If the answer is "Yes", I'll put together a reasonably good explanation of how and why it works. If the answer is "No", no amount of explaining will make the method good. So...

Would you be open to settle this dialectic by a back and forth comparison of enlargements?
The "rules of the game" I suggest are:
Enlargement only, with original input sRGB 8-bit, final output sRGB 8-bit, with -filter Lanczos -resize.
I understand that you do not like to put very large images on the web, so I'll refrain. But I think that, generally, enlargements by more than a factor of 2 are more informative. But you don't have to respect that preference: When it's your turn, you pick the test image and enlargement ratio.
With every test image, I'll provide similar enlargements through linear RGB, with "safe" sigmoidization (through linear RGB), and directly with sRGB values.
(I understand you are very very busy, and this is me asking you to help understand the limitations of a method I've proposed, as well as possibly ways of improving it. No offense if you decline.)

-----

You pick the first test image/enlargement ratio?

(Of course, there is always the chance that the comparison be inconclusive. But this, in itself, would be informative. The reason I exclude making images smaller is that this is an altogether different game.)

I would also prefer that you not use "broken" images as test images to be enlarged. If it's "ugly" when it's small, a faithful enlarger will make it "ugly" when it's big. Which IMHO defeats the purpose of the comparison.

@Anthony: I understand that we are discussing things at the level of
analogies and heuristics.

So, here is a heuristic comment:

About linearity: http://en.wikipedia.org/wiki/Linearity.

As soon as you have a non-infinite gamut in your colour space, nominally linear
filters (esp. those with negative over or undershoots) are not linear
anymore, meaning that

filter(a*image1+b*image2)

is not always equal to

a*filter(image1)+b*filter(image2).

The reason for this is that clipping is a nonlinear
operation, and clipping has to be applied sooner or later to "fit" the
result into the target colourspace.

The results are actually the same provided that clipping is always
performed at the last possible minute AND a*image1+b*image2 is
within gamut at every pixel. Even if a=1 and b=0, this last
condition does not generally hold if there are negative
coefficients. So, esp. near the limits of the gamut, linearity
assumptions are pretty much out the window with negative lobe
filters. This goes for physical and perceptual linearity.

So, I don't see nonlinearity as a good reason NOT to sigmoidize.
Because nonlinearity has entered through the back door as soon
as a colour space with a limited gamut is used.

One could say that I am fighting back door nonlinearity with
sigmoidization.

-----

This is not the first time that someone tries to use
nonlinearity to prevent or minimize under- and overshoots:

Ken Brodlie, Petros Mashwama and Sohail Butt: Visualization of surface
data to preserve positivity and other simple constraints. Computer &
Graphics, Vol. 19, Number 4, pages 585-594, 1995. DOI:
10.1016/0097-8493(95)00036-C.

http://forum.doom9.org/archive/index.php/t-145358.html

http://git.gnome.org/browse/gegl/tree/g ... r-lohalo.c

http://arxiv.org/abs/1204.4734

It's just AFAIK the first time that someone tries to do this
by building a custom colour space.

-----

Of course, none of the above has anything to say RE: whether sigmoidization is
a good thing.

And I would guess that the odds that filtering through a standard nonlinear
colourspace with a luminance or luma channel, or of sigmoidizing through such
a channel, being better, at 50/50.

The happy coincidence for me is that the sigmoid function that you and others had chosen for ImageMagick has the behavior I want from a back of the envelope viewpoint: Sloppy back of the envelope tells me that I want the gamut limit to be approached exponentially slowly, no faster and no slower, because I want the inverse to be logarithmic. And the logistic sigmoid, scaled or not, is pretty close from doing just that.

@Anthony: http://www.imagemagick.org/Usage/resize ... colorspace appears to make pretty clear what the main alternatives are, so I'll start a new thread when I have a minute, specifically about comparing them.
Thread is here: viewtopic.php?f=22&t=21804

The real smart thing to do would be to construct an S curve based on http://www.cg.tuwien.ac.at/research/the ... ode16.html or something like it (directly from the sRGB spec?).

Short of that, I think I may have decided on a satisfactory criterion for setting the contrast value: Match the light halo within darks suppression of sRGB when an image is black on the left, white on the right. Then, sRGB's dark halo suppression within lights will be far surpassed. It turns out that this is falls between my "safer" and "less safe" values when using the logistic sigmoidal, actually pretty close to the "safer" value, and it should be about the same for all filters with 3 lobes or more.

Take a look at equation 15 and chart 17 at http://radsite.lbl.gov/radiance/papers/ ... onemap.pdf (from the LaRP97 reference of your reference above)

However, the main reference to Shaler37 seems to be missing.

@Fred: Very very interesting!
P.S. on my last comment: Using the logistic sigmoidal is a bit like piecing together two Weber's laws, one for values near black, one for values near white. It's like symmetrizing Weber's law.

Note: My way of setting the sigmoidal contrast has been based on the second (bounce back) halo of methods with 3 or more lobes.
Not on the first overshoot.