How to draw an image with ARGB_8888 format in Skia?

[L2000]

Hi

          I'm working with an image that has the following pixel format:

Color type: ARGB (Alpha-Red-Green-Blue order)
Bits per component: 8
Bits per pixel: 32 (i.e., ARGB_8888)

           In Skia, the closest SkColorType I found is kARGB_4444_SkColorType, but that only supports 4 bits per component.Does Skia provide a way to render or create images with the ARGB_8888 format? If not directly supported, what is the recommended approach to handle images in ARGB_8888 format? Should I manually convert the pixel layout to a Skia-supported format like kBGRA_8888_SkColorType before rendering?

auto imageInfo = SkImageInfo::Make(imgWidth, imgHeight ,colorType, alphaType);
SkPixmap pixmap(imageInfo,imageDataBuffer.get(),imgWidth*samplesPerPixel);
auto image = SkImages::RasterFromPixmap(pixmap,nullptr,nullptr);
canvas->drawImageRect(image,imageRect,SkSamplingOptions(SkSamplingOptions(SkFilterMode::kLinear,SkMipmapMode::kLinear)));

How to draw the images that are having colortypes that are unavailable in Skia's SkColorType enum?Any guidance would be appreciated.

[Brian Salomon]

Are you sure that it isn’t really the same as kBGRA_8888_SkColorType? Some APIs specify the byte order from high to low and others low to high in writing/enum names. So BGRA in one denotation might be written as ARGB in another.

Brian

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/skia-discuss/7f27f6ca-6c8a-4405-bb27-de5499bb547bn%40googlegroups.com.

[L2000]

Yes, you're absolutely right — some APIs indicate byte order explicitly using terms like Big Endian (high to low) or Little Endian (low to high) in their naming conventions.
In my case, the image I’m trying to render uses a premultiplied alpha channel with the alpha stored first, and the data is laid out in little-endian byte order. This means that although the image's format description ( from NSImage in Mac) technically represents BGRA_8888, the image’s bitmap data in memory is actually stored in ARGB channel order.

I manually converted the bitmap data from ARGB to BGRA and set the color type as kBGRA_8888_SkColorType in Skia. After this change, the image rendered correctly — which confirms that the raw memory layout of the bitmap is indeed ARGB, despite the image’s apparent format.

let imageData = NSBitmapImageRep(cgImage: nsImage.cgImage!).bitmapData
for i in 0 ..< Int(imageWidth * imageHeight) {
let offset = i*4;
let aI = imageData[offset + 0]
let rI = imageData[offset + 1]
let gI = imageData[offset + 2]
let bI = imageData[offset + 3]

imageData[offset + 0] = bI
imageData[offset + 1] = gI
imageData[offset + 2] = rI
imageData[offset + 3] = aI
}
//skia side image rendering code
auto imageInfo = SkImageInfo::Make(imgWidth, imgHeight ,kBGRA_8888_SkColorType, kPremul_SkAlphaType);
std::shared_ptr<uint8_t> imageDataBuffer = std::any_cast<std::shared_ptr<uint8_t>>(imageDetails.at("imageData"));
SkPixmap pixmap(imageInfo,imageDataBuffer.get(),imageWidth*samplesPerPixel);
image = SkImages::RasterFromPixmap(pixmap,nullptr,nullptr);

canvas->drawImageRect(image,imageRect,SkSamplingOptions(SkSamplingOptions(SkFilterMode::kLinear,SkMipmapMode::kLinear)));

While manually converting ARGB to BGRA works, it involves iterating over each pixel and adjusting the channel layout, which is relatively time-consuming and not ideal for performance-critical rendering.
So my question is:
Is there a built-in or recommended approach in Skia for handling ARGB_8888-style images(and other formats like ABGR,RGBX,XRGB) without manually rewriting the pixel data?
A more efficient, native solution within Skia to support multiple color layouts (like ARGB, BGRA, RGBA) would significantly improve runtime performance.

[br...@pentrek.com]

Gotcha. Maybe you could write a little SKSL shader that swizzles the channels to a Skia supported order. Then you’d wrap your image in SkImage with a lie about the actual color type.

You could then do a one time conversion by drawing it into a surface or dynamically apply the swizzle every time you use that image.

On Jun 20, 2025, at 5:02 AM, L2000 <priyapus...@gmail.com> wrote:

Yes, you're absolutely right — some APIs indicate byte order explicitly using terms like Big Endian (high to low) or Little Endian (low to high) in their naming conventions.

To view this discussion visit https://groups.google.com/d/msgid/skia-discuss/69be432d-bc16-4b10-95f5-845448c429f1n%40googlegroups.com.