Legacy ImageMagick Discussions Archive

Hi.

Im use magick for pic resize on image hosting.
i prefer hight quality and that why i use gamma aware resizing with this cmdline, for example

Code: Select all

convert -depth 16 -gamma 0.454545 -filter ... -resize 500x500 -gamma 2.2 -depth 8

All works find, but i know that method with gamma isnt 100% perfect. i read bug report (viewtopic.php?f=3&t=17150) on this forum for properly working magick with -colorspace (in good topic about lanczos errors with gamma aware scaling viewtopic.php?f=2&t=17136).

Now i used this cmdline

Code: Select all

convert -depth 16 -colorspace srgb -filter ... -resize 500x500 -colorspace rgb -depth 8

This i have 2 question
1) Is in magic 6.6.7 version -colorspace is corrected (fixed bugs described in viewtopic.php?f=3&t=17150)?

2) Is method with -colorspace is good way to make gamma aware resizing?

Visible i dont see any differents with this 2 method on image. Both produce good quality, but compare show differents.

Version: ImageMagick 6.6.7-0 2011-01-10 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: OpenMP

Would you care to write up a short section for IM Examples, Resize?

Note depth is only used to control many output image file formats, (and just a few input file format). Basically it is just stored with the image meta-data, meaning input and output depth is generally preserved. It has no real bearing on the internal handling of the image.

The compile time Quality level is what is important for this. Q16 is generally the default, but you can use Q32 or Q64 or even HDRI to get higher quality from the resize 'convolution'.

Note that Resize is actually a special '2-pass orthogonally limited' distortion. An alternative to resize is to use Distort. A example of using Distort to do equivalent image resize is in IM Examples... See the last example in this example section...
http://www.imagemagick.org/Usage/resize/#distort

Note the difference along the sharp color change along a diagonal edge.

That is not to say it is better. Just a different method.

dimkalinux wrote:Visible i dont see any differents with this 2 method on image. Both produce good quality, but compare show differents.

The question is more likely... How much difference?

-gamma and -colorspace are two different functions. I am not even sure they are the same function, as I don't know exactly what SRGB represents. However if they are the same function, then presumably the difference would be only a one or two, 8 bit color value units (especially near 16 to 8 bit boundaries.

Code: Select all

time /usr/bin/convert ./28a42084.jpg -depth 16 -colorspace sRGB -filter Mitchell -auto-orient -resize 400x400 -colorspace RGB -quality 95 -sampling-factor 1x1  -unsharp 0x0.77+0.77+0.008  -strip -background white   jpeg:./t_colorspace.jpg

real	0m0.739s
user	0m1.188s
sys	0m0.074s

Code: Select all

time /usr/bin/convert ./28a42084.jpg -depth 16 -gamma 0.45454545 -filter Mitchell -auto-orient -resize 400x400 -gamma 2.2 -quality 95 -sampling-factor 1x1  -unsharp 0x0.77+0.77+0.008  -strip -background white   jpeg:./t_gamma.jpg

real	0m0.648s
user	0m1.093s
sys	0m0.025s

Code: Select all

time /usr/bin/convert ./28a42084.jpg -filter Mitchell -auto-orient -resize 400x400 -quality 95 -sampling-factor 1x1  -unsharp 0x0.77+0.77+0.008  -strip -background white   jpeg:./t_default.jpg

real	0m0.237s
user	0m0.333s
sys	0m0.026s

original - http://pic.lg.ua/test/original.jpg

most visible differences in the eyes of this fly - on default method is much darker and dont have silver.

Q32 result
colorspace method - black image, time 1.2s - too slow - maybe is bug?
black image on Q32 with any depth 16/24/32 with this cmdline

Code: Select all

time /usr/bin/convert ./28a42084.jpg -depth 16 -colorspace sRGB -filter Mitchell -auto-orient -resize 400x400 -colorspace RGB -quality 95 -sampling-factor 1x1  -unsharp 0x0.77+0.77+0.008  -strip -background white   jpeg:./t_colorspace_24.jpg

gamma method - no visible differences with Q16, time 1s - too slow

default method - no visible differences with Q16, time .8s - too slow

Q16 Resize vs Distorts

resize

Code: Select all

time /usr/bin/convert ./28a42084.jpg -depth 16 -gamma 0.45454545 -filter Mitchell -auto-orient -resize 400x400 -gamma 2.2 -quality 95 -sampling-factor 1x1  -unsharp 0x0.77+0.77+0.008  -strip -background white   jpeg:./t_gamma_r.jpg

real	0m0.624s
user	0m1.085s
sys	0m0.031s

distorts

Code: Select all

time /usr/bin/convert ./28a42084.jpg -depth 16 -gamma 0.45454545 -filter Mitchell -auto-orient -alpha on -virtual-pixel transparent +distort Affine '0,0 0,0   %w,0 268,0   0,%h 0,400' -alpha off -crop 268x400+0+0 +repage -gamma 2.2 -quality 95 -sampling-factor 1x1  -unsharp 0x0.77+0.77+0.008  -strip -background white   jpeg:./t_gamma_d.jpg

real	0m1.263s
user	0m2.287s
sys	0m0.032s

Visualy distorts looking better but slowly in 2x.

Is exists normal easy way to compute W and H for distorts cmdline?

Suggestions when using distort:

1) Don't use Mitchell. Let distort pick the default. It should give a slightly better result.

2) You may get a better quality result with -filter Lanczos, which will use 3-lobe Jinc-windowed Jinc if called from distort, or with -filter LanczosSharp, which will run a nudge faster. Both will be slower than Mitchell and the default distort filter.

