[Feature Request] Explicit color management

Description

Right now ImagePipeline allows to specify whether to transform to srgb and there are some APIs that use this bit. A more future-proof approach would be explicitly passing a target color space.

Before API level 26, Android only recognized all images as sRGB, right now it looks like old APIs just simply pass a false to its new variants to not decode to sRGB, which means the encoded color space of the images would likely be the target color space, applications that use the new version of Fresco and run on new OS might end up not getting what they want if they don’t do color management, maybe consider only decode images to sRGB color space for old APIs?

Solution

Just some thoughts:

1. Consider updating ImageDecodeOptions to have a ColorSpace, and use it instead of transformToSRGB;

2. Update current APIs that accepts transformToSRGB to accept a ColorSpace instead;

3. Update old APIs (introduced before API level 26) that don’t accept transformToSRGB to explicit decode images to sRGB.

[lpy]

Upload a pull request, please take a review 😃 If the direction looks good, I can proceed to sign the CLA, thanks!

[lambdapioneer]

@Lpy thanks a lot for doing this! There are two places where we decode without proper colour management, but these places are phasing out slowly:

• The static-webp backport. This uses libwebp directly on platforms that don’t have built-in webp support. This number is pretty low nowadays.
• The native image resizer uses libjpeg-turbos jpegtran to resize JPEG images. Afaik, it will drop color information. This is also going away mid-term as we want to reduce the amount of native libraries that are coming with Fresco.

@oprisnik for input regarding the animation backends