ImageEncoder with Alphasupport / variable depth

Got an idea for enhancing PureBasic? New command(s) you'd like to see?
benubi
Enthusiast
Enthusiast
Posts: 215
Joined: Tue Mar 29, 2005 4:01 pm

ImageEncoder with Alphasupport / variable depth

Post by benubi »

Hello PureBasic-Team,

I maybe found a simple solution to enhance the Purebasic ImageDecoder/Encoder plugins so Images can be loaded and stored with an Alphachannel, but still with being backward-compatible to the image plugins that do not support alpha channels yet. For the moment, I realy don't know how PB manages to load an alpha channel at all (Png ?) because the SDK examples do not show it clearly....

; Encoders ----------------

The simplest way I think is to implement a kind of "PB_Register_ImageEncoder2" internal function in PB. This function will be used by the plugins internaly, like shown in the SDK examples ( lcc directory).

PB could decide by itself if it uses the alphaencoder/normal encoder, or it could be triggered by the User in a flag during SaveImage/SaveSprite.
The prototypes for the encoders could look like this:

classic:
int Encode(char *Filename, char *Buffer, int Width, int Height, int LinePitch, int Flags); // PB_Register_ImageEncoder()

new:
int Encode2(char *Filename, char *Buffer, int Width, int Height, int LinePitch, int Flags, char *AlphaChannel); // PB_Register_ImageEncoder2()

If *AlphaChannel pointer is NULL, the image has no alphachannel to store... The new encoders should be able to handle this on their own.
Alpha channels should have a linepitch equal to their width then, an be stored as simple byte-arrays in the memory.

; Decoders ---------------
On the other side the same thing could be done for decoding. e.g. if "CheckImage" returns 2 instead of 1 or 0, this could simply mean for PB that there's an alphachannel in the image! so pb could allocate 32bits instead of 24bits per pixel. this would allow to keep the decoders fully backward-compatible.
So the decoder-VT's could be left totaly unchanged.

With the CheckImage-function returning the presence of an alpha-channel, there is no later need for additional functions like "getDepth" or "getAlpha" in the VT :)
This only, if the pixel are 32 bit broad then. if there is a separated alpha-channel, there should be a new VT for alpha-decoders so that the decoder-function can retrieve the address of the alphachannel.


classic:
int Decode(char *Buffer, int LinePitch, int Format); // PB_Register_ImageDecoder()

new:
int Decode2(char *Buffer, int LinePitch, int Format,char *AlphaChannel); // PB_Register_ImageDecoder2()

; ---------------------

PB should internaly check at first for the new encoder/decoder. This would allow to replace step by step the old plugins or simply to add new one's. Or i suggest that the internal functions may be changed to something like I wrote, so all plugins should be modified and recompiled (also the userlibs hehe).

To store alpha channels, I had to write my own plugins and put therefor additional functions like e.g. "TGAEncoderSetAlphaChannel(*Buffer)" and it works but each plugin has then its own set of help functions and it is not realy "pretty" and well-ordered for me.

Sorry for my english and thank you for checking the idea :)
Thorium
Addict
Addict
Posts: 1305
Joined: Sat Aug 15, 2009 6:59 pm

Re: ImageEncoder with Alphasupport / variable depth

Post by Thorium »

32bit are 24bit for the colors and 8bit for alpha channel. Don't know if PNG encoder supports alpha, but decoder does.
Alpha channel in memory is not stored as a byte array, it's stored as a part of the pixel information: BGRA
freak
PureBasic Team
PureBasic Team
Posts: 5940
Joined: Fri Apr 25, 2003 5:21 pm
Location: Germany

Re: ImageEncoder with Alphasupport / variable depth

Post by freak »

PB 4.40 supports loading and saving of alphachannels for formats that can store the data.
quidquid Latine dictum sit altum videtur
Post Reply