Posts by marcelvanherk

    something like this (untested).

    importconverter0 = process study by forwardtoremote.lua(%VStudyInstanceUID)


    local temp = tempfile('.zip')
    system('copy '..temp..' \\remoteserver\c\dicomserver\data\incoming')

    where the copy command must be replaced by an appropriate remote access command such a scp or curl


    are you transferring from conquest to conquest? In that case you can use e.g. "forward compresses as N4". This is not encrypted but a conquest specific compression that is hard to read for others. However, the patient information should be protected by usig e.g. a VPN.

    Another way to accelerate to is use the export: function, e.g. create zip file, transmit it and then put it incoming at the receiving end.


    Hi Luiz,

    this is a WIP api with some of the new functionality. It may be best to separate it from QIDO to avoid giving standard users too much rights.




      (5.6 kB, downloaded 2 times, last: )


    Ah, the problem is that looks like a numeric IP address to Gethostbyname in socket.cxx (it starts with a number and contains a .) I have updated the source to now scan for any character not . and 0-9. Can you try the adapted servertask.exe?




      (211.54 kB, downloaded 1 times, last: )


    I am not sure at all how to do this. The source code of servertask is quite simple. It maps directly to socket::open in socket.cxx. If you have any idea how to adjust it for ngrok that would be great. Socket prpgramming is not my strongest point.


    In what sense? QIDO WADO and STOW are compliant, but I do not think the other items are in the dicom standard.

    Basically I want to create a nice interface for a web-based GUI, so I can also just make these private e.g. /api/conquest/modalities



    I am thinking on expanding the rest api, looking at Orthanc for inspiration. Any ideas? My list sofar:

    Edit: propose to use HTTP commands, make more similar to Orthanc; will implement in Ladle first.

    -- remote server operations

    GET /api/dicom/modalities

    GET /api/dicom/modalities/:id

    PUT /api/dicom/modalities/:id

    POST /api/dicom/modalities

    DEL /api/dicom/modalities/:id

    GET /api/dicom/modalities/:modality/echo

    GET /api/dicom/rs/modalities/:modality/studies

    GET /api/dicom/rs/modalities/:modality/studies/:suid/series

    GET /api/dicom/rs/modalities/:modality/series

    GET /api/dicom/rs/modalities/:modality/studies/:suid/series/:euid/instances

    GET /api/dicom/rs/modalities/:modality/instances

    POST /api/dicom/rs/studies/:suid/series/:euid/instances/:ouid/move?target=AE

    POST /api/dicom/rs/studies/:suid/series/:euid/move?target=AE

    POST /api/dicom/rs/studies/:suid/move?target=AE

    -- delete

    DEL /api/dicom/rs/studies/:suid

    DEL /api/dicom/rs/studies/:suid/series/:euid

    DEL /api/dicom/rs/studies/:suid/series/:euid/instances/:ouid

    -- create zip file (optional anonymisation, parameters in query)

    GET /api/dicom/rs/studies/:suid/series/:euid/instances/:ouid/archive

    GET /api/dicom/rs/studies/:suid/series/:euid/archive

    GET /api/dicom/rs/studies/:suid/archive


    How to build latest OHIF with all extensions for deployment in Conquest:

    edit package.json and remove --stream from scripts/build (line 15)

    set PUBLIC_URL=/app/ohiftop/

    yarn install

    yarn build

    copy platform/viewer/dist to Conquest-DICOM-Server/webserver/htdocs/app

    ren Conquest-DICOM-Server/webserver/htdocs/app/dist Conquest-DICOM-Server/webserver/htdocs/ohiftop

    This works in Ladle if adapting ladle_routes in Conquest-DICOM-Server/webserver/htdocs/ladle_routes


    -- Static route: ohiftop viewer

    routes:get('/app/ohiftop/', function (params)

    redirect( '/app/ohiftop/index.html')

    end )

    routes:get('/app/ohiftop/*rest', function (params)

    redirect( '/app/ohiftop/'

    end )


    search is through the database not the dicom files. These two issues are not related. For retrieval speed, v2 if anything should be faster. However, I am trying to phase out use of .v2 in favour of standards unless you want to use eg N2 compression that is blindingly fast.

    What databases are you using?



    are you using immediate (forward to) or delayed (forward study to) export converters? They behave quite differently.

    The former can run up to 20 or so different one at the same time with up to 20 channels each. The latter go through 1 queue but multiple workers can be set to process the queue.

    It should be possible to make the queues work with database tables, the same code is used for all queues in dgate.cpp (process_queue, new_queue, into_queue, into_queue_unique). I have little time to do that though.

    In 1.5.0c (once I have the xxxx socket code fixed), there is code to run C-MOVEs in parallel as well.