Why was the addition of the kCGBitmapByteOrder32Little flag needed? Is this something that should be updated in the documentation? Is this because I'm on an Intel processor, and should I be checking the endian-ness of the running machine whether I add the flag or not? Is there anything I should be aware of moving this to iOS (i.e. a non-Intel processor)?
As a bit of historical weirdness, Quartz defaults a non-existant endian flag as big-endian rather than host endian. Under 5- and 8-bpc formats, this generates bit-wise and pixel-size ordering that is the same (i.e. ARGB reads as ARGB regardless of if you read it 8 bits or 32 bits at a time). For 16 -and 32-bpc formats however, this leads to what you've seen. I'm not certain exactly why that choice was made, but it is something to be aware of when working with larger bpc formats.
|
