On 9 Jan 2009, at 12:53 am, Eric Gorr wrote:
Interesting. It looks like the function has a pixelFormatType
parameter, so there is no need to place it in the attributes
dictionary. While it does look like I could get a CVPixelBufferRef,
what is unclear is how I could get a NSImage from the
vImage_Buffer struct has a field for row bytes as well as image
dimensions.
On Jan 8, 2009, at 6:54 AM, Eric Gorr wrote:
Looks nearly perfect ... unfortunately, it does not look like it
will take the rowBytes of the GWorldPtr data into account. But, it
may still be faster to create a flat
On Jan 8, 2009, at 6:57 AM, Michael Vannorsdel wrote:
Have a look at vImagePermuteChannels_ARGB in the Accelerate
framework. Should be the fastest and easiest option for reordering
color components in pixel streams.
Looks nearly perfect ... unfortunately, it does not look like it will
On Jan 7, 2009, at 7:39 PM, Graham Cox wrote:
On 8 Jan 2009, at 10:27 am, Eric Gorr wrote:
On Jan 7, 2009, at 11:31 AM, Daniel Kennett wrote:
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 f
Have a look at vImagePermuteChannels_ARGB in the Accelerate
framework. Should be the fastest and easiest option for reordering
color components in pixel streams.
On Jan 7, 2009, at 4:27 PM, Eric Gorr wrote:
Well, I wrote the code to change the pixel format from BGRA to ARGB.
Running
On 8 Jan 2009, at 10:27 am, Eric Gorr wrote:
On Jan 7, 2009, at 11:31 AM, Daniel Kennett wrote:
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:
Well, I wr
On Jan 7, 2009, at 11:31 AM, Daniel Kennett wrote:
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:
Well, I wrote the code to change the pixel format from BGR
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 othe
On Jan 7, 2009, at 10:24 AM, 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
On 8 Jan 2009, at 1:56 am, Eric Gorr wrote:
So, it is likely a problem that the pixelFormat (according to the
debugger) for the GWorldPtr is BGRA...?
The reason it looks like this is likely because of non-native byte
ordering. You need to deal with that.
NSBitmapImageRep *bitmap_rep
On Jan 6, 2009, at 6:42 PM, Graham Cox wrote:
When I tried to setup a NSBitmapImageRep, I tried
NSDeviceRGBColorSpace for the colorSpaceName which I believe
expects the pixelFormat for the GWorldPtr to be either RGBA or ARGB.
It should be straightforward to wrap an NSBitmapImageRep around
On Jan 6, 2009, at 5:42 PM, Graham Cox wrote:
It should be straightforward to wrap an NSBitmapImageRep around some
of the GWorld formats. Not all of them are supported but ARGB 32-bit
is. While GWorlds do not have an alpha channel QuickDraw does
preserve the bits in the unused byte, but
On 7 Jan 2009, at 10:03 am, Eric Gorr wrote:
I have something that comes close, but the problem I believe is that
the pixelFormat for the GWorldPtr is BGRA.
Why do you believe that? My recollection* is that a 32-bit RGB GWorld
uses URGB (where U means 'unused' - GWorlds do not have an alph
13 matches
Mail list logo
