Fix colour values not being decoded/encoded#112
Conversation
|
+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 crashfort/SourceDemoRender#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. |
yes, same fix comparison videos: 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:
|
|
oh crap. could it be because of quantisation? i'll take a look soon ™️ |
3 participants
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.