This slide definitely helped me fully process what goes wrong in the failure cases of non-premultiplied alphas.
bpopeck
A small thing, but shouldn't the $(.75,0,0.75)$ in the premultiplied box on the right be in the form $(C_r,C_g,C_b,\alpha_C)$, i.e. $(.75,0,0,.75)$?
dtorresr
So when applications are moving color data around, are they stored as premultiplied values up until it's finally time to render the final image?
Bananya
I think @bpopeck is right. Does the premultiplied method give the same result as non-premultiplied method before the un-premultiplied step (i.e. divide by alpha)?
hubbahubba
What would the result be if as a rule we were to normalize the non-premultiplied values after blending colors?
keenan
@bpopeck Good catch; looks like it's just a missing comma.
keenan
@dtorresr Some applications are written this way, yes. But you'll find plenty of code that isn't all that careful about alpha blending and still manages to make cool-looking images! A general phenomenon is that the more careful/thoughtful/principled you are in designing your computational representations (in this case, for color and alpha), the less painful it will be to synthesize beautiful images. Things will "just work" as expected in a variety of scenarios, and you won't have to do as much tweaking/kludging (even if it's more work up-front).
keenan
@hubbahubba Not sure—but you could try to cook one up that gives the same effect! I would guess it ends up being equivalent to premultiplied alpha/homogeneous cooridnates...
dranzer
Yup I also caught the typo in the right box. I just thought it was one of those hidden typos to check if we are paying attention.
barath
Yeah, Even I came here to mention the missing comma :/ guess I'm late to the party!
This slide definitely helped me fully process what goes wrong in the failure cases of non-premultiplied alphas.
A small thing, but shouldn't the $(.75,0,0.75)$ in the premultiplied box on the right be in the form $(C_r,C_g,C_b,\alpha_C)$, i.e. $(.75,0,0,.75)$?
So when applications are moving color data around, are they stored as premultiplied values up until it's finally time to render the final image?
I think @bpopeck is right. Does the premultiplied method give the same result as non-premultiplied method before the un-premultiplied step (i.e. divide by alpha)?
What would the result be if as a rule we were to normalize the non-premultiplied values after blending colors?
@bpopeck Good catch; looks like it's just a missing comma.
@dtorresr Some applications are written this way, yes. But you'll find plenty of code that isn't all that careful about alpha blending and still manages to make cool-looking images! A general phenomenon is that the more careful/thoughtful/principled you are in designing your computational representations (in this case, for color and alpha), the less painful it will be to synthesize beautiful images. Things will "just work" as expected in a variety of scenarios, and you won't have to do as much tweaking/kludging (even if it's more work up-front).
@hubbahubba Not sure—but you could try to cook one up that gives the same effect! I would guess it ends up being equivalent to premultiplied alpha/homogeneous cooridnates...
Yup I also caught the typo in the right box. I just thought it was one of those hidden typos to check if we are paying attention.
Yeah, Even I came here to mention the missing comma :/ guess I'm late to the party!