A free high quality resampling tool for ImageMagick users

[NicolasRobidoux]

The "wondering" comes from that, with pixel art, I'd like black and white features to be perceptually thickened/thinned out about the same amount. There is just a tiny bit too much of a difference, that I can see, with gamma 3. (On the other hand, I've not calibrated my MacBook's screen, so who knows, really?)
Also, I totally agree that if you don't get this close to Nyquist, it may be better to stick to gamma 3.
Basically, I am wondering if >>you<< can see a difference, leaving aside the amount of haloing for a minute, just focusing on the handling of thin features and sharp boundaries.

[Bart_van_der_Wolf]

Basically, I am wondering if >>you<< can see a difference, leaving aside the amount of haloing for a minute, just focusing on the handling of thin features and sharp boundaries.

Yes, I see it on the extreme checker example, but less so on continuous tone images, but then we're talking about huge upsampling factors on 'impossible' edge contrast. We're also 'exploiting' the white clipping which hides the first lobe halo there, and some of the first dark lobe halo as well. The clipping can in such a case be used to our benefit on bi-tonal images, by cranking up the contrast of the original, and if necessary reduce it again afterwards.

I also see the differences in the Chip-crop image, mostly on the highlight edge which is smoother with a higher gamma.

Cheers,
Bart

[NicolasRobidoux]

