Date   

Re: Collecting info regarding compatible software list

Thomas Mansencal
 

OCIO support is only partial in UE4, i.e. not first class citizen yet.

On Mon, 24 Feb 2020 at 11:04 AM, Jean-Francois Panisset <panisset@...> wrote:
A few apps in no specific order:

Unreal Engine got OCIO support in version 4.22, released in April 2019:



Mocha Pro 2020 adds OCIO support:


Autodesk Arnold supports OCIO for color management:

https://docs.arnoldrenderer.com/display/A5AFMUG/Color+Management

SideFX Houdini got OCIO support in version 16, Feb 2017:



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


Chaos Group V-Ray has OCIO support, for instance:



Isotropix Clarisse has OCIO support:


JF












On Sun, Feb 23, 2020 at 11:35 AM Carmelo DrRaw <aferrero1975@...> wrote:
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.

Pre-compiled PhotoFlow packages are available from here: https://github.com/aferrero2707/PhotoFlow/releases/tag/continuous

Regards,
Andrea

On Feb 23, 2020, at 8:16 PM, yashagrawal048@... wrote:

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?

--


Re: Collecting info regarding compatible software list

Doug Walker
 

Thanks for pulling that list together JF!

 

Your list was correct relative to the Autodesk products.  (Flame and 3dsMax do not currently support OCIO.)

 

From: <ocio-dev@...> on behalf of Jean-Francois Panisset <panisset@...>
Reply-To: "ocio-dev@..." <ocio-dev@...>
Date: Sunday, February 23, 2020 at 7:45 PM
To: "ocio-dev@..." <ocio-dev@...>
Subject: Re: [ocio-dev] Collecting info regarding compatible software list

 

Probably should add Flame then as well, right? What about 3DS Max?

 

Thanks!

JF


Re: Collecting info regarding compatible software list

Jean-Francois Panisset
 

Probably should add Flame then as well, right? What about 3DS Max?

Thanks!
JF


On Sun, Feb 23, 2020 at 3:51 PM Patrick Hodoul <patrickhodoul@...> wrote:
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:
 
Yes. Maya supports OCIO i.e. the synColor engine reads any OCIO config files.


Re: Collecting info regarding compatible software list

Patrick Hodoul
 

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:
 
Yes. Maya supports OCIO i.e. the synColor engine reads any OCIO config files.


Re: Collecting info regarding compatible software list

Gonzalo Garramuño
 



El 23/02/20 a las 16:16, yashagrawal048@... escribió:
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.


Re: Collecting info regarding compatible software list

Jean-Francois Panisset
 


On Sun, Feb 23, 2020 at 11:35 AM Carmelo DrRaw <aferrero1975@...> wrote:
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.

Pre-compiled PhotoFlow packages are available from here: https://github.com/aferrero2707/PhotoFlow/releases/tag/continuous

Regards,
Andrea

On Feb 23, 2020, at 8:16 PM, yashagrawal048@... wrote:

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?


Re: Collecting info regarding compatible software list

Carmelo DrRaw
 

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.

Pre-compiled PhotoFlow packages are available from here: https://github.com/aferrero2707/PhotoFlow/releases/tag/continuous

Regards,
Andrea

On Feb 23, 2020, at 8:16 PM, yashagrawal048@... wrote:

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?


Collecting info regarding compatible software list

yashagrawal048@...
 

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 Event: OpenColorIO TSC meeting (weekly) - Monday, 17 February 2020 #cal-cancelled

ocio-dev@lists.aswf.io Calendar <ocio-dev@...>
 

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


Re: iMac P3 Display

patrik@...
 

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


Re: iMac P3 Display

Doug Walker
 

This is perhaps more of a question for ACESCentral, but here is some info that may help you:

 

1)  MacOS uses ICC color management for the display.  OCIO is not integrated with that.  So to some extent, the answer to your question will depend on what the application does after calling OCIO.  For example, if the app is telling MacOS that it is an sRGB image, then you would want to use the ACES sRGB Output Transform and MacOS will try to make that look correct on the connected display via the ICC profile (even though it won't take advantage of the whole gamut).  Other apps bypass MacOS color management and so you should use the Output Transform that matches how the monitor is calibrated.  You may want to post on the forum for whatever app you are using for details along these lines.

 

2)  Apple uses P3 primaries with a D65 whitepoint.  ACES 1.0 had P3 Output Transforms with DCI and D60 whitepoints but ACES 1.1 introduced some addiitional P3 Output Transforms with a D65 whitepoint.  These would be closer to the Apple monitor.  However, all the P3 Output Transforms are intended for dark surround, whereas the sRGB Output Transforms (and Rec.709) are for dim surround.  Not sure which is more appropriate for how you are working, but keep in mind there is effectively a slight contrast and saturation difference between them.  If you want a P3 D65 dim surround Output Transform, that would be a request to make on ACESCentral.

 

best,

 

Doug

 

 

From: <ocio-dev@...> on behalf of "patrik@..." <patrik@...>
Reply-To: "ocio-dev@..." <ocio-dev@...>
Date: Wednesday, January 8, 2020 at 12:45 AM
To: "ocio-dev@..." <ocio-dev@...>
Subject: [ocio-dev] iMac P3 Display

 

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?


iMac P3 Display

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 Event: OpenColorIO TSC meeting (weekly) - Monday, 30 December 2019 #cal-cancelled

ocio-dev@lists.aswf.io Calendar <ocio-dev@...>
 

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 Event: OpenColorIO TSC meeting (weekly) - Monday, 23 December 2019 #cal-cancelled

ocio-dev@lists.aswf.io Calendar <ocio-dev@...>
 

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


Re: nuke-default's sRGB and ACES 1.1 sRGB

Gonzalo Garramuño
 

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


Re: nuke-default's sRGB and ACES 1.1 sRGB

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.


Re: nuke-default's sRGB and ACES 1.1 sRGB

Gonzalo Garramuño
 

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.


Re: nuke-default's sRGB and ACES 1.1 sRGB

Eberhard Hasche
 

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@gmail.com>
An: "ocio-dev" <ocio-dev@lists.aswf.io>
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.


Re: nuke-default's sRGB and ACES 1.1 sRGB

Gonzalo Garramuño
 

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.


Re: nuke-default's sRGB and ACES 1.1 sRGB

Eberhard Hasche
 

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@gmail.com>
An: "ocio-dev" <ocio-dev@lists.aswf.io>
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.

261 - 280 of 2154