PureBasic Forums - English

Don't know if it has been requested before but I couldn't find it.

CatchRawImage(#Image, Width, Height, *RGBAPixelBuffer)

The command would create a 32 bit image from raw pixel data in RGBA format.
The advantage would be to have a fast and cross platform way of creating images from raw data.

The idea seems good for sure. Where would these blocks of colorbits typically come from?

It's mainly a question because of my interest in assembler.
When you want to decode an image format PureBasic doesn't support or want to generate some kind of pattern such a command would be useful.
This way you could create all pixel data in memory and create a PureBasic image out of it with one command.

Currently you would either have to use Plot() for each pixel which results in a lot of procedure calls or use DrawingBuffer().
The problem with DrawingBuffer() is that according to the help file it is possible to have an image that doesn't support memory access and even if it does, you have to take into account a lot of options (is the image RGBA or BGRA, is the y coordinate flipped or not, the pitch of the buffer).
To have a cross platform command that simply takes a continuous stream of pixel data in a format that is the same on all operating systems would solve those problems.

CatchRawImage(#Image, Width, Height, *RGBAPixelBuffer, #PB_Image_32bit)
CatchRawImage(#Image, Width, Height, *RGBPixelBuffer, #PB_Image_24bit)
CatchRawImage(#Image, Width, Height, *RGBPixelBuffer, #PB_Image_16bit)

32bit is pretty straightforward but when you add in the lower depths a problem crops up. For 32bit your w*h gives the size of the memory block but at 24bit, not so much. Image colorbits at a depth of 24 must be DWORD aligned, which means that for a 10*10 image you have 32 widthbytes * 10 lines of height which comes to 320, not 300. So that raises the question, is the padding already in there or is it not? For 24 bits you might need to pass a size with it.

netmaestro wrote:Image colorbits at a depth of 24 must be DWORD aligned

Who said that? You can read byte data with PB on any supported platform.

10*10*32bit = 400 bytes (RGBA)
10*10*24bit = 300 bytes (RGB)
10*10*16bit = 200 bytes

Maybe it makes sense to specify but that could also be fixed to a specific PB-intern cross-platform format.
It is just raw pixel data, so you can draw sprites/images directly within data sections (like we did on C64 20 years ago): CatchRawImage() + CatchRawSprite().

wilbert wrote:Currently you would either have to use Plot() for each pixel which results in a lot of procedure calls or use DrawingBuffer().

You can also poke a BMP-Header in front of your raw data and use CatchImage() afterwards. That's how I do it when loading raw sound data, but of course with a WAV-Header and CatchSound(). To be a bit more precise, I use a header template which I copy and then just modify the needed values before catching. For images it may be a comfortable way to simply use SaveImage() at program initialization to create and rip the needed header template or templates.

I'm not that deep into BMP file format, but maybe the start address field of the header can be alienated to write the header somewhere else instead of directly in front of the raw image data. ...maybe...

PS: I also think a native CatchRawImage() would be nice!

Regenduft wrote:You can also poke a BMP-Header in front of your raw data and use CatchImage() afterwards.

The problem with the BMP format is that it doesn't support 32 bit images with an alpha channel.
Otherwise it might have been an option.