I'm very glad this issue is finally getting the attention it deserves! >> If it does, it makes more sense to go with added complexity and force >> the artist to learn the ins and outs of alpha for certain operations. >> > As usual I'm more for the teaching rather the hiding :) > As Matt said, only comp expert are going to want to mess with this anyway > (I'm even sure some expert will bypass it in some cases). But people who > wants to get serious about it will have to learn it no matter what with any > application out there
I'm not a comp expert but I'm happy that I had to learn how to deal with associated/unassociated alpha to get my composites right, mostly because I use OSA a lot and AA artifacts are pretty visible there if you do things wrong. I'm pretty comfortable with the alpha convert node and I'm all for keeping it and teaching people to use it instead of hiding the tricky part. The compositing books I've read mention this (I mean the differences about premultiplied/straight alpha and when to use them), other compositing apps have premul/unpremul nodes and alpha selectors in I/O nodes. I think it's pretty basic compositing knowledge and Blender shouldn't mask it but make it more obvious and let the user decide. It has been discussed to flag the alpha "mode" and make nodes "smarter" to avoid complexity, but I can think of several situations where a simple multiplication of two inputs would create an output that is, in practical terms, the same than a premultiplied image without being one. It's impossible to predict what the compositing artist will do, and as it has already been discussed both alpha modes are needed across the composite. Personally I don't think the compositor needs much improvement in that regard since it already offers the tools to move from one alpha "mode" to the other. And if the compositor needs something is making that more visible rather than hiding it. Assuming things you can't really assume is the problem. For instance, we have a serious input/output problem in the compositor with with gamma-corrected premultiplied images and color management. Premultiplied images are being linearized without "un-premultiplying" alpha and that creates an input that is not premultiplied or straight and it's impossible to comp right (a tiff file, for instance, can have premultiplied OR straight alpha. If it's premultiplied it's impossible to comp it right in Blender). A simple switch to manually declare if the input is premultiplied (triggering an unpremul before linearization) would solve this problem and help users to track the alpha "mode" across the composite. The same goes for the outputs, before final gamma-correction. IIRC Troy_s sent a patch for that, and if there isn't a better solution available I'd say it should be used immediately, since the current state is broken and there's no other solution than converting manually all the external assets to unassociated alpha (and that doesn't seem very consistent if the user chose "Premultiplied" to render CG). AFAIK, the rest of the alpha problems are simply mismatches between what is expected and what is used. Blender apparently expects premultiplied RGBA for most of the operations, so the best solution seems to unify that and do the proper divisions when straight alpha is needed, and of course make linearization of non-linear assets happen before premultiplying images that have unassociated alpha, or predivide>linearize>multiply when inputs are already premultiplied. If source material doesn't declare how its alpha is stored and if they're gamma-corrected or linear, the safest is to add selectors and let users choose. The same goes for outputs. If users are informed about what's expected in each case it would be easy to make a decision. Other apps like Nuke seem to have adopted that strategy and I think we should too. The alternative is to make assumptions, and the Adobe Forums thread shows what could happen with those assumptions if they're wrong. _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers