imageworks/opencolorio-configs

Color Configurations for OpenColorIO

opencolorio-configs's Issues

Update Nuke-default to preserve a greater dynamic range

the srgb transform should preserve a greater range of values on the high end, than just 1.2

http://groups.google.com/group/ocio-users/browse_thread/thread/e8ad20e837733e74

bright colors rendered with ACES OCIO-Config v1.0.3 don't match ACES CTLRENDER

Using ACES OCIO-Config v.1.0.3 to render ACES ST2065-1 AP0 EXR files to Output-REC709 does not seem to match the result of CTLRENDER. The bright ACES colors stay saturated and colorful in the OCIO-Config render, while in the CTLRENDER the bright ACES colors desaturate to white.

The differences are visible when processing the ACES-dev test image syntheticChart.01.exr which contains bright colors. See the snip below that shows the rendered output differences:

I used the following OCIO command-line to make the above example image using the OCIO-Config:

export OCIO=./ocio/aces_1.0.3/config.ocio

ocioconvert  ./input/syntheticChart.01.exr "ACES - ACES2065-1" ./output/syntheticChart.01.exr.OutputRE709.tif "Output - Rec.709"

I used the following CTLRENDER command-line to make the above example image using CTLRENDER:

ctlrender -force -ctl RRT.ctl -ctl ODT.Academy.Rec709_100nits_dim.ctl syntheticChart.01.exr -format tiff16 syntheticChart.01.ctl_render_to_rec709.tif`

I've also replicated the same OCIO result using the OCIO-Config ACES 1.0.3 built into Nuke 11.1, and also using the "baked" LUT Rec.709 for ACES2065-1 Maya.csp that is included in the folder /aces_1.0.3/baked/maya

I've also replicated the same CTLRENDER result using the built-in ACES workflow in Resolve 14.

To further confirm and research this issue, I made some test pattern images with RGB color-cube sweeps from -12 to +12 stops centered on mid-gray 0.18, and used OCIO and CTLRENDER to render Output-Rec709 using command-lines similar to what is described above. Rendering of these test patterns also shows the differences in rendering output of bright colors. Some examples are shown below with OCIO render on the left-side and CTLRENDER on the right-side.

-12 to +12 stops sweep in Red/Green with Blue=0.18 (OCIO on left CTLRENDER on right)

-12 to +12 stops sweep in Red/Blue with Green=0.18 (OCIO on left CTLRENDER on right)

-12 to +12 stops sweep in Green/Blue with Red=0.18 (OCIO on left CTLRENDER on right)

Below are DropBox links to zips containing the input EXR test patterns I created to generate the above images, and the resulting TIF renders from OCIO-Config ACES 1.0.3 using Nuke 11.1 and CTLRENDER represented by the above images:

EXR -12 to +12 RGB cube sweeps

OCIO Output-Rec709 render of EXR -12 to +12 RGB cube sweeps

CTLRENDER Rec709 render of EXR -12 to +12 RGB cube sweeps

"nan" (not a number) in InvRRT-ODT spi3d files

The value "nan" (not a number) appears in several inverse-RRT-ODT LUT files included in the ACES 1.03 OCIO Config:
'nan' appears 56534 times in InvRRT.P3-D60_ST2084__1000_nits_.Dolby_PQ_1000_nits_Shaper.spi3d
'nan' appears 45137 times in InvRRT.P3-D60_ST2084__2000_nits_.Dolby_PQ_2000_nits_Shaper.spi3d
'nan' appears 36663 times in InvRRT.P3-D60_ST2084__4000_nits_.Dolby_PQ_4000_nits_Shaper.spi3d
'nan' appears 49458 times in InvRRT.Rec.2020_ST2084__1000_nits_.Dolby_PQ_1000_nits_Shaper.spi3d

The first entry in the above four LUT files (on line 4 of each spi3d file) corresponding to input value 0 0 0 has output value nan nan nan, line 4 of those files looks like the following line:
0 0 0 nan nan nan
There are thousands of other lines in these files that also have nan output values.

If the display-referred input image to be processed by the inverse RRT-ODT LUT contains pure-black pixel value [0 0 0], which is of course very common, then the result of the output of the LUT is nan. This results in undefined/application-specific output. When using NUKE 11v1's built-in OCIO ACES v1.0.3 config, the value of these [0 0 0] input value is black and is shown as nan in the viewer's pixel sniffer and but it is rendered as max-white in the viewer and resulting output files.

Replacing "nan" with 0 in the above spi3d files leads to the expected result of black input values rendering back out to black output values. There may be better values to use instead of replacing nan with 0, but replacing with 0 fixed the nasty artifact to let me proceed with the project I'm working on.

The snip below shows an image processed with released ACES v1.03 LUTs containing "nan" (on the left side) and the same image processed by the same set of ACES v1.03 OCIO-Config LUTs but with the "nan" values replaced with 0.

About culling down ACES versions.

I would be keen on discussing about potentially removing the various ACES config versions in the ImageWorks repository and keep a single one that would maybe be a git-submodule hosted on an AMPAS dedicated repository.

@aforsythe, @scoopxyz, @lgritz (and anybody interested) any thoughts?

Github download speed at 50kb/s

Is there a way to download this outside github? A mirror? Thanks.

Alternative to Log2 shaper for aces Output colorspaces

The current use of Log2_48_nits_Shaper_to_linear.spi1d as the Output colorspace shaper has been problematic in our limited use of it at Imageworks. Particularly in animation, really saturated pixels with components well outside the [~0, ~16] input range are clipped, resulting in artifacts.

Instead we use an ACEScct shaper in our own aces configs, which performs very well in the same edge cases. I know other studios have made similar choices, or used another alternative shaper.

For future versions of the aces config (1.1, etc.), it would be worth considering an alternative. If example images are needed for stress testing, I could see about providing some.

Someone decided that Zero before Minizip-ng Version build definition is a good idea. Now we have 8 in octal number and error in compilation.

I guess minizip-ng support was added before minizip-ng become 3.0.8 and compilation had no issues. Now when MZ is 3.0.8 compiling give an error.

/* MZ_VERSION */
#define MZ_VERSION                      ("3.0.8")
#define MZ_VERSION_BUILD                (030008)

#if MZ_VERSION_BUILD >= 040000

Zero on start treat octal number and 8 is not the digit that can be in such numbers

convert RGB TO CMKY

how could i use openColorIO convert a image from RGB to CMKY?

The Future of OpenColorIO-Configs

We're starting this issue to publicly discuss the future of this repository. There has been a fair amount of discussion on this topic within the OCIO TSC, and with ACES leadership, and we need to put a plan into action as soon as possible. Here's where we stand currently:

• We intend to create one or more new OpenColorIO-Configs repos under the ASWF GitHub organization.
• The new repo(s) will be a clean start, and not a continuation of this repo or its history.
• The new repo(s) will use the same BSD-3-Clause license that OCIO uses, and all contributions will be made under that license, and adhering to the same CLA/DSO rules that OCIO contributors adhere to.
• This repo will be archived, making it read-only, and with a clear message pointing visitors to the new repo(s).
• The first new config will be a new ACES config, built on top of OCIO v2 features, with minimal LUT dependencies (it can mostly be self-contained now).
• The new ACES config would be maintained by OCIO contributors, in cooperation with ACES, as an official OCIO ACES implementation, and hopefully part of an application to join the ACES logo program.
• We may create a dedicated working group to oversee the design and maintenance of the ACES config, with a dedicated chair.
• The goal is to have this config ready to ship with OCIO v2 later in the year.
• We hope also that there would be opportunity for the OCIO community, both studios and individuals, to contribute additional OCIO configs to a repo, both for public use, and as modern OCIO production examples.
• Another goal is to not have large LUTs stored in the repo, but generated as a CI/CD process if needed. The "code" would entail config generation packages/modules, and possibly the generated config files. Complete config packages would be available for easy download as build artifacts.

That all puts us in the right direction to make some progress, but there are some decisions to be made to get started. To be discussed first (there is MUCH more to discuss, but let's focus on these topics initially):

• Should we create one new repo with some strategic means of releasing sub-packages independently (i.e. like this current repo, but supporting versioned releases per config instead of for the repo as a whole), or should we create a repo per config to isolate each config's history and releases?
• What should the naming scheme of these repos be?

Mismatch in the Canon BT.2020 Tungsten matrix

OpenColorIO-Configs/aces_1.0.3/python/aces_ocio/colorspaces/canon.py

Line 228 in 84425e4

0.014560161, 0.028562057, 1.014001897, 0,

The second coefficient here is +0.028562057, but it is -0.028562057 in the Canon CTL file.
aces[2] = 0.014560161 * lin[0] - 0.028562057 * lin[1] + 1.014001897 * lin[2];

ST2048 -> ST2084 typo in the README.md ?

https://github.com/imageworks/OpenColorIO-Configs/search?q=ST2048&unscoped_q=ST2048

Would it be ST2084 instead of ST2048 ?

In the related ocio config files:

    - !<View> {name: P3-D60 ST2084 1000 nits, colorspace: Output - P3-D60 ST2084 (1000 nits)}