Posts by toskrip

    Hi Marcel,


    it does not seem to be problem with DB connections (pg does not report problem and the number of connections is low). Changing


    VirtualServerPerSeries0 = 1


    improves the situation but, I can still get c004 error reported by virutal (the data node stays error free) only not so often.


    When I adapt lua script to execute dicommove from first from all data nodes to virtual and then from virtual to final destination AET, this seem to work nicely. Do you know... is it possible to get list of configured data nodes on virtual server via lua (so that I don't have to hardcode them)?


    Tomas

    No the database is not shared, each node has its own database (actually each node has its own DB server).


    I did increase the debug lvl but I really did not catch any error on data node. I will continue troubleshooting this, when I find something I will came back to you.


    Could it help to change the behaviour of virtual server to fetch data per series instead of image by image (could lover the amount of queries on DB) or are there any bad consequences with such change.


    I will probably also try to watch the number of active DB connections (default max is 100).

    Hi,


    thanks for quick response. So I have seen this in two different setups (one research virtual in front of research nodes and one clinical virtual in front of clinical nodes):


    * the virtual server is always Debian, 1.4.17d, with postgresql

    * the other research node is Debian, 1.4.17d, with postgresql

    * the other clinical node is Debian, 1.4.17d, with sqlite


    No error shown on the actual data nodes, only warning:


    Code
    Warning: use of as is compression for outgoing associations not fully implemented


    Actual the out of database connections case would explain it (the other errors you describe sound more like the data would never be found, but I can fetch them on second movedicom execution). Do you know it is possible to setup connection pool for postgresql connection on conquest?

    Hi,


    I noticed one behaviour that I cannot explain properly. I have a conquest setup as virtual server (in this case acting as virtual server for another conquest instances). I have a lua script in the virtual server that tries to CMOVE DICOM Study to specific defined AET (but still store it locally on the virtual):



    What often happens is that the CMOVE does not copy all the data (even thou the status string all images transferred). I get this error in the log:


    Code
    Virtual server - remote C-MOVE DICOM Error code c004 (49156) from OTHERCONQUEST


    and then I see the virtual server trying to fetch data from the second defined conquest instance (it will not find them there - there are only on the first one). Then comes the messages:


    Code
    *** missing file: MAG0.0 ...
    *** Could still not find file: ...
    ...


    Then when I try to execute the same move second time, the virtual actually collect the missing data from the other conquest node (where it failed before) and sends complete study to defined AET.


    Maybe somebody has easy solution for this. In a worst case I am thinking to change the script to the the first dicommove between data node and virtual server (repetitively until it collects all images) and then second dicommove to specific AET.


    best


    Tomas

    Thanks for quick response Marcel. I was also expecting DicomObject:Read('stu\ser\sop') to work with virtual servers but I tested it again and sadly no luck there. For now I use the dicommove from local to local in case that dicomread does not return the object and retry of dicomread after the dicommove. This works for me.


    Glad that you mention this local to local trick, I will use it in some other usecases where I want to prefetch the data on the virtual server so that I can zip and download from there... I was probing all storage nodes in order to locate which one has data to be moved to virtual but that is not very elegant.


    best


    Tomas

    Hi,


    I have one conquest instance configured as virtual server for two DICOM servers with data (happen to be conquest as well). I have a lua script where I have a need to read specific SOPInstance in order to get certain RT related tags (such as RTPlanLabel). I understand that for virtual server to be able to access SOPInstance it first need to fetch the actual data from the storage nodes and store it locally. From documentation it looks like the readdicom function in lua should support such behavior but maybe I missed something because it does not work in my case:

    Code
    dcm = newdicomobject();
    readdicom(dcm, stuid .. '\\' .. seuid .. '\\' .. sopuid);
    print([[ "RTPlanName": "]] .. dcm.RTPlanName .. [[", ]]);


    The above snippet works if the SOPInstance is cached locally on the virtual server, but it does not work if the data is only available on the storage nodes (does not trigger the fetch).


    Does anybody has an idea how to implement the behavior that I described? From my experience WADO requests on virtual server are triggering the fetch of requested DICOM SOPInstances. Maybe one option would be to trigger WADO request on virtual server from lua before readdicom.


    Note: running on version 1.4.19b


    best


    Tomas

    Hi,


    the Weasis team (me included) started to work on open source dicom-rt-plugin:


    https://github.com/nroduit/Weasis/tree/dicom-rt-plugin


    it is still under the development but the RTSTRUCT rendering should be stable enough. The plugin is for new unreleased Weasis branch (3.0.x) as it leverage OpenCV library for image processing. The conquest startup scripts will need to be adapted to allow launch of new Weasis because the DICOM study manifest for WADO data loading changed slightly.


    best


    Tomas

    Hi Marcel,


    the problem was that slicer is not starting DICOM listener automatically unless such behaviour is explicitly configured. And the listener starting configuration is actually in different window than the query/retrieve functionality so I have overlooked it initially. Sorry for the non relevant post. Everything works fine now.


    best


    Tomas

    Hi,


    I would like to query/retrieve data from conquest using 3D Slicer, but I was unable to get it running. It may be also problem on 3D Slicer site but let's see if somebody here was dealing with the same topic and was able to get it running. After modification of acrnema.map, the query seems to work fine. But the C-MOVE fails with following output:


    Slicer:

    Code
    About to retrieve 1.3.6.1.4.1.2452.6.3895409160.1338747868.2223972786.1677869976 from g40rpbpacsdev.med.tu-dresden.deStarting to retrieveStarting moveStudyNegotiating AssociationI: Requesting AssociationI: Association Accepted (Max Send PDV: 16372)Setting Retrieve ParametersSending Move RequestI: Sending C-MOVE Request (MsgID 1)I: Received C-MOVE Response (Failed: UnableToProcess)W: Status is 0xc005 (unknown)W: Will not wait for further C-MOVE responsesMOVE response receveid with status: Failed: UnableToProcessMOVE request failed, server does report errorMOVE request failed: No detailsRetrieve successI: Releasing Association


    Conquest:

    Code
    C-Move Destination: "CTKSTORE"
    Fri Apr 8 18:53:21 2016 Number of Images to send: 94
    Fri Apr 8 18:53:21 2016 Host 'CTKSTORE' did not accept the connection
    Fri Apr 8 18:53:21 2016 C-Move (StudyRoot)
    Fri Apr 8 18:53:21 2016 UPACS THREAD 84: ENDED AT: Fri Apr 8 18:53:21 2016
    Fri Apr 8 18:53:21 2016 UPACS THREAD 84: TOTAL RUNNING TIME: 0 SECONDS


    Any ideas where an issue can be?


    best


    Tomas

    Hmm at the end I got it running but it is a little bit ugly. Seems like when lua script is executed as web service it does not have permission to do certain operations (write, dump, ...). However if I use servercommand('lua:'..script), given that the modification (write logic) is within the composed script string, this is executed with conquest user permission and the file is properly modified.


    The working script is here:


    Tomas

    I will try to track down, what is happening there. I am using the default 3 as FileNameSyntax property in my conquest instance. You say that v2 are bad match... do you think it would be wise to switch to the option 4 when I am planning to have more lua scripts modifying DICOM data in a long term?


    T

    If I try to change some other tag e.g. PatientName it change the value in SQL database but does not apply it on DICOM lvl, when I dump the file nothing changed there. I have a feeling that I am still missing something in web dicom.ini configuration to allow lua persisting modification on dicom level.


    T

    I was missing some of DB configurations in my web dicom.ini. Now the error is gone, it says:


    Code
    Lua script rewritten file: /mnt/data1/DD-L036D0E1/233412335242842699416507238827857724766_0003_000002_139382758702b5.v2


    however the ROIName is unmodified... is modification of tag within sequences supported?


    BTW my script now looks like this:



    T

    Thanks for prompt response,


    I was actually running older version of conquest that did not seem to have AddImage method implemented. So I migrated to 14-17d now but I am getting an error on AddImage:


    Code
    Removed file: [MAG0:DD-L036D0E1/233412335242842699416507238827857724766_0003_000002_139382758702b5.v2]
    ***Could not remove IOD /mnt/data1/DD-L036D0E1/233412335242842699416507238827857724766_0003_000002_139382758702b5.v2
    ***Error writing file: /mnt/data1/DD-L036D0E1/233412335242842699416507238827857724766_0003_000002_14498299920000.dcm
    ***[lua addimage] Error entering object into serverlocalhost


    Also now it removes the instance from DB but it does not delete the dcm file. Just an idea... do I need some additional configuration in web dicom.ini file to make use of AddImage method?


    Tomas

    Hey,


    I was writing a simple lua script, that should allow to do modifications on RTSTRUCT ROINames of already existing data within conquest (I don't need this as converter, because this functionality will be accessible from different webapp calling it as web service).


    I have troubles saving the modified RTSTRUCT back to conquest. I was thinking to save it to incoming and let it be reimported, but the Write method does not seem to do the job. Am I missing something?


    One additional question... is there a better way of getting the MAGDevice0 path from lua rather than hardcoding it into a script?


    My script is here:



    I would be glad if somebody can point me to the correct direction for saving data back to conquest.


    best


    Tomas

    Hey Marcel,


    this looks interesting, just a simple question, should this also work with the older conquest version (1.14.7) or is it intended only for the new one?


    BTW: quick try to deploy this on conquest 1.14.7, start page loads fine, search patient redirect to listPatients.lua but no patients are displayed (looks exactly like start.lua).


    best


    Tomas

    Marcel ignore the last questing ... I understand now what is listed in dgatesop.lst are already decoders for image data which are already supported by Conquest and you can just enable or disable them.


    So theoretically I can configure Conquest to take incoming data as is (as) and modify the static structure to so the conquest will be able to store this files. And this way the responsibility to decompress the image will lay on the DICOM viewer.


    Tomas

    Hi,


    yeah I know that decoder is necessary. This is the problem with private transfer syntaxes. DICOM allows them so some companies (like Philips) use them (for whatever good reason they have) and make the produced DICOM files readable only in their specific applications. From what I learned they call it CT-private-ELE (Explicit Little Endian) so LittleEndianExplicit decoder should be fine with it.


    It contains compressed pixel data, using
    (07a1, 100a) [Tamar Compressed Pixel Data] OB: Array of 6532 bytes
    (07a1, 1011) [Tamar Compression Type] CS: 'PMSCT_RLE1'


    When I imported this file (by modifying hardcoded syntaxes) it look ok, Conquest is still running. The only problem is that viewer has a troubles with representing the image (which is obvious, because it does not known how to decompress this).


    In case you are planning to support this you can check this code:
    https://github.com/malaterre/G…/Examples/Cxx/rle2img.cxx


    What I did not understand completely in Conquest is that, you can to the configuration of transfer syntaxes in dgatesop.lst file. Why it this not used during data import. Or the other way around when is the transfer syntax configuration in dgtatesop.lst used?


    Tomas

    Hi,


    I have some image data produced from Philips PET-CT (GEMINI TF TOF 16), which have been exported to DVD and now I would like to save them in conquest. When I use incoming folder feature of conquest to import these data, conquest gives me "Unknown transfer syntax in..." error.


    Philips uses private transfer syntax UID (1.3.46.670589.33.1.4.1) which should be little endian explicit. I have modified the dgatesop.lst config and add this line at the end:
    PhilipsGeminiPETCT 1.3.46.670589.33.1.4.1 transfer LittleEndianExplicit


    However it did not end, and I was still getting the same error. Than I dig in and found out that in trnsync.cxx source file there is a Array of structures defined, called TransferSyntaxAliases. This array is hardcoded within source and the config has no influence on it. When I added the private transfer syntax there and recompile it fixed the issue and I could import a data. I would like to ask for a recommendation whether you think it is safe to have it this way. Or is there a configuration option which allows to extend the accepted transfer syntaxes?


    thanks for help
    best


    Tomas

    I see, hmm however you say that with change in code it is possible. Is it a lot of work? I would welcome such feature. Because currently I am getting often getting errors:


    Encountered an invalid group order during load of DCM file


    Which always occurs only for couple of slides that are afterward missing in database. I tried to use NoDICOMCheck=1, which solved group order issue however introduce other problems, and all in all I would rather prefer to have DICOM consistency checking enabled and catching problematic files for manual correction later.


    do you think you can put it on the wanted feature list?


    Tomas