i guess your encoder should be 100% java otherwise it
may use native library that rely on the colordepth the machine
can handle...

----- Original Message -----
From: "Rosenstrauch, David" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 21, 2004 8:50 PM
Subject: Re: [JAVA2D] color depth


  Hi David,

  you can use
    BufferedImage bi = ...;
    ColorModel cm = bi.getColorModel();
    int bpp = cm.getPixelSize();

  Thank you,
    Dmitri


Hmmm.  That did work (thanks!), but it looks that's not actually what I'm
looking for after all.  Let me clarify my problem a little bit then.

One of our developers wrote some code to do a screen scrape:  generate a
BufferedImage using the java.awt.Robot.  We then try to save that to a GIF
using an encoder class we found.  But we ran into a problem:  the GIF
encoding
worked on some people's machines and failed on others.  Turns out that the
deciding factor was whether the user's PC is set to 16-bit color or to a
higher setting.  Writing the GIF would succeed on 16-bit boxes, but fail
for
24- or 32-bit:  we'd get an exception thrown from the encoder indicating
that
the image contained more than 255 colors (which I assume is a limit for
the
GIF format).

Now I'm able to successfully work around the problem whenever I get that
exception by converting the image to 16 bit (by creating a new buffered
image
BufferedImage.TYPE_USHORT_565_RGB).  But I'd like to make this more
efficient.
I don't want to have to get halfway through encoding the image before I
get
that "> 255 colors" exception and then have to go and re-do the encoding
using
the converted image.  I'd much rather find a way to query up front as to
whether the original image is not encodable as a GIF due to too many
colors
and, if so, then do the conversion and in this way I would only ever have
to
do the encoding once.

Although the getPixelSize() method you mentioned does show the difference
between the pixel sizes of the original and the converted images (24 bit
as
opposed to 16), that's not a sufficient query to use for this purpose.  On
a
machine with 16-bit color (where I'm able to encode the image fine without
any
exceptions thrown) getPixelSize() still reports the original image at 24
bits,
even though it will encode to GIF just fine.

So I guess the problem is not just determining the pixel size, but rather
how
many colors are actually in use by the image.  Anyone know of a technique
I
can use to do that?

Thanks,

DR

==============================================================================
This message is for the sole use of the intended recipient. If you
received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until
they
are confirmed by us. Message transmission is not guaranteed to be secure.
==============================================================================

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
of the message "signoff JAVA2D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".



=========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to