On 05.02.2011 00:03:13 Cameron McCormack wrote: > 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 have no idea how widely JPEG-compressed TIFFs are processed with > Batik. I think it might make sense to do as you suggest, and if users > need to process such TIFFs to get them to use JAI. > > > 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). > > Good. :-)
This part is committed now: http://svn.apache.org/viewvc?rev=1068104&view=rev > > 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. > > I think that is worth doing. It should not be hard, right? Probably not. I'll see. > > 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. > > From my perspective, TIFF support seems kind of niche in the first > place, so I dont feel too strongly either way for it. On the DirectFactory (web-based postcard application of SwissPost) we embed almost as many TIFFs as JPEGs, mostly CMYK TIFFs. So for me, it's not niche at all. But with the JAI ImageIO TIFF codec I can at least handle about 98% of the TIFFs that get thrown at the application. It gets ugly when people somehow manage to embed RGB color profiles for an image with CMYK data or vice-versa, or when the color profile is bad, or when exotic n-channel TIFFs get uploaded. The special image bridge in FOP that can use ImageIO (actually the XGC image loader framework) saved my sanity many times already. > > 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). > > Yeah, if possible it would be good to avoid that. > > > 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... > > Sounds good. > > -- > Cameron McCormack ? http://mcc.id.au/ > More to come as time allows... Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
