Re: Fast direct pixel access
Re: Fast direct pixel access
- Subject: Re: Fast direct pixel access
- From: "John C. Randolph" <email@hidden>
- Date: Thu, 21 Oct 2004 18:12:38 -0700
On Oct 21, 2004, at 4:37 PM, Ricky Sharp wrote:
On Oct 12, 2004, at 1:48 PM, John C. Randolph wrote:
On Aug 1, 2004, at 9:13 AM, Ricky Sharp wrote:
Here's some sample code that creates a pretty cool gradient by
using a Category for NSImage:
<http://developer.apple.com/samplecode/Transformed_Image/
Transformed_Image.html>
When I wrote that code, CGShading wasn't available. If I were
writing that sample today, I'd use GCShading. I should also point
out that the code assumes that bytesPerRow == pixelsWide, which
isn't necessarily the case.
Correction: I meant to say it assumes that bytesPerRow ==
(pixelsWide * 4), which isn't necessarily true. In future versions
of AppKit and CoreImage, bitmaps may get padded to allow for word or
long word alignment for optimization.
I do understand what you wrote above regarding bytesPerRow. (Original
text above was in response to the "CGShading" thread).
Having said that, I have the need to take an NSImage (specifically an
NSBitmapImageRep) and do a grayscale conversion on it. In Carbon, I
used direct pixel access on my QuickDraw GWorld. As my app could run
in both 16-bit and 32-bit depths, I implemented two separate routines.
The starting address was obtained via GetPixBaseAddr. After I
processed all pixels for a row, the pointer was incremented like this:
p += ((*inPixMap)->rowBytes & 0x7FFF)
Originally, I was planning on baselining to 10.4 and thus could rely
on CoreImage. But I'm baselining to 10.3 and thus need something for
that OS.
My thought is that I can use NSBitmapImageRep's bytesPerRow method to
make the code depth-savvy.
As in your TransformedImage example, the start of the image data is:
unsigned char* imageBytes = [bitmapRep bitmapData];
And after processing bytes in that row, I can increment imageBytes by
[bitmapRep bytesPerRow]. Is this assumption correct?
Incrementing by bytesPerRow should work for you. I'd recommend that
you also look at the "Image Difference" sample, and see how I
implemented [NSBitmapImageRep negative]. Instead of just using
unsigned char *, I defined a number of pixel formats in "PixelTypes.h",
which makes for code that's somewhat easier to read.
Incidentally, I need to update the Image Difference sample for Tiger,
because I made the same mistake of not allowing for padding.
-jcr
John C. Randolph <email@hidden> (408) 974-8819
Sr. Cocoa Software Engineer,
Apple Worldwide Developer Relations
http://developer.apple.com/cocoa/index.html
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden