PageRenderTime 87ms CodeModel.GetById 67ms app.highlight 12ms RepoModel.GetById 2ms app.codeStats 0ms

/docs/FAQ.rst

http://github.com/imageworks/OpenColorIO
ReStructuredText | 147 lines | 115 code | 32 blank | 0 comment | 0 complexity | b959e92ff9a52d3d658c1222e59d6c6a MD5 | raw file
  1..
  2  SPDX-License-Identifier: CC-BY-4.0
  3  Copyright Contributors to the OpenColorIO Project.
  4
  5.. _faq:
  6
  7FAQ
  8===
  9
 10License?
 11********
 12
 13New BSD.
 14
 15You are welcome to include the OpenColorIO in commercial, or open source
 16applications. See the :ref:`license` for further details.
 17
 18
 19.. _faq-terminology:
 20
 21Terminology
 22***********
 23
 24- Transform - a function that alters RGB(A) data (e.g transform an image from scene linear to sRGB)
 25- Reference space - a space that connects colorspaces
 26- Colorspace - a meaningful space that can be transferred to and from the reference space
 27- Display - a virtual or physical display device (e.g an sRGB display device)
 28- View - a meaningful view of the reference space on a Display (e.g a film emulation view on an sRGB display device)
 29- Role - abstract colorspace naming (e.g specify the "lnh" colorspace as the scene_linear role, or the color-picker UI uses color_picking role)
 30- Look - a color transform which applies a creative look (for example a per-shot neutral grade to remove color-casts from a sequence of film scans, or a DI look)
 31
 32.. _faq-supportedlut:
 33
 34What LUT Formats are supported?
 35*******************************
 36
 37=========  ===================================  ===============================
 38Ext        Details                              Notes
 39=========  ===================================  ===============================
 403dl        Autodesk Apps: Lustre, Flame, etc.   Read + Write Support.
 41           Supports shaper LUT + 3D
 42ccc        ASC CDL ColorCorrectionCollection    Full read support.
 43cc         ASC CDL ColorCorrection              Full read support.
 44csp        Cinespace (Rising Sun Research)      Read + Write Support.  Shaper is
 45           LUT. Spline-based shaper LUT, with   resampled into simple 1D LUT
 46           either 1D or 3D LUT.                 with 2^16 samples.
 47cub        Truelight format. Shaper Lut + 3D    Full read support.
 48cube       Iridas format. Either 1D or 3D Lut.  Full read support
 49hdl        Houdini. 1D Lut, 3D lut, 1D shaper   Only 'C' type is supported.
 50           Lut                                  Need to add R G B A RGB RGBA ALL.
 51                                                No support for Sampling tag.
 52                                                Header fields must be in strict order.
 53look       IRIDAS .look                         Read baked 3D LUT embedded in file.
 54                                                No mask support.
 55mga/m3d    Pandora 3D lut                       Full read support.
 56spi1d      1D format. Imageworks native 1D      Full read support.
 57           lut format.  HDR friendly, supports
 58           arbitrary input and output domains
 59spi3d      3D format. Imageworks native 3D      Full read support.
 60           lut format.
 61spimtx     3x3 matrix + color offset.           Full read support.
 62           Imageworks native color matrix
 63           format
 64vf         Inventor 3d lut.                     Read support for 3d lut data
 65                                                and global_transform element
 66=========  ===================================  ===============================
 67
 68.. note::
 69   Shaper LUT application in OCIO currently only supports linear interpolation.
 70   For very small shaper LUT sizes this may not be sufficient. (CSP shaper luts
 71   excluded; they do use spline interpolation at load-time).
 72
 73
 74Can you query a color space by name (like "Rec709") and get back XYZ coordinates of its primaries and whitepoint?
 75*****************************************************************************************************************
 76
 77Not currently.
 78
 79OCIO is a color configuration 'playback' tool that tries to be as flexible as possible;
 80color information such as this is often only needed / relevant at configuration authoring time.
 81Making primaries / whitepoint required would limit the pipeline OCIO could service. In the
 82strictest sense, we would consider OCIO to be a 'baked' representation of color processes,
 83similar to how Alembic files do not store animation rig data, but rather only the baked geometry.
 84
 85Also, remember that not all colorspaces using in visual effects even have strongly
 86defined color space definitions. For example, scanned film negatives,  when linearized with
 871d transfer curves (the historical norm in vfx), do not have defined primaries/white point.
 88Each rgb value could of course individually be tied to a specific color, but if you were to
 89do a sweep  of the pure 'red channel', for example, you'd find that it creates a curves in
 90chromaticity space, not a single point.  (This is due to the 1d linearization not attempting
 91to undo the subtractive processes that created the pixels in the first place.
 92
 93But many color spaces in OCIO *do* have very strongly defined white points/chromaticities.
 94On the display side, for example, we have very  precise information on this.
 95
 96Perhaps OCIO should include optional metadata to tag outputs?  We are looking at this as
 97as a OCIO 1.2 feature.
 98
 99Can you convert XYZ <-> named color space RGB values?
100*****************************************************
101
102OCIO includes a MatrixTransform, so the processing capability is there. But there is no convenience
103function to compute this matrix for you. (We do include other Matrix convenience functions though,
104so it already has a place to be added. See MatrixTransform in export/OpenColorTransforms.h)
105
106There's talk of extended OCIO 1.2 to have a plugin api where colorspaces could be dynamically
107added at runtime (such as after reading exr  chromaticity header metadata).  This would
108necessitate adding such a feature.
109
110
111What are the differences between Nuke's Vectorfield and OCIOFileTransform?
112**************************************************************************
113
114(All tests done with Nuke 6.3)
115
116=========  =============================================   ===============================
117Ext        Details                                         Notes
118=========  =============================================   ===============================
1193dl        Matched Results
120ccc        n/a
121cc         n/a
122csp        *Difference*                                    Gain error. Believe OCIO is correct, but need to verify.
123cub        Matched Results                                 Note: Nuke's .cub exporter is broken (gain error)
124cube       Matched Results
125hdl        n/a
126mga/m3d    n/a
127spi1d      n/a
128spi3d      n/a
129spimtx     n/a
130vf         *Difference*                                    Gain error. Believe OCIO is correct, but need to verify.
131=========  =============================================   ===============================
132
133All gain differences are due to a common 'gotcha' when interpolating 3d luts, related to
134internal index computation. If you have a 32x32x32 3dlut, when sampling values from (0,1)
135do you internally scale by 31.0 or 32.0?  This is typically well-defined for each format,
136(in this case the answer is usually 31.0) but when incorrectly handled in an application,
137you occasionally see gain errors that differ by this amount. (In the case of a 32-sized
1383dlut, 32/31 = ~3% error)
139
140
141What do ColorSpace::setAllocation() and ColorSpace::setAllocationVars() do?
142***************************************************************************
143
144These hints only come into play during GPU processing, and are used to determine proper
145colorspace allocation handling for 3D LUTs. See this page :ref:`allocationvars` for
146further information.
147