Bug#824818: CharLS: One JPEG-LS not handled
As explained in upstream bug tracker, one should pay attention that `charlstest -decodetopnm` uses inverted UNIX convention for return value.
Bug#824818: CharLS: One JPEG-LS not handled
Package: src:charls Version: 1.0-7 I recently discover that at least one instance of a JPEG-LS codestream is not handled by CharLS: http://gdcm.sourceforge.net/thingies/JPEG_LS_InvalidEscapeSequence_COM_padding.dcm I've tried to simplify it: - Remove COM marker, - Change the recommended DICOM