mitk::ImageDataItem::ComputeItemSize() calculates the size in bytes necessary to hold an image volume. With big images (e.g. µCT) this limit hits early, is not recognized and the calculated size is completely wrong due to multiple integer overflow.
To reprocude this, all you need is something like this:
mitk::PixelType pixel_type = mitk::MakeScalarPixelType<short>();
unsigned int image_dimensions[3];
image_dimensions[0] = 1600;
image_dimensions[1] = 1600;
image_dimensions[2] = 5000;
mitk_image->Initialize(pixel_type, 3, image_dimensions);
// this should allocate ~20GB but does much less
mitk::ImagePixelWriteAccessor<short, 3> write_access(mitk_image.GetPointer(), mitk_image->GetVolumeData());
short* voxel_end = write_access.GetData() + 1600 * 1600 * 5000;
for (short* voxel = write_access.GetData(); voxel < voxel_end; ++voxel) {
*voxel = 1; // this will generate an illegal access beyond the allocated memory
}A fix would be to use size_t instead of unsigned long to hold ImageDataItem's m_Size.
This fix could produce/unveil a series of follow-up bugs where other types than size_t are used to hold byte sizes. I'd look into it but will not be able to do so soon.
