256 colors: Worse than 1.91.4?

Bugs found in XnView Classic. Please report only one bug per topic!

Moderators: XnTriq, xnview

Post Reply
stephan_g
Posts: 11
Joined: Thu May 31, 2007 10:22 pm

256 colors: Worse than 1.91.4?

Post by stephan_g » Mon Dec 31, 2007 12:16 pm

It looks like reduction to 256 colors (no dithering) in 1.92 may give worse results than the old 256 colors (adaptive) implementation found up to 1.91.4. In a sample image containing lots of white (255,255,255) background, the maximum value is (252,254,252). This also leads to a common red tone (255,x,x) becoming (252,x,x).

Original: http://stephan.win31.de/rp20s-2-3.png
1.91.4 result: http://stephan.win31.de/rp20s-2-4.png
1.92 result: http://stephan.win31.de/rp20s-2-4-test.png
1.92 result, dithering: http://stephan.win31.de/rp20s-2-4-testd.png

Save for the "clipped" dynamic range in 1.92, the palettes seem to be generated in an identical fashion, as they look virtually identical and are interchangeable (the images themselves are different though).

Interestingly, a test image containing just (255,255,255) and (255,0,0) gets a correct palette, which leads me to assume that the issue only occurs if originally #colors >256.

BTW: "Edit Colormap" is not consistent with the spelling of "Colour" elsewhere. (Why not call it "Edit Palette" anyway?)

I think it's pretty cool that Floyd-Steinberg dithering is now available with an adaptive palette. It would be interesting to know, however, which average value it shoots for - 50% (255,a,b) and 50% (245,a,b) almost certainly do not result in a perceived average of (250,a,b).

Post Reply