Reputation: 365
I'm trying to decode a bitmap from an InputStream
using BitmapFactory.decodeStream
, and I want to receive the bitmap in ARGB_8888
, so I used BitmapFactory.Options.inPreferredConfig = ARGB_8888
but some of my users somehow manage to load a bitmap in a different configuration (RGBA_F16
), which makes sense giving the fact that the name of the field is Preferred, But why is that? In what cases Android can't load a bitmap in the inPreferredConfig
? the source code is not very clear about that. my solution will be to convert the bitmap to ARGB_8888
using Bitmap.copy
, or Canvas.drawBitmap
, but before that, I want to understand why it happened.
Thanks.
Upvotes: 2
Views: 290
Reputation: 75
The documentation of BitmapFactory.Options
describes the role of inPreferredConfig
like this: If this is non-null, the decoder will try to decode into this color space. Although you specify Bitmap.Config.ARGB_8888, it will eventually be adjusted according to the image file itself.
The following code illustrates how the color space of the image is determined:
SkColorType SkAndroidCodec::computeOutputColorType(SkColorType requestedColorType) {
bool highPrecision = fCodec->getEncodedInfo().bitsPerComponent() > 8;
switch (requestedColorType) {
case kARGB_4444_SkColorType:
return kN32_SkColorType;
case kN32_SkColorType:
break;
case kAlpha_8_SkColorType:
// Fall through to kGray_8. Before kGray_8_SkColorType existed,
// we allowed clients to request kAlpha_8 when they wanted a
// grayscale decode.
case kGray_8_SkColorType:
if (kGray_8_SkColorType == this->getInfo().colorType()) {
return kGray_8_SkColorType;
}
break;
case kRGB_565_SkColorType:
if (kOpaque_SkAlphaType == this->getInfo().alphaType()) {
return kRGB_565_SkColorType;
}
break;
case kRGBA_F16_SkColorType:
return kRGBA_F16_SkColorType;
default:
break;
}
// F16 is the Android default for high precision images.
return highPrecision ? kRGBA_F16_SkColorType : kN32_SkColorType;
}
Upvotes: 1