Opened 11 years ago
Closed 5 years ago
#5183 closed defect (wontfix)
Artifacts in Image Using GDAL JP2KAK plugin for lossless 16 bit
Reported by: | swalter75 | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | closed_because_of_github_migration |
Component: | GDAL_Raster | Version: | svn-trunk |
Severity: | normal | Keywords: | |
Cc: |
Description (last modified by )
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/mex4/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.
Change History (15)
comment:1 by , 11 years ago
Description: | modified (diff) |
---|
comment:2 by , 11 years ago
Description: | modified (diff) |
---|
comment:3 by , 11 years ago
Description: | modified (diff) |
---|
comment:4 by , 11 years ago
Description: | modified (diff) |
---|
comment:5 by , 11 years ago
Component: | default → GDAL_Raster |
---|
follow-up: 7 comment:6 by , 11 years ago
comment:7 by , 11 years ago
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,
- 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
comment:8 by , 10 years ago
Description: | modified (diff) |
---|---|
Version: | 1.10.0 → 1.11.0 |
comment:9 by , 10 years ago
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
comment:10 by , 10 years ago
Description: | modified (diff) |
---|---|
Priority: | normal → high |
comment:11 by , 10 years ago
Version: | 1.11.0 → svn-trunk |
---|
New tests have been performed with kakadu library version 7.4, but the problem is still existing. The auto_test suite is not covering this problem possibly because it doesn't contain no_data.
comment:12 by , 10 years ago
Description: | modified (diff) |
---|
comment:13 by , 9 years ago
Priority: | high → normal |
---|
All those tickets have more than one year and nobody has acted on it, so the priority is not so high
comment:14 by , 6 years ago
Interestingly I can reproduce the same problem with the latest openjpeg version, so it seems this is a fundamental issue with JP2K lossless compression, high bit depths, and fast transitions
comment:15 by , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.
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,