A free high quality resampling tool for ImageMagick users

[NicolasRobidoux]

Opinion:
The Melbourne convention center is an example image in which EWA with a deblurred Jinc-windowed Jinc with 3 (maybe 4) lobes may be preferable to using EWA Keys cubic (which are 2-lobe methods) with post-sharpening, to eliminate the moire in the top right red wall without losing detail.
(Note that all my comments are off the top of my head: Based on experience, not experiment.)
P.S. Does the moire noticeably go down if the deconvolution sharpening amount is reduced?

[fdisilvestro]

Hi Nicolas,

I performed another test (I'm not sure if I addressed correctly your comments)

I have attached two images, one with comparisons made at 300% and the second one at 100%

- The top image is the same as the previous post, using the downsampling-optimized scheme with 100% sharpening
- The middle image is using the "generic" scheme without sharpening
- The bottom image is again using the generic scheme with deconvolution sharpening, Blur radius 2 px and 50% amount

I cannot tell if there is less moire with the generic version, maybe just a slight difference.  What I'm not sure is if I should try different parameters

Regards,

[NicolasRobidoux]

Looking at the last results posted by Frank, I think that EWA LanczosSharp (say) through linear light (skipping the gamma blending in the "generic" scheme) may do well with the moire, but I have to admit that the "downsampling" scheme does a pretty good job given how sharp it is. 3-lobe EWA Lanczoses, deblurred or not, will add some haloing/ringing if kept sharp
Maybe, in the "dowsampling" scheme, pushing the Keys C (a.k.a. alpha) down toward 0 and going light on the deconvolution sharpening?
No free hot lunch, most likely. But it would be nice to have something concrete to recommend when moire shows its ugly head.
-----
Idea:
Separately compute the result of 3-lobe EWA Lanczos through linear light. (I don't think LanczosSharp, either version, would be better for this.) Provide a "moire reduction" slider: 100% = pure EWA Lanczos through linear light. 0% = Pure "current downsampling scheme".
This way we are not messing with the tuned luminance weighted gamma blended deconvolution.
Will add ringing, sure, but that's less offensive than moire.

[Bart_van_der_Wolf]

Looking at the last results posted by Frank, I think that EWA LanczosSharp (say) through linear light (no dual blending, like is done in the "generic" scheme) may do well with the moire, but have to admit that the "downsampling" scheme does a pretty good job given how sharp it is. 3-lobe EWA Lanczoses will add some haloing/ringing if kept sharp
Maybe, in the "downsampling" scheme, pushing the Keys C (a.k.a. alpha) down toward 0 and going light on the deconvolution sharpening?
No free hot lunch, most likely. But it would be nice to have something concrete to recommend when moire shows its ugly head.

Letting the Keys 'C' go to 0.0 (and 'B' to 1.0) will produce more blurry output. By also lowering/eliminating sharpening the result will get quite soft, but aliasing, blocking, and ringing will also be minimal. Doing that as a simple linear light EWA Spline filter, without blending, works better than with blending.

Cheers,
Bart

[NicolasRobidoux]

Bart:
Indeed, that's the question: Is it possible to get rid of (most of) the moire without making things soft (or messing up the nice properties of downsampling through linear light)? My idea above hopes that one can trade moire for some ringing without losing too much sharpness.
Come to think of it, it one is willing to trade moire for not downsampling through linear light, blending the "downsampling" result with the "generic" scheme with sharpening set at 0 could work nicely, and would not add much ringing.
In any case, I like the original "blend (in linear light) the result of the "downsampling" scheme (before the conversion to sRGB) with the result of plain EWA Lanczos through linear light" idea more.
What do you think?
P.S. Maybe blending with the result of EWA Quadratic in linear light? (Can such a cheap filter be moire suppressing enough?)
Basically, there are two components to this "idea" of using a slider to let users reduce moire:
1) Find a good moire fighting filter that's not too blurry or ringy.
2) Make sure it jives, when blended, with the "downsampling" scheme.
P.S. 2 Maybe the moire is tolerable given the sharpness. (Using 67% sharpening instead of 100% makes it unnoticeable?) Any opinions? On this topic, see http://www.luminous-landscape.com/forum/index.php?topic=91754.msg751649#msg751649.

