[BitBucket user: Tomas Zubiri]
[BitBucket date: 2019-11-08.00:56:13]
Orthanc is one of the best libre DICOM technologies around, in my experience this is one of its most notable missing features: Orthanc doesn’t accept Grayscale presentation states, which is what most dicom compliant programs use to send images for printing.
If Orthanc were to accept this format, it could effectively be configured in most modalities as a printer, in addition to being configured as a pacs.
The most common use case is to receive printjobs from DICOM speaking modalities and send printjobs to printers through their specific drivers. This is used to avoid installing drivers in modalities and simplify architectures.
This is commonly known as a print server, here are commercial examples of such a thing:
https://dicom.offis.de/dcmprint.php.en
http://www.charruasoft.com/products/printscp/index.php
It’s possible that dcmprscp or dcmprscu could be used as a print server, but these are not public facing tools.
There are other usecases for adding Orthanc as a printer instead of a pacs, for example, in scenarios like Ultrasound, the presentation state sent to the printer might be more important than the one saved to the pacs, since that is what is sent to the referring physicians, and in the case of ultrasound, there isn’t a significant information difference between what is presented to the medic and what is saved to the pacs, \(unlike Computed tomography, and to a lesser extent two dimensional radiographies.\)
So in this case it’s more useful to save the images being sent to the printer, rather than the separate images as sent to the pacs.
The default behaviour of Orthanc would be to store the image in its database as it would any other image. The Orhtanc instance could be configured, through LUA, a C plugin or through the rest api, to convert the dicom image to a png format and send it to any printer through a 3rd party driver.
The dicom protocol for printing includes several parameters for page sizes, paper used and other details. These could be forwarded to the api consumer through dicom metadata, or as parameters in a callback.
What would the complexity of implementing this be? Can I add a presentation state through the plugin API or would this need to be a core modification?
There are 2 options:
Option 1\)
Write a C plugin that implements a callback for Store operations. Check the presentation context, if its basic grayscale, call a new user-implemented C or Lua callback function. Possibly delete the image?
This is a very raw implementation, we would be ignoring parameters like how many images should fit in one page. Which is used a lot for TC scans. In this case, as a callback consumer, I would implement an ImageMagick script that arrays images in a matrix http://www.imagemagick.org/Usage/montage/
Option 2 would be to bake the use of imagemagick into orthanc and provide support for the rest of the dicom print parameters.
Perhaps option 1 can be implemented in a way that option 2 can be incrementally added later.
Thank you for your time.
|