Stefan, thank you for you time. About your doubts:
> - you change finally the image loaded. This means that the data/image > delivered to sextante will contain the scaled values. > When you need to pass over the data/image to sextante, you could always retrieve the actual raster data. The rescaling of the data is done for display purposes only. Sure, you couldn't instantiate an OpenJUMPSextanteRasterLayer from a RasterImageLayer (like you do in your class CreatePolygonGridFromSelectedImageLayerPlugIn.java), you'd need to use a different constructor and a couple of other methods to set image properties and data. But still it would be feasible. Or am I missing the point here? > - you assume that the data loaded have only one band, so you need only > one array. > You're right. But we could replace the single array with a series of arrays, each of them storing the cell values of a single band. It should be feasible. I'd give it a try to see if it can be done. What do you reckon? > Mhm.. not sure what to do, maybe we modify the RasterImage method such > way that images/data with one band will always be GridFloat files? > But then we still would need to ensure that Sextante will get the > correct values? Or we change the Sextante interface-classes. I actually > talked to Victor a few weeks earlier, and it may be the better option to > have the interface classes maintained by us? [which means more work... ;)] > Don't know, I'd prefer to spend some more time on the topic and try to find a more general solution keeping the sextante classes untouched... Thanks again Alberto > > Alberto De Luca schrieb: > >> Stefan, >> >> thank you for your (not so late) answer, you told me you'd be away, so >> no problem at all! >> >> I had a look at Erwan's plug in: very interesting work! Briefly, if I >> got it right: he wrote a RasterLayer class that extends the jump Layer >> class. He then uses some geotools classes to read the ASCII grid file, >> and the GT GridCoverage2D class to store the raster values and >> properties. This is a useful class, because it stores the rescaled >> raster values as a PlanarImage (that can be passed to OJ for display), >> but also the actual cell values (that can be retrieved anytime using the >> appropriate method). >> >> On the other side, it seems to me that the OJ RasterImageLayer class >> stores only the image information. But I think it shouldn't be difficult >> to add a field (and a getter) to handle the raster cell data. I gave it >> a try (only for FLT raster file handling, which I know best): >> - I created a double[][] to store the raster values; >> - I created a getter to get the whole array (this clearly could be >> improved by adding direct access to single cell values); >> >> When an FLT is loaded: >> - the array is filled right after the raster is read; >> - the values are rescaled and passed over for visualization (as a b/w >> stretched image); >> >> When the actual values are needed, they can be accessed via the getter. >> This could be useful also when the image is redrawn, because it would >> avoid the need to reload the raster form scratch. >> >> What do you think? Does this make any sense? >> >> You can find attached to this e-mail: >> - inside the OJClasess archive the AddRasterImageLayerWizard, the >> RasterImageLayer and the SelectRasterImageFilesPanel class that I >> modified, plus the GridFloat class that actually reads the flt file. >> - inside the Flt_plugin archive: a small plug in that creates a button >> tool to inspect raster cell values (jar + src). You can try it out by >> loading an flt raster (I included one in the archive) as a "Sextante >> Raster Image", it should display in b/w. You can then use the tool to >> inspect its cell values. I didn't do much testing though... >> >> Alberto >> >> >> On 07/07/2010 05:41, Stefan Steiniger wrote: >> >>> Hei Alberto, >>> >>> late answer but something just came to my mind. >>> There was an ESRI Grid plugin by Erwan Bocher for OpenJUMP that allowed >>> to display different colors for a DEM. That should be something we want >>> - right? >>> >>> I think the code is here: >>> http://geosysin.iict.ch/irstv-trac/browser/openjump/plugin/gridCoverage/org/reso/openJump/raster?rev=96 >>> >>> >>> can you look into it? >>> >>> Not sure what would be needed to make it work with OpenJUMP and the >>> Sextante Raster. But we can do changes to the core here... >>> >>> stefan >>> >>> PS: I was last week away - so thats why I didn't respond earlier; need >>> to catch up with emails now. >>> >>> Alberto De Luca schrieb: >>> >>> >>>> Larry and Steven, >>>> >>>> sorry for bothering you, I know you're both busy... I had a deeper look >>>> at the RasterImageLayer class. Apparently there is a scaling function >>>> there (as Stefan pointed out), but for what I can understand, the image >>>> is read, then rescaled, then added to a Layerable. This means that the >>>> Layerable stores the already scaled cell values and, if the actual cell >>>> values are needed, the image needs to be reloaded. >>>> >>>> I don't see how this model can be tweaked to have on one side the cell >>>> values stored in memory and on the other a Layerable that can be >>>> rendered properly. What do you reckon? Please tell me I'm wrong. >>>> >>>> Thanks >>>> Alberto >>>> >>>> On 29/06/2010 16:32, Larry Becker wrote: >>>> >>>> >>>>> Hi Alberto, >>>>> >>>>> I did take a look at the render architecture to see how it might be >>>>> done, but unfortunately I don't have a lot of time right now to help >>>>> with this effort so any advice I have is only a guess, but I think it >>>>> might have to happen in the image layer's paint method. >>>>> >>>>> Larry >>>>> >>>>> On Tue, Jun 29, 2010 at 2:01 AM, Alberto De Luca >>>>> <i...@geomaticaeambiente.it<mailto:i...@geomaticaeambiente.it>> wrote: >>>>> >>>>> Stefan and Larry, >>>>> >>>>> thank you for your help. Unfortunately I'm not an expert either, >>>>> so I'm >>>>> really not sure about what to do. I kind of like Larry's approach >>>>> (but I >>>>> need to think about it to see if I can work something out of >>>>> it). I'll >>>>> have a deeper look at the pirol classes too... >>>>> >>>>> Alberto >>>>> >>>>> On 28/06/2010 21:49, Stefan Steiniger wrote: >>>>> > actually.. wasn't there a scaling function somewehere in the >>>>> pirol classes? >>>>> > so the place to correct is in those? >>>>> > >>>>> > Alberto De Luca schrieb: >>>>> > >>>>> >> Dear OJ developers, >>>>> >> >>>>> >> I was working on the Sextante classes, trying to enhance >>>>> raster >>>>> support >>>>> >> and visualization capabilities. Having a powerful raster >>>>> management is >>>>> >> important so we can port to OJ all the raster plugins we >>>>> developed for >>>>> >> the OJ-derived AdB-ToolBox (we exchanged some emails on the >>>>> topic a >>>>> >> while ago). >>>>> >> >>>>> >> So, as a first attempt, I tried to add ESRI FLT raster >>>>> support, >>>>> adding >>>>> >> some lines of code to the RasterImageLayer class. I am here >>>>> facing a >>>>> >> dilemma though. >>>>> >> >>>>> >> The loadImage method returns a planarimage, which is then >>>>> displayed on >>>>> >> the screen. >>>>> >> If I read the FLT file into a TiledImage whose SampleModel is >>>>> >> DataBuffer.TYPE_FLOAT (to match the data model of the FLT >>>>> file) and >>>>> >> return it to be displayed, OJ loads it ok, but the raster >>>>> displayed is >>>>> >> completely blank. I know it's there because I can export its >>>>> envelope >>>>> >> and I can read cell values (using the >>>>> OpenJUMPSextanteRasterLayer >>>>> >> class), values that exactly match the values stored in the FLT >>>>> file. >>>>> >> If after creating the TiledImage I rescale it into a 0-255 >>>>> range >>>>> >> PlanarImage, I can display it ok (as a grayscale for example) >>>>> but then >>>>> >> when I read the cell values from the raster layer, they're >>>>> clearly >>>>> >> different from the original FLT values. >>>>> >> >>>>> >> My question is: is there a way to have a correct visualization >>>>> while >>>>> >> maintaining access to the actual cell values? In >>>>> >> www.lac.inpe.br/JIPCookbook/2200-display-surrogate.jsp >>>>> <http://www.lac.inpe.br/JIPCookbook/2200-display-surrogate.jsp> >>>>> >> >>>>> <http://www.lac.inpe.br/JIPCookbook/2200-display-surrogate.jsp> >>>>> they >>>>> >> suggest the use of the javax.media.jai.iterator.RandomIter >>>>> class to >>>>> >> access cell values after the image has been rescaled. Would >>>>> this be >>>>> >> appropriate in OJ? >>>>> >> >>>>> >> In the attached GridFloat.java you can find the code used to >>>>> read the >>>>> >> FLT grid (see the readGrid and the getPlanarImage methods). >>>>> Also >>>>> >> attached you can find my modified RasterImageLayer class >>>>> (see in >>>>> >> particular the loadImage method). >>>>> >> >>>>> >> Please consider I'm not a good programmer, so I might just >>>>> be on a >>>>> >> completely wrong track... >>>>> >> Thanks >>>>> >> Alberto >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >> >>>>> >> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >> This SF.net email is sponsored by Sprint >>>>> >> What will you do first with EVO, the first 4G phone? >>>>> >> Visit sprint.com/first<http://sprint.com/first> -- >>>>> http://p.sf.net/sfu/sprint-com-first >>>>> >> >>>>> >> >>>>> >> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >> >>>>> >> _______________________________________________ >>>>> >> Jump-pilot-devel mailing list >>>>> >> Jump-pilot-devel@lists.sourceforge.net >>>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>>> >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>>> >> >>>>> > >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> > This SF.net email is sponsored by Sprint >>>>> > What will you do first with EVO, the first 4G phone? >>>>> > Visit sprint.com/first<http://sprint.com/first> -- >>>>> http://p.sf.net/sfu/sprint-com-first >>>>> > _______________________________________________ >>>>> > Jump-pilot-devel mailing list >>>>> > Jump-pilot-devel@lists.sourceforge.net >>>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>>> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>>> > >>>>> > >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> This SF.net email is sponsored by Sprint >>>>> What will you do first with EVO, the first 4G phone? >>>>> Visit sprint.com/first<http://sprint.com/first> -- >>>>> http://p.sf.net/sfu/sprint-com-first >>>>> _______________________________________________ >>>>> Jump-pilot-devel mailing list >>>>> Jump-pilot-devel@lists.sourceforge.net >>>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> This SF.net email is sponsored by Sprint >>>>> What will you do first with EVO, the first 4G phone? >>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>>>> >>>>> >>>>> _______________________________________________ >>>>> Jump-pilot-devel mailing list >>>>> Jump-pilot-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------ >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> This SF.net email is sponsored by Sprint >>>> What will you do first with EVO, the first 4G phone? >>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Jump-pilot-devel mailing list >>>> Jump-pilot-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> >>> ------------------------------------------------------------------------------ >>> >>> This SF.net email is sponsored by Sprint >>> What will you do first with EVO, the first 4G phone? >>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> >>> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