[snibgo]

Resample_by_Percentage_V122.bat contains a zero-consequence bug. Each of the four occurrences of:

-define convolve:scale=^%sharpAmount%%%,100

should read:

-define convolve:scale=%sharpAmount%%%^^,100

Explanation: the caret ^ is the Windows escape character. Windows says, okay, no need to do anything with that, and strips it before passing the command to convert.exe. But we want convert.exe to see the caret, meaning "normalize to make the kernel sum to zero", so the caret needs doubling in the command. I've moved it to the end because that's how the documentation http://www.imagemagick.org/Usage/convolve/#identity_addition has it. Perhaps the position doesn't matter.

This seems to be zero-consequence. Perhaps DoGs are zero-sum by design.

#3655:

... the remaining practical difficulty (with a batch script file) is to determine the fact whether one is effectively going to do upsampling or down-sampling, without asking the user for that.

I think the most sensible way is to tell IM to resize the image, and see what it comes up with. The result could be upsampled horizontally but downsampled vertically, eg a 1000x1000 image might be resized to 2000x500. As upsampling is the "generic" method, perhaps the rule is to use the downsampling method only if both dimensions shrink.

I have some more comments, but this margin is too narrow to contain them.

[NicolasRobidoux]

In the interest of making as quick progress as possible, let's agree that when downsampling (more than a little), nonlinear light (gamma different than 1) will only be used in the deconvolution step.
There may be some advantage to explore the alternative ("generic"-type luminance weighted gamma blending in the "prefiltering/resampling" step, as opposed to "downsampling"=type LWGB in the post-filtering step), but I think that the path of least resistance is to stick to linear light when downsampling (but not when sharpening).

[NicolasRobidoux]

...
This seems to be zero-consequence. Perhaps DoGs are zero-sum by design.
...

Alan: My guess is that if coefficients are computed accurately enough, things will turn out to be unnoticeably close to zero-sum.

[Bart_van_der_Wolf]

Hi Alan,

Thanks for joining us here. I appreciate your insights of the IM code specifics a lot, especially because of the Windows batch script dialect translations.

Resample_by_Percentage_V122.bat contains a zero-consequence bug. Each of the four occurrences of:

-define convolve:scale=^%sharpAmount%%%,100

should read:

-define convolve:scale=%sharpAmount%%%^^,100

Explanation: the caret ^ is the Windows escape character. Windows says, okay, no need to do anything with that, and strips it before passing the command to convert.exe. But we want convert.exe to see the caret, meaning "normalize to make the kernel sum to zero", so the caret needs doubling in the command. I've moved it to the end because that's how the documentation http://www.imagemagick.org/Usage/convolve/#identity_addition has it. Perhaps the position doesn't matter.

This seems to be zero-consequence. Perhaps DoGs are zero-sum by design.

Correct, according to the usage web page "All the edge detection kernels have one feature in common. They are all zero-summing." This can be verified by adding "-define showkernel=1", which will display the actual kernel values (if echo is on).

I remember struggling with the correct syntax when I started using the convolution option (and the convolve operator has changed over time), also due to the fact that the IM web page commands are UNIX oriented, and Windows batch files have slightly different syntax (such as the caret escape character instead of backslash). I stopped trying when it worked as intended.

In fact, the caret character by itself does not serve any function in the convolve operator, it was probably left over from an escaped exclamation point normalization in the past, and can now be removed all together because the DoG is zero-summing (unlike some other kernels I tried in the past), and normalizes automatically. As you said, the error is zero-consequence, but I've completely removed the caret for the updated script version 1.2.3. Should we decide it is useful for a future change (e.g. a hand-crafted kernel), it can also be replaced by an exclamation point to force a normalization (! may be more telling than ^^, and currently serves the same purpose in the -convolve:scale operator).

#3655:I think the most sensible way is to tell IM to resize the image, and see what it comes up with. The result could be upsampled horizontally but downsampled vertically, eg a 1000x1000 image might be resized to 2000x500. As upsampling is the "generic" method, perhaps the rule is to use the downsampling method only if both dimensions shrink.

The goal would be to predict which direction to take, instead of determining it afterwards.

