YaLTeR
Fix colour values not being decoded/encoded
Colloquially known as "gamma correction".
Apologies if my code is poopy or organised in the wrong place.
Colour values need to be decoded with the correct transfer function before blending or doing other stuff to them (and later encoded with the OETF (opto electrical transfer function) for display on a monitor).
The sRGB standard defines piecewise and pure power curves as transfer functions. I've opted to use the power curves, because most sRGB monitors use the pure power curve as an EOTF (x^(1/2.2)). More info can be found here with people arguing if it's right or not :) https://community.acescentral.com/t/srgb-piece-wise-eotf-vs-pure-gamma/4024
Here are some images for comparison (screenshots from recorded video, so quality is a bit meh):
The first one is where incorrectly no encoding/decoding is done, so things will look darker and "energy" isn't preserved.
+1. Sampling recording does look a lot darker than non sampling and I think this has been neglected for a while.
I assume this is a similar fix to https://github.com/crashfort/SourceDemoRender/issues/68?
Also, could you upload two videos to compare in motion?
Also, we might want to do the same change to the CPU-only fallback path, though I'm worried that it might drop the performance too much. Will need to benchmark.
I assume this is a similar fix to crashfort/SourceDemoRender#68?
yes, same fix
comparison videos: https://www.youtube.com/watch?v=Tl01yt_Uud4 https://www.youtube.com/watch?v=TaTIonPFT5k
looked at the cpu fallback code, seems way too complex for me to handle :/
Could you upload .mp4 here on github? Without YT compression
files are too big :(
put them on mediafire: https://www.mediafire.com/file/g4fxqhmdgbp4i6m/blending+clips.zip/file
As I understand, stationary frames should not change color, but they do, for example red on the very first frame: