Inconsistent imageio-ext versions

[mukoki]

Imageio-ext packaging is inconsistent in last release (OpenJUMP-Portable-20220620-r5116[8fb08d0]) : openjump-core includes imageio-ext 1.4.5 (except for tiff where it is 1.3.11) openjump-plus includes imageio-ext 1.1.13

[edeso]

will have a look

[edeso]

just checked and can't replicate. latest snapshots use imageio-ext-1.4.5 for everything but the tiff reader. see below

$ ls OpenJUMP-20220702-r5118\[dcf2c16\]-*/lib/ext/imageio-ext/
'OpenJUMP-20220702-r5118[dcf2c16]-CORE/lib/ext/imageio-ext/':
imageio-ext-gdalframework-1.4.5.jar  imageio-ext-tiff-1.1.13.jar
imageio-ext-geocore-1.4.5.jar        imageio-ext-utilities-1.4.5.jar
imageio-ext-streams-1.4.5.jar

'OpenJUMP-20220702-r5118[dcf2c16]-PLUS/lib/ext/imageio-ext/':
commons-lang-2.4.jar                     imageio-ext-gdalmrsid-1.4.5.jar
imageio-ext-arcgrid-1.4.5.jar            imageio-ext-gdalmrsidjp2-1.4.5.jar
imageio-ext-gdalarcbinarygrid-1.4.5.jar  imageio-ext-gdalnitf-1.4.5.jar
imageio-ext-gdalarcgrid-1.4.5.jar        imageio-ext-gdalvrt-1.4.5.jar
imageio-ext-gdalbsb-1.4.5.jar            imageio-ext-geocore-1.4.5.jar
imageio-ext-gdaldoq1-1.4.5.jar           imageio-ext-imagereadmt-1.4.5.jar
imageio-ext-gdaldoq2-1.4.5.jar           imageio-ext-kakadu-1.4.5.jar
imageio-ext-gdaldted-1.4.5.jar           imageio-ext-kakadujni-5.2.6.jar
imageio-ext-gdalecw-1.4.5.jar            imageio-ext-nitf-1.4.5.jar
imageio-ext-gdalehdr-1.4.5.jar           imageio-ext-png-1.4.5.jar
imageio-ext-gdalenvihdr-1.4.5.jar        imageio-ext-streams-1.4.5.jar
imageio-ext-gdalenvisat-1.4.5.jar        imageio-ext-tiff-1.1.13.jar
imageio-ext-gdalerdasimg-1.4.5.jar       imageio-ext-turbojpeg-1.4.5.jar
imageio-ext-gdalframework-1.4.5.jar      imageio-ext-utilities-1.4.5.jar
imageio-ext-gdalgeotiff-1.4.5.jar        nitf-bindings-2.7-r1269.jar
imageio-ext-gdalidrisi-1.4.5.jar         pngj-2.0.1.jar
imageio-ext-gdaljpeg-1.4.5.jar           turbojpeg-wrapper-1.2.1.5.jar
imageio-ext-gdalkakadujp2-1.4.5.jar

[mukoki]

My bad, my statement was errroneous. I will close the ticket. Just wonder if we really need to stick to 1.1.13 for geotiff.

[edeso]

Just wonder if we really need to stick to 1.1.13 for geotiff.

it is needed for Sextante Raster as some files failed to load with newer imageoio-ext versions. you can find the ticket/ml conversation about it in the archives and play with it. quick search found this (with example file) https://sourceforge.net/p/jump-pilot/bugs/498/

generally the whole Sextante Loader is a big mess and needs cleaning up anyway. so i'd rather make it use Commons-Image as it reads the whole file to memory to create a visual representation. but i don't find the time.

[mukoki]

Just tested the test-file from the ticket.For me, mdt25a fails with 1.1.13, 1.3.2 and 1.4.5 (with imageio-ext driver).The error with 1.1.13 is different from the others though.I could read the file with commons-imaging.I cannot make any definitive conclusion from this very single/simple test, but I'm not sure that sticking to 1.1.13 can really save this file.For the image framework, I agree there is still much to do. I have started some cleaning/debugging in the heatmap branch (which was originally only about styling), but I did not find time to go further until now.I wanted to do more with imageio-ext because it is two steps ahead of commons-imaging for geodata (bigtiff and COG), but as a library, I probably prefer commons-imaging. If you want to go further with commons imaging, I know there is a library for bigtiff (https://github.com/siiinc/commons-imaging-bigtiff/tree/master/src/main/java/org/apache/commons/imaging), but it is probably hasardeous to adopt it before its integration in the main repo.Michaëlenvoyé : 3 juillet 2022 à 16:20de : edeso @.>à : openjump-gis/openjump @.>cc : Michaël Michaud @.>, State change @.>objet : Re: [openjump-gis/openjump] Inconsistent imageio-ext versions (Issue #53) Just wonder if we really need to stick to 1.1.13 for geotiff.it is needed for Sextante Raster as some files failed to load with newer imageoio-ext versions. you can find the ticket/ml conversation about it in the archives and play with it. quick search found this (with example file) https://sourceforge.net/p/jump-pilot/bugs/498/generally the whole Sextante Loader is a big mess and needs cleaning up anyway. so i'd rather make it use Commons-Image as it reads the whole file to memory to create a visual representation. but i don't find the time.—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you modified the open/close state.Message ID: @.***>

[edeso]

If you want to go further with commons imaging, I know there is a library for bigtiff (https://github.com/siiinc/commons-imaging-bigtiff/tree/master/src/main/java/org/apache/commons/imaging), but it is probably hasardeous to adopt it before its integration in the main repo.

not to be mistaken. i'm merely talking about handling Sextante-Raster (Mono/Multiband-Files). for Referenced Images i'm willing to support pretty much anything but it is a whole different scenario as we are talking actual image rendering by library and not reading and interpreting raster data into a visual representation.

when going with the Apache Imaging guys over the issues we had with loading raster data files they showed me how it is supposed to be used and i implemented a test in

https://github.com/openjump-gis/openjump/blob/HEAD/src/com/vividsolutions/jump/workbench/imagery/graphic/CommonsTIFFImage.java#L63-L99

just to try it out.

took the time to find where i got the gist from. it was this ticket https://issues.apache.org/jira/browse/IMAGING-267 with example code from Gary Lucas linked in the last post.