> Hi David,
Hi Jim. Thanks very much for the response and helpful suggestions.
> It sounds like this GIF encoder package you found does some
> funny work
> under the covers to process the pixels and ends up using a system
> ColorModel when it doesn't need to. It doesn't have to have
> native code to
> have this dependency, it could make use of
> Component.getColorModel() and
> end up with such a dependency, though it is still pretty much
> unnecessary.
> In the new age (JDK 1.2 and later) of BufferedImage objects
> any reasonable
> encoder would work directly with the color depth that is
> given to it. You
> might want to look for another encoder.
It's certainly possible that the encoder's a bit lame. Someone else chose
this encoder prior to my arrival. It looks like it scans the image and builds
a list of all the colors used in it. From its Javadocs: "GIFEncoder will
convert the image to indexed color upon construction. This will take some
time, depending on the size of the image ...". I'll definitely keep in mind
the possibility of switching to a better encoder at some point, but for now I
think I need to just focus on getting this bug fixed.
> I might also recommend using PNG instead of GIF for this
> reason. The GIF
> format is restricted to at most 256 colors and so all of your great
> snapshots of your rich 24-bit color depth screens will end up getting
> dithered when reduced to 256 colors for writing as a GIF file. PNG
> supports 24-bit images so no color reduction will be needed
> for your screen
> snapshots to write out an image.
I wish I could use PNG. We use GIF and JPG as our standards system-wide,
though, so unfortunately I'm stuck with those. I have to have support export
to either of these 2 formats, since it's chosen by the user at run-time. JPEG
is obviously not a problem, as you indicated, but I have to support GIF too.
I've also had some discussions off-list with Dmitri about this situation too.
(Who was also very helpful, I might add.)
I think I'm just going to wind up doing this for now:
private static BufferedImage colorDepthReduce(BufferedImage img) {
BufferedImage colorDepthReducedImg =
new BufferedImage(img.getWidth(), img.getHeight(),
BufferedImage.TYPE_USHORT_565_RGB);
Graphics2D g2d = (Graphics2D)colorDepthReducedImg.getGraphics();
g2d.setComposite(AlphaComposite.Src);
g2d.drawImage(img, 0, 0, null);
return colorDepthReducedImg;
}
Seems to solve the problem. Dmitri suggested that I use
BufferedImage.TYPE_BYTE_INDEXED instead, but that seemed to generate a poorer
quality image.
Thanks very much for the help!
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".
