Bryan.TongMinh wrote:

For the indexed colors bug see bug 1218.

The unsharpness should be investigated though so leaving this bug open.

It's unclear from the bug whether the issue is *file size* or *image quality*... I can't really tell what you're indicating at the given URL. Can you describe how the different versions of this file interact with the issue?

Generally speaking you can't make a nice indexed-color scaled version of an indexed-color image, as scaling it either:

• looks horrible (nearest-neighbor etc)

or

• introduces a huge number of new colors (any kind of nice scaling)

It's possible to try to generate a new optimized indexed palette, but usually all that'll accomplish is making the image look worse again by throwing away color data.

Grayscale images (that are actually declared as grayscale, not indexed-color) *ought* to remain as grayscale rather than being promoted to truecolor, but I'm not sure offhand if we have logic to handle that case properly.

Ok I would remove my first sentence. I mean the issue of quality (not size of thumbs, but these are different too). Maybe this Bug is not sufficiently defined, or too general. Currently I've only tested grayscale images.

The logic can not tell the difference - thumbs from the same image (same colors but only different Bitdepth) to the same truecolor thumbs must be equal (or the indexed should be sharper?)

Another very simple 1b example (minimally, only to detect under magnification): Sharp Trucolor: http://upload.wikimedia.org/wikipedia/commons/thumb/archive/b/b5/20100430150734%21Ping_deny.png/300px-Ping_deny.png
Unsharp Indexed 4b: http://upload.wikimedia.org/wikipedia/commons/thumb/archive/b/b5/20110630223939%21Ping_deny.png/300px-Ping_deny.png

Ok I did a quick check resizing these versions of the Ping_deny.png image:

a.png -- the truecolor version
b.png -- the grayscale version (it is in fact grayscale, not indexed!)
truecolor.png -- a version explicitly re-saved from Gimp from a.png
gray.png -- a version explicitly converted to grayscale in Gimp from a.png
indexed.png -- a version explicitly converted to indexed color in Gimp from a.png

for x in a.png b.png gray.png indexed.png truecolor.png
do
convert \

		-quality 95 \
		-background white \
		$x \
		-thumbnail 300x142\! \
		-depth 8 -auto-orient \
		300px-$x

done

The resulting images match what I see from the above-linked thumbs:

• truecolor image, scaled, is still truecolor.
• grayscale image, scaled, is still grayscale. Looks slightly darker and possibly blurrier than scaled version of truecolor image.
• indexed-color image, scaled, becomes truecolor. Looks identical to grayscale version.

So the commands we're giving are exactly the same; ImageMagick itself is applying some slightly different behavior.

Tested:
Version: ImageMagick 6.6.2-6 2011-03-16 Q16 http://www.imagemagick.org

There is no different in grayscale and indexed, so this is a version problem of ImageMagick?
Another more suitable distinctly Indexed example (gallery from image:The Flying Serpent ArM.png) in http://de.wikipedia.org/wiki/Wikipedia_Diskussion:Grafikwerkstatt#Unterschiedliche_Behandlung_von_Bildformaten

The JPEG image there will receive additional sharpening that we add explicitly for JPEGs (as most JPEGs are photos and most photos benefit from a little sharpening on scaling, while most PNGs are line-drawings or screenshots and sharpening increases file size dramatically and often looks worse).

The PNG and GIF in theory should render the same (but then the truecolor & grayscale/indexed PNG should also render the same!). It looks like the GIF *does* render the same as the grayscale/indexed PNG, so at least that's consistent behavior between how it treats those two formats.

Now I realize that truecolor PNG also receive extra sharpening (though lesser). So maybe this is more a left feature!? But I would prefer instead a other scaling method for indexed images. [[Proximal interpolation]] or [[Bicubic interpolation]] instead of [[w:Bilinear interpolation]] or [[Lanczos resampling]] (I don't know).

PNG is the desired format for screenshots etc., but PNG thumbs are unsharp.

Compare: http://www.mediawiki.org/wiki/User:Subfader/PNG_thumbs_unsharp

Please solve this.

JPG thumbs of PNGs are sharper but have more artifacts when you look close, but still better to read than unsharp PNG thumbs.

See also my request to return thumbs of non-transparent PNG files as JPG:
https://bugzilla.wikimedia.org/show_bug.cgi?id=37960

See a strong effect on this image (comparing to indexed and true-color) T53400#1458867

In T31659#318148, @brion wrote:

Ok I did a quick check resizing these versions of the Ping_deny.png image:
[...]
So the commands we're giving are exactly the same; ImageMagick itself is applying some slightly different behavior.

Tested:
Version: ImageMagick 6.6.2-6 2011-03-16 Q16 http://www.imagemagick.org

Did anyone notify upstream?

In T31659#1501625, @McZusatz wrote:

In T31659#318148, @brion wrote:

Version: ImageMagick 6.6.2-6 2011-03-16 Q16 http://www.imagemagick.org

Did anyone notify upstream?

That comment, and the referenced version of ImageMagick, are over four years old. The checks need to be re-run with a current version.

$ convert -version
Version: ImageMagick 6.8.8-10 Q16 x86_64 2015-03-10 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC Modules OpenMP
Delegates: bzlib cairo djvu fftw fontconfig freetype gslib jng jpeg lcms ltdl lzma openexr pangocairo png ps rsvg tiff webp wmf x xml zlib

Testing https://commons.wikimedia.org/wiki/File:J%C3%BCrgen_Alberts_-_pv_portrait_02-3.png in RGB, grey and indexed gives three slightly different results but all of them are greyscale thumbs.

$ for x in 20*; do convert -quality 95 -background white $x -thumbnail 300x215! -depth 8 -auto-orient 300px-$x; done 

From RGB src:

From grey src:

From indexed src:

Any problems with current ImageMagick can be reported in their bugs forum.