Skip to main content

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

4 replies [Last post]
Anonymous

i think we are much closer to agreeing than it may seem.
the details are mostly semantic.

Your ImageStreamFinder is basically exactly our StreamFactory
interface. (In some cases we might want to read things that
aren't images using this framework, so I didn't call it
an ImageStreamFactory.)

Your description of the MultiImageInput is very similar to
our SourceID -- it wraps the StreamFactory and the name
of the resource, basically the MultiImageInput(ImageStreamFinder,
String)
constructor.

We have a factory (actually a factory builder, since I
called it StreamFactory) that identifies the right
StreamFactory for a resource name. This is actually not
highly coupled, since it uses the chain of responsibility
pattern to determine which StreamFactory instance to use,
and looks up the instances using the SPI mechanism. Nothing
in the API requires knowledge of either formats or sources
of data, so no coupling there. The abstraction of the
StreamFactory allows the ImageReader to get to "any other
files it might need" by providing a way of opening an
arbitrary resource, based on the instance of StreamFactory
that is used.

Are you still proposing using the ImageInputStreamSpi?
The one problem I see with MultiImageInput being an
ImageInputStream is that it can't be fully created by
the ImageIO.createImageInputStream() method. This is because
the ImageInputStreamSpi only has a
createImageInputStreamInstance(Object)
method -- it can't take arbitrarily many arguments. The
result is that you'd have to wrap the ImageStreamFinder
and the resource basename in another object -- which is
exactly our implementation.

This is really in part a problem with the ImageInputStreamSpi
as I said before -- how would your proposed implementation know
whether to use an ImageStreamFinder or not? Say, for example,
when opening a JPEG. You either have to always provide it, or
have format knowledge to determine when to provide it. We've
chosen to keep that format knowledge in the ImageReader by
giving it access to an abstraction for creating streams.

Of course there are dependencies between the files in an
image fileset, but the key thing is to abstract those
dependencies so that most of your software doesn't have to
know about them. If your ImageReader finds out that it just
can't locate or access a resource it needs, then it would
fail just like any other ImageReader would fail if it discovered
the image file were truncated or something.

About concatenated streams -- now not only does your
MultiImageInput implementation has to know where all the files
are in order to provide the logically-concatenated stream, but
as you say, your ImageReader now has to know the details of
which file logically comes at which point. What do you gain by
logically concatenating the stream in this way? This seems
like an unnecessary complication, and it doesn't avoid the
corruption of the data you mentioned before, or solve any of
the core problems with having one image in multiple files.
But your ImageReader has to know the details of the format
of the fileset, regardless of how it finds each file, so why
not constrain the knowledge of what files are needed to the
lowest possible level?

Another reason why you might require storing a single image
across filesystems is if your images are larger than the
original format allows. For example, the NITF specification
allows for images so large that they must span multiple files,
but they are displayed as a single image. Yeah, that's painful.

I'm guessing nobody else finds this interesting by this point, so
if you want to continue the discussion we can take it offline.

cheers,

Mike

> -----Original Message-----
> From: Robert Engels [mailto:rengels@ix.netcom.com]
> Sent: Friday, June 02, 2006 1:15 PM
> To: interest@jai-imageio.dev.java.net
> Subject: RE: [JAI-IMAGEIO] Getting filename to codec?
>
>
> I think you are missing some things:
>
> As far as the concatenated stream, you don't need to read all
> of the files at once. You know where the files start and
> maintain pointers (and seek) to read the needed data
> depending on which file (or portion thereof) is needed. The
> ImageReader would need to know the internal format though.
>
> But more importantly, there are natural dependencies that you
> cannot avoid. If an "image" is made up of multiple files, and
> each file is may or may not be valid on its own, then you
> have a built-in dependency between the files. Since you have
> dependency between the "files", you now are a functional
> dependency - given one file you must be able to find the
> other related files. This may or may not be possible given
> the other features of the OS, protocols, etc. Since you have
> this functional dependency it must be handled. The simplest
> (and I think best) solution is using MultiImageInput. It can
> do "whatever" is needed to find the other files and create
> "input streams" from them.
>
> I would create the following interface:
>
> interface ImageStreamFinder {
> ImageInputStream open(String basename,String requested);
> }
>
> Then MultiImageInput has the following ctors
>
> MultiImageInput(File baseFile); // convenience method
> MultiImageInput(URL baseUrl); // convenience method
> MultiImageInput(ImageStreamFinder isf,String basename);
>
> It is trivial to create ImageStreamFinder implementations for
> both Files and Urls. It would also be trivial to create a
> ImageStreamFinder for concatenated byte[], given the lengths
> of each array. You could also create ones that read different
> BLOBs from a db based upon the name., etc.
>
> Then just create your ImageReaderSpi that creates your
> ImageReader when the input is a MultiImageInput.
>
> You could also create a factory to register different
> ImageStreamFinder implementations, but because of the highly
> coupled nature I don't see the value.
>
> If the files that make up the "whole image" are themselves
> standalone images, the ImageReader could becomes trivial,
> since you can create an ImageReader for each standard
> ImageInputStream returned by the ImageStreamFinder.
>

---------------------------------------------------------------------
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.
Andrey Kuznetsov

