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

[Sébastien Jodogne]

>
> > Orthanc will not modify the file by itself, except if the input file is
> > corrupted
>
> I hadn't been made aware of this "except" so far. This means
> more testing will need to be done because eventually Orthanc
> _does_ modify input files sometimes. Sigh.
>

Well, Orthanc does not modify the *content* of the DICOM file, BUT
syntactic variants such as the padding or the explicit/implicit length
encoding might change.


> which could lead to undefined behavior. Garbage in, garbage out.
>
> Sure, but so far I'd have assumed "garbage in, SAME garbage out".
>

Unfortunately, you cannot make this assumption, as the decoder might behave
in some undefined fashion when faced with a corrupted DICOM file.



> Note that I fully understand the desire to accept and store
> the garbage (as [part of] the saying goes "be liberal in what
> you accept"). However, it'd be helpful if there was either
> documentation that Orthanc does indeed sometimes modify files
> on its own or else if there was even a configuration option
> for skip improworsening of DICOM files handed out. Orthanc
> would be the tool of the day if it offered a REST field /
> DICOM tag / whatever saying "Orthanc thinks this file is
> broken because ..." and the web frontend would offer buttons
> "display original", "display fixed", "fix permanently" ;-)
>
> Yeah, I know, making suggestions is cheap... :-)
>

The philosophy of Orthanc is indeed to accept any DICOM file, as soon as it
can be parsed and it contains the 4 mandatory tags PatientID +
StudyInstanceUID + SeriesInstanceUID + SOPInstanceUID. This is the most
liberal approach in the DICOM (I often talk about "least common
denominator").

However, a third-party C/C++ plugin for Orthanc could be implemented to
check the validity of each incoming DICOM file thanks to David Clunie's
dicom3tools (more precisely by calling "dciodvfy"). This would allow to
track corrupted files in the way you suggest. Incoming files could be
tagged and/or send to a kind of purgatory.

Check out the "OrthancPluginRegisterOnStoredInstanceCallback()" function
for this purpose:
https://orthanc.chu.ulg.ac.be/sdk/group__Callbacks.html#ga1af7c8c9877aaf670208bfc53164b9fb

As always, because I have already way too much work but few development
support, I unfortunately cannot implement such a plugin by myself in the
next few months...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20160131/ca5220f1/attachment.html>