Crash in Tx Syntax conversion from native to JPEG-LS

[wollet88]

Hi all.

We are experiencing a strange issue with OFFIS DCMTK when doing a DICOM Transfer Syntax conversion of a native-encoded DICOM file to JPEG-LS.

We have two different 10-bit grayscale DICOM images (CR images) which are part of the same study and which are apparently identical from the "features" point of view. In fact, both images have these common features:

* Grayscale
* Native TX Syntax (Implicit VR Little Endian)
* Bits allocated = 16
* Bits stored = 10
* High bit = 9
* Rows = 2140
* Columns = 1760
* Rescale Slope = 1
* Rescale Intercept = 0
* Photometric Interpretation = MONOCHROME1
* Value length of Pixel Data = 7532800 (which seems OK)

Nevertheless, for one of the two images the Tx Syntax conversion fails, and the following assert is triggered within CharLS code:

encodstr.h (line 82) --> AppendToBitStream() --> ASSERT(bitpos >=0);

Can you guess why? What could have this single image so "special" and different from the other image (which has the same set of features) which generates problems to OFFIS and/or CharLS?

Here is the code we use for Tx Syntax conversion in this case:

Code: Select all

DcmFileFormat dcmFileFormat;
if (dcmFileFormat.loadFile(aSrcPathName).good()) // Good file?
{
	DcmDataset *pDataset = dcmFileFormat.getDataset();

	E_TransferSyntax eTxSyntax = EXS_JPEGLSLossy;
	DJLSRepresentationParameter repParameters(2, OFFalse);
	
	// Crash happens on the following line!
	pDataset->chooseRepresentation(eTxSyntax, &repParameters);
	
	if (pDataset->canWriteXfer(eTxSyntax))
	{
		dcmFileFormat.saveFile(aDstPathName, eTxSyntax);
	}
}

Thank you in advance for any suggestion you will be able to provide.
Best regards.

[omarelgazzar]

Did you try dcmcjpls commandline tool in the debug mode to see the error message? Look at this example from the documentation.

[wollet88]

Hi.
We tried using the command line utility dcmcjpls (compiled from DCMTK 3.6.0 source with Visual Studio 2010), and here is what we obtain:

Code: Select all

dcmcjpls.exe -d c:\Share\testCrashCOmpressJPEG-LS\DICOM\00000000.crash c:\Share\testCrashCOmpressJPEG-LS\DICOM\00000000.crash.jpls
D: $dcmtk: dcmcjpls v3.6.0 2011-01-27 $
D:
I: reading input file c:\Share\testCrashCOmpressJPEG-LS\DICOM\00000000.crash
D: DcmItem::checkTransferSyntax() TransferSyntax="Little Endian Explicit"
D: setting undefined VR of PixelData (7fe0,0010) to 'OW'
I: Convert DICOM file to compressed transfer syntax
I: Encoding frame 1 of 1
Assertion failed: bitpos >=0, file c:\projects\offisdicomtoolkit_v3.6.0
\dcmtk-3.6.0\dcmjpls\libcharls\encodstr.h, line 82

However, please notice the following strange thing: if I use the pre-compiled dcmcjpls.exe binary as downloaded from OFFIS website (DCMTK 3.6.0 executable binaries for 32-bit Windows), then the same test is successful, and the above assertion is not thrown.

Can you guess why?
How could the build process affect the occurrence of this assertion / issue?

Thanks in advance for your hints/suggestions.

[J. Riesmeier]

Did you compile in debug mode? See http://www.cplusplus.com/reference/clib ... rt/assert/

[wollet88]

Hi Jorg,

actually I was compiling in Release mode, but for some reason the Release mode in my VS 2010 solution did not define the NDEBUG symbol. My VS 2010 solution was generated by CMake on the DCMTK 3.6.0 package.

I tried rebuilding with NDEBUG symbol defined: the assert() went away, and the Tx Syntax conversion was successful.
A question now:

- Now that the assert has been disabled, is my Tx Syntax conversion code reliable or not? The fact that the assert is disabled does not eliminate the cause of the assert. Please let me know your thoughts.

Thanks for your time.

[J. Riesmeier]

That's really strange. I guess that NDEBUG was never defined for Visual Studio when overwriting the compiler flags, which is the default for DCMTK. CMake does define NDEBUG but only if the project uses the automatically determined compiler settings. So, I've just committed a patch that solves this issue.

Now that the assert has been disabled, is my Tx Syntax conversion code reliable or not? The fact that the assert is disabled does not eliminate the cause of the assert.

This is something I cannot say without digging deeply into the CharLS code ...

Thank you for reporting this issue to us!

[wollet88]

Hi Joerg,

we are in contact with Jan de Vaan (CharLS author).
This is his answer regarding this issue:

Hi,

I have used the current build to encode the image you provided.

This worked --- although after I masked away the unused 6 high bits from each pixel. (charls assumes (not checks) that the unused bits are all 0).

If I did not, I got an assert.. but not the one you got.
Do you do this as well before you pass the image?

The assert message you got sometimes fails after the very last byte on very old charls builds. This was a harmless, but annoying bug. The version number you mentioned is more recent, so it should not have that problem.

If you can confirm me about the masking, I will try to reproduce with build you are using.

Jan

What do you think about its comment?
Does your toolkit perform this bit masking?

Thank you and best regards

[J. Riesmeier]

Could you please also send the respective DICOM image to us? Our email address is dicom/at/offis/dot/de.

[wollet88]

Hi Joerg,

here is the DICOM file causing the issue:

http://67.225.240.233/demo/00000000.crash.anon.zip

If it may be useful, here is a ZIP archive containing the "raw" pixel data of the image causing that assertion on CharLS:

http://67.225.240.233/demo/00000000.crash.raw.zip

Thank you and best regards

[J. Riesmeier]

Thank you for the files. I can confirm the assertion. We will see what we can do ...

[Uli Schlachter]

Hi,

this commit fixes the failed assertion:
http://git.dcmtk.org/web?p=dcmtk.git;a= ... 561ff0412a

I also reported this upstream:
http://charls.codeplex.com/workitem/10742

Some more details on what was going can be found there. The short version is: A weird corner case which caused the logic for writing individual bits into a bytestream to fail (and notice its own failure).

Uli