changes in version 3.6.6 when handling compressed transfer syntax

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
aanghele
Posts: 1
Joined: Tue, 2021-12-14, 18:08

changes in version 3.6.6 when handling compressed transfer syntax

#1 Post by aanghele » Tue, 2021-12-14, 19:01

I have a dataset with original transfer syntax EXS_JPEGProcess14SV1

the following code behaves differently in dcmtk 3.6.3 vs 3.6.6

Code: Select all

auto originalTS = m_dataset->getOriginalXfer(); //EXS_JPEGProcess14SV1
auto cond = m_dataset->chooseRepresentation(EXS_LittleEndianExplicit, nullptr); // no errors

//prepare to write object to stream
m_dfile->transferInit();
m_dfile->validateMetaInfo(EXS_JPEGProcess14SV1); // no erros
auto isValid = m_dataset->canWriteXfer(EXS_JPEGProcess14SV1) // returns true in v3.6.3 and false in v3.6.6

//elementLength returns the correct answer '31494' in  v3.6.3; v3.6.6 returns '4404'  
Uint32 elementLength =
    m_dfile->getMetaInfo()->calcElementLength(EXS_JPEGProcess14SV1, EET_ExplicitLength) +
    m_dfile->getDataset()->calcElementLength(EXS_JPEGProcess14SV1, EET_ExplicitLength); 

My questions are:
1. what changed in version 3.6.6
2. why does m_dataset->canWriteXfer(EXS_JPEGProcess14SV1) return false if the dataset's original syntax is EXS_JPEGProcess14SV1.
3. switching the current representation back to EXS_JPEGProcess14SV1 seems to fix the elementLength, why is this necessary ?

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1314
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

Re: changes in version 3.6.6 when handling compressed transfer syntax

#2 Post by Marco Eichelberg » Thu, 2022-01-13, 15:08

The reason is that decompression (i.e. the first call to chooseRepresentation()) often changes attributes other than the pixel data, such as PhotometricInterpretation.
In DCMTK 3.6.3, writing such datasets in the original transfer syntax will result in inconsistent files: compressed pixel data, but metadata of the uncompressed dataset.
In DCMTK 3.6.6, this problem is "fixed" by removing the original (compressed) representation after decompression. That is ugly but fixes the inconsistency problem.

Post Reply

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 1 guest