Re: exporting image files to disk using CGImageDestination
Re: exporting image files to disk using CGImageDestination
- Subject: Re: exporting image files to disk using CGImageDestination
- From: Bill Dudney <email@hidden>
- Date: Mon, 24 Feb 2014 10:04:22 -0800
On Feb 24, 2014, at 9:48 AM, Kevin Meaney <email@hidden> wrote:
> On 24 Feb 2014, at 17:21, Mike Abdullah <email@hidden> wrote:
>
>> On 24 Feb 2014, at 17:00, Kevin Meaney <email@hidden> wrote:
>>> I've written a command line tool that takes an image file (when testing I'm using JPEG files) and applies a custom CIFilter (a naive chroma key filter I've written) and saves a file to disk. Sampling the command line tool when processing files shows it is spending 90% of its time writing the png file of which most of this time is spent in a function called deflate in libz. The final file quality is good. I'm using CGImageDestination to export the file with default settings.
>> I’m a little unclear here. Are you saying the process appears to much slower than you can reasonably expect? Or simply that you’d like to find a way to make it go faster? (something which may well not be very possible)
>>
>
> I'd like one of two things, either getting the same quality exporting as TIFF as I do with PNG since exporting as tiff is more than 5 times faster, or that saving as PNG is faster. I suppose I don't understand when TIFF saving as uncompressed is meant to be lossless why is the image quality so much worse than saving as PNG.
>
> The ImageIO documentation relating to the dictionary properties when setting values to the CGImageDestination object, or when adding an image to the destination object are not really clear as to where to set which is appropriate. Secondly the description of the keys for the dictionary are not particularly helpful. Trying to work out what settings my work to achieve my goal is confusing and perhaps it is impossible. Both the speed difference between TIFF and PNG, and the quality difference surprised me.
>
Make sure that what you are looking at is what you think you are looking at. When you look at it in Preview is it being scaled? If so then the default scaling algorithm in Preview for TIFF might be 'fast but ugly’ (I don’t know, just guessing). With a PNG it might be choosing a ‘nice but slower’ algorithm.
My recommendation would be to ensure you are looking at the image unscaled as both PNG and TIFF. In Preview I think the menu item is ‘Show Full Size’ or something like that.
When you export as TIFF your file is basically a bit map, i.e. one 4 byte, 32bit number per pixel. If you choose TIFF compression it’s just using LZW to compress that loselessly. TIFF is really fast because nothing happens except disk IO.
With PNG the image has to be compressed. The compression is not just LZW but a complex approach to making the image smaller on disk but trying to keep as much quality as possible. All the detail you never wanted to know is here: http://www.libpng.org/pub/png/book/chapter09.html has all the info you would want to know about PNG.
If the docs are vague it would help to file a bug (http://bugreporter.apple.com) to make sure the people in charge of those docs get your input.
If you want to more fully understand the details behind what Image IO is doing, gaining an understanding TIFF vs PNG vs JPG and other image storage and compression algorithms would be helpful (but not necessary).
Hope this helps,
-bd
> Kevin
> _______________________________________________
>
> 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
_______________________________________________
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