Default resize filters

[Drarakel]

I know that for downsizing images with "-resize", IM usually uses Lanczos (not Mitchell). Except when there's an alpha layer or when it's a 'colormapped' image - right? According to the guides here:
http://www.imagemagick.org/Usage/resize/
http://www.imagemagick.org/script/comma ... php#filter
Are there any other exceptions or rules for that (especially with 'colormapped' images)? What exactly does IM check in order to decide which default filter to use?

An example:

Code: Select all

convert logo: -resize x200 test1.png

Here, Mitchell is used. OK.
But now:

Code: Select all

convert logo: logo.png
convert logo.png -resize x200 test2.png

Here, apparently Lanczos is used. Well, IM identifies no 'colormap' (as the default PNG output is the normal RGB format, not a palette format) - but it's still the same image, with type "palette" and less than 256 colors. Shouldn't the same resizing filter be used as in the case above?

[anthony]

If you add the expert option -set option:filter:verbose 1 and grab the standard output from teh convert command
you can look at the otuptu to see what 'filter' setup it used by default for that image.

See, IM Examples, Filters, Expert options
http://www.imagemagick.org/Usage/resize/#filter_options

Hmmm for example. downsize (minify) a solid color image (no transparency), result image junked.

Code: Select all

   convert -size 100x100 xc:  -set option:filter:verbose 1 -resize 50% null: | grep '^#'

#
# Resize Filter (for graphing)
#
# filter = SincFast
# window = SincFast
# support = 3
# win-support = 3
# blur = 1
# blurred_support = 3
# B,C = 0,0
#

NOTE this feature of the 'filter:verbose' expert setting was only just added last week, to allow users to see the final filter selection results. so update your IM NOW.

The above is the internal defination of a Lanczos Filter. That is a Sinc windowed Sinc, but using a Faster Polynomial Sinc equivalent, rather than a slow Trigonometric Sinc -- another recent change but one that only makes the filter faster with no effect on results.

Doing this again with a xc:none (a fully transparent image)

Code: Select all

 convert -size 100x100 xc:none  -set option:filter:verbose 1 -resize 50% null: | grep '^#'

#
# Resize Filter (for graphing)
#
# filter = Cubic
# window = Box
# support = 2
# win-support = 2
# blur = 1
# blurred_support = 2
# B,C = 0.333333,0.333333
#

The 'Box' window means it has no 'windowing' so this is just a Cubic filter with control settings of B=1/3 and C=1/3
That is the internal definition of a Mitchell-Netravali filter ('Mitchell' for short)
See Resize Cubic, B,C Settings
http://www.imagemagick.org/Usage/resize/#cubic_bc

See Resize page for all the nitty-gritty details of filters, what they look like, and the effects they generate.

PS: Mitch is used for downsize when transparency is involved as it will not produce 'ringing' effects in the transparency, where a larger (support 3) filter like Lanczos, can. Semi-transparency ringing is VERY bad and is best avoided.
Mitchell is the best compromise for that.

In Enlargements you also want to avoid ringing effects and enlargements make such an effect more pronounced. See the examples shown in Ringing Artifacts where enlargments were used on purpose to highlight the effect of ringing.
http://www.imagemagick.org/Usage/resize/#ringing

[anthony]

Well, IM identifies no 'colormap' (as the default PNG output is the normal RGB format, not a palette format) - but it's still the same image, with type "palette" and less than 256 colors. Shouldn't the same resizing filter be used as in the case above?

ANY use of resize will generate lots and lots of new colors. As such -resize convert from palette to TrueColor handling.

many other operators do the same thing for the same reasons. -distort, -convolve, -blur, etc etc etc...

You can use -type Palette or PNG8 to force a PNG with a color indexed palette when output, but that will cause it to be 'color reduced' to fit the palette requirements.

[Drarakel]

I know already the things that are explained in the documentation. (Well, sort of. I won't pretend that I have understood every detail. ) I should have made that clearer.
I wanted to know if there are other rules in deciding which default filter is used. Rules that are NOT in the documentation. Especially in cases with 'colormapped' images - as I didn't find much about that in the documentation.
And I read about "-set option:filter:verbose 1". I had already used that. Thanks for that!
That's why my question basically was:

Why does ImageMagick use Mitchell here:

Code: Select all

convert logo: -set option:filter:verbose 1 -resize x200 test1.png

# filter = Cubic
# window = Box

And why does IM use Lanczos when executed like that:

Code: Select all

convert logo: logo.png
convert logo.png -set option:filter:verbose 1 -resize x200 test2.png

# filter = SincFast
# window = SincFast

(Well, I sort of know why. "logo:" is identified as 'colormapped', while "logo.png" is not. And Mitchell would again be used if I had stored the logo image as PNG8. But the only real difference there is the input 'file format'. The source images itself are completely identical of course! So, I was a bit puzzled that IM uses different resizing filters in cases like that?!)

[anthony]

Okay I see. the image is the same but the image source is different.
Sorry I get used to explaining thing to the more novice users.

I have read (stepped) though the code for the actual resize operator, though it was a few years ago, and my understanding of the selection was as I described. I'll take a look again...

"Use the Source Luke -- Programmers Motto"

Hmmm...

Looks like Mitchell is also selected for 'palette' images. Presumably because they are typically 'line drawings'. I'll add that to the notes in IM examples. However the -filter command line option already lists that condition, but I have update other aspects of that documentation, (as well as the related -set and -define options)

[Drarakel]

Thanks for adding this to your documentation!

I used your motto now and looked at the source.
It seems that in the 'colormapped' case, IM just checks the Class. If the image is identified as PseudoClass, then Mitchell is used as the default.
That explains why e.g. the downsizing of a plain "xc:" image will use Lanczos (as it's DirectClass for IM), but e.g. the downsizing of a 16bit grayscale image with thousands of colors will use Mitchell (as IM will identify that as PseudoClass - even if it's stored as grayscale PNG, not as 'normal' palette PNG). It's good to know that.

[anthony]

If you feel this is a error, or that that test is invalid. I would suggest you report it as a 'Bug'.

It seems to me that the simple test for Palette image class is probably invalid in any case and a resize result will always be of class truecolor. As such testing on class seems rather usless.

The test for enlargement and/or transparency on the other hand has very valid and solid reasons behind them.

[Drarakel]

Regarding the 'colormapped' case:
Yes, I think the current test is odd - as this makes IM's decision whether to use Mitchell or Lanczos a bit random for some images. I wouldn't call it a bug though.

But even if I report it at the bugs forum.. I'm not sure if there is a 'perfect' test for the 'colormapped' case (given the fact that IM wants to use Mitchell there, as such images could contain only 'line drawings'). Perhaps IM should count the colors - and if less than 256, then always use Mitchell? I don't know if that would be a good choice (as I also don't know much about the inner workings of IM).

By the way:
The "Best Filter?" link (http://www.imagemagick.org/Usage/resize/#best_filter) in the index of your Resize Usage documentation doesn't work - as the anchor is missing down there.

[anthony]

Fixed, thanks. I have yet to find a html link checker that not only checks the URL pointers but the anchor tags as well.

I am sure there are quite a few broken anchor links in their, especially as I try to provide a lot of reference links to cross link everything.