Siemens non-image data ccorrupted after forwarding

    Hello, we store our Siemens spectroscopy data on a CONQUEST server (1.4.15). The line "CSANonImageStorage 1.3.12.2.1107.5.9.1 sop" was added to the dgatesop.lst file in order to correctly receive these dicoms. Siemens actually store the data in private fields of the header.


    Data on this server are OK, however if we try to forward these DICOM to a further conquest server (1.4.16), they become corrupted. Data are OK also if they are directly imported to the 2nd server from a CD burned on the scanner via GUI. I did not try, but I'm sure that sending data directly from the scanner to the 2ns conquest would not corrupt the data


    It seems that some text fields among the private fields are changed to uint8 (as read with matlab dicominfo tool). I don't know if there is further corruption, but this is enough to make unreadable the files by processing programs. I can attach sample dicoms, but the forum seems not to accept any extension.... Any hints?


    best regardas


    Federico

    Hi Marcel, here it is a snip from the header for both corrupted and uncorrupted data (matlab dump)


    CORRUPTED

    AcquisitionNumber: 1
    InstanceNumber: 1
    FrameOfReferenceUID: '1.3.12.2.1107.5.2.7.20113.20110624093516875.0.0.0'
    Private_0029_GroupLength: 32606
    Private_0029_10xx_Creator: 'SIEMENS CSA NON-IMAGE'
    Private_0029_11xx_Creator: 'SIEMENS MEDCOM HEADER'
    Private_0029_12xx_Creator: 'SIEMENS CSA HEADER'
    Private_0029_13xx_Creator: 'SIEMENS MEDCOM HEADER2'
    Private_0029_1008: [10x1 uint8]
    Private_0029_1009: [14x1 uint8]
    Private_0029_1131: [14x1 uint8]
    Private_0029_1132: [4x1 uint8]
    Private_0029_1133: [4x1 uint8]
    Private_0029_1134: [12x1 uint8]
    Private_0029_1208: [14x1 uint8]
    Private_0029_1209: [8x1 uint8]
    Private_0029_1210: [8004x1 uint8]
    Private_0029_1218: [2x1 uint8]
    Private_0029_1219: [8x1 uint8]
    Private_0029_1220: [24288x1 uint8]
    Private_0029_1360: [4x1 uint8]
    StudyGroupLength: 24
    RequestedProcedureDescription: 'Dev MP_phant_fg'
    Unknown_0040_0000: [4x1 uint8]
    PerformedProcedureStepStartDate: '20110624'
    PerformedProcedureStepStartTime: '093514.734000'
    PerformedProcedureStepID: 'MR20110624093514'
    PerformedProcedureStepDescription: 'Dev^MP_phant_fg'
    Private_7fe1_GroupLength: 8230
    Private_7fe1_10xx_Creator: 'SIEMENS CSA NON-IMAGE'
    Private_7fe1_1010: [8192x1 uint8]



    ORIGINAL


    SeriesNumber: 4
    AcquisitionNumber: 1
    InstanceNumber: 1
    FrameOfReferenceUID: '1.3.12.2.1107.5.2.7.20113.20110624093516875.0.0.0'
    Private_0029_10xx_Creator: 'SIEMENS CSA NON-IMAGE'
    Private_0029_11xx_Creator: 'SIEMENS MEDCOM HEADER'
    Private_0029_12xx_Creator: 'SIEMENS CSA HEADER'
    Private_0029_13xx_Creator: 'SIEMENS MEDCOM HEADER2'
    Private_0029_1008: 'SPEC NUM 4'
    Private_0029_1009: 'syngo MR 2004A'
    Private_0029_1131: '12.0.15970897'
    Private_0029_1132: 8192
    Private_0029_1133: 0
    Private_0029_1134: 'DB TO DICOM'
    Private_0029_1208: 'NONIMAGE NUM 4'
    Private_0029_1209: '20110624'
    Private_0029_1210: [8004x1 uint8]
    Private_0029_1218: 'MR'
    Private_0029_1219: '20110624'
    Private_0029_1220: [24288x1 uint8]
    Private_0029_1360: 'com'
    RequestedProcedureDescription: 'Dev MP_phant_fg'
    PerformedProcedureStepStartDate: '20110624'
    PerformedProcedureStepStartTime: '093514.734000'
    PerformedProcedureStepID: 'MR20110624093514'
    PerformedProcedureStepDescription: 'Dev^MP_phant_fg'
    Private_7fe1_10xx_Creator: 'SIEMENS CSA NON-IMAGE'
    Private_7fe1_1010: [8192x1 uint8]



    Note that some fields change position, type, o even size (eg Private_0029_1360: from 3 to 4 bytes, the last byte is actually ascii code 32). Fields changed to uint8 actually inlcude ascii codes of the original text. I suppose that the most disturbing feature is the change of size (about 100 bytes on the whole file), given that import programs expect ata at a given point of the file (depending on the header content). The group/element numbers do not appear in dgate.dic (that is the original one coming with the program).


    best, Federico

    Hi,


    the typecodes of the original DICOM data are lost and cannot be set by conquest as it does not know them. What is the flow? Sender, storage, and route to matlab. The change of lenght of 3->4 is natural; dicom does not allow odd lenghts. The change in total length must be due to difference in encoding; which is valid in dicom.


    Marcel

    Hi, the flow is:
    scanner =>conquest1=>conquest2=>processing
    conquest1 stores all the data, conquest2 stores a subset that need custom processing. Because of network/firewall issues we cannot send data directrly from scanner to conquest2, nor process the data on conquest1.


    So, which is the solution? integrate dgate.dic with the due definitions? I assume that I can find them on the scanner?


    best, Federico

    Hi,


    The default littleendianimplicit transfer syntax does not transfer typecodes. Try selecting littleendianexplicit to transfer it, e.g., set compression UL in acrnema.map. Not sure that this works though.


    Marcel

Participate now!

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

Register Yourself Login