[Bf-cycles] Alpha pass independent from transparent option

Daniel Salazar - 3Developer.com zanqdo at gmail.com
Sun Dec 9 04:00:15 CET 2012


Ehm I guess that last question should have been for Brecht.

Thinking more about non-renderlayer inputs, If the image input node does
some "clever" guessing (using flags or format standards as clues) of the
input format in order to ensure an associated alpha input I hope this
is accessible from the node UI so we can correct any missjudgements, i.e.
with a checkbox that can be unchecked

Daniel Salazar
patazstudio.com



On Sat, Dec 8, 2012 at 7:35 PM, Daniel Salazar - 3Developer.com <
zanqdo at gmail.com> wrote:

> Bassam: that sounds nice, what about image input nodes? convert all to
> premul based on image type?
>
> Daniel Salazar
> patazstudio.com
>
>
>
> On Sat, Dec 8, 2012 at 6:52 PM, Bassam Kurdali <bassam at urchn.org> wrote:
>
>> Hi Brecht, then it's perfect,
>>
>> - output files dictate the choice,
>>
>> - renderlayers are always premul.
>>
>> I had been initially scared you meant the renderdlayers themselves would
>> end up switching their alpha between key and premul based on the output
>> file choice!!
>>
>> Suggestions for the renderlayer nodes: a convenience 'key alpha' check
>> box that does a convert to key alpha if checked, removing the need for
>> the extra node... benefits:
>>
>> 1- removes need for an extra node in some setups.
>> 2- communicates to the user that the renderlayer is (unless you check
>> it) with premul alpha.
>>
>>
>> On Sat, 2012-12-08 at 20:47 +0100, Brecht Van Lommel wrote:
>> > Hi,
>> >
>> > > So I would make the following suggestion to avoid the ambiguity:
>> > >
>> > > 1- do as you said and switch key/premul based on output format (with
>> a a
>> > > choice if the format allows both) in the output file settings.
>> >
>> > Yes, probably there would be 3 choices: automatic, premul, key. I'm
>> > not sure about the design yet, it's probably not feasible to make the
>> > compositor keep track automatically of what the user did. I'm thinking
>> > there would be some settings that says if the compositor outputs
>> > premul or key, and based on that it could do automatic conversion to
>> > the file format then.
>> >
>> > So there would actually be 2 settings, but I would hope that in nearly
>> > all cases the compositor output type can be set to premul and file
>> > format to automatic. This should work for the cases where you use
>> > typical intermediate formats like OpenEXR and TIFF, and do final
>> > output either without alpha or with alpha in a web format like PNG.
>> >
>> > > 2- allow switching key/premul in renderlayers regardless of output
>> > > format , and make them a sane and consistent default (regardless of
>> > > output format chosen, maybe something suitable for openexr).
>> >
>> > Not sure what you mean by this, where this switching would happen. But
>> > basically anything that comes out of a render engine is naturally
>> > premul. OpenEXR is always premul, and TIFF has metadata to indicate
>> > which alpha type was used. For intermediate formats premul seems the
>> > best option.
>> >
>> > Layers can be converted to key after rendering but there's no
>> > information to be gained there, and it would give some information
>> > loss for surfaces that are both emissive and transparent (though
>> > that's no so common, maybe for fire volumetrics or so). I think it
>> > would be good to make compositing nodes work by default with premul as
>> > a convention, so blur type nodes would have to do no conversion, and
>> > color correction nodes would optionally convert to key and back.
>> >
>> > Brecht.
>> > _______________________________________________
>> > Bf-cycles mailing list
>> > Bf-cycles at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-cycles
>>
>>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20121208/fd2c19bf/attachment.htm 


More information about the Bf-cycles mailing list