Difference in ImageStatus after processing dicom file using dcmtk library

[Arnoj.Saha]

Hi
We are trying to process one Dicom file. This Dicom file (2.6 GB size) is got by compressing another dicom file (4.3 GB size) by some software.
Now when we are processing the compressed file, we are calling below function to check if the file is a valid dicom file:
bool DicomFile::isDicom(const std::filesystem::path &path)
{
return DicomImage(path.string().c_str()).getStatus() == EI_Status::EIS_Normal;
}
The below two members are in the class “DicomImage” (in dcmimage.h):
Class DicomImage {
…
EI_Status ImageStatus;
DiImage *Image;
…
}
Now the call: DicomImage(path.string().c_str()) returns “DiImage* Image” and when we call:
DicomImage(path.string().c_str()).getStatus() it is giving me “EIS_InvalidImage(7)”
But ImageStatus (which is member of DicomImage class) is giving me “EIS_Normal(0)”.

Why these two values which seem to indicate the status of image processing giving two different values?
I will be sharing the compressed dicom file through a secure email to you.

NOTE: I will be posting the first reply via email by Jörg Riesmeier in below comment

[Arnoj.Saha]

Reply by Jörg Riesmeier:
Dear Arnoj,

> We are trying to process one Dicom file. This Dicom file (2.6 GB size)
> is got by compressing another dicom file (4.3 GB size) by some
> software. Now when we are processing the compressed file, we are
> calling below function to check if the file is a valid dicom file:
> bool DicomFile::isDicom(const std::filesystem::path &path) {
> return DicomImage(path.string().c_str()).getStatus() ==
> EI_Status::EIS_Normal; } The below two members are in the class
> "DicomImage" (in dcmimage.h):
> Class DicomImage {
> ...
> EI_Status ImageStatus;
> DiImage *Image;
> ...
> }

I don't think that loading a 2.6 GB file (with all pixel data) just in order to check whether the file is a DICOM image does not seem to make much sense to me.
At least you should limit the number of frames to be processed by specifying the "fcount" parameter of the DicomImage constructor.

> Now the call: DicomImage(path.string().c_str()) returns "DiImage*
> Image" and when we call: DicomImage(path.string().c_str()).getStatus()
> it is giving me "EIS_InvalidImage(7)" But ImageStatus (which is member
> of DicomImage class) is giving me "EIS_Normal(0)".
>
> Why these two values which seem to indicate the status of image
> processing giving two different values? If needed I can share the
> compressed dicom file to you in a secured way like I did before.

Looking into the implementation of DicomImage::getStatus(), the answer should be obvious:

inline EI_Status getStatus() const
{
return (Image != NULL) ?
Image->getStatus() : ImageStatus;
}

By the way, what Transfer Syntax is used for this particular DICOM image file?
And what is the output to the debug logger?

[Arnoj.Saha]

The Transfer syntax is below:
(0002,0010) Transfer Syntax UID 1.2.840.10008.1.2.4.70 (JPEG Lossless, Nonhierarchical, First - Order Prediction (Processes 14[Selection Value 1]))

Can you guide me where I can find the debug logger?

I have sent an email with the compressed Dicom file (2.6 GB size) via secure email which is having the problem

[J. Riesmeier]

I haven't downloaded the file, but in order to process JPEG-compressed DICOM images with the DicomImage Class, you have to register support for the JPEG decoders in your application.
The following excerpt is from the source code of DCMTK's sample application dcm2pnm:

Code: Select all

    // register JPEG decompression codecs
    DJDecoderRegistration::registerCodecs(opt_decompCSconversion, EUC_default,
        EPC_default, opt_predictor6WorkaroundEnable, opt_cornellWorkaroundEnable,
        opt_forceSingleFragmentPerFrame);

Details of DCMTK's logging framework can be found in the oflog module. And, here are some additional Howtos.

[Arnoj.Saha]

We are calling DJDecoderRegistration::registerCodecs() with default parameter values like below (without passing any parameters):

Some code …
DJDecoderRegistration::registerCodecs();
Some code …

So how we will decide what parameters to pass to above function in this particular case of decompression of this particular dicom file?
NOTE: In dcm2pnm.cc, I saw that the parameter values are passed through command line while running dcm2pnm.

[Arnoj.Saha]

Hi

Is there any suggestion to our last question?
Also, wanted to explore if you have any paid support for certain time duration?

Regards.

[Marco Eichelberg]

I have looked at the test image you provided. Due to the file size, you simply cannot decompress it, because the decompressed pixel data element would be larger than 4 GBytes, the upper limit for (7fe0,0010) Pixel Data in uncompressed format.
You can, however, use DcmElement::getUncompressedFrame() to decompress individual frames without trying to decompress the entirety of the dataset. See https://support.dcmtk.org/docs/classDcm ... 64efeeaca3

[J. Riesmeier]

Alternatively, the DicomImage Class also allows for passing an optional "fcount" parameter to the constructor, which limits the number of frames that are processed at the same time.
Also see this Howto on how to "access multi-frame images without loading complete pixel data".

[George]

I have looked at the test image you provided. Due to the file size, you simply cannot decompress it, because the decompressed pixel data element would be larger than 4 GBytes, the upper limit for (7fe0,0010) Pixel Data in uncompressed format.
You can, however, use DcmElement::getUncompressedFrame() to decompress individual frames without trying to decompress the entirety of the dataset. See https://support.dcmtk.org/docs/classDcm ... 64efeeaca3

Hello Marco Eichelberg,

It would be nice to share a functional example of using the function DcmElement::getUncompressedFrame(), I only found this https://github.com/InsightSoftwareConso ... /diinpxt.h
It would be extremly nice if you use this large file as a sample https://drive.google.com/file/d/1rBZw-o ... vD5D6/view

also please explain why the file limit is 4GB and not more. is there any way to bypass this?

Regards
George

[J. Riesmeier]

also please explain why the file limit is 4GB and not more. is there any way to bypass this?

The Pixel Data (7fe0,0010) Data Element has a Length Field of 32-bit, so the maximum size of uncompressed pixel data is (usually) limited to about 4.2 GB.

Only recently, CP-2083 introduced a new Transfer Syntax that encapsulates the uncompressed pixel data (similar to compressed pixel data) and, therefore, allows for encoding more than 4.2 GB of pixel in uncompressed format.
Please note, however, that the DCMTK does not yet support this new Transfer Syntax (see DCMTK issue #1000).

[George]

Hello,

I follow up on this, was it added to our support because I need to decompress large files?

Best Regards
George

[Marco Eichelberg]

No. It is on the "to do list", but not yet implemented (and not likely to get done soon).

[George]

Hello,

What can be done to deal with this issue aside from using gdcmconv? because I think it smarter to directly extract images rather than splitting
If possible I would love to join your team to help progessing this problem, I noticed that you have contributers.

Best Regards
George

[Marco Eichelberg]

We usually receive pull requests via the DCMTK mirror on GitHub https://github.com/DCMTK/dcmtk

Note, however, that support for the uncompressed encapsulated transfer syntax requires modifications rather deeply in the DICOM parser. This is not a trivial task, and unless you have multiple years of experience with DCMTK, I would not recommend this as a toy project. There is a reason why we have not implemented it yet.

[J. Riesmeier]

In addition to what Marco wrote: You could also sponsor development if this would be an option (see also this blog posting).