Revert "treat SkPMColor as sRGB in SkPM4f::FromPMColor()"

This reverts commit a4f3e14d896708376aa50b2a8804796e6e1ee644.

Reason for revert: affecting 565 in ways I didn't expect

Original change's description:
> treat SkPMColor as sRGB in SkPM4f::FromPMColor()
> 
> We made the wrong call in SkPM4f::FromPMColor().  SkPM4f::FromPMColor()
> is only used by the color correct drawing pipeline, not legacy.  That
> means it makes a lot more sense to treat SkPMColors as premul sRGB than
> premul linear.
> 
> You can see the effect very clearly in any code path using the fallback
> SkShader::Context::shadeSpan4f().  We shade legacy 8888, then
> "linearize" to float by calling SkPM4f::FromPMColor().  At head we're
> not really linearizing, which means everything ends up too bright in the
> end.  Things get double sRGB-encoded, etc.
> 
> It is expected that this CL will make many color correct images look
> darker and a lot more like legacy mode.  It may be jarring... we've
> gotten used to seeing this bug and thinking brighter == fixed.
> 
> The only GM that changes in actual legacy 8888 is gamut, which
> explicitly creates non-legacy 8888 images... the diff there is expected.
> 
> Change-Id: I77ac6cfe8f7ffb15e90f4aad798dbe8f9d3aafbd
> Reviewed-on: https://skia-review.googlesource.com/15227
> Commit-Queue: Mike Klein <mtklein@chromium.org>
> Reviewed-by: Herb Derby <herb@google.com>
> Reviewed-by: Mike Reed <reed@google.com>
> 

TBR=mtklein@chromium.org,herb@google.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Change-Id: I80d852cbb618e94744f786bc82a4648128e99c71
Reviewed-on: https://skia-review.googlesource.com/15300
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>

0 files changed, 0 insertions, 0 deletions