|
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
| 