Trouble finding documentation

  • To all,
    First, thanks for the great server! I've gotten it up and running in CentOS 5.4 64-bit with very little difficulty and setup a sink server (sql=null) which is working great for our purposes.


    What I can't seem to find is a single concise listing of how the ExportConverter functionality actually works. Our group uses a QA script that's being run (somewhat haphazardly) in a cron job on our old server. I'd like to be able to tie it directly into the new server using an export script once the entire study has been transferred.


    I noticed some mentions of functionality for a command 'process by' that seems to be able to work on an image/series/study basis but I can't find any actual documentation of the feature in the manuals and only haphazard snippets in the forums.


    From what I've gathered I'd just need to do the following:


    Code
    ExportConverters = 1
    ExportModality0 = 0
    ExportConverter0 = process study by <QA Script>


    Is that correct or is there something else to this? I figure I'll have to make a wrapper script for the QA functions that takes the input correctly as well but there doesn't seem to be any documentation on what that output would actually look like.

  • hi,


    this is exactly how it works. <QA script> is a string in which you can fill in things like patient id, studyuid, or whatever you can read from the images at a study level. The expanded string is passed to the C-function system() once per recieved study (after a delay of default 10 minutes, to make sure the study is completed). Try e.g.,


    ExportConverters = 1
    ExportConverter0 = process study by echo %p:%V0020,000D > log.log


    Most useful commands have to go into the DICOM files to do their job. In your case, the DICOM file naming should be such that you can locate them at study level from your script or application without reverting to a database (which you have disabled). You output your data to a log file or such. Do not put ';' inside the command string, though.


    Marcel

  • Ok, so if I'm reading this correctly that means the 'process study by' is just a control for when to kick off the export converter, it doesn't actually provide any pathing information about the study in question? In that case, do the same '%' codes that apply to the FileNameSyntax apply here as well? If they do then I'll just pass the base directory on to the script as an argument. (I can't test the suggested test info right now as access to our scanner is fairly restricted).


    Thanks in Advance!

  • Marcel,
    This project fell on the back burner and is being dusted off and looked at again. As per your suggestion I've attempted to simply invoke the duke QA scripts (http://www.nitrc.org/projects/bxh_xcede_tools/) from conquest using export scripts. However when I do I run into some issues with the invoked command as demonstrated below:


    The configuration invoking this appears as follows:


    It appears what is happening is that any % symbol next to a / is being consumed by the / but I'm not sure why. It also appears to be inserting the ConquestAE and the CallingAE at some of these locations.

  • Marcel,
    I've got the basic calls looking correct now based on the export controls. However I'm having some issues with what appears to be either order of operations or execution context.


    Current export filters:


    edit - I've since figured out that these all need to be compacted into a single exportconverter. I am however having some issues getting them to execute correctly as they seem to be staging wrong.
    Log Output from a small basic data set.



    Any idea what is up here? The server has no issue making folders on it's own.


    Also, if your executing these processes at the change in uid of a series (based on process series by X), what is the purpose of having the ForwardCollectDelay at all? Couldn't it simply be set to 1 or 2 seconds and left to execute out of band? And what are the implications if the files are not sent in image order, we have a scanner here that doesn't deliver them in sequential order for reasons not entirely clear to me at the moment.

  • Hi,


    the delay is there to ensure that a series is completely transferrd before the process command triggers. Since indeed data is often sent out of order, the delay is long enough to get the entire transfer in.


    To fix the mkdir issue, you can use the built-in mkdir command of 1.4.16; it will just make the directory once even if called for each image and it will create multiple subdirectories at once, greatly simplifying your process. Process by uses a system() call and includes all characters up to a ;. It does not use quotes around the call. I would create a shell script that processes both commands at once for simplicity.


    E.g.


    Exportconvertor0 = mkdir /mnt/cd/scratch/dicom-srv-test/conquest/%u/%V0008,0020[0,3]/%V0010,0010/%V0008,1030/%V0008,0020[4,7]-%V0040,0245[0,3]/qa/%V0020,0011; process series by script.sh /mnt/cd/scratch/dicom-srv-test/conquest/%u/%V0008,0020[0,3]/%V0010,0010/%V0008,1030/%V0008,0020[4,7]-%V0040,0245[0,3]/%V0020,0011;


    Marcel

  • Marcel,
    That makes the most sense and I'm working on an appropriate script now. A follow up question however. If I can make the script handle an entire session at a time, is there a reason to configure the time lag to anything other than 1 or 2 seconds (since ostensibly it's timeout should be setoff when the session transfer ends?). I don't necessarily need to process these QA tests per series, I could just as easily hit the whole dataset at the end and it would be nice to just have it kick off once the transfer thread does it's close out.

  • Hi,


    alas, the timeout starts (incorrectly) when the session starts.... So I would keep it a bit longer. And with out of order reception there could be hundreds of other images received between images belonging to one series.


    For debugging I usually set it to 10s.


    Marcel

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!