Correct resize

[NicolasRobidoux]

I find it really interesting to follow your process.

[dimkalinux]

After testing on different types of images: photo, screen-shots with text and others - i`m found that this parameters work best for me

Code: Select all

/usr/bin/convert ./322ca0b1.png -depth 16 -colorspace sRGB -auto-orient -alpha on -virtual-pixel transparent +distort Affine '0,0 0,0 %w,0 740,0 0,%h 0,650' -crop 740x650+0+0 +repage -colorspace RGB -quality 95 -sampling-factor 1x1 -unsharp 0x0.75+0.75+0.008 -strip -background white -depth 8

1) it`s slow, but CPU is cheap.
2) USM parameters 0x0.75+0.75+0.008 is good for images > 500*500. For small images need decrease parameters - 0.5-0.65
3) differents with resize+Mitchell+USM very very small and resize 10-15% faster.

[NicolasRobidoux]

It looks like you found a good combo.

If I may suggest one last thing, it would be to try the blur option of resize/distort instead of USM. I am making this suggestion because it appears that you value sharpness a lot.

For example, inserting

Code: Select all

-define filter:blur=.9

just before +distort, and then skipping the USM step, with "pure" distort (=Robidoux) or Lanczos distort.

.9 is just a rough guess. The useable range with the above two filters is about .8-1.

Smaller values will also make things run faster.

See viewtopic.php?f=1&t=17447 for some examples (in a slightly different context).

[dimkalinux]

I test this.

-filter blur is worse for diagonal lines - when overall sharpnes is the same as USM 0.75 - on blur diagonal lines is very bad. Specialy when lines is contrast solid thin line.

[dimkalinux]

Another "funny" things with distort+USM.
If your image have 1px contrast borders - after USM it can dissapear.

For avoid this u need well tune USM mask for different image size.

Like this

Code: Select all

// MIN SHARPING
$sharpen_cmd_part = ' -unsharp 0x0.5+0.4+0.005 ';

//
if ($dst_size > ((250 * 250) + 1)) {
	$sharpen_cmd_part = ' -unsharp 0x0.65+0.45+0.0065 ';
}

// INCREASE SHARPING FOR BIG IMAGES
if ($dst_size > ((500 * 500) + 1)) {
	$sharpen_cmd_part = ' -unsharp 0x0.8+0.75+0.008 ';
}

[NicolasRobidoux]

Thank you very much for sharing your careful comparison.

When Anthony chose the Robidoux filter over 3-lobe Jinc-windowed Jinc as default filter for distort (Elliptical Weighted Averaging), I disagreed. (I, of course, was also pleased.)

What you've done suggests that, at least if one uses USM in the usual way as a final step, a careful user may actually side with Anthony (in some common resize situations).

Looking at some of the results involving man-made objects, CG and text, I am myself not so sure that Jinc-windowed Jinc EWA "always" beats Robidoux EWA.

[dimkalinux]

Make test with HDRI version - it produce many tiny color errors in result.
Its normal for HDRI or report bug?

HDRI - http://pic.lluga.net/s/sifaS
Normal Q16 - http://pic.lluga.net/s/aXHFH

[magick]

HDRI pixels can go negative or exceed the pixel range, generally 0-65535. You probably need to add -clamp in your workflow to restrict the pixel values to 0-65535.

[anthony]

I have been listening to the conversation with great interest, and plan to prepare some (small) resize examples in IM examples.

I have not responded until now as I was at the Linux Conference here in Brisbane, Australia. yes the conference survived the flood, a major kudo's to the organizers who had to re-plan the venues and arrangements 10 days before it started!

u need well tune USM mask for different image size.

I think it is not image size that you should be testing, but the scaling factor of the resize.

I suppose the 1 pixel borders you talk about is dependant on if the border should be visible in the final image. However the border is thicker in larger higher resolution images, so if it should appear it will appear. however I suppose with an image like the fly, having the border 'disappear' in places can produce a unusual and definitely unwanted moire effect with borders.

Can you give a demonstration of the effect you are trying to avoid, and the command you use?

Such a demonstration would probably be more important as an example than the more normal, how to do it.

[anthony]

Q16 Resize vs Distorts
...
Is exists normal easy way to compute W and H for distorts cmdline?

The final W and H for the distort was taken from resize so as to produce a equivalent result.
Resize already calculated the size, so I just used it.

Resize calculates it so that the image fits inside the box specified (so typically only one dimension will match the user input, if aspect ratio is to be preserved). It then works out the scale, transfers that to the other dimension and rounds it off to an integer. Remember resize only generates an integer sized result.

Distort can generate a more exact sub-pixel sized result. It also normally handles a correct border 'fadeout' which makes the result overlay better into larger 'layered' images. As such you can perfectly preserve aspect ratios without the resize integer or 'quantum' effects. That is also why some final cropping and alpha handling is needed to make the result more in line with resize's 'completely ignore pixels outside the image proper'.

