# PhotometricInterpretation
**URL:** https://discourse.itk.org/t/photometricinterpretation/1837
**Category:** Engineering
**Created:** [May 4, 2019, 8:44am UTC](https://discourse.itk.org/t/photometricinterpretation/1837 "2019-05-04T08:44:30Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@Dominik\_Szczerba](https://discourse.itk.org/u/Dominik_Szczerba)
#### Post date: [May 4, 2019, 8:44am UTC](https://discourse.itk.org/t/photometricinterpretation/1837/1 "2019-05-04T08:44:31Z")
Reading a compressed DICOM series I have an assertion failing at
itkAssertInDebugAndIgnoreInReleaseMacro( pixeltype\_debug == pixeltype );
If I run in a Release mode (NDEBUG) I get my file read all right, I have no problem with it. Please guide me understanding what is happening, why and how I should go on doing things right (I need to work in debug mode).
Thanks!
Dominik
---
### Author:  [@fbudin](https://discourse.itk.org/u/fbudin)
#### Post date: [May 6, 2019, 12:46pm UTC](https://discourse.itk.org/t/photometricinterpretation/1837/2 "2019-05-06T12:46:24Z")
Hello Dominik,
Would you be able to share the data that creates this issue? Are you manually selecting the DICOM IO you are using (GDCM, DCMTK)?
Best,
Francois
---
### Author:  [@Dominik\_Szczerba](https://discourse.itk.org/u/Dominik_Szczerba)
#### Post date: [May 6, 2019, 3:02pm UTC](https://discourse.itk.org/t/photometricinterpretation/1837/3 "2019-05-06T15:02:48Z")
Hello Francois,
Thanks for the reply. I am reading this DICOM series using GDCM (no experience with DCMTK…)
> **[Thorax-Abdo.7z](https://www.dropbox.com/s/6h2gtqm5aw7l83h/Thorax-Abdo.7z?dl=0)**
>
> Shared with Dropbox
As I wrote, it quits on an assert, but works otherwise. Please advise.
Thanks
Dominik
---
### Author:  [@fbudin](https://discourse.itk.org/u/fbudin)
#### Post date: [May 8, 2019, 5:32pm UTC](https://discourse.itk.org/t/photometricinterpretation/1837/4 "2019-05-08T17:32:09Z")
Hello Dominik,
I looked more into it. This is maybe a small bug in DCMTK or simply in `itkGDCMImageIO`. Maybe @mathieu.malaterre could confirm this.
Tracing the execution lead me to see that:
- the assert message you see comes from [here](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/GDCM/src/itkGDCMImageIO.cxx#L323)
- It appears that the assert fails because it checks that the pixel format has not been changed between [here](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/GDCM/src/itkGDCMImageIO.cxx#L287) and [here](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/GDCM/src/itkGDCMImageIO.cxx#L323) if [this](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/GDCM/src/itkGDCMImageIO.cxx#L321) condition is false, meaning if the image is not `gdcm::PhotometricInterpretation::PALETTE\_COLOR.
- However, the pixel format can be modified [here](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/IO/GDCM/src/itkGDCMImageIO.cxx#L312) because [inside `GetBufferInternal()`](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmBitmap.cxx#L908), the correct codec is called to decode the image and inside the [`TryJPEG2000Codec` function](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmBitmap.cxx#L712-L819) the `HighBit` (at least in the case of your image) can be modified.
So, the assert in `itkGDCMImageIO` is a little to strict. The simple solution would be to remove it, but maybe there is a way to keep it and make the `if` statement around it more restrictive to avoid this type of issues.
---
### Author:  [@mathieu.malaterre](https://discourse.itk.org/u/mathieu.malaterre)
#### Post date: [May 9, 2019, 6:49am UTC](https://discourse.itk.org/t/photometricinterpretation/1837/5 "2019-05-09T06:49:35Z")
@fbudin You forgot one item in your demonstration. The PixelFormat `==` operator only checks the ScalarType (uint16 vs uint32). So we should not care about the `HighBit` value here. See:
- [https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmPixelFormat.cxx#L147-L149](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmPixelFormat.cxx#L147-L149)
---
### Author:  [@mihail.isakov](https://discourse.itk.org/u/mihail.isakov)
#### Post date: [May 9, 2019, 12:18pm UTC](https://discourse.itk.org/t/photometricinterpretation/1837/6 "2019-05-09T12:18:35Z")
> The PixelFormat == operator only checks the ScalarType (uint16 vs uint32).
not sure about the subject, didn’t look closer, but IMHO PixelFormat’s “==” operator does check bits stored / allocated/ high bit ?
[here](https://github.com/InsightSoftwareConsortium/ITK/blob/9e122664724eb049955c968c054247c00d92eee2/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmPixelFormat.h#L215)
```
bool operator==(const PixelFormat &pf) const
{
return
SamplesPerPixel == pf.SamplesPerPixel &&
BitsAllocated == pf.BitsAllocated &&
BitsStored == pf.BitsStored &&
HighBit == pf.HighBit &&
PixelRepresentation == pf.PixelRepresentation;
}
```
---
### Author:  [@fbudin](https://discourse.itk.org/u/fbudin)
#### Post date: [May 9, 2019, 3:28pm UTC](https://discourse.itk.org/t/photometricinterpretation/1837/7 "2019-05-09T15:28:49Z")
@mathieu.malaterre , I ran the program step by step in debug mode and it was going in the `operator==` function that @mihail.isakov pointed out. To reproduce the problem, I actually simply downloaded the code from an ITK example [here](https://itk.org/ITKExamples/src/IO/GDCM/ReadDICOMSeriesAndWrite3DImage/Documentation.html) and downloaded the dataset provided by @Dominik_Szczerba. The reader works for some of the `dcm` files and fails for some. Maybe they use a different codec? But if you want to reproduce the problem, you can use the example I pointed to and create a repository with only the `IM-0001-0520.dcm` file.
---
### Author:  [@mihail.isakov](https://discourse.itk.org/u/mihail.isakov)
#### Post date: [May 9, 2019, 6:25pm UTC](https://discourse.itk.org/t/photometricinterpretation/1837/8 "2019-05-09T18:25:15Z")
Ah, yes, IM-0001-0520.dcm
before (file)
```
BitsStored :12
HighBit :11
```
after openjpeg decoder
```
BitsStored :11
HighBit :10
```
gdcmJPEG2000Codec updates PixelFormat [here](https://github.com/InsightSoftwareConsortium/ITK/blob/9e122664724eb049955c968c054247c00d92eee2/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmJPEG2000Codec.cxx#L806) or [here](https://github.com/InsightSoftwareConsortium/ITK/blob/9e122664724eb049955c968c054247c00d92eee2/Modules/ThirdParty/GDCM/src/gdcm/Source/MediaStorageAndFileFormat/gdcmJPEG2000Codec.cxx#L1497)
Probably not a problem.
**Edit** :
> So we should not care about the `HighBit` value here.
may be something like
`itkAssertInDebugAndIgnoreInReleaseMacro( pixeltype_debug.GetScalarType() == pixeltype.GetScalarType() );`
were better, if we don’t care about bits stored/high bit?
---
### Author:  [@Dominik\_Szczerba](https://discourse.itk.org/u/Dominik_Szczerba)
#### Post date: [May 24, 2019, 10:01am UTC](https://discourse.itk.org/t/photometricinterpretation/1837/9 "2019-05-24T10:01:59Z")
Dear all,
So what is the conclusion? How should I proceed reading such DICOMs?
Thank you for your support,
Dominik