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

[ChrisNewell-Inari]

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

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