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 :)<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div>
<br></div><div>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.</div>
<div><br></div><div>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.<br>
<br>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. <br>
<br>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.<br>
<br>A few extra notes:<br></div><br>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.<br>
<br>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.<br>
<br>cheers<br><br>Matt<br>