Re: precomputing alpha + color accuracy ?
Re: precomputing alpha + color accuracy ?
- Subject: Re: precomputing alpha + color accuracy ?
- From: Andrew Platzer <email@hidden>
- Date: Thu, 3 Jan 2002 13:39:27 -0800
On Sunday, December 23, 2001, at 12:43 , Raphael Sebbe wrote:
BTW, and on the content this time, it seems to me premultiplying implies
loss of color accuracy. As an example, an image with 0.5 alpha all over
will have all its color components coded on 7 bits instead of 8 (image is
29 bits), 0.25 -> 6 bits (image is 26 bits) and so on...
Yes, premultiplication is a lossy process. It sacrifices stored accuracy
for speed. For example, if alpha is 1 (with allowable values from 0 to 255)
then the only valid values for RGB are 0 and 1. If you undo this
premultiplication, you don't necessarily get back the original value.
So my next question naturally is: is there a way to generate not
premultiplied transparent images (actually, tell NSBitmapImageRep that
the samples are not premultiplied) ? It is really embarrassing not being
able to use all 32 bits in a 32 bits image, especially when you need high
quality output.
No, NSBitmapImageRep always premultiplies. If you need to work with
unpremultiplied data, you have to use Quartz, specifically CGImageCreate
with kCGImageAlphaLast.
As for high quality output, premultiplying does not affect the output.
Given source bitmap pixel s and destination pixel d, a blend is basically
d' = c * s + (1 - a) * d
All premultiplication does is precalculate c * s. What it does mean is if
you want manipulate the actual data (e.g. like Photoshop), you shouldn't
use NSBitmapImageRep for storage.
Andrew
__________________________________________________________________
A n d r e w P l a t z e r
A p p l i c a t i o n F r a m e w o r k s
A p p l e