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
dcmcjpeg in conquest dicomserver
Moderator: Moderator Team
-
- ICSMED DICOM Services
- Posts: 2217
- Joined: Fri, 2004-10-29, 21:38
- Location: Oldenburg, Germany
Behaviour is different with v3.5.4
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 .
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 .
-
- ICSMED DICOM Services
- Posts: 2217
- Joined: Fri, 2004-10-29, 21:38
- Location: Oldenburg, Germany
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).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.
Who is online
Users browsing this forum: No registered users and 1 guest