Posts by joelspangler

I am experimenting with just this because my organization doesn't like other web server apps. I got it mostly working, on a windows 2008 server with IIS7. I say mostly as the weasis viewer that seems to be included by default in the 1.4.17d config files isn't working fully for me yet.

When installing IIS, I made sure to tell it to use CGI (was an option when installing from scratch)
Copied cgi-bin folder to C:\inetpub\wwwroot
In IIS Manager made the cgi-bin folder an application folder (right click and "convert to Application")
with the cgi-bin folder highlighted in IIS, clicked "handler mappings" and created a new one. I the line after creation shows
name = dgate
path = *.exe
state = enabled
file = unspecified
handler = cgimodule

That should get you working with responses to http://servername:8080/cgi-bin/dgate.exe?mode=top

I have weasis partially working - steps taken downloaded weasis portable (make sure you get a new version - my first google search got me one from 2011). Put the weasis directory from the archive in C:\inetpub\wwwroot. Make folder an application folder - add a MIME type of .jnlp - with MIME type application/x-java-jnlp-file. That should make weasis try to open rather than download as a file, but with the config files that came with 1.4.17d, I'm getting "Unable to launch the application" - and I haven't yet figured that out yet. I need to make time to really read through the sticky on Weasis to figure it out. I'll put the created launch file that is generated and exception below (note I am running the web server on port 8080, and had to modify C:\inetpub\wwwroot\cgi-bin\viewers - LaunchWeasisStudy.cq launchWeasis.cq to add the :8080 after %server_name% (both files needed to be modified in multiple places)

<jnlp spec="1.6+" codebase="http://tstvnadbw8k1v:8080/weasis" href="">  <information>    <title>Weasis</title>    <vendor>Weasis Team</vendor>    <description>DICOM images viewer</description>    <description kind="short">An application to visualize and analyze DICOM images.</description>    <description kind="one-line">DICOM images viewer</description>    <description kind="tooltip">Weasis</description>    <icon href="images/logo-button.png" kind="default"/>    <icon href="images/about.png" kind="splash"/>    <shortcut online="false">      <desktop/>      <menu submenu="Weasis"/>    </shortcut>  </information>  <security>    <all-permissions/>  </security>  <resources>    <j2se version="1.6.0_10+" href="http://java.sun.com/products/autodl/j2se" initial-heap-size="128m" max-heap-size="512m"/>    <j2se version="1.6.0_10+" initial-heap-size="128m" max-heap-size="512m"/>    <jar href="weasis-launcher.jar" main="true"/>    <jar href="felix.jar"/>    <extension href="substance.jnlp"/>    <property name="jnlp.packEnabled" value="true"/>  </resources>  <application-desc main-class="org.weasis.launcher.WebstartLauncher">    <argument>-VMPfelix.config.properties="http://tstvnadbw8k1v:8080/weasis/conf/config.properties"</argument>    <argument>-VMPfelix.extended.config.properties="http://tstvnadbw8k1v:8080/weasis/conf/ext-config.properties"</argument>    <argument>-VMPweasis.codebase.url="http://tstvnadbw8k1v:8080/weasis"</argument>    <argument>-VMPgosh.args="-sc telnetd -p 17179 start"</argument>    <argument>-VMPapple.laf.useScreenMenuBar="true"</argument>    <argument>-VMPweasis.i18n="http://tstvnadbw8k1v:8080/weasis-i18n"</argument>    <argument>$dicom:get -w http://10.230.30.70/cgi-bin/dgate.exe?port=107&address=10.230.30.70&mode=weasisstudyxml&compress=un&study=1137323678.1864233347:1.2.826.0.1.3680043.2.135.735333.28061483.7.1399385632.349.23&dum=.xml</argument>  </application-desc></jnlp>

java.lang.NullPointerException
	at java.util.Hashtable.put(Unknown Source)
	at java.util.Properties.setProperty(Unknown Source)
	at java.lang.System.setProperty(Unknown Source)
	at org.weasis.launcher.WeasisLauncher.loadProperties(WeasisLauncher.java)
	at org.weasis.launcher.WeasisLauncher.launch(WeasisLauncher.java)
	at org.weasis.launcher.WebstartLauncher.main(WebstartLauncher.java)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at com.sun.javaws.Launcher.executeApplication(Unknown Source)
	at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
	at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
	at com.sun.javaws.Launcher.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

I decided to just put them in the input folder and let it crunch though them - got through about 45% of them over the weekend. I figured out with my previous testing that it was compressing each image - now changed to "as" compression. I'm getting about 1000 studies per minute on average. Some benefits of doing it this way: the files are organized a bit more logically, and in the event of a crash the process is restartable without having to re-read any files. I thought about trying to set up two instances both hitting the same storage location and MSSQL database, but I was afraid that I might make a mistake and cause myself more issues.

