DICOM @ OFFIS

I was asking for the output of the presentation contexts (option -d or +v).

FYI: Now, there is a "getscu" in the current development version of the DCMTK. See this commit. Of course, it will also be part of the next snapshot.

Using getscu with option -d or +v would help to check whether there is a problem with the association negotiation.

As far as I can see, the problem is related to the trailing "\" in the path you've provided to the -dfp option. The following " is not treated as expected if there is a \ in front of it. And in multi-process mode the wlmscpfs tool adds " around all parameters (as far as I remembe...

As far as I understand it, the term "excess padding" refers to the end of the pixel data stream. How should the "receiving application" know that there is an "intra-frame padding"? Here's another paragraph from the referenced section: Also, the Value Field containing Pi...

Read PS 3.5-2011 Section 8.1.1:

In a multi-frame object that is transmitted in Native Format, the individual frames are not padded. The
individual frames shall be concatenated and padding bits (if necessary) apply to the complete Value
Field.

I guess this issue is already fixed in the current DCMTK release 3.6.0. See this commit.

The new option --invalid-item-value (-Ev) should do. Please note, however, that this option is only available for DCMTK 3.6.1 snapshots (after 20110318).

To the original poster: You should also inform the creator of these SR documents that they are not DICOM compliant!

And here's another sentence from PS3.5 that proves the "implicit" aspect:

The Command Set structure as specified in PS 3.7 is encoded using the Little Endian Implicit VR
Transfer Syntax.

The original poster was asking for command sets (not for data sets), so here's the relevant paragraph from DICOM PS3.7-2011: 6.3.1 COMMAND SET STRUCTURE The Command Elements in a Command Set shall be ordered by increasing Command Element Tag number. A Command Element Tag uniquely identifies a Comman...

So the DICOM file is corrupted. However, you can ignore the wrong meta header group length with the dcmdump option --ignore-meta-length. In your program, you could set the corresponding parser flag: dcmIgnoreFileMetaInformationGroupLength.set(OFTrue); Unfortunately, this flag is not available in DCM...

And what is the output with dcmdump in debug mode? Btw, you should use the current DCMTK release 3.6.0 instead of 3.5.4, which is almost 6 years old.

First of all, the stucture of these LUT tables is described in part 3 of the DICOM standard. You should really read that! You have said that these LUTs contain monochrome/gray values only. And we have noticed that these values are from 16 to 4031. These values are weird to us. Because as far as we a...

In order to load a DICOM file (like this LUT file) with DCMTK, you can simply use DcmFileFormat::loadFile(). The complete code that is used for DICOMscope can be found in DVInterface::selectDisplayPresentationLUT(). They are seems like the grayscale values, but not the complete list of them. No, bec...

These are LUT files are in fact DICOM files, so you can use dcmdump to show their contents. For example: # dcmdump (1/1): darken256us.lut # Dicom-File-Format # Dicom-Meta-Information-Header # Used TransferSyntax: Little Endian Explicit (0002,0000) UL 194 # 4, 1 FileMetaInformationGroupLength (0002,0...