Recomended Way to Contribute

Hi, Sébastien!

I’d like to present a handful of updates to the Orthanc codebase. If they’re somehow incorporated, that’d be lovely.

Apologies in advance for this e-mail grew bigger by the minute.

I just don’t know the best way to do so. As of now, I’ve got a pretty clean checkout with said modifications. I was hoping to fork and possibly do a pull request. But I’m a newbie when it comes to opensource projects.

So I need help.

Over the last 6 months or so I’ve been working on a large PACS project based on Orthanc. During that period some modifications where made to the codebase, initially on the 1.3.2 version but yesterday I ported to the mainline. I’d love to have them contributed.

What has been done:

  • Two callbacks:

  • FilterIncomingInstance: it was available only for Lua scripts, or so it seemed

  • You can process the image or do something before it is actually stored. We use it to notify an external system of its arrival. This triggers a pooling system.

  • This was done based on this thread: https://groups.google.com/forum/#!searchin/orthanc-users/polling%7Csort:date/orthanc-users/EiO4KPVwSbU/tRcmT6NIRBgJ

  • DicomImageFilter:

  • When an archive is generated through the “/studies/(…)/archive” URI, we needed to strip some tags of the images whilst keeping the Orthanc storage intact. Through this callback we access the raw image content right before it gets written to the zip. And replace it.

  • So with a couple of dcmtk’ing we can pretty much do what we need with the images.- RestApi:

  • When the image was filtered, Orthanc should return 400 (Bad Request).- C Plugin Functions:

  • ExportImage: given AutomatedJpeg2kCompression example and considering compression to be driven by an external application, to compress an image, we have to call OrthancPluginGetDicomForInstance which reads the entire image into memory. Since we can have large images that amount to 500MB+ each, we couldn’t do with loading them into memory only to write it to disk right after that. Hence this function was created. In the end it calls boost::filesystem::copy_file. Then we call gdcmconv (actually our own, but that’s for another day).- Other modifications:

  • SIGCHLD: we reset it after calling mg_start because we experienced problems invoking external programs with Linux syscall popen. What happened was we were getting incorrect responses when dealing with pclose (false negatives and positives).

  • According to mongoose.h: Side-effects: on UNIX, ignores SIGCHLD and SIGPIPE signals. If custom processing is required for these, signal handlers must be set up after calling mg_start()

  • In theory, no harm done.

  • Also while generating the study archive, we needed the images inside the zip to be in the order determined by DICOM tag InstanceNumber. ServerIndex.cpp was modified to make it so.

  • For the record, we also modified the log format to include thread information so as to allow for better tracking of requests when dealing with issues.

These mods can (and should) be improved upon. For instance, the ExportImage was implemented for the Filesystem Storage driver only. Certainly many other need polishing.

Still, I’m reaching out because we feel they can be good additions to the core of Orthanc and would make Orthanc even better. Thanks everyone for the time put on writting it.

Hoping to hear from you soon,