DICOM @ OFFIS

Make sure that you always #include "osconfig.h" before you include any other DCMTK header file. Also, make sure that the compiler does not find another version of "osconfig.h" or "cfunix.h". Both would explain the error message.

If I remember correctly, dbregimg never deletes image files, it only ever modifies the index.dat registration database. The error message you are seeing seems to indicate that you are trying to add an image to the database that has already been registered with the same SOP instance UID but a differe...

DICOMscope indeed is "compatible" with DICOM Part 14 in the sense that it allows a display to be calibrated against the GSDF and it also supports Presentation States including a faithful rendering of the DICOM grayscale display pipeline. If you want your scanned images to be displayed corr...

DICOM strings except UI are indeed space padded to achieve even length. DCMTK creates and removes this padding character transparently in the background (unless certain options are enabled), so the XML representation created by dcm2xml does not see this artifact, and does not have to.

From the perspective of the parser, "isIconImage" and "isPrivate" would be synonymous. The only meaning of this flag is that it tags instances of the DcmPixelData class that may be written with explicit length (i.e. with uncompressed content) in encapsulated (compressed) transfer...

This is not possible with movescu alone. You could use storescp with the --output-directory and --rename-on-eostudy command line options and use movescu to initiate the retrieval to storescp. In that case, storescp should be listening on the target port and movescu needs to use a dummy listen port t...

There is nothing in the toolkit that would allow you to do that, but it is certainly possible. You would have to write the configuration file at runtime, and then restart all the tools (dcmprscu and dcmpssnd instances) that read the configuration file at startup.

Does the DICOM server need to support receiving the file in the JPEGProcess25_27TransferSyntax tansfer syntax (only receiving, since processing, after it is received, is performed by another application)? Yes, this is how the DICOM network protocol works. The transfer syntax needs to be negotiated ...

You are not really trying to send pixel data as part of the C-MOVE-RQ message, are you? I suggest carefully re-reading DICOM part 4 section C.4.2.2.

Your analysis is correct. The question is what you would like to have on the "to do list" for the next version. The problem you describe is only manifest with compression codecs that do not compress icon images (all codecs in DCMTK always do compress icon images, for good reason :wink: ). ...

In general, no.

Are there any other requirements to be met in order to send the image successfully.

This is not really a DCMTK related question, is it. I would suggest you re-read the definition of encapsulated pixel data in part 5 of the DICOM standard, in particular with regard to the so-called offset table.

DICOM objects containing multiple "images" (frames) do not use a sequence structure for encoding the pixel data. They use a direct concatenation of pixel cells inside attribute (7FE0,0010) along with the Multiframe Module that describes properties of the multiframe objects. Details can be ...

You are mixing Pixel Data (DCM_PixelData, attribute tag is 7FE0,0010) and Pixel Data Group Length (DCM_PixelDataGroupLength, attribute tag is 7FE0,0000).

The error message indicates that the other side aborts the association, not imagectn.