PhotometricInterpretation

Engineering
1

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

1 Like
2

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

3

Hello Francois,

Thanks for the reply. I am reading this DICOM series using GDCM (no experience with DCMTK…)

As I wrote, it quits on an assert, but works otherwise. Please advise.

Thanks
Dominik

4

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
  • It appears that the assert fails because it checks that the pixel format has not been changed between here and here if this condition is false, meaning if the image is not `gdcm::PhotometricInterpretation::PALETTE_COLOR.
  • However, the pixel format can be modified here because inside GetBufferInternal(), the correct codec is called to decode the image and inside the TryJPEG2000Codec function 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.

2 Likes
5

@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:

6

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

  bool operator==(const PixelFormat &pf) const
    {
    return
      SamplesPerPixel     == pf.SamplesPerPixel &&
      BitsAllocated       == pf.BitsAllocated &&
      BitsStored          == pf.BitsStored &&
      HighBit             == pf.HighBit &&
      PixelRepresentation == pf.PixelRepresentation;
    }
7

@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 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.

1 Like
8

Ah, yes, IM-0001-0520.dcm
before (file)

  BitsStored  :12
  HighBit     :11

after openjpeg decoder

  BitsStored  :11
  HighBit     :10

gdcmJPEG2000Codec updates PixelFormat here or here

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?

9

Dear all,

So what is the conclusion? How should I proceed reading such DICOMs?

Thank you for your support,
Dominik