Hi Michael, Since working with raster generates a lot of derivated raster maps, the main problem is about our raster database. I am thinking about Roberto and the files he uses for his courses. Anyhow, if I am not wrong, the problem is on writing and not on reading. Right now I have not fond any problem reading these derivated-wrong-nodata rasters, generated by open jump, with Qgis, possibly due to gdal framework. I am not sure about ArcGIS. In any case, big tiff support in openjump seems to me important (from my side I was exploring another possibility to increase raster management in Openjump via ImageJ) that worth some sacrifices in my raster database, if you decide to change the code. Let us wait Roberto's answer Peppe
Il gio 5 mag 2022, 09:00 Michaud Michael <m.michael.mich...@orange.fr> ha scritto: > Hi Jumpers, > > Lately, I have worked on raster images and I wanted to support bigtiff > through imageio-ext > which is already a dependency, but I have encountered difficulties > related with the way nodata > value is currently handled in the code. Let me explain : > > While using imageio-ext library for its capability to read bigtiff, I > observe regressions (failures) > on many other images of my collection ((many of which come from Peppe, > Jukka, Rossi, gdal library, etc.). > > Here is my explanation : > - many images I have use a wrong tiff tag type (the nodata tag is coded > using a byte array instead of a ascii array. > https://www.awaresystems.be/imaging/tiff/tifftags/gdal_nodata.html > - OpenJUMP has a tiff writer writing nodata value with a byte array > instead of ascii type > RasterImageIO#writeImage() encodes TIFFTAG_GDAL_NODATA as byte array > => I suppose most of the images I have for testing have been written by > OpenJUMP's RasterImageIO :-( > > In OpenJUMP we also have a piece of code which reads the nodata tag in a > flexible way (understanding both ascii or byte array storage) > TiffTags#readMetadata > This makes the actual version quite resilient > But there are plenty of places where image metadata is read and can fail > at any time if they are > read by imageio-ext or by commons imaging which try to read nodata flag > from a string array, not a byte array. > I even think that we avoid some of these failures by eating exceptions. > > Just want to have your opinion about this situation : do you know any > other library/tool which produce > nodata value with the wrong encoding ? Is it reasonnable to just accept > that these images can't be read > anymore (for me it is OK, but maybe it is a problem for Peppe or other > users who have been working with > OpenJUMP and images for a long time). > Also it seems that other libraries like gdal/python can read these images > in a more flexible way (maybe > imageio-ext and commons imaging should be more tolerant, but it does not > depends on OpenJUMP. > > > Michaël > _______________________________________________ > 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
