A free high quality resampling tool for ImageMagick users

[NicolasRobidoux]

Bart:
(Possibly mistaken) opinion:
For incoming images that are Adobe RGB it is good enough to "import" with the gamma trick and export back with the gamma trick, attaching whatever profiles things came with.
For incoming images that are sRGB, good enough to use -set colorspace sRGB -colorspace RGB ... -colorspace sRGB.
Profiles matter more when you create Adobe RGB or sRGB from a larger color space than once the damage is done.
I care more about smoothness of the transformations, and I think the above two ways are "smoother".
I'd love to find out if I'm wrong.

[NicolasRobidoux]

If I was to do a full job, I'd actually let nip2 do the color management, having it call its own private copy of ImageMagick. This works on all platforms. nip2, which can be called in batch mode even when the workspace has been created interactively, has a really powerful, accurate and clear handling of colorspace management. Originally designed by museum image processing experts. They care. It chews up monster images without breaking a sweat.
P.S. I'm not saying that ImageMagick can't be used to produce a fully color managed tool. I just happen to know nip2 better in this context.
P.S. For Adobe RGB and sRGB, I think the above ImageMagick tricks are enough unless possibly if one changes the bit depth of the output compared to the input. Probably fine too.

[NicolasRobidoux]

http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=25629&start=15#p113972
P.S. It's looking more and more like Q32 or HDRI may be required.

[Bart_van_der_Wolf]

http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=25629&start=15#p113972
P.S. It's looking more and more like Q32 or HDRI may be required.

I notice that OP used:

convert infile.jpg -colorspace RGB

instead of

convert infile.jpg -set colorspace sRGB -colorspace RGB

Maybe that has something to do with his results?

Cheers,
Bart

[NicolasRobidoux]

TTBOMK JPEGs are assumed to be sRGB in ImageMagick. Not pngs.

[NicolasRobidoux]

What may make a difference is -depth 16 from the get go?

[Bart_van_der_Wolf]

TTBOMK JPEGs are assumed to be sRGB in ImageMagick. Not pngs.

Assumptions are dangerous, it's better to define (-set ). ImageMagick has changed behavior a few versions ago which e.g. also influences how Grayscale images are interpreted (as linear gamma by default), if I'm not mistaken, and IM tries to simplify files to their lowest number of channels if RGB gray. Dangerous stuff, easy to lose track, which I also may have.

Changing to at least 16-bit/ch is mandatory for any attempt to survive serious gamma changes. Both of these, '-set colorspace sRGB' and forcing to 16-bit/channel with '-depth 16', is what we do in our resampling script at hand. In addition there is an attempt to avoid halos (and a risk of clipping) through blending. As I have demonstrated with the slightly (~0.39) blurred input, it also makes a difference how well behaved instead of synthetic the input is.

Cheers,
Bart

[NicolasRobidoux]

Bart:
Have you had a chance to check if -evaluate Pow .3333333333333333 gives a similar result to -gamma 3 and vice versa?
P.S. My sincere apologies for not having the time to look in the source code and performing experiments myself.

[Bart_van_der_Wolf]

Bart:
Have you had a chance to check if -evaluate Pow .3333333333333333 gives a similar result to -gamma 3 and vice versa?
P.S. My sincere apologies for not having the time to look in the source code and performing experiments myself.

Not checked yet, I have been spending some time checking the differences between the current convolution with a DoG, and an

-unsharp 0x%blurSigma%+%unsharpAmount%+0

operation, and they produce 'almost'(!) the same results. The simpler code may be tempting, and maybe faster, but it also robs us of another control possibility (not simply deblurring, but targeting certain (edge) spatial frequencies).

Have also been investigating Profile conversions instead of colorspace assignments/conversions, to bypass the sRGB linear part of the gamma curve. Also a direct gamma conversion without respecting colorspace or profile would be possible, but may have unintended effects. Lots of things to verify..., but I'll eventually have a look at Pow versus Gamma.

Cheers,
Bart

[NicolasRobidoux]

