On 10 Mar 2013, at 13:04, Markus Spoettl <ms_li...@shiftoption.com> wrote:
> On 3/10/13 1:09 PM, Mike Abdullah wrote: >>> NSData *tiff = [image TIFFRepresentation]; >>> NSBitmapImageRep *bmprep = [NSBitmapImageRep imageRepWithData:tiff]; >>> NSDictionary *props = [NSDictionary dictionaryWithObjectsAndKeys:[NSNumber >>> numberWithBool:NO], NSImageInterlaced, nil]; >>> NSData *pngData = [bmprep representationUsingType:NSPNGFileType >>> properties:props]; >> >> This is a massively wasteful approach. Likely the best compromise for your >> needs is to grab a CGImage from the NSImage, and then generate the PNG from >> that (either using NSBitmapImageRep or CGImageDestination). This takes care >> of only creating a fresh CGImage instance if actually needed. > > OK, I'll look into that, thanks. Since performance is not really a concern > and if the implementation doesn't have any other weak spots that could cause > legitimate trouble, it's a bit academic, though. > > The point of the original question was to find out if -TIFFRepresentation is > "allowed" to crash on special images and if there was a way to predict such a > crash or avoid it. I think what you're seeing is that any method in the frameworks is allowed to fail weirdly should you ask of it something that exceeds the available memory. >From the original exception, I wonder if your user has brought in an image >that is a massive black and white scan. Many, many pixels, but each is only >either black or white, so the overall memory usage is reasonable. Converting >to a TIFF might attempt to use more data per pixel, ballooning the file size. _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
