OpenColourIO (OCIO) v2 Support

[playername]

Thanks @Chris B

Thankyou, that sounded hopeful as I did have the configs on an external mvne drive connected via Thunderbolt. However, shifting the configs to the User/Documents folder on the Mac Studio's main drive resulted in the Affinity OCIO being seen but having the same issues (no change of image and missing 'slots') and the AGX config I shared with you not being seen at all (all fields for OCIO being blank). Not sure what is going on. I might try a reinstall of Affinity when I get a chance. I do have Affinity V1 also installed on the same volume - would that be an issue?

Cheers

 

[Chris B]

Having V1, Retail builds and or beta's installed on the same volume should not be an issue. You can try a reinstall as it may ask for new permissions as something may have gotten confused there.

I've uploaded a video of what I'm doing. For reference, I'm using an EXR file but I've also tried it on other 32-bit documents.

 

 

[playername]

Hi @Chris B

thanks for sending that video. I think I see the problem. Are you using a beta version of the software? In ash’s original email above it said v2 supported ocio 2 but didn’t mention the need to download a beta. I thought we were just testing it as targeted user of ocio. I see now at the bottom of that email there is a suggestion to join the beta program which I didn’t realise would be a necessary condition. I guess joining would allow me to download that version. Is that right? Can try tomorrow if so. 
Sorry for any misunderstanding that may have caused your developers anguish and added to your workload..
 

[walt.farrell]

17 minutes ago, playername said:

In ash’s original email above it said v2 supported ocio 2 but didn’t mention the need to download a beta.

This entire topic is in the Beta section of the forum, and specifically in the "2.2 New Features and Improvements" section of the forums.

[Chris B]

33 minutes ago, playername said:

Sorry for any misunderstanding that may have caused your developers anguish and added to your workload..

Please don't apologise. If anything, it allowed me to cover this area pretty deeply and we did find a few minor issues so it was worthwhile as far as I'm concerned. 

If you wish to join the beta and trial it, that would be super. Any feedback/issues found before we release may be very useful but it's also fine should you wish to wait until we go to retail  

[playername]

HI @Chris B

I have joined the beta group, installed 2.2 and the update and the Ocio configs seem to be working! Although the config I supplied seems to yield pretty odd results. Let me test those a bit but essentially all seems good. Thank you for your persistence and the developer's work to get Ocio v2 working. 

Thanks Walt for pointing out the location of this forum. As I was led here by a direct link and have not visited the forum at all, I didn't notice it was a dedicated beta section etc. The obvious is not always obvious, to the otherwise engaged. Despite the garden path though, it looks like all is good. Thanks again Chris. 

[Chris B]

1 hour ago, playername said:

Although the config I supplied seems to yield pretty odd results.

Are they appearing washed out at all? 

I just checked the bug reports and we logged an issue where we may be incorrectly doing a bounded transform when importing EXR/HDR documents and converting from the document colour space to scene linear. This can be reproduced with any OCIO config.

[playername]

Hi Chris,

Yes that is mostly it. Very low contrast, washed out images. A couple of options in my config don't seem to do anything at all when adobe RGB is selected - false colour and none in particular (this might be a limitation of that particular config). I also notice in 32 bit preview, that if AGX is selected as source and adobergb as output, the image is almost grey scale and very washed out (see screenshot). Much better with RGB as output, so again, maybe the config. It would be expected for AGX to look a little lower contrast but the results are very extreme. 

Changing the output also causes the Source to default to Guard Rail. Not sure if this is expected/normal behaviour.

Cheers

[playername]

AGX to sRGB for comparision

[playername]

@Chris B Also, don't know if you know this thread and these two guys, you probably do

https://blenderartists.org/t/feedback-development-filmic-baby-step-to-a-v2/1361663/505?page=24

Eary Chow who produced the config I am using and is developing AGX for Blender and Troy Sabotka who is around there too. He wrote Filmic for Blender and wrote AGX to replace it which various folk are refining. They are all over OCIO and color management and are stupid helpful to anyone who asks. I am sure they could/would lend a hand. 

