dcmcjpeg in conquest dicomserver

[ajg]

HI,

The use of dcmcjpeg in conquest dicomserver to compress lossless images causes an alteration of the header of the dicom file from ORIGINAL to SECONDARY IMAGE. This may have some legal implications.

Is this the actual behaviour of the dcmcjpeg tool or is this due to how it was called by the conquest program? dcmcjped is v3.5.3

example of file header below:

original header from sample dicom image file

(0002,0000) UL 188 # 4 MetaElementGroupLength
(0002,0001) OB \00\01 # 2 FileMetaInformationVersion
(0002,0002) UI [1.2.840.10008.5.1.4.1.1.2] # 26 MediaStorageSOPClassUID
(0002,0003) UI [1.3.46.670589.5.2.10.2156913941.892665339.718742] # 48 MediaStorageSOPInstanceUID
(0002,0010) UI [1.2.840.10008.1.2] # 18 TransferSyntaxUID
(0002,0012) UI [1.2.826.0.1.3680043.2.135.1066.101] # 34 ImplementationClassUID
(0002,0013) SH [1.4.12/WIN32] # 12 ImplementationVersionName
(0008,0000) UL 518 # 4 IdentifyingGroupLength
(0008,0005) CS [ISO_IR 100] # 10 SpecificCharacterSet
(0008,0008) CS [ORIGINAL\\PRIMARY\\AXIAL\\NORMAL ] # 30 ImageType
(0008,0016) UI [1.2.840.10008.5.1.4.1.1.2] # 26 SOPClassUID
(0008,0018) UI [1.3.46.670589.5.2.10.2156913941.892665339.718742] # 48 SOPInstanceUID


after JPEG lossless compression with DCMCJPEG.EXE lossless and decompression with DCMDJPEG.EXE by conquest dicomserver v1412c and 1413 using JPEGLossless setting.

(0002,0000) UL 192 # 4 MetaElementGroupLength
(0002,0001) OB \00\01 # 2 FileMetaInformationVersion
(0002,0002) UI [1.2.840.10008.5.1.4.1.1.2] # 26 MediaStorageSOPClassUID
(0002,0003) UI [1.3.46.670589.5.2.10.2156913941.892665339.718742] # 48 MediaStorageSOPInstanceUID
(0002,0010) UI [1.2.840.10008.1.2.4.70] # 22 TransferSyntaxUID
(0002,0012) UI [1.2.826.0.1.3680043.2.135.1066.101] # 34 ImplementationClassUID
(0002,0013) SH [1.4.12/WIN32] # 12 ImplementationVersionName
(0008,0000) UL 614 # 4 IdentifyingGroupLength
(0008,0005) CS [ISO_IR 100] # 10 SpecificCharacterSet
(0008,0008) CS [DERIVED\\SECONDARY\\AXIAL\\NORMAL] # 30 ImageType
(0008,0016) UI [1.2.840.10008.5.1.4.1.1.2] # 26 SOPClassUID
(0008,0018) UI [1.3.46.670589.5.2.10.2156913941.892665339.718742] # 48 SOPInstanceUID

anatole

[Jörg Riesmeier]

During compression, the first value of the ImageType is always set to "DERIVED".

[ajg]

I guess that is true. Does'nt that violate integrity of file. It does have legal implications.

It seems v 3.5.4 does not have this behaviour because the compression and decompression process, using lossless setting, does not change the header.

Unless there are serious bugs will be sing this new version.

Hoping the jpeg2000 will be freely available .

[Jörg Riesmeier]

It seems v 3.5.4 does not have this behaviour because the compression and decompression process, using lossless setting, does not change the header.

As already discussed in other threads, versions prior to 3.5.4 did not have a "true lossless mode", i.e. because of rounding errors the lossless compression was only visually lossless. Starting from version 3.5.4, there are two modes: --true-lossless (which is the default) and --pseudo-lossless (previous behaviour).