I have some more comments, but this margin is too narrow to contain them.

Looking forward to more helpful comments.

Cheers,
Bart

[Bart_van_der_Wolf]

Alan: My guess is that if coefficients are computed accurately enough, things will turn out to be unnoticeably close to zero-sum.

Correct. The zero-summing and normalization are automatic, and I specified to create a slightly larger (7x7) kernel than the default (5x5) that IM calculated. That results in a normalized kernel sum that gives less than a maximum of 0.11 of an RGB value difference in 16-bit precision.

Cheers,
Bart

[Jack Hogan]

Correct. The zero-summing and normalization are automatic, and I specified to create a slightly larger (7x7) kernel than the default (5x5) that IM calculated. That results in a normalized kernel sum that's gives less than a maximum of 0.11 of an RGB value difference in 16-bit precision.

Hi Bart,

I am a big fan of your efforts here, thank you very much for doing this, I think we need a tool like this.  My constructive feedback on 1.2.2: it seems to me that the downsampling versions, with all those clones, gammas and blending are losing some local contrast along the way.  I thought it was the DoGs, but it looks like I was barking up the wrong tree

Jack

[alain]

Thanks for the good work.

[NicolasRobidoux]

Suggestion:
Since these ideas and scripts are starting to spread and hopefully people will start experimenting with variants (although they are awesome as is), I would like to suggest some terminology:
The "generic" scheme currently is LWGB3 deblurred EWA Lanczos (at least in the default version, without deconvolution).
The "downsampling" scheme currently is EWA RobidouxSoft with tuned LWGB3 Gaussian deconvolutions. (The plural comes from that the deconvolution parameters are slightly different for gamma 1 and gamma 3.)
LWGB3 = Luminance Weighted Gamma Blending (with gamma) 3.
EWA = Elliptical Weighted Averaging (the "clamped" version, advocated originally in Andreas Gustaffson's Masters thesis AFAIK, and the default in ImageMagick for a few years now, where it's called Clamped EWA. Nobody in her right mind should use the original Heckbert, non-clamped, version so I think we can safely drop the "clamped" in "Clamped EWA". On the other hand, the original version still occasionally shows up in academic papers so maybe Clamped EWA is better?)
RobidouxSoft if the Keys cubic with alpha=C=0.1601886205085204.
As components get swapped in and out, the above are easy to modify so that people (or at least I) know exactly what's going on. And then it's easier for everybody to search for the components and go directly where they are discussed. For example, someone blending with a gamma 2 result could use LWGB2 and then we'd all know what's going at a glance.
-----
Bart: These work for you? I suppose even shorter versions could be LWGB EWA Lanczos and EWA RobidouxSoft with LWGB deconvolution (or even EWA Keys with LWGB deconvolution, since the exact value of the Keys alpha is a detail). Still mouthfuls, but nonetheless pretty specific.

[NicolasRobidoux]

As Bart no doubt knows, more local contrast could most likely be obtained by using a larger Keys alpha (=C). But then he needs to retune the deconvolution, so this is not a one minute fix. And we'd need to see which artifacts this increases. Zero sum is hard to escape.

[Bart_van_der_Wolf]

Hi Bart,

I am a big fan of your efforts here, thank you very much for doing this, I think we need a tool like this.  My constructive feedback on 1.2.2: it seems to me that the downsampling versions, with all those clones, gammas and blending are losing some local contrast along the way.  I thought it was the DoGs, but it looks like I was barking up the wrong tree

LOL. As people say; A dog is man's best friend ...

Jack, I'm not sure where your perceived loss of local contrast comes from, but maybe it is the absence of artifacts (seeing that many people like Luminance aliased Sigma Foveon conversions)? All my tests show me that there is a very good correspondence between source and result although, due to the choice for a relatively soft interpolation filter, the need for post-resample sharpening is a given.

Of course, it is possible to process the down-sampled result (optionally with a sharpening amount of 0) with halo free tools like Topaz 'Clarity' or 'Detail'. That's why I maximize the 'Lossless' nature of the output, even for JPEGs. However, it is still on my To-Do list to find an automatic clamping function that allows to boost sharpening which will automatically throttle back locally when artifacts (like halo and clipping) begin to show-up. It will probably be something along the lines of a Blend-if functionality that I have mentioned before.

