Hi Saul,
thanks for the comments, some more inline
On Monday 02 February 2009 17:32:28 Saul Farber wrote:
> Gabriel,
>
> I tried a bit of stronger JAI integration early in my ArcSDE rasters
> implementation, but ran into some hurdles around tile-ordering (tiles from
> ArcSDE came in a weird order that wasn't the same order that tiles in JAI
> were drawn, causing repeated SeQueries rather than one long streamed
> SeQuery).
I understand. My approach is as follows
- we pick up the correct pyramid level before issueing the request just as its
being done now, then instruct JAI to request always the image at index 0. this
allows a single query to carry over all the tiles for the chosen level, and
jai sees it as a single raw image.
Then our custom ImageInputStream, wrapped by a RawImageInputStream
with the appropriate image layout should do the trick.
So far I've been able to read any combination of pixel format and number of
bands. Writing the result to a tiff image gdalinfo reports all the bands.
Testing up to seven bands.
The problem is with the image layout, cause with more than one band the image
produced is a mix up of tiles from the different bands, quite psycodelic. I'm
under the impression that the correct combination of interleave type for the
SeQuery and jai's image layout should do the trick though.
Does that make any sense?
>
> That said, I think all the problems that I ran into could definitely be
> worked around by someone smarter/more JAI knowledgeable than I, and I think
> that JAI has the potential to provide lots of good support-infrastructure
> that we've needed to write ourselves in the ArcSDE module. If your spike
> is going well and you're getting good performance out of it, I think it's
> probably a good idea to go the JAI route.
>
> I'll defer to the other JAI experts on the list for better technical
> opinions on JAI, but I'm interested to hear/see more about the JAI+ArcSDE
> spike's progress.
>
I of course didn't run any perf comparison yet. I'm more interested in being
able to support any combination of pixel type and number of bands in a
straightforward way by now. Yet, I don't foresee any considerable perf
regression, since the way the ImageInputStream works is by calling
SeRasterTile.getTileData() which returns the raw byte[] containing both the
data packaged as bytes for the given pixel format plus the bitmask data.
Question for you Saul: it seems if a tile is completely blank then it may
contain no data at all, right? which may explain some missing tiles when I
zoom in to some of the newly supported formats (16bit-u I think).
Cheers,
Gabriel
> --saul
>
> Gabriel Roldan wrote:
> Hi guys,
> As you know I'm working on
> improving ArcSDE gce support by adding support for extra formats.
> So, the way it works is
> that we have a so called ArcSDERasterReader (extending ImageReader) for
> each pixel format. Each one reads tile data in the appropriate pixel
> packaging (float, byte, ushort, etc) into a BufferedImage's
> WritableRaster.
> But since there are a bunch
> of formats and this is leading to quite some duplication and, the gtopo
> and geotiff plugins inspired me to experiment over the weekend with
> implementing a JAI's ImageInputStream for arcsde rasters.
> The spike seems to be going
> quite well, and, in my understanding, this would lead to out of the box
> support of any of the formats and number of bands combinations, right?
> What I'm not so sure of and
> may be you can better tell me is what the other advantages of going
> through JAI ImageRead operation, using a RawImageInputStream and
> RawImageReaderSpi producing a RenderedOp would be over building a plain
> BufferedImage (with the appropriate Sample and Color models for a given
> format).
> One of them, if I'm getting
> it right, is that we can give JAI any number of bands regardless of
> which of them are used as the visible bands, which is useful for band
> selection operations and other jai related stuff?
> Cheers,
> Gabriel
> --
> Gabriel Roldan
> OpenGeo -
> http://www.opengeo.org
--
Gabriel Roldan
OpenGeo - http://www.opengeo.org
------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
