[pandy71]

Originally Posted by jsr

Unfortunately this is not true in this case, because the quantizer works on full 24-bit, so even if i convert the image to have only "symmetric" channel values ($ee, $55, $11, $99, etc.), the palette quantizer will generate colours which are not symmetric and we're at where we begun.

Ok then seem that Wu algorithm average color - indeed, http://www.ece.mcmaster.ca/~xwu/cq.c

This algorithm often produces optimized images with less quality degradation than other quantizers due to its methodology of optimizing based on clusters of colors that are closely related to one another rather than simply finding the most used colors in an image.

.

Side to this questions:

are You using inverse gamma before processing (i mean normal pictures have no linear RGB space and to be correctly processed then need to be set back in linear space by applying inverse gamma)? http://www.4p8.com/eric.brasseur/gamma.html (and as real inverse gamma is CPU intensive then i use in ffmpeg trick with negate/inverting levels before any processing and reapplying negate at the end to restore correct values)

did You considered non RGB color space (for example YCgCo which seem to be very fast to compute (add + shift) and provide very good color decorrelation http://en.wikipedia.org/wiki/YCgCo ) - i sometimes notice that this approach produce better CLUT.

Originally Posted by jsr

Yes, the correct method would be choosing only bright colours, because the dark ones will be generated (your reverse way works too, choose the secondary dark colours, then generate the primary bright palette) - however intensify or reduce the image's brightness can cause information loss, because of over or undersaturation. There could be some method to prevent this, but i am not a mathematician, the algorithm of the quantizer is done by Mr. Wu twenty years before, i just know what it does, but do not know why it works.I am aware of them; i tried them before and they gave much worse results, than Mr. Wu's quantizer.You are welcome.

Ok, my point with half level was that in EHB only bright colors can be selected and HB colors are always half of the bright one - it may happen that HB colors will be same i.e. non optimal CLUT values halved will be equal thus focusing on selecting lower half should provide better CLUT usage IMHO.

I tried many times those new algorithms and from my perspective they are superior to everything (gimp/xnview with xiquantizer http://www.ximagic.com/q_results.html ) - especially for low CLUT (16 colors and less) spatial color seem to be hard to beat.

Originally Posted by jsr

However, on the Amiga, nothing supports alpha channel, nor from hardware, neither from software. Besides, even if i would made a custom IFF chunk, which would contain the alpha data, i cannot expect existing software supporting it.

Simply there is no any point storing the alpha data.

Ok, alpha 1 bit is supported by hardware ECS and maybe AGA(?) - You can set transparency for genlock http://amiga-dev.wikidot.com/hardware:colorx .