Stefan,
thank you for your plug-in, I'm looking forth to have a look at it. And
about trasparency, I believe that something can be done with the
RasterImageLayer class, I'll give it a try...
I'll be away for 2 weeks, so I hope I'll be able to get back to this
stuff when I'm back.
Alberto
On 05/08/2010 19:05, Stefan Steiniger wrote:
Hei Alberto,
i-loading small images:
interesting proposal, need to look at it when I have time. (still
hoping for the weekend)
ii-coloring:
the coloring is similar to what I did based on Paul Plouy's code - so
I guess this is the way to go. I zip all classes and attach them. It
contains also a color editor from pirol, but I didn't use it yet.
iii-Transparency for no-data is also an open issue - don't know if
that info is somewhere stored with RasterImageLayer. In Sextante it is...
cheers,
stefan
Alberto De Luca wrote:
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
------------------------------------------------------------------------
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
