[cairo] How to do non premultiplied alpha <=> premultiplied alpha
conversion
Billy Biggs
vektor at dumbterm.net
Fri Aug 26 10:02:13 PDT 2005
Bertram Felgenhauer (bertram.felgenhauer at googlemail.com):
> We were discussing this on IRC:
>
> <biesi> what's the correct way to convert a double color to an int?
> * 255 and round, or * 255 and truncate?
> <ds> imo, *256, truncate, clamp
> <int-e> at least that's what you get if you divide 0..1 into 256 equal
> intervals
> <int-e> *255 and truncate will only give you 255 for exact 1.0; *255 and
> round will give you 0 and 255 half as often than the other values
> (assuming uniformely distributed real numbers)
This came up also in the thread where I wanted to change the cairo
colour internal format to the more honest and understandable 8-bit per
channel. I think we should be consistent and use *255+round, here's
why.
1. This is what Jim Blinn does, and is what is achieved by his
algorithm for integer /255. See "Dirty Pixels", chapter 19. This
definition is prevalent in the industry, and is used by libpixman
and the X server already. Doing something different anywhere in
cairo seems unwise.
2. Values outside [0,1] do occur, and these should be clamped. This
compensates for the bucket-size issue.
I agree that there is no perfect solution, and that this definition
may not be ideal for some application. However, I think there are good
reasons to be consistent.
(FWIW, Jim Blinn also has a really nice system for 16-bit per channel
pixels using 2^14+1 == 1. Makes a lot of sense, and gives enough
precision for linear colour plus overhead, with cheap computation).
-Billy
More information about the cairo
mailing list