Posts by blub_smile

    Hi


    I just tried the new JPEG2000 feature on the iPhone with Osirix HD. J2K lossless works perfectly but on bad connection speeds it can be very slow.
    Therefore I tried out the J2K lossy compression and fiddled a bit with the settings, going from 95, 90, 85 down to 75 - however not even 95 was quite acceptable just too many gray-scale colours were already mora black-and-white so that really using the pictures is not an option.
    has anyone tried those setting and maybe can confirm that behavour?


    btw, momentarilary I am using 1.4.16 beta4 - may also be a bug!?


    greetz

    Hi


    Ok after some testing I figuered that much :-).


    However it would be a usefull feature to compress in n2 or nX - if jk is not possible - instead of just stopping and let the move fail when jk is set!?


    Over he week I will test versions x.16 beta 4 and up to see in which vesion it will stop working and let yu know where the bug mght be.

    Huuhh quite complicated that matter.


    I downgraded to version 1.4.16 beta 4 - and now the archival process starts without crashing - yeah!!


    Problem is now that the following message comes up:


    recompressed with mode = jk (Strip=0)
    cannot rewrite jpeg/rle image in v2 format
    failed selectin patients for nightly moving


    danm it :-)!


    So my database is mostly V2 in NKI compression.
    New data coming into the server is J2K lossless - thats why I upgraded.
    The nightly moved data schould also be stored in J2K lossless on the MAG1 drive.


    To give it a second try I changed the file extension from *.V2 to *.DCM - maybe it will work!?

    Ok when I use" dgate -v -au" to reset archive flags I get dagte crashes balbalabla...etc....


    Below is the error message file from Win XP/( I think it used to XML!?) if someone bothers to take a look, mabe its helpfull :-)




    Hi


    I just upgraded from 1.4.15 to 1.4.16 (b).
    I upgrade as usally replaceing .exe files inculding copy the 7zip and all that jpeg compression files - However I did not replace acrenamp dgatesop dicom.ini.
    Server runs fine, just this morning I recognized that the nightly move operation failed.


    Message was similar to this (cant copy paste at the moment):
    could not select patients for archival
    nightly move failed


    Systems runs:
    MySQL, no other changes were made.


    Any ideas how to troubleshoot this?

    Hi


    Sending DICOM files can take very long - we experienced that 2 weeks ago.
    We tried to send DICOM data over a VPN connection vis sattelite... forget it :shock:
    The SDSL line for sending the files needs exactly 2 second per 512k file, the ping time (round-trip) was about 1000-1500ms including the "dicom testing" one file took around 8-10 seconds.
    Or in other words completely useless....
    So if you have a high ping between the machines..forget it.

    Hi
    First of all I would download the Conquest package and read the manual :-).
    After that I wouzld setup a test machine with a running Conquest server and on or two Client programs Kpacs or Efilm, on this setup
    u can play and see how things work.
    PACS systems a very complicated, DICOM is even more :-) and I for sure cannot explain how they work in detail.


    However if u would give us the error message ID u get it would help to figure out the problem.


    U said u cloned network settungs, by that I would guess u mean the IP. For a working DICOM connecten, in your case TAC and Conquest, u need 2 more things:
    AE Title ("name" of a DICOM communicating program)
    Port number


    Each of the above have to be entered into the two communicating software, so that every program knows "how to talk to the other".
    greetz

    Hi
    I got a quick question that somehow wasnt answered in the manual ( or I didnt find it).
    I just added another 2TB of storage for Conquest and changed the .ini as follows:


    MAGDevices = 2
    MAGDEVICE0 = d:\CQ\
    MAGDEVICE1 = e:\CQ\



    Conquest lists available storage correctly.
    But I am wondering at which point Conquest actually uses the new MAG device!?
    I would like to tell Conquest to use the new drive when there is about 150GB left on the old one, is this done via the "Device threshhold" setting?
    greetz
    steve

    ...mhh not "really"


    After some testing I discovered that on fast HDs MySQl will be confronted by Conquest with 80-120 queries during rebuild.
    In "daily life" average MySQl connections reach up to 15-20 (depending on your enviroment / users)
    Database size for approx. 1M images is about 1GB to 1,125GB



    I am runnig InnoDB with a max of 125 connections, I allow MySQl to use 800MB of ram on a machine with 3GB ram (on a dedicated server I would suggest about 1.2GB), if you are interested
    in the specific cache settings let me know - I have too look them up. (but I am not a sql specialist :-)
    I assume the most gain in terms of speed you will get with running the databse on a dedicated 15k rpm disc.
    greets
    steve

    Hi


    Forwarding "study" or "series" level should make ist faster I tested that some time ago ( i think conqurest even has a "delay" function for forwarding so that it starts after other jobs are done)
    If you have 3.2M+ images and Mysql process only has 32mb there could also be a bottleneck slowing you down.
    For example our mysql process has usually 130-200mb, depends on how long the server is up.
    You might want to checkt the msql setting how much ram it is allowed to use to cache tables and how many multiple connections it is confugured for.
    greetz

    Hi
    Its not that I think that CQ is slow in particular.
    I was just wondering what kind of improvements are possible for a new setup.
    The new server will maybe hold 10TB an more, so I think it would be good too keep it fast when multiple queries / receive / sends happen at the same time
    greetz

    Hi
    We have this problem betweeen Conquest and a Vitrea WS.
    We changes AE titles IPs etc. it still isnt working either way..very strange....
    Toshiba techs have no idea, Vital Images tech says ist a Conquest problem and he doenst really care - althour every other WS with different software works fine with CQ.
    very annoying I have to admitt

    Hi
    I wonder if I am thinking right that when I am running multiple instances of CQ it will improve query/retreive speed etc.


    Basic idea:


    Two instances only for receiving:
    One CQ instance A for storing MR data on drive A with its own database


    One CQ instance B for storing CT data on drive B with its own database



    And another instance of CQ for the modolities used for querys that has added instance A and B as virtual server.


    Does this make any difference or is it without any benefit and just plain nonsense :-)!?

    I can confirm that Efilm has no problem storing those studies.
    If we are aware of the problem we delete the old study in Conquest and just sent the new one - if we are not aware of it....well then the radiologists have to do a little diggin when they are searching for that specific study in the future ;-)

    Hi
    Our databse is currently short under 7 GB and we back it up twice a week - for our needs that is sufficient enough.
    When a crash occurs only 2-3 days of data is unaccassible and a rebuild/find missing images takes quite a while the larger your archive gets.
    greetz