dcmjpeg issues?

[tkoninck]

Hello,

I'm storing endoscopic camera images as a set of "UID_SecondaryCaptureImageStorage" DICOM images.
Everything works fine, the data seems to be compatible with most if not all viewers. Excellent, so far!

However, if I now add jpeg compression to the dataset which works flawlessy above, things go wrong.
What I did for the compression is similar to what is explained here:
http://support.dcmtk.org/docs/mod_dcmjpeg.html

The resulting image is not all too portable anymore (both for lossy and losless): eg ok for eZDICOM and DicomWorks, but not ok for Gimp Dicom plugin and xnview... and also not for the tools like dcm2pnm (yields: Error Invalid Data...)
Finally, when reloading the data with dcmtk and decompressing the brightmess is also strongly modified, and some parts of the color data seems to suffer from overflow (white turns magenta) Any suggestions/hints how to overcome this? Thanks beforehand.

If usefull I can post my code and the dcm images.

Bye
Thomas

[Michael Onken]

Hi Thomas,

As you probably know, DICOM allows many compression methods (~transf er syntaxes) for storing Pixel Data - so it's not unusual that Gimp or xnview cannot open some DICOM images, because (as I know from my earlier tries) that they often only can handle uncompressed DICOM pixel data or fail on some "specialities" (unusal high bit, bits allocated, etc. values).

First of all, please try to compress your images using dcmcjpeg from the DCMTK release. It does some modifications of pixel data attributes (like color model etc.) if necessary. These attributes could be part of your brightness problems. Another issue could be windowing (monochrome images?); you could play around with some windowing features in dcmcjpeg to evaluate that.

dcm2pnm only can handle uncompressed DICOM pixel data, try to use dcmj2pnm for JPEG compressed DICOM files instead.

If you can't get the compression to work, then you could mail the files to dicom (at) offis (dot) de. After hopefully resolving your issues we could then return posting to the forum to let other people participate in the solution.

Regards,
Michael

[tkoninck]

Hi Michael,

Thanks for the response. After going through the dcmcjpeg example: hereby my findings:
-uncompressed dcm write and read with dcmtk: consistent result
-losless jpeg compression write and read with dcmtk: consistent result (through applying all options listed in the example during codec registration)
-losless jpeg compression write and read with dcmtk: nok

Starting from the uncompressed dcm, I then used dcmcjpeg to create a losless and lossy image in order to check if my encoding or decoding is causing the trouble. The result: idem to above: losless shows correct in my app, lossy shows incorrect. -> thus: decoding lossy is done incorrectly in my case I would guess.

However, using now dcmj2pnm to 'double check' on respectively the losless and lossy images made with dcmcjpeg I get two times the color overflow effect.

Therefore: my attemptive conclusions: I guess there is a (small) bug in dcmj2pnm on the side of the decoder, and possibly dcmcjpeg with lossy jpeg doesn't work flawlessy either.

Is there anything I can do to further track this problem down, or do you prefer to get some images with comand lines to repeat the error?

Many thanks for the help so far (altogether, one of my issues has already been solved).

Bye
Thomas

[Michael Onken]

Hi Thomas,

please send the files. I've checked our cvs history and noticed, that we did some small bugfixes since DCMTK 3.5.4 in the dcmjpeg code. So I will examine your files using both, the release and the CVS version.

Regards,
Michael

[darb_india]

Hi;

I tired copying the complete function on http://support.dcmtk.org/docs/mod_dcmjpeg.html
inside my code to convert dicom to jpeg.

Unfortunately it does not works. I tried to debug and it seems the problem is at
if (dataset->canWriteXfer(EXS_JPEGProcess14SV1TransferSyntax))
this line of code. since it returns false and file is not created.

Please help me on this

Regards,
Dhaval