the bug is already tagged OJ_future so no hurry there. we still got 5 open OJ 1.16 bugs[1] which look like they might be solved already.. ede
[1] https://t1p.de/oix8 On 11/30/2020 10:40, giuseppe.ar...@gmail.com wrote: > 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 > <mailto: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 >> <mailto:e...@users.sourceforge.net>> >> *à :* "[jump-pilot:bugs] " <5...@bugs.jump-pilot.p.re.sourceforge.net >> <mailto: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 >> >> >> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ >> >> *<https://sourceforge.net/p/jump-pilot/bugs/515/>[bugs:#515] >> <https://sourceforge.net/p/jump-pilot/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] <https://sourceforge.net/p/jump-pilot/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 > <mailto: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 > <mailto: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 > _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
