ordered-dithering problem (images included) updated!

[denizen]

i use 6.4.9 q8 version of imagemagic.
when

convert 1.png -ordered-dither o8x8,8 1.gif

i have a color artifacts on white zone of animation...

[denizen]

what is the problem with my topic?

[anthony]

THIS IS NOT A BUG!

Your 'white' zone is NOT pure white!!!!! thus the scattering of dots.

Very large dither/threshold patterns tend to do this for images that are slightly off.

I recommend you increase contrast slightly so as to properly peg your slightly off white colors to pure white, and try again.

[denizen]

Thanks to you reply.
I done what you recomend, but .... see picture below



I use -white-threshold 95% and after -ordered-dither o8x8,8

Thanks again.

[anthony]

Code: Select all

convert 0040.png -white-threshold 95% 0041.png
 convert 0041.png -ordered-dither o8x8,8 x:

result did not show dither problem. You need to apply it BEFORE the dither.

If doing it in one command, make sure your READ the image BEFORE applyin the operators to it. When you do that IM will do the operators in the right order.

Code: Select all

convert 0040.png -white-threshold 95% -ordered-dither o8x8,8 x:

[denizen]

yes, i doing it in separate commands

ferst i done
convert 0040.png -white-threshold 95% 0040m.png
second
convert 0040m.png-ordered-dither o8x8,8 0040.gif

but broblem is not dissapear!

i use windows binaries of IM 6.5.1 Q16

i think it bug, because GIMP have not this artifacts (then ordrerd ditherng of this image).

Thanks

[anthony]

I ran your command, directly cut and pasted from the forum. Added one space before -order-dither, and the results
came out correctly. image is ordered dithered, and white areas remained 'white' with not speckle noise.

I am using the very latest IM directly from SVN archives, as per an hour ago. ImageMagick 6.5.1-1 2009-04-09 Q16
This will be released in a day or so, though their has been no work that I can see to make this any different to what you are using.

Could you have multiple IM's installed that are confusing each other? or something else.

Check the intermediate image white areas and see if they are really 'white' to determine if it is the first or the second command that fails.

save second image as PNG to avoid possible GIF color reduction faults.

[denizen]

Thanks to you reply.
I use only one IM release intalled on my PC. This poblem is present in all latest verions of IM for windows. I check it on 32 and 64 bit versions and on 8Q and 16Q. (6.4.9.10, 6.5.1.0...)
I have assured that the white zones is pure white (255,255,255 color).
On what platform you use the IM? Can you do the check on pure windows?
Below i post the orignal image with pure white zones, comman convert and result. Binaries IM for win 32, V 6.5.1.0

convert 0040m.png -ordered-dither o8x8,8 0040f.png

[anthony]

I use linux version, and I have no setup to test windows versions. Sorry.

However I wrote the current code that ordered dither uses, and an quite certain it runs the same on BOTH systems. You really could NOT be talking to a better person for trying to work out what is happening.

Is your IM a Q8 version? It may be that a o8x8 threshold pattern will have quantium effects due to the use of 8 bit color range.

Can you please try dithering a gray-scale gradient? This is an ideal check that IM is doing things correctly.

For example, like those in IM Usage Examples, Color Quantization and Dithering, Diffused Pixel Dithering
http://www.imagemagick.org/Usage/quantize/#diffused

Code: Select all

convert -size 20x1000  gradient: -rotate 90  -ordered-dither o8x8  od_o8x8.gif

This should distinctly show all 65 distinct patterns of ordered dither that a o8x8 threshold map can produce.

The threshold map itself should be defined by the IM configuration file "thresholds.xml" somewhere on your machine, The location will be listed using this option.

Code: Select all

  convert -list threshold

The previous URL has all the documentation on the ordered dither implementation beyond what is in the distributed "thresholds.xml" file. I wrote all of it as part of the re-programming on IM to allow a expanded and user-expandable set of order-dither threshold maps.

The only things not implemented at that time was...

• is 'channel offset' dithering much like used for 'offset printing'
• a method of using a low level ordered-dithering using a small limited set of user defined colors,
  much like many 'icon' generating programs provided on window 3.1 with its limit set of 16 colors.

[denizen]

I appreciate you help, i realy want to help to make IM better.
I use IM Q16 version for windows, so it is not quantum effects.
The command you propuse to chek works good!

convert -size 20x1000 gradient: -rotate 90 -ordered-dither o8x8 od_o8x8.gif

the result is below



but the disscused image works bad... what can we do to correc this bug?
i can post more "buggy" ordrerd dithered images if you want.

Thanks.

[anthony]

The gradient working out perfectly, so I can't see why it is failing for you for the image.

Hmmm how many colors do you get in the final image BEFORE you save it?
You are saving to PNG so it should not make a difference, but window PNG library may be different to linux.

The reason I ask about quantim effects is because of the ,8
that means it wants 256 colors for each channel of the image, and dithers between
each of the colors. That is 2^8^3 colors or 'millions of colors'.

However the image shows dithers involving colors that are not that bad! More like the
comma part was ignored. Try running it without the ,8 then with say ,4

[denizen]

Ok. I done it.

convert 0040m.png -ordered-dither o8x8 0040m0.png



convert 0040m.png -ordered-dither o8x8,4 0040m4.png



I hope it helps....

[anthony]

Ok so the 'levels' cause the problme, but only on windows. Arrrggghhhhh....

[denizen]

i hope it can be fixed.

Regards.

[anthony]

Without being able to replicate the problme that may be difficult.

I'll try some tests and see if I can get it to appear.