| Age | Commit message (Collapse) | Author |
|---|
|
Populating fakeOutputDataspace got dropped, which turned off the one-off
workaround to bypass skia's color management to encode as gamma 2.2.
Turn it back on to prevent flickers on some devices.
Bug: 293311643
Test: SilkFX test app
Change-Id: I4370756c48fe79c1b4fcbd88a3bf2579fde1bf65
|
|
Aligning HLG and PQ to 1.0 == 203 nits made SDR assets in screenshots
too dim, since both the colorspace and the color transform applied
dimming. Removing dimming application from the color transform is a
larger change, so just compensate when configuring the screenshot in
SurfaceFlinger instead.
Bug: 280347733
Test: HwAccelerationTest
Test: Navigate in and out of recents
Change-Id: Idfdb74c0c3b977717b870b2bb9a469be37d27dc9
|
|
The public HLG and PQ definitions map 203 nits to SDR white by scaling
the respective transfer functions.
Bug: 278121691
Bug: 278122024
Test: HwAccelerationTest test gradients
Test: HDR test videos match DPU and GPU composition
Test: SilkFX test HLG and PQ images
Change-Id: Id830e2ac72f5bcf8566556053fcf3af6b945581b
|
|
Previously screenshots always rendered to either an SDR or a wide gamut
colorspace. For screenshotting HDR content, this is only appropriate
when the resulting screenshot (a) never leaves the device and (b) the
relevant code has workarounds for the display to appropriately handle
its luminance range.
HDR screenshots will now have two paths:
* A standard path for rendering to HLG. HLG was chosen because the OOTF
shape is less hand-wavey than PQ's, does not require metadata, and
bands less at 8-bits of color.
* A special path for "display-native" screenshots. This is for
use-cases like screen rotation where there are stricter color accuracy
requirements for round-tripping.
Skia already encodes the resulting screenshot by supplying an HLG CICP
alongside a backwards-compatible transfer function, so it's only
sufficient to change how SurfaceFlinger renders.
Bug: 242324609
Bug: 276812775
Test: screencap binary
Test: rotation animation
Test: swiping in Recents
Change-Id: Ic9edb92391d3beb38d076fba8f15e3fdcc2b8f50
|
|
* Add util for getting buffer dataspace from metadata, since some
ANativeWindow queries are unreliable when Surface endpoints are passed
between processes, e.g., camera
* Let libshaders generate SkSL for SkColorFilters
Bug: 238395777
Test: Switching HDR cameras don't color shift
Change-Id: I7c3b917eeafcf8d028f8f52f38aa1389025bc607
|
|
This improves the quality of HDR->SDR tone-mapping in TextureView by
removing an incorrect gamut mapping which was causing undesired hue
shift.
The technical detail is that in TextureView, skia will color manage the
input image to the destination colorspace prior to tone-mapping. The
tone-mapping shader library compensates when authoring the shader to use
the correct EOTF when re-decoding the image, but did not compensate when
binding uniforms. This patch compensates accordingly so that the correct
gamut->gamut mapping is applied.
This patch adds a brief test suite for libshaders to verify that the
correct color gamut matrices are being selected.
Bug: 234355355
Test: Observe accurate HLG colors in Photos and Instagram where
TextureView is used for media playback.
Test: libshaders_test
Change-Id: I801349cfe1780880a55528fd7e91ff1ac553281b
|
|
Bug: 219698906
Test: play YouTube videos with Focus Mode on
Change-Id: Ic1d3ef72778da4e69d33c11dc11872356b856a41
|
|
Add RenderIntent as a supported uniform which is needed as some devices
may perform contrast enhancements intended for SDR content which must be
compensated for pre-blend for HDR content.
Bug: 227779465
Test: builds
Change-Id: Id74277e727d73cb9e371c37a83bef805e66271f4
|
|
Usage of current display brightness may be vendor-configured when the
display brightness is very low, so keep the OOTF in libtonemap as part
of the reference implementation.
Concretely, this means that:
* The BT2100 recommended OOTF for HLG->output format is moved from
ScaleLuminance in libshaders to be the first part of the tonemapping
operator in libtonemap
* The inverse OOTF for input format->HLG is moved from
NormalizeLuminance in libshaders to the end of the tonemapping operator
in libtonemp
* Current display brightness is only taken into account in the default
tonemapping for Android T. The historic tonemapper does not take into
account current display brightness, as it treats the "nominal peak
brightness" of the display as 1000 nits instead of the current
brightness.
Also add a default lower-bound for using the current display brightness,
because not having a bound looks really terrible on existing shipping
devices
Bug: 208933319
Test: builds
Test: HLG test video looks okay
Test: HDR10 test video didn't break
Change-Id: I4f489c68f635a8ecc4d497b98c32e91c297d0765
|
|
This is to allow for partners to take gralloc4 metadata into account for
their tone-mapping operation.
Bug: 212641375
Test: builds
Change-Id: Id20291fc1a1a0350a7fff0a8e703f242c68d2b28
|
|
...which it turns out we already do, except we apply a tone-map for
HDR10 after scaling the luminance. Don't apply the HDR10 tone-map, and
instead linearly normalize to max display luminance.
Furthermore, adjust the gamma used in the default HLG OOTF in
libshaders to take into account current display luminance according to
the BT2100 spec, which says that the OOTF gamma should be adjusted if
the effective luminance differs from 1000 nits
Bug: 208933319
Test: librenderengine_test
Test: libtonemap_test
Test: HLG and PQ test videos on youtube
Change-Id: I622096ad387420ce4769f6f080b8756cd57baa7d
|
|
A future CL will update the HLG->SDR tonemapping algorithm to consider
current display brightness, as recommended by BT2100.
In preparation for this:
* Fix an issue where maxLuminance was using the current display
brightness if supplied from DisplayManager instead of the max luminance
* Add currentDisplayBrightnessNits to the RenderEngine interface to
support the current brightness
* Plumb current display brightness all the way to libtonemap, where
nothing uses it (yet)
Bug: 206035964
Test: libcompositionengine_test
Change-Id: I3e9f0fdb23fbb08c50e4733e5a16bcd20948d750
|
|
Bug: 200307628
Test: librenderengine_test pass
Change-Id: I81d9e86e8a826a74d65ce378d01ab55496cdd944
|
|
This library is for exposing system-only shader implementations in SkSL.
Notably: libshaders depends on the vendor available libtonemap, but
libtonemap is vendor available as it is a single source of truth for
tonemap operations, whereas libshaders is not meant to be shared with
the vendor partition. Rather, the intent is to allow for sharing of SkSL
between librenderengine and libhwui.
Bug: 200309590
Ignore-AOSP-First: Introduces internal-only library
Test: builds
Change-Id: I611b79eb3addd15528f0cdb70e9f2f3d62473ec1
|