Let's do this because:
(1) We can.
(2) Android and Chrome have asked for it.
(3) It will simplify the implementation of SkImage::makeColorSpace().
Bug: skia:
Change-Id: Ia3c322b8a58c79ad67cdebe744e0623bd59dcffd
Reviewed-on: https://skia-review.googlesource.com/15148
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
This now demonstrates that readPixels does not do color sapce conversion
in Ganesh (and fails completely for unpremul F16). Next: fix those issues.
BUG=skia:5853
Change-Id: If3bd1882249ae85b4738ef72e16cfb87b06b9363
Reviewed-on: https://skia-review.googlesource.com/9904
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
We don't support unpremultiplied images. Therefore:
- Don't test unpremul source images.
- After doing an unpremultiplying read, make sure to premul before drawing
For this to work with F16, add support for F16 sources to
SkColorSpaceXform.
Public API change is comments-only.
TBR=reed@google.com
BUG=skia:
Change-Id: Ie05b58231e99ca88cd7792b65ffbb4f390b01726
Reviewed-on: https://skia-review.googlesource.com/9900
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Enforce that picture backed images created by the public API
must have a non-null SkColorSpace.
SkPictureShader uses a private call to get around this restriction.
BUG=skia:
Change-Id: I2fc11a8ffe583035d09e83abf40b827fbf575321
Reviewed-on: https://skia-review.googlesource.com/8415
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
BUG=skia:
Change-Id: I01c5e1874c9a034febc64e25b3aaafb5050393a6
Reviewed-on: https://skia-review.googlesource.com/8021
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>
Good news:
Everything seems to work as it is supposed to. That's why this
CL is just tests.
Bad news:
Picture is a bit strange in that the caching behavior may affect
how the output looks. Ex: If we choose to cache, we will first
draw into the picture's colorSpace and then convert that to the
dstColorSpace. If we choose not to cache, we will draw directly
into the dstColorSpace.
And then untagged pictures seem like they really shouldn't work
very well... We are caching a legacy draw and then drawing that
into the dstColorSpace? Maybe this isn't the most critical
thing to think about right now though, given Florin's work.
Remaining TODOs:
Color space support for gpu-backed images.
I still plan to clarify conversions that are allowed vs. not
allowed and share that code between all SkImages.
BUG=skia:6021
Change-Id: I9557ca1c00ff6854848fe59c3a67abd2af91bb46
Reviewed-on: https://skia-review.googlesource.com/6853
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Matt Sarett <msarett@google.com>
Correct handling of kGray, k565, k4444 etc. is still a TODO.
SkImage_Generator and SkImage_Gpu are still TODOs.
BUG=skia:6021
Change-Id: Ib53d97d3a866b2b4934fd85c10100855743a8fab
Reviewed-on: https://skia-review.googlesource.com/6396
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Mike Reed <reed@google.com>
