Simone Giannecchini a écrit :
>> [... about "if (image.getTileHeight() <= image.getHeight())" ...]
>
> That is done because there are many formats that use stripes as an
> alternative to tiles, an example is tiff. A stripe can be a
> performance black hole, I have seen stripes as large as 20.000 columns
> x 8 rows. If you just want to see a chunk of 512x512 think about how
> much data you have to load!!!
Good point. I will commit the code together with a comment explaining that then
:).
>> [... about setting tile size with "Format" operation ...]
>
> I think it is a bit too much to recompute the tile size at each
> operation for various reasons. Once you inject a raster into a
> rendering chain in JAI if that raster is tiled its tile size will be
> retained as much as possible through the chain, which means that at
> each node the tile grid of the output raster will be similar of the
> one of the source raster.
I agree with that. The algorithm in the old coverage framework was:
* If the image is untiled, then compute a tile size and pass this
information to the
operation as an ImageLayout hint. I know for sure that it work for many
JAI operations
like "GradientMagnitude": I read a Sea Surface Temperature image in PNG
format as one
big tile, then I apply directly a "GradientMagnitude" operation on it with
a proper
ImageLayout hint. The "GradientMagnitude" output is really a tiled image,
and I can
see the tiles appears one after the other at rendering time (using
J2D-renderer).
* If the image is already tiled, then ImageUtilities.getRenderingHints(...)
do not
provide any ImageLayout hint.
This means that if we invoke ImageUtilities.getRenderingHints(...) before each
image operation, a
tile size is suggested (without the need for a separated "Format" operation)
only if the image was
not already tiled. Otherwise, the previous tile size is preserved. The net
result is the same than
"compute tile size once and then retain it", but more robust (I think) since it
can retile an image
if some operation untiled it (e.g. org.geotools.image.jai.Hysteresis, which can
only be applied to a
whole image - the hysteresis algorithm used is quite hard to apply on tiles)
and avoid the cost of
caching tiles for the "Format" operation.
> I add also that it would be good to add the
> possibility to control the cache at each step of a coverage op but
> this is something that we need to do to all the operation in
> gridprocessing package (it is a capability that right now is missing,
> if I am right :-) ).
Right, I think that this capability is not provided right now (will need to
check however, since
GridCoverageProcessor nevertheless allow user-specified hints I think. But it
may be too hard to use
right now).
Thanks for yours work and comments,
Martin.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
