Artifacts in Image Using GDAL JP2KAK plugin for lossless 16 bit

[swalter75]

When converting Int16 data to JP2KAK with the -co "QUALITY=100" option, scrambled artifacts are created in the no_data values and in some cases also in the image data. Using the conversion without the lossless option everything works as expected.

For example, the problem can be inspected with this example data (Mars elevation):

​http://maps.planet.fu-berlin.de/2956/h2956_0000.da4.50.tif

The following command gives strange results:

gdal_translate -ot Int16 -of JP2KAK -co "QUALITY=100" h2956_0000.da4.50.tif h2956_0000.da4.50.jp2

These problems occur not only in the no_data areas, but also in the valid data borders close to the no_data.

[RPopov007]

Hi,

You may take a look the ticket #4050 at http://trac.osgeo.org/gdal/ticket/4050.

The same problem was seemingly tackled, and a patch for the file jp2kakdataset.cpp has been proposed by GMaillet.

I use this patch routinely to compress 16 bit TIF images into 16 bit JP2 images, it works fine.

Hope it helps.

Best regards,

18. Provin

[swalter75]

Replying to RPopov007:

Hi,

You may take a look the ticket #4050 at http://trac.osgeo.org/gdal/ticket/4050.

The same problem was seemingly tackled, and a patch for the file jp2kakdataset.cpp has been proposed by GMaillet.

I use this patch routinely to compress 16 bit TIF images into 16 bit JP2 images, it works fine.

Hope it helps.

Best regards,

18. Provin

Hi, Thanks for your comment. I tried the patch but the reults do not improve. As far as I can see, the ticket 4050 is related to UInt16 with an offset of 32768 in the "no data", while I need Int16 and the "no data" is totally scrambled. But it could be a good hint that these two problems are related...

Many Regards, S. Walter

[swalter75]

Hi This is just to mention that the problem still exists in version 1.11.0. Links to example images have been updated. Best, Sebastian