On 18.12.2007 02:21:38 thomas.deweese wrote: > Hi Cameron, Jeremias, > > This is written pretty quickly just to get potential ideas comments > out. > The Image package sounds nice in general. > > > Jeremias Maerki: > > > > I could move the new image package from org.apache.fop.image2 [2] (in > > > the temporary branch) to Commons. > > > > > > The new package name needs to be discussed as there is already an > > > org.apache.xmlgraphics.image. My proposal: > > > > > > org.apache.xmlgraphics.image.loader (in analogy to the writers) > > Cameron McCormack <[EMAIL PROTECTED]> wrote on 12/12/2007 07:32:42 PM: > > > Would this be a replacement for Batik?s > > org.apache.batik.ext.awt.image.spi.* classes? They currently use an SPI > > interface to provide access to codecs, which take a stream/URL and > > return a org.apache.batik.ext.awt.image.renderable.Filter. > > > I?m all for rationalising the image handling code between Batik and FOP > > so that as much commonality as possible can be factored out. > > Right this would be good. However there are bits that are needed > for spec conformance. In particular for PNG we need to be able to > override gamma correction for PNG images in order to apply ICC > Color profiles.
I've noticed that. For FOP, the requirements are (usually) not that high although I would like to improve FOP color-wise. The big problem is lack of knowledge in the color area. I'm also still learning. I'm sure it is absolutely doable to include the features necessary for Batik. FOP will also profit from that. > > > Key features of the package: > > > - Image preloading: format detection and reading the intrinsic size of > > > the image without loading the whole image into memory (works for most > > > images). > > This is nice. > > > > - Image consumers can simply tell the package what kind of images it > > > supports and the image library tries to provide the image in the best > > > possible format (possibly using automatic image conversion). > > Are we talking about in memory formats (RGB, 8bit, 16bit, Grey, etc.) > or disk formats? In-memory representation, although at this time not in such a detailed manner. You can only say: I need a BufferedImage and then you get a BufferedImage. Whether that's 16bit or Grey or whatever currently just depends on the image's original format and the components used to load the image (i.e. the codecs). I'm pretty sure that at some point the use of the ImageFlavor class has to be refined. At the moment, it's just a String indicating what kind of images are supported by a renderer. The PCL renderer, for example, currently just supports bi-level images directly. It does some conversion from color to gray and gray to bi-level by itself. That is something that the image package could also do as part of the conversion pipeline if the ImageFlavor concept is refined. > Is it 'push' oriented? I ask because of the mention of Image consumer. > This can make filtering complex (basically you would have to cache the > entire image in memory). I tried to avoid buffering where possible, exactly because I wanted to keep memory consumption low. But I've worked with RenderedImage for bitmap images, not with Renderable. But the RenderedImage is contructed only when the caller is asking for it. I've looked into Batik's image loading code when I constructed the package in order not to be too far away from the requirements there. > > > - Currently supported: All bitmap formats supported by ImageIO codecs, > > > SVG/WMF through Batik, EPS (only usable for PostScript output without > a > > > PostScript interpreter in the back) > > Does the interface support tiling? Not at the moment, no, because we don't need that functionality for FOP. However, FOP could still profit at some point because large images might consume less memory when processed in tiles. > > > - Custom image loaders and converters can be dynamically plugged in. > > > - Image cache (using soft references) > > This is a needed feature however it often needs to be overridden > to fetch an image that has been rewritten/updated "in place". So the > ability to flush the cache on an individual and/or group basis is > important. I'm sure this can be refined. Thanks for asking these questions. It shows that Batik has quite different requirements in some areas. I'm pretty confident that there is room for improvement in this package so Batik's requirements can be met. FOP simply has a different set. For FOP, it's important to provide more image formats and conversions between them because we also have more different output formats. And that's why the current focus is mostly on that. For Batik it doesn't go to a deep-enough detail level, yet. I guess we simply need to make a few experiments when I've moved the package into Commons. It will quickly show what needs to be improved and how this could be done. Jeremias Maerki --------------------------------------------------------------------- Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
