Jump to content
You must now use your email address to sign in [click for more info] ×

OpenColourIO (OCIO) v2 Support


Recommended Posts

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

 

Link to comment
Share on other sites

  • Staff

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.

 

 

Link to comment
Share on other sites

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..
 

Link to comment
Share on other sites

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.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.3, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.3.1

Link to comment
Share on other sites

  • Staff
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 :) 

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

  • Staff
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.

Link to comment
Share on other sites

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

image.thumb.png.20d03fd194e8def49014402e652c8bc5.png

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

  • Staff

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...

Product Expert (Affinity Photo) & Product Expert Team Leader

@JamesR_Affinity for tutorial sneak peeks and more
Official Affinity Photo tutorials

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • Staff
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)

Product Expert (Affinity Photo) & Product Expert Team Leader

@JamesR_Affinity for tutorial sneak peeks and more
Official Affinity Photo tutorials

Link to comment
Share on other sites

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.

 

Screenshot 2023-08-24 at 11.45.42 am.png

Screenshot 2023-08-24 at 11.44.28 am.png

Screenshot 2023-08-24 at 11.45.02 am.png

Screenshot 2023-08-24 at 11.43.27 am.png

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

@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. 

Link to comment
Share on other sites

  • Staff

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!

Product Expert (Affinity Photo) & Product Expert Team Leader

@JamesR_Affinity for tutorial sneak peeks and more
Official Affinity Photo tutorials

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.