[Bf-vfx] Blender's colour pipeline

[François T.]

AMEN !!! :)

2011/7/18 Matt Ebb <matt at mke3.net>

> 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
>
> _______________________________________________
> Bf-vfx mailing list
> Bf-vfx at blender.org
> http://lists.blender.org/mailman/listinfo/bf-vfx
>
>


-- 
____________________
François Tarlier
www.francois-tarlier.com
www.linkedin.com/in/francoistarlier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-vfx/attachments/20110718/d47f37f0/attachment.htm