0

I have a native char* buffer containing an RGBA image. The problem seems to be that it is a real RGBA format, and not the windows style ARGB. (which stands for BGRA, backwards)

The object must be created from the buffer without copying it.

So far, I'm using a BitmapSource that is created from the buffer using:
BitmapSource::Create Method (Int32, Int32, Double, Double, PixelFormat, BitmapPalette, IntPtr, Int32, Int32)
I have tried System::Drawing::Bitmap, But unfortunately it seems to only support window's ARGB format, and not "normal" RGBA.

Now I would like have a DeleteObject(BitmapSource ^ ) function to free the buffer it is using. It should be called after object's use.
With the Bitmap it is quite simple: 

void DeleteObject(Bitmap^ bmp)
{
    if (bmp == nullptr) 
    {
        return;
    }
    Rectangle rect(0, 0, bmp->Width, bmp->Height);
    System::Drawing::Imaging::BitmapData^ bmpData =
        bmp->LockBits(rect, System::Drawing::Imaging::ImageLockMode::ReadWrite,
        bmp->PixelFormat);

    delete [] (char*) bmpData->Scan0->ToPointer();

    bmp->UnlockBits(bmpData);
    bmp->~Bitmap();
}

I would like to do something similar with the BitmapSource (or anything else that may use RGBA).

How can i safely free the BitmapSource buffer ?
How can i get the underlying buffer of a BitmapSource?

I don't mind using any other C# object that can use and display an RGBA buffer (real RGBA, not windows style ARGB).

Yochai Timmer
  • 48,127
  • 24
  • 147
  • 185
  • Hmm, no, that delete[] operator call does nothing. That memory wasn't allocated by your CRT's new[] operator. The Bitmap destructor of course releases the allocation. – Hans Passant Nov 11 '13 at 18:03
  • possible duplicate of [How do you make sure WPF releases large BitmapSource from Memory?](http://stackoverflow.com/questions/1684489/how-do-you-make-sure-wpf-releases-large-bitmapsource-from-memory) – Hans Passant Nov 11 '13 at 18:04
  • @HansPassant The memory in the bitmap was created using a new[] operator. Hence the need to free it. – Yochai Timmer Nov 11 '13 at 18:44
  • And no, it's not a duplicate. This memory buffer isn't managed at all. It originated in native c++ code. – Yochai Timmer Nov 11 '13 at 18:46
  • Uh, if there's no native pixelformat supporting your byte order, then you simply _can't_ create your new image without copying the data, unless you edit the bytes to reverse them per 4 _inside_ the existing buffer. – Nyerguds Jan 10 '18 at 13:47
  • By the way, ARGB does not stand for byte order A, R, G, B, but for the order of the values in a read Int32. The fact the bytes in it are reversed is simply because this value is little-endian. – Nyerguds Jan 10 '18 at 13:49

0 Answers0