3) If speed matters, I would pick a filter which gives a result you like WITHOUT unsharp masking. Think of filter + unsharp mask as one composite filter. If you can get most of the sharpening you want from the filter, you can skip the unsharp masking step. My guess is that skipping the unsharp step will make up for the use of distort instead of resize. You can also "sharpen" filter with the -blur option, but this is not something to be used blindly.

If quality is the only thing that matters, I would first find a filter which pleases you without unsharp masking; then, and only then, I would fine tune with unsharp mask. Note that Mitchell is a relatively "soft" filter. With resize, you may get results that you find more pleasing without unsharp mask with Catmull-Rom (fast) or Lanczos (slower). The price to be paid is haloing, but you are already paying this price by unsharp masking.

I many times tested Lanczos filter - its good (not perfectly) sharpen, but on images like Fly (u can see it on my previous posts) it make strong halo or muar effect in fly eyes. On my opinion Mitchell + small USM (< 1) give better or equal result without or less halo/muar effect. And seems to be Lanczos have more artifacts in gamma aware resizing mode - (depth 16 -gamma 0.4545 -resize -gamma 2.2 -depth

I`m will be test distorts.

What differences with Mitchell and default distorts filter - its Robidoux filter, right?
Is Robidoux filter good for resize as Mitchell or it tunned special for pure distort operation (not resize)?

dimkalinux wrote: ...
What differences with Mitchell and default distorts filter - its Robidoux filter, right?
Is Robidoux filter good for resize as Mitchell or it tunned special for pure distort operation (not resize)?

In IM, there are two different "general ways" that you can resize:

One is to use a tool which can only resize (-resize).

The other is to use a tool which can pretty much perform any resampling task, including, of course, resizing (-distort). Right now, unfortunately, there is no "simple" interface to -distort when you want to resize (like there is for -resize). You have to specify a lot of the reference point/affine transformation/cropping etc yourself.

Both -resize and -distort can use (in principle) any filter function (Mitchell, the default for -resize, Robidoux, the default for -distort, and many many others, can be used with -resize and -distort).

However, because filters are used very differently by the underlying method (standard orthogonal, two pass, tensor filtering for -resize; Elliptical Weighted Averaging (EWA) for -distort) the results obtained with a given filter are extremely different for -resize and -distort.

Mitchell, for example, works well when used with both -resize and -distort. But Sinc-windowed Sinc (a.k.a. Lanczos), which works well for -resize, does not for -distort. So, it is automatically substituted for a similar filter which does work well with -distort, namely Jinc-windowed Jinc, when -filter Lanczos is used with -distort.

Robidoux (cough! cough!) is basically a Mitchell filter tweaked so that it works a little better with EWA and consequently, with -distort when the image is barely enlarged, reduced or warped.

Technical note: Tensor filtering (the method used by -resize) can actually be used to do warping, but this is not, to my knowledge, implemented in IM. Likewise, EWA could be implemented so that all it can do is resize, but in IM it is used for any "non-trivial" resampling. This being said, there are computation shortcuts which can be taken with tensor methods which allow them to run faster (and have simpler code) than equivalent non-tensor methods. I just happen to like the results obtained with non-tensor methods a lot, even when the transformation is a tensor method's best friend, namely pure resizing.

IMHO, -filter Lanczos used with -distort has less haloing and moire than -filter Lanczos used with -resize.

Give it a try.

(Nice test picture, BTW.)

I make a few tests - results here http://pic.lg.ua/test/resize_vs_distort/

1) Distorts with Lanczos work bad on diagonal lines (much better in IM 6.6.7).
2) Resize+Mitchell visually close identical to Distort.
3) Unsharpen (USM) after resizing work good and make image much better.
4) Gamma aware resizing is good idea and work good in Q16 with -colorspace mode.
5) Gamma aware resizing with -depth tricks can produces colors artifacts.

P.S. Seems to be need retest Distort with latest version of IM with High Quality EWA algo.
Retest.

Distort + USM give best quality than other methods - but slowly ~30-50%.

Retest with 6.6.7 - PNG on some operation too slow, lanczos distort fixed but slow, Distort+USM is better.

Seems to be distort bad working with shadows around images border on png.

With this cmdline

Code: Select all

/usr/bin/convert '/var/upload/pic2/1/d0e857/pv_33e63afc.png' -depth 16 -colorspace sRGB   -auto-orient  -alpha on -virtual-pixel transparent +distort Affine "0,0 0,0   %w,0 70,0   0,%h 0,60" -alpha off -crop 70x60+0+0 +repage -colorspace RGB  -quality 95  -sampling-factor 1x1  -unsharp 0x0.65+0.65+0.008  -strip  -depth 8  png:'/tmp/piclgua_icRzdS3Z'

I got black borders instead a shadow

Resize method

Original http://pic.lg.ua/x/1/4ad2ca/33e63afc.png

Also found erros in resize animated gifs.

1) Just in case, have a look at viewtopic.php?f=2&t=17410

2) For all three image processing systems I am reasonably familiar with (IM, VIPS and GEGL), png is a time sink (and an erratic time sink at that: you change the task a little and the time jumps). It's not IM specific that png conversion is slow (although it is being worked on by Glenn if I understand).

3) So, I was wrong: unsharp masking is fast compared to the other operations.

Black borders instead a shadow in previos post is reason use '-alpha off' in cmd.
With -alpha on semi-transparent bordes looks perfect.

Now try deal with -distort animated gif

Yes, some thing - "-alpha on" all fixed.

Distort with lanczos a little better than pure distort, but all both produse a not-sharpen images and than i need steel use Distort+USM. More with pure distort.

Warning: What works best with sharply shot human made objects or CG or text is not likely to work best with "natural" (e.g. bugs, people, old buildings) images.

Legacy ImageMagick Discussions Archive

Correct resize

Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize

Re: Correct resize