> 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? > Makes sense to me. That was the part that I had trouble with, so if you've got it working with a single SeQuery, that should solve the performance problems I was seeing.
> > > > > 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 > Yeah, the performance issues I had were around the creation of multiple SeQuerys for one image request, so if you're past that step then you should be good. As for the completely blank tiles...yes, I believe the size of the response to "SeRasterTile.getPixelData()" will be a zero-length array if/when the tile doesn't contain any data. getNumPixels() should also return zero, I believe. --saul ------------------------------------------------------------------------------ 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
