Proposal: Choosing the background color or export transparency

[Conclusio]

It would be useful to be able to choose the background color (e.g. white) for documents/publications.
Alternatively, since the screenshot tool saves PNG files, one could use transparency information from the frame buffer.

[BrutPitt]

Hi, and thanks for your post.

Currently is already possible (just from latest release) chose the background color, although it is influenced from post processing settings (like glow, gamma, bright, contrast, exposure, tone-mapping, etc), and also (mostly) blending process is affected accordingly.

You can select it from following widget:

I admit that it is not very visible from dark GUI (euphemistic: I need to add at least a label!), better on light GUI:

For what concerns: "to export transparency", it could be a good idea.
I want to study if export a "mask" or leave to select a background color for transparency...

Any suggestion about this?

[Conclusio]

Thank you for the quick response!

Indeed, I did not see the control to change the background color.
But you're right - every post-processing step has influence on the result, especially the "display adjust" section, which cannot be turned off. So choosing a background color would not immediately solve the issue. For example on your homepage: It would be quite hard to match the background color of the resulting image to your used dark-blue background of #002033, since gamma, brightness, etc. influence the result.

So, the way to go would be to save the alpha information into the PNG file. Selecting a color for transparency is not the correct approach. E.g. black background and black shadows would be treated equally as transparent, although they should not. Also it would not allow for semi-transparency, but only act as a binary indicator, leading to really ugly borders, for example with glow.

I did not look too much into your implementation, but since you're blending, I assume you have a framebuffer with RGBA components. Since you have post-processing shaders which basically remove the transparency information (e.g. the FXAA shader returns 1.0 as alpha component), you have two options:

1. Save the framebuffer's alpha channel after blending is complete and before post-processing for a later PNG export
2. Change all post-processing shaders to return the original texture's alpha value (e.g. for FXAA)

Personally, I would go with the first one. While saving the PNG file you can then use the currently displayed RGB color information as usual and add the alpha information from after the blending stage as the PNG's alpha channel.

If your PNG exporter does not support writing alpha channel values, you can save it as an extra grayscale file. It can easily be manually combined afterwards in e.g. Photoshop.

[BrutPitt]

Yes, you are right about background color, and also the FXAA was implemented with the intention of working with the "solid" rendering and depth buffer, so I does not thought to alpha.
Now the fast way is copy the alpha value of the central pixel... and seems works (without consequence on other renderings on video, but I need to test it more deeply.)

The other post processing routines works with vec4 (glow: blur/deNois filters) or don't touch it (DisplayAdjust: gamma, exposure, bright, contrast and tone-mapping).

I tested the post processing DisplayAdjust: both with blending and solid rendering (but without glow), and seems OK:

blending	solid

The glow procedure, indeed seems to degrade alpha (smooth excessively) : below a little sample:

original	saved with alpha

I need to investigate more deeply

Currently I'm working on rendering engine. (I'm adding transformFeedback), so I have a few things out of place, but I hope to can implement a beta for new PNG with alpha saving in one or two days (max in the Week End)

The way to differentiate the capture?
I had thought one of the following:

• with left-shift/left-control+PrtScrn capture without alpha (like currently happens) and with right-shift/right-control+PrtScrn capture with alpha.
• a flag in the "Settings (F8)" window to select or one or the other saving type (keeping the same keys)

Alternative?

[BrutPitt]

And instead I have already published a beta to test it:
https://github.com/BrutPitt/glChAoS.P/releases/tag/v1.4.3beta
But there are only binaries for Win and Linux, and source files are still not updated in repository.

FXAA now is not a simply pass-through (I don't copy simply the alpha value of central pixel), but I still need to test/investigate on glow filters (blur and deNoise)

[Conclusio]

Interesting. So, I did have a look at the beta version.

I don't think that using the alpha value of the central pixel is the way to go.
Example (biCplxJ m.4) no glow, no tonemapping:

normal	with alpha	alpha + black

So the first image (normal) should be the same as exporting with per-pixel alpha values and choosing a black background in Photoshop (alpha + black). That cannot be achieved with using only one transparency value for the whole picture.

The way to differentiate the capture?
I had thought one of the following:

* with left-shift/left-control+PrtScrn capture without alpha (like currently happens) and with right-shift/right-control+PrtScrn capture with alpha.

* a flag in the "Settings (F8)" window to select or one or the other saving type (keeping the same keys)

Alternative?

I do have a counter proposal. Instead of introducing a distinction between saving with/without alpha, the user can actually control the export behavior by choosing the background color:

• either no background color (= RGBA=(0,0,0,0)), or
• a background color, but fully opaque (only RGB, no alpha to choose from)

If "no background" is chosen, the PNG export would be with transparency, otherwise the result is a normal blending with opaque background.

At the moment, the program behaves a bit unexpected with transparent background color values. If one chooses the background as RGBA = (255,0,0,0) (i.e. transparent red) - it is still drawn as solid red, although it shouldn't be visible at all. That's probably because of the post-processing steps, at some point the alpha channel is ignored and everything is set to opaque. The question is though, is that correct behavior? Two different RGBA values in the final framebuffer:

• RGBA1 = (255, 0, 0, 128)
• RGBA2 = (255, 0, 0, 255)

would be converted to full red (RGB = (255, 0, 0)) if the alpha value is just ignored. But should they? Probably not, since they are different colors.

Without changing too much of your program, the easiest and safest bet is to introduce the new key bindings as you already proposed. But you should think about what the use cases are for a semi-transparent background and why the user would ever want that in the first place.