Use proper sRGB conversion in DepthCamera #766
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🦟 Bug fix
No ticket was filed for this issue
Summary
Depth Camera uses an approximation for sRGB conversion.
This causes regular Camera to slightly but visibly differ in their RGB output compared to the one done by Depth Camera (stored encoded as RGBA8888 in the A channel of the DepthCamera).
This fix causes cameras to identically match 100% both outputs (possibly some GPUs may have a margin of error of up to 1/255 due to precision issues with floating points. DepthCamera already suffers a few problems due to assembly code not understanding that we store a binary encoded value in a F32 value; and sometimes denormals or NaNs get flushed).
Without this patch, here's a an output of a Regular Camera (Note these pictures were taking using Garden while this PR is targeting Fortress):
And here's an output of a Depth Camera:
The shades of green are quite apart (R, G, B) and can be seen by the naked eye if you toggle between them:
The shadow is also in a different colour, but there's no point to keep pointing it out.
After this patch, the output produced is binary identical.
Update: Correction. It's NOT binary identical. The error seems to be up to 3 / 255. A bit more than I'd hope, but much better than having the current massive error where it's even visible with the naked eye.
Update:
The error depends on GPU and backend. However it is quite good. At worst case, only 14 pixels out of 10.000 pixels were not exact with a max seen error of 9 / 255.
Vulkan backend fares MUCH better in providing exact results (these tests were made in Garden, not in Fortress).
Checklist
codecheck
passed (See contributing)Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining
Signed-off-by
messages.