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 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
