Re: Converting CGImageRefs to NSImages, how?
Re: Converting CGImageRefs to NSImages, how?
- Subject: Re: Converting CGImageRefs to NSImages, how?
- From: Andrew Platzer <email@hidden>
- Date: Wed, 27 Apr 2005 11:53:04 -0700
On Apr 26, 2005, at 6:57 AM, Sean McBride wrote:
On 2005-04-25 13:59, Andrew Platzer said:
I'm trying to convert a CGImageRef returned from "[context
createCGImage: img fromRect: imgRect]"
to an NSImage so it can be used as the image in a drag operation
but can't find any way to do the conversion.
Simple. Draw it using CG in a lock focus view. The NSGraphicsContext
has a 'graphicsPort' that gives you the CGContextRef. (The CGRect
coercion is to make the compiler happy even though CGRect has the
same struct layout as NSRect)
NSImage* image = [[NSImage alloc] initWithSize:rect.size];
[image lockFocus];
CGContextDrawImage([[NSGraphicsContext currentContext]
graphicsPort], *(CGRect*)&rect, imageRef);
[image unlockFocus];
Looks good, but it's not exactly what I'd call 'conversion' but
more of a
'duplication'. As I understand it, the CGImage and NSImage will not
share the same pixel memory, so depending on your uses this may be
a big
problem. Actually, are the pixel values even guaranteed to be the
same or
does the process of 'drawing' (ie CGContextDrawImage()) do some colour
conversion? The docs say "Note that the appearance of the pixels
in an
image that's drawn in a Quartz context can change due to factors
such as:
[...]
-Color matching, if the image and context color spaces are
different
-Color adjustments to match the display hardware"
And the OP, Ken, did seem to be worried about extracting the name
of the
colour space.
True. It is possible to have ColorSync generate RGB values that don't
match the original.
The issue is that CGImageRef is an opaque object and the pixel data
may not be available. For example, if image is created with
CGImageCreateWithJPEGDataProvider, then there are no decompressed
pixels (though of course, the data will probably be decompressed and
cached internally.) NSBitmapImageRep may not support the format (e.g.
indexed colour space.) In fact, in accelerated drawing, the pixel
data may be uploaded to the graphics card and no longer reside in
regular RAM.
NSImage isn't always the thing to use for large images. Its
optimization for UI element images tends can make it inefficient for
large image handling. It may be better do implement a custom scheme
in that case.
Andrew Platzer
Application Frameworks
Apple Computer, Inc.
_______________________________________________
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