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-
