Hi;

I wanted to ask about who or how the way to encode an element of type SQ is decided when serializing a DICOM object received by the network to a file.

I know there are ways to encode a SQ (Explicit Length or Undefined Length), but I don't know how to indicate which method to use.
(PS3.5> 7.5.2) http://dicom.nema.org/medical/Dicom/2017c/output/chtml/part05/sect_7.5.2.html

Perhaps it is something that the DICOM parser decides when serializing to file? Because the Transfer Syntax, when it indicates whether it is Explicit or Implicit, does not refer to how to encode an element of type SQ, that attribute of the Transfer
Syntax refers to how it is indicated data type code of every DICOM element.

We have a problem with a customer:
Our component is a PACS, and when the customer makes a QR (at the end, our PACS makes a StoreSCU against the customer's StoreSCP) to obtain a DICOM object, as a result the customer obtains a DICOM file with all the SQ elements encoded in Undefined Length
form. This customer wants all the SQs in Explicit Length. So, is there something wrong with our part? Or is it something that only the customer can solve?

I have come to the conclusion that the way to encode the SQs is something that cannot be negotiated in the DICOM association, and that it is something that corresponds solely and exclusively to the component that receives the stream and serializes it to
a file (therefore it is something that corresponds to the client to solve since on our side we can do little). Do you agree?

I know there are many questions, but it is not necessary to answer them all, simply having a cross-sectional understanding of how this issue is resolved would help me a lot.

Thank you and take care.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The SQ encoding cannot be negotiated. It is initially chosen by the modality that generates the data set, and my opinion is that a PACS that changes the SQ encoding is ill-behaved (though I don't know if the standard says anything about this).

The delimiters are data elements, and are therefore part of the data set, even though they are purely syntactic and have no semantic meaning. So I think it's incorrect to say that their use is up to the software that writes the file. It seems to me that
if they are in the data set, they should be written to the file, and if they aren't in the data set, they should not be added to the file. Others might have a different opinion, of course.

Conforming DICOM equipment must accept both defined and undefined length sequences. Additionally, a DICOM data set is allowed to contain a mix of defined length and undefined length sequences.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I'm going to qualify my assertion that "delimiters are data elements, and are therefore part of the data set." In PS 3.19 Appendix A (http://dicom.nema.org/medical/dicom/current/output/chtml/part19/chapter_a.html), the XML encoding of data sets
eliminates the following:

1. Group length attributes
2. Sequences of zero length
3. Sequence delimiters

So Part 19 does not consider delimiters to be worth keeping track of during xml-based transformations of the data.

On the other hand, gdcm and dcmtk both keep track of which sequences have undefined length and which ones have explicit length, within their internal C++ data structures at least.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

A further correction:

2. Sequences of zero length

Part 19 doesn't state that the XML encoding eliminates sequences of zero length, it just seems to state that no items are allowed to be encoded within a sequence of zero length (PS 3.19 Table A.1.5-2).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)