Posts by joelspangler

Expanding on Marcel's comment - if you don't know the hostname, but know the current IP address of the device, you can do ping -a IPAddress which should return the DNS/Hostname. The DNS name should follow the device as it picks up new IP addresses.

The *.dcm will store automatically. It will store to whatever MAG0 is + FileNameSyntax in the DICOM.ini file. If you didn't change anything it will create a folder called "data" under the file directory where you ran conquestDICOMServer.exe from. The Filenamesyntax by default is = %V0010,0020\%V0020,000D\%sopuid.dcm

for the .jpg, I tested the following code (add this to the bottom of your dicom.ini - if you already have an importconverter, you might have to change the number from 0.

ImportConverter0 = save jpg to c:\datajpg\%V0010,0020-%V0008,0018.jpg

***when I tried to create subfolders (c:\datajpg\%V0010,0020\%V0008,0018.jpg) conquest failed to store the images! The above code stores them, but doesn't neatly segregate them by PatientID/MRN. I only tried in 1.4.17d on windows7 - unsure if other versions can create sub folders.

The manual covers a couple ways to convert DICOM to an image file. For files sitting in the database, you could use commands against dgate.exe - specifically conversion options:
--convert_to_gif:file,size,out,l/w/f Downsize and convert to mono GIF
--convert_to_bmp:file,size,out,l/w/f Downsize and convert to color BMP
--convert_to_jpg:file,size,out,l/w/f Downsize and convert to color JPG

For incoming dicom you can use input/export converters:
save bmp to filename.bmp save bitmap image to file
save gif to filename.gif save gif image to file
save jpg to filename.jpg save jpeg image to file
Unsure of where filename.XXX would get stored - you'd need to use some variables to make the filename unique for each image. Also unsure of how multi-frame DICOM objects would be handled - you might only get the first frame.

To receive DICOM - that's mostly done via network DICOM transfers. If you have DICOM as files, you can drag/drop onto the conquest interface (assuming enabled in dicom.ini). You can also copy the files to the Mag0\incoming folder (which would ingest them in to Conquest's database). Similar to the incoming folder you can also specifying a WatchFolder in the DICOM.ini file.

As far as JPG - I don't think there is a way to convert a JPEG file to a DICOM file using conquest - jpeg files wouldn't contain information like MRN, Name, DOB, etc, so Conquest wouldn't be able to properly create the DICOM files. When I need to convert a .jpg file to DICOM, I usually use a tool called Ginkgo CADX to do so.

you can only have one exportconverter0 - the second one would need to be 1.

This currently would export every incoming dicom object to REMOTEHOST - which probably isn't what you intended. You could use an ifmatch statement, but I'm not sure what the "trigger" would be. I've used something like:

ExportConverter0 = ifmatch %calledae", "ANON"; anonymize_script.cq
ExportConverter1 = ifmatch %calledae", "ANON"; forward compressed as jk to REMOTEHOST

This would look for incoming DICOM calling conquest by AE title ANON. I couldn't find the actual example that I was thinking about so code above might not be exactly correct, but should be close.

There are some other examples in the following thread, and you can check the manual for everything that you can match against.
http://forum.image-systems.biz/viewtopic.php?f=33&t=16072

And if you are worried about anonymizing burned in (image pixel) data such as on many ultrasound images and/or on CT dose pages, you can check out how I've blocked out pixels - it's a little tedious, but less so than using tools to remove this data manually. I've used (expanded versions) of this script to anonymize over 50,000 exams that research has used and shared with other groups.
http://forum.image-systems.biz…33&t=42252&p=54083#p54083

it doesn't by default, but adding that SOP class to allow conquest to store the images would be very easy. This would allow conquest to store the dicom encapsulated PDF files, the internal viewer wouldn't know how to handle them, but other tools would be ine.

To add support, open dgatesop.lst and add the following line: *note tabs might get converted to spaces - you might need to change them back to tabs if you copy/paste.

EncapsulatedPDFStorage 1.2.840.10008.5.1.4.1.1.104.1 sop

I don't think it really matters where you put it, but I generally add new SOP classes before the lines that end with "transfer".

I know I'm sort of hijacking this thread here but I'm curious why so many people try to use KPACS with conquest. From what I can tell, K-PACS development stopped many years ago and it doesn't work well with modern operating systems. The download page sais:

Quote

K-PACS is a NON-SUPPORTED software tool designed to work only in a Windows XP or Windows VISTA environment.

I used it a few times years ago and wasn't very impressed - why is there such interest with hooking it up with conquest. Why not use something more actively developed. If you want a client based solution I like Ginkgo CADx and if you want to go with browser based viewing there is Weasis. There are 100's of DICOM viewing solutions - why is KPACS interest so prevalent?

I upgraded the back-end server to 1.4.19alpha (by replacing dgate.exe, dgate64.exe, conquestdicomserver.exe, and cqdicom.dll) in my back-end application directory. Now that everything is on 1.4.19alpha the new web interface works fine. No modifications were made to any of the config files, the only difference was replacing the files mentioned.

So your suspicion that the back-end server can be an older version does not seem to actually be true.

I originally set up with cgi-bin\test\dgate.exe as a 1.4.17d, which resulted in a search page that never returned any results. When I changed cgi-bin\test\dgate.exe to 1.4.19alpha, it was still reporting as being 1.4.17d. I changed the main cgi-bin\dgate.exe to 1.4.19alpha, and search has begun to work, listing everying. I can view images as thumbnails, but when I try the "view study" button I get error:

