• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Fast direct pixel access
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fast direct pixel access


  • Subject: Re: Fast direct pixel access
  • From: Ricky Sharp <email@hidden>
  • Date: Thu, 21 Oct 2004 20:54:00 -0500

On Oct 21, 2004, at 8:12 PM, John C. Randolph wrote:

On Oct 21, 2004, at 4:37 PM, Ricky Sharp wrote:

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.

Thanks for pointing out this example. I had downloaded it a while back, but forgot that it directly accessed pixels. I agree with your structure approach too. Sometimes it can lead to optimizations if you have say the R, G and B values packed into a UInt32.

Incidentally, I need to update the Image Difference sample for Tiger, because I made the same mistake of not allowing for padding.

When I get my code working, I can also post a link to an example. Something I'll most likely add to my code is the ability to apply the effect to planar images as well.

Thanks again,

___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com

_______________________________________________
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
References: 
 >Re: CGShading (From: "John C. Randolph" <email@hidden>)
 >Re: CGShading (From: "John C. Randolph" <email@hidden>)
 >Fast direct pixel access (From: Ricky Sharp <email@hidden>)
 >Re: Fast direct pixel access (From: "John C. Randolph" <email@hidden>)

  • Prev by Date: Re: Bug in NSArrayController? (immutable instead of mutable dictionaries)
  • Next by Date: Re: confused about framework headers
  • Previous by thread: Re: Fast direct pixel access
  • Next by thread: Re: CGShading
  • Index(es):
    • Date
    • Thread