FileNameSyntax

    Well, I finally finished copying out ~800gb database. Now I need to reinsert the data to conquest. I would appreciate any help with the following:


    Which filenamesyntax should I use to ensure I have the widest compatibility with other PACS?


    ie. In the future, if I want to just move the entire database without doing an export/import but just a reading of the files?



    I am leaning toward 8. From the Manual:


    "8 (standard patient root DICOM directory structure in chapter 10 format):
    filename = ID[32]\Studyuid\Seriesuid\Imageuid.dcm"


    I read somewhere that this may be slower than others. Is that true? If so, is it significant? 4 modalities, 1 Rad, 4 others accessing database intermittently.


    PS. Server is 2xDual Core Xeon 5130, 2Gb Ram, Dual Gb Ethernet and 2 TB Raid5 WinXPPRO


    (Although this IS going to change to a linux install as soon as I get everything working right on my other test tsystem.)


    Thanks!

    Hi!
    When all your data is already on your HD where you want Conquest to store it you can point the MAG0 path in the Dicom.ini to that path and just re-initialize the DB with the conquest user interace.
    If you do this, the already stored files will NOT be modified according to your setting for the filesyntax - this setting only affects incoming files in the future, for example send to conquest by your CT / MRI scanner.


    When you want to store your files according to your desired file syntax you have to sent them to conquest by a DICOM client. i.e. KPACS eFilm etc.


    For moving files in the future:
    Just copy the archive directories to your new drive and edit the dicom.ini MAG0 device path according to the new storage path - thats all :-)



    With the compatibility I am not sure, but this is only important when you want to read the files directly from folders with other programs.
    Settings 8 and 9 should be ok I think.
    greetz


    PS: what kind of program did you use to copy the 800GB of files?

    Yes, the whole point of this exercize is to get the filenamesyntax in the correct format.


    Just dragged the entire data directory to an external usb (1TB) drive with windows explorer. (yes, it takes a Looooong time) I wanted the entire database.


    It is my understanding that with all the data in a drive that conquest doesn't use, that I can now change Filenamesyntax, delete original data directory, recreate directory, verify db install, re-initialize database (on empty directory) then simply drop the old files onto conquest to import the data and have it saved in the new filenamesyntax.


    I am thinking of holding off re-importing data until I get the linux version sorted out and convert the server over, then put the old data back in the new filenamesytax on an ext3 filesystem.


    Will have to try that on my test box first though. After I get the Linux Conquest working right. :shock::?::twisted::x:(:o:D

    Hi,


    Filenamesyntaxes affect directory structure (no difference) and extension (format). Extension .dcm is dicom compliant but (slightly) slower as .v2, and I advise to not (and now block) use nki compression on .dcm (this is not dicom compliant). In summary, if nki compression use v2, else use dcm. Also note the bug list: if starting fresh with the native mysql driver use dgate -v -i or dgate -v -r, instead of using the gui: the latter forgets creating indices.


    Currently linux has a limit at 1.4 million images with dbaseIII. Linux is also probably slower - the code was optimized under windows. I have not yet succeeded to install mysql under my vmware knoppix system, so I cannot help you there.


    Marcel

    Thanks



    Will be uncompressed on server with .dcm for compliancy. I was just trying to make sure that I choose filenamesyntax wisely this time. :-)


    3,8,9... I guess I'll go with 8 when I get linux/Apache/MySql/PHP/Conquest install working.


    (as cheap as storage is nowadays and not having 10's of TB to worry about for a few years, I am just going to keep server side uncompressed.)



    Following Linux thread closely.

    @radtreveller
    That decision sounds reasonable, although we went with compression and v2 to keep the server tower as small as possible and still having the possibility to up to 4TB in the future.
    By the way what stripesize did u choose for the RAID?
    greetz

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login