Color Management

[karl]

the Gamma 2.2 is coming from the octane render's camera imager node,gamma is set to 2.2,which default number is 1.0

2020.2.XB2_vp_g.jpg

Ah, I see, you're applying the gamma 2.2 response curve and also setting gamma to 2.2, meaning the effective gamma in the render viewport is 2.2 * 2.2 = 4.84. One of those is made up for by the difference between sRGB and linear sRGB and you need to correct for the other one to make the EXR match in Photoshop. With the new "Force tone mapping" option in 2020.2 XB3 you can use that to bake the additional 2.2 gamma into the EXR file.

[karl]

Yes in theory it should be the g10 profile,I did do that
but they are exactly the same appearance, I am actually quite curious why.

I get the same behavior with GIMP:

EXR + g22 profile = looks OK
EXR + g10 profile = looks OK
PNG + g22 profile = looks OK
PNG + g10 profile = looks wrong

My guess is that both Photoshop and GIMP ignore the gamma part of the profile when viewing an EXR file, because it knows those are linear and don't have gamma. Clever? Maybe. Helpful? ...Maybe.

[jimho]

the Gamma 2.2 is coming from the octane render's camera imager node,gamma is set to 2.2,which default number is 1.0

2020.2.XB2_vp_g.jpg

Ah, I see, you're applying the gamma 2.2 response curve and also setting gamma to 2.2, meaning the effective gamma in the render viewport is 2.2 * 2.2 = 4.84. One of those is made up for by the difference between sRGB and linear sRGB and you need to correct for the other one to make the EXR match in Photoshop. With the new "Force tone mapping" option in 2020.2 XB3 you can use that to bake the additional 2.2 gamma into the EXR file.

to select gamma2.2 or sRGB as response curve do not change the matter of fact that tonemap EXR export is too bright,

[samsue]

Hey

i found this documnetation from Arnold about ACES

https://docs.arnoldrenderer.com/display ... S+Workflow

http://help.autodesk.com/view/MAYAUL/20 ... 5EEF3D3F29

[oddvisionary]

Hello everyone,

I'd like to mention a few important points.

• Octane Standalone: is at this moment and when the original thread was posted here, at its early stage of the OCIO implementation and not fully featured nor fully implemented. There is no doubt that the OTOY team will update the documentation once ACES (OCIO) will be fully featured and correctly implemented. The OTOY team is still actively working on it and I would recommend to wait for a future non-experimental build, as anything you currently do with ACES will never be correct (as per the ACES standards) for the simple reason that ACES and OCIO are not yet fully and correctly implemented in Octane, for instance the rendering (scene referred) space is 2065-1 AP0 (primaries) while it should be ACEScg AP1 (primaries)
EDIT: Even for a spectral renderers (perhaps not for Octane though) we may encounter an XYZ to RGB conversion at the end Such information is AFAIK, not publicly available. I am guessing that Octane uses the ACEScg primaries when using OCIO, or at least, should be, since only ACES 2065-1 is available (and linear-sRGB as the "intermediate" alternatives).
In any case, it is a work-in-progress and so far, the OTOY team has been making great progress.

• Photoshop: It is worth mentioning that OCIO and ACES have not been 'designed' with Photoshop in mind as far as I know, which is not an application that has been 'designed' for CGI pipelines either (although it comes from VFX/ILM, its primary field, to this date, is graphic design including photography although there is LightRoom, and digital painting). The application does not have a full featured and official native OCIO implementation, resulting in workarounds and the use of ICC profiles/cube LUTs (only as far as I know).

