P3 and Rec2020 do not match on SkiaColorSpace and gfx::ColorSpace |
||
Issue description
CanvasRenderingContext is currently using gfx::ColorSpace for both canvas color space and the color space of the media drawn to it. Since Skia has added support for Rec2020 and P3 gamuts, it's better to get aligned with Skia and use these gamuts for the canvas color space. Trying to do this, I noticed that the following color spaces do not match (they don't pass SkColorSpace::Equals):
SkColorSpace::MakeRGB(SkColorSpace::kLinear_RenderTargetGamma,
SkColorSpace::kRec2020_Gamut)
gfx::ColorSpaceColorSpace(gfx::ColorSpace::PrimaryID::BT2020,
gfx::ColorSpace::TransferID::LINEAR_HDR).ToSkColorSpace().ToSkColorSpace()
------> Fail
SkColorSpace::MakeRGB(SkColorSpace::kLinear_RenderTargetGamma,
SkColorSpace::kDCIP3_D65_Gamut)
gfx::ColorSpace(gfx::ColorSpace::PrimaryID::SMPTEST432_1,
gfx::ColorSpace::TransferID::LINEAR_HDR).ToSkColorSpace()
------> Fail
I believe this might be due to the different primaries used:
https://cs.chromium.org/chromium/src/third_party/skia/src/core/SkColorSpacePriv.h?type=cs&l=34
https://cs.chromium.org/chromium/src/ui/gfx/color_space.cc?type=cs&l=562
,
Apr 17 2017
I've run into similarly annoying issues with SkColorSpace::Equals(). If I do: orig = SkColorSpace::MakeRGB(); new = SkColorSpace::MakeICC(SkICC::WriteICC(orig.fn(), orig.toXYZ()); SkColorSpace::Equals(orig, new) is false because the floats don't round-trip perfectly through ICC fixed point. It would be cool gfx and SkColorSpace used the same primaries... but I'd guess the "equals" failure is more likely tied to really tiny floating point diffs. Maybe there should be a version of SkColorSpace::Equals() with some tolerance?
,
Apr 17 2017
Sgtm. Chris is putting up a fix for the current issue. I was wondering what is the effect of different primaries (and transfer functions) on the browser compatibility? I'm thinking if we need to be more clear about the color spaces (e.g., clearly specifying the matrices) in the proposal.
,
Apr 17 2017
I agree that the spec proposal should be very clear on color spaces with multiple variations... But in most cases the color space should have its own spec: typically the gamut is specified as primaries (like gfx does). The Skia version has just already gone ahead and done the "to D50" transformation. Which is a fair amount of math and can be computed in multiple ways.
,
Apr 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9962fbabc5fadbcb8e5aaead8681474f0fe761e0 commit 9962fbabc5fadbcb8e5aaead8681474f0fe761e0 Author: ccameron <ccameron@chromium.org> Date: Tue Apr 18 00:10:09 2017 color: Use named gamuts in ToSkColorSpace BUG= 712266 Review-Url: https://codereview.chromium.org/2826513002 Cr-Commit-Position: refs/heads/master@{#465071} [modify] https://crrev.com/9962fbabc5fadbcb8e5aaead8681474f0fe761e0/ui/gfx/color_space.cc [modify] https://crrev.com/9962fbabc5fadbcb8e5aaead8681474f0fe761e0/ui/gfx/color_space_unittest.cc
,
Apr 18 2017
|
||
►
Sign in to add a comment |
||
Comment 1 by zakerinasab@chromium.org
, Apr 17 2017