commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Abey Mullassery" <>
Subject Re: [New Proposal] An Imaging wrapper package
Date Fri, 07 May 2004 10:37:52 GMT

Thanks a lot for the detailed mail and very useful suggestions.

> I agree with Martin that Apache Commons would be a better place. Another
> place could be the shared code base in the upcoming XML Graphics project
> but I think Apache Commons is still preferred. I'd rather not have such
> a package outside the ASF if possible. There are enough potential customers
> here that we can justify a shared ASF-homed API adapter for images.

That was my understanding as well eventhough upcoming XML Graphics project was news to me.
I personally would love to share this code with ASF than anywhere else.
Since many of you say that its better fit to be an Apche commons project, I will send this
proposal to the Apache-commons list. Is the procedure same for Apache Commons as well?

But I think it is best to propose the package to Apache commons after we redefine the scope
based on the feedback that we have got here. I started writing this library for myself :-)
and hence I designed it in such as way that was easy for me to use (for Image Taglib and Image
ANT Tasks). However it is just in a preliminary stage to be an apache commons package.

> As for the scope, I think you're already on the right track. If I were
> to define the scope without already looking at what you've done, I would
> do it like this:
> - Functionality defined by interfaces.

It has ImageLoader (wanted to name it ImageIO), ImageTransformer and an Imaging interface
extending the other two.

> - Central factory for getting (and registering) implementations for
> these interfaces. Possibly auto-discovery of available implementations.

ImagingFactory by default gets you a JAI based support if available, if not Java2D (Imageio
or plain AWT). It could also be specified explicitly.

> - Support for multiple image libraries simultaneously (not all libraries
> support the same set of codecs).

JAI an Java2D support is available. GIF encoding support comes from pjatools if available
but this has a lot of room for redesign.

> - The above makes it necessary to have code to detect the image format
> when loaded from an InputStream without a MIME type available. FOP
> already has code for that.

Not available. 
This would be a great feature to include.

> - Support for prioritizing the image libraries to be used.

Not available. 
The JAI support is used if available. If not it defaults to Java2D. 
In the same way for loading it tries to use ImageIO or defaults to AWT.

> - Main adapter interface should expose load and save functionality.
> - Image manipulation should be a different set of interfaces as most
> applications will only use the load/save part. The extent of the image
> manipulation functions available would have to be defined further.

The IO functionality is exposed by the ImageLoader interface.
The transformations are exposed byt he ImageTransformer interface.
But both are commonly exposed by the Imaging interface. maybe this requires some change of

> - a codec library would probably be out of scope but could be done later
> if there's enough interest.

Not available.
Formats like Dicom, Flash etc., could be useful.
It has to be redesigned to add such capabilities.

> An important point for applications that write images is support for
> metadata. ImageIO does a not so bad job here. Raises the question how
> much should be invested here and if this is really all necessary now
> that JDK 1.4 is already available for almost all platforms.

Not available.
Need to look into this.

> Could you elaborate what you mean by "SVG operations"?

All I meant was a simpe interface with methods that take SVG string/file/stream as input,
does some manipulation on it and returns SVG.

Let me know your thoughts,

Abey Mullassery

> On 07.05.2004 07:26:27 Abey Mullassery wrote:
> > 
> > Thanks for the pointers and the suggestions.
> > 
> > If there is a need for loading and saving images in various projects already wouldn't
it be a good idea to create a common package. The primary goal of the package I proposed was
to make it simple. All the feedback I get from the users of PMIW lauds this very point.
> > I had plans of including a simple wrapper for SVG operations as well but I thought
it would force the package to do too many things and lose focus. 
> > 
> > Please add your comments and suggestions. 
> > If you think that we need to redefine the scope before the can think about including
it in the commons, we could do that as well.
> > Can this be included into a similar project that is now in the proposal stage (like
> > If you think that Jakarta-commons is not the right place for this package, please
suggest another place. Would Apache-commons be a better place?. How about 
> > 
> > My aim was to make the package (that supports Image Taglibs and Image Tasks and
being used directly) a public project so that many more can contribute and will have much
more functionality and feedback.
> > 
> > Eagarly waiting for your thoughts.
> Jeremias Maerki
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message