[Bf-vfx] Blender's colour pipeline

[Matt Ebb]

Hi, Jeroen poked me about joining this list a little while ago, and I
started typing up this email and have just gotten around to finishing it :)

I notice in the archives there's a bit of discussion about colour pipeline,
so I thought I'd give a bit of a summary of where I think things are at and
where they can go.

As you probably know, the 'colour management' feature in blender is a first
version, obviously not a full cms, but one step in the way there. Most of
the work was in tracking down and more clearly defining the inputs and
outputs where imagery enters and exits blender, and a simple conversion at
those points. Now, it's defined that (with a few minor exceptions) all
colours represented inside blender's renderer/compositor are linear and with
sRGB primaries - previously this was all over the place. This was done
mainly to ensure that calculations in the renderer and compositor were done
in a linear rather than gamma corrected colour space, which was a good first
stage target with significant rewards in quality.

The current system introduces the idea of tagging imbufs with a simple
'profile' metadata, which are used to guide what happens during conversions
in and out of the internal pipeline.

Currently, for simplicity's sake the system assumes that all non-linear
inputs and outputs of the system are sRGB (or linear w/sRGB primaries in the
case of exrs), and at conversion time does no gamut mapping. This leads to
blender implicitly having an internal working space of linear with
sRGB/rec.709 primaries. The next step should be to remove the assumption
that all inputs are sRGB and introduce some method of correction/gamut
mapping to convert from input imagery colour space -> working colour space
-> output colour space.

Much of the infrastructure for this should be already set up for the most
part - the way I see that things should go from here is replacing the
hardcoded srgb_to_linearrgb() functions with calls to some kind of CMS
library, like lcms or OIIO. This would handle the transform between the
input imagery colour space -> working colour space (linear with whatever
primaries) and from working colour space -> whatever output is required for
various situations.

The experiment with OIIO as a compositing node is a good start, but this
sort of thing really needs to be hooked into blender at a deeper level
within it's imaging pipeline (as the current srgb<->linear stuff mostly is
now). It needs to be in effect for imagery being displayed in the image
editor, ideally for the 3D view, for colour pickers and swatches, for the
compositor, it should be available for the video sequence editor too, and
any other places where blender deals with colour. Having colour management
as compositor only will just fragment things even further when what blender
needs is better integration.

So from a user's perspective for example, just like in Nuke, we should have
a little dropdown in Blender's image editor controlling what the output
space is (default sRGB, but some common ones like rec.709, as well as any
custom profiles you've loaded). There would also be similar options on all
image inputs - primarily on image nodes, but also in other places in blender
like textures, to define the profile of each input image too.

A few extra notes:

In further versions, especially now with the advent of Cycles, I'd really
like to see the option to disable colour management removed. This was really
only implemented so that there'd be some kind of backwards compatibility
between Blender 2.4 and Blender 2.5, so users' renders in BI would look
similar.

This option, however, has been the cause of most of the bugs and complexity
within the pipeline since its implementation. With a more advanced colour
management system, people could still bypass colour management by assigning
some kind of null profile (or just one that's equal to blender's working
space), to both their input and output imagery. This would mean that no
translation/mapping would occur and the raw pixels would be processed as-is.
This would be a clunky, yet possilbe way of disabling colour management, and
it *should* be clunky - people should really never need to be able to
disable it on a system-wide level.

cheers

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-vfx/attachments/20110718/93e86c11/attachment.htm