Allow decoding JPEG into A8.

Allow decoding JPEG into A8.

If the original image is grayscale, allow decoding into A8.

Change the size of PrefConfigTable to allow for 8bit gray, a new source config.

Add a new sampler to SkScaledBitmapSampler to 'convert' to A8.

FIXME: Should there be a dithered option for gray scale?

R=reed@google.com

Committed: https://code.google.com/p/skia/source/detail?r=10157

[reed1, 2013-07-08 12:41:19]

JPEG is always fully opaque, yes? If so, won't the output A8 *always* be 0xFF in
every pixel?

[scroggo, 2013-07-09 01:25:24]

On 2013/07/08 12:41:19, reed1 wrote:
> JPEG is always fully opaque, yes? If so, won't the output A8 *always* be 0xFF
in
> every pixel?

It is possible for a JPEG image to be grayscale. We don't have a grayscale
config on SkBitmap, so we convert a grayscale image to ARGB. The request in
https://b.corp.google.com/issue?id=9189955 seems to be to interpret the
grayscale as alpha values. Is that not a reasonable use of the image decoder? We
could push back and say they need to do the conversion themselves, although it
seems a shame to do an extra, unnecessary conversion. Maybe there should be an
extra flag for InterpretGrayScaleAsAlpha8?

[reed1, 2013-07-09 13:45:58]

Ah, so this is (another) decoder-only feature? They are not asking for Skia to
support GrayScale?

[reed1, 2013-07-09 13:53:26]

On 2013/07/09 13:45:58, reed1 wrote:
> Ah, so this is (another) decoder-only feature? They are not asking for Skia to
> support GrayScale?

If we can make the API such that they have to explicitly request this
conversion/fakery, then I'm fine.

1. In the future, perhaps we should support gray8, and I don't want to confuse
things if/when that happens
2. Don't want other clients (direct or indirect) of ImageDecoder to suddently
get A8 when they weren't expecting it

[scroggo, 2013-07-10 21:42:35]

On 2013/07/09 13:53:26, reed1 wrote:
> Ah, so this is (another) decoder-only feature? They are not asking for Skia to
> support GrayScale?
> 
> If we can make the API such that they have to explicitly request this
> conversion/fakery, then I'm fine.

They are doing some fakery (they are passing this data to renderscript), but
there are times when they actually want an alpha mask. Either way, I think that
requesting A8 of a grayscale only makes sense if it means to interpret the
grayscale as alpha (rather than returning a bitmap with 0xFF in every pixel).

(As a sidenote, here's a fun workaround someone came up with for this use case:
http://stackoverflow.com/questions/5106122/how-to-convert-grayscale-bitmap-in...)

The latest patch updates the comments to explain what is going on for A8.

I looked into providing an extra setting for interpretGrayscaleAsA8, but it ends
up being much messier. We have to do more special casing, and we have both a
setting which only makes sense for one config preference and a config preference
that only does anything with one special setting.
 
> 
> 1. In the future, perhaps we should support gray8, and I don't want to confuse
> things if/when that happens

I don't think this will be confusing. If the caller requests gray8 (if and when
we add it), the data may look the same as alpha8, but Skia would treat it
differently.

> 2. Don't want other clients (direct or indirect) of ImageDecoder to suddently
> get A8 when they weren't expecting it

In the latest patch, A8 will only be provided when requested. I made the
PrefConfigTable more explicit, and it supports supplying the old style table for
backwards compatibility.

New patch up for review.

[reed1, 2013-07-11 15:34:59]

I don't really grok the naming convention in the new PrefConfig struct, but this
does a good job of making any hoaky gray->A8 conversion very clear. lgtm

[scroggo, 2013-07-11 20:37:29]

New patch with names in PrefConfigTable that are clearer.

https://codereview.chromium.org/18083026/diff/7001/include/core/SkImageDecoder.h
File include/core/SkImageDecoder.h (right):

https://codereview.chromium.org/18083026/diff/7001/include/core/SkImageDecode...
include/core/SkImageDecoder.h:482: k16Bit_SrcDepth,
Removed this, since it was never used.

https://codereview.chromium.org/18083026/diff/5629499534213120/include/core/S...
File include/core/SkImageDecoder.h (right):

https://codereview.chromium.org/18083026/diff/5629499534213120/include/core/S...
include/core/SkImageDecoder.h:193: SkBitmap::Config fPrefFor_8Index_NoAlpha_src;
New names. Uglier, but also more clear what they stand for.

https://codereview.chromium.org/18083026/diff/5629499534213120/include/core/S...
include/core/SkImageDecoder.h:197: SkBitmap::Config fPrefFor_8bpc_YesAlpha_src;
The 32/24 duality was because we used the same SrcDepth enum for 24 bit (8 bits
per component RGB) and 32 bit (8 bits per component ARGB). We could split that
up in SrcDepth, but then we have a redundant hasAlpha.

https://codereview.chromium.org/18083026/diff/5629499534213120/tests/ImageDec...
File tests/ImageDecodingTest.cpp (right):

https://codereview.chromium.org/18083026/diff/5629499534213120/tests/ImageDec...
tests/ImageDecodingTest.cpp:139: void testPrefConfigTable(skiatest::Reporter*
reporter) {
New test confirms that using the old API still behaves the same.

[reed1, 2013-07-11 20:42:04]

lgtm

[scroggo, 2013-07-18 19:34:54]

Committed patchset #3 manually as r10157 (presubmit successful).