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. 



---

** [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 10:34 AM 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

Reply via email to