Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Stefan Steiniger]

Hei Alberto,

traveling again/still/long... so not sure when I will get back to you on 
that.

stefan

Alberto De Luca schrieb:
>  Stefan,
> 
> I worked a bit on transparency for nodata pixels. It should be now 
> possible to load Ascii and Flt Grids with nodata values represented as 
> transparent pixels. I might be able to do the same for tiff files, but I 
> still need to work a bit on it.
> 
> I modified 3 classes, you can find the source code attached to this 
> email. In RasterImageLayer.java I marked the changes with an [ADL] 
> comment, so you can check what I have done. I also modified 
> GridAscii.java and GridFloat.java, so now nodata pixels are stored as 
> Float.NaN values.
> 
> Let me know what you think
> Alberto
> 
> On 10/08/2010 21:38, Stefan Steiniger wrote:
>> so, I think I could fix the problem.
>> What I do now is a complete reload of the image when getRasterData() is
>> called (but not replacing the image4display). This way I get sure that
>> always the rasterdata are delivered to Sextante which seemed to be the
>> problem.
>>
>> While testing I noticed that when I load an ascii grid and calculate the
>> contours of that grid with sextante [own plugin that accesses the
>> sextante function], then the delivered contours are displaced in the
>> location (don't fit with the raster anymore). Not sure where this is to
>> be attributed to?
>>
>> But when I calculate contours for KernelDensity raster (tif) that I
>> created earlier out of points, then the contours seem to be in the right
>> place. So maybe its some referencing info
>>
>> Alberto, could you check that?
>>
>> I hope tomorrows nightly build is fine with all the raster stuff
>>
>> stefan
>>
>> Stefan Steiniger wrote:
>>> Hei Alberto,
>>>
>>> ok.. I have a problem here.
>>> I needed to revert some changes (dynamic loading etc).
>>> I am not sure what is going on, but if I do now some calculations I
>>> don't get proper reference to the rasters/layerable.
>>>
>>> So sometimes I have no reference and in other instance after the
>>> processing is done and results are returned... those results are
>>> shifted. It even happens with the convert to polygons function.
>>> Interestingly this faulty behaviour is visible when I open the raster
>>> color editor. if it contains no further elements, just the name, then
>>> something is wrong.
>>>
>>> However, if I use from the raster layer context menu the function:
>>> "Export Envelope as geometry", then I get the correct reference back.
>>>
>>> not sure what happens here...
>>>
>>> stefan
>>>
>>> Stefan Steiniger wrote:
 me again,

 I don't have
 javax.swing.GroupLayout

 where is that from? I have only GridBagLayout from java.awt.*

 stefan

 Stefan Steiniger wrote:
> I actually just see that the Properties dialog of the raster layer 
> has a
> transparency checkbox
>
> stefan
>
> Stefan Steiniger wrote:
>> Hei Alberto,
>>
>> I changed the RasterImageLayer class to allow for dynamic loading.
>> I haven't tested fully if it works as expected. Can you have a look.
>> With respect to this I chose now some arbitrary values for
>> maxPixelsForFastDisplayMode
>> so we can change it...
>>
>> I have also added the changes to read ASCII grids.
>>
>> Also if you want I can give you write access to our SVN. I think you
>> will do the right thing... ;)
>>
>> next I will look at the coloring.
>> Have a good 2 weeks (holidays I assume ;).
>>
>> stefan
>>
>> Alberto De Luca wrote:
> --
>  
>
> 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
>
>
 --
  

 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


>>> --
>>>  
>>>
>>> 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/jum

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Alberto De Luca]

 Stefan,

- with regards to the ascii grid displacement problem, there was 
actually an error in reading the header values (when handling the corner 
vs. centre origin position). I attach to this email 2 new java files 
that should be ok (the flt grid code had the same problem). When I have 
time (sic!) I might try to reorganize the two now independent classes in 
one abstract class and 2 subclasses. Let me know if things are ok now. 
If not, could you please send me the ascii grid that's giving you 
problems, so I can test on it?


