ImageJ (https://imagej.nih.gov/ij/) manages in a very good way rasters, including reading values and styling. Just a note to check an alternative source for the future
Il giorno lun 30 nov 2020 alle ore 11:52 <edgar.sol...@web.de> ha scritto: > 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 >
_______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
