commit 1d3a8d8892b6920cd26d2e99dfc4efb87b6999c0
author Christopher Cameron <ccameron@chromium.org> Thu Sep 22 19:37:32 2022
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Thu Sep 22 19:37:32 2022
tree a15aa6231088cf60834ad3469b2588072f6e4d93
parent cc1000086dd061af774903e22061b4e8187d607a

GpuImageDecodeCache: Fix decoding 8-bit HDR images

When HDR support was initially added, we performed color conversion
at image decode time. The color conversion was a conversion to an
extended-sRGB type space, where we needed to represent values >1.
This required setting the decode SkColorType to kRGBA_F16_SkColorType,
lest we clamp the >1 values.

This created a problem for decoders that couldn't decode 8-bit image
into a float16 buffer, and would just fail.

We've shuffled all of this around, and now we try to do as little
pixel work as possible at decode time. As a result, when decoding
an 8-bit PQ or HLG image, we gain very little by our current policy
of forcing the output to be kRGBA_F16_SkColorType (perhaps a little
precision, even less precision if if we're decoding to YUV).

The tone mapping (which creates out-of-range values, and requires a
buffer that is kRGBA_F16_SkColorType) now happens far away in
ColorConversionSkFilterCache::ConvertImage.

Change this behavior to only decode to kRGBA_F16_SkColorType if the
decoder itself indicates that it would prefer to decode to
kRGBA_F16_SkColorType. Leave in place the restriction that this is
also restricted to HDR images being drawn to HDR displays (meaning
that we will truncate all high precision images to 8 bits per pixel).

Bug: 1266456
Change-Id: I641910717175e96bbbae3a61ba6a080d462baeec
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3910319
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1050336}