- incidentally: I've noticed that when a grid file is read by the 
AddRasterImageLayerWizard class, if a world file is not found the method 
#getGeoReferencing will generate one for you. This could be dangerous 
because next time you open the raster, the georeferencing information 
are read from the world file and not from the raster. So if the file 
(say an ASCII GRID) has been modified in terms of georeferencing, it 
will be loaded in the wrong position. What do you reckon?


- the javax.swing.GroupLayout is a standard feature in Java SE 6 
(http://download-llnw.oracle.com/javase/6/docs/api/javax/swing/GroupLayout.html). 
I can rewrite the plug in to avoid SE 6 classes if you want. Let me know.


I'm going back to raster symbology as soon as I can. In the meantime, 
thank you for your help.


Alberto


On 10/08/2010 21:38, Stefan Steiniger wrote:

so, I think I could fix the problem.
What I do now is a complete reload of the image when getRasterData() is
called (but not replacing the image4display). This way I get sure that
always the rasterdata are delivered to Sextante which seemed to be the
problem.

While testing I noticed that when I load an ascii grid and calculate the
contours of that grid with sextante [own plugin that accesses the
sextante function], then the delivered contours are displaced in the
location (don't fit with the raster anymore). Not sure where this is to
be attributed to?

But when I calculate contours for KernelDensity raster (tif) that I
created earlier out of points, then the contours seem to be in the right
place. So maybe its some referencing info

Alberto, could you check that?

I hope tomorrows nightly build is fine with all the raster stuff

stefan

Stefan Steiniger wrote:

Hei Alberto,

ok.. I have a problem here.
I needed to revert some changes (dynamic loading etc).
I am not sure what is going on, but if I do now some calculations I
don't get proper reference to the rasters/layerable.

So sometimes I have no reference and in other instance after the
processing is done and results are returned... those results are
shifted. It even happens with the convert to polygons function.
Interestingly this faulty behaviour is visible when I open the raster
color editor. if it contains no further elements, just the name, then
something is wrong.

However, if I use from the raster layer context menu the function:
"Export Envelope as geometry", then I get the correct reference back.

not sure what happens here...

stefan

Stefan Steiniger wrote:

me again,

I don't have
javax.swing.GroupLayout

where is that from? I have only GridBagLayout from java.awt.*

stefan

Stefan Steiniger wrote:

I actually just see that the Properties dialog of the raster layer has a
transparency checkbox

stefan

Stefan Steiniger wrote:

Hei Alberto,

I changed the RasterImageLayer class to allow for dynamic loading.
I haven't tested fully if it works as expected. Can you have a look.
With respect to this I chose now some arbitrary values for
maxPixelsForFastDisplayMode
so we can change it...

I have also added the changes to read ASCII grids.

Also if you want I can give you write access to our SVN. I think you
will do the right thing... ;)

next I will look at the coloring.
Have a good 2 weeks (holidays I assume ;).

stefan

Alberto De Luca wrote:

--
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



--
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



--
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@l

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Stefan Steiniger]

so, I think I could fix the problem.
What I do now is a complete reload of the image when getRasterData() is 
called (but not replacing the image4display). This way I get sure that 
always the rasterdata are delivered to Sextante which seemed to be the 
problem.