The chip test image (that I've used because others have) has been pushed some rather drastic processing, I am fairly sure. The ways the colours mix and vary appears to have little connection to what one would expect from an unmanipulated digital photograph. Maybe I am wrong on this, but something that can only be seen on the "chip" test image I would tend to dismiss.
It's a fun image to enlarge with, but definitely not a litmus test.
(Same with Lena, mandrill, the photographer, etc. Nothing to do with what digital photographs are about now.)

[NicolasRobidoux]

OK: Let's stick to gamma 3.

[Bart_van_der_Wolf]

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.

Understood, and that was what I intended to do; a full upsample (16-b/ch RGB image) only changing the -gamma 'x' to -evaluate '1/x' and back.

Well, the result is in (Q16 version of ImageMagick): with '-evaluate' it takes some 4-5% longer to execute a full upsample process to 800% than with '-gamma', and the image data results are identical (zero difference). I've tried multiple runs and averaged, and small 0.1sec differences were seen but nothing all that significant between runs, and -evaluate was consistently 'slower'.

Of course it's only a sample of one specific 64-bit computer running on Win 7, but based on this I'll stick to '-gamma'.

Cheers,
Bart

[NicolasRobidoux]

Case closed.

[NicolasRobidoux]

If I am not mistaken, the Unix version of the downsampling scheme with maximum (=default) sharpening is basically

convert \( input.jpg -set colorspace sRGB -colorspace RGB \
  -define filter:c=0.1601886205085204 -filter Cubic -distort Resize 512x512 \) \
  \( -clone 0 -gamma 3 -define convolve:scale=100^,100% \
  -morphology Convolve DoG:3,0,0.4981063336734057 -gamma 0.3333333333333333333 \) \
  \( -clone 0 -define convolve:scale=100^,100% \
  -morphology Convolve DoG:3,0,0.4806768770037563 \) \
  -delete 0 \
  \( -clone 1 -colorspace gray -auto-level \) \
  -compose over -composite \
  -set colorspace RGB -colorspace sRGB \
 output.png

P.S. Here is what it gives with the (rather unforgiving) fly http://upload.wikimedia.org/wikipedia/commons/8/85/Calliphora_sp_Portrait.jpg.
P.S. 2 I also quite like the result with half the amount of sharpening (50^,100% instead of 100^,100%). Attached below as well. (Bart: You did well! The "generic" scheme is no match when downsampling.)
P.S. 3 Looked more carefully on a variety of monitors, including a large color balanced one (Eizo), and I think that 67^ instead of 100^is a good, safe but still punchy, value. There is just a hint too much moire at 100. (Of course this test image is a torture chamber.) I also looked at the result of resizing to 25% so that I could align results with the original, to get a sense of colour preservation. Should do that every time, actually.
P.S. 4 The original shows a good amount of sharpening halo. Maybe 100^,100% is just fine when the image being downsampled was not pre-sharpened.

[NicolasRobidoux]

Bart:
I think your script should use the downsample scheme when downsampling, and the generic scheme when upsampling, automatically switching between the two.
This leaves the issue of what is done near the identity in a somewhat undesirable state. But it's reasonable.
Near the identity (say, between 50% and 100%) it could blend the two results in linear light, in such a way that the current generic is all of it at 100% or above, and at 50% it's all the current "downsample".

[Bart_van_der_Wolf]

Bart:
I think your script should use the downsample scheme when downsampling, and the generic scheme when upsampling, automatically switching between the two.
This leaves the issue of what is done near the identity in a somewhat undesirable state. But it's reasonable.
Near the identity (say, between 50% and 100%) it could blend the two results in linear light, in such a way that the current generic is all of it at 100% or above, and at 50% it's all the current "downsample".

Hi Nicolas,

I agree. However, during the stage of searching for optimal approaches and filters, I did want to allow the possibility to use either type of algorithm for both up- and down-sampling, for comparisons (without having to change the script itself).

Now that things seem to stabilize (although I'm thinking of a Keys Cubic variable input if that beats Lanczos), 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.

If we were to restrict the input to percentage inputs, then it would be relatively simple, but I did also want to allow some of the ImageMagick special resizing options, such as fitting to maximum width (or height) to achieve an exact number of pixels (without running the risk of a percentage rounding to 1 pixel more of less than intended). That makes it harder to parse the input and determine if the result will be larger or smaller than the original.

I'm pretty sure it is possible to parse the input and find out what to do, but it could require quite a bit of code (and time to compact and optimize) to do so reliably. As a minimum, it should distinguish between e.g. 800% (obviously upsampling), and 800x800 (could be either upsampling or down-sampling, depending on the  input size), or 800x (for maximum width, could also be either up/down), or x800 (for maximum height, could also be either up/down). Ideally it would also allow to parse the other size limiting resizing options (!, >, <, ^, @) that IM recognizes, and determine which direction to take the resampling.

Again, I agree (and I have been looking into it already), but it may take a lot more time to really figure it out than I can currently invest. I suppose I could throw it over the fence of the IM discourse server and let someone else solve it ..., but not before doing an initial attempt myself (may be a character flaw on my side ).

But feel free to call in the troops for their collective knowledge, which is what I do like about fora. The question to ask would be how to parse the IM resize options to determine whether up- or downsampling is going to occur (ideally expressed as a percentage, only to take further decisions on like with 50-100% identity resizes).

Cheers,
Bart

[NicolasRobidoux]

Then split the script into two:
Upsample (which can be used to downsample if this is what the command states, even though it's tuned for upsampling).
Downsample (which can be used to enlarge...).

Users usually know which one they want.
P.S. I also agree that EWA with Keys cubics gives an awful lot of mileage for the money. As far as linear schemes go, they are the best I know with only one halo. But unless you enlarge more than a little, they hold their own against (deblurred) EWA Lanczos 3, all things considered, which is mind blowing.
I am actually stunned. (There are theoretical reasons why they perform so well: They are almost second order accurate, the tensor Keys cubic being exactly second order accurate at the expense of not being rotationally invariant. But it does not appear to me that this "strength" should be sufficient.)

[kirkt]

I have very little shell script programming experience, but I think I got the downsampling commands to work with the following *nix bash script, I called it "resizer.sh":

#!/bin/bash
#
# set default values for command line arguments
convolveScale=100 # -c scale of CONVOLVE operation
longEdge=512 # -s SIZE of long edge for resample
infile="input.jpg" # -i path to INPUT file
outfile="output.tif"        # -o path to OUTPUT file
       # -h help

while getopts "hc:s:i:o:" VALUE "$@" ; do
 
    echo "GOT FLAG $VALUE"
 
    if [ "$VALUE" = "h" ] ; then
        echo "USAGE: resizer.sh [options] ... -i infile -o outfile"
        echo "-c: convolve scale (default = 100)"
        echo "-s: size of output long edge in pixels (default = 512)"
        exit
    fi
    if [ "$VALUE" = "c" ] ; then
     convolveScale="$OPTARG"
        echo "convolveScale=$OPTARG"
    fi
    if [ "$VALUE" = "s" ] ; then
        longEdge="$OPTARG"
        echo "longEdge=$OPTARG"
    fi
    if [ "$VALUE" = "i" ] ; then
        infile="$OPTARG"
        echo "infile=$OPTARG"
    fi
      if [ "$VALUE" = "o" ] ; then
        outfile="$OPTARG"
        echo "outfile=$OPTARG"
    fi
 done
 
convert \( $infile -set colorspace sRGB -colorspace RGB \
  -define filter:c=0.1601886205085204 -filter Cubic -distort Resize "$longEdgex$longEdge" \) \
  \( -clone 0 -gamma 3 -define convolve:scale="$convolveScale^",100% \
  -morphology Convolve DoG:3,0,0.4981063336734057 -gamma 0.3333333333333333333 \) \
  \( -clone 0 -define convolve:scale=100^,100% \
  -morphology Convolve DoG:3,0,0.4806768770037563 \) \
  -delete 0 \
  \( -clone 1 -colorspace gray -auto-level \) \
  -compose over -composite \
  -set colorspace RGB -colorspace sRGB \
$outfile

The script permits the user to specify the convolve scale (so you can specify, for example, 50^ instead of 100^ and the long edge pixel dimension for the resize operation, as well as the input and output file, all as arguments on the command line.  Type -h for help.

You can comment out the "GOT FLAG $VALUE" and the echo of the flag arguments - this was for debugging.  Works on my Mac (Mavericks) and ImageMagick 6.8.9.  When I open the resulting output file in PS, there is no embedded color profile tag recognized by PS.

Thanks for all of your work on this!

kirk

[Bart_van_der_Wolf]

Thanks for all of your work on this!

Hi Kirk,

Thanks for chipping in, the more the merrier.

I'll have a look later at how that would work out in an interactive Windows environment.

Cheers,
Bart

[NicolasRobidoux]

Now that things seem to stabilize (although I'm thinking of a Keys Cubic variable input if that beats Lanczos)

Opinion: EWA with Keys cubics beat deblurred EWA Lanczoses if you don't want a second halo (for example if you want to post-sharpen). Otherwise, deblurred Jinc-windowed Jinc 3-lobe (EWA Lanczos 3) is the winner, unquestionably so if you are fighting moire (when downsampling) or you are enlarging more than a bit.

[fdisilvestro]

Hi,

I performed some tests using Bart's Script + IM with a converted B&W image and compared the results with PS and LR. I am using version 1.2.1 of Bart's script (I don't know if there is a newer one). One thing I found out is that if the original image is monochrome (all values R=G=B) and has an embedded RGB profile (such as sRGB) then the output file is in an invalid mode (as shown in the screen capture from Bridge in Fig 1) where the color mode is B&W and the color profile is sRGB. It seems that Image Magik detects the image is in B&W and leaves it that way. Photoshop would give a warning and ignore the profile.

This was solved by converting the original image to Gray Gamma 2.2 (you can use your preferred B&W profile) and then downsampling the image with Bart's script.

The downsizings were performed with the following parameters
Original image: JPEG, size 6148 x 3458
Output image size 1200 x 675

PS: Resample: automatic
LR: Resize to 1200 long edge, normal sharpen for screen output
IM+Script: Downsizing optimized, 1200 Long edge, 75% sharpening

The second image contains the center crop from each output file. The order from left to right: IM + Bart's Script; LR; PS.

The output from PS (right) shows some artifacts (rose windows) and is the worse of the three. LR performed a much better job (center) than PS but the image has a darker appearance than the original (similar to PS).

I'm attaching also (third image) a 100% crop of the original image to get the sense of the original details and brigthness in the rose window and bricks.

The output from IM + Bart's script (left) is IMO the better one. What surprised me was not the lack of artifacts (where LR also did a decent job), but how the texture of the bricks looks much better, closer to the original image while the LR and PS version look darker.

I have yet to explore the optimal settings with the script and also trying the deconvolution options, but overall I'm very satisfied with this method, which I would use for most of my images.

Thanks Bart, Nicolas and all who contributed to this tool.

P.D. I have posted the whole image (downsized) in the user critique forum here (CxC welcome)

Regards,

[NicolasRobidoux]

The scripts really are set up assuming sRGB as input and the same as output.
Because ImageMagick is OK at figuring out automatically what to do, it may work in other situations. For best performance, however, the scripts need to be modified when one or both of these assumptions does not hold.
The "core" of the method works from linear RGB and converts out of linear RGB. In addition, the script, as it is, assumes sRGB primaries. Which primaries are used is not important; what is important is that the "input" primaries and "output" primaries match. Additional steps that perform colorspace conversion may be required if this is not the case.
The most immediately useful sections of the ImageMagick documentation are
http://www.imagemagick.org/Usage/color_mods
http://www.imagemagick.org/Usage/formats/#color_profile
Generally, you'll want to convert from your input colorspace to some linear RGB, resample as usual with the core of the script, then convert out from the same linear RGB (same = same primaries) to whatever colorspace you want for the final result (this includes modifying the bit depth, choice of compression etc).

[fdisilvestro]

The scripts really are set up assuming sRGB as input and the same as output.
Because ImageMagick is OK at figuring out automatically what to do, it may work in other situations. For best performance, however, the scripts need to be modified when one or both of these assumptions does not hold.
The "core" of the method works from linear RGB and converts out of linear RGB. In addition, the script, as it is, assumes sRGB primaries. Which primaries are used is not important; what is important is that the "input" primaries and "output" primaries match. Additional steps that perform colorspace conversion may be required if this is not the case.
The most immediately useful sections of the ImageMagick documentation are
http://www.imagemagick.org/Usage/color_mods
http://www.imagemagick.org/Usage/formats/#color_profile
Generally, you'll want to convert from your input colorspace to some linear RGB, resample as usual with the core of the script, then convert out from the same linear RGB (same = same primaries) to whatever colorspace you want for the final result (this includes modifying the bit depth, choice of compression etc).

Thanks for your response. I actually started with an RGB file with the embedded profile sRGB. When I run the script I ended with a file in color mode B&W (which I assume was assigned by Image Magik) and color space sRGB, which was not accepted by Photoshop.

This is the process:

1) Start with a color image in sRGB
2) convert to B&W in Photoshop by Image -> Adjustments -> Black & White
3) Save

Technically, this is still an RGB image with profile sRGB, even if all values are R=G=B

4) Run the script

The output image has:
- Color mode: B&W
- Color space: sRGB

Which is considered as non-valid by Photoshop

Am I doing something wrong? How can I keep the image in Color mode:RGB?

That's why I converted the image to GrayGamma 2.2 in PS before saving. Surprisingly the downsizing worked well.

Regards

[NicolasRobidoux]

Francisco:
You did not do anything wrong. You found a quick and dirty workaround.
I don't have time to assemble and test a "most accurate and efficient" toolchain for your particular situation (no matter how common). Colorspace transformations/image format/compression in ImageMagick are not a trivial thing to put together "just right" (so much so that I usually use other tools when this is a key concern, assembling a hybrid pipeline). Which is why my response was basically RTFM.
So, let's call it a win. And hope that I have more time to RTFM myself some time before 2015.
-----
If I have a little bit of time, I may make a suggestion and hope it hits the nail without testing.
It is possible that this is relevant: http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=21031

[NicolasRobidoux]

Francisco:
(Untested) I believe that the quick but less dirty answer has to do with inserting -type TrueColor just before the final conversion to JPEG.
http://www.imagemagick.org/script/command-line-options.php?#type

[fdisilvestro]

Francisco:
(Untested) I believe that the quick but less dirty answer has to do with inserting -type TrueColor just before the final conversion to JPEG.
http://www.imagemagick.org/script/command-line-options.php?#type

Thanks Nicolas, that did the trick!  Now the resulting image shows Color Mode: RGB

Regards,

[NicolasRobidoux]

Frank (a.k.a. Francisco):
I agree that with your example Bart's "sharpened downsampling scheme" is clearly superior to both LR and PS.