Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Choosing the background color or export transparency #4

Open
Conclusio opened this issue Dec 16, 2019 · 5 comments
Open

Proposal: Choosing the background color or export transparency #4

Conclusio opened this issue Dec 16, 2019 · 5 comments
Labels
enhancement New feature or request

Comments

@Conclusio
Copy link

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
Copy link
Owner

BrutPitt commented Dec 17, 2019

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:
Screenshot at 2019-12-17 09-04-58

I admit that it is not very visible from dark GUI (euphemistic: I need to add at least a label!), better on light GUI:
Screenshot at 2019-12-17 09-05-28

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?

@BrutPitt BrutPitt added the enhancement New feature or request label Dec 17, 2019
@Conclusio
Copy link
Author

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
Copy link
Owner

BrutPitt commented Dec 17, 2019

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:

sShot_20191217_18431 sShot_20191217_18457
blending solid

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

sShot_20191217_184946 sShot_20191217_18505
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
Copy link
Owner

BrutPitt commented Dec 17, 2019

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
Copy link
Author

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 alpha alpha plus black
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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants