very slow +dither on IM 6.6.7.7 Q16

[magick]

The complex structure is a Octree whose leaf nodes are the image colormap. So when you dump the image colormap you can getting all the colors used in dithering, even if some of the colors are not used.

[anthony]

Hmmm okay....

Code: Select all

convert -size 20x512  gradient:red-blue -colors 256 -verbose info: | grep Colormap:
  Colormap: 256

I got the 256 colors requested.
and

Code: Select all

 convert -size 20x512  gradient:red-blue -colors 256 -unique-colors -format %w info:
117

was actually used by the dithering process.
Though having such a low number of colors being used from the palette seems a little wrong.

ASIDE: I may have to write a script to convert colormap to palette image for more experiments.



This however particular case seems to be a bit excessive, in the final number of colors color!

Code: Select all

convert -size 20x512  gradient:red-blue -colors 32 -verbose info: | grep Colormap:
  Colormap: 8

I mean out of the 512 colors, requested 32 but got only 8!!!! That's not very good.
Even PbmPlus does a lot better than that!

But then why is it when do I ask for no dithering!

Code: Select all

convert -size 20x512  gradient:red-blue +dither -colors 32 -verbose info: | grep Colormap:
  Colormap: 16

I no get 16 colors!

The selection of colors (unless you give me some good reason otherwise) should be independant of the actual method chossen to dither those colors.

However for Error Correction Dithers having some 'out-rider' or colors around the edge of the used color space can prevent some dither speckling faults.

Basically things seem to be in a bad way. Perhaps the algorithm has been tweeked to death and it is time to inplement a number of color reduction algorithms, seperate to the current 'one size fits all' approach.

[anthony]

Hmmm can we have a new option, A bit like -unique-colors but which ouputs the current 'colormap' instead of the actual colors in the image?

That will be a good starting point for this type of work.

[magick]

To get more colors use -treedepth 8. Dithering by default uses a tree depth of 5. A deeper color tree takes more time but gives more accurate results.

[fmw42]

To get more colors use -treedepth 8. Dithering by default uses a tree depth of 5. A deeper color tree takes more time but gives more accurate results.

Does this help my slowed down times for +dither -remap in the last few releases? This would appear to be more for Anthony's issue?

[magick]

Did you check 6.6.7-8, the current release? It should have the same runtime as older versions. If not, let me know and I'll take a closer look at the problem.

[fmw42]

Did you check 6.6.7-8, the current release? It should have the same runtime as older versions. If not, let me know and I'll take a closer look at the problem.

Yes, you are right the times are back.

For my own benefit, what did you change and is this final or might it change back to longer times with regard to solving Anthony's issues? Or is setting the tree-depth larger the solution for Anthony?

[magick]

For posterize I set the tree depth to the maximium, 8, for more accurate color matching. Like previously mentioned, it always been a trade off between color matching and speed. The default tree depth is 5 for dithering and 6 for non-dithering. For image remapping and posterize, we use a tree depth of 8.

[fmw42]

Thanks. I will notify my client to try the current version 6.6.7.8.

By the way does this include now OpenMP processing?


Fred

[magick]

By the way does this include now OpenMP processing?

Yes, however, this particular algorithm does not scale well with OpenMP. There is a minor reduction in speed.

[achillies000]

I am reporting this as it seems excessive for no dither. Furthermore, a client reported to me about the speed of a script I wrote for them using the above (like) command when run from IM 6.6.7-7 (about 7 seconds) compared to IM 6.5.9-3 (about 2 seconds).