Posts by johncronin

Hi Marcel,

My code probably isn't the most efficient but this works!

ImportConverter0		= ifequal "%V0008,0016", "1.2.840.10008.5.1.4.1.1.7"; save to C:\conquest_SIEMENSCTQA\temp_store\%o.dcm;
ImportConverter1		= ifnotequal "%V0008,0016", "1.2.840.10008.5.1.4.1.1.7"; destroy;
ImportConverter2		= append "%f%n" to c:\conquest_SIEMENSCTQA\incoming.txt;
ImportConverter3		= system python c:\conquest_SIEMENSCTQA\SiemensDailyQAtoBMP.py C:\conquest_SIEMENSCTQA\temp_store\%o.dcm;
ImportConverter4		= destroy;

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:

• ImportConverter0 = ifequal "%V0008,0016", "1.2.840.10008.5.1.4.1.1.7"; system "python c:\conquest_SIEMENSCTQA\SiemensDailyQAtoBMP.py %f"

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:

a.QueryRetrieveLevel='STUDY'.

So this is my output with STUDY level selected:

27/04/2021 17:21:35 [RTPHYSICS] Server command sent using DGATE -- option
27/04/2021 17:21:35 [RTPHYSICS] Server command sent using DGATE -- option
27/04/2021 17:21:37 [RTPHYSICS] 0381930 XXXX^^Mr. 20210319 MRI PELVIS PROSTATE 1.3.51.0.1.1.10.1.236.46.13056692.3599568 U13056692
27/04/2021 17:21:37 [RTPHYSICS] Start Move
27/04/2021 17:21:37 [RTPHYSICS] ***No valid presentation contexts/transfer syntax found in 0 candidates
27/04/2021 17:21:37 [RTPHYSICS] ***In 0 presentation contexts
27/04/2021 17:21:37 [RTPHYSICS] ***#Possible transfer syntaxes: 1
27/04/2021 17:21:37 [RTPHYSICS] ***dicommove: remote DICOM error
27/04/2021 17:21:37 [RTPHYSICS] *** multiplex: connection terminated
27/04/2021 17:21:37 [RTPHYSICS] End Move

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:

a=DicomObject:new()
a.QueryRetrieveLevel='PATIENT'
a.StudyInstanceUID='1.3.51.0.1.1.10.1.236.46.13056692.3599568'
a.PatientID='0381930'
a.PatientName=''
a.StudyDate='20210319'
a.StudyDescription=''
a.AccessionNumber=''
b=dicomquery('UHGEIPROD', 'STUDY', a)
for i=0, #b-1 do
  print(b[i].PatientID, b[i].PatientName, b[i].StudyDate, b[i].StudyDescription, b[i].StudyInstanceUID, b[i].AccessionNumber)
end;

print("Start Move")

dicommove('UHGEIPROD', 'RTPHYSICS', a);

print("End Move")

It fails and in the serverstatus.log I get:

