Corrupt Multi-frame File - Consistent for all image sizes.

[ChrisNewell-Inari]

Describe the bug

When attempting to generate a US Multiframe Image, (Using OtherBytePixelData) I run into an error where frame 1001 (regardless of image size) is always corrupt. Frames 1000 & 1002 are correctly represented in the DICOM image.

To Reproduce

The list of System.Drawing.Bitmap provided to this function is a bitmap of size 1x1, where each bitmap alternates between Red & Blue.

     private void AddImagePixel(List<Bitmap> frames)
    {
        _dataset.AddOrUpdate(DicomTag.SamplesPerPixel, (ushort)3);
        _dataset.AddOrUpdate(DicomTag.PhotometricInterpretation, PhotometricInterpretation.Rgb.Value);
        _dataset.AddOrUpdate(DicomTag.Rows, (ushort)frames.First().Height);
        _dataset.AddOrUpdate(DicomTag.Columns, (ushort)frames.First().Width);
        _dataset.AddOrUpdate(DicomTag.BitsAllocated, (ushort)8);
        _dataset.AddOrUpdate(DicomTag.BitsStored, (ushort)8);
        _dataset.AddOrUpdate(DicomTag.HighBit, (ushort)7);
        _dataset.AddOrUpdate(DicomTag.PixelRepresentation, (ushort)PixelRepresentation.Unsigned);
        _dataset.AddOrUpdate(DicomTag.PlanarConfiguration, (ushort)PlanarConfiguration.Interleaved);

        // pixelData resolves to OtherBytePixelData at runtime
        var pixelData = DicomPixelData.Create(_dataset, true);
        // GetValidImage converts the bitmap to Format24bppRgb & GetColorBytes swaps the format to BGR
        foreach (var frame in frames)
        {
            PinnedByteArray pixels = ImageHandler.GetColorBytes(ImageHandler.GetValidImage(frame));
            MemoryByteBuffer buffer = new(pixels.Data);
            pixelData.AddFrame(buffer);
            pixels.Dispose();
        }
    }


    // here is the file generation code for good measure
    public string SaveDicomFile(DicomFile dicomFile, string fileName, string storagePath)
    {
        string path = Path.GetFullPath(storagePath);

        if (!Directory.Exists(path))
        {
            Directory.CreateDirectory(path);
        }

        path = Path.Combine(path, fileName) + ".dcm";
        dicomFile.Save(path);

        return path;
    }

Expected behavior
When opening the generated DICOM File, produced by the above & related code that adds additional tags, all frames should be present, alternating between a Red & Blue background.

Screenshots or test DICOM files
Frame 1000 (even frame numbers are always blue)

Frame 1001 (should be red)

Frame 1002

Environment
Fellow Oak DICOM version:
fo-dicom.core, Version=5.1.2.0

OS: Win 11 Pro Version 22H2 Build 22621.3155
Platform: .NET 6

[gofal]

Sadly I cannot reproduce your issue. Maybe you could post this generated file.
Because I don't know how the method ImageHandler.GetColorBytes looks like, I used a modified version of your code to reproduce:

        var _dataset = new DicomDataset();
        _dataset.AddOrUpdate(DicomTag.SOPInstanceUID, DicomUID.Generate());
        _dataset.AddOrUpdate(DicomTag.SOPClassUID, DicomUID.SecondaryCaptureImageStorage);

        _dataset.AddOrUpdate(DicomTag.SamplesPerPixel, (ushort)3);
        _dataset.AddOrUpdate(DicomTag.PhotometricInterpretation, PhotometricInterpretation.Rgb.Value);
        _dataset.AddOrUpdate(DicomTag.Rows, (ushort)1);
        _dataset.AddOrUpdate(DicomTag.Columns, (ushort)1);
        _dataset.AddOrUpdate(DicomTag.BitsAllocated, (ushort)8);
        _dataset.AddOrUpdate(DicomTag.BitsStored, (ushort)8);
        _dataset.AddOrUpdate(DicomTag.HighBit, (ushort)7);
        _dataset.AddOrUpdate(DicomTag.PixelRepresentation, (ushort)PixelRepresentation.Unsigned);
        _dataset.AddOrUpdate(DicomTag.PlanarConfiguration, (ushort)PlanarConfiguration.Interleaved);

        // pixelData resolves to OtherBytePixelData at runtime
        var pixelData = DicomPixelData.Create(_dataset, true);
        // GetValidImage converts the bitmap to Format24bppRgb & GetColorBytes swaps the format to BGR
        for (var i = 0; i < 1500; i++)
        {
            MemoryByteBuffer buffer = (i %2 == 0) ?
                new MemoryByteBuffer(new byte[] {255,0,0 })
                : new MemoryByteBuffer(new byte[] { 0, 0, 255});
            pixelData.AddFrame(buffer);
        }

        var file = new DicomFile(_dataset);
        string path = Path.GetTempFileName();
        file.Save(path);

You see, I dot not use Bitmaps or PinnedMemoryBuffers etc, but directly wrote the bytes into the frames. The output (with fo-dicom as well as with MicroDicom) was fine, all frames altered from red to blue. Not a single frame was black.

Please also try this code, that I provided. If this method works fine, then the issue likely within your ImageHandler methods.
Also I am interested, that is the software that you are using for displaying the file? have you tried several applications? the issue could also be in rendering the frame.

[ChrisNewell-Inari]

@gofal
Thank you for your response, after doing some more debugging, a colleague found an overflow issue, here is his analysis:

I tried to use the solution from Corrupt Multi-frame File - Consistent for all image sizes. · Issue #1761 · fo-dicom/fo-dicom (github.com), The generated DICOM file still has issue which frame 1001 is blank.

For a further investigation, after call pixelData.AddFrame(buffer) (Previously we talked about similar findings but that at the ‘save’ phase not add frame phase)

1. If the media is less than 1000 frames, for example 280 frames (960X960 pixel), both count and length is correct (280x960x960x3 = 774,144,000)
   

2. If the media is larger than 1000 frames, for example 1087 (960X960 pixel), the length is correct (1087960960*3 = 3,005,337,600) but the count is not, is seems overflow to become negative.
   

The detail error information is “Array dimensions exceeded supported range”.

So it seems issue happened at add frame, before even called ‘save’ function.

But test with 1500 frames and 1 pixel by pixel, as suggest by Corrupt Multi-frame File - Consistent for all image sizes. · Issue #1761 · fo-dicom/fo-dicom (github.com), the count is correct, not overflow since it only has 1500x1x1x3=4500, but the frame 1001 is still blank. Which means that count overflow may not be the direct issue towards it.