Skip to main content

RE: [JAI-IMAGEIO] Getting filename to codec?

1 reply [Last post]
Anonymous

you're right, your implementation doesn't require any different
handling in the calling program, and this is an advantage.

Of course, you are vulnerable to the possibility that some other
ImageInputStreamSpi could be called first, and your ImageReader
will not receive a FileImageInputStream. But this is a problem
with the API, in my opinion. The way we avoid it is by avoiding
the ImageInputStreamSpi altogether.

If our software is used as an API/library, we provide some
higher-level factories to essentially do the same thing that
the ImageInputStreamSpi does without the drawbacks. Of course,
we can't just drop our ImageReader plugins into another
application and have them work, at least not the ones that
require finding extra files. You need the extra software layer
to provide that for our library.

Mike

> -----Original Message-----
> From: Fabrizio Giudici [mailto:Fabrizio.Giudici@tidalwave.it]
> Sent: Friday, June 02, 2006 2:43 PM
> To: interest@jai-imageio.dev.java.net
> Subject: Re: [JAI-IMAGEIO] Getting filename to codec?
>
>
> I'm reading with interest this thread to find out if I can
> improve my
> design in jrawio.
>
> But I'd point out that - unless, and it's probable - I'm missing
> something, the alternate solutions provided require for dealing with
> custom code in the application, creating a wrapper around ImageIO,
> while my "FileImageInputStream2" approach lies entirely within the
> implementation of the Image I/O Spi.
>
> Sometimes specialized code could be ok, others not (e.g. when
> implementing a custom image reader that should be completely
> decoupled from the image format details).
>
> Furthermore FileImageInputStream2 could be easily extended to deal
> with URLs.The 'read from memory' case is always a problem, with any
> implementation, as memory is not aware of any resource name - this
> case would always require custom code at application level.
>
> Finally, concatenating the two streams sometimes could be not an
> option, if the size of the former stream is unknown.
>
> --
> Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> http://www.tidalwave.it/blog - Fabrizio.Giudici@tidalwave.it
> mobile: +39 348.150.6941 - fax: +39 027.005.105.36
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Robert Engels

I think there is one critical point that is being missed (and that is easy
to do since we are talking about several different options and it can get
confusing).

If you have a image format that relies on multiple resources, you need to be
able to determine both what resources are needed, and where/how to read the
resources. In SOME cases you may be able to infer the additional resources
(and how to read them) given one or more resources, but this may not be the
case (looking at the underlying stream, detecting it is a FileInputStream,
etc.)

MultiImageInput is a REPLACEMENT for an ImageInputStream. There is no static
method ImageIO.read(Object), but using the other ImageIO framework methods
will find the proper reader based upon the 'input' object.

Just write an ImageReader that only needs to understand how to read from a
MultiImageInput.

Then create an ImageReaderSpi (and associated ImageReader) that knows how to
use a MultiImageInput (returns true from canDecodeInput(Object)), and can
create a MultiImageInput from the provided source object (if it is not a
MultiImageInput).

-----Original Message-----
From: Nidel, Mike [mailto:mike.nidel@lmco.com]
Sent: Friday, June 02, 2006 1:59 PM
To: interest@jai-imageio.dev.java.net
Subject: RE: [JAI-IMAGEIO] Getting filename to codec?

you're right, your implementation doesn't require any different handling in
the calling program, and this is an advantage.

Of course, you are vulnerable to the possibility that some other
ImageInputStreamSpi could be called first, and your ImageReader will not
receive a FileImageInputStream. But this is a problem with the API, in my
opinion. The way we avoid it is by avoiding the ImageInputStreamSpi
altogether.

If our software is used as an API/library, we provide some higher-level
factories to essentially do the same thing that the ImageInputStreamSpi does
without the drawbacks. Of course, we can't just drop our ImageReader plugins
into another application and have them work, at least not the ones that
require finding extra files. You need the extra software layer to provide
that for our library.

Mike

> -----Original Message-----
> From: Fabrizio Giudici [mailto:Fabrizio.Giudici@tidalwave.it]
> Sent: Friday, June 02, 2006 2:43 PM
> To: interest@jai-imageio.dev.java.net
> Subject: Re: [JAI-IMAGEIO] Getting filename to codec?
>
>
> I'm reading with interest this thread to find out if I can improve my
> design in jrawio.
>
> But I'd point out that - unless, and it's probable - I'm missing
> something, the alternate solutions provided require for dealing with
> custom code in the application, creating a wrapper around ImageIO,
> while my "FileImageInputStream2" approach lies entirely within the
> implementation of the Image I/O Spi.
>
> Sometimes specialized code could be ok, others not (e.g. when
> implementing a custom image reader that should be completely decoupled
> from the image format details).
>
> Furthermore FileImageInputStream2 could be easily extended to deal
> with URLs.The 'read from memory' case is always a problem, with any
> implementation, as memory is not aware of any resource name - this
> case would always require custom code at application level.
>
> Finally, concatenating the two streams sometimes could be not an
> option, if the size of the former stream is unknown.
>
> --
> Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave
> s.a.s. - "We make Java work. Everywhere."
> http://www.tidalwave.it/blog - Fabrizio.Giudici@tidalwave.it
> mobile: +39 348.150.6941 - fax: +39 027.005.105.36
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
> For additional commands, e-mail:
> interest-help@jai-imageio.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net