Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.

Dicom ReadImageRLE bug with 16-bit

Thomas_Jensen1
Beginner
379 Views

I think there is a bug in the IPP samples (ipp-samples.8.0.0.005), dicom.cpp, function ReadImageRLE().

With 16-bit RLE-encoded data, the bug surfaces:

  if(precision  > 8)
  {
    ippsSwapBytes_16u_I((Ipp16u*)decData, width * height);
    image.CopyFrom((Ipp16s*)decData, step, roi);    // BUG
  }
  else
    image.CopyFrom(decData, step, roi);

The step parameter is wrong. It is a copy of image.Step(), and it should be the step of the decData buffer, which is width*2.

The bug presents itself with either scanline mismatches in the resulting image, or with an AV because of buffer overflow.

Also, possibly Ipp16u should be used in CopyFrom, since pixels are usually 16u. Otherwise, the Dicom tag Pixel Representation should be used to determine if the pixels are signed or not.

Suggestion:
    image.CopyFrom((Ipp16u*)decData, width*2, roi);
 

0 Kudos
2 Replies
Sergey_K_Intel
Employee
379 Views

Hi Thomas,

Many thanks for finding this. Unfortunately, it is impossible for us to update the samples, because we are stopping support of UIC/Picnic samples, due to changed priorities to GPU support mostly.

Regards,
Sergey

0 Kudos
Thomas_Jensen1
Beginner
379 Views

I have understood that samples are end-of-life, but I also posted about that in the sticky note.

Just curious!

0 Kudos
Reply