On 7/16/05, Martin Desruisseaux <martin.desruisseaux@anonymised.com> wrote:
I'm glad to see interest in GridCoverage :).
About GridCoverage2D: Simone rightly point out that GridCoverage2D
expects a RenderedImage at construction time. However, because of JAI
deferred execution mechanism, a RenderedImage should take a negligible
amount of memory until the pixel values are first requested. This will
not work with java.awt.image.BufferedImage, but should work with most
images produced by JAI. The fact that GridCoverage2D wraps RenderedImage
in a PlanarImage implementation should not trigs pixel computation ahead
of time.
Because BufferedImage do not supports deferred execution, we should
banish all methods from javax.imageio returning a BufferedImage. For
example we should banish ImageReader.read(...) and use
ImageReader.readAsRenderedImage(...) instead. Or yet better, use
JAI.create("ImageRead", ...) operation from JAI Image I/O extension (yet
an other download after the JAI's one), which should read pixel values
only when a tile is first requested.
We shoud always use either the ImageRead operation or direclty an
ImageReader from ImageIO, since this way we can read metadata to have
an idea about what we are dealing for (compression, overviews, tiling,
thumbnails, dimensions, etc...) and defer pixel reading.
I agree with Bryce that RenderableImage do not fits naturally with
GridCoverage. GridCoverage (no matter which implementation) has know
size with know resolution and know grid geometry. RenderableImage has no
know geometry; it can be an abstract mathematical formulae producing
values at any resolution. The natural matches in my understanding are:
RenderedImage --> wrapped in two-dimensional GridCoverage
RenderableImage --> wrapped in two-dimensional Coverage
I fully agree.
A Coverage2D implementation for RenderableImage may be a valuable
addition to Geotools.
For big images (and I agree with Simone that JPEG2000 is probably the
way to go),
Either JPEG2K or TIFF. Actually I am almost done with a small utility
to generate a multipage tiled tiff, which means a single tiff file
which is tiled on disk and which holds the original image plus a
certain number of overviews. More on this later....
I would rather try to make JAI's deferred execution work
with tiled, pyramidal images. I believe it should work. If it doesn't,
lets try to figure out where the pixels are computed ahead of time. If
the cause is on our side, lets try to fix that.
There are a couple of ways for handling pyramids and decimation aka
subsampling in JAI, let me summarise them for whom are not familiar
with them:
1>ImageMIPMap
This is a RenderedImage subclass which can provide a certain number of
overviews given a RenderedImage (the image at higher resolution) a
downsampler and an interpolation. It basically gives you on the fly
different levels of overview using the downsampler and the
interpolation provided. The resulting images are RenderedImage.
2>ImagePyramid it is a subclass of the previous one and works pretty
the same way. The main difference it allows you to traverse the
pyramid bidirectionally which means as you downsample you cal also
upsample.
-->Annotation.
These two classes are very suitable with file formats that do not
support multiple images in a single file (I realy hate having
overviews in different files, I used that with the MIT OrthoSErver and
it sucks [the approach, not the OrthoServer!]) because they force us
to build the pyramid on the fly. Deferred Execution helps with
processing only pixels we need when they are needed.
<--
3>We can use directly the ImageReader since it allows the user to
perform decimation at reading time using subsampling factors (well we
can do much more than that like cropping, progrsive loading,
offsetting, layout changing...).
-->Annotation.
Not so sure if in our architecture this is useful even if it is very powerful.
<--
4>MultiResolutionRenderableImage, it is a RenderableImage which needs
to be feed with a
certain number of RenderedImages at progressive ower resolution and
which is able to generate rendering at different scales.
-->Annotation.
This is very suitable when you have a file format that support
overviews. You can take advantage of the deferred execution and load
only the level of detail you need when you relly need it. This would
be useful especially with giant images (up to gb) for which having
prebuilt overvies would bereally useful.
<--
By the way, I did not mention this, but I am also working on Large
Dataset support, which means large number of small images doing
mosaicizing+tiling+pyramids, but this is still more on my mind than on
my pc.
simone giannecchini a écrit :
> I think that the specifications on Coverages are somehow incomplete
> since they do not really take into account implemntation of 3d and 4D
> coverages.
Yes. Current GeoAPI is based on a legacy OGC implementation wich should
be replaced by ISO 19123. The great new is that I had a look on ISO
19123, and I believe that the transition can be done smootly.
getCoordinateReferenceSystem and evaluate methods should stay there for
example.
I put a first (partial) set of ISO 19123 interfaces there:
http://cvs.sourceforge.net/viewcvs.py/geoapi/pending/org/opengis/coverage/
I'll take a look at it, I am pretty interested.
The ISO 19123's Coverage interface may looks quite different from the
one we currently have, but actually it is not that much different. It
contains much more additions than conflicts (for example I like a lot
their "evaluateInverse" method, even if it is going to be a lot of work
to implement). It has only one "evaluate" method, but it is compatible
with our current "evaluate" methods (both in spirit and in the method
signature) and doesn't prevent us to put all our current "evaluate"
methods in addition, as more efficient ways to get the same information.
Now about the work that need to be done with GridCoverageExchange: this
one is quite incomplete too. I hope to get more experience with geotools
implementation in order to suggest changes in GeoAPI interfaces. Anyway,
my proposal is:
1) Create a javax.imageio.metadata.IIOMetadataFormat implementation
matching the format described in "GML in JPEG2000" OGC specification.
We already talked about this, I like it a lot but for the moment we
stil ned to focus on older formats. It would be good to use it as an
internal format for all the georeferenced images, instead of having
png, gif, tiff, jpeg, geotiff, + world file+ prj files, etc.. etc..
2) Implement all plugins as javax.imageio.ImageReader implementation,
and ask them to express their metadata (CRS, envelope, etc.) into
an javax.imageio.metadata.IIOMetadata object. Which should be as
much independant as possible from GridCoverage at this stage.
Me and Alessio have been checking this approach, but for the moment I
have no valid argumentation in favour or against it. Need more time to
check it out.
3) Write a single GridCoverageExchange or Format implementation. Given
an arbitrary javax.imageio.ImageReader, this generic implementation
should get the image data using JAI.create("ImageRead", ...)
operation and get the metadata in the format described above using
the RenderedImage.getProperty("JAI.ImageMetadata") or
RenderedImage.getProperty("JAI.StreamMetadata") call. Those metadata
shall be used for creating the appropriate CoordinateReferenceSystem
or Envelope objects. This way, we should be able to keep raster
plugins close to independant from GridCoverage (we basically need
to add to existing ImageReader the capability to express metadata as
IIOMetadata object in the format described by "GML in JPEG2000").
What do you think?
Martin.
Same as above, very interesting but I might see some troubles. Let's
look at an example. I have a GribCoverageReader I wrote last month, it
uses JGrib to read te grib file. Following your approach I should use
JGriB from Jai and ImageIO and I do not know if that would lower
increase the level of complexity (which usualy means problems...) of
what we do.
I checked carefully the AbstractGridCoverageReader you are
implementing, it would be coeherent with this approach since it forces
us to rely on jai to read coverages, and I somehow like that idea.
Anyway it is interesting that we thought about this approach at the
same time without having talked about it, it means that it is suposed
to be good, therefore I will check it out deeper.
My impellent goal now is to coordinate with Martin (and whoever wants
to help) in order to find a way to suport overview (both prebuilt and
on-the-fly) within the current architecture of the GridCoverages since
we need that for the WMS.
I will send an email with some suggestions next week.
Ciao a tutti.
Simone.
)
) therefore I hope things will come out better than in the