OCIO config building Sink

· OCIO for config Authors · OCIO building from source · OCIO · CG · #note/sink ·

If you want to try out the new OpenColorIO v2 features, you'll need to build from source

Windows build

While build environments may vary between user, here is an example batch file for compiling on Windows as provided by @hodoulp:

@echo off


REM Grab the repo name, default is ocio
set repo_name=ocio
if not %1.==. set repo_name=%1


REM Using cygwin to have Linux cool command line tools
set CYGWIN=nodosfilewarning

set CMAKE_PATH=D:\OpenSource\3rdParty\cmake-3.12.2
set GLUT_PATH=D:\OpenSource\3rdParty\freeglut-3.0.0-2
set GLEW_PATH=D:\OpenSource\3rdParty\glew-1.9.0
set PYTHON_PATH=C:\Python27

REM Add glut & glew dependencies to have GPU unit tests
set PATH=%GLEW_PATH%\bin;%GLUT_PATH%\bin;D:\Tools\cygwin64\bin;%CMAKE_PATH%\bin;%PATH%

REM Add Ninja & jom to speed-up command line build i.e. one is enough
set PATH=D:\OpenSource\3rdParty\ninja;D:\OpenSource\3rdParty\jom;%PYTHONPATH%;%PATH%

call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64
REM call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Auxiliary\Build\vcvarsall.bat" x64

set OCIO_PATH=D:\OpenSource\%repo_name%

D:

IF NOT EXIST %OCIO_PATH% (
echo %OCIO_PATH% does not exist
exit /b
)
cd %OCIO_PATH%


set CMAKE_BUILD_TYPE=Release

echo *******
echo *********************************************
echo ******* Building %OCIO_PATH%
echo **
echo **
set are_you_sure = Y
set /P are_you_sure=Build in %CMAKE_BUILD_TYPE% ([Y]/N)?
if not %are_you_sure%==Y set CMAKE_BUILD_TYPE=Debug


set BUILD_PATH=%OCIO_PATH%\build_rls
set COMPILED_THIRD_PARTY_HOME=D:/OpenSource/3rdParty/compiled-dist_rls
set OCIO_BUILD_PYTHON=1

if not %CMAKE_BUILD_TYPE%==Release (
set BUILD_PATH=%OCIO_PATH%\build_dbg
set COMPILED_THIRD_PARTY_HOME=D:/OpenSource/3rdParty/compiled-dist_dbg
set OCIO_BUILD_PYTHON=0
)

set INSTALL_PATH=%COMPILED_THIRD_PARTY_HOME%/OpenColorIO-2.0.0

IF NOT EXIST %BUILD_PATH% ( mkdir %BUILD_PATH% )
cd %BUILD_PATH%

echo **
echo **

REM cmake -G "Visual Studio 14 2015 Win64"
REM cmake -G "Visual Studio 15 2017 Win64"
REM cmake -G "Ninja"
cmake -G "NMake Makefiles JOM" ^
    -DCMAKE_BUILD_TYPE=%CMAKE_BUILD_TYPE% ^
    -DCMAKE_INSTALL_PREFIX=%INSTALL_PATH% ^
    -DBUILD_SHARED_LIBS=ON ^
    -DOCIO_BUILD_APPS=ON ^
    -DOCIO_BUILD_TESTS=ON ^
    -DOCIO_BUILD_GPU_TESTS=ON ^
    -DOCIO_BUILD_DOCS=OFF ^
    -DOCIO_USE_SSE=ON ^
    -DOCIO_WARNING_AS_ERROR=ON ^
    -DOCIO_BUILD_PYTHON=%OCIO_BUILD_PYTHON% ^
    -DPython_LIBRARY=%PYTHON_PATH%\libs\python27.lib ^
    -DPython_INCLUDE_DIR=%PYTHON_PATH%\include ^
    -DPython_EXECUTABLE=%PYTHON_PATH%\python.exe ^
    -DOCIO_BUILD_JAVA=OFF ^
    -DCMAKE_PREFIX_PATH=%COMPILED_THIRD_PARTY_HOME%\OpenImageIO-1.9.0;%COMPILED_THIRD_PARTY_HOME%/ilmbase-2.2.0 ^
    %OCIO_PATH%

REM Add OCIO & OIIO
set PATH=%BUILD_PATH%\src\OpenColorIO;%INSTALL_PATH%\bin;%COMPILED_THIRD_PARTY_HOME%\OpenImageIO-1.9.0\bin;%PATH%


REM Find the current branch
set GITBRANCH=
for /f %%I in ('git.exe rev-parse --abbrev-ref HEAD 2^> NUL') do set GITBRANCH=%%I

