Hi, I agree with Michael that ij this step we can consider a good result to have a better RasterImageLayer framework for this three reasons: it if faster in opening images, it requires less ram, it can open more TIF versions than before. Possibly we can postpone, as Michael suggests, to rewrite the code to make it simpler. One idea could be to extend Referenced image framework to styling (only monoband raster) and give up with RasterImageLayer , even if this will require more and more job to rewrite plugins. Or Ede proposals which seems to be more interesting. We can wait after migration to Openjump V.2 I want to really thank Ede and Michael to all of the efforts, work, ideas and discussion. All your contribution that surely many user will benefit in their work or course activities. Thanks again Giuseppe -- Inviato da myMail per Android domenica, 29 novembre 2020, 06:35PM +01:00 da michael michaud via Jump-pilot-devel jump-pilot-devel@lists.sourceforge.net :
> > >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 < e...@users.sourceforge.net> >>à : " [jump-pilot:bugs] " < 5...@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/ >> >---------------------------------------------------------------------- >[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
_______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
