How to change TransferSyntaxUID

[csmeso]

We have got a bad DICOM file, containing wrong content in meta tag (0002,0010) TransferSyntaxUID:

# Dicom-File-Format

# Dicom-Meta-Information-Header
# Used TransferSyntax: Little Endian Explicit
(0002,0000) UL 216 # 4, 1 FileMetaInformationGroupLength
(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion
(0002,0002) UI =MultiframeTrueColorSecondaryCaptureImageStorage # 28, 1 MediaStorageSOPClassUID
(0002,0003) UI [1.2.276.0.113.2.1.1439.230823.1.230823093415119.5] # 50, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianExplicit # 20, 1 TransferSyntaxUID
...

# Dicom-Data-Set
# Used TransferSyntax: Little Endian Explicit
...
(0008,0016) UI =MultiframeTrueColorSecondaryCaptureImageStorage # 28, 1 SOPClassUID
...
(0028,0002) US 3 # 2, 1 SamplesPerPixel
(0028,0004) CS [YBR_PARTIAL_420] # 16, 1 PhotometricInterpretation
(0028,0006) US 0 # 2, 1 PlanarConfiguration
(0028,0008) IS [3193] # 4, 1 NumberOfFrames
(0028,0009) AT (0018,1063) # 4, 1 FrameIncrementPointer
(0028,0010) US 1080 # 2, 1 Rows
(0028,0011) US 1920 # 2, 1 Columns
(0028,0100) US 8 # 2, 1 BitsAllocated
(0028,0101) US 8 # 2, 1 BitsStored
(0028,0102) US 7 # 2, 1 HighBit
(0028,0103) US 0 # 2, 1 PixelRepresentation
(0028,0301) CS [NO] # 2, 1 BurnedInAnnotation
(0028,2110) CS [01] # 2, 1 LossyImageCompression
(0028,2114) CS [ISO_14496_10] # 12, 1 LossyImageCompressionMethod
(0040,0555) SQ (Sequence with explicit length #=0) # 0, 1 AcquisitionContextSequence
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(7fe0,0010) OW (not loaded) # 65813376, 1 PixelData


As you can see, the correct TransferSyntaxUID is probably MPEG4HighProfile/Level4.1 (because the PixelData is in mp4 format).
How can this be changed in DcmFileFormat object?

[Marco Eichelberg]

I don't think that changing the UID in the metaheader is a function that is foreseen in DCMTK because the transfer syntax value is directly bound to the encoding used, i.e. if you change transfer syntax to MPEG4, then DCMTK will look for an encoder module that would convert uncompressed pixel data to MPEG4 (which is not present in DCMTK).

Furthermore, the file is not a valid MPEG4 DICOM file anyway. Attribute (7fe0,0010) PixelData uses the 'OW' value representation and an explicit length, both of which are illegal in compressed objects.
So if this is really MPEG4, fixing the object would involve writing your own class derived from DcmCodec that claims to be able to convert from uncompressed to MPEG4 and that, when called, would access the byte array in Pixel Data, check whether this is really MPEG4, and then create the sequence-like structure starting with the Basic Offset Table that DICOM expects for compressed data.

[Marco Eichelberg]

On the other hand, if this is just a single file you are trying to fix, I would use dcmdump +W and dump2dcm to convert the dataset to a text file, and back, while keeping the pixel data in the binary file created by the dcmdump +W option.