Have you tried activating the ImageIO implementation with having JAI ImageIO Tools in the classpath? That should take care of many CMYK-related problems. Since I'm going in that direction anyway, we can later see if your problems are already solved without your replacement. Did you use ImageIO as backend for the replacement?
On 04.02.2011 11:48:08 Raik Nagel wrote: > Nice to hear something about JPEG. There are several problems in the > current jpg decoder, like CYMK and other Adobe specific JPEG output. We > use an replacement for the batik loader and it works fine for a huge set > of input images every day. Let me know if you want to check our patch. > > raik nagel > > Am 03.02.2011 21:27, schrieb Jeremias Maerki: > > I've started looking into the com.sun problem, i.e. the problem with the > > Sun-private JPEG codec that is not available in OpenJDK and other JVMs. > > > > I've already removed the JPEG compression support from the TIFF codec > > fork in XGC. I'm tempted to do the same in Batik. The TIFFTranscoder > > can't generate TIFFs with JPEG compression anyway (apparently, there > > were NPEs). Removing this means that Batik won't be able to load TIFFs > > with JPEG compression anymore unless the user switches over to the > > ImageIO codec. However, a TIFF ImageIO codec is only available with the > > JAI ImageIO Tools in the classpath. > > > > I've also locally deleted the com.sun-based JPEG ImageWriter and enabled > > the ImageIO-based one. I've compared the generated JPEGs on a low level > > and they are basically identical (especially the pixel data). > > > > Next on the list is making sure the ImageIO-based JPEG support can fully > > replace the com.sun JPEG codec. When I have that, we basically are > > completely rid of of the com.sun classes with only the restriction > > indicated above. > > > > If anyone thinks that removing JPEG decoding support from the internal > > TIFF codec is unacceptable, please let me know. If necessary, I can try > > to make sure there is a fallback to ImageIO if the internal codec cannot > > load a particular TIFF. > > > > From my experience, the TIFF codec from JAI ImageIO Tools is superior to > > the internal one. So personally, I'd actually love to remove that one > > from Batik and XGC altogether. But I guess that's not very popular. > > > > An alternative to my approach above is to conditionally compile the > > com.sun-"tainted" classes but I'd rather put something together that > > works on all JVMs in a consistent way (or as consistent as possible). > > > > BTW, after the build improvements (in the new branch), the XGC > > dependency comes in. I plan to slowly synchronize and then phase out the > > Batik-duplicates. And I may be tempted to plug in the XGC image loading > > framework as additional image source so Batik can support MUCH more > > image formats. But first things first... > > > > Jeremias Maerki > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- > Dr. Raik Nagel > > sprd.net AG > Gießerstraße 27 > 04229 Leipzig > Germany > > > Vorstand/Executive Board: Matthias Spieß, Tobias Schaugg, Philip Rooke > Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Lukasz Gadowski > > Handelsregister/Trade Register: Amtsgericht Leipzig, HRB 22478 > Umsatzsteuer-IdentNummer/VAT-ID: DE 8138 7149 4 > > www.spreadshirt.net > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