There is a new ImageMagick 7 beta for Windows: http://www.imagemagick.org/download/beta/ImageMagick-7.0.0-0~beta20140731-windows.zip.
IM7 is HDRI by default (which does not mean that it does not use LUTs internally; for some operations it's probably no more precise).

[Bart_van_der_Wolf]

There is a new ImageMagick 7 beta for Windows: http://www.imagemagick.org/download/beta/ImageMagick-7.0.0-0~beta20140731-windows.zip.
IM7 is HDRI by default (which does not mean that it does not use LUTs internally; for some operations it's probably no more precise).

Nicolas:
Thanks for the link. However, I don't think we should fall into the trap of getting sloppy with procedures "because floating point will be our safety net to prevent clipping while processing". Processing should be so robust that e.g. clipping errors are caught or prevented, also in a 16-b/ch processing. Only in rare, e.g. integer round-off situations (think about FFT divide by near zero deconvolution), should 32-bit/ch or floating point allow the required additional precision. Again, not as a safety net for sloppy procedures, but for when no other solution offers the absolutely required precision.

We should also note that it's still a Beta release, so there may be more bugs than in a stable release. So some options may change behavior, or parameters may have different meaning between releases, and there may be bugs. I hate to waste time searching for my own errors when there are none.

Having said that, I'm looking out for the stable IM7 releases, even though it might mean having to rewrite some of the scripted commands. For the moment I'll stick to optimizing the script for the stable IM6 environment, and have an occasional look at IM7 to see if we can prepare for that by maybe doing things a little different. I'm not going to maintain 2 versions, so when the switch is made, that's it. Backwards compatibility may play some role but will not drain my resources. I've done enough programming to know that that is to be avoided.

Cheers,
Bart

[NicolasRobidoux]

IM6 will be maintained and most likely developed "forever".
I suspect that the IM7 effort may have diminished given that Anthony Thyssen is not as involved in ImageMagick as he once was.
You should not worry about being "trapped" in IM6.
-----
Let's hope that -gamma or Pow, with intermediate storage in 16 bit, is accurate enough. Let's face it, ICC profiles are not that particularly precise themselves, esp. the older (pre sRGB v2, for example) ones.

[NicolasRobidoux]

Not checked yet, I have been spending some time checking the differences between the current convolution with a DoG, and an

-unsharp 0x%blurSigma%+%unsharpAmount%+0

operation, and they produce 'almost'(!) the same results. The simpler code may be tempting, and maybe faster, but it also robs us of another control possibility (not simply deblurring, but targeting certain (edge) spatial frequencies).

Good idea to check whether the complication brings benefit. Thank you.

Have also been investigating Profile conversions instead of colorspace assignments/conversions, to bypass the sRGB linear part of the gamma curve.

As far as sRGB goes, I trust the IM conversions performed by -colorspace sRGB and -colorspace RGB (with proper -set colorspace).

Also a direct gamma conversion without respecting colorspace or profile would be possible, but may have unintended effects. Lots of things to verify..., but I'll eventually have a look at Pow versus Gamma.

I am really really distrustful of conversions to gamma spaces without going through a linear light space (unless we already are in a gamma space, like Adobe RGB, or the profile has a mode that allows direct conversion to a gamma space, which I doubt). I would not even bother trying.

[NicolasRobidoux]

Bart:
This is with really quick testing, but the "generic" scheme that corresponds to sharpening at 50% (with a deblur that falls halfway between EWA LanczosSharpest 3 and Lanczos 3, which happens to be about halfway between LanczosRadius 3 and LanczosSharp 3) looks quite good to me when used to enlarge.
Haloing is mild, the result is fairly sharp, it's not too aliased, and it actually sort of looks like an image taken slightly out of focus, which is pretty good for an enlargement. (There definitely are things to argue here...)
The usual artifacts are all there, but none of them jumps at you. Good in a not bad way, in other words.
Let's see if this opinion holds up with further testing etc.
-----
P.S. I've also tried the scheme that corresponds to maximal sharpening/deblur, a.k.a. LanczosSharpest 3, and given how sharp it is, it produces quite good looking results. It corresponds to

convert \( input.png -depth 16 -set colorspace sRGB -colorspace RGB \) \
 \( -clone 0 -gamma 3 -define filter:lobes=4 -define filter:blur=0.88549061701764 -filter Lanczos -distort Resize 6400% -gamma 0.3333333333333333 \) \
 \( -clone 0 -define filter:lobes=4 -define filter:blur=0.88549061701764 -filter Lanczos -distort Resize 6400% \) \
    -delete 0 \
 \( -clone 1 -colorspace gray -auto-level \) \
 -compose over -composite \
 -set colorspace RGB -colorspace sRGB \
output.png

(I've moved the -delete to, hopefully, free memory halfway through the pipeline. The syntax being that of a stack, what used to be -clone 2 is now -clone 1.)
Here are the results of a contrived test, which nonetheless I find quite telling, a 64x enlargement. The original is at the bottom (8x8 image).
P.S. I made a mistake and what is shown above is almost EWA LanczosSharpest 4 instead of EWA LanczosSharpest 3. See the following posts.

[Bart_van_der_Wolf]

Bart:
This is with really quick testing, but the "generic" scheme that corresponds to sharpening at 50% (with a deblur that falls halfway between EWA LanczosSharpest 3 and Lanczos 3, which happens to be about halfway between LanczosRadius 3 and LanczosSharp 3) looks quite good to me when used to enlarge.

Yes, in general this looks like a good compromise. If you want, I can change the default sharpening from 0 to 50, just let me know if the setting keeps looking pleasing on different images. Others are invited to judge their images and share their preferred settings for upsampling, but also if there are things they do not like about their upsampled results.
 

Haloing is mild, the result is fairly sharp, it's not too aliased, and it actually sort of looks like an image taken slightly out of focus, which is pretty good for an enlargement. (There definitely are things to argue here...)
The usual artifacts are all there, but none of them jumps at you. Good in a not bad way, in other words.
Let's see if this opinion holds up with further testing etc.

Yes, some more testing with different image content will need to be done.

P.S. I've also tried the scheme that corresponds to maximal sharpening/deblur, a.k.a. LanczosSharpest 3, and given how sharp it is, it produces quite good looking results.

Maybe we can consider where both alternatives excel, and device a gradual transition between the two, or simply offer a choice between two methods.

(I've moved the -delete to, hopefully, free memory halfway through the pipeline. The syntax being that of a stack, what used to be -clone 2 is now -clone 1.)

It won't hurt and it may help, it's up to the memory management of IM and the OS I guess, whether it immediately frees memory. As far as the image content is concerned it produces identical results, so I'll implement it for the next update.

Here are the results of a contrived test, which nonetheless I find quite telling, a 64x enlargement. The original is at the bottom (8x8 image).

Yes, it's not bad, but what we cannot see is how much the first halo ring over/undershoots the goal value (which is already at the clipping level to start with). The first lobe of a 4 lobe support has a higher amplitude, and the remainder has lower amplitudes. I assume that a reduced contrast checker will be more revealing for continuous tone images, but for line drawings this does give a useful impression.

Cheers,
Bart

[NicolasRobidoux]

Bart:
Given that the two schemes I just tested correspond, respectively, to deblur=50 in the case of the "halfway scheme" and 100 for LanczosSharpest 3, and that I know that deblur=0, namely plain EWA Lanczos, works well with JPEG compression, offering the range [0,100] with default at 50 would seem like a pretty good thing.
Cheers
P.S. In case it was not clear: All the methods I've discussed very recently are 3-lobe EWA Jinc-windowed Jinc. No 4-lobe here. I'll be really clear if I bring back EWA LanczosSharpest 4.
As you may guess, there is a LanczosSharp at every number of lobes, a LanczosSharpest at every number of lobes, etc. But they are not implemented like this in ImageMagick: The deblur is fixed, instead of depending on the number of lobes like it does with EWA LanczosRadius. Programming expediency.
P.S. Bart: My apologies. Indeed I tested the four lobe LanczosSharpest. Not quite, actually, since the deblur is the one for 3 lobes. It's right in the code.
Here is the result of

convert \( input.png -depth 16 -set colorspace sRGB -colorspace RGB \) \
 \( -clone 0 -gamma 3 -define filter:blur=0.88549061701764 -filter Lanczos -distort Resize 6400% -gamma 0.3333333333333333 \) \
 \( -clone 0 -define filter:blur=0.88549061701764 -filter Lanczos -distort Resize 6400% \) \
    -delete 0 \
 \( -clone 1 -colorspace gray -auto-level \) \
 -compose over -composite \
 -set colorspace RGB -colorspace sRGB \
output.png

which is what I meant to do and which, this time, is achievable with your script.

[NicolasRobidoux]

This is "the other end", namely sharpening=0 in the "generic" scheme:

convert \( input.png -depth 16 -set colorspace sRGB -colorspace RGB \) \
 \( -clone 0 -gamma 3 -filter Lanczos -distort Resize 6400% -gamma 0.3333333333333333 \) \
 \( -clone 0 -filter Lanczos -distort Resize 6400% \) \
 -delete 0 \
 \( -clone 1 -colorspace gray -auto-level \) \
 -compose over -composite \
 -set colorspace RGB -colorspace sRGB \
output.png

[NicolasRobidoux]

Bart:
I am starting to suspect that going through gamma 2 instead of gamma 3 may strike a better balance between "faithfulness" and halo reduction.

[Bart_van_der_Wolf]

Bart:
I am starting to suspect that going through gamma 2 instead of gamma 3 may strike a better balance between "faithfulness" and halo reduction.

Hi Nicolas,

Perhaps, although the dark side undershoots will become more prominent. We could also go for an intermediate Gamma 2.5/0.4 (slightly brighter than the presumed original gamma 2.2 precompensation), and see how pleasing the results from that are. I suppose it also depends on image content. But maybe you have a specific example that makes you wonder if 3 is too much.

Line-art (which lends itself better for vectorization than raster interpolation) would require different settings (or maybe an ever so slight preblur) than continuous tone images. And the latter would require tuning to the degree of sharpening that the image already received. As my earlier example of the 128x upsampled ramp showed, a very small radius Gaussian preblur (maybe even with an reduced amount) totally changes the over/undershoot behavior of a given method/filter.

I'll try to squeeze in an evaluation (precision and timing) of  '-evaluate Pow' versus '-gamma', later today. I think I've found a useful command execution timer batch file to do the execution time part of that evaluation.

Cheers,
Bart

[NicolasRobidoux]

Quick suggestion: Don't time subcomponents in isolation. So much time is spent in memory management in typical systems that you should time the entire command, including read and save to file. If you can't see a difference, you have your answer. (Of course, you need to try to have the disk be in a similar state, or take the minimum time over a reasonable number of runs (5 is probably enough), which is less of a hassle than trying to prevent other processes to access the disk or setting the disk to a fixed state.)
If I was timing things in Unix, I'd just put time before the command and call it a day.
P.S. That was a bit terse. What I really mean is this: If an instruction, in isolation, runs faster, but its insertion in a toolchain somehow interferes with the smooth flow of data through the pipeline, the fact that it runs faster is irrelevant. I/O and memory management dominate computation time, almost always. Timing individual links is less informative than the whole.