Re: [Bf-committers] Color space and alpha issues
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 developersbf-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
Re: [Bf-committers] Color space and alpha issues
+1 2011/12/19 Matt Ebb m...@mke3.net On Mon, Dec 19, 2011 at 8:03 PM, François T. francoistarl...@gmail.com wrote: 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 don't think hiding anything's a good idea, on the contrary I think it needs to be more explicit, but above all it should work correctly by default for simple scenarios. I agree its better for peoples own sake that they learn this stuff for more advanced usage, but it shouldn't be a requirement in order to get blender to do simple things correctly. I think probably a nuke style solution with premul default but options on each node to un-premul/premul before and after its operation would be a good way to go. This could mean that a) It could be switched on by default for nodes that need it, so a simple setup throwing down a file in and a colour correction node will just do the right thing b) hopefully if individual nodes had these sorts of controls, if you want to keep your input unassociated, troublesome nodes like defocus and vector blur could infer this and take it into account, hopefully not mangling your data so much if you want to keep it around. c) you could of course turn all these options off and do it all explicitly if you want too. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- 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
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [42708] trunk/blender: Removed buttons in node headers for hiding unused sockets and for hiding the (non-socket) option buttons.
I'm perfectly fine with current hide all unused sockets while collapsed. Let's not over think this either, who would want to connect to an unused socket while collapsed? you can't see a damn thing anyway Daniel Salazar 3Developer.com On Mon, Dec 19, 2011 at 6:27 PM, PabloVazquez.org venom...@gmail.comwrote: Thanks Lukas! I actually like the way the sockets remain visible when the node is collapsed. Agree in *some* nodes is nice to have the sockets shown, but default behavior should be to hide them, as it is not the same case for all the nodes, so perhaps let the Toggle Hidden Node Sockets option still work when collapsed? So we can manually specify which node should show its sockets and let the rest not to. Would this make everyone happy? P.S: pss pss!, Toggle Hidden Node Sockets operator name should be Toggle Unused Node Sockets -- Pablo Vazquez CG Artist Blender Foundation Certified Trainer E-mail: cont...@pablovazquez.org Website: http://www.pablovazquez.org On Mon, Dec 19, 2011 at 19:34, Alex Fraser adfr...@vpac.org wrote: Hi Lukas, - Original Message - Ok, i just had a discussion with Daniel and Dalai, who also are not amused about the removed hide unused sockets button ;) Instead of just adding back this button though, Dalai proposed to add a more intelligent auto-hide feature: unused sockets are automatically hidden in collapsed node mode. This seems to be the primary purpose of the feature, and since neither names nor values are displayed on collapsed nodes it makes linking more-or-less impossible anyway in that mode. I actually like the way the nodes remain visible when the node is collapsed. The order is maintained, so it's easy to remember which node does what - especially for nodes like Separate RGB. You can quickly glance at the collapsed node and know which channel is being used. Cheers, Alex ___ 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 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [42768] trunk/lib/windows/gcc: Adding png lib 1.2.46 for MinGW
Hi Antony, thanks for that! :) Regards, Thomas Am 20.12.2011 14:51, schrieb Antony Riakiotakis: Revision: 42768 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=42768 Author: psy-fi Date: 2011-12-20 13:51:16 + (Tue, 20 Dec 2011) Log Message: --- Adding png lib 1.2.46 for MinGW Added Paths: --- trunk/lib/windows/gcc/png/ trunk/lib/windows/gcc/png/include/ trunk/lib/windows/gcc/png/include/png.h trunk/lib/windows/gcc/png/include/pngconf.h trunk/lib/windows/gcc/png/lib/ trunk/lib/windows/gcc/png/lib/libpng.a -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] line length / code style.
Hi, c'mon! - http://www.graphicall.org/ftp/ideasman42/long_lines.png That's not a good example. Some of these long lines are great to be in 1 line; because they're just not meant to be read as code really (it's data, a long string, or just lot of crap). The rule for line length is not about numbers (80 or 120) but about producing readable code, emphasizing structure and functionality and to assist debugging. A developer can use own insights and style to follow this in sane ways. For that reason, the line length rule is not a rule (like always capitalize #defines) but an important guideline; follow it to produce readable code, based on your insights for it. Splitting the code guide in Rules and Guides would be also helpful to prevent lengthy discussions. You know; strict in what we agree on, freedom in our doubts, love for all! :) -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 20 Dec, 2011, at 0:12, Campbell Barton wrote: one of the things I was worried about, looks like it might be happening... - not content to set basic rules, devs want full style guide. - devs can't agree - nothing happens So if we cant get our act together in under a month or so (or if Ton is busy, since it seems Ton wants to handle this now) - whatever the reason, I'd like to go ahead with some sane line length (120, and apply this rule where it makes sense). c'mon! - http://www.graphicall.org/ftp/ideasman42/long_lines.png ___ 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
Re: [Bf-committers] Color space and alpha issues
-Original Message- From: James Ruan ruanbeih...@gmail.com 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. Adopting a recommended format for alpha is good, as long as artists have control over it across the composite. However I don't agree that artists don't need to know which format files use. It's an extremely important factor and you can't assume which is the correct since different applications (Blender included) allow to store alpha without respecting formats specifications. And even if applications would store alpha following specifications, some formats (like Targa and Tiff, for instance) allow both types of alpha. You can try guessing, like one of the options in After Effects, but it's not a bullet-proof method and could misinterpret some files, like premultiplied files with luminescent colors. So giving every node in Node System to choose there input and output format is not a good option. No, it's not for every node in the node system. Just for the input/output nodes, so the artist can choose, and more importantly to avoid color management to introduce errors (color management shouldn't affect alpha channel, and converting premultiplied data does it). +1. Good internal representation should store the most info. And RGB+mask alpha is the best choice for compositing. Not when you only need to transform, blur and alpha-over CG renderlayers, for instance. Every compositing tree is different and you can't assume which alpha format is better. Both are needed. Sticking with unassociated alpha has as many problems as associated alpha, and some situations are completely impossible with unassociated alpha (again, luminescent premul). Apart from that, how do you preserve the original info (I mean RGB+mask) after some alpha-over or blur nodes? I wouldn't say that unassociated is the best choice for compositing. It's one of the two available choices. 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). That wouldn't be bad, but it's impossible to make it perfect. This is a simple example showing how easy is to blow it: I have a straight alpha image flagged as unassociated. It's an image introduced to the comp using the inputimage node. I want to multiply the diffuse pass from a render layer on my image. That pass hasn't the renderlayer's alpha channel... how do you flag it? is it RGB? Is it straight RGBA with fully opaque alpha? is it premultiplied RGBA with fully opaque alpha? What's the flag after the multiply operation? Let's say the result will end up flagged as straight alpha. Now I want to use the renderlayer's alpha as the alpha channel for the result of the mix. So I Use a set alpha node. The original RGBA information was tagged as straight, so I assign a new alpha and it should stay straight, right? But it doesn't. Because the diffuse pass I multiplied has a black background already, and if I'm using OSA the result will be, in practical terms, the same than a premultiplied image* So if I keep treating the result as straight alpha I'll get black fringes in the next alpha-over or blur node, because if those nodes are aware of the incoming flag, they will pre-multiply the alpha (because it's needed for those operations) and introduce a double premul fringe. *) I stress in practical terms, I take the liberty to misuse the term premultiplied to point that a difusse pass with the render's alpha set is pretty much the same than a premultiplied combined of the same mesh with a diffuse-only material. 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. As Francesco said, premul/postdivide is for compositors what topology is for modelers. Artists should care about it because it's essential to get good results. If that isn't important, I don't see why the compositor should be improved. Unexperienced compositors are already used to compensate alpha fsckups with dilate/erode nodes, masks, curves and all kinds of hacks to get visually acceptable results avoiding alpha problems. ___ Bf-committers mailing list Bf-committers@blender.org
Re: [Bf-committers] line length / code style.
On Wed, Dec 21, 2011 at 5:27 AM, Ton Roosendaal t...@blender.org wrote: Hi, c'mon! - http://www.graphicall.org/ftp/ideasman42/long_lines.png That's not a good example. Some of these long lines are great to be in 1 line; because they're just not meant to be read as code really (it's data, a long string, or just lot of crap). The rule for line length is not about numbers (80 or 120) but about producing readable code, emphasizing structure and functionality and to assist debugging. A developer can use own insights and style to follow this in sane ways. For that reason, the line length rule is not a rule (like always capitalize #defines) but an important guideline; follow it to produce readable code, based on your insights for it. Splitting the code guide in Rules and Guides would be also helpful to prevent lengthy discussions. You know; strict in what we agree on, freedom in our doubts, love for all! :) -Ton- Yep, I'm aware of this should be some strict rule we apply blindly. My point is that since some lines are so incredible long they should be split, we should probably set some line length to split them at rather then each dev having their own. To referencing that image again: http://www.graphicall.org/ftp/ideasman42/long_lines.png Example of data (shouldn't be changed --- or only changed by the maintainer if they really want to) - unit.c:274 Example of code that should be split (unless maintainers really _don't_ want to) - editmesh.c:925 - sculpt.c:595 - transform_snap.c:1625 ...that leaves function calls and definitions: - makesrna.c: all long lines - interface.c: all long lines IMHO - these should be up to the maintainer(s) weather to split or not. - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Tile!
Really interesting and clear! Should this be a bit more publicized? I didn't know about this meeting, and maybe some other blender users/devs want to join the node porting :) Are you planning an article on code.blender.org once you had another few meetings? Just saying Ehi guys, we had this meeting about porting the old nodes to new compositor. Here the logs, you'll find all the informations! ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Color space and alpha issues
2011/12/21 gespert...@gmail.com gespert...@gmail.com: -Original Message- From: James Ruan ruanbeih...@gmail.com 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. Adopting a recommended format for alpha is good, as long as artists have control over it across the composite. However I don't agree that artists don't need to know which format files use. It's an extremely important factor and you can't assume which is the correct since different applications (Blender included) allow to store alpha without respecting formats specifications. And even if applications would store alpha following specifications, some formats (like Targa and Tiff, for instance) allow both types of alpha. You can try guessing, like one of the options in After Effects, but it's not a bullet-proof method and could misinterpret some files, like premultiplied files with luminescent colors. So giving every node in Node System to choose there input and output format is not a good option. No, it's not for every node in the node system. Just for the input/output nodes, so the artist can choose, and more importantly to avoid color management to introduce errors (color management shouldn't affect alpha channel, and converting premultiplied data does it). +1. Good internal representation should store the most info. And RGB+mask alpha is the best choice for compositing. Not when you only need to transform, blur and alpha-over CG renderlayers, for instance. Every compositing tree is different and you can't assume which alpha format is better. Both are needed. Sticking with unassociated alpha has as many problems as associated alpha, and some situations are completely impossible with unassociated alpha (again, luminescent premul). Apart from that, how do you preserve the original info (I mean RGB+mask) after some alpha-over or blur nodes? I wouldn't say that unassociated is the best choice for compositing. It's one of the two available choices. 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). That wouldn't be bad, but it's impossible to make it perfect. This is a simple example showing how easy is to blow it: I have a straight alpha image flagged as unassociated. It's an image introduced to the comp using the inputimage node. I want to multiply the diffuse pass from a render layer on my image. That pass hasn't the renderlayer's alpha channel... how do you flag it? is it RGB? Is it straight RGBA with fully opaque alpha? is it premultiplied RGBA with fully opaque alpha? What's the flag after the multiply operation? Let's say the result will end up flagged as straight alpha. Now I want to use the renderlayer's alpha as the alpha channel for the result of the mix. So I Use a set alpha node. The original RGBA information was tagged as straight, so I assign a new alpha and it should stay straight, right? But it doesn't. Because the diffuse pass I multiplied has a black background already, and if I'm using OSA the result will be, in practical terms, the same than a premultiplied image* So if I keep treating the result as straight alpha I'll get black fringes in the next alpha-over or blur node, because if those nodes are aware of the incoming flag, they will pre-multiply the alpha (because it's needed for those operations) and introduce a double premul fringe. *) I stress in practical terms, I take the liberty to misuse the term premultiplied to point that a difusse pass with the render's alpha set is pretty much the same than a premultiplied combined of the same mesh with a diffuse-only material. I'm sorry that I failed to follow your opinion. I don't understand why double premultiply will happen if each internal buffer's tag is correctly set to what its content should be. If it goes wrong, it must be something that breaks the rule. Certainly, every image entering the composite system must indicates its format and outputs a straight alpha( actually recommended) to the system. And actually I don't see any problem to introducing emitting in partially transparent image with the format straight alpha. As a blender user, if followed by your 'teaching not hiding' doctrine, I would be the first student to understand the complexity of the problem. So let me show my understanding of this problem. Correct me at any
