[Bf-committers] Render and Scene Panel Audit?

[Guillermo Espertino (Gez)]

El 27/09/12 09:45, Brecht Van Lommel escribió:
> Basically:
>
> * Alpha mode should be turned into a transparent on/off setting, same
> as Cycles. If it's off there is no alpha, if it's on it's
> premultiplied.
Oh, that makes sense and it would be easy to understand for anyone.
Also, premultiplied as default seems the best option for render layers. 
Key doesn't offer a benefit for rendered images over a pre-divided 
associated image.

> * 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.

> * 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).

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).

The second example is quite frequent, because it's necessary for 
compositing glares, glows and volumetric lights.
Premultiplied formats should be used for that, of course. But if you 
bring your files from other applications like Photoshop or GIMP that's a 
problem, since those applications automatically multiply alpha when an 
associated alpha format is chosen.

The problem here is that an associated alpha image is not necessarily an 
image where the RGB data was pre-multiplied by its alpha, so any file 
could be an associated alpha image, from an artistic point of view, 
depending on the effect you want to achieve, hence using a flag to 
define what's "premultiplied" or not doesn't cover all the possible cases.

In my opinion inputs should be left as they are, and offer the chance of 
forcing pre-multiplication if it's needed, just like we have now. It 
takes a little effort from the user, but it covers all the possibilities.

As you pointed out in the wiki page, Blender has to adopt one single 
alpha convention (and associated seems to be the most adequate option), 
but perhaps it's not possible to make it completely transparent to the 
user, because of the potential complexity of the compositing work.
It's clear that having this kind of flexibility complicates things for 
color management, but apparently that's the path applications like Nuke 
followed, instead of automatic.

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.

The inputs/outputs would be still in charge of the user, just like now.

Gez