<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>
<html xmlns="http://www.w3.org/1999/xhtml";><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</head><body style="font-family: arial,helvetica,sans-serif; font-size:
13pt"><p>Hi Ede,</p><p>Thank you for the overview of the main raster
classes.</p><p>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.</p><p>Michaël</p><p> </p><blockquote type="cite"><p
style="font-family: Arial,Helvetica,sans-serif; font-size: 14px;"><strong
style="color: #000;">envoyé :</strong> <span style="color: #666;">26 novembre
2020 à 14:43</span><br><strong style="color: #000;">de :</strong> <span
style="color: #666;">ede <e...@users.sourceforge.net></span><br><strong
style="color: #000;">à :</strong> <span style="color: #666;">"[jump-pilot:bugs]
" <5...@bugs.jump-pilot.p.re.sourceforge.net></span><br><strong style="color:
#000;">objet :</strong> <span style="color: #666;">[jump-pilot:bugs] Re: #515
Raster display in low memory situation</span></p><br><div
class="ox-dfdd4e2a86-markdown_content"><p>On 11/25/2020 13:15, michael michaud
wrote:</p><blockquote><p>Even after several bug fixes, I still not have a good
understanding of the image framework.<br> 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.</p></blockquote><p>for
ReferencedImage(imagery.geoimg) it's pretty easy, albeit the class naming is
maybe not optimal.<br> GeoRaster - takes care of loading, provides a
RenderedOp<br> GeoReferencedRaster - adds Referencing, vulgo Envelop<br>
GeoImage - renders/paints a given GeoRaster (implements the whole rendering
chain, the only place that caches)</p><p>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.</p><blockquote><p>It would deserve a page on the
wiki if it does not exists so that we know precisely what we are taking
about.</p></blockquote><p>probably would. just shying away creating
documentation that'll probably become obsolete fast because nobody maintains
it. am pretty wikilazy myself ;(</p><blockquote><p>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 ?</p></blockquote><p>idea is to cache the visualization on disk
instead in memory hence saving some.</p><blockquote><p>Or is it about saving
the symbolization step ?</p></blockquote><p>if symbolization is the creation of
the visualization of the values in the monoband, then yes.</p><blockquote><p>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.</p></blockquote><p>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.</p><blockquote><p>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.</p></blockquote><p>it's what ReferencedImage(imagery.geoimg) does
except for whole image overviews.</p><blockquote><p>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.</p></blockquote><p>agreed. that's why i suggest the caching on disk
approach.</p><p>..ede</p><hr><p><strong> <a class="ox-dfdd4e2a86-alink"
href="https://sourceforge.net/p/jump-pilot/bugs/515/";>[bugs:#515]</a> Raster
display in low memory situation</strong></p><p><strong>Status:</strong>
open<br> <strong>Milestone:</strong> OJ_future<br> <strong>Created:</strong>
Tue Nov 24, 2020 10:20 PM UTC by michael michaud<br> <strong>Last
Updated:</strong> Wed Nov 25, 2020 12:15 PM UTC<br> <strong>Owner:</strong>
michael michaud</p><p>This ticket follows ticket #513.<br> After correction of
the bug reported by Roberto Rossi in #513 two problems are left over.<br>
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.<br>
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.</p><hr><p>Sent from
sourceforge.net because you indicated interest in <a
href="https://sourceforge.net/p/jump-pilot/bugs/515/";>https://sourceforge.net/p/jump-pilot/bugs/515/</a></p><p>To
unsubscribe from further messages, please visit <a
href="https://sourceforge.net/auth/subscriptions/";>https://sourceforge.net/auth/subscriptions/</a></p></div><div>
<br></div></blockquote></body></html>
---
** [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
