Hi Marcel,
My code probably isn't the most efficient but this works!
My SiemensDailyQAtoBMP.py script is then able to process image at its own pace and delete temporary .dcm image at the end.
Thanks for all your help,
John
Hi Marcel,
My code probably isn't the most efficient but this works!
My SiemensDailyQAtoBMP.py script is then able to process image at its own pace and delete temporary .dcm image at the end.
Thanks for all your help,
John
Hi Marcel,
Thanks for the guidance. I have managed to write a python script to convert overlay into a BMP which works great by itself. A DICOM overlay image was new to me!
I have never executed a script before using Importconverter but one quick question, when I run something like this:
It seems to work fine but also saves images to the server itself which I don't want it to do.
When I add destroy command like so:
ImportConverter0 = ifequal "%V0008,0016", "1.2.840.10008.5.1.4.1.1.7"; system "python c:\conquest_SIEMENSCTQA\SiemensDailyQAtoBMP.py %f"; destroy
The python script doesn't work so possibly the destroy command carries out just before the python script gets a chance to run? Should i build in a slight wait time or how best would you work this?
Apologies for the basic questions and thanks for your help so far.
John
Thanks Marcel, there is probably no straight forward way of converting that overlay to a jpg/pdf etc?
Hi All,
I'm wondering if anyone has come across a way of viewing/parsing results from a Daily CT QA image taken on a Siemens Somatom go.sim scanner? It looks to me like some sort of secondary capture image. It imports fine into Conquest but I can't seem to view the secondary capture and it doesn't seem to have the results explicitly in the header. See attached dicom file. Note this is 1 image file of 5 it creates.
Thanks,
John
Hi Marcel/Robert,
Still no luck here I'm afraid so I'm not sure whats going on. My dgatesop.lst seems to be correct too.
Very strange that you have the same system Robert and seem to be able to work fine.
I'll try a full re-install and scratch again. I'll also try using Wireshark as you suggested Marcel,
Thanks for your help,
John
Hi All,
So just to update this morning, Agfa have some back and said:
"For accession number - U13056692 we send formats:
MR and SR
MR - SOP is fully supported by EI
SR - SOP class is fully supported by EI
When I've checked the SOP classes for this accession I have noticed there is a rejection note here - SOP class '1.2.840.10008.5.1.4.1.1.88.59' - This could be the reason the external system is not accepting the images.
Please can you ask John to check if that SOP class is fully supported in the external system?"
Is this making any sense to you Marcel and is "SOP" class fully supported by ConQuest? Sorry if these are basic/obvious answers!
Thanks,
John
robertvanommen PS: it sounds like you are familiar with AGFA's enterprise imaging PAC's, do you happen to have Q/R working with AGFA PAC's system and would you be able to send on any details of a working ConQuest node including any compression settings?
Hi Robert,
Thanks for your suggestion but unfortunately I have no access to PAC's admin myself so I'm at their mercy to send on applicable screenshots. They have said they will also try and get back to me re:any compression being applied.
Re: AE,IP,port: I am confident they are all correct because I can use DCMTK software to query and retrieve successfully on that same machine.
Also images that come across look to be standard dicom after that DCMTK retrieve.
I'm open to any other suggestions though, hopefully I'm missing something obvious!
John
Hi Marcel,
See attached screenshot of our PAC's node set-up screen. I'm not sure if there is anything jumping out there as a culprit. They are hopefully going to refer back with more detail on any compression settings.
John
Hi Robert,
Thanks very much for your suggestion, I didn't know that about the GUI change by double-clicking.
I have tried that but to no avail. I have also manually used ZeroBraneStudio to query with the seriesUID seperatly so no good either.
I'm still waiting on a rely from PAC's so hopefully that will throw up something obvious.
John
Apologies Marcel, with further testing it looks like it was failing the drag and drop import due to being run as admin (which I need to keep it running as service). I discovered this the hard way but spotted this here: Drag and Drop not working Conquest
So PACS Retrieve function still not working but images ae importing through drag-drop no problem.
I will email PACS again and just verify that images are sent as a dicom format? Would that be the best question to ask them?
Apologies for all the questions, learning lots here so thanks!
John
Hi Marcel,
Another interesting thing I've just noticed is that when I retrieve images with DCMTK and then try and drag and drop (which usually works fine for any DICOM I've seen), it will not import images and also gives no error in logs.
The images, MR images in this case will open fine with ImageJ. Would you like me to try and send you the anonymized text header?
John
Hi Marcel,
I think I have enabled jpeg compression. I have attached screengrab of config tab and also the dgatesop.lst file (changed to .txt file).
I have also tried uncommenting out all parameters in dgatesop.lst file, restarted server and still no luck.
Let me know if I need to enable jpeg compression anywhere else.
Thanks,
John
Hi Marcel,
If you are referring to the "Enable Explicit and JPEG Transfers" switch then yes that option was always checked.
The images that were retrieved by DCMTK seemed to be a standard DICOM format?
Thanks,
John
Hi Marcel,
008,0052 is "QueryRetrieveLevel" so sorry, that was my fault. I had
a.QueryRetrieveLevel='PATIENT' set.
I have changed this again to:
So this is my output with STUDY level selected:
Using DCMTK software, STUDY level and the same UID I can successfully query and retrieve study.
Let me know if you can think of any other steps I can try.
Thanks for your help,
John
Hi Marcel,
So our PAC's system admins here have reviewed their settings and are happy on their side.
I have separately used DCMTK software and successfully queried and retrieved that same study so I'm coming back to ConQuest again to try see what's going on.
So by manually using ZBS with this:
It fails and in the serverstatus.log I get:
27/04/2021 09:47:52 [RTPHYSICS] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'
27/04/2021 09:47:52 [RTPHYSICS] 9999,0300 42 LO ConquestConsoleText "Server command sent using DGATE -- option"
27/04/2021 09:47:53 [RTPHYSICS] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'
27/04/2021 09:47:53 [RTPHYSICS] 9999,0300 42 LO ConquestConsoleText "Server command sent using DGATE -- option"
27/04/2021 09:47:53 [RTPHYSICS] 9999,0400 572 LO ConquestConsoleComma "luastart:xpcall(function() io.stdout:setvbuf('no');\n package.path = package.path ..";" .. "/lua/?.lua";\n package.cpath = package.cpath ..";" .. "/clibs/?.so";\n require('mobdebug').checkcount = 1;\n require('mobdebug').yield=function() if iup the"
Sorry to bother you again but if you can spot something, I'd love to get this working.
Thanks,
John
Thanks Marcel, I have tried dicommove from ZBS with the following code:
That Patient study is found successfully but it is still having issues retrieving image with the following output:
[RTPHYSICS] 0381930 XXXX^XXXX^^Mr. 20210319 MRI PELVIS PROSTATE 1.3.51.0.1.1.10.1.236.46.13056692.3599568
I will log a call with PAC's here and make sure everything is set up correctly on their side.
Fingers crossed!
Thanks for your help,
John
Hi Marcel,
Is it possible to use the DGATE command in command line to do a simple query and then try retrieve a study?
I see in the manual for a query to find a patient study it is:
So I've been trying use this but I'm failing and not too sure what to put in for "fmt" of "file" parameters
I'm using:
but I'm getting nothing back.
Then can I use --movestudy option to try and move patient?
Thanks for your help,
John
Hi Marcel,
That updated seems GUI file works perfect to query the PACs system so this is great thanks! That was a very fast fix!
However...my next problem is when I try to copy that query to destination (my ConQuest server), it fails with "***dicommove: remote DICOM error" so I wonder is there a chance that PAC's might have forgot to tick the "retrieve" box when setting up? Or else, would you have any other suggestions to test retrieve capabilities? Is there a similar retrieve .lua script to test?
I will try a debug the Web application myself and let you know. This might take me a while!
John
Hi Marcel,
Yes that works if I update line 13 with your suggestion.
That would be great to update GUI if possible. Would that then fix the Web application too?
When I try search same patient in Web Application I don't get any results/errors, see attached window. Let me know if there is further testing you would like me to try.
Thanks very much,
John