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 jump-pilot-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/jump-pilot/bugs/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
