UN_SQ

[GabrielBianco]

I had an image in Implicit Little that my application encoded as Explicit Little. I wanted my code to treat an unkown data element (not in my dictionary) with undefined length as a sequence, but I made a mistake and it encoded it as UN. I wanted it to be SQ.

Here is the resulting image
http://rapidshare.com/files/7582934/UN_SQ.html

Now, even though that was a mistake on my part, that image should still be valid, right? All DICOM applications I tested with manage to read it properly, with the exception of the DCMTK tools :(

The error I get is:

DcmItem: Length of attribute (0008,0100) is odd
DcmElement: CodeValue(0008,0100) larger (411731) that remaining bytes in file
Error: Invalid Stream: reading file: UN_SQ

After manually changing the VR from UN to SQ, it works.

It's a quite a weird error. It goes into to the sequence properly (it knows a UN with undefined length is a SQ), but once it gets to the first data element in the first item, it reads it as Implicit Little, and obviously gets the wrong length... Why would it be reading the data elements in the UN sequence as Implicit Little?

[Michael Onken]

Hi Gabriel,

there was a correction proposal CP 245, that defines, that "Undefined length UN VR value is always implicit VR".

If you use dcmdump, you can disable this behaviour on demand:

handling of undefined length UN elements:
+ui --enable-cp246 read undefined len UN as implicit VR (default)
-ui --disable-cp246 read undefined len UN as explicit VR

By the way, this command line option was introduced with the latest release (3.5.4), so dcmdump from DCMTK 3.5.3 will display your file completely, because it does not "know" of CP 246.

Regards,
Michael

[GabrielBianco]

Ohh, I see ... But why is that? Whats the reason to always use implicit VR?

And what about dcmcjpeg and dcmdjpeg?

[Michael Onken]

This is the reason given in the Correction Proposal linked above:

Rationale for Correction

The UN VR only needs to ever be used when receiving a dataset in implicit VR little endian (IVRLE) transfer syntax. For all other transfer syntaxes the VR is explicit and therefore UN is not needed.

If one were to receive, in IVRLE, a sequence with a defined length, then one would have no way of knowing it was a sequence, and would copy the bytes verbatim to the output and designate the VR as UN. The contents of this value would therefore be "a sequence in IVRLE". There is no way to avoid this.

If on the other hand, the value length was undefined, one has to parse it as a sequence, recursively, down to either the data element level or to the level at which a defined length item is found (e.g. as would be the case if it were a encapsulated pixel data in an OB rather than an SQ). In either case one has to make a decision as to whether to regurgitate it with a) the lengths unchanged or not, and b) in explicit or implicit VR. Since:

- there is no way of signaling in the output UN value whether it is encoded explicit or implicit VR

- in the defined length sequence case it will always be implicit VR

- the UN VR only exists to convert IVRLE streams to explicit the only reliable choice is to always encode the value of undefined length VR values received as IVRLE, with implicit VR, not explicit VR.

This interpretation is consistent with the existing statement in the standard that “the Unknown (UN) VR shall only be used for … Data Elements previously encoded … using the DICOM Default Transfer Syntax (Implicit VR Little Endian),”

[GabrielBianco]

That link doesn't work here... But the reason makes perfect sense. Matter of fact, I remember thinking about that when I was writing the code for the UN conversion.

Thanks for the help, Michael :-)