Hi,
By reading but not testing yet all this sounds great. You did not especially
mention but I suppose that if tiff file is tiled the reader can access the
right tiles directly. However, based on this sentence:
"If the whole image is needed for display, it is obviously fully loaded in
memory"
you have not considered methods about utilizing overview layer or pyramid
layers. I do not know if there is any standardized way for supporting them but
quite common is to support the GDAL way to create overviews with the gdaladdo
utility http://www.gdal.org/gdaladdo.html. At reading the drivers are reading
image data from the overview level which has the closest smaller pixel size
than the one needed for the output.
-Jukka Rahkonen-
________________________________
alberto.deluca wrote:
Dear all,
we kept working on the raster handling capabilities of OJ. We focused on your
indications about keeping the raster file-based, and loading when possible only
the part of the image that is needed for display.
The RasterImageLayer class was deeply reworked, and we've separated the display
data from the actual cell data. Therefore now the raster files are read as
BufferedImage (we've removed the PlanarImages, that implied some
memory-consuming conversions between classes), and the cells data are read only
on request when the getRasterData() method is called.
There are a couple of new methods to read a single cell values,
getCellValue(int, int), getCellValue(double, double), and
getCellValue(Coordinate).
There is a new class, RasterImageIO, where we've grouped all the methods needed
to load the different raster formats. In particular, the part dedicate to TIFF
images allows to load only the part of the TIFF file that is needed for
display. To do so, we had to write some code to read in an efficient fashion
the TIFF tags, because the existing XTIFFDirectory and XTIFFField classes are
slow (at least in my tests) when reading large raster. Therefore there is a new
class, TIFFUtils, that does this job, even if limited to the tags we were
interested in.
If only a part of the image is needed for display, only that part is loaded
into memory. If the whole image is needed for display, it is obviously fully
loaded in memory, and in this case there will be no more reading operations on
it (unless the actual cell data are requested).
The RasterImageIO class includes also a writeImage() method, that writes
GeoTIFF files (with TFW, just in case).
There is a new Metadata class to store basic information about rasters:
envelope, columns and rows, cell size, no data value, some statistics (min,
max, average, standard deviation). These values are calculated on the entire
image, also when only a portion of the image is loaded and displayed.
Since we've made so many changes, we didn't feel like pushing them up to SVN.
Instead, we've made a new openjump.jar for you to try, modifying the source
code downloaded from SVN (you can find the jar
here<https://www.dropbox.com/s/f2xi7j307jzxwqm/OpenJUMP.jar?dl=0>). You can
replace it to the OpenJUMP.jar of the latest stable release, provided you also
replace the default-plugins.xml with this
one<https://www.dropbox.com/s/equnejnc1c8agcq/default-plugins.xml?dl=0> (that
accounts for the macro plugin).
Instead, if you want to check the source code, here
<https://www.dropbox.com/s/sxqo96rh8jtan0k/Modified.7z?dl=0> you can find all
the modified classes.
We've made some test to check against memory leaks, and it appears that all the
references to images are released when an image is removed from the project.
We've not completed the debugging yet, before spending more time on it we'd
like to know what's your opinion.
Let us know
Alberto
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
