Re: NSImage TIFFRepresentation crashes
Re: NSImage TIFFRepresentation crashes
- Subject: Re: NSImage TIFFRepresentation crashes
- From: Markus Spoettl <email@hidden>
- Date: Sun, 10 Mar 2013 13:55:37 +0100
On 3/10/13 12:50 PM, Graham Cox wrote:
On 10/03/2013, at 7:12 PM, Markus Spoettl <email@hidden
<mailto:email@hidden>> wrote:
Why does it conform to NSCoding if it's not safe to use?
I'm not sure I said it wasn't safe, just that it wasn't a good idea.
OK, that's true.
An NSImage can contain multiple representations of the same image, often in
highly expanded forms, e.g. the actual bitmaps. A 10MB JPEG can easily end up as
a 250MB NSImage - you don't want that in your archive. If you can archive the
original compressed data, that's ideal. If not, using the TIFFRepresentation is
at least a better option, unless there's a PDF representation that you could use
instead (which you have to go and look for yourself), which could well be
considerably smaller than the TIFF .
I recently ran into the fact that if you create an NSColor with a pattern image,
archiving the colour archives the NSImage. A trivial 512 x 512 pixel image
became a 41MB NSImage, archived individually for every instance of that colour,
which ran me out of memory in the 32-bit build of our app during a document save
(Greatly exacerbated by the fact that NSFileWrapper copies a chunk of immutable
data given to it instead of retaining it - there just isn't room for two
enormous blocks in memory at once). Other parts of our app go to great lengths
to a) archive the original data wherever possible and b) eliminate duplicates of
that image data by using a hash of the data to identify duplicates. The pattern
case passed us by, though now I'm aware of it I can fit it into the rest of the
app's imaging scheme.
Back to your case, since archiving NSImages can hit memory limits easily,
perhaps there's a memory issue somewhere where you (or the OS) aren't checking
that an allocation succeeded?
I can only speculate (all I have is a crash log) but I guess the image is valid
because it was displayed to the user in our app. Serializing - as we now
established - works and shouldn't cause the image to go from valid at archiving
time to broken when it is being read back in.
The crash happens when I call -TIFFRepresentation on that image, wasteful
perhaps but should not crash with any valid image (at least there is no
documentation that suggests -TIFFRepresentation will fail with specific images).
Fixing this up in an existing archive isn't difficult - decide how your archives
are going to save images from now on and use a new archive key. Then when
importing you can check which key it has and either import the old NSImage
archive, or do something a lot smarter with the new format image data. Also
adding checks at dearchiving time for bad image size will catch the case you
have a problem with - it will be better to ignore the errant image (and perhaps
notify the user) than crashing.
That's what I do (reading PNG data and constructing an image from that, when
it's available or decoding the NSImage directly if not).
Regards
Markus
--
__________________________________________
Markus Spoettl
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden