DICOM @ OFFIS

With the latest snapshot (from today) we've tried to enhance the performance of the DICOMDIR code significantly. Could you please check? Thanks!

It took some time, but finally we've managed to enhance the performance of the DICOMDIR code significantly: Could you please check the latest DCMTK snapshot (from today)? Thanks.

To the original poster ("angad"): Could you please check the latest DCMTK snapshot (from today)? We've tried to enhance the performance significantly. Thanks.

Thank you for the feedback. We've now also moved the status detail information (if any) from the "warning" to the "debug" level. This is now consistent for all DCMTK network tools.

Here's the modification I've just committed. This is more in accordance with the other DCMTK network tools (at least with some of them .

Maybe, it's too obvious but images of the SOP Class DigitalMammographyXRayImageStorage ForProcessing are not meant to be displayed. This is the reason why there is another SOP Class called DigitalMammographyXRayImageStorage ForPresentation . The latter (your "Control Image") is displayed c...

Thank you for your proposal. However, are you sure that something changed in this regard between DCMTK 3.5.4 and 3.6.0? Here's the relevant code fragment from storescu 3.5.4: /* finally conduct transmission of data */ cond = DIMSE_storeUser(assoc, presId, &req, NULL, dcmff.getDataset(), progress...

So, could you please tell us what was wrong and what you changed, i.e. could you provide a patch, so we can fix this bug also in the DCMTK. And, are you really sure that this issue was not caused by the DICOM image you've processed?

Have you seen how old DICOMscope is? Do you think it is likely that DICOMscope supports the enhanced multiframe paradigm?

I guess we've solved this issue now by simply removing the version check for "darwin". See the corresponding commit.

I hope that this fix also work on your system. We would appreciate your feedback!

You are right. I guess this is the corresponding commit . It has been introduced in order to solve other issues that were present with the "old approach". Of course, the global data dictionary is cleared in the destructor of the class, but that's too late for most memory leak checking tool...

So, does that mean that there is/was a bug in the dcmjpeg module, which is based on the IJG library, or is the image buggy?

Some of the DCMTK command line tools contain the following code at the end of the main function (before return): #ifdef DEBUG dcmDataDict.clear(); /* useful for debugging with dmalloc */ #endif Maybe, this is also useful to convince your checking tool that there is no memory leak. The problem is tha...

Have you already checked the source code of "dcmjpeg" for this kind of error code?

First of all, these tags are only required to be supported by the server (SCP). The client (SCU) can always decide what to query for.
Secondly, range matching is not defined for Patient ID (it is only defined for date and time fields).