On the TIFF Image I/O codecs, it may be worth to note a gotcha: all
standard image readers (PNG, JPEG, etc.) are correctly found by the
javax.imageio API, except the TIFF image reader which (at least on
Sun/Oracle Java implementation) seems to appear magically only after a
AWT window has been created.
The "Image I/O extension for JAI"
numerous image format, but many of them have bugs and doesn't seem to be
maintained anymore. Now, every standard codecs provided in the standard
Java distribution seems to be better than the JAI ones, except for the
TIFF format: the TIFF reader provided in "Image I/O extension for JAI"
seems to be better than the standard Java one.
"ImageIO-ext" is an alternative. Geotk provides also its own TIFF
reader, which happen to be faster than the other readers I have tried (I
didn't tried all of them) but doesn't support compression.
Le 28/05/12 19:04, Tom Kunicki a écrit :
On May 24, 2012, at 3:01 AM, Jon Blower wrote:
I remember some discussions on this list a while ago about reading in GeoTIFFs
through NetCDF-Java. Has anyone achieved this and if so, is code available
somewhere? Would be terrific if this is possible.
I have a GeoTIFF IOSP available on GitHub, https://github.com/tkunicki-usgs/geotiff-iosp
. It's built using maven and the dependencies will be listed in the pom.xml for the
project. While not explicitly listed in the pom, I would strongly recommend utilizing
the ImageIO-EXT tiff implementation as it has better handling for TIFF images with
"scientific" data types (bands with floating point). In fact there's a bug in
the Java ImageIO implementation reading these data types with strides. Access to a
complete EPSG database is required due to the numerous ways CRS can be defined. I
currently use EPSG database CSV dumps from the libgeotiff svn repo but some work has been
done with plugins to use either the GeoTools or GeoTK referencing APIs (I have a GeoTools
working but it's not enabled in the current incarnation of the source). Let me know if
you have any questions.