Hi all, I'm really interested in this discussion since I found myself unable to understand how alpha works in the blender compositor and how I can clearly use it.
In my quite long experience with many compositing system I always had the need to keep separated RGB from any other channel, alpha included since anything but RGB describe the color of the image. As an artist I would never take care of how blender internally handle the premultiplication but while making the network of nodes I must have the chance to premult or postdivide an image every time I need it because there are so many situation where a choice in this field as to be taken. Situation that require postdivided img: 1. Avoid black edges around obj 2. Better color correction handling 3. More saturated half transparent layer 4. Capability of work or undestand how to modify that half transparent edges 5. Ability to treat color and alpha in a separated manner Of course a the end of the chains there are almost always premultiplied images. About the "teaching part" For a compositor being able to handle premult/ postdivide is quite like for a modeler make the right topology. Hope this is usefull for further proposal/ discussion! :) Francesco E-Mail Sent via BlackBerry from BT Mobile -----Original Message----- From: James Ruan <ruanbeih...@gmail.com> Sender: bf-committers-boun...@blender.org Date: Mon, 19 Dec 2011 21:03:43 To: bf-blender developers<bf-committers@blender.org> Reply-To: bf-blender developers <bf-committers@blender.org> Subject: Re: [Bf-committers] Color space and alpha issues 2011/12/19 François T. <francoistarl...@gmail.com>: >> >> >> >> 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 > > > cheers, > > F. > > > -- > ____________________ > François Tarlier > www.francois-tarlier.com > www.linkedin.com/in/francoistarlier > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers I don't think the opposite of teaching is hiding. I think we need a uniform format for alpha. Artists don't need to know in which format there file is stored or processed. Only the well defined result counts. So giving every node in Node System to choose there input and output format is not a good option. > The issue with compositing is that the image buffers are not just used for > final storage and distribution, but they're used as a work-in-progress > scratch pad, and it's often that the way you work with channels doesn't > always represent something logical (eg. keeping masked out RGB pixels > around so you can retrieve them later). +1. Good internal representation should store the most info. And RGB+mask alpha is the best choice for compositing. Maybe, we can handle both format by adding a tag in the imbuf, then define a RECOMMEND format for certain application (eg. premultiplied for rendering buffers). Image that used in other format will be converted to the RECOMMEND for only once. This will add a lot of code for checking and converting the format of imbuf though. But by using a cache, we can find a balance between CPU and Memory (maybe disk cache). And it's a good habit to check the input data and outputs to a RECOMMEND format (always assuming others doing wrong and do it right itself). Or we just use the unassociated alpha everywhere since it preserves most info and do conversions every time it is needed. After all, it should be easy, simple and correct for the users. They should not care about in which format their image is stored. -- James Ruan _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
