DICOM @ OFFIS

Usually, there is no need to call verify() directly. This methods is mainly used internally as part of other DCMTK functions.

To the OP: Why are you calling verify() at all?

You mean whether the storescp would be able to decompress the PixelData if the required decoder is registered to the application? The answer is: Yes, this should be possible with a few modifications to the current source code.

By default, large element values are not loaded with loadFile() but only when they are accessed. The threshhold what is meant by "large" can be specified with the "maxReadLength" parameter of the before-mentioned method.

I guess you are talking about the ImageHelper class in gdcm, right? No, there is no such thing as the various ImageHelper::getSpacingXXX() methods in DCMTK - at least not yet. As far as I can see, the gdcm code also contains a lot of workarounds based on assumptions that might not always be true. An...

No, this is not possible since the "file size" it not known to the SCP before the DICOM dataset has been received completely. Of course, you could modify the source code in order to reject (or just do not save) a dataset that exceeds a certain size. However, both approaches would be bad st...

From today's perspective, I would also write a C++ class for the core functionality of xml2dcm or incorporate it into the dcmdata class hierarchy. However, at the time when I wrote xml2dcm I had dump2dcm in mind and tried to keep the libxml2 dependency out of the dcmdata library ... To answer your q...

Have you ever looked into the source code of any of the two command line tools? Using the same functionality as dcm2xml from a library/program should be easy since the main work is done by calling DcmFileFormat::writeXML() . The other direction (xml2dcm) requires some additional work since the core ...

DicomImage does report the ratio between the Horizontal and Vertical Pixel spacing, but not the pixel spacing itself! That's true because there is/was no need to determine the size of a pixel; the ratio is sufficient for scaling an image according to the pixel aspect ratio. Btw, what exactly do you...

Currently, i.e. for the current snapshot, there is no pre-compiled libiconv provided by our team. Usually, we only make available these packages for official DCMTK releases. So in the meantime, you'll have to compile libconv on your own ... Btw, why does the current DCMTK snapshot fail to compile (i...

So, the C-FIND responses use different character sets. Since your UI uses UTF-8, it would probably make sense to convert all C-FIND response datasets to UTF-8 before displaying any values. Fortunately, we have implemented this conversion in the latest DCMTK snapshot (based on libiconv). Also see thi...

Where did you read that "UTF-8" is the correct term for UTF-8? It's "ISO_IR 192" (see section C.12.1.1.2 in part 3 of the DICOM standard). Also, the SpecificCharacterSet (0008,0005) attribute is treated differently for Query/Retrieve (see DICOM standard part 4). And finally, what...

Unfortunately, I cannot help you with the Apple-related stuff but in addition to "make install" you also need "make install-lib" (or use "make install-all" for both) - see INSTALL file for details: Step 3: make install Step 3 will install the executables and some suppor...

I read the Dicom standard Part-4 Annex C, and find the above attributes not belong to series level, I think it is the root cause

That's right.

but I use the same code to access the local sever(DCM4CHEE), I can get all the information!

This is something you should ask the author(s) of DCM4CHEE.