<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> Orthanc will not modify the file by itself, except if the input file is<br>
> corrupted<br>
<br>
I hadn't been made aware of this "except" so far. This means<br>
more testing will need to be done because eventually Orthanc<br>
_does_ modify input files sometimes. Sigh.<br></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> which could lead to undefined behavior. Garbage in, garbage out.<br>
<br>
Sure, but so far I'd have assumed "garbage in, SAME garbage out".<br></blockquote><div><br></div><div>Unfortunately, you cannot make this assumption, as the decoder might behave in some undefined fashion when faced with a corrupted DICOM file.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Note that I fully understand the desire to accept and store<br>
the garbage (as [part of] the saying goes "be liberal in what<br>
you accept"). However, it'd be helpful if there was either<br>
documentation that Orthanc does indeed sometimes modify files<br>
on its own or else if there was even a configuration option<br>
for skip improworsening of DICOM files handed out. Orthanc<br>
would be the tool of the day if it offered a REST field /<br>
DICOM tag / whatever saying "Orthanc thinks this file is<br>
broken because ..." and the web frontend would offer buttons<br>
"display original", "display fixed", "fix permanently" ;-)<br>
<br>
Yeah, I know, making suggestions is cheap... :-)<br></blockquote><div><br></div><div>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").</div><div><br></div><div>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.</div><div><br></div><div>Check out the "OrthancPluginRegisterOnStoredInstanceCallback()" function for this purpose:</div><div><div><a href="https://orthanc.chu.ulg.ac.be/sdk/group__Callbacks.html#ga1af7c8c9877aaf670208bfc53164b9fb">https://orthanc.chu.ulg.ac.be/sdk/group__Callbacks.html#ga1af7c8c9877aaf670208bfc53164b9fb</a><br></div></div><div><br></div><div>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...</div></div>
</div></div>