I wouldn't be against renaming to .dcm, but files are in thousands of folders, and there are 15 million of them. I don't know of a bulk renaming tool that can handle that volume. I'd have to keep the full filename and add .dcm, so I'd go from something like 8ghy9h3v.1 to 8ghy9h3v.1.dcm

If anyone knows of a tool that can accomplish a mass-rename job like this, I'd appreciate information on it. Most tools I'm finding can only replace a file extensions, which would result in duplicate file names.

I upgraded to 1.4.17d (from 17c) today and ran against a larger test dataset. It now regens a small subset of images. It is picking up series with .1000 and higher filenames, but is still completely ignoring files with .1, .2, etc. Out of the 45K images that are in the directory, only 5.5K were recognized. Is there any configurable option to tell conquest what to inventory vs what to ignore when doing a regen? (ie - I'd like to tell it that .wav and .tsrt files shouldn't be inventoried)

Files have extensions of .1 through however many series the case has - so .2000 on a 2000 slice CT. Full file names would be something like 01K46HS8.1 - 01K46HS8.2000 (and these would be in a folder named 01K46HS8). When I tested the other day, I think i put one more "level" of directories in there so data\testdata\01K46HS8\01K46HS8.1 (does it only go so "deep" when re-indexing?

I don't have a log to send at this point, but will try again. Is there a specific re-index log, or would it be contained in one of the other logs (windows based instance)

I have about 15 million DICOM files (600k studies?) on an external disk array. Disk has DICOM files only (no software) and I'm hoping to import them into an instance of conquest, then make available to other systems via query/retrieve. Is there a way to have conquest simply inventory the files (ie put them in the database), but leave the file structure on the external disk array as-is? The folder structure is a random 8 character alpha-numeric folder for each study, and DICOM files within are that same random name + .1 .2 .3 (up to .2000 or higher for large CT studies - files do not have a .dcm identifier). Initial testing of putting a sample of the files in the "data" folder and telling the system to re-inventory failed - the files were not recognized. Placing files in a watch folder or the "incoming" folder works, but conquest seems to only inventory one single file at a time, and it seems to copy to a new folder then delete the original rather than just move the existing file. The speed of the sampling that I did was slow, so much so that my calculations say that it would take about 5 days to complete importing via this method.

What is the best/fastest way of importing these files using conquest and/or another tool (if there is something better suited for my situation).

You may be able to bind the webpage to a non-standard port - I'm betting the cisco client is only blocking HTTP port 80 and HTTPS 443.

It took me a bit to figure out how to actually send the DICOM file from inside the lua script. I initially expected to just add "forward to AETITLE" to the .lua code, but that does not work. In order to pass the command back to conquest you must print(script('conquestcodehere')). My final looks very similar to my original code above:

if  Filename:match "watchfolder.ToPACS" then
	print ('matches ToPACS', Filename)
	print(script('forward to PACS'))

I have c:\watchfolder set up, with a sub directory of ToPACS. When a DICOM file is dropped in the "c:\watchfolder\ToPACS" folder my lua code is run. The first line of code (the if statement) looks for a match. The second line of code displays information about which subfolder the file matched (I currently have 8 sub-directories, so this is just for informational/troubleshooting purposes - information is displayed in the "server status" tab as well as the log file). The last line basically just passes "forward to PACS" back to conquest to do the actual work of doing the DICOM transfer. (this can accomplish more than just forwarding files if you do ConquestTask1;ConquestTask2;etc). As in the first example, you can do multiple levels with elseif statements, and the if loop needs closed out with an 'end'.

All-in-all I'm thrilled that I've been able to get this working. The results of using conquest are much more robust and faster than I've previously been able to accomplish using .bat files and the DCMTK/GDCM command line DICOM tools. As an even better bonus the always live watchfolder directory will allow me to let other staff from our radiology support group do some of the tasks that were previously too technical to pass on to others. Many thanks to Marcel for making such a great solution freely available!

I got a bit of time to look into this a bit further today. The trick of putting a read only file into each subfolder works well. I researched lua code a bit and found that I don't have to parse the string because lua has a match function. The following code doesn't yet actually forward studies anywhere, but it does successfully identify between subfolders "Folder1" and "Folder2" under my watchfolder. To add more subfolders I'd simply need to add more Elseif lines.

if Filename:match "watchfoldername.Folder1" then
	print ('matches Folder1 - ', Filename)
elseif  Filename:match "watchfoldername.Folder2" then
	print ('matches Folder2', Filename)
end

The path in the sample above is "watchfoldername.Folder2" If your directory is C:\WatchME\SubFolderName you'd search for "WatchMe.SubFolderName" I couldn't figure out how to match special characters, so I dropped the c:\ and put a wildcard (.) in for the \ character. I'm sure there is a more exact way to match these - but finding the syntax for special characters in LUA has proven a bit difficult. In any case, searching this way results in not finding files whose filename happens to match the directory name (ie - I named a file folder1.dcm and it didn't mess up the matching logic)

