diff options
author | Mike Klein <mtklein@chromium.org> | 2017-05-03 17:57:48 -0400 |
---|---|---|
committer | Skia Commit-Bot <skia-commit-bot@chromium.org> | 2017-05-04 14:22:08 +0000 |
commit | db711c982bfaa805d2de5a253c55a680c30189e0 (patch) | |
tree | 33181d88864b163412f7a13c93d59b5f52756e3b /include | |
parent | 65f33fcbbadde807667a0c7ce451ad95c31c52ea (diff) |
move dither after the transfer function
There's no single dither rate that we can use in linear space if we're
using a non-linear transfer function... if it's too high (like today)
we'll dither too much around zero (e.g. 0 -> 5), and if it's too low we
won't dither near one.
We were thinking it'd be a good idea to move the dither later in the
pipeline anyway. This has to be the right spot!
Now that we're moving dither from operating in linear space to operating
in bit-space (after transfer function, aware of bit-depth of
destination) we have to start clamping [0,1] instead of [0,a]...
But, I think I've rewritten things to make sure we don't need to clamp
at all. The main idea is to make sure 0-dither and 1+dither round to 0
and 1 respectively. We can do this by making the dither span exclusive,
switching from [-0.5,+0.5] to (-0.5,+0.5). In practice I'm doing that
as [-0.4921875,+0.4921875], a maximum dither of 63/128 of a bit.
Similarly, I don't think it makes sense to fold in the multiply by alpha
anymore if we're after the transfer function.
Change-Id: I55857bca80377c639fcdd29acc9b362931dd9d12
Reviewed-on: https://skia-review.googlesource.com/15254
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions