Difference in ImageStatus after processing dicom file using dcmtk library

All other questions regarding DCMTK

Moderator: Moderator Team

Message
Author
Arnoj.Saha
Posts: 13
Joined: Fri, 2023-05-05, 09:34

Difference in ImageStatus after processing dicom file using dcmtk library

#1 Post by 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
Posts: 13
Joined: Fri, 2023-05-05, 09:34

Re: Difference in ImageStatus after processing dicom file using dcmtk library

#2 Post by 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
Posts: 13
Joined: Fri, 2023-05-05, 09:34

Re: Difference in ImageStatus after processing dicom file using dcmtk library

#3 Post by 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
DCMTK Developer
Posts: 2546
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: Difference in ImageStatus after processing dicom file using dcmtk library

#4 Post by 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
Posts: 13
Joined: Fri, 2023-05-05, 09:34

Re: Difference in ImageStatus after processing dicom file using dcmtk library

#5 Post by 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
Posts: 13
Joined: Fri, 2023-05-05, 09:34

Re: Difference in ImageStatus after processing dicom file using dcmtk library

#6 Post by 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
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1497
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

Re: Difference in ImageStatus after processing dicom file using dcmtk library

#7 Post by 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
DCMTK Developer
Posts: 2546
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: Difference in ImageStatus after processing dicom file using dcmtk library

#8 Post by 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
Posts: 56
Joined: Sun, 2023-11-12, 16:50

Re: Difference in ImageStatus after processing dicom file using dcmtk library

#9 Post by George »

Marco Eichelberg wrote: Tue, 2023-10-31, 12:09 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
DCMTK Developer
Posts: 2546
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: Difference in ImageStatus after processing dicom file using dcmtk library

#10 Post by 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
Posts: 56
Joined: Sun, 2023-11-12, 16:50

Re: Difference in ImageStatus after processing dicom file using dcmtk library

#11 Post by 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
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1497
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

Re: Difference in ImageStatus after processing dicom file using dcmtk library

#12 Post by Marco Eichelberg »

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

George
Posts: 56
Joined: Sun, 2023-11-12, 16:50

Re: Difference in ImageStatus after processing dicom file using dcmtk library

#13 Post by 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
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1497
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

Re: Difference in ImageStatus after processing dicom file using dcmtk library

#14 Post by 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
DCMTK Developer
Posts: 2546
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: Difference in ImageStatus after processing dicom file using dcmtk library

#15 Post by J. Riesmeier »

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

Post Reply

Who is online

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