On Sun, Feb 23, 2020 at 05:04 PM, Jean-Francois Panisset wrote:

Autodesk Maya got OCIO support in version 2016 (I believe Autodesk SynColor color management system can read OCIO configurations?), May 2016:

 

https://knowledge.autodesk.com/support/maya/learn-explore/caas/CloudHelp/cloudhelp/2016/ENU/Maya/files/GUID-C22F815A-8390-405B-BA50-74FEC42C75E0-htm.html

Yes. Maya supports OCIO i.e. the synColor engine reads any OCIO config files.

Some softwares have added OpenColorIO support which are not being reflected in https://opencolorio.org/CompatibleSoftware.html . Can anyone suggest me all the softwares, libraries and DCCs which support OCIO?

_._,_._,_

Please add mrViewer which is a professional flipbook player, hdri viewer and video/audio playback tool.  It supports OCIO input color spaces in images as well as display/view color spaces.

I am the developer of PhotoFlow (https://github.com/aferrero2707/PhotoFlow), and editor for RAW image files. It supports OCIO via a dedicated tool that can load a given configuration and apply the available color transforms. So far the tool has been tested it with the Filmic (https://github.com/sobotka/filmic-blender) and ACES (https://opencolorio.org/configurations/aces_1.0.3.html) configs.

Some softwares have added OpenColorIO support which are not being reflected in https://opencolorio.org/CompatibleSoftware.html . Can anyone suggest me all the softwares, libraries and DCCs which support OCIO?

Cancelled: OpenColorIO TSC meeting (weekly)

This event has been cancelled.

When:
Monday, 17 February 2020
9:30am to 10:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Description:
Weekly meeting of the OpenColorIO TSC.

Add topics to the meeting agenda.

Meeting notes listed by YYYY-MM-DD.md format at: 
https://github.com/imageworks/OpenColorIO/tree/master/docs/tsc/meetings

Join Zoom Meeting
https://zoom.us/j/924729729

One tap mobile
+16699006833,,924729729# US (San Jose)
+16465588656,,924729729# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj

Hi Doug,

Thank you for the info. I tried P3D65 from ACES1.1, but it uses a gamma of 2.6, rather than the sRGB gamma of the iMac P3 displays, so in the end, I modified the ACES configs, creating a new entry based on P3D65, with an additional gamma correction. I will check with ACESCentral if Mac support could be added into future versions.

Thanks,

Patrik

I am starting to adopt ACES1.0.3, and have a question about the iMac P3 displays. Most people seem to use ACES sRGB for viewing, but this is quite different from the display P3 color space. What display transform would be correct to use on an iMac?

Cancelled: OpenColorIO TSC meeting (weekly)

This event has been cancelled.

When:
Monday, 30 December 2019
9:30am to 10:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Description:
Weekly meeting of the OpenColorIO TSC.

Add topics to the meeting agenda.

Meeting notes listed by YYYY-MM-DD.md format at: 
https://github.com/imageworks/OpenColorIO/tree/master/docs/tsc/meetings

Join Zoom Meeting
https://zoom.us/j/924729729

One tap mobile
+16699006833,,924729729# US (San Jose)
+16465588656,,924729729# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj

Cancelled: OpenColorIO TSC meeting (weekly)

This event has been cancelled.

When:
Monday, 23 December 2019
9:30am to 10:00am
(UTC-08:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Description:
Weekly meeting of the OpenColorIO TSC.

Add topics to the meeting agenda.

Meeting notes listed by YYYY-MM-DD.md format at: 
https://github.com/imageworks/OpenColorIO/tree/master/docs/tsc/meetings

Join Zoom Meeting
https://zoom.us/j/924729729

One tap mobile
+16699006833,,924729729# US (San Jose)
+16465588656,,924729729# US (New York)

Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 646 558 8656 US (New York)
        +1 877 369 0926 US Toll-free
        +1 855 880 1246 US Toll-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj

On 7/12/19 17:41, Gonzalo Garramuño via Lists.Aswf.Io wrote:

It is clear the RED SDK does some magic behind the scenes, but it isn't clear to me what or why.

Okay, I found out what magic it is.  The R3DSDK has an ImageProcessing struct and I was not setting it.  Once I set it to the camera settings, everything started to match.  Note that besides the camera settings there is the RMD sidecar settings which Nuke can load with Load RMD.  By default, with no image settings set, the RMD file is used.  That's why I was not matching at all.

Now, all is good with all RED files I tried.

--
Gonzalo Garramuño

On 7/12/19 15:26, Gonzalo Garramuño via Lists.Aswf.Io wrote:

When using the ACES config file, the sRGB/rec709 (ACES) are darker due to the RRT+ODT issue as you pointed out before, so I get a darker image instead of a brighter one, following a similar approach to setting the input to scene linear.

Okay, here's a crazy one.  If I decode the R3D clip as 16 bit, and I set the input color space to Output - Rec.709 and set the view to Rec.709, I get a matching picture to the one you saved out from Nuke12.

It is clear the RED SDK does some magic behind the scenes, but it isn't clear to me what or why.

On 7/12/19 04:38, Eberhard Hasche wrote:

Hi Gozalo,

good to hear that it is going better!

The OCIOColorSpace Node in then ACES script is only for demonstration and debugging sake.
You don’t need it in production.

Glad to know.

When you set the Input (IDT) in the Read node correctly and view the Read node with the Viewer
set to Rec.709 (ACES) at one hand – or viewing the OCIOColorSpace node and set the Viewer to Raw (ACES) on the other should generate the same result.

Currently, I cannot get the same result with the sRGB/rec709 of ACES.  I get a close to good, but darker  and more saturated image, as I got with exrs.  This is the issue with the RRT+ODT.

I don't need to set the color space to Input - Red - RedLog3G10 - RedWideGamutRGB as that is created by the RED SDK automatically when I load the .r3d file as a half float image.   That's what I meant by not using the middle node in the nuke default script (the matrix transform you had) and instead using a scene linear setting for the input.  With that, I got it to match the output you were getting from Nuke12.

When using the ACES config file, the sRGB/rec709 (ACES) are darker due to the RRT+ODT issue as you pointed out before, so I get a darker image instead of a brighter one, following a similar approach to setting the input to scene linear.

Not sure if I am explaining myself properly.

Hi Gozalo,

good to hear that it is going better!

The OCIOColorSpace Node in then ACES script is only for demonstration and debugging sake.
You don’t need it in production.

When you set the Input (IDT) in the Read node correctly and view the Read node with the Viewer
set to Rec.709 (ACES) at one hand – or viewing the OCIOColorSpace node and set the Viewer to Raw (ACES) on the other should generate the same result.

Accordingly, with the Write node: Writing out the imagery directly after the Read node with a Write node, set to Output - Rec. 709
should produce the same result as writing out the images after the OCIOColorspace node with a Write node, set to Utility - Raw.

The middle Clamp node in the Nuke default script has the only purpose to clamp down values above 1.0,
to avoid potential problems and misinterpretations down the line.
It should work fine without it, but who knows where the imagery is going to.

Cheers

Eberhard

----- Ursprüngliche Mail -----
Von: "Gonzalo Garramuño" <ggarra13@...>
An: "ocio-dev" <ocio-dev@...>
Gesendet: Samstag, 7. Dezember 2019 03:41:32
Betreff: Re: [ocio-dev] nuke-default's sRGB and ACES 1.1 sRGB

On 6/12/19 13:02, Eberhard Hasche wrote:

Hi Gonzalo,
maybe you should consider that something in your pipeline is broken.

I tried your file out and all worked fine. Attached are two Nuke files (one ACES 1.1, the other
Nuke default) with all necessary color conversion nodes.
I rendered out two 1/8th resolution jpg images set to Rec709. The only difference in the color pipeline is that with the nuke-default image,
the picture-rendering part is missing, so it is clamped at 1.o whereas the
aces image is a bit brighter because parts of the luminance above 1.o has been rolled in.


cheers

Eberhard

Dear Eberhard,

I can confirm that the Nuke default one is matching my version
completely, but without the middle node that you have in the Nuke
script.  The RED SDK it seems already sends a half image with
RedWideGamutRGB baked in when you request a HalfFloat image buffer.  So
for the nuke-default to work, I had to set scene-linear and my view to
sRGB/Rec709.

Now, for the ACES pipeline, I am still struggling with it as it seems I
may need an additional transform node as you have in the nuke script,
which is not trivial as my viewer only accepts an image transform and a
display/view transform.

Thank you very much for the Nuke scripts, btw.  I had to download a demo
of nuke but it was worth it.

On 6/12/19 13:02, Eberhard Hasche wrote:

Hi Gonzalo,
maybe you should consider that something in your pipeline is broken.

I tried your file out and all worked fine. Attached are two Nuke files (one ACES 1.1, the other
Nuke default) with all necessary color conversion nodes.
I rendered out two 1/8th resolution jpg images set to Rec709. The only difference in the color pipeline is that with the nuke-default image,
the picture-rendering part is missing, so it is clamped at 1.o whereas the
aces image is a bit brighter because parts of the luminance above 1.o has been rolled in.


cheers

Eberhard

Dear Eberhard,

I can confirm that the Nuke default one is matching my version completely, but without the middle node that you have in the Nuke script.  The RED SDK it seems already sends a half image with RedWideGamutRGB baked in when you request a HalfFloat image buffer.  So for the nuke-default to work, I had to set scene-linear and my view to sRGB/Rec709.

Now, for the ACES pipeline, I am still struggling with it as it seems I may need an additional transform node as you have in the nuke script, which is not trivial as my viewer only accepts an image transform and a display/view transform.

Thank you very much for the Nuke scripts, btw.  I had to download a demo of nuke but it was worth it.

Hi Gonzalo,
maybe you should consider that something in your pipeline is broken.

I tried your file out and all worked fine. Attached are two Nuke files (one ACES 1.1, the other
Nuke default) with all necessary color conversion nodes.
I rendered out two 1/8th resolution jpg images set to Rec709. The only difference in the color pipeline is that with the nuke-default image,
the picture-rendering part is missing, so it is clamped at 1.o whereas the
aces image is a bit brighter because parts of the luminance above 1.o has been rolled in.


cheers

Eberhard

----- Ursprüngliche Mail -----
Von: "Gonzalo Garramuño" <ggarra13@...>
An: "ocio-dev" <ocio-dev@...>
Gesendet: Freitag, 6. Dezember 2019 11:22:37
Betreff: Re: [ocio-dev] nuke-default's sRGB and ACES 1.1 sRGB

On 6/12/19 03:16, Eberhard Hasche wrote:

Hi Gonzalo,

strange!

It is interesting. Maybe there is a look buried in the MetaData i. e. a tinting
or some white point problem.
May you give me the link to the RED-file?

Cheers

Eberhard

It happens with any RED file, but if you want one to try, try the first
clip (the one with the guy in the motorcycle) from the sample 3d files:

http://downloads.red.com.s3.amazonaws.com/sample-r3d-files/w8kvv-sth-48fps-10to1redcode_FF.RDC.zip

When I decompress it as HalfFloat and try the Log* WideGamutRGB, I get a
posterized look.  When I decompress it as 16bit short, I get a better
but too dark image.

On 6/12/19 03:16, Eberhard Hasche wrote:

Hi Gonzalo,

strange!

It is interesting. Maybe there is a look buried in the MetaData i. e. a tinting
or some white point problem.
May you give me the link to the RED-file?

Cheers

Eberhard

It happens with any RED file, but if you want one to try, try the first clip (the one with the guy in the motorcycle) from the sample 3d files:

http://downloads.red.com.s3.amazonaws.com/sample-r3d-files/w8kvv-sth-48fps-10to1redcode_FF.RDC.zip

When I decompress it as HalfFloat and try the Log* WideGamutRGB, I get a posterized look.  When I decompress it as 16bit short, I get a better but too dark image.

Hi Gonzalo,

strange!

It is interesting. Maybe there is a look buried in the MetaData i. e. a tinting
or some white point problem.
May you give me the link to the RED-file?

Cheers

Eberhard


----- Ursprüngliche Mail -----
Von: "Gonzalo Garramuño" <ggarra13@...>
An: "ocio-dev" <ocio-dev@...>
Gesendet: Donnerstag, 5. Dezember 2019 22:14:46
Betreff: Re: [ocio-dev] nuke-default's sRGB and ACES 1.1 sRGB

On 5/12/19 15:06, Eberhard Hasche wrote:

Hi Gonzalo,

IPP2 is the RED Image Processing Pipeline #2, introduced three or four years ago which is closer to the ACES concept.
If you read in RED footage choose the settings at the attached image in Nuke's Read node and you are on the safe side.
To get those settings in the Read Node color space line choose: (Colorspaces) --> Input --> RED --> REDLog3G10 -
REDWideGamutRGB.


Cheers

Eberhard

Hi Eberhard,

I tried that with my viewer (setting the ocio colorspace input to Input
- RED - REDLog3G10 - REDWideGamutRGB) and set the display/view to
ACES->sRGB and the results were all colors like a Warhol painting :D.  I
must have missed something.

Cheers,
Gonzalo

On 5/12/19 18:14, Gonzalo Garramuño via Lists.Aswf.Io wrote:

On 5/12/19 15:06, Eberhard Hasche wrote:

Hi Gonzalo,

IPP2 is the RED Image Processing Pipeline #2, introduced three or four years ago which is closer to the ACES concept.
If you read in RED footage choose the settings at the attached image in Nuke's Read node and you are on the safe side.
To get those settings in the Read Node color space line choose: (Colorspaces) --> Input --> RED --> REDLog3G10 -
REDWideGamutRGB.


Cheers

Eberhard

Hi Eberhard,

I tried that with my viewer (setting the ocio colorspace input to Input - RED - REDLog3G10 - REDWideGamutRGB) and set the display/view to ACES->sRGB and the results were all colors like a Warhol painting :D.  I must have missed something.

Cheers,
Gonzalo

One thing I noticed is that I get different results in decoding the clips with RED's PixelType_HalfFloat_RGB_Interleaved and PixelType_16Bit_RGB_Interleaved.  The 16 Bit clip seems to be in log space, but none of the RED - Log* transforms works with it.