[Bf-committers] Color space and alpha issues

[François T.]

+1

2011/12/19 Matt Ebb <matt at mke3.net>

> On Mon, Dec 19, 2011 at 8:03 PM, François T. <francoistarlier at 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 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
____________________
François Tarlier
www.francois-tarlier.com
www.linkedin.com/in/francoistarlier