Bug #892
open
dcmcjpls may generate JPEG-LS images that dcmdjpls cannot decode
Added by Marco Eichelberg about 6 years ago.
Updated almost 4 years ago.
Category:
Library and Apps
Description
Under certain (rather unusual) conditions, dcmcjpls will create a compressed DICOM image that dcmdjpls cannot decode:
- The command line option
--interleave-none is used
- The image is a color image with BitsStored > 12
This is caused by the CharLS library, which in this case writes multiple LSE marker segments to the JPEG-LS bitstream, which is permitted, but apparently the library is unable to decode such files.
This bug has been registered as Issue 25 in the CharLS bug tracker: https://github.com/team-charls/charls/issues/25
- Target version changed from 3.6.5 to 3.6.6
- Status changed from New to Resolved
- % Done changed from 0 to 80
Unfortunately, the author of the CharLS library has decided to only fix this issue in the 2.x branch of the CharLS library, since fixing it in 1.x would be too much effort.
DCMTK uses the CharLS 1.x and cannot yet be switched to CharLS 2.x, because that requires C++14 whereas DCMTK still supports a number of pre-C++11 compilers such as Visual Studio 2008. Therefore, the bug cannot be fixed before DCMTK gives up support for pre-C++14 compilers.
As a stopgap measure, the creation of such images is prevented now by removal of the --interleave-none option on command line and library level. Images from third parties may still cause the decoder to fail, but color images with > 12 bits/sample are extremely unusual, so this should be a very rare phenomenon.
See DCMTK commit #6b03bc98b.
- Target version deleted (
3.6.6)
- Target version set to 3.6.6
Should be fix or tagged as open issue (won't fix).
- Target version changed from 3.6.6 to 3.6.7
- Target version deleted (
3.6.7)
Also available in: Atom
PDF
Updated by Jan Schlamelcher 
Updated by 
Updated by 
Updated by