利用者:Sobotka/Color Management/Blender CM Integration
目次
Summary
The following is a high level outline covering frequently experienced artist needs in a color managed system.
Most of this document is likely depreciated, but some of the UI elements remain valid.
Breakdown
While there are many unique situations for color management, the primary regions can be divided into four discrete areas that will need to be tackled.
User Interface Colorspace Control
It is important for an artist to be able to control the colorspace that elements such as a color picker represent. The following details might be considered:
- Color Picker Colorspace. The colorspace that the color picker transforms to. This should be considered a working space to color space transform.
- Out of Gamut Indication. Where a working space is larger than the destination colorspace dimension, it can be useful for an artist to get an indication as to what colors are beyond representation in the current output domain.
Input Asset Colorspace Control
Input assets must be properly transformed from a source colorspace to the working space. While this transformation might be a single step, such as an ACES or AdobeRGB to an internal working space, it might also be stacked with other transforms. An example might be a transformation that permanently bakes in a source side transform such as the Cinestyle 1D LUT for footage.
Working Space Colorspace Control
The working space will need to be specified somewhere. This is a required portion for any input transformation. Within Blender, only radiometrically linear colorspaces qualify.
Output Asset Colorspace Control
Fine grained control over output spaces is crucial. Output spaces might include:
- File output.
- Display output.
Considerations
It is important to realize that colorspaces are not always desired to be permanently baked into the data. An example is a display output pipeline. Example cases might be as follows:
- An artist wishes to toggle back and forth between a raw transform from the color space to the display without a look modification LUT.
- An artist wishes to view raw data without a colorspace transformation.
- An artist wishes to bake in both a look modification LUT and a proper primaries based transformation to an alternate colorspace for delivery.
Design Needs
As we can see with the above considerations, we can divide the color management needs into advanced and reduced systems.
Reduced LUT UI Element
In this instance, a single LUT would be assigned. Obvious UI candidates would be a single selection box. Candidate colorspace LUTs would be populated from the central OCIO configuration file.
Advanced LUT UI Element
In order to offer artists proper granular control, the UI element must be able to accommodate:
- The ability to add or remove LUTs in a sequential list.
- The ability to selectively toggle the various transformations in the list on and off.
The simplest approach appears to be a UI element that is virtually identical to the existing texture selection UI element.
Breakdown of Advanced / Reduced LUT Control Elements
Reduced LUT UI Controls
- Working space. Likely stored within User Preferences area. Provides OCIO with information on suitable transformations from the OCIO configuration file. Use an OCIO Role to define default colorspace transformation.
- Color Picker. Use an OCIO Role to define default colorspace transformation.
Advanced LUT UI Controls
- Input Image / Animation. Likely located in the Properties panel of the UV Image editor pane. OCIO Role to define default colorspace transformation.
- UV Image Editor control. The UV Image editor may have chains of LUTs such as a look LUT, a display transformation to a known color space LUT, and / or per monitor display profile LUTs. As a result, granularity is required.
- Output File Control. Output panel of Properties seems reasonable. Should be bounded with the Predivide work for curved space output formats. OCIO Role to define default colorspace transformation.
- Colorspace Node. A node to perform transformations within the compositor for various artist needs such as keying, color manipulations, etc. No OCIO Role required, as default would be an empty transform chain.
Migration Path
In order to keep Blender as close to usage patterns as is currently possible, OCIO Roles will need to be defined to clearly mimic existing patterns.
The Default Blender OCIO Configuration
The default Blender OCIO is a nightmarish mess as it currently exists. For 2.8, it would be wise to revisit and reconstruct a more foundationaly solid configuration.
Defining the Default Blender Space
The default Blender space is technically already defined as sRGB (IEC 61966-2.1) with implied viewing conditions. It is worth considering adopting a wider reference space for delivery to HDR formats and contemporary outputs such as modern televisions, computer displays, and other such media.
Additional Blender Considerations
To accomplish more complex issues such as per shot grading, ASC CDL transformations etc., some degree of Blender interaction with files will be needed. While OCIO provides for much of the syntax and generation, Blender may need to consider generation of per shot grade files, OCIO CDL files, etc. Examples can be found at http://opencolorio.org/userguide/contexts.html.
Conclusion
Default OCIO Roles will be defined to keep Blender as close to the current usage patterns as possible. Dividing colorspace transformations into Advanced and Reduced classifications keeps the Blender system workable without hindering artists migrating from older versions. Granular control over colorspace transformations will greatly augment artist needs that cover shot grading, destination delivery output, and other complex areas.
