Posts by marcelvanherk

The only line that needs changing in the line with copy. If you get the data into the incoming folder it will unzip, load and delete.

something like this (untested).

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

forwardtoremote.lua

local temp = tempfile('.zip')
servercommand('export:,'..command_line..',,,'..temp)
system('copy '..temp..' \\remoteserver\c\dicomserver\data\incoming')
os.remove(temp)

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

Hi,

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.

Marcel

Hi,

Do you want this automated when the images are recieved? Recompression can be done on the fly but there is no encryption built in into conquest.

Marcel

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.

Marcel

Ok,

I have updated on github.

Marcel

Hi,

Ah, the problem is that 6.xxx 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?

Marcel

Ok, I will change it tonight and get you a new servertask.exe, but if this is the issue can you just pass 2.tcp.ngrok.io and 18444?

Marcel

Hm,

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.

Marcel

BOOL    Socket    ::    Open ( char    *ip, char    *port)
    {
    struct    hostent        *he;
    struct    hostent        hecopy;
    struct    servent        *se;
    struct    servent        secopy;
    struct    linger        Linger;

    if ( Socketfd )
        closesocket(Socketfd);

    Connected = 0;

    he = Gethostbyname(ip);
    
    if ( !he )
        {
    //    fprintf(stderr, "Could not resolve host\n");
        return ( FALSE );    // could not resolve host name
        }
       
    memcpy ((void *) &hecopy, (void *) he, sizeof(struct hostent));
    
    se = Getservbyname(port, NULL);
    
    if ( !se )
        {
//        fprintf(stderr, "Could not resolve port\n");
        return ( FALSE );    // could not resolv port
        }
    
    memcpy ((void *) &secopy, (void *) se, sizeof(struct servent));
    if(!hecopy.h_addr_list)
        return ( FALSE );
    
    Socketfd = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
    if(Socketfd<0)
        return ( FALSE );    // could not create socket
    Linger.l_onoff  = 0; // 20121214 was 1
    Linger.l_linger = 0;
    setsockopt(Socketfd, SOL_SOCKET, SO_LINGER, (char*)&Linger, sizeof(struct linger));
        
#ifdef    SYSV_SOCKET
    memcpy((void *) &sa.sin_addr.s_addr , (void *) hecopy.h_addr_list[0], 4);    // adddress
#else
    memcpy((void *) &sa.sin_addr.S_un.S_addr , (void *) hecopy.h_addr_list[0], 4);    // adddress
#endif
    memcpy((void *) &sa.sin_port , (void *) &secopy.s_port, 2);            // port
    sa.sin_family = AF_INET;
    sa.sin_port = secopy.s_port;

    Error = connect(Socketfd, (struct sockaddr *) &sa, sizeof(struct sockaddr_in));
    if( ! Error )
        {
        Connected = TRUE;
        return ( TRUE );
        }

    closesocket(Socketfd);
    Socketfd = 0;
    return ( FALSE );
    }

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

Marcel

Hi,

dcm4che is shown here:

https://smart-api.info/ui/be87344696148a41f577aca202ce84df#/

orthanc here

https://book.orthanc-server.com/users/rest-cheatsheet.html

they are not compatible

Marcel

I don't think so. Can you gave a look?

I expect delete is specified, but I doubt the others are.

Marcel

Hi,

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

Marcel

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/'..params.rest)

end )

Hi Vlad,

DICOMWeb PUT has not yet been implemented (only qido and wado). Many people use Conquest as forwarder from DICOM to DICOM though. And of course you can script a call to e.g. Curl from Conquest to automically upload data to the cloud service when it is incoming.

Edit: these capabilities have been in conquest before 1.5.0c.

Marcel

Hi,

1) A query never accesses images. Have a look at setting:

EnableComputedFields = 0

2) I cannot access your log file.

Marcel

When you are comparing the speed of v2 and dcm what do you do?

Marcel

Hi,

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?

Marcel

Hi,

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.

Marcel

I do have enableStudyLazyLoad: true