+2
−0
Loading
Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more
Introduce a debug sysprop, defaulted to false, to allow for rewriting the transfer function to sRGB when set to true. This is due to several considerations: 1. SurfaceFlinger has not color managed SMPTE 170M properly ever since color management was introduced in Android O, and was only fixed in Android 13. This means that some camera -> encoding -> storage -> playback flows may be incorrectly calibrated on some devices since SMPTE 170M was reinterpreted as sRGB for a long time. 2. BT. 1886 recommends a reference EOTF of gamma 2.4 with tuneable parameters to approximate a CRT on a non-CRT display. Because the framework doesn't support BT. 1886 and it's too late to add support, casting as sRGB is probably okay for now and matches old behavior. 3. Typical Rec. 709 content is graded assuming a dim surround, but phone displays are used in a wide range of viewing environments, which means that viewing Rec. 709 content in a bright environment may appear to have lower contrast. Decoding as sRGB will push the dark codes into lower luminance levels, which will improve contrast in those scenarios. Note that it's better to adjust contrast based on the ambient viewing environment, but again it's too late for Android 13 to improve the color pipeline in the GPU. Bug: 229442032 Test: Photos playback after recording a video Change-Id: I64fc8f2ea77f8e595333de36fb9da2979d8316ca