File HEADER cahnges using J1 (JPEGLossless) compression

    JPEG changes


    JPEGLossless which in the dicom.ini file corresponds to J1
    is a commonly used compression format by dicom3 compliant
    software and equipment. While this is supported by conquest,
    I observed that the image file is altered after it is decompressed.
    The header are change from primary to secondary image.


    In both our CT scan and efilm software when the images are sent to the conquest server set at JPEGLossless and the retrieved, images are unusable for 3D reconstruction in the workstation. Images may viewed individually and show no change in quality but identified by the software as individual images and not part of a series.


    It is the Headers that are modified from PRIMARY to SECONDARY after decompression.


    This occurs when using both native compression ( dgate feature) and DCMTK JPEG compression binaries. The problem is present from version 1410 to the present 1412c.


    It does not happen when using NKI compression.


    Is this an expected behaviour? Is there a way to avoid this outcome when using JPEGLossless compression.



    Thanks for any information



    ajg

    Hello,


    I did try the other available options from lossless JPEG. The result seems to be the same. DCMCJPEG.EXE that is comes from OFFIS changes the Header tag as shown below.


    original header from conquest sample 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


    (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



    It can be clearly shown that (0008,0008) CS has change. This header is not reverted to the original even after decompresssion.



    This behaviour, I hope will be given a warning in the manual. This will bite anyone trying to save space ( Like those with multislice CT which can generated 3-4G of image data per study) Reconstruction on some 3D workstations on this modified files is not possible. The one we use, Leonardo from Siemens, will recongnize the changes. We can no longer use the files in the study for image postprocessing like Volume rendering and coronal sagittal reformations and others.


    This behaviour does not happen with NK compression.

    Although your observation about the header changes is correct, the problems you encounter are most likely not caused by changing attribute 0008,0008 (Image Type).


    The neccessary tag for identifying image type (IOD) is 0008,0016 (SOPClassUID) which is not altered because it is still 1.2.840.10008.5.1.4.1.1.2 (CTImageStorage)


    If EFilm and other Applications do not sort these images correctly into studies/series then have a look at the following attributes:
    0020,000D (StudyInstanceUID)
    0020,000E (SeriesInstanceUID)


    have a look whether these attributes are altered (maybe because of the correction algorithm for illegally space padded UIDs). If not post a complete header of two images formerly belonging to a series and after compression and retrieval from conquest do not anymore.


    Btw.: the lossess in JpegLossess compression only refers to the pixeldata, not the header.


    Regards,
    Andreas

    Hi,


    Thanks for the reply. I agree that this is an issue with DCMCJPEG.EXE and I will ask OFFIS people.


    The attributes 0020,000D (StudyInstanceUID) 0020,000E SeriesInstanceUID)
    are not altered with the test I have conducted. Only the following are modified


    Original
    (0002,0000) UL 194 # 4 MetaElementGroupLength
    (0002,0010) UI [1.2.840.10008.1.2] # 18 TransferSyntaxUID
    (0008,0000) UL 508 # 4 IdentifyingGroupLength
    (0008,0008) CS [ORIGINAL\\PRIMARY\\OTHER] # 22 ImageType
    (0028,0000) UL 170 # 4 ImagePresentationGroupLength

    Compressed
    (0002,0000) UL 198 # 4 MetaElementGroupLength
    (0002,0010) UI [1.2.840.10008.1.2.4.70] # 22 TransferSyntaxUID
    (0008,0000) UL 608 # 4 IdentifyingGroupLength
    (0008,0008) CS [DERIVED\\SECONDARY\\OTHER ] # 24 ImageType
    (0028,0000) UL 184 # 4 ImagePresentationGroupLength



    This header added
    (0008,2111) ST [Lossless JPEG compression, selection value 1, point transform 0, compression ratio 1.5305 ] # 90 DerivationDescription


    I have a hunch that the applications we use treat secondary image as unique individual sets. Don't know if this is a dicom 3 requirement.


    The only disadvantage of not having a restorable J1 compression is not having its the space saving capability and being able to browse the images with dcm file viewers like infranview.


    Thanks again for your help.



    anatole

    If your application treats these images as different sets although StudyInstanceUID and SeriesInstanceUID were not change, then this is an illegal behaviour.


    In the case of E-Film (1.9) I can not reproduce this with Conquest and Jpeg Lossless compression.


    Try to query/retrieve these images with K-PACS (you have to enable JPegLossless TS in the Server Administration tool)


    Regards,
    Andreas

    Hi,


    I agree that it would be an illegal behaviour when an application treats these images as different sets although StudyInstanceUID and SeriesInstanceUID were not change


    I will copy the error generated by our worktstation. Any try to post it.
    Will inform manufacturer of problem



    Is it expected that images converted to JPEG lossless should have their
    HEADER (0008,0008) modified to SECONDARY?


    Anatole

    Hello,


    An undate on JPEGlossless j1. It appears that the failure of the images to restore completely for 3D reconstruction was related to skips in the series of images being compressed. There appears to have been gaps in the sequence of images. I am still reconstructing the behaviour.
    A fresh installation of the dicomserver 1412c and regeneration of the database index was done and a new set of images are being saved and retrieved without problem.

    The errors came when the 2000+ images on a CT study gets retrieved as chunks of 20 to 50 image sets with gaps between sets.
    This problem may be related to the bug 20070127:


    I will be observing this in a couple of days and see if this is software or a hardware problem.



    The header (0008,0008) CS [DERIVED\\SECONDARY\\OTHER ] # 24 ImageType is modified but this is not the problem because the despite the change in the header, the images retrieved in the newly setup server was accepted by the our workstation without a glitch.



    Anatole

    HI,


    I manage to correct the problem of dcmcjpeg changing the header to secondary image by using the newer OFFIS DCMTK (DICOM ToolKit) software version 3.5.4. This is a downloadable win i386 binary from the website.


    Maybe it would be possible to upgrade the compression tool distributed with conquest. The newer verison has New lossless JPEG encoder that guarantees "true lossless" compression in contrast to the old implementation which could cause rounding errors in certain cases.


    :D

Participate now!

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

Register Yourself Login