Posterise does not uniformally distribute colors

[anthony]

This may be a symption of the continuing problem of the closests color match failure.

Posterise of a gradient does not produce a uniform distribution of colors.

Code: Select all

  convert -size 20x640  gradient: -rotate 90  gradient.png
  convert gradient.png  +dither  -posterize 5   posterize_gradient.gif

The colors generated...

Code: Select all

 convert posterize_gradient.gif -unique-colors txt:

# ImageMagick pixel enumeration: 5,1,255,rgb
0,0: ( 0, 0, 0) #000000 black
1,0: ( 64, 64, 64) #404040 grey25
2,0: (127,127,127) #7F7F7F grey50
3,0: (191,191,191) #BFBFBF grey75
4,0: (255,255,255) #FFFFFF white

Which is a uniform selection (quantization) of 5 colors (which is what posterize should do, but the matching of 'nearest' color to this color map is failing -- BADLY

This is the clearest indication of a problem I and others have reported a number of times.
Something is not correct with 'dither' image color to the color map.

[anthony]

Things seems to have improved since the last time I reported the bug (above).

However while the result is more 'linear' it is only producing 4 colors, not the requested 5 colors.
The color distibution looks like it is gamma adjusted (which can be good!)

Code: Select all

  convert -size 20x640  gradient: -rotate 90  gradient.png
  convert gradient.png  +dither  -posterize 5   posterize_gradient_2.gif

The color palette generated, is uniform, just 1 color short of the 5 colors requested.

Code: Select all

convert posterize_gradient_2.gif -unique-colors txt:

# ImageMagick pixel enumeration: 4,1,255,rgb
0,0: ( 0, 0, 0) #000000 black
1,0: ( 85, 85, 85) #555555 rgb(85,85,85)
2,0: (170,170,170) #AAAAAA rgb(170,170,170)
3,0: (255,255,255) #FFFFFF white

Going to 6 colors reproduces the previous problem. As such 2 bugs are now present!

[magick]

Look for a patch in ImageMagick 6.6.7-7 Beta to fix the number of colors problem you reported. We now get:

• -> convert posterize_gradient_2.gif -unique-colors txt:
  # ImageMagick pixel enumeration: 5,1,255,rgb
  0,0: ( 0, 0, 0) #000000 black
  1,0: ( 64, 64, 64) #404040 grey25
  2,0: (128,128,128) #808080 fractal
  3,0: (191,191,191) #BFBFBF grey75
  4,0: (255,255,255) #FFFFFF white

[anthony]

This problem is probably related to the long-term "Get closest matching color" bug in the image dithering function....

Specifically reducing color (of a gradient) using a linear color map

Code: Select all

convert -size 20x640  gradient: -rotate 90  gradient.png
convert -size 1x5 gradient:   posterize_color_map.gif
convert gradient.png  +dither -map posterize_color_map.gif   posterize_map.gif

As you can see the resulting reduction of colors is not very evenly (linearly) distibuted.

ASIDE: watch the forum browser window size. The forum website gives no indication if you are seeing the complete image or one truncated by your browser window size limits.

[anthony]

Look for a patch in ImageMagick 6.6.7-7 Beta to fix the number of colors problem you reported. We now get:

• -> convert posterize_gradient_2.gif -unique-colors txt:
  # ImageMagick pixel enumeration: 5,1,255,rgb
  0,0: ( 0, 0, 0) #000000 black
  1,0: ( 64, 64, 64) #404040 grey25
  2,0: (128,128,128) #808080 fractal
  3,0: (191,191,191) #BFBFBF grey75
  4,0: (255,255,255) #FFFFFF white

get the number of color problem is now fixed. But the dither using nearest matching color (+dither) is still wrong.
This also effects the other two error correction dither types too.

[magick]

The -posterize option distributes colors uniformally in ImageMagick 6.6.7-7 Beta available by sometime tomorrow.

[anthony]

I'll check it out.

I am reinvestigating this bug as I found information on new methods of ordered dithering that will allow you to dither with a small pallete of colors rather than a linear gradient, and want to get the current dither color sections working properly again.

FYI...

Here is the information listing various ordered-dither techniques, as well as threshold map generation.
http://bisqwit.iki.fi/story/howto/dither/jy/

[anthony]

No change. The colors are quantized uniformally. But the dither to 'nearest' color is not so uniform, and it should be.

Perhaps it should use the same distance function that was developed for compare -metric fuzz

[magick]

The colorspace is divided into a cube. For a uniform mapping we needed to move to a higher level in the tree before we searched for the closest color. The trade off is we now get uniform colors as you requested but it does slow down the color quantization algorithm a bit due to the larger search space. Look for a patch in SVN and in ImageMagick 6.6.7-7 Beta by sometime tomorrow.

[anthony]

Still it would solve the problem, which has been reported many times in the forum, by a number of people with examples that show the problem of dithers failure to get the 'closest' color to the pixel being replaced.

This will be vital when (if I get time, as it is well down on my ToDo list) I program ordered-dithers with quantized or user provided palettes of colors. I'd probably implement it as a type of -dither setting.

[magick]

Both SVN and ImageMagick 6.6.7-7 beta now have the patch to fix the dither "closest color" and the posterize problems you reported. Post here if you find problems with our patch. Thanks.

[anthony]

Yes it is now correctly selecting the nearest color for given palette if colors!
ASIDE: this fix has also corrected a large number of other minor problems I have been seeing in IM Examples.



As such the same result will be generated by the -posterize operator. (confirmed).


However while -posterize 1 no longer produces an floating point exception, it does NOT produce any image
nor any 'operational error'. You just get NOTHING!

Also posterize without changing the default dither setting does not generate a dithered image!

That is

Code: Select all

convert gradient.png   -posterize 2  posterize_dithered.gif

should produce a black and white dithered image, but it is not (and it used to).

Mind you the official documents does not really say very much about it either, so I should have a look at updating the -posterize option reference.

[magick]

Posterize with 2 levels produces a black and white image which is the correct results. Any previous results were wrong due to the bug you discovered.

We added a patch to fix the posterize for 1 level. A level 1 produces a pure black image.

[anthony]

Posterized previously dithered by default.

My examples above used +dither to remove dither effects without that option the result should be dithering. It is not.

That is

Code: Select all

convert gradient.png   -posterize 2  posterize_dithered.gif

should produce a black and white dithered image, but it is producing a "+dither" type image.