quicklookd[516] : CgBI: unknown critical chun

Question

Level 1

20 points

quicklookd[516] : CgBI: unknown critical chun

Does anyone have an idea why these errors are appearing in my log? And what does quicklook have to do with my Comcast connect? I just to switch to cable from dsl and I do not remember seeing these errors before.

4/14/09 6:42:51 PM com.apple.quicklook[47269] Tue Apr 14 18:42:51 c-98-203-115-95.hsd1.fl.comcast.net quicklookd[47269] <Error>: CgBI: unknown critical chun
4/14/09 6:42:51 PM com.apple.quicklook[47269] Tue Apr 14 18:42:51 c-98-203-115-95.hsd1.fl.comcast.net quicklookd[47269] <Error>: CgBI: unknown critical chun
4/14/09 8:56:53 PM com.apple.quicklook[326] Tue Apr 14 20:56:53 c-98-203-115-95.hsd1.fl.comcast.net quicklookd[326] <Error>: CgBI: unknown critical chun
4/14/09 8:56:53 PM com.apple.quicklook[326] Tue Apr 14 20:56:53 c-98-203-115-95.hsd1.fl.comcast.net quicklookd[326] <Error>: CgBI: unknown critical chun
4/14/09 9:17:58 PM com.apple.quicklook[516] Tue Apr 14 21:17:58 c-98-203-115-95.hsd1.fl.comcast.net quicklookd[516] <Error>: CgBI: unknown critical chun
4/14/09 9:17:58 PM com.apple.quicklook[516] Tue Apr 14 21:17:58 c-98-203-115-95.hsd1.fl.comcast.net quicklookd[516] <Error>: CgBI: unknown critical chun
4/14/09 6:42:51 PM com.apple.quicklook[47269] Tue Apr 14 18:42:51 c-98-203-115-95.hsd1.fl.comcast.net quicklookd[47269] <Error>: CgBI: unknown critical chun
4/14/09 6:42:51 PM com.apple.quicklook[47269] Tue Apr 14 18:42:51 c-98-203-115-95.hsd1.fl.comcast.net quicklookd[47269] <Error>: CgBI: unknown critical chun
4/14/09 8:56:53 PM com.apple.quicklook[326] Tue Apr 14 20:56:53 c-98-203-115-95.hsd1.fl.comcast.net quicklookd[326] <Error>: CgBI: unknown critical chun
4/14/09 8:56:53 PM com.apple.quicklook[326] Tue Apr 14 20:56:53 c-98-203-115-95.hsd1.fl.comcast.net quicklookd[326] <Error>: CgBI: unknown critical chun
4/14/09 9:17:58 PM com.apple.quicklook[516] Tue Apr 14 21:17:58 c-98-203-115-95.hsd1.fl.comcast.net quicklookd[516] <Error>: CgBI: unknown critical chun
4/14/09 9:17:58 PM com.apple.quicklook[516] Tue Apr 14 21:17:58 c-98-203-115-95.hsd1.fl.comcast.net quicklookd[516] <Error>: CgBI: unknown critical chun

MacBook Pro, Mac OS X (10.5.6)

Posted on Apr 14, 2009 6:27 PM

Reply

Answer 1

Apr 25, 2009 2:46 PM in response to BlackFrog

Greetings,
I found your question while also searching for an answer. While I haven't found one yet, I can at least clarify your issue. I'm debugging my own iPhone app, and this error is coming out of the PNG image-file reader. I've determined (so far) that the PNG image in question loads fine under Windows XP, and in the iPhone simulator, just not on the device. Looking at the libpng source code (freely downloadable: http://libpng.org/pub/png/libpng.html), it is clear that all chunks have four-letter names, and must always start with a lower-case letter (*). While the version of the source I'm working from doesn't support one, it -looks- like this might be an "endian" problem (successive pairs, or quads, of bytes are reversed on one type of processor as compared to another) for a chunk named "gCIB". Or it might indicate that the previous chunk in the image file was read incorrectly (though consistently so) and this is some "other data" that the reader is trying to interpret as the name of the next chunk. I'll try to remember to come back and follow up on this should I be able to solve my own problem!

