<div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>I'm trying to read a DICOM file using ITK and GDCM and I have found a bug case. The file in question has BitsAllocated = 16, BitsStored = 8, RescaleSlope = 1.0, and ResceleIntercept = 0.0. With this combination the ITK-GDCM pipeline produces a buffer overflow because size of the buffer allocated by ImageFileReader is half of the expected one by GDCM. This happens because of a combination of factors.<br>
<br>In GDCMImageIO m_ComponentType is set CHAR or UCHAR because gdcm::Rescaler::ComputeInterceptSlopePixelType() determines that the values fit in 8 bits. Then, ImageFileReader computes the needed buffer size this way:<br>
</div><br>size_t sizeOfActualIORegion = m_ActualIORegion.GetNumberOfPixels() * (m_ImageIO->GetComponentSize()*m_ImageIO->GetNumberOfComponents());<br><br></div>Here GetComponentSize() returns 1, and thus 1 byte per pixel is allocated (there is also only 1 component). But then, GDCM needs 2 bytes per pixel, as returned by gdcm::Bitmap::GetBufferLength(), which takes into account BitsAllocated independently of other factors.<br>
<br></div>So, here's the conflict. I'm thinking that maybe m_ComponentType should be set directly according to BitsAllocated and ignoring rescale, but I don't really know if that would break other things.<br>
<br>
</div>This bug has been found using ITK 3.20.1 and GDCM 2.0.19, but looking at the code of current versions, the involved code has not changed.<br></div>