In a current project of mine, I’m presenting some backgrounds via a simple system of layered OnscreenImages.
And for the most part this works well enough!
Save that alpha would seem to not be handled in Panda in the same way as in my painting-program (GIMP). This makes it difficult to use an image’s alpha-channel to blend one OnscreenImage into another: the alpha that I paint isn’t the alpha that is rendered.
However, setting the texture’s format to “F_rgba” doesn’t seem to alleviate the problem. (And setting it to “F_srgb_alpha” makes everything far too dark!)
Is there a way that I might get my alpha-channels to line up for the purpose of layering in 2D, whether in Panda, in exporting my textures, in GIMP, or by some other means…?
Hmm… It looks like it’s primarily the darker levels of alpha that are affected; as long as I’m careful and make a point in GIMP of blending mid-to-darker levels in an alpha-mask, I seem to get acceptable results.
Ah, I didn’t know this! I’m not using CommonFilters (or indeed anything that “complex”) right now–it’s a very simple project–but it’s good to know that such functionality is available should the problem become an issue again! So thank you!
I have a feeling that all these solutions are a half-measure. The problem is that you are trying to combine images in the linear range and srgb. As a rule, artists do not work in srgb mode, because when the user turns on srgb monitor mode or srgb system mode. Your application will be too light. If you use the srgb setting when working in a graphics editor, then you need to decode the resulting images back to linear mode.
I’m currently using GIMP’s default settings, I believe.
And for what it’s worth, the GIMP documentation says the following (emphasis mine):
When opening an image with an embedded color profile, GIMP offers to convert the file to the RGB working color space. This is sRGB by default and it is recommended that all work is done in that color space.
If you use framebuffer-srgb true in Config.prc then Panda will assume you’re writing linear-space colors to the framebuffer, and you will get the correct result if you have sRGB textures. There is also a filter for this in CommonFilters, but normally framebuffer-srgb will take care of it.
However, rereading your original post, I’m not sure that this is indeed the problem - incorrect usage of sRGB can produce blending issues, but you can also look into using premultiplied alpha blending:
There is a M_premultiplied_alpha mode in TransparencyAttrib. But it expects your textures to be preprocessed in this way.
Hmm… While I’m not entirely confident that I’ve performed the pre-multiplication correctly, neither of the above options (the “srgb” switch or the use of premultiplied alpha) seems to solve the problem, I’m afraid.
Applying both brings me the closest that I’ve yet seen to the alpha-blending matching… but also causes all colours to be far too bright. :/