SkColorSpaceXform supports in place color conversion.  Ex:

SkColorSpace* src, dst;
void* buffer;
int len;
SkColorSpaceXform::ColorFormat dstFormat;
SkColorSpaceXform::ColorFormat srcFormat;
std::unique_ptr<SkColorSpaceXform> xform = SkColorSpaceXform::New(src, dst);
// Size of dstFormat pixel must equal size of srcFormat pixel
xform->apply(dstFormat, buffer, srcFormat, buffer, len, kUnpremul_SkAlphaType);

This will memcpy() in the case where color spaces are equal.  Alternatively, you can use SkColorSpace::Equals(src, dst) to skip the xform altogether.

I'm guessing that there is a complication I am missing?  Dooes the client not have access to the pixels in the SkImage?

Thanks for the update. I assume that you can send the same buffer to the SkColorSpaceXform for in-place conversion only if the SkColorTypeBytesPerPixel() is the same for both color spaces, right?

The complexity here is that currently we only have a SkImage here and we cannot extract the source color space and color type from that. Is there a way to do that so we can directly use SkColorSpaceXform?

> Thanks for the update. I assume that you can send the same buffer to the
> SkColorSpaceXform for in-place conversion only if the
> SkColorTypeBytesPerPixel() is the same for both color spaces, right?

Yes, with the caveat that the xform takes a ColorFormat (not an SkColorType).

> The complexity here is that currently we only have a SkImage here and we
> cannot extract the source color space and color type from that. Is there a
> way to do that so we can directly use SkColorSpaceXform?

For some SkImages (ex: backed by SkPicture), it is a little strange to report a colorType/colorSpace.  How was the SkImage created?

The specific SkImage that I'm dealing with now comes from a call to createImageBitmap and is created by ImageDecoder. Anyway, I set this bug to won't fix as it isn't a valid bug.