so I played just a tiny bit more - it seemed that no matter what filename i put, it didnt' find my lua file. I moved my lua file to c:\dicomserver and it seems to like it there. I also figured out that I had to remove the importconverter part inside of the lua file. I'm now getting "[C60577] Is there a file dropped? C:\dicomserver\watchfolder\Homer.dcm" in my logging window.

I'll have to dig through the documentation to actually figure out how to get just the folder name, and also how to act upon that. I'll play and document what I find.

Also blank folders are being wiped out inside of the watchfolder. Is there a way to make it leave the folder structure alone?
Thanks,
Joel

You'll have to excuse my lack of understanding how LUA works.

Here's what I've done:
I created a file in the c:\dicomserver\lua directory named watchfolder.lua - contents were the code you sent - ImportConverter0 = print('Is there a file dropped?', Filename)
I then added the following to dicom.ini

ImportConverter0 = watchfolder.lua
ExportConverter0	              = watchfolder.lua

The following is from the server status tab (with debug enabled):
[C60577] *** Importconverter0.0 error: watchfolder.lua
[C60577] FreeStore Left 824785 on C:\
[C60577] Added file: C:\dicomserver\data\11111111\1.2.276.0.7230010.3.1.3.2745455252.10072.1332446330.240_0000_000000_13881774240000.dcm
[C60577] ***Exportconverter0: Spawning 'watchfolder.lua' failed (argv=C:\dicomserver\data\11111111\1.2.276.0.7230010.3.1.3.2745455252.10072.1332446330.240_0000_000000_13881774240000.dcm)

I'm not entirely sure what to try next - can you point me in the direction of where the code you sent was intended to go - I'm assuming it should either create a pop-up that gives me the filename - or add the file name to the log.
Thanks Again!
Joel

This appears to still be encoding the same way (the file sizes are the same) but the new files have 1.2.840.10008.1.2.4.70 in dicom tag 0002,0010. There must a decent difference between the compression types because the viewer app on the burned disks is still unable to open the DICOM files. I normally publish disks by dropping DICOM files in the CD Robot's shared directory, but I played with a normal DICOM network transfer. It kept negotiating uncompressed DICOM, until I found and modified a text file of acceptable transfer syntax's. On a whim, I changed the order of the file (on the CD robot) putting 1.2.840.10008.1.2.4.70 at the top... my next DICOM transfer negotiated to J1

Accepted compression: j1
Sending file : C:\dicomserver\data\[removed due to technically being Identifiyable PHI].dcm
[recompress]: recompressed with mode = j1 (strip=1)

Resulting files were slightly larger in size, but viewable on my burned disk. They are identified as .70 compression. So J1 must be 1.2.840.10008.1.2.4.70, whereas J2 is 1.2.840.10008.1.2.4.57

Is there a list of the various compression methods that also includes the associated Transfer Syntax used. In the manual there is a list that lists the various schemes (shortened list as example below):
AS (as is) * n/a as it would use the original transfer syntax.
IS (as is) * n/a as it would use the original transfer syntax.
UN (uncompress) *implicit/explicit big/little not defined - unsure what transfer syntax would be used.
J2 (jpeglosslessNH14) * two transfer syntax's could fit this name 1.2.840.10008.1.2.4.57 and 1.2.840.10008.1.2.4.70 according to http://www.dicomlibrary.com/dicom/transfer-syntax/
JK (Lossless JPEG2000) * would this be 1.2.840.10008.1.2.4.90?

I'm having trouble figuring out what DICOM transfer syntax (DICOM tag 0002,0010) resulting files will wind up having.

My current issue is that I used J2 and expected transfer syntax 1.2.840.10008.1.2.4.70, however the resulting files are 1.2.840.10008.1.2.4.57. These files are cause a weird issue with my rather finicky DVD burning solution. This solution accepts transfer syntax 4.57, however the included viewer only supports 4.70. Is there a way to force J2 to use transfer syntax 4.70 and/or another compression short-name to use that will result in using 4.70 as the transfer syntax?

Is it possible to create more than one Watchfolder? I've found the watchfolder along with auto-forwarding rules extremely helpful, but it seems I need to create a new instance for each folder/destination that I'd like to work with. I guess my request goes beyond multiple Watchfolders, I may also need a way to differentiate between them in my ExportConverter rules (Ie could I use something like ExportConverter0 = ifequal "%p, "c:\destination1\"; forward to destination1)

* To those who may have found this via a search for "watchfolder", here are some notes on how I got it working:
1 - When defining the WatchFolder in the dicom.ini you need to use a \ at the end of the path - WatchFolder = C:\pathto\watchfolder\
2 - In order to use import and export rules on watchfolders one must enable the ImportExportDragAndDrop function in dicom.ini (change from 0 to 1).