Test Dicom-JLSN files fails

Nov 12, 2010 at 4:38 PM
Edited Nov 12, 2010 at 4:48 PM

Hi all,

I'm trying out the test project of CharLS with David Clunie's JLSN-Dicom files.

I have modified the class "dicomsamples.cpp" method "TestDicomWG4Images()"

 TestDicomSampleImage("test/jpegls/JLSN/MR1_JLSN");  //OK
TestDicomSampleImage("test/jpegls/JLSN/MR2_JLSN");  //OK
TestDicomSampleImage("test/jpegls/JLSN/MR3_JLSN"); //OK
TestDicomSampleImage("test/jpegls/JLSN/MR4_JLSN"); //fails
TestDicomSampleImage("test/jpegls/JLSN/CT2_JLSN");  //fails

Has any one an idea why some files coud not bes testet. Reason

 

test.exe!__crt_debugger_hook(int _Reserved=0)  Line 2 C
test.exe!_invalid_parameter(const wchar_t * pszExpression=0x00000001400a9e38, const wchar_t * pszFunction=0x00000001400ab0d0, const wchar_t * pszFile=0x00000001400a9fd0, unsigned int nLine=163, unsigned __int64 pReserved=0)  Line 114 C++
test.exe!std::_Vector_const_iterator<unsigned char,std::allocator<unsigned char> >::operator+=(__int64 _Off=-1)  Line 164 C++
test.exe!std::_Vector_iterator<unsigned char,std::allocator<unsigned char> >::operator+=(__int64 _Off=-1)  Line 376 C++
test.exe!std::_Vector_iterator<unsigned char,std::allocator<unsigned char> >::operator+(__int64 _Off=-1)  Line 382 + 0xf bytes C++
test.exe!TestDicomSampleImage(const char * name=0x00000001400c1e58)  Line 42 + 0x6a bytes C++
test.exe!TestDicomWG4Images()  Line 92 C++
test.exe!main(int argc=2, char * * argv=0x0000000000563090)  Line 243 C++
test.exe!__tmainCRTStartup()  Line 266 + 0x19 bytes C
test.exe!mainCRTStartup()  Line 182 C
kernel32.dll!000000007733f56d()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] 

All Images are readable by using dcm4chee and jai-imageIO.

Thx

 

Call Stack

Coordinator
Nov 14, 2010 at 8:32 PM

I have tested these files before the release, and then they worked. Are you sure the file is correctly read in memory? The iterator callstack suggests that the input byte array is empty. At what line does it actually fail?

Nov 14, 2010 at 9:13 PM
Edited Nov 15, 2010 at 5:58 PM

Hi,

 Yes thats right, the orig test files are from the directory JLSL and they are OK.

TestDicomSampleImage("test/jpegls/JLSL/CT1_JLSL");
TestDicomSampleImage("test/jpegls/JLSL/XA1_JLSL");	
TestDicomSampleImage("test/jpegls/JLSL/CT2_JLSL");	
TestDicomSampleImage("test/jpegls/JLSL/MG1_JLSL");
TestDicomSampleImage("test/jpegls/JLSL/MR1_JLSL");
TestDicomSampleImage("test/jpegls/JLSL/MR2_JLSL");
TestDicomSampleImage("test/jpegls/JLSL/MR3_JLSL");
TestDicomSampleImage("test/jpegls/JLSL/MR4_JLSL");
TestDicomSampleImage("test/jpegls/JLSL/NM1_JLSL");
TestDicomSampleImage("test/jpegls/JLSL/RG1_JLSL");
TestDicomSampleImage("test/jpegls/JLSL/RG2_JLSL");
TestDicomSampleImage("test/jpegls/JLSL/RG3_JLSL");
TestDicomSampleImage("test/jpegls/JLSL/SC1_JLSL");

 

But I've tried to test the near lossless files also files from the directory JLSN. And some files seems to be OK, but some do not that.

I can read the "damaged" images with jai_image IO and I do not know what is wrong with this files.

Hier is the original routine from the dicomsamples.cpp, I've marked the line at which the programm crashes.

 

void TestDicomSampleImage(const char* name)
{
	std::vector<BYTE> data;
	bool success = ReadFile(name, &data, 9);

	ASSERT(success);
	
    	BYTE pixeldataStart[] =  { 0x00, 0x00, 0x01, 0x00, 0xFF, 0xD8, 0xFF, 0xF7 };

	int offset = findstring(data, pixeldataStart, COUNT(pixeldataStart));
	//At this line crashes the programm, with some files NOT ALL
	data.erase(data.begin(), data.begin() + offset - 4);

	// remove the dicom fragment headers (in the concerned images they occur every 64k)
	for (unsigned int i =  0; i < data.size(); i+= 64 * 1024)
	{
		data.erase(data.begin() + i, data.begin() + i + 8);		
	}

	JlsParameters info;

	JLS_ERROR error = JpegLsReadHeader(&data[0], data.size(), &info);


	//    0xFE, 0xFF, 0x00, 0xE0, 0x00, 0x00, 0x01, 0x00
	std::vector<BYTE> dataUnc;
	dataUnc.resize(info.bytesperline * info.height);

	error = JpegLsDecode(&dataUnc[0], dataUnc.size(), &data[0], data.size(), NULL);
	ASSERT(error == OK);
	std::cout << ".";
}

 

Thx

Coordinator
Nov 15, 2010 at 5:12 PM

Aha.

I would guess that the problem has to do with the dicom encapsulation used in these files. For some reason, the lossless wg04 images have multiple pixeldata fragments (all exactly 64 k bytes). The test code blindly assumes that this is how all of those files are laid out.

If you have a proper DICOM parser in your project, you can use that to read the files, and pass the raw jpegls stream to charls. I am confident there won't be a problem.

As a side note, I can't really reccommend lossy mode for medical images. You easily get striping artifacts, which degrade the perceived quality with respect to other compression schemes.

Nov 15, 2010 at 6:08 PM

Hi,

thanks, I understand.

I have dcm4che 2 lib, than can parse the Dicom files.

Yes, thats right, but I'd like to decode any Dicom-LS file and convert it to a plain Jpeg. So I've to decode any file (lossless and lossy)

I try to take jni and make a wrapper for java and give only the jpegls stream to charls.

Thanks 

Coordinator
Nov 17, 2010 at 10:46 PM

For production code, that would be the only sensible thing to do. For a small set of dicom files in a consistent format, it can be easy to extract the pixel data, but if you need to be able to do so for any dicom file, you need a dicom parsing library.