[Debian-med-packaging] Bug#753809: ginkgocadx and certain dicom files

[David Clunie]

Hi Karsten

On 1/31/16 3:37 PM, Karsten Hilbert wrote:

> Sure, but so far I'd have assumed "garbage in, SAME garbage out".

There is no reason to assume this.

If a DICOM storage SCP receives an invalidly constructed data
set, then it has no obligation to be able to cope with it,
though many implementations try very hard to clean up bad
stuff.

Even a valid data set is likely to be modified in various
minor or significant ways (coercion of identifiers, cleaning
up of padding, removal of retired group lengths, change in
fixed versus delimited sequence item encoding, and even
removal of private or non-standard or non-mandatory
attributes depending on the Storage SCP "level" that the
system supports). See, for example:

http://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_B.4.html#sect_B.4.1

On 1/31/16 4:34 PM, Sébastien Jodogne wrote:
>>> Unfortunately, you cannot make this assumption, as the decoder might
>> behave
>>> in some undefined fashion when faced with a corrupted DICOM file.
>>
>> I would not have thought that decoding is needed when
>> retrieving files for storage over DICOM but that only shows
>> my igorance regarding that protocol :-)
>
> Indeed, DICOM store piggybacks the DICOM instance together with the C-Store
> command itself. This unfortunately opens the path to many compatibilty
> problems related to non-conforming, proprietary implementations.
>
> Note however that, in the context of Orthanc, if the DICOM file is sent
> through the REST API, then this decoding/re-encoding chain does not take
> place (accordingly to your intuition). This would also be the case if
> DICOMweb STOW-RS is used.

A simple example of the importance of the correct encoding
of the data set and the need to be able to decode it, is
indexing ... if the data set cannot be parsed, then how can
one extract the patient and study and series identifiers to
use in the database so as to respond correctly to a query?

Or to put it another way, neither the data set that follows
the meta information header in a DICOM file, nor the data
set that follows a C-STORE command message on the network
(or an HTTP GET or POST), is an opaque bunch of bytes, but
has to be a correctly formed data set (just like an XML file
needs to be correctly formed to be parseable even if it
doesn't match the schema or DTD), if one is going to
extract anything from it.

Though many implementations try their best to cope with
really crappy data sets by fixing them, sometimes the
heuristics to fix one data set defect conflict with those
to fix other data set defects, so this gets really tricky.

Whether the data set arrives via a C-STORE or STOW makes
no difference to whether or not data set integrity and
compliance are required, at least beyond simply storing
the bytes (the DIMSE protocol is no more or less dependent
on the data set bytes after the command message than the
HTTP POST). Or more precisely, the command and data set
DIMSE messages are completely separated in terms of the way
they are packaged during encapsulation as Presentation
Data Values in Presentation Data Units, and the PDV
Message Header signals whether the fragment is a Command
or Data type; see:

 
http://dicom.nema.org/medical/dicom/current/output/chtml/part08/chapter_E.html

Unlike with STOW (or WADO-RS), one does not have to separate
the PS3.10 meta information header from the data set, because
there is no meta information header sent over the wire with
the DIMSE protocol.

On 1/31/16 1:15 PM, Karsten Hilbert wrote:
> On Sun, Jan 31, 2016 at 09:23:16AM -0500, David Clunie wrote:
>
>> I agree with Mathieu Malaterre. This is an invalid DICOM
>> file, so the bug is in the source system, not the
>> recipient.
>
> Well, that may be true (I can't verify).
>
> However, that fact doesn't have anything to do with the bug I reported.

Now hopefully you see why it does. What you reported does
not sound like a bug in the implementation, it is a "feature
request" to cope with a particular pattern of invalid input,
for which a fix might not necessarily lead to coping with
other patterns of invalid input.

Beyond that one bad file, a feature request to "store and index
any garbage that even vaguely resembles a DICOM instance" is
a pretty ambitious demand.

David