if not "%GITBRANCH%" == ""  prompt $C%GITBRANCH%$F $P$G

TITLE %repo_name% (%GITBRANCH%)

echo *******
echo *********************************************
if not "%GITBRANCH%" == "" echo branch  = %GITBRANCH%
echo *
echo Mode         = %CMAKE_BUILD_TYPE%
echo Build path   = %BUILD_PATH%
echo Install path = %INSTALL_PATH%
echo *
echo compile = jom all
echo test    = ctest -V
echo doc     = jom doc
echo install = jom install
echo *********************************************
echo *******

You could create a desktop shortcut with the following command:
%comspec% /k "C:\Users\hodoulp\ocio.bat" ocio
Also look to the Appveyor config script at the root of repository for an example build sequence.

From chat with Saul

its not that easy, you also would need to convert the icc profile to ACES and so on

RGB colourspace transformation matrices

https://www.colour-science.org:8010/apps/rgb_colourspace_transformation_matrix
and primaries https://www.colour-science.org:8010/apps/rgb_colourspace_chromatically_adapted_primaries

Adobe RGB - CIE XYZ transform

https://en.wikipedia.org/wiki/Adobe_RGB_color_space

mechanics/definitions

IDT - input device transform - is the import/conversion of the textures/images/renders to the ACEScg colorspace

RRT - Rendering Reference Transform
The RRT converts raw scene-linear data into linear HDR display-referred data in preparation to be used with an ODT. This is a step that is performed automatically in the background whenever an ODT is used and is necessary to convert from the rawzlinear output into a color space suitable for conversion into the final display space for monitors.

ODT - output device transform

from OCIO, Display Transforms and Misconceptions#The importance of terminology
I'll start here with a bit of OCIO vocabulary, so we're all on the same page :

in Redshift
Display
This is the Output Display Transform that should be set to a color space that is supported by the display that you are working on, for most people this will be sRGB.

View
This determines how the image is displayed on screen and works in conjunction with the Display transform. By default this can be set to an ACES SDR tone-mapped result, un-tone-mapped, a logarithmic color space (ACEScct) or the raw linear result which is unaffected by the Display transform.

from OCIO, Display Transforms and Misconceptions#BT 709 and BT 1886

from OCIO, Display Transforms and Misconceptions#Custom Display Rendering Primaries experiment
Here is the list of operations:

And for clarity, this beautiful quote:

The working space (primaries) and the Display Rendering Transform need to be considered together.

display_colorspaces:

# The Display Colorspaces are another new OCIO v2 feature.  These are like traditional colorspaces
# but are defined in relation to a display-referred reference space rather than a scene-referred space.
# One of the benefits of this is that a ColorSpaceTransform may now convert between a pair of display
# colorspaces (e.g., from Rec.709 to sRGB) without needing to invert a tone-map all the way back to
# the scene-referred reference space.
#
display_colorspaces:

example (notice 2 items style)

 - !<ColorSpace>
    name: Rec.2100-PQ
    family: Displays/HDR
    description: |
      Rec.2100-PQ monitor with Rec.2020 primaries and ST-2084 EOTF
    isdata: false
    categories: [ file-io, advanced-3d, basic-2d, advanced-2d ]
    encoding: hdr-video
    from_display_reference: !<GroupTransform>
      children:
        - !<BuiltinTransform> {style: "DISPLAY - CIE-XYZ-D65_to_REC.2100-PQ"}
        - !<RangeTransform> {min_in_value: 0., min_out_value: 0., max_in_value: 1., max_out_value: 1.}

view_transforms:

# This section of the config defines the View Transforms.  A View Transform is a transform that
# converts between the scene-referred reference space and the display-referred reference space
# (which is new in OCIO v2).  The View Transform is sometimes referred to by other names in
# various color science documents.  For example, in [[ACES]] it is called a "rendering" and in the
# ITU standards for HDR television it is called an Opto-Optical Transfer Function (OOTF).  It
# is also commonly referred to as a "tone-map".  This is typically where the S-shape curve that
# avoids clipped highlights is applied, along with other adjustments necessary to adopt the
# latest color science best-practices.
#
view_transforms:

example (notice 3 items style)

 - !<ViewTransform>
    name: ACES 1.0 SDR-video
    description: |
      [[ACES]] Output Transform for SDR displays in a video viewing environment. [[ACES]] neutrals are at D65.
    from_scene_reference: !<BuiltinTransform> {style: "ACES-OUTPUT - ACES2065-1_to_CIE-XYZ-D65 - SDR-VIDEO_1.0"}