From BlenderWiki

Jump to: navigation, search

Color

For the current state of color management, see the color management release notes.

Definitions

  • Scene linear: this is the central color space that is used for rendering and compositing, it should correspond to physical units of light for realistic result.
  • sRGB / gamma corrected: this is the color space used for display in Blender.
  • Key alpha: color stored as (R, G, B, A). This is a format that is used in most paint programs. This makes it possible to have RGB colors in part of the image that are completely transparent. Also called: straight alpha, unassociated alpha, unpremultiplied alpha. This also dictates which over operation to use in compositing [(Over.RGB * Over.Alpha) + (Background.RGB * (1- Over.Alpha))].
  • Premultiplied alpha: color stored as (R*A, G*A, B*A, A). This is a format that is natural for texture filtering, blurring. Also called: associated alpha. This also dictates which over operation to use in compositing [Over.RGB + (Background.RGB * (1 - Over.Alpha))].

Issues

Alpha I/O

File formats usually have well defined alpha mode, premul or key, but we do not respect this. It's basically up to the user now to guess what the right mode is.

Solution: image file I/O should take care of any needed conversion.

Alpha & Rendering

Game engine and viewport OpenGL drawing assume key alpha, while render engine needs premul alpha. This means that an image with alpha with only look right in one or the other. Image editor display always assumes premul alpha. For correct texture filtering premultiplied alpha should be used in OpenGL and rendering.

Solution: we should either define on a single standard or give tag buffers as being in either format, and ensure this is handled everywhere.

Color Managment & Alpha

Color space conversion does not take premul alpha into account, which gives bad looking results in some cases.

Solution: color space conversion usually should happen on RGB without alpha multiplied in. This should be done by default, but it should be possible to toggle this off in some cases as well. Neither solution is right since color space conversion on images with alpha is undefined.

Compositing and Sequencer

The sequencer and compositor code don't take into account if the image is premul or key, color correction or blurring nodes need to take into account which alpha type is used in the input image. If we go for a premultiplied alpha standard here, color correct nodes will need changes to work correct on premultiplied RGBA.

Solution: add an option to color correction nodes, enabled by default, that converts colors to key and back for the color correction operations. This is often the desired behavior but not always.

Premultiplied

Color correction/mapping/management operations often need to work on color without alpha, so for those we need to first divide by alpha, do the operation, and multiply by alpha again. This may not always be needed though, the right operation is not always well defined and may depend on the background we're compositing over.

Negatives:

  • Image color in parts with alpha < 1.0 will not be usable separately anymore. This is currently possible in the texture stack with color influence enabled but alpha not for key alpha file formats (png).
  • All colors on data are key alpha (this is useful because modifying alpha does not also modify RGB, but needs conversion).
  • Node sockets colors are stored in key alpha, so need conversions, confusing when mixed with premul buffers.
  • Image painting code assumes key alpha, so would need to be converted to use premul.

Key

Blurring/filtering/interpolation type operations need to multiply each element by alpha, so its color gets weighted properly, and then at the end divided by the sum of alphas to convert it to key alpha again.

Negatives:

  • Extra multiplications/divisions for mipmap creation and texture filtering.
  • Need conversion to premul for good OpenGL texture filtering.
  • Need extra operations in blur/defocus/vblur/filter/..
  • EXR is premultiplied standard, and used through the render pipeline, so this would need many conversion here.
  • Premultiplied alpha is more natural for render, there is already no color in places with alpha 0.

Proposed Changes

  • Premultiplied as standard for float images.
  • Key alpha for byte images, or at least have the images tagged depending on the alpha type (?)
  • Image I/O is responsible for the correct conversion to of the file format.
  • OpenGL textures must be ensured to be in premultiplied alpha format.
  • Color correction / management / mapping operations should happen on RGB without alpha premultiplied by default.
  • Image datablock should get Automatic / Premul / Key options to indicate the alpha type in the file.
  • Images used as image textures in rendering/OpenGL need an option to indicate if their alpha channel should be used or not, to avoid premultiplying when alpha is not used.

If we use a key alpha convention for byte images, the rendering and OpenGL code needs to be adapted. When used as image textures for rendering, premultiplied alpha should be used for correct mipmapping and texture filtering. It could do conversion for mipmapping and convert back, and then in the texture filtering code make it multiply with alpha on the fly. For OpenGL there's a similar issues where for best filtering the images should be stored premultiplied on the GPU, again this conversion could be done on the fly.

Further Reading