On download page for GDAL native libraries http://java.net/projects/imageio-ext/downloads/directory/Releases/Dependencies/GDAL/NativeLibraries/1.4.5 there is only win x32 version. However I'm running win x64 jre and tomcat so x64 version of GDAL dlls are required. Nowadays x64 is more popular than x32 (Server 2008R2 only has x64 version) so please add win x64 support.

We have images in geotiff format that don't display correctly (tested in GeoServer 2.1RC2 with no native libs added). It looks like it fails to convert colorspace to RGB.

Output from gdalinfo:
Driver: GTiff/GeoTIFF
Files: 10120415361937809856.tif
Size is 5119, 5119
Coordinate System is:
LOCAL_CS["unnamed",
UNIT["unknown",1]]
Origin = (456552.750000000000000,7003661.250000000000000)
Pixel Size = (1.500000000000000,-1.500000000000000)
Metadata:
AREA_OR_POINT=Point
Image Structure Metadata:
SOURCE_COLOR_SPACE=YCbCr
COMPRESSION=JPEG
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 456552.750, 7003661.250)
Lower Left ( 456552.750, 6995982.750)
Upper Right ( 464231.250, 7003661.250)
Lower Right ( 464231.250, 6995982.750)
Center ( 460392.000, 6999822.000)
Band 1 Block=256x256 Type=Byte, ColorInterp=Red
Band 2 Block=256x256 Type=Byte, ColorInterp=Green
Band 3 Block=256x256 Type=Byte, ColorInterp=Blue

As I don't have good knowledge of TIFFDecompressor and TIFFJPEGDecompressor I'm not sure if a colorConverter should be set or not or what is really the problem.

GIMP opens the image correctly.

Metadata from ENVI .hdr files is especially useful for some images, e.g supervised classification results where metadata describes classes found or a multispectral image where metadata contains spectral parameters of the image. HDR files are supported by GDAL (a getMetadata("ENVI") call is said to return the required data), so it should not be hard to add support in imageio readers. For example, there is a BufferedImage.getProperty(String name) that could be used to store this information.

Also, it could be implemented for other filetypes.

NetCDFConverters module is no more used.
We can move out from ImageIO-Ext to another project (it contains some interpolation and georectification code which may be useful for some other projects)

Method JP2KFileWalker#init() checks the field JP2KFileWalker#initialized, but it never sets it to true when it completes successfully. Hence the initialization is done for every call to JP2KFileWalker#getJP2KBoxesTree().

Even when the size of all tiles/strips can be known in advance, the header isn't fully written in advance. The header is written, and as each tile is written, the part of the header corresponding to the tile is replaced, but this requires writing two increasingly-distant parts of the file.

GDAL has methods to compute/retrieve statistics for the various bands. I think
we should try to see if we can spend some time and investigate if and how we can
expose this information.

We should document the common metadata format since otherwise it si quite
difficult to understand what we can get out of such tree of information.

The readAsRenderedImage method for gdal now fallsback on the read method
resulting in an immediate mode call while it should be deferred call.
We need to provide a better implementation for this method which supports
non-immediate mode.

Here it is http://java.net/jira/browse/IMAGEIO_EXT

We should probably take a look to the CLIBJPEGMetadata or the standard JPEGMetadata to setup some code to do JPEG metadata creation.

It would be great to have a unified HDF4ImageReaderSPI able to handle with all
the different types of HDF4 dataset (APS,TeraScan,TIROS,TOVS,...)

Out of memory errors have occurred when writing an U_SHORT image having an
IndexColorModel with 65536 elements of the color map.
The tiff plugin should better handle this case allowing to write the image
without problems.

Details from Daniele:

I think I have found the problem. I guess all the JP2K images we have used until now (from several customers needing JP2 related support) don't contain these box.

I think that the constructor which is trying to invoke through reflection has only a byte[] argument whilst the available resolutionBox construtor needs both (byte[] data, int type) to setup a CaptureResolutionBox vs a DisplayResolutionBox.

The current code has been quickly developed to support EXIF write operation, insert and update.
There isn't any utility method which allows to get a TAG content from a file, a byte[], a marker,... what else. We need to a few methods to do that.

Also make sure to rename the EXIFUtilities static methods starting with "Is"

We should create a very simple java program to be dropped within the native libraries that can be run in order to check the formats are available.

As an instance the gdalinfo.java turned into a jar would do it.

We should check that we are avoiding too many reads when reading large chunks of bytes

Tiff reader is relatively inefficient since it heavily relies on metadata for doing its work and metadata for bigtiff can be enormous due to the fact that it stores two arrays of long where each element holds the tile offset in the file as well as the tile bytes count.

It would be great to try and:

1 cache these values between multiple successive reads
2 load them as we need them since they are rather big

Here it is the old one http://java.net/projects/imageio-ext/

It is not exactly the most user friendly one!

When investigating on a JP2ECW issue, we found (thanks to Even Rouault for that) a bug on Dataset management.

Long story short, on some metadata initialization, we acquire a Dataset but we don't close it. A deinitialization conflict between the ECW driver and GDAL Driver results into a segmentation fault as reported here:
http://trac.osgeo.org/gdal/ticket/5024

We can avoid that by properly explictly closing any Dataset.

On Turbojpeg writer there is a section of code which perform some checks on sourceImage and requested layout and force a Copy operation to handle cases like this.

imageSize = 20x20
Tile layout size = 128x128.

getData(new Rectangle(0,0,20,20)) will anyway return a 128x128 raster (due to the tile layout) filled with a lot of zeros.

We need to improve the math on this method to deal with special case with negative minX,minY, tileGridOffsets, ...

Checking the read_ code we noticed that we are using a seek also when we are already at the right position.

We need to make sure that the canDecode method of the Gdal ImageReader SPI do not
leave files open. File Descriptors are a limited resource, we need to take care of
proper clean up during the canDecode method.

In turbo jpeg ImageReaderSPI we set the loading priorities so that the turbojpeg one is the first to be chosen.
The same behaviour should be set in the image writer.

The issue depends on
#14

On download page for GDAL native libraries http://java.net/projects/imageio-ext/downloads/directory/Releases/Dependencies/GDAL/NativeLibraries/1.4.5 there is only win x32 version. However I'm running win x64 jre and tomcat so x64 version of GDAL dlls are required. Nowadays x64 is more popular than x32 (Server 2008R2 only has x64 version) so please add win x64 support.

We should create updated GDAL native libs (built on top of GDAL 1.9.2?) for different systems:

• Centos 64
• Centos 32
• Ubuntu 64
• Ubuntu 32
• ....

Also setting up an installer to install them on the system would be helpful.

Need to setup some code samples on how to use the imageio-ext code (we may use parts of code from junit tests and/or see what we have on User doc)

A plugin specific page containing needed maven dependencies would be very
useful for users which needs to use only a single plugin.
Knowing all the dependencies needed by that plugin in order to getting it work,
would be helpful.

When parsing the MATLAB5 file via the jmatio library, having the capability to
skip TAGS/Entities (when compression is disabled) would be great in terms of
performance improvements. This will allow if needed, to avoid reading the whole
array/CELLS when initializing the MatfileReader, since you know in advance the
Matlab TAG size.

Daniele created a specific implementaion of ImageOutputStream to be able to get access to the underling OutputStream. We should streamlines this capability and remove the specific implementation.
Part of this work should ongoing on ImageIO-Ext

Issue ported from previous repository

continous integration would be very useful.
we should setup at least

• windows
• linux

Currently we manage the domain metadata from GDAL , see here for more info on the metadata concept, as Map of String pairs.

I am hoping we can do slightly better and come up with a better OO design for that, which should also retain information such as the names of the single elements of the domains.

Setup a new jar with bindings and deploy it.

Actually, when loading data involving overviews, any access to an overview of a
dataset is managed by the underlying GDAL library. Provided a region and a
databuffer/array where that region should be loaded, GDAL will internally find
the proper overview (by taking access to the related raster band) and will do
proper subsampling operations (if needed) in order to fit the specified source
region to the specified destination data buffer.

It would be useful to allow the framework to take direct access to a specific
underlying overview.