27/04/2021 09:47:52 [RTPHYSICS] Connected by address: 0100007f
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] 0000,0002     18 UI AffectedSOPClassUID    "1.2.840.10008.1.1" 
27/04/2021 09:47:52 [RTPHYSICS] 0000,0100      2 US CommandField           48 
27/04/2021 09:47:52 [RTPHYSICS] 0000,0110      2 US MessageID              1 
27/04/2021 09:47:52 [RTPHYSICS] 0000,0800      2 US DataSetType            257 
27/04/2021 09:47:52 [RTPHYSICS] 0002,0010     17 UI TransferSyntaxUID      "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:52 [RTPHYSICS] 9999,0400     26 LO ConquestConsoleComma   "lua:return Global.Basedir" 
27/04/2021 09:47:52 [RTPHYSICS] Server command sent using DGATE -- option
27/04/2021 09:47:53 [RTPHYSICS] Connected by address: 0100007f
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] 0000,0002     18 UI AffectedSOPClassUID    "1.2.840.10008.1.1" 
27/04/2021 09:47:53 [RTPHYSICS] 0000,0100      2 US CommandField           48 
27/04/2021 09:47:53 [RTPHYSICS] 0000,0110      2 US MessageID              1 
27/04/2021 09:47:53 [RTPHYSICS] 0000,0800      2 US DataSetType            257 
27/04/2021 09:47:53 [RTPHYSICS] 0002,0010     17 UI TransferSyntaxUID      "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" 
27/04/2021 09:47:53 [RTPHYSICS] Server command sent using DGATE -- option
27/04/2021 09:47:56 [RTPHYSICS] 0381930 XXXXXXXXX^^Mr. 20210319 MRI PELVIS PROSTATE 1.3.51.0.1.1.10.1.236.46.13056692.3599568 U13056692
27/04/2021 09:47:56 [RTPHYSICS] Start Move
27/04/2021 09:47:56 [RTPHYSICS] ***dicommove: remote DICOM error
27/04/2021 09:47:56 [RTPHYSICS] 0000,0100      2 US CommandField           32801 
27/04/2021 09:47:56 [RTPHYSICS] 0000,0120      2 US MessageIDBeingRespon   1365 
27/04/2021 09:47:56 [RTPHYSICS] 0000,0800      2 US DataSetType            257 
27/04/2021 09:47:56 [RTPHYSICS] 0000,0900      2 US Status                 43264 
27/04/2021 09:47:56 [RTPHYSICS] 0000,0901      4 AT OffendingElement       (0008, 0052) 
27/04/2021 09:47:56 [RTPHYSICS] 0000,0902     30 LO ErrorComment           "Invalid Attribute: (0008,0052)" 
27/04/2021 09:47:56 [RTPHYSICS] 0002,0010     17 UI TransferSyntaxUID      "1.2.840.10008.1.2" 
27/04/2021 09:47:56 [RTPHYSICS] End Move
27/04/2021 09:47:56 [RTPHYSICS] Link.Connected false in PDU:Read

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:

a=DicomObject:new()
a.QueryRetrieveLevel='STUDY'
a.StudyInstanceUID=''
a.PatientID='0381930'
a.PatientName=''
a.StudyDate=''
a.StudyDescription=''
a.StudyInstanceUID='1.3.51.0.1.1.10.1.236.46.13056692.3599568'
b=dicomquery('UHGEIPROD', 'STUDY', a)
for i=0, #b-1 do
  print(b[i].PatientID, b[i].PatientName, b[i].StudyDate, b[i].StudyDescription, b[i].StudyInstanceUID)
end
dicommove('UHGEIPROD', 'RTPHYSICS', a);

That Patient study is found successfully but it is still having issues retrieving image with the following output:

[RTPHYSICS] Server command sent using DGATE -- option
[RTPHYSICS] 0381930 XXXX^XXXX^^Mr. 20210319 MRI PELVIS PROSTATE 1.3.51.0.1.1.10.1.236.46.13056692.3599568
[RTPHYSICS] Connected by address: d5ec790a
[RTPHYSICS] ***No valid presentation contexts/transfer syntax found in 0 candidates
[RTPHYSICS] ***In 0 presentation contexts
[RTPHYSICS] ***#Possible transfer syntaxes: 1
[RTPHYSICS] no transfer syntax could be negotiated
[RTPHYSICS] *** multiplex: connection terminated
[RTPHYSICS] ***dicommove: remote DICOM error
[RTPHYSICS] 0000,0100      2 US CommandField           32801
[RTPHYSICS] 0000,0120      2 US MessageIDBeingRespon   1365
[RTPHYSICS] 0000,0800      2 US DataSetType            257
[RTPHYSICS] 0000,0900      2 US Status                 42753
[RTPHYSICS] 0000,0902     64 LO ErrorComment           "org.dcm4che3.net.service.DicomServiceException: java.io.EOFExcep"
[RTPHYSICS] 0002,0010     17 UI TransferSyntaxUID      "1.2.840.10008.1.2"
[RTPHYSICS] Link.Connected false in PDU:Read

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:

dgate --studyfinder:srv|str|fmt|file

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:

dagte64.exe --studyfinder:UHGEIPROD|0381930|fmt|file

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