While testing I noticed that when I load an ascii grid and calculate the 
contours of that grid with sextante [own plugin that accesses the 
sextante function], then the delivered contours are displaced in the 
location (don't fit with the raster anymore). Not sure where this is to 
be attributed to?

But when I calculate contours for KernelDensity raster (tif) that I 
created earlier out of points, then the contours seem to be in the right 
place. So maybe its some referencing info

Alberto, could you check that?

I hope tomorrows nightly build is fine with all the raster stuff

stefan

Stefan Steiniger wrote:
> Hei Alberto,
> 
> ok.. I have a problem here.
> I needed to revert some changes (dynamic loading etc).
> I am not sure what is going on, but if I do now some calculations I 
> don't get proper reference to the rasters/layerable.
> 
> So sometimes I have no reference and in other instance after the 
> processing is done and results are returned... those results are 
> shifted. It even happens with the convert to polygons function.
> Interestingly this faulty behaviour is visible when I open the raster 
> color editor. if it contains no further elements, just the name, then 
> something is wrong.
> 
> However, if I use from the raster layer context menu the function: 
> "Export Envelope as geometry", then I get the correct reference back.
> 
> not sure what happens here...
> 
> stefan
> 
> Stefan Steiniger wrote:
>> me again,
>>
>> I don't have
>>  javax.swing.GroupLayout
>>
>> where is that from? I have only GridBagLayout from java.awt.*
>>
>> stefan
>>
>> Stefan Steiniger wrote:
>>> I actually just see that the Properties dialog of the raster layer has a 
>>> transparency checkbox
>>>
>>> stefan
>>>
>>> Stefan Steiniger wrote:
 Hei Alberto,

 I changed the RasterImageLayer class to allow for dynamic loading.
 I haven't tested fully if it works as expected. Can you have a look.
 With respect to this I chose now some arbitrary values for
maxPixelsForFastDisplayMode
 so we can change it...

 I have also added the changes to read ASCII grids.

 Also if you want I can give you write access to our SVN. I think you 
 will do the right thing... ;)

 next I will look at the coloring.
 Have a good 2 weeks (holidays I assume ;).

 stefan

 Alberto De Luca wrote:
>>> --
>>> 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
>>>
>>>
>> --
>> 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
>>
>>
> 
> --
> 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
> 
> 

--
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

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Stefan Steiniger]

Hei Alberto,

ok.. I have a problem here.
I needed to revert some changes (dynamic loading etc).
I am not sure what is going on, but if I do now some calculations I 
don't get proper reference to the rasters/layerable.

So sometimes I have no reference and in other instance after the 
processing is done and results are returned... those results are 
shifted. It even happens with the convert to polygons function.
Interestingly this faulty behaviour is visible when I open the raster 
color editor. if it contains no further elements, just the name, then 
something is wrong.

However, if I use from the raster layer context menu the function: 
"Export Envelope as geometry", then I get the correct reference back.

not sure what happens here...

stefan

Stefan Steiniger wrote:
> me again,
> 
> I don't have
>   javax.swing.GroupLayout
> 
> where is that from? I have only GridBagLayout from java.awt.*
> 
> stefan
> 
> Stefan Steiniger wrote:
>> I actually just see that the Properties dialog of the raster layer has a 
>> transparency checkbox
>>
>> stefan
>>
>> Stefan Steiniger wrote:
>>> Hei Alberto,
>>>
>>> I changed the RasterImageLayer class to allow for dynamic loading.
>>> I haven't tested fully if it works as expected. Can you have a look.
>>> With respect to this I chose now some arbitrary values for
>>> maxPixelsForFastDisplayMode
>>> so we can change it...
>>>
>>> I have also added the changes to read ASCII grids.
>>>
>>> Also if you want I can give you write access to our SVN. I think you 
>>> will do the right thing... ;)
>>>
>>> next I will look at the coloring.
>>> Have a good 2 weeks (holidays I assume ;).
>>>
>>> stefan
>>>
>>> Alberto De Luca wrote:
>> --
>> 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
>>
>>
> 
> --
> 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
> 
> 

--
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

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Stefan Steiniger]

me again,

I don't have
javax.swing.GroupLayout

where is that from? I have only GridBagLayout from java.awt.*

stefan

Stefan Steiniger wrote:
> I actually just see that the Properties dialog of the raster layer has a 
> transparency checkbox
> 
> stefan
> 
> Stefan Steiniger wrote:
>> Hei Alberto,
>>
>> I changed the RasterImageLayer class to allow for dynamic loading.
>> I haven't tested fully if it works as expected. Can you have a look.
>> With respect to this I chose now some arbitrary values for
>>  maxPixelsForFastDisplayMode
>> so we can change it...
>>
>> I have also added the changes to read ASCII grids.
>>
>> Also if you want I can give you write access to our SVN. I think you 
>> will do the right thing... ;)
>>
>> next I will look at the coloring.
>> Have a good 2 weeks (holidays I assume ;).
>>
>> stefan
>>
>> Alberto De Luca wrote:
> 
> --
> 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
> 
> 