(*) Technical note: The checks in the libpng code actually verify that the first character has bit 5 (of 7..0) set:
if (!(png ptr->chunkname[0] & 0x20)) {
...
png chunk_error(pngptr, "unknown critical chunk");
so any ASCII characters in the (decimal) ranges 32-63 (which includes the numeric digits) or 96-127 (which includes the lower-case letters), or even non-ascii 8-bit characters in the ranges 160-191 or 224-255, should work also. At least as far as the above test is concerned. 🙂

Reply

Answer 2

Apr 25, 2009 3:00 PM in response to BlackFrog

Well, that was fast. Next time I'll read first and post later! 🙂 Anyway, there's a great discussion of this issue at http://www.nabble.com/CgBI-error-td19563316.html, but in a nutshell:

The chunk name -is- in fact CgBI -- the 'C' indicates that the chunk is critical and cannot be ignored, the 'g' indicates that the chunk type is private and that a file containing it is not portable (and thus is a bad idea to publish as a valid PNG file), and the presence of the chunk in the file (an Apple-specific variant) indicates that the pixel data is stored as 'BGRA' rather than the usual 'RGBA' color order.

Now what is not at all clear to me, at this juncture, is (a) why on earth Apple would need or want to reverse the stored byte-order of pixels in a PNG file in the first place, and (b) why my copy of the libpng source handles a private chunk-type on Windows and on the iPhone simulator, but not on the device. Or is it that the pixel data is actually correctly ordered, and libpng is ignoring the unrecognized chunk on Windows and iPhone simulator, but not on the device?

Arrrrrgghhhh!!!

Anyway, the "solution" seems to be to load the image in an app that handles the CgBI chunk and save it back out as some other type (while preserving an alpha channel if it has one), then use some non-Apple application to convert the image back to PNG (if you need to use PNG) so that the resulting file won't have the Apple-specific chunk in it.

Good luck.

Dave

Reply

Answer 3

Apr 25, 2009 6:32 PM in response to BlackFrog

Yeesh, finally found it in another discussion thread in the Apple forums here ( http://discussions.apple.com/message.jspa?messageID=8314150) which references an external webpage full of all kinds of useful iPhone trivia (though could stand a hyperlinked table-of-contents at this point, hint hint 😉 -- http://plaidworld.com/iphonefaq.txt). Sorry for all the incoherent and often incorrect material I posted earlier.

What's going on is that the pixel ordering in PNG image-format files is converted from RGBA to BGRA, and the color values are pre-multiplied by the alpha channel value as well, by a compression utility 'pngcrush' (for device-specific efficiency reasons, when programming with the UIKit interface). The utility also (apparently) renames the required IHDR header chunk to CgBI, making the new PNG file unusable anywhere else (*). These are done AUTOMATICALLY when PNG files are deployed onto the iPhone. While this is fine for the UIKit, libpng (and other non-Apple libraries) generally can't then read the files.

This explains my earlier confusion about why the PNGs work in other situations: the original PNG is fine, it's what Xcode does to it while putting it onto the iPhone that causes the problem I have on the device.

The simple solutions are:
1) rename your PNG files, if you have control over how they're loaded later, with a different extension, such as .ppng
2) for your iPhone -device- build (double-click on the appropriate target, make sure the Configuration is selected appropriateley at the top of the 'Build' pane), add the following user-defined setting (click the 'gear' icon at the lower-left of the info window, select 'Add User-Defined Setting'):
...
User-Defined:
IPHONE OPTIMIZEOPTIONS | -skip-PNGs

At this point, I have no idea whether I've addressed the original question, but hope that anyone searching for a solution has been helped!

(*) Of course, if you have the source code, e.g. for libpng, you could code your way back out (accept CgBI in place of IHDR, divide RGB values by A, and handle the BGR ordering). Good luck, have fun, code safely!

Dave

Reply