aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/core/SkSRGB.h
diff options
context:
space:
mode:
authorGravatar mtklein <mtklein@chromium.org>2016-07-08 06:33:16 -0700
committerGravatar Commit bot <commit-bot@chromium.org>2016-07-08 06:33:16 -0700
commitac41bac40f5a80d2bc5ccec584c23478a6900179 (patch)
tree923db53d051d849d57e82cc35c573733324a56dd /src/core/SkSRGB.h
parent0e56972e5f69f75cf098fec10687f128430c13e6 (diff)
Move sRGB <-> linear conversion components to their own files.
This makes them a little easier to use outside SkColorXform code. I've added some notes about how best to use them and their eccentricities, and added a test. Ultimately any software sRGB <-> linear conversion should funnel somehow through here. BUG=skia: GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2128893002 CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Release-Trybot;client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot Committed: https://skia.googlesource.com/skia/+/45e58c8807179638980aae8503573b950b844e4c Review-Url: https://codereview.chromium.org/2128893002
Diffstat (limited to 'src/core/SkSRGB.h')
-rw-r--r--src/core/SkSRGB.h50
1 files changed, 50 insertions, 0 deletions
diff --git a/src/core/SkSRGB.h b/src/core/SkSRGB.h
new file mode 100644
index 0000000000..de80596de4
--- /dev/null
+++ b/src/core/SkSRGB.h
@@ -0,0 +1,50 @@
+/*
+ * Copyright 2016 Google Inc.
+ *
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+#ifndef SkSRGB_DEFINED
+#define SkSRGB_DEFINED
+
+#include "SkNx.h"
+
+/** Components for building our canonical sRGB -> linear and linear -> sRGB transformations.
+ *
+ * Current best practices:
+ * - for sRGB -> linear, lookup R,G,B in sk_linear_from_srgb;
+ * - for linear -> sRGB, call sk_linear_to_srgb() for R,G,B, clamp to 255, and round;
+ * - the alpha channel is linear in both formats, needing at most *(1/255.0f) or *255.0f.
+ *
+ * sk_linear_to_srgb()'s output requires rounding; it does not round for you.
+ *
+ * Given inputs in [0,1], sk_linear_to_srgb() will not underflow 0 but may overflow 255.
+ * The overflow is small enough that you can safely either clamp then round or round then clamp.
+ * (If you don't trust the inputs are in [0,1], you'd better clamp both sides immediately.)
+ *
+ * sk_linear_to_srgb() will run a little faster than usual when compiled with SSE4.1+.
+ */
+
+extern const float sk_linear_from_srgb[256];
+
+static inline Sk4f sk_linear_to_srgb(const Sk4f& x) {
+ // Approximation of the sRGB gamma curve (within 1 when scaled to 8-bit pixels).
+ // For 0.00000f <= x < 0.00349f, 12.92 * x
+ // For 0.00349f <= x <= 1.00000f, 0.679*(x.^0.5) + 0.423*x.^(0.25) - 0.101
+ // Note that 0.00349 was selected because it is a point where both functions produce the
+ // same pixel value when rounded.
+ auto rsqrt = x.rsqrt(),
+ sqrt = rsqrt.invert(),
+ ftrt = rsqrt.rsqrt();
+
+ auto lo = (12.92f * 255.0f) * x;
+
+ auto hi = (-0.101115084998961f * 255.0f) +
+ (+0.678513029959381f * 255.0f) * sqrt +
+ (+0.422602055039580f * 255.0f) * ftrt;
+
+ return (x < 0.00349f).thenElse(lo, hi);
+}
+
+#endif//SkSRGB_DEFINED