DCMTK | WARNING : This is NOT the official upstream DCMTK git

PHP 8.0.15 and 8.1.2 has a bug which is breaks compile sockets extension.

You have a two options:

1. Skip this versions.
2. Apply a workaround to bypass bug and build sockets extenstension.

Source:

• Issue at origin PHP source repository
• Issue at official PHP Dokcer image source repository

Your DICOM dictionary is not found, meaning that probably something in the build/installation went wrong.

There are 2 possibilities to include the DICOM dictionary:

• compile it into the library (default under Windows)
• install it and point the environment variable DCMDICTPATH to its location (default under Posix)

From the documentation:

The built-in approach offers the advantage that a binary will not have to load any information from a separate file which may get lost or or used in an outdated version. Loading the dictionary content from a separate file, however, has the advantage that application programs need not be recompiled if additions or corrections are made to the data dictionary.

The related information can be found in the dcmtk sources under dcmdata/docs/datadict.txt, there is also an online version of the file.

In short, for non-Windows systems:

To compile the dictionary into the library:

• with autoconf, use the options --enable-builtin-dict and --disable-external-dict
• with CMake, use DCMTK_ENABLE_BUILTIN_DICTIONARY

To use the separate dictionary:

• use the default build options and make sure that use the install-libs option; in this case dicom.dic will be installed into the default location (under ) and should be found; for this, you should call "make install" and specify the installation path during "configure" (aka as "--prefix") if needed

• if you want to use your own dictionary, or for some reason want to move the dictionary elsewhere, you have to set DCMDICTPATH to the location of that dictionary, e.g.:

Image Type (0008,0008) is a multi-valued attribute. That is, it may include several values which are separated by the backslash character. Note, that "officially", the backslash is not part of the attribute's value. It is a delimiter between several values of the attribute. This is what you have. So in terms of DICOM, there is no "one value" but multiple ones. The DCMTK API allows you to handle this (of course).

findAndGetOFString() has a third parameter ("index") to define which of the multiple values you want to obtain.

The behavior that you probably expect is what findAndGetOFStringArray() does.

As an alternative, you could iterate through the multiple values of the attribute by obtaining the "Value Multiplicity" first and then loop through the values like

Install the OpenGL dev support:

The answer can be found in DCMTK's "logger howto": https://support.dcmtk.org/redmine/projects/dcmtk/wiki/Howto_LogProgram#Redirecting-log-output-to-a-file

The SOP Instance UID is a mandatory return key for the Query SCP in an IMAGE-Level request. It must not be present in any request on any other level (PATIENT, STUDY, SERIES). The SOP Class UID is optional, but it is usually supported by an SCP. In many places in the Standard SOP Class- and Instance UID form a pair that uniquely identifies the object, and here the SOP Class UID is a required attribute. So not supporting it would significantly reduce the use scenarios for the SCP.

Since the background of querying for SOP Instance UID is usually: "Please give me a list of images belonging to this particular patient, study and series", it is very common to send it empty with the request. This instructs the SCP to fill in this attribute in its responses.

DCMTK sadly does not provide correctly exported CMake targets, so you will have to patch around that. I installed DCMTK via vcpkg and was able to compile your code with this build (after replacing COUT with std::cout and including iostream):

The tag you are looking for is inside a sequence (RealWorldValueMappingSequence). To get to the tag, you first have to get the sequence, something like this:

Your requests only differ in that your non-working query queries for a different patient ID.

An obvious mistake in both queries is that for a SERIES-level request in STUDY-ROOT, you must not include a value for the Patient ID, but for the Study Instance UID. This is wrong in terms of DICOM, but Orthanc seems to be capable of handling it in general. This is however the only hint that I can obtain from your logs, so I would give it a try.

Please note, that the Content Sequence is not a mandatory Return Key for the C-FIND, so you can never rely on the SCP supporting it.