利用者:Sobotka/Color Management/Team Based Color Pipeline Concerns

提供: wiki
< 利用者:Sobotka‎ | Color Management
2018年6月29日 (金) 06:07時点におけるYamyam (トーク | 投稿記録)による版 (1版 をインポートしました)
(差分) ← 古い版 | 最新版 (差分) | 新しい版 → (差分)
移動先: 案内検索

Color Pipeline Concerns

Maintaining a distributed team is a challenge regarding color. Here is a brief list of concerns regarding color integrity and management in a distributed scenario.

Outstanding Blender Technology Issues

  • Several aspects of Blender's UI remain unhooked into the color management pipeline.
  • Color pipeline should be outlined and tested, including target delivery format.

Outstanding Blender Color Management Technology Needs

Color Picker

Currently the color picker dumps raw data values unmanaged to the display. The implications are:

  • The resultant output is in the primaries of whatever device it is dumped to. A wide gamut displays wide gamut values, a projector displays potentially XYZ values, etc.
  • A disconnect between the working space and the UI element.

Solution

Implement the color picker role and apply it to the wheel. Most color related UI elements require perceptual tone curved space transforms for interaction. Further, the currently enabled display must transform the result to accommodate for color transforms to the destination device. As a result, the chain for the color picker must adhere to the following order:

  1. Color Picker Role for perceptual transform to properly display data / account for the non-linearity of the selected color space.
  2. Display transform for unique primaries adjustment per display.

Per-Display Transform

Currently it is impossible to maintain a color managed working environment across multiple displays. Each display / output device requires a unique transform to accommodate the unique primaries per device.

Solution

Output views per UV Image Editor are selectable per pane.

Textures and other UI elements

Certain aspects of the UI such as gradients in ramp areas etc. are likely unmanaged. The implications are:

  • Potential disconnects between the data and the UI.

Solution

Implement a UI perceptual role for such elements. If color is involved, route through unique per-display transform for primaries adjustments.

Default OCIO Configuration

A default OCIO configuration is a hacked mess. It should be updated and cleaned up.

Team Complexities

The following is a short list of concerns and issues that are likely an issue when dealing with a project with teams and diverse work pipelines:

  • Different teams using different display monitors for color critical work.
  • Different assets being ingested into the working space.
  • Different teams making color critical adjustments to data.
  • Elevate knowledge regarding color management and the complexities surrounding it.
  • Need to identify targets for delivery early.

Remedies

Outline and Adhere to Color Management Pipeline Rules

A simple document outlining how to profile a display and implement it for color critical work. The following is a brief outline of some methods of negotiating the obstacles.

Identify Delivery Contexts Early

Knowing the destination of the content will help in deciding on a working space. Gooseberry should decide early if it will target the REC.2020 standard or other such wider gamut format.

Different Display Hardware for Color Critical Work

The various levels of quality of displays will impact the ability to evaluate and collaborate on color systems. The solution is to rely heavily on OpenColorIO to deliver the correct transforms for the data. The only method to eliminate this obstacle is to invest in proper display profiling hardware for each team. Inexpensive options include the I1DisplayPro (200$-250$ USD) and the ColorMunki Display (150$-170$ USD). Both are virtually identical in hardware, with a minor difference in processing power.

Wide gamut displays make matters potentially worse, as Blender cannot currently properly render color swatch pickers to wide gamut displays. In addition to this, without a custom profile for each workstation, Blender will not display correct colors, and no amount of calibration can fix this.

The correct method to eliminate this difference in hardware would be to perform the following steps and assumptions:

  1. Always perform a profile on uncalibrated displays.
  2. Profile to a known standard. The sRGB standard is the most likely candidate here, with a reference D6500k white point and sRGB primaries, but Gooseberry is likely more well suited to aim for REC.2020.
  3. Convert the ICC profile to a 3D LUT correctly. Disable printing related conversions such as black point compensation and be certain to keep any calibration adjustment out of the 3D LUT.
  4. Add a custom OCIO profile for each workstation display on the team using a unique profile for each.

Different Assets in Different Color Spaces

Care must be taken in the early preproduction steps to design a well crafted OCIO configuration set to include all possible asset entry points and synced via Git. AdobeRGB, ACES, sRGB, ProPhoto, or any other needed spaces should have configurations defined for data acquisition. A Git branch could be set up with only the OCIO configurations in order to keep all studios in sync with the main development, requiring only layering in custom profiles for each workstation.

Different Teams Making Color Critical Adjustments to Data

Teams should attempt to not adjust data between team boundaries when possible. When not possible, it is important that all data transformations are known and applied using the correct transforms as outlined in the OCIO configuration set.

If color critical work is required, it is mandatory that the team have a hardware colorimeter and use a custom profile for each workstation that color critical work is being performed on, and adhere to a reasonable process.

Elevate Color Knowledge and Awareness

A group meeting would be wise early in pre-production to highlight all color critical areas and needs. A point person should be assigned for color issues through the project.