> Not at all!! I'm following the discussion with *great* interest, as we
> have similar problems with separate files constituting a single image.
> I simply haven't got around to thinking about it in depth yet. So,
> please continue!
>
> It would be nice if we could hammer out some semi-standardized
> method for doing this, which could be (compatibly) incoporated into
> IIO at the next revision opportunity... but that works on its own in
> the meantime.

This problem comes because File does not give you right abstraction level.
For another project I wrote an interface which was a bit more flexible as
File.

It look like this:

public interface VFile {
String getName();
String getDisplayName();
void setDisplayName(String displayName) throws IOException;
String getParent();
VFile getParentFile();
String getAbsolutePath();
boolean isDirectory();
boolean isHidden();
void setHidden(boolean hidden) throws IOException;
String [] list();
String [] list(VFilenameFilter filter);
VFile get(String s); //counterpart of new File(File parent, String name)
boolean exists();
int getPos();
void setPos(int pos) throws IOException;
void create() throws IOException;
boolean rename(String name);
boolean delete();
boolean mkdir();
boolean mkdirs();
boolean rmdir(boolean rf);
long lastModified();

InputStream getInputStream() throws FileNotFoundException;
OutputStream getOutputStream() throws IOException;
}

It looks mostly like File, but have some additional methods like
get(String), getInputStream() and getOutputStream().
So instead of writing new FileInputStream(f) or new FileOutputStream(f) you
just call f.getInputStream();
And instead of File f = new File(f0, name) you write (much more flexible)
VFile f = f0.get(name);

At this point you just need to implement VFile and VFileFactory
which knows how to create desired VFile object.

Note I don't want to say that exactly this interface should be used.
It is just a possible direction where could we go.

Andrey

--
http://uio.imagero.com Unified I/O for Java
http://reader.imagero.com Java image reader
http://jgui.imagero.com Java GUI components and utilities

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

Robert Engels

I think abstracting file is overkill. I think the would much rather see
something like MultiSourceImage, and it might have some implementation that
uses a Vfile. I think it is far more flexible in many cases, and makes
"better" OO sense.

interface MultiSourceImage {
String[] getListOfSources();
ImageInputStream getInputSteam(String source);
}

public MultiFileImage implements MultiSourceImage {
public MultiFileImage(File primary);
...
}

public MultiUrlImage implements MultiSourceImage {
public MultiUrlImage(URL primary);
...
}

public MultiArrayImage implements MultiSourceImage {
public MultiArrayImage(String[] names,byte[][] data);
...
}

-----Original Message-----
From: Andrey Kuznetsov [mailto:ak@imagero.com]
Sent: Monday, June 05, 2006 6:55 PM
To: interest@jai-imageio.dev.java.net
Subject: Re: [JAI-IMAGEIO] Getting filename to codec?

> Not at all!! I'm following the discussion with *great* interest, as
> we have similar problems with separate files constituting a single image.
> I simply haven't got around to thinking about it in depth yet. So,
> please continue!
>
> It would be nice if we could hammer out some semi-standardized method
> for doing this, which could be (compatibly) incoporated into IIO at
> the next revision opportunity... but that works on its own in the
> meantime.

This problem comes because File does not give you right abstraction level.
For another project I wrote an interface which was a bit more flexible as
File.

It look like this:

public interface VFile {
String getName();
String getDisplayName();
void setDisplayName(String displayName) throws IOException;
String getParent();
VFile getParentFile();
String getAbsolutePath();
boolean isDirectory();
boolean isHidden();
void setHidden(boolean hidden) throws IOException;
String [] list();
String [] list(VFilenameFilter filter);
VFile get(String s); //counterpart of new File(File parent, String name)
boolean exists();
int getPos();
void setPos(int pos) throws IOException;
void create() throws IOException;
boolean rename(String name);
boolean delete();
boolean mkdir();
boolean mkdirs();
boolean rmdir(boolean rf);
long lastModified();

InputStream getInputStream() throws FileNotFoundException;
OutputStream getOutputStream() throws IOException; }

It looks mostly like File, but have some additional methods like
get(String), getInputStream() and getOutputStream().
So instead of writing new FileInputStream(f) or new FileOutputStream(f) you
just call f.getInputStream(); And instead of File f = new File(f0, name) you
write (much more flexible) VFile f = f0.get(name);

At this point you just need to implement VFile and VFileFactory which knows
how to create desired VFile object.

Note I don't want to say that exactly this interface should be used.
It is just a possible direction where could we go.

Andrey

--
http://uio.imagero.com Unified I/O for Java http://reader.imagero.com Java
image reader http://jgui.imagero.com Java GUI components and utilities

---------------------------------------------------------------------
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

Bob Deen

> I'm guessing nobody else finds this interesting by this point, so
> if you want to continue the discussion we can take it offline.

Not at all!! I'm following the discussion with *great* interest, as we
have similar problems with separate files constituting a single image.
I simply haven't got around to thinking about it in depth yet. So,
please continue!

It would be nice if we could hammer out some semi-standardized
method for doing this, which could be (compatibly) incoporated into
IIO at the next revision opportunity... but that works on its own in
the meantime.

-Bob

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

Brian Burkhalter

Excellent idea!

On Mon, 5 Jun 2006, Bob Deen wrote:

> It would be nice if we could hammer out some semi-standardized
> method for doing this, which could be (compatibly) incoporated into
> IIO at the next revision opportunity... but that works on its own in
> the meantime.

----------------
Brian Burkhalter
Java Media, Imaging, and Graphics
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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