>>>>> "JI" == Jun Inamori <[EMAIL PROTECTED]> writes:
JI> Hi Thomas,
>> I'll see if I can put togeather at least the adaptive
>> pallete part. I don't know how long it will take me
>> to get around to this, so if you or some other
>> enterprising programmer has a copy of Graphics Gems they
>> can probably beat me to it.
JI> The big problem is... The sources in "Graphics Gems" are written
JI> in C. On the net, I tried to find the similar resource in Java.
JI> But no result at this time :-(
As I said I'll try and write it some time, but it will be a 'dead
time' activity for me.
>> 4) I'm not certain but I believe the JDK uses a simple
>> pattern dither to effect color quantization
>> (it may use something better when drawing images).
>> It would be nice but probably not essential to use
>> a more advanced dithering function (like
>> Floyd-Steinberg - also see Foly-Van Dam,
>> Graphics Gems(?)).
JI> Does the good color palette solve the dither problems?
A good color palette will put less pressure on the dithering
function, so given a good palette you will get a significantly better
image given the same dithering function. The exact difference depends
on the image.
>> I don't want people to criticize the whole engine just
>> because we cut corners on palletization.
JI> I agree with you.
JI> The better color palette should be implemented.
JI> I'll continue to work with this issue at my free time.
JI> Whenever I found the solutions, I'll post it to this list.
Thanks for your work on this already.
I'll also remind you that there are a number of C programs that
will palettize images in the manner I describe so if a two step
processes is acceptable you could use a package like Image Magik (SP?)
to go from our 24bit PNG to a 4 or 8 bit PNG.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
