[Bf-committers] Render and Scene Panel Audit?

Brecht Van Lommel brechtvanlommel at pandora.be
Sat Sep 29 02:46:33 CEST 2012


On Fri, Sep 28, 2012 at 4:44 PM, Guillermo Espertino (Gez)
<gespertino at gmail.com> wrote:
>> * RGB/RGBA is a file saving option, does not belong in the shading
>> panel. This option should default to RGBA and save alpha if it is
>> available. With the current Sky rendering that is not ideal, but if we
>> have a transparent on/off switch it makes sense.
> I wonder if it's really necessary to have a RGB/RGBA switch as a saving
> option if you chose "transparent" in the rendering panel. If you did
> that, is clear that you want transparent (RGBA) and not RGB.
> Leaving the transparent option and the RGB/RGBA switch in the output
> panel makes it necessary to select two options to get the right output.
> Two options is basically the same we have now.

The option defaulting to RGBA makes it so that you do not actually
have to select anything. If there is no alpha in the render it would
not hurt to have that option on. However the transparent setting only
applies to the render (or maybe one of many render layers), and in
compositing or the sequencer alpha can still be added, and it would be
good to save that alpha by default too.

>> * File formats should automatically convert premul<=>  key alpha based
>> on whatever the standard is for that file format. So PNG key, EXR
>> premul, etc.
> I don't agree here.
> That shouldn't be automatic. Or at least if it's automatic, a
> non-destructive option to revert it should be offered (maybe a
> "prediction" based on the format could be used, giving the chance of
> changing it if it's wrong).

Sure, there would be an option for the alpha format to save, like you
have for color spaces now. It should just do the most commonly useful
thing by default.

> That conversion is destructive, and there are a couple of edge cases
> where the conversion is not only not needed, but also undesirable.
>
> Sometimes you want to keep the RGB data from your unassociated alpha
> images for several reasons, like:
> - A masked unassociated file (a PNG for instance) stores the original
> RGB data of the fully transparent pixels, you could need it.
> - You could need to use an unassociated alpha format for a luminescent
> alpha over (for instance a photo of a candle shot over black background.
> The alpha channel shows the opaque parts but there is a glow in the
> masked part you want to keep and composite via an alpha over node).

Yes you could, but it should not be the default. If you want to set up
a workflow with premul PNG files, great, but that's the exception to
the rule. If you really wanted there could be an option to indicate
the default assumption, but for most users going with the file format
standard is the right choice.

> Sorry for being repetitive, but there's a number of minor changes that
> can be applied to improve things considerably, like unifying the alpha
> convention of viewers and 3D view to expect premultiplied and make the
> application more consistent internally.
> This is what we have now: The textures preview expects associated (no
> matter what you chose in the shading panel) because shaders seem to
> expect associated alpha textures too. The GLSL 3D view expects
> unassociated (again, no matter what "alpha" is selected in the shading
> panel). Viewers seem to expect unassociated too.
>
> I don't think it's necessary to go through a complete overhaul of the
> internals to get that right.
> What it seems to be needed there is just skipping a multiplication in
> the 3D view and the image viewer and that would make those viewers
> consistent whith the shading system, which seems to expect associated.

No, you can not do minor changes to make this work. You really can't,
it's a big undertaking that affects more places than you might think,
even without considering file I/O. It's also not true that the render
texture stack expects premultiplied, what works best depends on how
you use the texture. Just making the 3D view and image viewers expect
premultiplied opens you to a different set of problems that then need
to be solved instead.

You might be happy with a workflow where you manually control alpha
formats at every step, but it should not be necessary, and we better
design things so that it does the right thing automatically whenever
possible.

Brecht.


More information about the Bf-committers mailing list