Cheers

[James Ritson]

Hi @playername, there's something else that may be causing your issue: as per the OCIO v2 spec, Photo will now always convert from the document colour space to scene linear (in V1 this was optionally ignored if the EXR filename didn't contain a valid colourspace name appended to it).

In the AgX config file (at least with Troy's main Git repo), we have the following:

ocio_profile_version: 2

environment:
  {}
search_path: LUTs
strictparsing: true
luma: [0.2126, 0.7152, 0.0722]

roles:
  color_picking: sRGB
  color_timing: sRGB
  compositing_log: sRGB
  data: Generic Data
  default: sRGB
  default_byte: sRGB
  default_float: Linear BT.709
  default_sequencer: sRGB
  matte_paint: sRGB
  reference: Linear BT.709
  scene_linear: Linear BT.709
  texture_paint: sRGB

file_rules:
  - !<Rule> {name: Default, colorspace: default}

Photo will be using the Default rule—you should see a toast in the top right every time you open an EXR file saying it has converted from 'default' to scene linear. The 'default' role, however, is defined as sRGB (see roles above), so Photo will be converting from non-linear sRGB primaries to scene linear, which will look very wrong. If you change the rule section to:

file_rules:
  - !<Rule> {name: Default, colorspace: default_float}

This will then convert from Linear BT.709 (Blender's default internal colour space) to scene linear, which should look correct. Does that fix it for you?

Alternatively, you can go to Settings>Preferences>Colour and disable Perform OCIO conversions based on file name, and that will stop the conversion entirely and assume the EXR primaries are already in scene linear.

I'm not sure what the correct approach is here—according to the OCIO documentation (https://opencolorio.readthedocs.io/en/main/guides/authoring/rules.html), rules are now a requirement for V2 configs as a default colour space must be mandated. I'm not sure why the AgX configuration has defined the default colour space as non-linear sRGB, I suspect there must be a reason. Perhaps adding some additional file rules may help make the configuration more flexible, e.g.:

file_rules:
  - !<Rule> {name: OpenEXR, extension: "exr", pattern: "*", colorspace: default_float}
  - !<Rule> {name: Default, colorspace: default}

This would at least convert from Rec.709 linear (or whatever default_float is in another configuration) if an EXR file is loaded.

There is another separate issue where the colour space transform appears to be bounded 😬 (this is already logged). This issue won't help matters, but it doesn't account for the radically different results you're seeing, which I suspect is a result of the configuration file causing Photo to convert from the wrong colour space.

I'll discuss with the Photo developer next week when he's back off holiday—we may need to do some more investigating...

[playername]

Hi @James Ritson

Very much appreciate you chiming in here and for your work with Affinity generally, very helpful. 

I will try disabling the preference as a first step and see if that helps, then report back here. My efforts and modifying configs generally go astray. 

Just a heads up - the GitHub Troy Sabotka config was the initial one he wrote as a proposition, a swag of developers have then taken it on and refined it, so it is way behind what will find its way into Blender. AGX will be implemented by Blender by V4 by the looks and the config they are basing it on is Eary Chow's (also available on Github). The config I am using is his, and then modified by him, at my request, to include the AdobeRGB colourspace, rather than just P3. So if the developers are looking at AGX, please refer to Eary Chow's as it is almost fully integrated into the upcoming Blender builds. The previous thread at Blender Artists charts this and the most recent posts include the Blender developers reports on implementing AGX as the new default. 

I hope this helps and is not just preaching to the choir. 

Best

Stephen

[James Ritson]

18 hours ago, playername said:

Hi @James Ritson

Very much appreciate you chiming in here and for your work with Affinity generally, very helpful. 

I will try disabling the preference as a first step and see if that helps, then report back here. My efforts and modifying configs generally go astray. 

Just a heads up - the GitHub Troy Sabotka config was the initial one he wrote as a proposition, a swag of developers have then taken it on and refined it, so it is way behind what will find its way into Blender. AGX will be implemented by Blender by V4 by the looks and the config they are basing it on is Eary Chow's (also available on Github). The config I am using is his, and then modified by him, at my request, to include the AdobeRGB colourspace, rather than just P3. So if the developers are looking at AGX, please refer to Eary Chow's as it is almost fully integrated into the upcoming Blender builds. The previous thread at Blender Artists charts this and the most recent posts include the Blender developers reports on implementing AGX as the new default. 

I hope this helps and is not just preaching to the choir. 

Best

Stephen

Hi @playername, thanks for the information, it's very useful. I had a look at Eary's configuration and it looks very comprehensive. It doesn't appear to have any file rules defined however—therefore I'm unsure of what Photo will be converting from into scene linear. I'm hoping it just looks at the 'default' role which is Linear Rec.709, but if your source colour space was something else then it would need a custom file rule adding into the configuration file. I haven't really experimented with other colour spaces when using Blender, can you actually set it up to use something like ACES or Adobe RGB for all its internal compositing?

I'll have to take a look and see if Eary's AgX transforms and output differ to Troy's, as I based my macros off Troy's version... (I've developed some macros so that users can easily apply AgX/Filmic transforms without requiring OCIO at all, which makes it far easier to just export as a gamma-encoded image format straight from Photo)

[playername]

Hi @James Ritson and @Chris B

I tried disabling OCIO conversions in preferences. I enclose the results below of a file rendered as exr using agx and adobe linear from Blender - as in first screenshot. Results are not great but it might help.

I am a bit reluctant to fiddle with the config as that is the path of tears, but may give it a go and report back. I think there is a plan to shift the default Blender colourspace, or at least broaden it with AGX and retain backward compatibility. Might the reason for the linear sRGB.

Anyway, these - in case they are useful.

 

[playername]

Hi @James Ritson

Thanks for getting back and that above post is one I tried to send yesterday but had all manner of problems logging in. 

Quote

I'm hoping it just looks at the 'default' role which is Linear Rec.709, but if your source colour space was something else then it would need a custom file rule adding into the configuration file. I haven't really experimented with other colour spaces when using Blender, can you actually set it up to use something like ACES or Adobe RGB for all its internal compositing?

I am not sure but I believe Eary and crew are aiming for BT2020 to be the default colour space (or possible colour space anyway) and then the configs will modify downwards - or at least, the display native can be chosen -  so it will include wide gamut displays. P3 is the one they are focussing on, hence my request to Eary to write a specific AdobeRGB one for me, which he kindly provided stanzas for and I cobbled together, badly. (Their developer discussions are way beyond my pay grade but as a painter, I am interested in their talk regarding colour perception.)

As you can see in the above, the config does allow you to specify different linear spaces including AdobeRGB. Blender can be set up to use different OCIO spaces and ACES is supported (but despised by Troy and crew as a pseudo solution. Again, above my pay grade.)

At the moment, when I use the AGX config with Adobe RGB as the colourspace I often get complaining error messages when importing if the source texture is in another colourspace. But if it is adobeRGB, it seems fine. It also seems to save to adobeRGB as converting it to sRGB in Affinity or photoshop presents the usual compressed gamut.

These are user descriptions rather than an under the hood explanation but it might allow you to figure out what is actually going on. 

I saw your macros by the way and actually bought and installed the filmic version in V1 which were very handy. The approach is a far simpler method than messing about with exr files - but they do allow all those useful layers. 

At present, the simplest workflow from Blender is using that AGX config and adobeRGB display space (I have a wide gamut monitor) exporting to Tiff and it opens all colour correct in Affinity or Photoshop - but without the compositing options of an exr. Hence the hopes for V2.2

It is my guess that Photo has not taken into account the expanded color spaces of Blender - and the upcoming increasing gamut that v4 should further provide - so it is assuming the sRGB limit. But - non-code writing user guess. 

Congrats on your very useful video tutorial series btw. Very clear, comprehensive and concise. Compared to the the usual "hey guys" YouTube videos that make my heart sink and which only get to some form of useful information around the 7 minute mark, yours are in another world altogether. The world of useful information.

Cheers

 

[playername]

@James Ritson

Oh and for clarity sake, you asked if Blender can be set up to use ACES etc. If on a Mac, right click the Blender application>package contents>contents>resources>3.6>datafiles>colour management

If you swap out that config and the LUTs etc with another set (in my case Eary Chow's AGX config) then that determines the colour spaces. ACES configs can be inserted here too. So this allows for wider gamuts - although I think there is an issue with the Blender developers wanting to retain sRGB as the standard space and that's presenting issues. 

btw, I use a fork of Blender called Bforartists which has all the functionality of Blender with the difference that you can find these functions or intuit them. That is to say, it is a much more logical, cleaned up user interface rather than the 'tack another bit on and add another million keyboard commands, somewhere' of the original. Well worth a look. 

[James Ritson]

Thanks again @playername, I'll do some more digging then will hopefully be able to discuss with the developers early next week.

2 hours ago, playername said:

I saw your macros by the way and actually bought and installed the filmic version in V1 which were very handy. The approach is a far simpler method than messing about with exr files - but they do allow all those useful layers. 

Just to clarify, the Filmic/AgX macros are meant explicitly for use with EXR/HDR formats—they're essentially an alternative to setting up OpenColorIO. Instead, you stick with the ICC display transform method and apply these macros above all your layer compositing work that wants to be done in linear space (e.g. blending multiple render passes together with Add such as mist, volumetrics etc). Then you apply the macros to do the required transform and get the linear values into bounded gamma-corrected space. At this point you would treat the editing as if you were working with a gamma-encoded bitmap like JPEG/TIFF, e.g. using adjustment layers, live filters and so on for further retouching. Hope that makes sense—it just sounded from your post like you were trying to use the macros with gamma-encoded output from Blender, but they already have the OCIO transforms applied.

The main reason I made the macros is because it's notoriously difficult to export from Photo to a gamma-encoded format when using the OCIO view transform. Using File>Export and going to a format such as JPEG doesn't actually use OCIO at all, it uses ICC display transform instead—so people will be working in OCIO, then find their exported result looks very different. The macros allow you to work with ICC display transform instead and then get a consistent File>Export result.

OCIO's implementation in Photo was more meant for VFX workflows where the app would be an intermediary, not an endpoint/delivery. For example:

• User would bring in an EXR document tagged with an appropriate colour space (which is then converted to scene linear)
• Alternatively, they would develop straight from photographic RAW using Photo's 32-bit HDR output option (which remains in scene linear)
• The user would then perform matte painting and any other retouching work required, perhaps using the OCIO adjustment layer to 'move' between colour spaces if they are compositing layers from different source colour spaces
• They would then File>Export back to EXR. appending the file name with the colour space they want to convert back to
• The EXR would then be brought into the VFX/NLE software

Being able to 'match' what is seen with the OCIO view transform when exporting to a gamma-encoded format is still an ongoing discussion internally for now...

2 hours ago, playername said:

At present, the simplest workflow from Blender is using that AGX config and adobeRGB display space (I have a wide gamut monitor) exporting to Tiff and it opens all colour correct in Affinity or Photoshop - but without the compositing options of an exr. Hence the hopes for V2.2

It is my guess that Photo has not taken into account the expanded color spaces of Blender - and the upcoming increasing gamut that v4 should further provide - so it is assuming the sRGB limit. But - non-code writing user guess. 

If you're working with gamma-encoded TIFFs, I believe Blender writes them out untagged, so Photo will assume sRGB primaries when importing them. You can change this in Settings>Colour by modifying the first "RGB Colour Profile" dropdown to your input space (e.g. Adobe RGB).

Hope the above helps!

[playername]

Hi James

Thanks for that. It has been while since I used the filmic ones and forgot that indeed, they are for exr files. Your explanation here is very useful though (for why and how to use them).

Yep, Blender does send things out untagged but I have modified the default colour space in Affinity and Photoshop and that works seamlessly. 

And in many ways, I could save myself a world of pain by just sticking with that simple work flow. The layers are a help though so I will have another look at your new macros. 

cheers

[mdriftmeyer]

Per Blender 4.0 Developer Release Notes Bcon 1

https://wiki.blender.org/wiki/Reference/Release_Notes/4.0/Rendering

 

Below link to the new default folding into Blender 4.0.

https://projects.blender.org/blender/blender/commit/a9053f7efbe8b25429b11bccd679dbe81ea60e3f

[phantascy]

On 8/21/2023 at 10:41 AM, Chris B said:

Thanks playername,

I downloaded the files and managed to get them straight into the app. See below:

I wonder if perhaps that fact you have it stored on some sort of volume that the sandbox is failing?

Are you able to move them locally and see if it works? If this is the case, I can log this with the developers and see if they can get this resolved.

i'm sorry to bother anyone within a year later of this. just i'v spent the majority of the night trying to find a open config file like blender with these settings. i loaded how my settings looked. its just irritating going thru various of blender/openconfig files not finding the exact settings like the left and right column of OCIO DISPLAY TRANSFORM.
if you still have a copy of that file please message me an inbox.
i want to test these exact settings with other editors that allow it match the color science from my cameras.  i even wrote to affinity youtube channel that the tutorial shows this photo above but the files arent the same as drop box at all.

anyone with the film side also lut side of these  files i would deeply appreciate the info/help to locate these specific files.

[phantascy]

On 8/21/2023 at 10:41 AM, Chris B said:

Thanks playername,

I downloaded the files and managed to get them straight into the app. See below:

I wonder if perhaps that fact you have it stored on some sort of volume that the sandbox is failing?

Are you able to move them locally and see if it works? If this is the case, I can log this with the developers and see if they can get this resolved.

thank you for responding. just other formats thats not * sRGB * Display P3 * Rec.1886 * Rec.2020 isi appeariing on the right OCIO display transform at all just aces.
on the left neither of the agx agx log agx false color display native does not appear either.
i just want those exact name label titles instead of aces & those photos i sent.

its not greyed out but im following some old tutorials that to be honest is making my livid cause i want to test this across davinchi blender affinity all at once to match colormanagements with Quicktime and so on.  i'm already signed in if you can forward it to my email those files to see what they dont match with what compile on my end i would appeciate it.
thanks for the responds . (nolifye@gmail.com)

[phantascy]

16 hours ago, phantascy said:

thank you for responding. just other formats thats not * sRGB * Display P3 * Rec.1886 * Rec.2020 isi appeariing on the right OCIO display transform at all just aces.
on the left neither of the agx agx log agx false color display native does not appear either.
i just want those exact name label titles instead of aces & those photos i sent.

its not greyed out but im following some old tutorials that to be honest is making my livid cause i want to test this across davinchi blender affinity all at once to match colormanagements with Quicktime and so on.  i'm already signed in if you can forward it to my email those files to see what they dont match with what compile on my end i would appeciate it.
thanks for the responds . (nolifye@gmail.com)

anyone else i tried on affinity youtube channel stating the files down show on the opencolor io display tranforms at all. i just need the exact config file and folder above with the formats i thats displayed that are missing.

 

[Guillermo Espertino]

@phantascy and anyone else having troubles with their OCIO config.
Keep in mind that an OCIO Config file has different roles and sections that different software tend to use in a different way.
For instance, Blender exposes looks, while most of the other software don't so it's necessary to create new colorspace definitions including the contrast looks, for instance, as part of the transform chain.
If you don't have any experience editing OCIO configs and/or you don't find yourself inclined to learn how it works, I recommend using a well mantained, generic configuration that suits your needs.

For that purpuse I think this one is probably the best option for general use:

https://github.com/Joegenco/PixelManager

It works well with affinity out of the box, but if you want to have access to all the variations of view transforms and looks available you have to do a minor editing to the config file, commenting out all the inactive_colorspaces (or choosing what to disable according to your needs). The config documentation explains what to do, it's quite easy.

This configuration is updated regularly and reflects the changes released new versions of Blender, so it works for stuff made with vanilla Blender, but it also includes other neat options, like ACES among others.

Using this config and commenting out the inactive colorspaces, you get the same combinations you get in the 32bit preview in the OCIO layer effects, allowing to replicate the appearance of the view transform in the layer stack, allowing to export the appearance to display-referred formats like JPG, PNG, TIFF, etc.

It's also a good idea to add this config to your system's environment variables, so every OCIO enabled software picks it up and make the same transforms available.

[phantascy]

On 7/20/2024 at 3:08 PM, Guillermo Espertino said:

Im going to check this out. thanks for the response/help


@phantascy and anyone else having troubles with their OCIO config.
Keep in mind that an OCIO Config file has different roles and sections that different software tend to use in a different way.
For instance, Blender exposes looks, while most of the other software don't so it's necessary to create new colorspace definitions including the contrast looks, for instance, as part of the transform chain.
If you don't have any experience editing OCIO configs and/or you don't find yourself inclined to learn how it works, I recommend using a well mantained, generic configuration that suits your needs.

For that purpuse I think this one is probably the best option for general use:

https://github.com/Joegenco/PixelManager

It works well with affinity out of the box, but if you want to have access to all the variations of view transforms and looks available you have to do a minor editing to the config file, commenting out all the inactive_colorspaces (or choosing what to disable according to your needs). The config documentation explains what to do, it's quite easy.

This configuration is updated regularly and reflects the changes released new versions of Blender, so it works for stuff made with vanilla Blender, but it also includes other neat options, like ACES among others.

Using this config and commenting out the inactive colorspaces, you get the same combinations you get in the 32bit preview in the OCIO layer effects, allowing to replicate the appearance of the view transform in the layer stack, allowing to export the appearance to display-referred formats like JPG, PNG, TIFF, etc.

It's also a good idea to add this config to your system's environment variables, so every OCIO enabled software picks it up and make the same transforms available.

[Alfred]

2 hours ago, phantascy said:

On 7/20/2024 at 8:08 PM, Guillermo Espertino said:

Im going to check this out. thanks for the response/help


@phantascy and anyone else having troubles with their OCIO config.
Keep in mind that an OCIO Config file has different roles and sections that different software tend to use in a different way.
For instance, Blender exposes looks, while most of the other software don't so it's necessary to create new colorspace definitions including the contrast looks, for instance, as part of the transform chain.
If you don't have any experience editing OCIO configs and/or you don't find yourself inclined to learn how it works, I recommend using a well mantained, generic configuration that suits your needs.

For that purpuse I think this one is probably the best option for general use:

https://github.com/Joegenco/PixelManager

It works well with affinity out of the box, but if you want to have access to all the variations of view transforms and looks available you have to do a minor editing to the config file, commenting out all the inactive_colorspaces (or choosing what to disable according to your needs). The config documentation explains what to do, it's quite easy.

This configuration is updated regularly and reflects the changes released new versions of Blender, so it works for stuff made with vanilla Blender, but it also includes other neat options, like ACES among others.

Using this config and commenting out the inactive colorspaces, you get the same combinations you get in the 32bit preview in the OCIO layer effects, allowing to replicate the appearance of the view transform in the layer stack, allowing to export the appearance to display-referred formats like JPG, PNG, TIFF, etc.

It's also a good idea to add this config to your system's environment variables, so every OCIO enabled software picks it up and make the same transforms available.

Expand  

Posting tip: When quoting the post to which you’re replying, type your reply either before or after the box containing the quote, not inside the box itself. @Guillermo Espertino didn’t write “Im going to check this out. thanks for the response/help”, you did!