bzotto / rgba_bitmap Goto Github PK

One problem is that there aren't any easy ways to produce RGBA images. Someone may have generated a logo in Gimp and now they need to load it as an OpenGL texture to use it in ImGui... this would be such an an easy matter if the image was in RGBA format. However, Gimp cannot save RGBA images. Gimp cannot save any image format that is easy to read in order to convert it to RGBA, or to an OpenGL texture. We need something.

For myself I made a small program, png2rgba.cpp. It seems to work pretty well with most forms of PNG (I tried it on the PngSuite set). Take it, convert it to pure C or do whatever. I think RGBA would gain more traction if there was some way to produce RGBA:
https://gist.github.com/roaral/c6cc2eae2b65c1fdb27dcdb86725cfab

:)

I propose after before RGBA signature (for differs between version) add length value, and after image data add CRC32 checksum. And will align of 16 byte in header, and will one huge PNG chunk ever.

I'm working on steganography (not stenography) with 24-bit RGB and 32-bit RGBA images in the BMP format, with all my code in C. BMP files have an annoying number of bytes in the header that play no role for me, and an RGBA file with the simple format you suggest is really excellent. I have drafted out some possible enhancements for such files, which can have the extension .rgby or .rgbz to hold 24-bit RGB and 32-bit RGBA data.

My suggestions are as folllows:

1. The signature can be "RGBY" for 24-bit and "RGBZ" for 32-bit data.
2. instead of storing the width and height as 2 unsigned 32-bit integers, store them in the lower 14 bits of 2 unsigned 16-bit short integers. The upper 2 bits in the width short and the 2 bits in the height short can store additional information, such as whether the color channels are RGB or BRG, and likewise when an alpha channel is present, whether it is below or above the byte order of the color channels. The order left to right or right to left in columns, and top to bottom or bottom to top is rows can also be specified.
3. An additional enhancement is that if the width is specified as zero (leaving the upper 2 bits unchanged), the height can instead store the width as a power of 2 in the lowest 4 bits of the short, and the height can be stored as a power of 2 in next 4 bits in the short. Thus an image with a width of 512 pixels and a height of 256 pixels would be stored as 10001001 or 0x89 in the lower 8 bits of the short. The idea of powers of 2 is to make processing the image with an FFT easier.
4. 8 bytes have been used so far, and the 32 bits previously used to store the height in an .rgba file are freed up and can store an id number or some other information. This can be useful if a large number of files are created by placing an id in each one. The header is still 12 bytes long, but can store additional information.

I've only drafted out some preliminary idea, and have not yet written any code. Let me know what you think.

I can be contacted at [email protected]

Christopher Sharp