Posts by blub_smile

    Hi


    No the database is empty. I deleted all images, made a regen of MAG0 and then imported the study.

    Hi


    I am having problem to receive studies from another PACS which have a pretty long patient ID.
    Due to one old scanner the same patient and its ID can have different writing for the name and the the other PACS ads a suffix to the patient ID like "[IMPORT ROOT date and time]".


    Conquest always chokes on those studies and doesn't store the images and hence can't forward them.


    Attached is an excerpt of the debug log:




    Any workaround for that?


    thx for any help here

    Hi


    I just finished some testing were I compared the J2K lossless compression time in images/s on our Ivy Bridge based server and on a new Ryzen 1800x.
    The Ryzen should have a better IPC of roughly 10% and in addition clocks 1,5Ghz higher than my IB server CPU - so in theory I should see an improvement of more than 50% - yet nothing changes
    and I merely get 7,8 images/s from uncompressed to J2K lossless.


    I know that compression is ST and that it is slow, however I am very confused that the speed doesn't improve with more horsepower in ST!? - it actually means that compression of JEPG in conquest it doesn't matter what kind of CPU on uses at all

    Hi


    I know its a little late but I would like to add a feature request:


    Possibility to add multiple IP Adresses to one AET


    Reason:
    We use Site-2-Site VPN as well as "on the road" dial-up-vpn. However Client IPs for S-2-S differ from dial up IPs - any chance to make that happen anytime in the future?

    HI


    mhh ok. I haven't decided which way to with compression yet anyway and sending data to itself via GUI also works fine - although it is quite a lot more work since drag_n-drop would only be a one time task (sending 50M images in one chunk is probably not a good idea for neither conquest nor database :) )



    PS: It also happens with other compressions - so from NKI to JPEG i.e.

    High Marcel,


    in another thread you posted:
    "
    Re: Compress Old Images


    Postby marcelvanherk » Wed Aug 24, 2016 12:50 pm
    Hi,


    Change the receiving compression and send the images to itself.


    Marcel
    "


    But isn't drag-n-frop the archive folder exactly the same thing as sending the image to itself?

    Quote from marcelvanherk

    Hi,


    I would not advise this workflow - but I am curious what goes wrong. Could you try with a few source compressions other than jpeg2000?


    Marcel



    Hi, I will try something different tonight. I once re-compressed the entire archive this way to jpeg2000 lossless and it worked perfectly..

    Hi


    I tried to recompress some data in my archive from J2K lossless to NKI N4 and encountered some error.


    Here is what/ how I did it and how to reproduce it:


    Use Conquest 1.4.17d or 1.4.19b3b and have some files with J2K lossless in your data directory. Then simply change compression for Conquest to NKI and drag-n-drop your data folder to the GUI - it starts recursively scanning the data and re-compresses it to NKI.


    This process works flawlessly for any CT/MRI image I have tested (about 6k) but fails for CR/DX images after a couple of successful recompresses.
    The original files or OK and when I drop them to the GUI to an empty Conquest setup (still set to NKI) they all compress just fine - its just the recompress that fails.


    Setup uses MySQL and I have tried it with different HDDs and partitions (HDD and SSD)


    So here is a debug log, maybe that helps:


    Quote from marcelvanherk

    Simplicity!


    it codes difference as 7 or 15 bits, and n3 throws in run length encoding as well. The entire decoder is maybe 30 lines code. And compressed data reads faster from disk.


    Marcel


    Giving the amazing speed it is a much better choice than any JPEG compression - and in my opinion worth a shot to maybe squeeze out a tiny bit more compression and/or speed :D

    Hi!


    After looking into the new JPEGLS compression I did some benchmarking and found that compression speed was somehow sub-par as far as my expectation were going.
    So I dismissed the JPEGLS migration but now, since I got some spare time, looked back into it and I was pretty much kicked in the nuts from what I just found out.


    OK here is the deal:
    If you use Windows or Windows Server with Xeon CPUs the standard performance scheme is "balanced" - this sounds quite fine as this is what most users actually want, powersaving in idle but ramping up clockspeed via Speedstep when needed.
    However when in "balanced" mode Windows does not scale your CPU up to the max frequency when there are just a few threads with high CPU utilization (the more cores you have the more likely this issue appears) - even with prime95 my CPU sits below 2Ghz with 2 threads running prime - only when I add more threads it scales up to 2,4Ghz, but even then it is not using its boost frequency.


    Since conquests JPEG compression is single threaded I was loosing a lot of performance here!


    Solution:
    Set windows power scheme to "performance", click "advanced properties" and scroll down to CPU and set minimum frequency from 100% to 5%.


    Now Windows will scale the CPU much quicker, will finally use your CPUs Turbo frequency (which is disabled in "balanced" mode) and will use low frequencies when idle.


    To give you some performance figures:


    scheme "balanced" JPEG LS lossless: 19 images/s -> scheme "performance" : 26 images/s which is +30%


    scheme "balanced" NKI compression: 26 images/s -> scheme "performance" NKI compression : 35 images/s


    cheers

    Hi


    A simple drag'n drop of your DICOM folder to the Conquest GUI also works. I did that a couple of years ago, took like aweek but worked like a charm.
    I would however use a 2nd Conquest instance/GUI for the task if you want to keep your archive online - it just has to use the same DICOM folder and database.

    Here you go :-)