First: None of the Mac OS X image APIs are set up around completely bare access to pixels. Bare pixel access is at odds with performance. Take caching: In order to cache effectively, the frameworks needs to understand what's changing when, and that cannot happen when people have unmediated pixel access. It would effectively mean no caching.
That said, CoreImage _is_ set up around access to pixels, just in a more structured way. You define kernels of processing to be applied, and CoreImage handles applying them. It also composes kernel chains beforehand, applying a composite kernel to an image in one pass when possible. There are lots of predefined image filters that you can chain together to do useful things. There are certain things that you cannot do this way (a histogram, for example), but it's a nice place to start if it sounds like what you need to do. The Quartz Composer app is a nice way to play with CoreImage stuff live. You could also consider OpenCL. This is somewhat similar, but more data oriented and less image oriented, and more flexible. Both CoreImage and OpenCL can use the GPU. Last, you could work in bare memory buffers, do whatever you want to them (but with no particular help from the system), and package up a copy of your buffer as an image when you want to draw it. For this packaging, look at NSBitmapImageRep or CGImage. This is kind of a brute force approach, but it uses the fewest special concepts, and that's attractive. You should realize that the system is not prepared for the bits to mutate behind the back of the framework when doing this. CGImage is immutable. NSBitmapImageRep is implemented using CGImage. These classes are oriented around fast drawing, not modification. -Ken Cocoa Frameworks On Wed, Feb 10, 2010 at 9:11 PM, Alexander Golec < alexgolecmailingli...@gmail.com> wrote: > I am writing an application that wants to perform some basic computer > vision computation, and I want a class that offers pixel-level access to an > image. What would be the best way to approach this? > > Alex_______________________________________________ > > 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/kenferry%40gmail.com > > This email sent to kenfe...@gmail.com > _______________________________________________ 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