DICOM server 1.4.19b bug fixes and updates

  • So if I run ./linux.sh and go to http://localhost:5912/ I don't get any response.


    If I look in $ netstat -lptu I can see tcp 0 0 *:5912 *:* LISTEN 6324/dgatesmall


    Also:

    Code
    $ ./linux.sh
    nohup: appending output to 'nohup.out'
    ###!!! [Parent][MessageChannel] Error: (msgtype=0x15007F,name=PBrowser::Msg_Destroy) Closed channel: cannot send/recv
    ###!!! [Child][MessageChannel] Error: (msgtype=0x2C0105,name=PContent::Msg_AsyncMessage) Channel closing: too late to send/recv, messages will be lost


    And nohup.out:

    The process doesn't get killed - I have to do that myself.


    Is this just something to do with the system I am trying this on? Does this work for others?

  • Hi,


    So the install control server runs OK. Then there is a webserver which uses the same dgatesmall as well as CGI application (service.lua is actually the script that creates the web page). Maybe the files are not copied correctly into cgi-bin on apache?


    regards,


    Marcel

  • Hi! I am a old urologist in Japan. I can not understand "c++" at all. So I am not sure that bugs are already corrected and my changes are correct, and afraid that you can understand my English.


    std::auto_ptr (is deprecated) -> std::unique_ptr


    ./src/dgate/charls/header.h:60:7:

    ./src/dgate/charls/decoderstrategy.h:36:31:

    ./src/dgate/charls/decoderstrategy.h:310:7:

    ./src/dgate/charls/encoderstrategy.h:44:33:

    ./src/dgate/charls/encoderstrategy.h:183:7:

    ./src/dgate/charls/encoderstrategy.h:187:7:

    ./src/dgate/charls/scan.h:198:26:

    ./src/dgate/charls/scan.h:199:23:

    ./src/dgate/charls/scan.h:803:51:

    ./src/dgate/charls/scan.h:825:49:

    ./src/dgate/charls/jpegls.cpp:88:6:

    ./src/dgate/charls/jpegls.cpp:107:14:

    ./src/dgate/charls/header.cpp:69:7:

    ./src/dgate/charls/header.cpp:72:48:

    ./src/dgate/charls/header.cpp:136:8:

    ./src/dgate/charls/header.cpp:138:27:


    STRATEGY::_processLine = processLine; ->

    STRATEGY::_processLine = move(processLine);


    ./src/dgate/charls/scan.h:805:25:

    ./src/dgate/charls/scan.h:827:25:

  • Hey.

    There was a problem when saving data from ultrasound devices to Conquest. The saved images from the ultrasound machines have a defect in the form of green stripes in different parts of the image. Some third-party browsers normally display the data saved by the Conquest, and some also display them with green defects ...

    I apply a problem file. How to fix it?

    I'm understood that a problem in color space interpritation?

    https://groups.google.com/forum/#!topic/dcm4che/T3Nzp6fyPYs

  • Hi,


    the color changes indeed in 1.4.19b, which happens on decompression. If you configure conquest as:


    enable jpeg support

    keep jpeg or uncompressed


    The original data is kept and your viewer should show the correct colors. Conquest will still display the image green. I added the issue to the bug list.


    Marcel

  • hi

    i try to install conquest on a raspberry and i have the same error message than tbuziak (9 jun 2018) when i run maklinux

    i download qrsop.cxx before


    raspbian version:

    Linux 4.14.70+ #1144 Tue Sep 18 17:20:50 BST 2018 armv6l GNU/Linux

    gcc version :

    gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516




    regards


    roland

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!