Posts by bart

Check the first link - the source html has no "a" at the end, so I didn't check this! just copy & paste...and 1.5.0...

Downloaded with additional "a" and magic goes on!

Regards, and as always - thanks for quick reply!

Hello,

Please correct me if I'm wrong, but I did a test upgrade to 1.5.0a and everything is fine, but one important function is not working on my old win2003 setup - incoming compression is uncompressed but in dicom.ini it is set to Jpeg2000.

OpenJpg library problem with old 64bit system (2003 server is very old and not supported now...) or maybe I miss some configuration in new version? Old files are in the same place, only updated binaries and libs...

If I retrieve the files from PACS - server correctly send in j2k format, but incoming series from MR scanner are saved without compression...

Thanks for any clearance, maybe I miss current known bugs...

Hello, nice to hear quick reply from You.

My conquest PACS server is running about 10-11 years - now it is 1.4.19b, but I remember .17 for some years. Mainly MRI images, it stores 2 siemens mri sources (about 6 TBytes now).

I could attach this image - please contact me using PM. The source of the problem is probably that it is not medical image, but the test image from manufacturer.

Regards

Hello again,

I'm happy user of Conquest server for several years.

Now after ten years - your CQ server is running fine with no errors - stable as rock.

But last time I reviewed a log for some day and noticed this error with one file:

---------

*[OpenJP2(J2k)]: Number of resolutions is too high in comparison to the size of tiles

[MRPACS] ***[OpenJP2 compress]:OpenJpeg could not start encoding the image.

---------

Maybe is typical error, but I searched the forum and nothing was displayed.

Regards

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?

Regards

Hello Marcel...my 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

Bart

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.

Regards

Thx Marcel, it works now!

Hello,
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?

Thx
Bart

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.

Regards

I have "UN" option in settings of dicom.ini, and it not helped.
Maybe the compiled dgate.exe has only .wado extension built in?

Did You set-up successful Weasis and CQ on windows?

_regards

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?

_regards
Bart

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.
Regards
Bart

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"

etc.

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?
Anyone?

Regards

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!

Regards!

Hello,

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?

Regards

Any changelog?

Thanks

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?

Regards
Bart

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.

Regards
Bart

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.