It is quite posible that a -resize-distort or -resize-ewa option can be added. The method has been worked out, though it will ONLY work for opaque images. However it is possible for a second distort to be applied to rectangular 'mask' image, which is then used to recover the original images alpha channel in the distorted result. But I have not tried to do this.

[anthony]

Resize+Mitchell visually close identical to Distort.

Micthel (resize default) is actually almost a perfect match for the Robidoux (distort default) as a filter function. In many ways you can use them on either.

The main difference was the Mitchel was a 'rough guess' based on a survery of results by Image processing experts. On of its features is that a no-op resize (IM would short cirtuit in that case though) it produces absolutely no change to the resulting image (Sinc also has that properity)
http://www.imagemagick.org/Usage/resize/#mitchell

It is basically imposible to create a good filter that produce absolutly no color changes in a special no-op distort case. But it was by pure luck that it was found that Mitchel produced very minimal color distortion for the 'no-op distort' case. Nicholas Robidoux then under took the mathematics needed to produce the minimal color distortion result for a special no-op distort of a edge, and Robidoux filter was the result.

So while Mitchel is a guess, (a VERY good guess) Rodidoux is a mathematically tweeked for no-op distort case. Either can be used for distort or for resize, but are also defaults, so you should stick with these defaults for a cubic filter selection.

Gaussian and Gaussian-Like filters (no negative effects) and a switched Sinc/Jinc (resize/distort) can also be used. A 'sharpened' Gaussian does work well, and you can apply a gaussian and unsharp to produce good resizes too. See this and later sections...
http://www.imagemagick.org/Usage/resize/#filter_blur

[dimkalinux]

HDRI pixels can go negative or exceed the pixel range, generally 0-65535. You probably need to add -clamp in your workflow to restrict the pixel values to 0-65535.

I think that in case when i save in non-float-able format like png/jpg truncate pixels range aka clamp make automatically.
Ok, i try retest with -clamp.

[dimkalinux]

Can you give a demonstration of the effect you are trying to avoid, and the command you use?
uch a demonstration would probably be more important as an example than the more normal, how to do it.

Example better view on white background.

Original http://pic.lluga.net/x/1/248770/347e2821.png

Left border much thinner.

Code: Select all

/bin/nice --adjustment=15 /usr/local/bin/convert.hdri '/var/upload/pic2/1/248770/347e2821.png' -depth 16 -colorspace sRGB  -auto-orient  -alpha on -virtual-pixel transparent +distort Affine "0,0 0,0   %w,0 364,0   0,%h 0,350" -crop 364x350+0+0 +repage -colorspace RGB -quality 95  -sampling-factor 1x1  -unsharp 0x0.65+0.45+0.0065  -background white  -clamp -depth 8 png:'/tmp/piclgua_ic9M0U1J' 2>&1

Left border normal.

Code: Select all

/bin/nice --adjustment=15 /usr/local/bin/convert.hdri '/var/upload/pic2/1/765d87/347e2821.png' -depth 16 -gamma 0.4545454545 -filter Mitchell  -auto-orient  -resize 364x350\> -gamma 2.2 -quality 95  -sampling-factor 1x1  -unsharp 0x0.65+0.45+0.0065  -background white  -clamp -depth 8 png:'/tmp/piclgua_icrwL2LK' 2>&1

Default i use 0x0.65+0.65+0.0065 USM and resize good with this values, but for distort i need use 0x0.65+0.45+0.0065 for avoid border problems.

[dimkalinux]

u need well tune USM mask for different image size.

I think it is not image size that you should be testing, but the scaling factor of the resize.

Not shure - USM applied after resize for already scaled images.
Why i need make differences for original size?

For example:

1 case: scale 502x502 image to 500x500 - scale factor is very small and i need use small USM values.
2 case scale 2000x2000 image to 500x500 - scale factor is large and i need use larger USM.
i think in first case image will be blured, but i will test this cases.

[NicolasRobidoux]

One of its (Mitchel) features is that a no-op resize (IM would short cirtuit in that case though) it produces absolutely no change to the resulting image (Sinc also has that properity)

Mitchel (without short-circuit) does change the image under no-op since the corresponding filter function is not zero at all nonzero integer positions.The BC splines which don't change the image under no-op are the cardinal ones ("cardinal" means "0 at all all nonzero integer positions, and 1 at zero") which are on the horizontal axis of the plot shown at http://www.imagemagick.org/Usage/resize/#mitchell (Hermite and Catmull-Rom being two of them).

Consequently, even with a very mild resize (502x502 to 500x500), USM as a final step is warranted. Actually, if resize did not short-circuit to no-op when resizing to the exact same size, it would make sense to use USM with Mitchell even when "resizing" 500x500 to 500x500.

distort, that I know, never short-circuits (and it almost certainly should not if it is to be used with animation and warping).