DICOM @ OFFIS

This is not what should be happening, but I suspect that the problem is on the fo-dicom side. The protocol for closing a DICOM network association requires one side (usually the client, as with findscu or echoscu) to send an A-RELEASE-RQ message to the server, indicating the wish to close the networ...

I think that this behaviour might be related to the use of MFC. As far as I know, the MFC comes with it's own implementation of operator new that calls AfxThrowMemoryException() if a block of memory cannot be allocated. Perhaps this implementation also ignores std::nothrow. Adjusting the link order ...

IPv6 support is not high on the list of priorities for the development team, the main reason being that our network infrastructure is IPv4 only, which makes it very difficult to develop and debug this. Unless somebody provides a patch / pull request for adding server-side IPv6 support, I do not see ...

The "unrecognized PDU type" message indicates that something that is not DICOM tries to connect to that port.
The timeout might be caused by an attempt to look up the hostname using a reverse DNS lookup. Try running storescp with the --disable-host-lookup option.

When writing a new DICOM file, the meta-header will be re-created from scratch, unless you use certain options in DcmFileFormat::saveFile(). Specifically, the implementation class UID and version name refer to the "implementation" that has written the file, which is DCMTK for the new file....

If I remember correctly, it should be possible to write a DICOM file in a different transfer syntax without all data getting loaded, as long as both the original transfer syntax and the new one are uncompressed (or Deflate). It should be easy for you to test this. Just don't call loadAllDataIntoMemo...

However, I have one more question—why was it working in Debug mode before enabling this setting?

Very good question. That should have produced the same error as in your release build.

Can you explain to us what the issue was and how it was resolved? Maybe others could benefit from your experience...

Then my guess would be that your code defines a pre-processor macro that changes the definition of DcmItem::findAndGetOFString() such that the function signature that your code expects is not identical anymore to the one that was used during compilation of dcmdata.lib. For example, a #define HAVE_ST...

The missing symbol is definitely part of dcmdata.lib. Perhaps you should try to re-compile the release build of DCMTK to make sure that this library is intact.

Since the description of your approach does not mention the position information, I would suspect that this is the root cause. For MPR, each DICOM image needs contain information that exactly describes its position and orientation in 3D space, e.g. Image Position (Patient) and Image Orientation (Pat...

In DICOM, the expected behavior of a storage SCU is to first check if an image can be transmitted in compressed form, and if this is not the case, then to silently decompress the image and transmit in uncompressed form. Apparently the SCU does not have a decoder for JPEG lossless, so this fails (and...

I apologize for the late response - somehow we have apparently missed this thread. I have created an issue in our bug tracker, see https://support.dcmtk.org/redmine/issues/1145. If you have meanwhile found further information whether this is related to a specific bug in oflog, a timing issue, networ...

Transmission of a DICOM image in JPEG lossless will only work if during association negotiation a presentation context is proposed and accepted where SOP Class is CT Image Storage and Transfer Syntax is JPEG Lossless, Non-Hierarchical, First-Order Prediction (Selection Value 1). This has nothing to ...

Thanks for letting us know. I will put it on the to-do-list to remove the __BORLANDC__ #ifdefs, which were intended for a rather ancient version of Borland C++.