[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