On 7 Jan 2009, at 15:24, Graham Cox wrote:
However if you need to flip each pixel's byte order you might not
have much choice but to iterate over the buffer and do it by hand.
It's still going to be much simpler than creating a data provider,
etc. You've already got the data, all that other stuff looks like
overkill.
To further support this theory, take a look at this NSImage where I
mistakenly only flipped half of my data - the garbled half of the
image is from data with the wrong endian-ness:
http://www.flickr.com/photos/ikenndac/2492125512/
Here's the (working) code. In my instance I know the data is Little-
Endian RGB565, so I use EndianS16_LtoN. For Big-Endian 32-bit *RGB
you'd probably use EndianS32_BtoN. Although, I'm not sure if I'm using
the "correct" methods, since the values represent colours rather than
signed integers.
unsigned short *src = incomingData; // Array of data
int i =0;
int end = (width*height) * 2; // * 2 as there's 2 bytes per pixel
for (i = 0; i < end; i += 2) {
// This little loop converts the bits to big endian for PPC systems
*src = EndianS16_LtoN(*src);
src++;
}
After this, I convert the data to ARGB8888 using
vImageConvert_RGB565toARGB8888 and wrap it in an NSBitmapImageRep with
initWithBitmapDataPlanes:pixelsWide: (etc). No further processing is
needed after that.
Hope this helps,
-- Daniel
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
