Closed LoganDark closed 2 years ago
Non-gamma-corrected (current behavior, left) and gamma-corrected (PR behavor, right) screenshots, side by side:
Full size (if you have a 1x screen):
The one on the right looks closer to how the reMarkable physically displays the framebuffer. It's just that the PNG image had to be prepared (gamma correction) to properly look that way in an image viewer, which generally expects sRGB from PNG images. And notice how the outlines around the buttons look a lot more consistent on the gamma-corrected screenshot.
Not sure how you'll feel about the last commit but I thought it'd be worth pushing so you can try it out. I'll probably need to revert it before this is merged :P
It might be worth incorporating a couple LUTs like that one into libremarkable itself to provide convenience functions like, for example, to_srgb
, or from_srgb
.
Embedded LUT:
real 0m0.560s
user 0m0.506s
sys 0m0.050s
rgb565
crate:
real 0m0.578s
user 0m0.556s
sys 0m0.021s
Not sure where the mismatch is, but it's close enough. Still faster than the original (0.679s)!
Is this good to merge? Anything more I need to address?
Right now, screenshot.rs takes the raw rgb values and pipes them into a PNG image.
This is not sufficient; viewers generally assume that pixel data in PNGs is sRGB (unless otherwise specified, which
screenshot.rs
does not). So map it from linear RGB to sRGB. This results in graphics looking much smoother on computer monitors.