imageworks / opencolorio-configs Goto Github PK
View Code? Open in Web Editor NEWColor Configurations for OpenColorIO
Home Page: opencolorio.org
Color Configurations for OpenColorIO
Home Page: opencolorio.org
This repository contains all the default color configurations, for use with OpenColorIO. Visit opencolorio.org for additional information.
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
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
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.
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?
Is there a way to download this outside github? A mirror? Thanks.
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.
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
how could i use openColorIO convert a image from RGB to CMKY?
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:
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):
aces[2] = 0.014560161 * lin[0] - 0.028562057 * lin[1] + 1.014001897 * lin[2];
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)}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.