• Side note: Both ACES 1.2 (current) and OCIO v1.x are not perfect.
ACES has flaws, at the moment: such as the per-channel look ups or the ACES ODT (based on a 3x3 matrix which can only models linear transformation and clamps the gamut in an Abney Effect way (extremely important missing gamut mapping resulting in horrible hue skews and posterization) but is part of the "ACES Retrospective and Enhancements" as well as the upcoming OCIO v2, which I don't doubt, OTOY will update in Octane in the future.

I cannot stress enough and highly recommend to use an appropriate post-compositing software like Nuke, Fusion or equivalent, which all support OCIO natively and have hassle-free and most importantly: non-destructive color management 'workflow', suited for motion pictures, CGI and VFX, more than Photoshop. I would have recommended Affinity Photo but the application has an issue when exporting to integer images when using ACES via OCIO. Otherwise, it works very well when exporting to floating-point EXRs. I could also highly recommend the display-(view)-transform Filmic which is also OCIO-based and is much simpler than the ACES-workflow, without the gamut mapping issue (or at least, better handled as for now). Although not perfect either, it is a very solid and simpler alternative, made by Troy Sobotka, a master-mind in Digital Color Science, initially for Blender but since it's OCIO, it does work in any renderer (or software) that correctly supports OCIO (already available and working in XB3-XB4 Octane Standalone, which I tested myself).

I hope it clarifies better the current state of ACES (or OCIO) in Octane.

Best.

[karl]

Hi oddvisionary, a few points to your points

• Octane Standalone: is at this moment and when the original thread was posted here, at its early stage of the OCIO implementation and not fully featured nor fully implemented. There is no doubt that the OTOY team will update the documentation once ACES (OCIO) will be fully featured and correctly implemented. The OTOY team is still actively working on it and I would recommend to wait for a future non-experimental build, as anything you currently do with ACES will never be correct (as per the ACES standards) for the simple reason that ACES and OCIO are not yet fully and correctly implemented in Octane, for instance the rendering (scene referred) space is 2065-1 AP0 (primaries) while it should be ACEScg AP1 (primaries). It is a work-in-progress and so far, the OTOY team has been making great progress.

The current implementation of ACES and OCIO in Octane standalone is missing some features that we plan to add in the future (for example, there is no ability to assign different color spaces to image textures), and it may have some bugs (which we're hoping to iron out with the current 2020.2 experimental builds), but the features that are present are, as far as we know, complete and correct. Octane doesn't have a "rendering space" as it is a spectral renderer, not an RGB renderer. I'm not sure where you heard that Octane uses ACES2065-1 internally, but it doesn't - ACES color spaces are only used when an ACES color space is selected when exporting an image file. While we intend to keep improving the support for both ACES and OCIO and adding new features, we do want to hear about any and all problems with the current implementation - anything you can do with the current 2020.2 XB4 experimental build should work 100% correctly.

• Side note: Both ACES 1.2 (current) and OCIO v1.x are not perfect.
ACES has flaws, at the moment: such as the per-channel look ups or the ACES ODT (based on a 3x3 matrix which can only models linear transformation and clamps the gamut in an Abney Effect way (extremely important missing gamut mapping resulting in horrible hue skews and posterization) but is part of the "ACES Retrospective and Enhancements" as well as the upcoming OCIO v2, which I don't doubt, OTOY will update in Octane in the future.

Yes, we plan to upgrade to OCIO v2 after it is released. Hopefully this will be ready for the next major Octane release.

[oddvisionary]

Hello Karu,

Thank you for your reply.

The current implementation of ACES and OCIO in Octane standalone is missing some features that we plan to add in the future (for example, there is no ability to assign different color spaces to image textures)

Indeed. This is why I did mention not yet full implemented/full featured. Looking forward to it!

Octane doesn't have a "rendering space" as it is a spectral renderer, not an RGB renderer. I'm not sure where you heard that Octane uses ACES2065-1 internally, but it doesn't - ACES color spaces are only used when an ACES color space is selected when exporting an image file.

Generally speaking, being a spectral renderer doesn't mean it doesn't convert from CIE XYZ to RGB at the end (and possibly a specific color space such as the chromaticity primaries of the sRGB gamut), as this information is nowhere mentioned in the documentation.
What I think is incorrect is the intermediate color space option that is not yet documented and only provides ACES 2065-1 and Linear-sRGB. Using ACES for rendering, only ACEScg (AP1 primaries) is recommended as the rendering space, generally speaking (if that applies to Octane). If Octane does not convert to any rendering space, then I do not understand very well this option in the preferences (that yelds in some questionable results). Especially that we have another option named "OCIO" which doesn't specify anything.

Although I'm waiting on your team that I already contacted, it clarifies some thoughts I had and make sense as it an option available at the export. That said, I would prefer to wait for your team to get back to me regarding the other questions I've had sent to them.

You should have access to my documents that I've sent recently. I invite you to consult them. I am looking forward to hearing back from you or your team.

Best

[karl]

Generally speaking, being a spectral renderer doesn't mean it doesn't convert from CIE XYZ to RGB at the end (and possibly a specific color space such as the chromaticity primaries of the sRGB gamut), as this information is nowhere mentioned in the documentation.
What I think is incorrect is the intermediate color space option that is not yet documented and only provides ACES 2065-1 and Linear-sRGB. Using ACES for rendering, only ACEScg (AP1 primaries) is recommended as the rendering space, generally speaking (if that applies to Octane). If Octane does not convert to any rendering space, then I do not understand very well this option in the preferences (that yelds in some questionable results). Especially that we have another option named "OCIO" which doesn't specify anything.

Although I'm waiting on your team that I already contacted, it clarifies some thoughts I had and make sense as it an option available at the export. That said, I would prefer to wait for your team to get back to me regarding the other questions I've had sent to them.

You should have access to my documents that I've sent recently. I invite you to consult them. I am looking forward to hearing back from you or your team.

Best

I've sent you a PM about the separate feedback you sent.

Regarding the intermediate color space in preferences, this is only relevant when using OCIO (that's why it's under the OCIO header, although the spacing on that screen could perhaps make this a bit clearer). The intermediate color space allows Octane to convert between built-in color spaces for which it knows all the details (chromaticities etc.), and OCIO color spaces for which it knows nothing except the name (as a string). The intermediate color spaces function as a "bridge" for these conversions - to convert from built-in color space A to OCIO color space B, Octane first converts from A to the "Octane" side of the intermediate color space (using, for example, a 3x3 matrix), and then uses OCIO to convert from the "OCIO" side of the intermediate color space to B. The conversion in the other direction is similar (but Octane doesn't do this yet). Without the two halves of the intermediate color space being set, Octane would have no way of knowing that the "Utility - Linear - sRGB" OCIO color space (for example) matches what Octane calls linear sRGB. Non-spectral renderers don't need this information because they are generally color-space-agnostic - whatever color space you put in is what you get out - but Octane needs to know the specific details of at least one OCIO color space because the renderer produces absolute wavelengths of light.

The only options available for the "Octane" half of the intermediate color space are linear sRGB and ACES2065-1, because this list only needs to cover enough color spaces so that any OCIO config a user would want to use should always contain at least one color space that matches one of them. ACEScg is not included because I don't believe there are (or should be) any practical ACES OCIO configs that do not include ACES2065-1 (plus, including ACEScg in the list may contribute to the mistaken assumption that it's somehow more correct than ACES2065-1 in this context).

The color management preferences page contains the text "For the intermediate color space, ensure both selections represent the same scene-linear color space (it doesn't matter which color spaces are selected as long as they match).", and both the intermediate color space boxes have tooltips that should be helpful. Please let me know if you think this could be made clearer because you're not the only one who's been unsure about these preferences.

[jimho]

Hello everyone,

I'd like to mention a few important points.

• Octane Standalone: is at this moment and when the original thread was posted here, at its early stage of the OCIO implementation and not fully featured nor fully implemented. There is no doubt that the OTOY team will update the documentation once ACES (OCIO) will be fully featured and correctly implemented. The OTOY team is still actively working on it and I would recommend to wait for a future non-experimental build, as anything you currently do with ACES will never be correct (as per the ACES standards) for the simple reason that ACES and OCIO are not yet fully and correctly implemented in Octane, for instance the rendering (scene referred) space is 2065-1 AP0 (primaries) while it should be ACEScg AP1 (primaries)
EDIT: Even for a spectral renderers (perhaps not for Octane though) we may encounter an XYZ to RGB conversion at the end Such information is AFAIK, not publicly available. I am guessing that Octane uses the ACEScg primaries when using OCIO, or at least, should be, since only ACES 2065-1 is available (and linear-sRGB as the "intermediate" alternatives).
In any case, it is a work-in-progress and so far, the OTOY team has been making great progress.

• Photoshop: It is worth mentioning that OCIO and ACES have not been 'designed' with Photoshop in mind as far as I know, which is not an application that has been 'designed' for CGI pipelines either (although it comes from VFX/ILM, its primary field, to this date, is graphic design including photography although there is LightRoom, and digital painting). The application does not have a full featured and official native OCIO implementation, resulting in workarounds and the use of ICC profiles/cube LUTs (only as far as I know).

• Side note: Both ACES 1.2 (current) and OCIO v1.x are not perfect.
ACES has flaws, at the moment: such as the per-channel look ups or the ACES ODT (based on a 3x3 matrix which can only models linear transformation and clamps the gamut in an Abney Effect way (extremely important missing gamut mapping resulting in horrible hue skews and posterization) but is part of the "ACES Retrospective and Enhancements" as well as the upcoming OCIO v2, which I don't doubt, OTOY will update in Octane in the future.

I cannot stress enough and highly recommend to use an appropriate post-compositing software like Nuke, Fusion or equivalent, which all support OCIO natively and have hassle-free and most importantly: non-destructive color management 'workflow', suited for motion pictures, CGI and VFX, more than Photoshop. I would have recommended Affinity Photo but the application has an issue when exporting to integer images when using ACES via OCIO. Otherwise, it works very well when exporting to floating-point EXRs. I could also highly recommend the display-(view)-transform Filmic which is also OCIO-based and is much simpler than the ACES-workflow, without the gamut mapping issue (or at least, better handled as for now). Although not perfect either, it is a very solid and simpler alternative, made by Troy Sobotka, a master-mind in Digital Color Science, initially for Blender but since it's OCIO, it does work in any renderer (or software) that correctly supports OCIO (already available and working in XB3-XB4 Octane Standalone, which I tested myself).

I hope it clarifies better the current state of ACES (or OCIO) in Octane.

Best.

In short using icc and photoshop as before for still image, for now.

[funk]

Please let me know if you think this could be made clearer because you're not the only one who's been unsure about these preferences.

OK count me in as one of the confused. I assumed we were waiting for ACEScg to appear in the "intermediate color space - octane" list.

So are you saying I can set it to octane = "ACES2065-1", OCIO = "rendering (ACES - ACEScg)" and it will look correct?

The tooltips make it sound like I must choose octane = "ACES2065-1", OCIO = "default (ACES - ACES2065-1)".

EDIT:
By the way, IF its OK to do so, rather than PM each other, could you post your discussions on the forum so we can all learn from them?