Page 1 of 1

wxPalette PNG and GIF images undocumented?

Posted: Sat Aug 03, 2019 8:10 pm
by Mick P.
Some of the documentation here is unclear:

https://docs.wxwidgets.org/trunk/classwx_palette.html

https://docs.wxwidgets.org/trunk/classw ... ndler.html

The first says PNG and GIF images with palettes will use wxPalette. I'm interested in this. Except I have yet to come across information about wxImage::GetData ever being 8-bit color indices. You have to read between the lines to figure out it can be RGB or RGBA, but nothing ever says it's just 1B indices.

Secondly, it's annoying that there isn't an option for loading these images without palettes (by converting to RGBA on the fly) and I can't see a workflow for ripping out the palette, assuming it's there. Will SetPalete(wxPalette()) convert to full color? If so, wouldn't it be better to do that while loading? Maybe there is an undocumented option. How to tell what is the size of GetData() pixels?

EDITED: wxIMAGE_OPTION_PNG_BITDEPTH exists: "Bit depth for every channel (R/G/B/A)."

I don't see a "GetDepth" method for wxImage. Or anything related to depth. So I assume it is guess based on HasAlpha and HasPalette :?:

Re: wxPalette PNG and GIF images undocumented?

Posted: Sat Aug 03, 2019 8:48 pm
by doublemax
In general, support for 8bit bitmaps is low. wxImage is always 24 or 32 bit. Only a wxBitmap can be 8bit.

I'd avoid using 8bit bitmaps all together.

Re: wxPalette PNG and GIF images undocumented?

Posted: Sat Aug 03, 2019 9:45 pm
by Mick P.
So how would GetPalette work? If the palette is saved, but the index image is not?

Any large image that is indexed can be large memory saving, which helps when transferring images, like loading a "texture" from system memory to video memory. (It's unpacked on the video side. Takes up less space backed in system memory. Faster transfer.)

In any case, according to the documentation, a PNG or GIF file that is indexed will generate an indexed wxImage file. There is a feature macro wxUSE_PALETTE that enables these features. I don't know off hand if it's on for the public release binaries. It would be pointless though to have such features if they are only available to custom builds.

(If the palette is only there to be reverse indexed I hope the documentation would not omit such important information! My sense of it is 8-bit is just undocumented. Waiting to crash someone's code. IntelliSense says wxUSE_PALETTE is 1. I will have to run tests I suppose. I am in the planning stages. It could be a while, but I will report my findings.)

Re: wxPalette PNG and GIF images undocumented?

Posted: Sat Aug 03, 2019 10:27 pm
by doublemax
So how would GetPalette work? If the palette is saved, but the index image is not?
Did you even read the documentation for wxImage::GetPalette and SetPalette?
In any case, according to the documentation, a PNG or GIF file that is indexed will generate an indexed wxImage file.
Where does it say that? That would be wrong. Like i said, *wxImage* is 24 or 32 bit, no exceptions.

Re: wxPalette PNG and GIF images undocumented?

Posted: Sat Aug 03, 2019 11:14 pm
by Mick P.
Did you even read the documentation for wxImage::GetPalette and SetPalette?
It's pretty unremarkable?
Where does it say that? That would be wrong. Like i said, *wxImage* is 24 or 32 bit, no exceptions.
"Some of the wxImage handlers have been modified to set the palette if one exists in the image file (usually 256 or less colour images in GIF or PNG format)" (https://docs.wxwidgets.org/trunk/classwx_image.html)

FWIW I did just look at wxPalette itself... it is strangely implemented. I expected something very basic. It seems weird if the palette is provided, and the only way to use it is to do a reverse look-up on individual pixels.

Re: wxPalette PNG and GIF images undocumented?

Posted: Sat Aug 03, 2019 11:20 pm
by doublemax
"Some of the wxImage handlers have been modified to set the palette if one exists in the image file (usually 256 or less colour images in GIF or PNG format)"
That just means that you can access the original palette of the image file, even if the image was converted to 24bit. I assume the palette will also be used when you save a wxImage as GIF.

Re: wxPalette PNG and GIF images undocumented?

Posted: Sat Aug 03, 2019 11:28 pm
by Mick P.
It looks like maybe GetPixel (wxPalette) also finds closest matches. Maybe internally it is a spatial lookup system.

In my case it's not useful. It's funny wxWidgets implements saving images when the loading system is so fragile. Priorities.

Re: wxPalette PNG and GIF images undocumented?

Posted: Thu Aug 29, 2019 2:41 pm
by Mick P.
doublemax wrote:
Sat Aug 03, 2019 8:48 pm
In general, support for 8bit bitmaps is low. wxImage is always 24 or 32 bit. Only a wxBitmap can be 8bit.

I'd avoid using 8bit bitmaps all together.
I'm returning to this. Do you know if 32bit data is real? Or do mean the alpha channel is not interleaved with the RGB data? That is 24bit+8bit alpha in separate buffer? wxWidgets is pretty stingy on image APIs. The ability to load images is nice, but they are not good if you need to flip the image, or have interleaved alpha. It always requires doing multiple copies, and writing manual code.

Re: wxPalette PNG and GIF images undocumented?

Posted: Thu Aug 29, 2019 3:02 pm
by doublemax
The alpha channel is separate, it's not interleaved RGBA. And yes, this is annoying for image processing code. But nothing stops you from using wxImage only for loading and then copying it over into your own custom image class.

Re: wxPalette PNG and GIF images undocumented?

Posted: Thu Aug 29, 2019 4:10 pm
by Mick P.
I dunno. For 3D productivity software, it often has to load data much like a video game, except that the data isn't prepared in advance as it is in a game. I think wxWidget's developers could be more considerate. Images can be many megabytes. Ideally you want to load them into general memory once, and then transfer to video memory. How the mask is stored in wxImage is ridiculous, considering the bytes are 24bit instead of 32bit, and so don't fit into units processors can directly work with.

I think wxImage is long in the tooth and should be retired from use. The wxWidgets team should rewrite the loaders with an intermediary data structure, that can map to wxImage, and replace wxImage with a better designed, flexible interface.