Re: Collecting info regarding compatible software list
On Sun, Feb 23, 2020 at 05:04 PM, Jean-Francois Panisset wrote:
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
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: 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:
|
|
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.
toggle quoted messageShow quoted text
Pre-compiled PhotoFlow packages are available from here: https://github.com/aferrero2707/PhotoFlow/releases/tag/continuous Regards, Andrea
|
|
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: Where: Organizer: Michael Dolan michdolan@... Description: Meeting notes listed by YYYY-MM-DD.md format at: 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@...>
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: Where: Organizer: Michael Dolan michdolan@... Description: Meeting notes listed by YYYY-MM-DD.md format at: 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: Where: Organizer: Michael Dolan michdolan@... Description: Meeting notes listed by YYYY-MM-DD.md format at: 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:
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:
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,Glad to know. When you set the Input (IDT) in the Read node correctly and view the Read node with the ViewerCurrently, 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@...> 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,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,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@...> 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,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.
|
|
Re: nuke-default's sRGB and ACES 1.1 sRGB
Gonzalo Garramuño
On 6/12/19 03:16, Eberhard Hasche wrote:
Hi Gonzalo,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.
|
|
Re: nuke-default's sRGB and ACES 1.1 sRGB
Eberhard Hasche
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,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
|
|
Re: nuke-default's sRGB and ACES 1.1 sRGB
Gonzalo Garramuño
On 5/12/19 18:14, Gonzalo Garramuño via Lists.Aswf.Io wrote:
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.
|
|