marcelvanherk,
Thank you. I have got it to work with the below:
JavaScript
marcelvanherk,
Thank you. I have got it to work with the below:
Sorry forgot to add the error message. here it is:
<b>Warning</b>: Undefined array key 0 in <b>F:\Program Files\xampp\htdocs\api\dicom\posters.php</b> on line <b>135</b><br />
<b>Warning</b>: Trying to access array offset on value of type null in <b>F:\Program Files\xampp\htdocs\api\dicom\posters.php</b> on line <b>138</b><br />
I am trying to use the webserver API to attach a new DICOM instance/file (/rs/attachdicom) into the server.
In Nodejs, I have the below function (DICOM to be attached is read as a Buffer and sent)
I couldn't get the request to attach dicom to be fulfilled as there is always some parsing issue with multipart content in attchdiomfile() function in posters.php].
Temporarily I got it work using my own functions:
Although my functions work, I would like to utilize the attachdicomfile function which you already provided.
But I couldn't figure out what's wrong with the parsing of the multipart content!!!
Am I doing anything wrong in building the request object for the POST request from Nodejs?
Any help would be appreciated! Thank you.
marcelvanherk Thank you. Both bugs are fixed.
I have noticed few minor bugs in the webserver part of v1.5.0e (tested in Windows env).
1) For move commands, index.php (line 237) passes null as default for source AE. But this in rquery.lua (line 157) its treated as an empty string because of the parsing in qido.php (line 158).
Since its an empty string, local from = from or servercommand('get_param:MyACRNema')
from is always an empty string because of which dicommove throws the error "AE not found".
2) In rquery.lua, in some places, the output of the server command is passed directly to iowrite: iowrite(servercommand('lua:'..remotecode)).
But this causes nil error in iowrite function when there is no command output.
I have corrected them locally. Just listing them here, so you can add them to your next patch.
Thank you.
Hi marcelvanherk
Sorry for the late response. It did work. I just replaced libmysql64.dll with the one from MySQL8.4 lib folder - libmysql.dll.
Now, the Conquest is able to use caching_sha2_password authentication method instead of mysql_native_password.
Thanks.
Hi marcelvanherk,
Good afternoon. I am changing my existing Conquest installations to connect with MySQL Community Server 8.4.4.
In MySQL 8.0, mysql_native_password is being disabled and from 9.0, its being removed completely in favour of caching_sha2_password.
This being the case, Conquest can only connect with MySQL Server if its mysql_native_password
How to make it work with caching_sha2_password?
Any help would be appreciated. Thanks
Yes. Basically, I already have the whole content of the dicom file as binary string. I just don't want to use filepath.
In webserver/htdocs/api.dicom/posters.lua, there is already a function poststow(path) which takes filepath.
I would like to add another similar function but instead of a filepath, it would take the binary dicom file content as argument.
I could try this myself but I am not sure how to structure those remotecodes for such a function?
If its not a bother, it would be very helpful if you could add such a function to the webserver.
Thank you.
Hi marcelvanherk,
Currently, I can upload a new DICOM file either using web api or by calling dgate directly by providing the filepath.
Is it possible to do the upload by passing the content (binary or buffer etc.,) directly instead of a filepath?
Thanks.
Hi marcelvanherk
I am currently using v1.5.0c on Windows.
Can I just update my dgate64.exe & ConquestDICOMServer.exe from v1.5.0e but retain the webserver from v1.5.0c?
Would it cause any issues?
Thanks.
marcelvanherk Awesome. Thank you. Could I please ask when are you planning to release this update?
Conquest Version: 1.5.0d
When querying metadata, there is a minor incompatibility if the result is converted to JSON.
The reason being the Value Representation for DS allows optional + at the start of either a fixed point number or a floating point number.
Most of the programming languages don't care about the + at the front of a number but JSON treats it invalid.
If metadata result has to be converted into a valid JSON, its quite tedious in JS or similar languages. But its quite simple in the C++ source code.
I believe the issue can be rectified in the source Conquest-DICOM-Server/src/dgate/src/dgate.cpp
by just adding this if (*q == '+') q++; after Line 7847 (Please verify this!!!)
Would it possible to accommodate this change in a new minor release for [tt]dgate.exe[tt]?
Thank you for your consideration.
Thank you very much marcelvanherk. It works
marcelvanherk
Thank you.
But unfortunately, when I call servertask "--dolua:dofile([[rquery.lua]]);getmetadata(nil,[['.$st.']],[['.$se.']],[['.$sop.']])", the result is the same
I don't know why the result is 0.000000 whereas the Conquest headers show the full value .
marcelvanherk
When viewing the data (headers) in Conquest, I see the value without any problem.
The problem is only when I query the webserver of Conquest. I am not sure whether the issue is with lua or php code inside \webserver\htdocs\api\dicom.
I tried to call the specific getmetadata(...) function in rquery.lua from command line directly using dgate. But I believe the syntax is wrong and I can't get any result to debug this more.
dgate64.exe "--lua:dofile(\"./webserver/htdocs/api/dicom/rquery.lua getmetadata <AETITLE> <STUDYUID> <SERIESUID> <INSTANCEUID>\")"
Could you please look into this? Thank you.
Conquest Version: 1.5.0c
I am using the webserver to query the metadata from conquest:
http://127.0.0.1/api/dicom/rs/studies/<UID>/series/<UID>/instances/<UID>/metadata
For the tag 3004, 000E (DoseGridScaling), I get the value 0 (Postman API result)
Whereas the actual value is 6.66056188E-9 (Taken from CQ webserver - header in browser)
I also double checked by writing the API output to a file through curl but the value is 0.
This rounding causing a major issue as its not accurate and the data from the API is treated as 0 from then on.
What's causing this issue? I suppose PHP can handle such small values without any problem as it follows double precision floating point (64 bit)!!!
Could you please guide me to rectify this behaviour?
Thank you so much.
marcelvanherk
Thanks Marcel.
I did try the above like:
[lua]
Association = local list = {}; local list2={}
ImportConverters =1
ImportConverter0 = list[Data.SeriesInstanceUID]= Data.SeriesInstanceUID; list2[Data.StudyInstanceUID]= Data.StudyInstanceUID
EndAssociation = local f=io.open(list2[1], 'wt') f:write(table.concat(list, '\n') f:close()
But I get lua error in the console, for the line io.open(list2[1], 'wt') as list2 is nil when I restarted the server after changing dicom.ini.
I thought EndAssociation will only be called after something comes in. May be I am understanding incorrectly?
Please guide on me to properly configure dicom.ini to record data in a single association.
Also, could you please clarify one more thing?
In ImportConverters or ExportConverters, can I call two scripts in one converter?
Currently, I call a lua script like this:
ExportConverters = 1
ExportConverter0 = process series after 10 by F:\myApp\processSeries1.lua "%u"|"%i"
Can I call two lua scripts instead of one in the same converter?
Thank you.
marcelvanherk
>> Do they come on a single association?. It is easy to store lua data in a single association.
Could you please show how to record data in a single association using ExportConverter with lua? Thank you.