Posts by bart

    I've just testing 1419c1 version and first problem is that old Kpacs doesn't work with dicom transfer (querying works, retrieve not). Rolling back to 1419b and Kpacs gets back to normal behavior. Maybe the new c-get/c-move compatibility breaks old Kpacs settings?


    Hello CQ server setup is running fine with nearly 10 years without serious problems, btw. :-) thanks for your superior software...

    Recently I discover the "WatchFolder" option.

    I tested it with a lot of files from burned CDs with dicom data.

    But is there any option to filter/list which extension will be processed during import?

    Like "*.dcm" and files without extension - the rest of other files could be skipped (like .

    Or maybe there is another way to fix this non-necessary job.

    Thanks, regards


    From my experience if you have a PC with rimage software (for printing) and DicomWebCDfactory you can send dicom from ConQuest to this PC (may be the same machine) and then automatically burn the patient.
    The worst part is decision where is the moment of last image coming from MR or CT machine. My siemens machine doesn't have that indication (it's not working) and I never know when, or the patient is changed and then you can take a LUA script. But the last patient of the day is the problem. Or my situation is very rare.


    I'd like to mention that latest (maybe not - newest could be "k") "j" revision of CQ fails to compile under Debian and Ubuntu (both 64bit).

    Compilation errors:
    Debian (sid):
    In file included from total.cpp:137:
    /usr/include/sys/stat.h: In member function ‘virtual UINT16 MyBridgeStorage::CheckObject(DICOMDataObject*, PDU_Service*)’:
    /usr/include/sys/stat.h:323: error: too few arguments to function ‘int mkdir(const char*, __mode_t)’
    dgate.cpp:2259: error: at this point in file

    Ubuntu (oneiric 64bit):
    In file included from total.cpp:137:0:
    dgate.cpp: In member function ‘virtual UINT16 MyBridgeStorage::CheckObject(DICOMDataObject*, PDU_Service*)’:
    dgate.cpp:2259:18: error: too few arguments to function ‘int mkdir(const char*, __mode_t)’
    /usr/include/x86_64-linux-gnu/sys/stat.h:323:12: note: declared here

    Any ideas?


    I confirm that It could be customized.

    From my config (dicom.ini):

    FileNameSyntax = %V0008,1010\%studydate\%name\%counter.dcm

    Means that in Conquest Data folder every study is located in Machine station ID folder. Then Study date, patient name, and number.


    I tested your (skrani) scenario, but after launching Weasis I see quickly disappearing Patient's thumbnailes on the left and then I can't view images.

    On Conquest log there is query but no receive (although i see transfer rate in Weasis). Then after transfering I have empty Weasis page.

    Any rights to folders? debug log?


    Form my experience, I had such a weird behaviour (incomplete studies) when my CQ server tries to forward series to host (linux) that has huge CPU utilization and couldn't response well to tcp/ip requests.

    After turning off this host, Conquest restores its normal state. Very irrational from first look.

    Recheck your exportconverter section.

    Look in manual and forum.

    From my experience the best is to write some batch file (cmd or bat or bash script) and put in it:
    dgate(64) "--movestudies:AET_SOURCE,AET_DEST,20100601"
    dgate(64) "--movestudies:AET_SOURCE,AET_DEST,20100602"


    replacing AET_SOURCE with your clinic PACS and DEST with your PACS
    But be warned that if there is huge number of image there could be some problems with multitasking this queries. And it's better to check sum of images after transmissions.

    BTW Maybe someone knows how to easy implement such a utility to compare to PACS (number of images for the same studies). I have some elements of this utility (command line utils) - maybe some perl scripts or other ideas?


    I also agree with Qqmber, we have almost 15000 studies - running fine about 1,5 year (windows version).

    Thanks to Marcel and all users of this forum!



    For tests, I've just deployed linux ubuntu compilation of CQ server.
    After removing some win32 lines (remove getch() and luaheapinfo) for proper compilation, my conquest server is receiving images properly (from devices).
    But there is strange behavior from another Conquest server - I set up exportconverter (with send compressed jk) and images are storing well - only when I want to receive this images this error stops this process:

    Mon Jun 13 10:45:10 2011 ***[DecompressJPEGL]: No jpeg data found
    Mon Jun 13 10:45:10 2011 ***[DecompressImage]: JPEG library decompression error

    After switching exportconverter to uncompressed - images are storing and queried/receiving ok? Any ideas?


    Your way seems to be logical, but consider:

    -change compression mode (j2kr or jpeg) (disabling "regenerate" option) but save a lot of space
    -SQlite seems to be good for smaller amount of studies than postgresql/mysql solutions (in my opinion)
    -how many TBytes you have on production server?


    The recompress would be great addition to this process, but anyway:

    First, open command prompt and test the dgate command option (in my post)
    Second - create text document, generate lines with this commands tested from command prompt and save it as .cmd file.
    And run it.


    Hello, I had also similar problem.
    After some tests, I just ended with batch scripts:
    dgate(64) "--movestudies:SRC_AET,DEST_AET,20101124"
    cloned with every day of year - one day wasn't to much and the assoc. lost did'nt appear.

    But this scripts often run in parallels threads rather than one after another - to fix it for some "days" I had to re-run scripts.
    Generally 3 year "move" took over about a week to clone from one server to another.
    But it worked.

    I have also Siemens Avanto and after adding sops in dgatesop.lst Conquest receives and transmits raw spectro data without problems.

    Besides mentioned SOP's i have also:
    RawDataStorage 1.2.840.10008. sop

    Check this out and test this - but my CQ server accept this after that modifications - I double check tommorow again, but two weeks ago I had tested this and worked without problem.


    I just migrated to new expanded storage (6x2TB sata hdd's - raid6 - only ~7-8TB real space) with 2003 x64 server. I use 64bit mysql (5.5.11) - CQ is working fine.

    I also use jpeg2k compression (lossless) with ntfs-folder compression, which gives me maximum savings of my storage.
    My MR studies are compressing well - for example (size: oryg-jpeg2k-ntfs) study: 360MB--> 177 MB --> 117 MB
    <-- occupied on disk.

    Thanks to Marcel this is most advanced pacs server in the world.


    Hello Marcel again,

    Is this normal (or is there any solution) that my spectroscopy series (raw) are properly stored but with warning "***[CompressJPEG2K]: Failed to get image height".
    Files are properly written but maybe there is possibility to avoid this message?