Stefan, thank you for your quick reply. A couple of things about raster display:
1) when panning, only small images are reloaded. To avoid this, in RasterImageLayer.java we could just call #setNeedToKeepImage(true) when the following condition is true (around line 300):
this.origImageWidth * this.origImageHeight) < RasterImageLayer.getMaxPixelsForFastDisplayMode() // faster display (uses more RAM) for small images
This way, we'd speed up the display of small images without the risk of finishing memory up.
2) The parameter maxPixelsForFastDisplayMode has a fixed value of 250000. Maybe we could make this value dependent on available memory, so the concept of "small image" won't be absolute but dependent on system resources.
With respect to raster symbology, I'd be interested to see your work. I've done a bit of work on raster symbology myself, it's just preliminary work, but I'd like to share it with you to see if it can be useful. I'm attaching here just a simple plug-in (source and jar in the rar archive) that allows to chose from a list of color models and repaints the selected raster consequently using a stretch renderer. There is only one color model available, and the color values are hardcoded. So you just select a raster layer from the layer list, start the plug-in from the tools menu, pick a color model and hit ok. The only problem is that you need to zoom in or out to see the changes in raster symbology! There used to be a method in the RasterImageLayer class, #forceRepaint that did the refresh, but I can't find it anymore... Plus I need to figure out how to show nodata cells as transparent. If you find this approach acceptable, I'd like to extend the tool so to allow the user to create and edit color models, both for stretched renderers and for class renderers. The models would then be saved as ascii filed (xml maybe).
Alberto On 04/08/2010 18:57, Stefan Steiniger wrote:
Hei Alberto, I hope to integrate your changes towards the weekend - if that works for you. And yes, I noticed too that the images are (most often) read for very pan or zoom operation to save memory. I discovered this when I did the coloring of the image and when I did a pan all the colors where gone - so I need to set layer.setNeedToKeepImage(true); and then it is not reloaded from file. However, so the easy fix may be to just set this option right after loading the file in #loadImage(). But then we might run into memory problems if several images are loaded... need to think about it. but if you have suggestions let me know. stefan Alberto De Luca wrote:Stefan, I had a look at your work, it seems great. To carry it a bit further I wrote a new class (GridAscii) to add reading capabilities for the ESRI ASCII GRID format. Consequently, I modified the following classes: AddRasterImageLayerWizard.java RasterImageLayer.java SelectRasterImageFilePanel.java I also did a bit of clean-up to the GridFloat class: following your work, I replaced the double[][] array with a Raster object. So you can now read the raster directly from GridFloat (and GridAscii as well) without need of any conversion. You can find all the java files attached to this email. It seems to me that the RasterImageLayer class makes a very conservative use of memory, favouring disk access to memory consumption. I was doing some tests using a 2000x2000 ASCII GRID file (roughly 35 MB on disk) and noticed that it is read 2 times from disk during the loading phase (because it's big, smaller images are read just once). Plus, if I want to retrieve the pixel values later, the image is read again from disk. This can slow things down quite a bit, do you think we could come up with a faster solution? Thanks a bunch Alberto On 03/08/2010 19:04, Stefan Steiniger wrote:Hei Alberto, I did some changes to the model yesterday night. Instead of a double array I used "Raster". I adde getRasterData() to the RasterImageLayer class. Subsequently I also changed the retrieval method in Sextante. I.e. instead of m_Raster = layer.getImage().getData(); i use now m_Raster = layer.getRasterData(); I have done only some preliminary tests and most of the stuff worked as far as I can assess (i.e. I fixed broken functions). However more testing is probably needed. stefan Alberto De Luca wrote: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------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel------------------------------------------------------------------------ ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ------------------------------------------------------------------------ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
TestRasterSymbologyPlugIn.rar
Description: Binary data
------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm
_______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
