DICOM @ OFFIS

Great to hear that it's working now

The provider keeps telling me that it is a Transfer Syntax issue. I disagree. I see no sign of any transfer syntax related problems. If the modality negotiates Implicit VR Little Endian, then the worklist SCP will convert all response messages to that transfer syntax before sending. If the provider...

It looks like you are trying to compile DCMTK 3.6.2 on MacOS for ARM. That platform is only supported since DCMTK 3.6.8.
DCMTK 3.6.2, which is from 2017, predates the existence of MacOS for ARM by several years.

1. Once I build the toolkit using WITH_OPENSSL, I should be able to do secure and unsecure connections (I think the answer is yes)? Correct. 2. Is the only way to create, and use secure, connections with TLS to always create a DcmTLSTransportLayer and pass it to ASC_setTransportLayer? Yes, this is ...

I would suggest that you look at how dcmnet/apps/findscu.cc does this, since this is one of the DCMTK command line tools that support secure TLS connections. dcmnet/apps/storescp.cc would be an example of a server application with TLS support.

I am sorry, Michael, but this is not really a DCMTK question. There are certainly tutorials out there how to compile things with Visual Studio. Basically, you need to start Visual Studio, open the "solution" file (.sln) and start the compiler within Visual Studio.

This information is not sufficient to provide any help. CMake certainly reports more about the source of the problem than "Error in configuration process". First thing to check, have you installed the C++ compiler within Visual Studio? That is not installed by default. In the Visual Studio...

If I remember correctly, the UID generation algorithm will cut off the UID after 64 characters. In this case the UID may not be unique anymore.

SITE_UID_ROOT needs to be passed to the C++ compiler. You are just defining a CMake variable that never gets used. Try CXXFLAGS=-DSITE_UID_ROOT=\"1.2.826.0.1.3680043.10.1395\" cmake -DDCMTK_ENABLE_CXXX11:BOOL=ON ... I suspect that your UID root is too long for the UID generation algorithm...

I don't see any reason why this should not work, but in the absence of an IPv6 network, I cannot test it. Sorry.

There is no general answer to this question. If you have a DICOM image type that exists both in a single frame and a multiframe variety, then converting from multiframe to single frame requires an adaptation of all physical parameters related to the image acquisition. This is a fairly complex tasks ...

The command line tools will not work with IPv6 yet. On library level, some classes and functions are "IPv6 ready", such as class OFSockAddr OFStandard::getHostnameByAddress() the gethostid() function, which in some cases uses the system's IP address the oflog logging module Other functions...

DCMTK contains partial support for IPv6, but the support is incomplete, so it is not entirely surprising that you are encountering issues.

OFFIS explicity permits the use of the UIDs generated by DCMTK under the OFFIS UID root by DCMTK users. While we cannot accept any legal responsibility for the uniqueness of the UIDs, the UIDs are as unique as technically possible. If the PACS vendor has reason to suspect otherwise, I would be happy...

I have today committed a fix for this issue to our testing branch. This should appear in the public git repository in a couple of days.
I have also reported the issue to FreeBSD, see https://bugs.freebsd.org/bugzilla/show_ ... ?id=278229.