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

[Sébastien Jodogne]

Dear David,

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. [...]
>>
>
> 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). [...]


I fully agree with you, but just for clarity sake: What I wrote above is
the description of an implementation choice of Orthanc.

If Orthanc receives a DICOM instance through REST or DICOMweb, the instance
will be stored as such on the hard disk (i.e. byte-to-byte identical). If
Orthanc receives an instance through a DIMSE message, the file might not be
byte-to-byte identical to the source instance (because things such as
repadding might occur). In both cases, if the DCMTK parser is not able to
decode the DICOM instance, or if one of the DICOM tags PatientID,
StudyInstanceUID, SeriesInstanceUID or SOPInstanceUID is missing, the
instance will not be stored by Orthanc.

This is how Orthanc is designed, as an answer to Karsten's question...
Obviously, I do not pretend this is the best convention, and other
DICOM/DICOMweb servers might not follow the same conventions as Orthanc. :)

The sense of my answer was also to say that a plugin could be developed to
turn Orthanc into a strict server that would only accept 100% conformant
DICOM instances.

Regards,
Sébastien-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20160201/81e69d56/attachment.html>