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