Skip to content

Fix iOS pixel format label for default byte order#159

Open
mrousavy wants to merge 2 commits into
mainfrom
fix/ios-pixel-format-byte-order
Open

Fix iOS pixel format label for default byte order#159
mrousavy wants to merge 2 commits into
mainfrom
fix/ios-pixel-format-byte-order

Conversation

@mrousavy

Copy link
Copy Markdown
Owner

What

CGImage's .orderDefault byte order has big-endian semantics: components are stored in memory in exactly the order alphaInfo names them (for example premultipliedLast + orderDefault is physically [R, G, B, A], the classic RGBA context). This is a property of the Core Graphics format description, not the host CPU's endianness.

getPixelFormat treated .orderDefault as little-endian, so toRawPixelData reported reversed pixel format labels (R and B swapped) for ImageIO-decoded images such as PNG/JPEG loads. Camera-frame-style images that carry an explicit byteOrder32Little were unaffected.

Fix

Treat .orderDefault as big-endian so the reported pixelFormat matches the physical bytes. Also documents that the noneSkip padding byte is intentionally reported as alpha (Apple's decoders fill it with 0xFF).

🤖 Generated with Claude Code

CGImage's .orderDefault byte order has big-endian semantics: the
components are stored in memory in the order alphaInfo names them (for
example premultipliedLast + orderDefault is physically [R, G, B, A]).
It is a property of the Core Graphics format description, not the host
CPU's endianness.

getPixelFormat treated .orderDefault as little-endian, so toRawPixelData
reported reversed pixel format labels for ImageIO-decoded images (such as
PNG/JPEG loads). Treat .orderDefault as big-endian so the reported label
matches the physical bytes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant