Posts by marcelvanherk


    you can move data to an archival device, and as it is moved change the compression (this is ArchiveCompression in dicom.ini; default 'as' is no change; but j2 compresses only slightly better than n2). Moving is always done actively using:

    dgate -as

    dgate -am


    dgate -v -as1000000,0

    dgate -v -amMAG0.Archiving,MAG10

    Moves 1GB (1000000 kB) of data from MAG0 to MAG10

    The GUI option "nightly move data" uses these two calls.

    There is no method to forbid conquest writing directly on MAG10, if MAG0..MAG9 are full it will write to MAG10.



    I guess any MAG can be considered an ARCHIVAL MAG, you should just stop writing there. While moving between devices you can change the compression. Conquest also has an old mechanism to archive to a DVD jukebox but that is probably not very helpful.


    This is some sample code from lua/anonymiser. The anonymisation happens on reception if enabled.

    It should be easy to adjust to your situation.

    Use zerobrane studio to control and run it.



    You can delete a few but e.g the web viewer may stop working. Are you sure the columns define the database use. Many will be mostly empty and take little space.

    I think you can delete these:

    [EchoNumber] [varchar](64) NULL,

    [NumberOfFr] [varchar](12) NULL, (maybe)

    [AcqDate] [char](8) NULL,

    [AcqTime] [varchar](16) NULL,

    [ReceivingC] [varchar](16) NULL,

    [AcqNumber] [varchar](12) NULL,

    [SliceLocat] [varchar](16) NULL, (maybe)

    [SamplesPer] [varchar](5) NULL,

    [PhotoMetri] [varchar](16) NULL,

    [Rows] [varchar](5) NULL,

    [Colums] [varchar](5) NULL,

    [BitsStored] [varchar](5) NULL,

    [ImageType] [varchar](128) NULL, (maybe)

    [ImageID] [varchar](16) NULL, (maybe)

    [qSpare] [varchar](64) NULL,

    But I cannot guarantee it does not break certain functionality.



    really you have to find the root problem which is not Conquest at all. You are trying to force two different patients into the same database row, which conquest rightfully refuses.

    But conquest can change anything in the data.

    For instance before (re)uploading the conflicting data (e.g. using drag and drop) try to add something like this in dicom.ini:



    Here script('newuids') replaces all UIDs (like in anonymisation).



    you can script any change that you want. The important question is what you want. The safest option is to change all UIDs, but you then need to know for sure there are only two studies that clash. If you change the study UID you can in principle split every image into a new study and I am sure that you do not want that.

    What caused the clash in the first place?