DICOM @ OFFIS

Hi, we noticed a strange slowness sending from StoreSCU.exe to a PACS. After some tests we discovered this behavior depended from MAX PDU SIZE set on the PACS (it was 512KB). In addition the transfer rate from modality managing big PDU SIZE (512KB) to the same PACS was very fast. By reducing PACS PD...

Hi Jorg, first of all, thanks for your prompt feedback. A couple of comments: 1 - I am not using the DicomImage class explicitly, I am just doing Tx Syntax conversion on the DICOM file and related dataset. My code looks more or less like this: DcmFileFormat dcmFileFormat; if (dcmFileFormat.loadFile(...

Should it be useful for some testing, here is a link to a sample Enhanced MR DICOM file which shows issues once converted to Lossy JPEG Tx Syntax through DCMTK:

https://www.dropbox.com/s/sppwkjqz5tpkgi4/ENH_MR.dcm

Thanks in advance for any feedback on this topic.
Best regards,

Marco

Hi all. I am experiencing an issue while trying to convert an Enhanced MR DICOM image file to JPEG lossy (1.2.840.10008.1.2.4.50) Transfer Syntax. The original uncompressed DICOM image file (Enhanced MR) has the following features: * Transfer Syntax UID = 1.2.840.10008.1.2.1 * Bits Allocated = 16 * ...

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 b...

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...

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 Sy...

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: dcmcjpls.exe -d c:\Share\testCrashCOmpressJPEG-LS\DICOM\00000000.crash c:\Share\testCrashCOmpressJPEG-LS\DICOM\00000000.crash.jpls D: $dcmtk: dcmcjpls v3.6.0 2...

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 "fea...

I added the following code (as suggested): log4cplus::SharedAppenderPtr nullapp(new log4cplus::NullAppender()); /* make sure that only the null logger is used */ log4cplus::Logger log = log4cplus::Logger::getRoot(); log.removeAllAppenders(); log.addAppender(nullapp); BUT the crash is always present....

Hi, we encountered the same crash. Since we have DCMJP2K library, how can we workaround the problem? If we use the commit you signaled we lost JP2K library and I think also this library need to be patched to be thread safe. How can we solve? We don't need logging functionality but we seen that disab...

The problem was the PixelRepresentation=1 (not codec) incompatible with JPEG-LS near lossless.
I tryed to convert from JPEG2000 to JPEG-LS lossless and it's working.
Also other conversion from JPEG to JPEG2000 and viceversa works.

Thank you

I add that the second chooseRep. compressing to JPEG-LS again return the following:

"Unsupported pixel representation for near-lossless JPEG-LS compression"

Yes all registered correctly. I'm able to compress/decompress from non-encapsulated to encapsulated and vice-versa. I'm looking for a workaround to convert from encapsulated to encapsulated by decompressing to EVRLE on the fly. Adding my previous piece of code I think the decompression in memory suc...

I use the following code: // Temporary decompress original file eTxSyntax = EXS_LittleEndianExplicit; pDataset->chooseRepresentation(eTxSyntax, NULL); if (!pDataset->canWriteXfer(eTxSyntax)) // Decompression failed? { return FALSE; } Debugging the application the pDataset tx syntax remains EXS_JPEG2...