Hi, I can’t say if other programs use also the wrong byte array encoding. If GDAL tolerates such encoding it could be because GDAL supports so many formats which are defining nodata in different ways. Internally GDAL seems to convert nodata by default into double, but sometimes it must use for example Int64. I think that at least OpenJUMP should use the right encoding when writing. For me it would be OK if nodata of type byte array would be skipped or even if the image could not be opened with OpenJUMP especially if it is possible to fix the image with gdal_translate or maybe just fix the metadata with gdal_edit.
If I understand right the 42113 is an array of ASCII strings but because GeoTIFF supports only one nodata value that is applied to all bands then the array should have only one value. And in that case the example from the OGC GeoTIFF standard http://docs.opengeospatial.org/is/19-008r4/19-008r4.html with a pipe character and null could be followed even the nodata tag is a private tag: “Example of a GeoAscii tag containing only one string: "NAD27 / UTM zone 11N|{NULL}" (where {NULL} is the ASCII character of code 0)” The older specification http://geotiff.maptools.org/spec/geotiff2.4.html left it to the client to convert the final pipe into {NULL} “A baseline GeoTIFF-reader must check for and convert the final "|" pipe character of a key back into a NULL before returning it to the client software.” I guess that they may create {NULL}{NULL} when they meet a new type of nodata tag but that is probably OK. I wonder how well OpenJUMP supports this kind of nodata values that I found from the GDAL codebase: -32768 nan NaN -3.402823466385289e+38 1.701410009187828e+38 1e+20 -Jukka- Lähettäjä: Michaud Michael <m.michael.mich...@orange.fr> Lähetetty: torstai 5. toukokuuta 2022 10.00 Vastaanottaja: OpenJump develop and use <jump-pilot-devel@lists.sourceforge.net> Aihe: [JPP-Devel] NoData value management in Rasters 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