--
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

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Stefan Steiniger]

I actually just see that the Properties dialog of the raster layer has a 
transparency checkbox

stefan

Stefan Steiniger wrote:
> Hei Alberto,
> 
> I changed the RasterImageLayer class to allow for dynamic loading.
> I haven't tested fully if it works as expected. Can you have a look.
> With respect to this I chose now some arbitrary values for
>   maxPixelsForFastDisplayMode
> so we can change it...
> 
> I have also added the changes to read ASCII grids.
> 
> Also if you want I can give you write access to our SVN. I think you 
> will do the right thing... ;)
> 
> next I will look at the coloring.
> Have a good 2 weeks (holidays I assume ;).
> 
> stefan
> 
> Alberto De Luca wrote:

--
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

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Stefan Steiniger]

Hei Alberto,

I changed the RasterImageLayer class to allow for dynamic loading.
I haven't tested fully if it works as expected. Can you have a look.
With respect to this I chose now some arbitrary values for
maxPixelsForFastDisplayMode
so we can change it...

I have also added the changes to read ASCII grids.

Also if you want I can give you write access to our SVN. I think you 
will do the right thing... ;)

next I will look at the coloring.
Have a good 2 weeks (holidays I assume ;).

stefan

Alberto De Luca wrote:
>   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 
>>> 25. 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 convers

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Alberto De Luca]

 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 
25. 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

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Alberto De Luca]

 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 
25. 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 b

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Stefan Steiniger]

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 develop

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Stefan Steiniger]

btw. if someone is interested I also created a function, with the help 
of several Pirol classes, to obtain a color image for a raster.

Not sure if I will port that anytime soon, as it will require quite a 
bit of clean-up to be used in OJ. But it is there (thanks to Pirol!).

stefan

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
> 

--
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

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Stefan Steiniger]

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

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Alberto De Luca]

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 c

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Stefan Steiniger]

Hei Alberto,

so i looked now into it and am not sure about some things.
- you change finally the image loaded. This means that the data/image 
delivered to sextante will contain the scaled values.
- you assume that the data loaded have only one band, so you need only 
one array.
Hence your approach works for new data/file types - but will not be 
applicable to, lets say, *.tif files if they have only one band - they 
will be treated as until now.

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... ;)]

I also programmed a couple of GUI function that read grid data and 
transform them into vector. Here it would be necessary now, that those 
functions are able to distinguish what type of layerable we have - i.e. 
is it an image or a 1d grid. Mhm.. checking the number of bands may 
actually help here?

just some thoughts... as we should try to get things right from the 
start on ;) but as you I am not an expert/developer either (and the 
other issue is speartime to look/think about this, currently)

cheers from Canada
stefan

PS: as your methods should not affect anything currently running, I will 
just commit it for now.



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
>>>

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Stefan Steiniger]

great - I will have a look at it hopefully at the weekend

stefan

Alberto De Luca wrote:
> 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
 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
  

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Stefan Steiniger]

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 
>> 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
>> 
>> >> 
>>  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
>> >>
>> >>
>> >>
>> >>
>> >>
>> ---

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Alberto De Luca]

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 
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

>> 
 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://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 <

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Larry Becker]

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  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
> >>   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://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

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Alberto De Luca]

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
>>   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://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

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Stefan Steiniger]

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 
>  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://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

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Stefan Steiniger]

Hei Alberto,

I also had the problem, but having only black images...I need to think 
about this (neither being an expert on this topic) - and I will be off 
this week until next, so no answer soon...

I wonder if Victor Olaya had an idea (or the Geotools or uDig 
people)...maybe we should ask them first?

stefan

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 
>  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://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

Re: [JPP-Devel] SextanteRasterLayer, pixel values and visualization

[Larry Becker]

Hi Alberto,

  I have had similar problems with MRSID.  It sounds like we need to define
an image depth rescaling transformation that is applied to the per-layer
window image buffer.  It doesn't sound too difficult in principle.

regards,
Larry

On Mon, Jun 28, 2010 at 10:49 AM, Alberto De Luca <
i...@geomaticaeambiente.it> wrote:

>  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 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://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