Difference in ImageStatus after processing dicom file using dcmtk library
Moderator: Moderator Team
-
- Posts: 13
- Joined: Fri, 2023-05-05, 09:34
Difference in ImageStatus after processing dicom file using dcmtk library
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
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
-
- Posts: 13
- Joined: Fri, 2023-05-05, 09:34
Re: Difference in ImageStatus after processing dicom file using dcmtk library
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?
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?
-
- Posts: 13
- Joined: Fri, 2023-05-05, 09:34
Re: Difference in ImageStatus after processing dicom file using dcmtk library
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
(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
-
- 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
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:
Details of DCMTK's logging framework can be found in the oflog module. And, here are some additional Howtos.
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);
-
- Posts: 13
- Joined: Fri, 2023-05-05, 09:34
Re: Difference in ImageStatus after processing dicom file using dcmtk library
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.
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.
-
- Posts: 13
- Joined: Fri, 2023-05-05, 09:34
Re: Difference in ImageStatus after processing dicom file using dcmtk library
Hi
Is there any suggestion to our last question?
Also, wanted to explore if you have any paid support for certain time duration?
Regards.
Is there any suggestion to our last question?
Also, wanted to explore if you have any paid support for certain time duration?
Regards.
-
- 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
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
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
-
- 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
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".
Also see this Howto on how to "access multi-frame images without loading complete pixel data".
Re: Difference in ImageStatus after processing dicom file using dcmtk library
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
-
- 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
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.also please explain why the file limit is 4GB and not more. is there any way to bypass this?
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).
Re: Difference in ImageStatus after processing dicom file using dcmtk library
Hello,
I follow up on this, was it added to our support because I need to decompress large files?
Best Regards
George
I follow up on this, was it added to our support because I need to decompress large files?
Best Regards
George
-
- 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
No. It is on the "to do list", but not yet implemented (and not likely to get done soon).
Re: Difference in ImageStatus after processing dicom file using dcmtk library
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
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
-
- 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
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.
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.
-
- 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
In addition to what Marco wrote: You could also sponsor development if this would be an option (see also this blog posting).
Who is online
Users browsing this forum: Ahrefs [Bot], Amazon [Bot] and 1 guest