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
