Yes BGRABitmap.data can accessed stable as bytes, across the systembounderies (Win, Linux,..)Thanks. I see from your code and a test I did that TBitmap.RawImage.Data is also a contiguous array of bytes. I can probably put that characteristic to good use as well.
See some samples here https://github.com/afriess/GSTCamera/tree/master/pasv4l/demos. I have got troubles wit 3-Byte and 4-Byte Bitmaps, BGRABitmap was for me the fastest soloution.
Hi!Thanks. You gave me some ideas. I've been fighting with GTK all day (Linux Manjaro). It refuses to deal with anything that doesn't have an alpha channel. It wouldn't even let me create a TBitmap with BPP of 24. With one exception: if I created the TBitmap by LoadFromFile.
I never tried that, but I know:
The unit GraphType contains the TRawImageDescription.
This contains the the byte field AlphaPrec. If it is set to 0 this means Alpha is unused.
If you set that the you can misstreat the Alpha channel for other use.
I hope it works, but I don't know.
Winni
OpenCV library
I use the modern C++ version of OpenCV (right now 4.5):OpenCV library
BTW: Which version of OpenCV you use and what pascal wrapper ?! The reason is, i want to know a functional version of OpenCV for fpc/Lazarus
Just to give some extra info on Data in BGRABitmap.Thanks. The more I looked at TBGRABitmap, the more it seemed like you solved several cross-platform problems in one stroke, and added many sophisticated functions. I remember the vertical flip of the scanlines from the CImage class in MFC. I don't remember the reason for it but there was a flag somewhere that indicated if they were flipped so you could unflip them if needed. The padded column width in bytes (stride) I've seen in other places too.
There are 3 things to consider: the line order, padding and pixel format.
Line order can be bottom to top or top to bottom depending on the system. So it is ok to loop over all pixels to change them as long as it doesn't matter what is the vertical position. Otherwise, you need to use Scanline for each line or to apply the correct delta, either adding or subtracting RowSize bytes or Width for a PBGRAPixel type.
About padding, it can happen with OpenGL bitmaps. The TBGLBitmap can be padded in order to have a size that is compatible with OpenGL. So in this case, RowSize will be a correct delta in bytes, but Width won't be. You need to use AllocatedWidth instead to get the delta in pixels. You could as well loop though all the Data by using AllocatedWidth*Height pixels, though that would be doing unnecessary processing for the padding pixels.
About pixel format, TBGABitmap is always 8-bit BGRA or RGBA. But you can use another format by using another class. Currently those are defined:
- TLinearRGBABitmap contains 32-bit float linear RGBA (16 bytes total per pixel)
- TExpandedBitmap contains word linear RGBA (8 bytes total per pixel)
- TGrayscaleMask contains 1-byte linear gray
- TXYZABitmap contains 32-bit float XYZA (16 bytes total per pixel)
- TWordXYZABitmap contains word XYZA (8 bytes total per pixel)
I guess one could define a 24-bit RGB format. You can look at existing formats to see how it is done to create one if you're interested. If you have any question, feel free to ask.