xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: FOP's new image package in Commons?
Date Tue, 18 Dec 2007 07:05:19 GMT
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 <cam@mcc.id.au> 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: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org


Mime
View raw message