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

Make CRT filter more sRGB-correct #38

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

y2kcyborg
Copy link
Contributor

Background

I noticed that applying the CRT filter with parameters that should be neutral would instead affect the brightness of sources, and ended up digging into the sRGB handling.

I created a test image, which may not preview correctly here:

Test image of black-and-white and transparent-and-white checkerboards against a mid grey and mid alpha background

The top half has checkerboards of black and white pixels at different scales, against a mid-grey background. The bottom half is similar but with transparent and white checkerboards and a mid-transparent white background.

If viewing the image at 1:1 pixel scale, composited on a black background, with decent monitor calibration and nothing like f.lux running that messes with color curves, when looking at the image from a distance the checkerboards should fade into the background color. The 1px checkerboards might not, depending on monitor subpixels.

The image is a good check that the srgb conversions in a filter are correct, that alpha is handled correctly, etc.

Testing

01-test-setup

I'm testing on a 1080p canvas with a scene that has a black color source under the test image, set to apply alpha in linear space.

02-filter-setup

I'm testing with most of the CRT filter settings turned off, and just playing with bloom settings.

Results

Please view results at 1:1 scale and without f.lux / night mode!

Before this PR, with no bloom:

03-before-changes-no-bloom

After this PR, with no bloom:

04-after-changes-no-bloom

This image looks correct and top and bottom sections look identical.

Before this PR, 16px strong bloom:

05-before-changes-16px-bloom

After this PR, 16 px strong bloom:

06-after-changes-16px-bloom

It's not yet perfect in terms of the alpha results, but it's an improvement.

Before this PR, 16px medium bloom:

07-before-changes-16px-mid-bloom

After this PR, 16 px medium bloom:

08-after-changes-16px-mid-bloom

The bloom and compositing have changed, but with some tweaks to the parameters a similar look can be recreated:

Before, defaults with with black/white levels at 0/255:

09-before-defaults-no-bw-level

After, and tweaking params:

11-after-tweaked-defaults

Implementation

gs_effect_set_texture_srgb is called instead of gs_effect_set_texture for texture parameters that should be srgb-decoded.
gs_enable_framebuffer_srgb(true) is called when rendering to a render target that should be srgb-encoded.

Blur is performed on premultiplied colors.

Bloom is changed to a linear mix of premultiplied samples. This is more physically correct; the existing bloom is more like the classic XB360 era bloom, that might be fun as its own retro effect!

@y2kcyborg
Copy link
Contributor Author

Oh, and I've not yet had a chance to test opengl, and have not yet applied the premultiply fix to the opengl version of the gaussian blur effect!

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

Successfully merging this pull request may close these issues.

1 participant