Conquest DICOM server 1.4.19beta release

    Hi Julian,


    the sqlite USLEEP change will be in the 1.4.19beta release for linux. A draft is circulating for feedback.


    There is an export command (even in 1.4.17d; do install 7zip) which may do the trick.


    dgate --export:patid,studyuid,seriesuid,sopuid,file,script


    you could try this:


    #after 30 seconds launch a lua file for each incoming series
    ImportConverter0 = process series after 30 by ProcessSeries.lua(%VPatientID,%VStudyInstanceUID,%VSeriesInstanceUID)


    ProcessSeries.lua

    Code
    servercommand('export:'..command_line..',,'..string.gsub(command_line, ',', '_')..'.zip')

    local patid, studyuid, seriesuid = string.match(command_line, '^(.-),(.-),(.-)$')

    d = DicomObject:new()

    d.PatientID = patid

    d.StudyInstanceUID = studyuid

    d.SeriesInstanceUID = seriesuid

    dicomsdelete(d)


    regards,


    Marcel

    As part of some testing I also upgraded one of my live servers to the beta release here.
    The ExportConvertors I have in place to forward images are no longer working.
    It seems like they are completely ignore now.
    No sign of life in any of the logs either.
    I tested on a brand new installation by just adding the code below to the bottom of my dicom.ini file, and that is also not forwarding any images any more


    Code
    # Configuration of forwarding and/or converter programs to export DICOM slices

    ExportConverters                  = 1

    ExportConverter0                  = forward to STENTOR_SCP

    

    

    ForwardCollectDelay               = 600

    MaximumExportRetries              = 0

    MaximumDelayedFetchForwardRetries = 0

    The log below is from a server that is running the latest 1.4.19beta
    This was working just fine before I put the update in place


    Code
    20160625 16:25:17 Started zip and cleanup thread

    20160625 16:25:17 Monitoring for files in: E:\pacsimagesupmc\incoming\

    20160625 16:25:17 DGATE (1.4.19beta, build Sat Mar 19 16:31:20 2016, bits 64) is running as threaded server

    20160625 16:25:17 Database type: built-in SQLite driver

    20160625 16:25:17 Started 1 export queue thread(s)

    Hi


    I just gave the new version a quick try and I noticed that J2K lossless compression seems to be arkward slow - without real measurement I would guess like 2 images/s.


    Is that a known limitation of the new compression alghorithm?

    Hi,


    here are my tests:


    servercomp write read
    j1 un 0.02441 0.00716
    j2 un 0.025 0.00761
    j3 un 0.01991 0.00777
    j4 un 0.02442 0.00711
    j450 un 0.0199 0.00523
    j5 un 0.03716 0.01088
    j6 un 0.03751 0.01089
    js un 0.03093 0.01625
    j7 un 0.03082 0.01627
    j702 un 0.03169 0.01384
    j710 un 0.03101 0.01376
    j720 un 0.02622 0.01385
    j740 un 0.02708 0.01461
    j780 un 0.03244 0.01488
    n2 un 0.0146 0.00365
    n3 un 0.0153 0.00283
    n4 un 0.01504 0.0037
    jk un 0.08793 0.05471
    jl un 0.09749 0.08064
    jl25 un 0.09511 0.06243
    jl10 un 0.09409 0.04709
    jl05 un 0.09309 0.04218


    This is for a 512 x 512 CT image on an I5 processor, e.g. jpeg2000 should be able to compress about 10 frames per second. What images are you using and can you compare with the previous version. We changes library because lossy jpeg2000 was faulty.


    Marcel

    below are some test results using different compressions and different versions:


    Hi


    OK here we go:
    Study of 852 images from uncompressed via drag'n-drop to GUI:
    Conquest 1.4.17 storage set to jk: 151s -> 5,6/images/s
    Conquest 1.4.19 beta storage set to jk: 182s -> 4,6/images/s
    Comparison to 1.4.17 storage as n2: 40s -> 21/s


    OK I admit that it is not as slow as I thought but in general I am suprised how slow J2K lossless is in storage...
    Machine is a Xeon 12 core 3Ghz 32GB RAM. Source was SSD destination was a 8 Disk RAID with 7200rpm.
    CPU Utilization was like 8% max.


    Is there no way of speeding up J2K compression on fast machines?

    Sounds about right for cpu load.
    Conquest will process everything single threaded, so on a 12 core cpu, 1 core under full load will translate to 8.3% overall.
    The way to speed up conquest would be to go for a faster clocked cpu, not necessarily more cores is better.
    One of the Xeon's at 3.5Ghz would be a good bet, or an overclocked pc might work well if speed is your most important attribute you are looking for.

    Hi,


    I 'reserved' multi-threading for multiple incoming connections. And again, people are going away from jpeg2000 as it is too computationally heavy for its compression. JpegLS is coming and seems a better choice.


    Marcel

    Ok afetr some quick test:


    JpegLS = 12,2 IMages/s - so much better but still not as fast as N2.


    Now we just have to wait for the DICOM viewers to work with JpegLS


    PS: Just noticed that in the beta the export converters are not working - any idea when that will be fixed?

Participate now!

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

Register Yourself Login