New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
/*
|
|
|
|
* Copyright 2016 Google Inc.
|
|
|
|
*
|
|
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
|
|
* found in the LICENSE file.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "gm.h"
|
2017-03-22 17:47:51 +00:00
|
|
|
#include "sk_tool_utils.h"
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
|
2016-10-13 17:45:44 +00:00
|
|
|
#include "SkColorSpace_Base.h"
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
#include "SkGradientShader.h"
|
2017-01-17 21:10:07 +00:00
|
|
|
#include "SkImagePriv.h"
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
#include "SkPM4fPriv.h"
|
2016-10-13 17:45:44 +00:00
|
|
|
#include "SkSurface.h"
|
2017-04-03 15:11:09 +00:00
|
|
|
#include "SkVertices.h"
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
|
|
|
|
static const int gRectSize = 50;
|
|
|
|
static const SkScalar gScalarSize = SkIntToScalar(gRectSize);
|
|
|
|
static const int gTestWidth = 700;
|
|
|
|
static const int gTestHeight = 300;
|
|
|
|
|
|
|
|
struct CellRenderer {
|
|
|
|
virtual void draw(SkCanvas* canvas) = 0;
|
|
|
|
virtual const char* label() = 0;
|
|
|
|
virtual ~CellRenderer() {}
|
|
|
|
};
|
|
|
|
|
|
|
|
struct PaintColorCellRenderer : public CellRenderer {
|
|
|
|
PaintColorCellRenderer(SkColor color) : fColor(color) {}
|
|
|
|
void draw(SkCanvas* canvas) override {
|
|
|
|
canvas->drawColor(fColor);
|
|
|
|
}
|
|
|
|
const char* label() override {
|
|
|
|
return "Paint Color";
|
|
|
|
}
|
|
|
|
protected:
|
|
|
|
SkColor fColor;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct BitmapCellRenderer : public CellRenderer {
|
|
|
|
BitmapCellRenderer(SkColor color, SkFilterQuality quality, float scale = 1.0f)
|
|
|
|
: fQuality(quality) {
|
|
|
|
int scaledSize = SkFloatToIntRound(scale * gRectSize);
|
|
|
|
fBitmap.allocPixels(SkImageInfo::MakeS32(scaledSize, scaledSize, kPremul_SkAlphaType));
|
|
|
|
fBitmap.eraseColor(color);
|
|
|
|
const char* qualityNames[] = { "None", "Low", "Medium", "High" };
|
|
|
|
fLabel = SkStringPrintf("Bitmap (%s)", qualityNames[quality]);
|
|
|
|
}
|
|
|
|
void draw(SkCanvas* canvas) override {
|
|
|
|
SkPaint paint;
|
|
|
|
paint.setFilterQuality(fQuality);
|
|
|
|
canvas->drawBitmapRect(fBitmap, SkRect::MakeIWH(gRectSize, gRectSize), &paint);
|
|
|
|
}
|
|
|
|
const char* label() override {
|
|
|
|
return fLabel.c_str();
|
|
|
|
}
|
|
|
|
protected:
|
|
|
|
SkFilterQuality fQuality;
|
|
|
|
SkBitmap fBitmap;
|
|
|
|
SkString fLabel;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct GradientCellRenderer : public CellRenderer {
|
2016-09-22 19:31:58 +00:00
|
|
|
GradientCellRenderer(SkColor colorOne, SkColor colorTwo, bool manyStops) {
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
fColors[0] = colorOne;
|
|
|
|
fColors[1] = colorTwo;
|
2016-09-22 19:31:58 +00:00
|
|
|
fManyStops = manyStops;
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
}
|
|
|
|
void draw(SkCanvas* canvas) override {
|
|
|
|
SkPoint points[2] = {
|
|
|
|
SkPoint::Make(0, 0),
|
|
|
|
SkPoint::Make(0, gScalarSize)
|
|
|
|
};
|
|
|
|
SkPaint paint;
|
2016-09-22 19:31:58 +00:00
|
|
|
if (fManyStops) {
|
|
|
|
SkColor colors[4] ={
|
|
|
|
fColors[0], fColors[0], fColors[1], fColors[1]
|
|
|
|
};
|
|
|
|
paint.setShader(SkGradientShader::MakeLinear(points, colors, nullptr, 4,
|
|
|
|
SkShader::kClamp_TileMode));
|
|
|
|
} else {
|
|
|
|
paint.setShader(SkGradientShader::MakeLinear(points, fColors, nullptr, 2,
|
|
|
|
SkShader::kClamp_TileMode));
|
|
|
|
}
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
canvas->drawPaint(paint);
|
|
|
|
}
|
|
|
|
const char* label() override {
|
|
|
|
return "Linear Gradient";
|
|
|
|
}
|
|
|
|
protected:
|
|
|
|
SkColor fColors[2];
|
2016-09-22 19:31:58 +00:00
|
|
|
bool fManyStops;
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct VerticesCellRenderer : public CellRenderer {
|
|
|
|
VerticesCellRenderer(SkColor colorOne, SkColor colorTwo) {
|
|
|
|
fColors[0] = fColors[1] = colorOne;
|
|
|
|
fColors[2] = fColors[3] = colorTwo;
|
|
|
|
}
|
|
|
|
void draw(SkCanvas* canvas) override {
|
|
|
|
SkPaint paint;
|
|
|
|
SkPoint vertices[4] = {
|
|
|
|
SkPoint::Make(0, 0),
|
|
|
|
SkPoint::Make(gScalarSize, 0),
|
|
|
|
SkPoint::Make(gScalarSize, gScalarSize),
|
|
|
|
SkPoint::Make(0, gScalarSize)
|
|
|
|
};
|
2017-04-03 15:11:09 +00:00
|
|
|
canvas->drawVertices(SkVertices::MakeCopy(SkVertices::kTriangleFan_VertexMode, 4, vertices,
|
|
|
|
nullptr, fColors),
|
|
|
|
SkBlendMode::kModulate, paint);
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
}
|
|
|
|
const char* label() override {
|
|
|
|
return "Vertices";
|
|
|
|
}
|
|
|
|
protected:
|
|
|
|
SkColor fColors[4];
|
|
|
|
};
|
|
|
|
|
2016-11-03 18:40:50 +00:00
|
|
|
static void draw_gamut_grid(SkCanvas* canvas, SkTArray<std::unique_ptr<CellRenderer>>& renderers) {
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
// We want our colors in our wide gamut to be obviously visibly distorted from sRGB, so we use
|
|
|
|
// Wide Gamut RGB (with sRGB gamma, for HW acceleration) as the working space for this test:
|
|
|
|
const float gWideGamutRGB_toXYZD50[]{
|
2016-09-09 17:36:17 +00:00
|
|
|
0.7161046f, 0.1009296f, 0.1471858f, // -> X
|
|
|
|
0.2581874f, 0.7249378f, 0.0168748f, // -> Y
|
|
|
|
0.0000000f, 0.0517813f, 0.7734287f, // -> Z
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
SkMatrix44 wideGamutRGB_toXYZD50(SkMatrix44::kUninitialized_Constructor);
|
|
|
|
wideGamutRGB_toXYZD50.set3x3RowMajorf(gWideGamutRGB_toXYZD50);
|
|
|
|
|
|
|
|
// Use the original canvas' color type, but account for gamma requirements
|
2016-09-30 13:14:49 +00:00
|
|
|
SkImageInfo origInfo = canvas->imageInfo();
|
2016-10-18 17:02:51 +00:00
|
|
|
sk_sp<SkColorSpace> srgbCS;
|
|
|
|
sk_sp<SkColorSpace> wideCS;
|
2016-09-30 13:14:49 +00:00
|
|
|
switch (origInfo.colorType()) {
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
case kRGBA_8888_SkColorType:
|
|
|
|
case kBGRA_8888_SkColorType:
|
2017-02-07 18:56:11 +00:00
|
|
|
srgbCS = SkColorSpace::MakeSRGB();
|
2016-10-24 13:24:02 +00:00
|
|
|
wideCS = SkColorSpace::MakeRGB(SkColorSpace::kSRGB_RenderTargetGamma,
|
2016-10-18 17:02:51 +00:00
|
|
|
wideGamutRGB_toXYZD50);
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
break;
|
|
|
|
case kRGBA_F16_SkColorType:
|
2017-02-07 18:56:11 +00:00
|
|
|
srgbCS = SkColorSpace::MakeSRGBLinear();
|
2016-10-24 13:24:02 +00:00
|
|
|
wideCS = SkColorSpace::MakeRGB(SkColorSpace::kLinear_RenderTargetGamma,
|
2016-10-18 17:02:51 +00:00
|
|
|
wideGamutRGB_toXYZD50);
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return;
|
|
|
|
}
|
2016-10-18 17:02:51 +00:00
|
|
|
SkASSERT(srgbCS);
|
|
|
|
SkASSERT(wideCS);
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
|
2017-01-17 21:10:07 +00:00
|
|
|
// Make our two working surfaces (one sRGB, one Wide)
|
2016-09-30 13:14:49 +00:00
|
|
|
SkImageInfo srgbGamutInfo = SkImageInfo::Make(gRectSize, gRectSize, origInfo.colorType(),
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
kPremul_SkAlphaType, srgbCS);
|
2016-09-30 13:14:49 +00:00
|
|
|
SkImageInfo wideGamutInfo = SkImageInfo::Make(gRectSize, gRectSize, origInfo.colorType(),
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
kPremul_SkAlphaType, wideCS);
|
2017-01-17 21:10:07 +00:00
|
|
|
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
sk_sp<SkSurface> srgbGamutSurface = canvas->makeSurface(srgbGamutInfo);
|
|
|
|
sk_sp<SkSurface> wideGamutSurface = canvas->makeSurface(wideGamutInfo);
|
2016-09-30 13:14:49 +00:00
|
|
|
if (!srgbGamutSurface || !wideGamutSurface) {
|
|
|
|
return;
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
}
|
|
|
|
SkCanvas* srgbGamutCanvas = srgbGamutSurface->getCanvas();
|
|
|
|
SkCanvas* wideGamutCanvas = wideGamutSurface->getCanvas();
|
|
|
|
|
|
|
|
SkPaint textPaint;
|
|
|
|
textPaint.setAntiAlias(true);
|
|
|
|
textPaint.setColor(SK_ColorWHITE);
|
|
|
|
sk_tool_utils::set_portable_typeface(&textPaint);
|
|
|
|
|
|
|
|
SkScalar x = 0, y = 0;
|
|
|
|
SkScalar textHeight = textPaint.getFontSpacing();
|
|
|
|
|
|
|
|
for (const auto& renderer : renderers) {
|
|
|
|
srgbGamutCanvas->clear(SK_ColorBLACK);
|
|
|
|
renderer->draw(srgbGamutCanvas);
|
|
|
|
wideGamutCanvas->clear(SK_ColorBLACK);
|
|
|
|
renderer->draw(wideGamutCanvas);
|
|
|
|
|
|
|
|
canvas->drawText(renderer->label(), strlen(renderer->label()), x, y + textHeight,
|
|
|
|
textPaint);
|
|
|
|
|
2017-01-17 21:10:07 +00:00
|
|
|
// Re-interpret the off-screen images, so we can see the raw data (eg, Wide gamut squares
|
|
|
|
// will look desaturated, relative to sRGB).
|
|
|
|
auto srgbImage = srgbGamutSurface->makeImageSnapshot();
|
|
|
|
srgbImage = SkImageMakeRasterCopyAndAssignColorSpace(srgbImage.get(),
|
|
|
|
origInfo.colorSpace());
|
|
|
|
canvas->drawImage(srgbImage, x, y + textHeight + 5);
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
x += (gScalarSize + 1);
|
|
|
|
|
2017-01-17 21:10:07 +00:00
|
|
|
auto wideImage = wideGamutSurface->makeImageSnapshot();
|
|
|
|
wideImage = SkImageMakeRasterCopyAndAssignColorSpace(wideImage.get(),
|
|
|
|
origInfo.colorSpace());
|
|
|
|
canvas->drawImage(wideImage, x, y + textHeight + 5);
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
x += (gScalarSize + 10);
|
|
|
|
|
|
|
|
if (x + (2 * gScalarSize + 1) > gTestWidth) {
|
|
|
|
x = 0;
|
|
|
|
y += (textHeight + gScalarSize + 10);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
DEF_SIMPLE_GM_BG(gamut, canvas, gTestWidth, gTestHeight, SK_ColorBLACK) {
|
2016-11-03 18:40:50 +00:00
|
|
|
SkTArray<std::unique_ptr<CellRenderer>> renderers;
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
|
|
|
|
// sRGB primaries, rendered as paint color
|
2016-11-03 18:40:50 +00:00
|
|
|
renderers.emplace_back(new PaintColorCellRenderer(SK_ColorRED));
|
|
|
|
renderers.emplace_back(new PaintColorCellRenderer(SK_ColorGREEN));
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
|
|
|
|
// sRGB primaries, rendered as bitmaps
|
2016-11-03 18:40:50 +00:00
|
|
|
renderers.emplace_back(new BitmapCellRenderer(SK_ColorRED, kNone_SkFilterQuality));
|
|
|
|
renderers.emplace_back(new BitmapCellRenderer(SK_ColorGREEN, kLow_SkFilterQuality));
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
// Larger bitmap to trigger mipmaps
|
2016-11-03 18:40:50 +00:00
|
|
|
renderers.emplace_back(new BitmapCellRenderer(SK_ColorRED, kMedium_SkFilterQuality, 2.0f));
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
// Smaller bitmap to trigger bicubic
|
2016-11-03 18:40:50 +00:00
|
|
|
renderers.emplace_back(new BitmapCellRenderer(SK_ColorGREEN, kHigh_SkFilterQuality, 0.5f));
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
|
|
|
|
// Various gradients involving sRGB primaries and white/black
|
2016-09-22 19:31:58 +00:00
|
|
|
|
|
|
|
// First with just two stops (implemented with uniforms on GPU)
|
2016-11-03 18:40:50 +00:00
|
|
|
renderers.emplace_back(new GradientCellRenderer(SK_ColorRED, SK_ColorGREEN, false));
|
|
|
|
renderers.emplace_back(new GradientCellRenderer(SK_ColorGREEN, SK_ColorBLACK, false));
|
|
|
|
renderers.emplace_back(new GradientCellRenderer(SK_ColorGREEN, SK_ColorWHITE, false));
|
2016-09-22 19:31:58 +00:00
|
|
|
|
|
|
|
// ... and then with four stops (implemented with textures on GPU)
|
2016-11-03 18:40:50 +00:00
|
|
|
renderers.emplace_back(new GradientCellRenderer(SK_ColorRED, SK_ColorGREEN, true));
|
|
|
|
renderers.emplace_back(new GradientCellRenderer(SK_ColorGREEN, SK_ColorBLACK, true));
|
|
|
|
renderers.emplace_back(new GradientCellRenderer(SK_ColorGREEN, SK_ColorWHITE, true));
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
|
|
|
|
// Vertex colors
|
2016-11-03 18:40:50 +00:00
|
|
|
renderers.emplace_back(new VerticesCellRenderer(SK_ColorRED, SK_ColorRED));
|
|
|
|
renderers.emplace_back(new VerticesCellRenderer(SK_ColorRED, SK_ColorGREEN));
|
New gamut GM, to test gamut conversion in various code-paths
After several different strategies, this one appears to work
well. The basic test:
1) For a variety of drawing techniques, we render fixed size
rectangles. (Solid colors via paint color, bitmap, etc...)
2) For each method in #1, we render to both an sRGB and
WideGamutRGB offscreen surface. (AdobeRGB isn't wide enough
to clearly demonstrate if things are working or not).
3) Use readPixels to fetch the raw (still in wide gamut) pixel
data, then draw that directly to the final canvas.
So, for each pair of squares, they should look clearly
different. Currently, with the GPU backend, only the bicubic
bitmap paths have that behavior. Adding more test cases (and
fixing the ones that are already incorrect) will be the long
tail of gamut transformation.
Current output (with my other patchset, which fixes all
bitmap draws): https://screenshot.googleplex.com/wsL3x7eCtWE.png
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2293173002
Review-Url: https://codereview.chromium.org/2293173002
2016-09-07 14:04:44 +00:00
|
|
|
|
|
|
|
draw_gamut_grid(canvas, renderers);
|
|
|
|
}
|