#515 Raster display in low memory situation

[michael michaud]

This ticket follows ticket #513.
After correction of the bug reported by Roberto Rossi in #513 two problems are left over.
Images are not loaded permanently in memory, but when they must be shown, RasterImageLayer evaluates if they fit in memory before trying to display. To evaluate if the image fits in memory it multiplies the number of pixels by 4 bytes (usual pixel deep for a color image). This evaluation should be more precise and take into account 1 bit images (b&w) or 64 bits float values.
Also in the case a black and white image is not displayed, the little symbol in the LayerNamePanel stay colored instead of turning to gray.

[ede]

maybe it'd make sense to simplify the framework to make it more memory efficient?

as i see it, currently two things happen

1. for visualization a virtual image is created representing the (elevation or such) values in the raster
2. the image is still accessed to retrieve the actual values to do calculations by plugins

problematic seems to be step 1 - visualization, as we currently either
a) generate a bufferedimage i memory and keep it (memory-hog)
or
b) recreate the visualization every time (cpu-hog but memory efficient).

suggestion
how about we save the generated in -memory-image in a temp folder (lossless, say compressed TIF) and use ReferencedImage henceforth for visualization, which with it's complete renderchain is the most memory efficient way we currently got.

[michael michaud]

Even after several bug fixes, I still not have a good understanding of the image framework.
To be able to imagine improvements, I would need a more precise idea about when the image is read from disk and when/where/what is cached.
It would deserve a page on the wiki if it does not exists so that we know precisely what we are taking about.

Not sure I understand your proposition. Can you explain what would be the benefit of reading a lossless compressed tiff image from a temp folder compared to reading it from the original file ?
Or is it about saving the symbolization step ?
I have no idea if transforming rough data to the displayed image is cpu-intensive, but I think reading from disk is more time consuming.
Also it seems that the cached displayed image is just the part of the image we want to display. It seems difficult to read/write on disk every time the envelope of the visible part of the image changes.
There are also other ways to optimize like using tiled images or subsampled overviews (at least in geotiff). I don't think we are ready to take advantage of it.

[ede]

On 11/25/2020 13:15, michael michaud wrote:

Even after several bug fixes, I still not have a good understanding of the image framework.
To be able to imagine improvements, I would need a more precise idea about when the image is read from disk and when/where/what is cached.

for ReferencedImage(imagery.geoimg) it's pretty easy, albeit the class naming is maybe not optimal.
GeoRaster - takes care of loading, provides a RenderedOp
GeoReferencedRaster - adds Referencing, vulgo Envelop
GeoImage - renders/paints a given GeoRaster (implements the whole rendering chain, the only place that caches)

the Sextante Raster Image framework is a convoluted mess, not sure what's going on there. just contributed it reusing GeoReferencedRaster for a way to enforce the tif loader and reusing the same instance for performance. my current guess is it creates a buffered image once and caches that in memory.

It would deserve a page on the wiki if it does not exists so that we know precisely what we are taking about.

probably would. just shying away creating documentation that'll probably become obsolete fast because nobody maintains it. am pretty wikilazy myself ;(

Not sure I understand your proposition. Can you explain what would be the benefit of reading a lossless compressed tiff image from a temp folder compared to reading it from the original file ?

idea is to cache the visualization on disk instead in memory hence saving some.

Or is it about saving the symbolization step ?

if symbolization is the creation of the visualization of the values in the monoband, then yes.

I have no idea if transforming rough data to the displayed image is cpu-intensive, but I think reading from disk is more time consuming.

probably not, creation of the the visualization involves two times iterating over all pixels of the whole image, one go to find the lower/upper limit, second time to create the visualization based on that information.

Also it seems that the cached displayed image is just the part of the image we want to display. It seems difficult to read/write on disk every time the envelope of the visible part of the image changes.

it's what ReferencedImage(imagery.geoimg) does except for whole image overviews.

There are also other ways to optimize like using tiled images or subsampled overviews (at least in geotiff). I don't think we are ready to take advantage of it.

agreed. that's why i suggest the caching on disk approach.

..ede

[michael michaud]

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

Hi Ede,

Thank you for the overview of the main raster classes.

I don't know if your proposition of saving the displayed image to disk would improve performance/memory usage. It would need tests. Anyway, let's postpone this to v2. From my point of view, making raster code more robust and simpler is more important, but making it faster or less greedy in memory would also be nice.

Michaël

 

envoyé : 26 novembre 2020 à 14:43
de : ede <edso@users.sourceforge.net>
à : "[jump-pilot:bugs] " <515@bugs.jump-pilot.p.re.sourceforge.net>
objet : [jump-pilot:bugs] Re: #515 Raster display in low memory situation

On 11/25/2020 13:15, michael michaud wrote:

Even after several bug fixes, I still not have a good understanding of the image framework.
To be able to imagine improvements, I would need a more precise idea about when the image is read from disk and when/where/what is cached.

for ReferencedImage(imagery.geoimg) it's pretty easy, albeit the class naming is maybe not optimal.
GeoRaster - takes care of loading, provides a RenderedOp
GeoReferencedRaster - adds Referencing, vulgo Envelop
GeoImage - renders/paints a given GeoRaster (implements the whole rendering chain, the only place that caches)

the Sextante Raster Image framework is a convoluted mess, not sure what's going on there. just contributed it reusing GeoReferencedRaster for a way to enforce the tif loader and reusing the same instance for performance. my current guess is it creates a buffered image once and caches that in memory.

It would deserve a page on the wiki if it does not exists so that we know precisely what we are taking about.

probably would. just shying away creating documentation that'll probably become obsolete fast because nobody maintains it. am pretty wikilazy myself ;(

Not sure I understand your proposition. Can you explain what would be the benefit of reading a lossless compressed tiff image from a temp folder compared to reading it from the original file ?

idea is to cache the visualization on disk instead in memory hence saving some.

Or is it about saving the symbolization step ?

if symbolization is the creation of the visualization of the values in the monoband, then yes.

I have no idea if transforming rough data to the displayed image is cpu-intensive, but I think reading from disk is more time consuming.

probably not, creation of the the visualization involves two times iterating over all pixels of the whole image, one go to find the lower/upper limit, second time to create the visualization based on that information.

Also it seems that the cached displayed image is just the part of the image we want to display. It seems difficult to read/write on disk every time the envelope of the visible part of the image changes.

it's what ReferencedImage(imagery.geoimg) does except for whole image overviews.

There are also other ways to optimize like using tiled images or subsampled overviews (at least in geotiff). I don't think we are ready to take advantage of it.

agreed. that's why i suggest the caching on disk approach.

..ede

---

[bugs:#515] Raster display in low memory situation

Status: open
Milestone: OJ_future
Created: Tue Nov 24, 2020 10:20 PM UTC by michael michaud
Last Updated: Wed Nov 25, 2020 12:15 PM UTC
Owner: michael michaud

This ticket follows ticket #513.
After correction of the bug reported by Roberto Rossi in #513 two problems are left over.
Images are not loaded permanently in memory, but when they must be shown, RasterImageLayer evaluates if they fit in memory before trying to display. To evaluate if the image fits in memory it multiplies the number of pixels by 4 bytes (usual pixel deep for a color image). This evaluation should be more precise and take into account 1 bit images (b&w) or 64 bits float values.
Also in the case a black and white image is not displayed, the little symbol in the LayerNamePanel stay colored instead of turning to gray.

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/jump-pilot/bugs/515/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/