*** lua run error wadostudyviewer.lua:22: attempt to index local 'str' (a nil value) in 'dofile('wadostudyviewer.lua')'

The back end gui (version 1.4.17d) shows activity
[ANON]
[ANON] UPACS THREAD 672: STARTED AT: Wed Dec 02 15:09:08 2015
[ANON] Calling Application Title : "none "
[ANON] Called Application Title : "ANON "
[ANON] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384
[ANON] Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.1" 1
[ANON] (StudyRootQuery) search level: IMAGE
[ANON] C-Find (StudyRoot) located 2 records
[ANON] UPACS THREAD 672: ENDED AT: Wed Dec 02 15:09:08 2015
[ANON] UPACS THREAD 672: TOTAL RUNNING TIME: 0 SECONDS
[ANON] getting image for wado viewer 90 140

I get a different error if I drive in deeper to where the "View series" button is available. Clicking on that results in
Server Error
502 - Web server received an invalid response while acting as a gateway or proxy server.
There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server.

Similar back-end activity happens in the gui.

You basically have two choices when building an in bound windows firewall rule, as a program or as a port.

For program you'd use %pathto%\dage.exe, and %pathto%\dgate64.exe (you probably only need one, but create rules for both to be safe)
If you use port, you'd need to open whatever port number dgate is listening to - I think it's something in the 5000's by default, but I almost always change it to the standard DICOM port (104). You can verify what port number you are using in the GUI on the Configuration tab (it's also in the dicom.ini under TCPPORT)

I don't know of a way to capture the IP address, but you can get the following - station name is probably unique, or could be modified on the modality to be unique.

%u=CallingAE
%s=stationname

To get to the log file, you could use the append command as an import converter - the example in the manual is written as:
append "date: %d" to file.txt

I suspect that you could use (untested)
ImportConverter0 = append "CallingAE: %u Station Name: %s" to serverstatus.log

Can you manually connect to the path using start - run (keyboard shortcut win+R)? If running conquest as a service, does whatever user it runs as have access to the path? I think a generic user named "SYSTEM" is the user by default, but you can change the user the service runs under from start/run services.msc

"Everyone" in windows terms generally means anyone with a valid account on a trusted authentication source (usually only itself unless part of a domain) so users still need to authenticate to be included as part of "Everyone"

When forwarding as a series or study, it waits for the entire study to be received before sending it out. Since conquest can't know for sure that there won't be any additional images, it waits a specified period of time. By default, the wait is 10 minutes and can be changed with ForwardCollectDelay in the .ini file.

You might need to use forward series instead of just forward, however I'm not sure that "forward series compressed as jk to DESTINATION" is valid syntax (manual is unclear - I didn't actually try). You might need to just "forward series to DESTINATION" and set up the destination's preferred syntax as jk (in the ACRNEMA.MAP file). If you want different compression levels, you might have to build multiple destinations in ACRNEMA.MAP.

If you are running one of Microsoft's more recent operating systems, you might need to close conquest - and run it as an administrator (right click conquestDICOMServer.exe and choose run as administrator). Once running as an admin, the process to create a windows service should work as expected.

It does get the images there - was just hoping save some bandwidth. I might yell at my PACS vendor as it's actually more of their issue.

Our PACS negotiates fairly aggressively for uncompressed images (it want's to store the images in it's non-DICOM compression scheme). Is there a way to not even propose 1.2.840.10008.1.2 with the current code? If not - please don't spend any additional time looking into it.

Tried J3, J4 and Jk compressions - all resulted in "Accepted compression: ui" messages.

I looked in the PACS to find examples of images using compression. Below are some of the transfer syntax's found:

1.2.840.10008.1.2.4.50 - JPEG Baseline (lossy)
1.2.840.10008.1.2.4.51 - JPEG Extended (lossy)
1.2.840.10008.1.2.4.90 - JPEG 2000 (Lossless)

The list above is just what I could find examples of - it almost certainly isn't a complete list.

I've already tried JL, J2 and J6 - I will try J3, J4 and Jk which I believe line up with the Transfer systax's I found above. I probably won't be able to actually test until sometime monday.

Conquest doesn't technically need to be installed in the traditional setup.exe (or .msi) fashion. I would speculate that both packages could co-exist on the same machine - you'd just need to make sure that the listening port# is setup differently. For example they both wouldn't be able to listen to the standard DICOM port (104) at the same time.

I'm also a little confused - kpacs was developed/released a long time ago when windows 2000 was the main OS - my understanding is that it runs on XP, but it can't run on more modern operating systems such as windows Vista, win 7, nor win 8 (http://forum.image-systems.biz/viewtopic.php?f=1&t=43417). Is there something I'm missing for how you intend to install on win 7?

I have an instance where I'm trying to forward a study to a DICOM destination as compressed. In the ACRNEMA.MAP destination is built specifying as jl, but whenever I forward (even if I use "forward compressed as jl to AETITLE") it doesn't actually listen. Logs say Accepted compression: ui I've also tried J2 and J6 with the same results.

I can't even find what UI stands for - assuming it's uncompressed implicit little endian, but I don't know that for sure. I know the DICOM node can/does store compressed images, but I can't get conquest to believe that. I've even gone so far as to try to comment out all uncompressed syntaxes from dgatesop.lst and it still somehow winds up doing the exact same thing. I upgraded from 1.4.17c to 17d with the same results.

Do you have any suggestions on how to force a specified compression method?