imagectn database limitations ?

[antw1]

I am currently using imagectn on a small NAS appliance as a PACS server for 2 workstations (eFilm & OsiriX).
And it does a perfect job !

I am wondering what the limitations are, in term of maximum Studies permitted...
The NAS I'm using for testing features one 80 GB IDE drive, and should hold 8,000 images at best (CR mostly).
But a 400 GB is in my mind (40,000 images).
Can imagectn's database file handle these volumes ?

I tried to figure out from Dr. Saul's CDMEDIC how to use imagectn with a theoritically better performing MySQL database, but the documentation isn't overwhelming in details, and my ability to read code quite limited.
I'd really appreciate some pointers here...

Thanks.

[Michael Onken]

Hi,

the use of imagectn for 40.000 images and more is not recommended, perhaps not even possible. I can't say for sure, because I'm not very experienced with imagectn code. But there seem to be a few issues to consider:

- If the index file reaches a size of 32MB, warnings are printed out to console
- There is MAX_NUMBER_OF_IMAGES = 10000 defined; I don't know the exact implications, if you increase this value, but there is no guarantee, that imagectn still works as expected
- Many internal variables use "int" as their datatype; if int is a 32-bit-integer you might get into trouble if there is an integer overflow (> 65535).

In addition you have to consider, that the performance of such a large index file should be very bad. The use of a database is really recommended;-) As a conclusion I would say, that you should not use such large volumes of images with imagectn.

Regards,
Michael

[antw1]

This is certainly the answer I expected.

How do you interface imagectn with a database then ?
I've seen the use of MySQL in CDMEDIC, and PostgreSQL in Conquest MiniPACS.
Both of these application work well for standart PC desktop, but when trying to port them to a tiny linux NAS appliance (Kuro Box), I am having some trouble with the database configuration.

Any input would be appreciated...