Drawing pictures in Quickdraw

[Fenris]

It has been a while since I last touched QuickDraw, so please bear with me... :)

I'm currently building out the GUI for a gamepad setup dialog. I want to represent the different directions on the direction pad with a custom Carbon control, which works fine. The thing is, I tired of color-coding the different directions and using FillRect. :bored: So, I want to use QD to draw a nice little mock-up gamepad. The nicest thing would be to draw alpha-channeled arrows. So, my question is basically, which is the preferred way to draw an image in a QD view? How do I get an image file into my app without reverting to pre-Carbon PICT resources (which don't support 4-channel pics, right?)

In short I need to load five images from somewhere (preferrably the Resources directory in the bundle) and copy them onto the control.

By the way, this is only for Mac OS X so there's no need to respect pre-X. :sneaky:

[FCCovett]

The source code from this thread shows how to load images (jpg, png, tga, pict) from a bundle (instead of using resources files with PICT images in them). Also, it shows how to set up a Quickdraw and/or a Quartz context. It's really a nice way to load .png pics with alpha channels and put them on the screen. Check it out.

http://www.idevgames.com/forum/showthread.php?t=5236

[Fenris]

First off, thanks FC! You spared me tons of hours! (What an odd thing to say, btw...)
Just a nitpicker, though... When the PNG is shown in the window, it appears darker/more saturated than it does on file. Have you experienced this?

Comparison Carbon Window vs Photoshop
http://www.rusted.se/pngdiff.jpg
(Yes, I know it's upside down in the window)

[OneSadCookie]

Looks like a premultiplied alpha issue...

when a pixel in a semitransparent image (color components Ir, Ig, Ib, Ia) is blended onto a background (color components Br, Bg, Bb), the standard blending equation from OpenGL is used to determine the resulting color (components Rr, Rg, Rb):

Rr = Ir * Ia + (1 - Ia) * Br (similarly for green and blue channels).

Notice that Ir only occurs once in the equation, where it's multiplied by Ia -- another property of the source image.

This means that you can store the image with the alpha "premultiplied", that is each pixel in the source image has components Ir * Ia, Ig * Ia, Ib * Ia, Ia. Now you can avoid doing that multiplication during blending -- it's effectively cached in the image.

The problem is this -- different programs expect and produce premultiplied or nonpremultiplied images, yet there's no way to tell just from the pixel data of the image whether it's premultiplied or not.

If a program that is expecting a nonpremultiplied image receives a premultiplied one, it'll mess up the blending equation, effectively giving this:

Rr = Ir * Ia * Ia + (1 - Ia) * Br

which is overly transparent.

Likewise, if a program that is expecting a premultiplied image receives a nonpremultiplied one, it'll effectively use this equation:

Rr = Ir + (1 - Ia) * Br

which is overly opaque.

Premultiplied images are useful when dealing with OpenGL, since they don't leave halos when filtered and blended, which nonpremultiplied images do unless the colors of the transparent parts match the colors of the surrounding opaque parts.

Photoshop expects and produces nonpremultiplied images.

*whew*

[arekkusu]

There is also a bug in AppKit (RADAR #3366529) which causes loaded PNG pixel data to be slightly darker than the data on disk, regardless of alpha (it happens with 8 bit indexed PNGs with no transparency, for example.)

This bug only darkens the image very slightly though, not as much as you're seeing. Not really an issue for loading data for games (but just try writing an image editor and using PNG to round trip...)

Yes, the bug is still there in 10.3.2.


Also, be aware of Photoshop's color correction. Your app might be showing you the actual pixels, while Photoshop is showing you the pixels modified for whatever color profile it thinks you want to use. Cross check with another app.

[FCCovett]

Do deal with that PNG gamma problem, I've been saving my files as TIFF or another format, and then I convert then to PNG with the Preview.app, or GoldBerg, or ToyViewer. Voila.

[update] PNG files record information about your screen gamma, so it can display the images with gamma compensation across different platforms. When you save a PNG from an application running on Classic, the gamma is set to 3.0 or it's not recorded properly. To circumvent this, open the file with some other application on OS X and export your PNG.

[Fenris]

Premultiplied images are useful when dealing with OpenGL, since they don't leave halos when filtered and blended, which nonpremultiplied images do unless the colors of the transparent parts match the colors of the surrounding opaque parts.


First off, thanks to Keith for explaining the premultiplied alpha. Didn't know that about GL and premults, thanks for that too.

Arekkusu; the image isn't really darker, but rather more saturated. Thanks for pointing out the pitfall anyway.


FCCovett, interesting technique! I'll try it as soon as I get back to work.