AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Disable dithering in libjpeg-turbo for 565 decodes

Browse Source 
libjpeg-turbo turns on dithering by default.  When we
decode to RGBA, it uses Floyd-Steinberg dithering -
consistent with the libjpeg6b gold standard,

When we decode to 565, it uses ordered dithering.  Ordered
dithering for 565 is not part of the 6b standard (libjpeg6b
doesn't even support 565) and is causing us a number of
issues:
(1) Ordered dithering + nearest neighbor sampling is
causing checkerboard visual artifacts in some outputs.
(2) The ordered dither function in libjpeg-turbo actually
behaves differently depending on the alignment of the
memory that it decodes into.  This means that two image
decodes that should be identical may look different just
because they decode into different memory blocks.  This
was causing some diffs on Gold with the scanline_subset
test that were causing me some confusion.
(3) Maybe not the best evidence, but visually I can't tell
a difference with and without dithering (except when
nearest neighbor scaling causes the checkerboard artifact).
(4) Turning off dithering should be a more significant
performance improvement than you might expect.
libjpeg-turbo has SIMD color conversions to 565, but when
dithering is on, it defaults to scalar code.

This CL should make every jpeg decode to 565 on Gold look
slightly different.  Yay!

BUG=skia:

Review URL: https://codereview.chromium.org/1349563007
This commit is contained in:
msarett 2015-09-18 12:06:04 -07:00 committed by Commit bot
parent 496d29f6b2
commit 8ff6ca6e73
2 changed files with 16 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/codec/SkJpegCodec.cpp
View File

@ -246,8 +246,12 @@ bool SkJpegCodec::setOutputColorSpace(const SkImageInfo& dst) {
return true;
case kRGB_565_SkColorType:
if (isCMYK) {
// FIXME (msarett): We need to support 565 here. It's not hard to do, considering
// we already convert CMYK to RGBA, I just need to do it. I think it might be
// best to do this in SkSwizzler and also move convert_CMYK_to_RGBA into SkSwizzler.
return false;
} else {
fDecoderMgr->dinfo()->dither_mode = JDITHER_NONE;
fDecoderMgr->dinfo()->out_color_space = JCS_RGB565;
}
return true;

21
tests/CodexTest.cpp
View File

@ -99,14 +99,6 @@ static void check(skiatest::Reporter* r,
SkImageInfo info = codec->getInfo().makeColorType(kN32_SkColorType);
REPORTER_ASSERT(r, info.dimensions() == size);
{
// Test decoding to 565
SkImageInfo info565 = info.makeColorType(kRGB_565_SkColorType);
SkCodec::Result expected = (supports565 && info.alphaType() == kOpaque_SkAlphaType) ?
SkCodec::kSuccess : SkCodec::kInvalidConversion;
test_info(r, codec, info565, expected, nullptr);
}
SkBitmap bm;
bm.allocPixels(info);
SkAutoLockPixels autoLockPixels(bm);
@ -117,7 +109,18 @@ static void check(skiatest::Reporter* r,
SkMD5::Digest digest;
md5(bm, &digest);
// verify that re-decoding gives the same result.
{
// Test decoding to 565
SkImageInfo info565 = info.makeColorType(kRGB_565_SkColorType);
SkCodec::Result expected = (supports565 && info.alphaType() == kOpaque_SkAlphaType) ?
SkCodec::kSuccess : SkCodec::kInvalidConversion;
test_info(r, codec, info565, expected, nullptr);
}
// Verify that re-decoding gives the same result. It is interesting to check this after
// a decode to 565, since choosing to decode to 565 may result in some of the decode
// options being modified. These options should return to their defaults on another
// decode to kN32, so the new digest should match the old digest.
test_info(r, codec, info, SkCodec::kSuccess, &digest);
{