Call DicomRemap from within Java program

[Simon Doran]

Hi Kevin,

  Could you give me some advice as to the best way to proceed?

  I want to make use of the facilities of DicomRemap from within a Java program that I am writing. The specific use case is that my utility XNATDataChooser now has (almost) the facility to select studies from one XNAT instance and export them directly to another with anonymisation. This is a very common task at our institution, where we have one XNAT directly connected to the clinical scanners, and containing patient-identifiable data, but a different version of XNAT that people actually use for their research, where the data are all anonymised.

  The command I want to run is something along the lines of 

DicomRemap -d anon_script.das -o dicom:<XNAT DICOM receiver> <file list>

and it seems to me that there are three possible routes here.

1. Use Java's ProcessBuilder class to recreate precisely this command and issue it to the OS.

    Advantage: It should be really easy.

    Disadvantage: Not portable; relies on DicomRemap being present on the path the Java program has access to, and this is not guaranteed to be the case without the end user installing it.

2. As 1, but add the DicomBrowser bin and lib directories to my Java program's distribution.

    Advantage: Portable

    Disadvantage: An OS call is not necessarily optimal when you have made the source code of the Java available.

3. Make use of the DicomBrowser source code itself (via the "main" method of file CSVRemapper.java???)

    Advantage: Direct calls from my Java program to other Java code 

    Disadvantage: Potentially more work to implement

  So my question is which route would you recommend?

  Best wishes,

Simon

[Kevin Archie]

Hi, Simon,

I’d lean strongly towards incorporating the DB jars into your project and calling the methods directly. There’ll be a little bit of work sorting out the dependencies (depending on your build tool, maybe made easier by having all the jars in one place in the .tgz) but in the long run it will be easier to keep everything inside one JVM.

  - Kevin

--
You received this message because you are subscribed to the Google Groups "DicomBrowser users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dicombrowser-us...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Simon Doran]

Thanks, Kevin.

Have I identified the correct entry point. Should I just call the main method of CVSRemapper.java with the same arguments that I would use on the command line?

Best wishes,

Simon

[Kevin Archie]

Simon,

That would work. If I were doing it I’d probably want to skip all the option processing, so I’d copy-and-paste the relevant parts from CSVRemapper::main into my own application-internal driver method and then remove things until I had only the parts I needed.

Thinking about it, CSVRemapper has extra functionality (the spreadsheet mapper) and DicomBrowser has lots of stuff related to display and manual edit that are all probably unnecessary complications for your use case. Take a look at this class: https://bitbucket.org/nrg/nrg_anonymize_1_6dev/src/tip/src/main/java/org/nrg/dcm/Anonymize.java , which is how XNAT calls the DicomEdit engine. It’s not exactly how I would have written it (not idiomatic Java in a few ways) but the ideas are there, especially if you look at the static methods down towards the bottom of the file. If you’re using a build tool with transitive dependencies (e.g., Maven 2+) then you probably only need to refer to DicomEdit and all the other dependencies should work themselves out.

  - Kevin