Thanks for your feedback.

Cheers,
Bart

[Bart_van_der_Wolf]

Bart: These work for you? I suppose even shorter versions could be LWGB EWA Lanczos and EWA RobidouxSoft with LWGB deconvolution (or even EWA Keys with LWGB deconvolution, since the exact value of the Keys alpha is a detail). Still mouthfuls, but nonetheless pretty specific.

Nicolas: Yes, sounds usable although cryptic for the uninitiated, but such is the nature of jargon.

Cheers,
Bart

[Bart_van_der_Wolf]

As Bart no doubt knows, more local contrast could most likely be obtained by using a larger Keys alpha (=C). But then he needs to retune the deconvolution, so this is not a one minute fix. And we'd need to see which artifacts this increases. Zero sum is hard to escape.

Indeed, but the trade-off between more artifact prone filters, or softer ones with added sharpening is always present. It is still on my radar to find an automatic Blend-if functionality that allows to boost the sharpening amount without reintroducing artifacts like jaggies/aliasing.

Of course, if I would have more time to spare, I could probably also develop an automatic re-tuning of the deconvolution settings, based on a variable Keys alpha input (something that a modern commercial image processing tool could use). Lack of resources is unfortunately slowing me down ...

Cheers,
Bart

[snibgo]

I have adapted the 1.2.2 script to suit my own working methods, and published resampHM.bat with a number of trials at http://im.snibgo.com/resamphm.htm

My script takes parameters instead of prompting for values. The other major change is that there is only a single convert command. Thus any deconvolution doesn't spend time (and lose precision) converting to sRGB, writing a file, reading the file, and converting to RGB.

My script expects to find identify.exe in directory %IM%, and convert.exe in %IM32f%. For my web page, %IM32f%convert.exe is Q32 HDRI.

The script can auto-select the method from downsampling or upsampling. See the page for details. I don't think the IM utilites can find resized dimensions without also creating the image in memory. But a trivial utility could be written to take a width, height and resize, call ParseMetaGeometry() in geometry.c, and return the new dimensions.

I shouldn't judge the results from a single image, but I gotta say: I love the downsampling with sharpen. It's much better than I get with "-resize -unsharp".

A note on colorspaces and profiles: Resample_by_Percentage_V122.bat writes any embedded profile to a file, then flags the image as sRGB with "-set colorspace sRGB". This will give inaccurate linearization. After saving the profile, it would be better to convert the image to sRGB with "-profile sRGB.icc", perhaps providing a path to that file. (The IM installation directory contains sRGB.icc.) At the end of the convert command, the "-profile" operation will then convert the image back to the saved ICC profile.

My page describes how to adapt my script for non-sRGB colorspaces. As almost all my work is in sRGB, I haven't automated this.

[NicolasRobidoux]

I have adapted the 1.2.2 script to suit my own working methods, and published resampHM.bat with a number of trials at http://im.snibgo.com/resamphm.htm
...

Alan: This is a very nice and informative comparison.
Comment about your "u" option examples: Among deblurred EWA Lanczoses, those that correspond, roughly, to low sharpening (<50) are more artifact free. For example, LanczosSharp corresponds to something like 10.
Anything above 100 is guaranteed unusable: With EWA Lanczos, (de)blur=0.88549061701764 a.k.a. EWA LanczosSharpest 3, is the smallest reasonable value that can be used (based on a heuristic), and this is (should be) what 100 corresponds to. So the range of sharpening values shown in your examples probably should be narrower. 0 to absolutely no more than 50. (A wider range was provided for experimentation and allowing people to push the envelope. It's not necessarily recommended.)
Note: These are preliminary comments. I'll have a closer look later today.

[snibgo]

So the range of sharpening values shown probably should be narrower.

Fair comment, thanks. My work on this isn't over; I'll be using it for downsample-with-sharpening on a variety of images. If I discover anything interesting, I'll publish it. I do very little upsampling.

Meanwhile, I'll keep an eye on what you folks are doing. You know vastly more about filters and lobes and stuff than I do.