OTOY Forums

Posted: **Thu Sep 24, 2020 9:23 pm**

jimho wrote: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.

Posted: **Fri Sep 25, 2020 1:56 am**

jimho wrote: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.

Posted: **Fri Sep 25, 2020 2:55 am**

karu wrote:
jimho wrote: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,

Posted: **Mon Oct 19, 2020 8:48 pm**

Hey

i found this documnetation from Arnold about ACES

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

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

Posted: **Tue Oct 27, 2020 9:35 pm**

Hi oddvisionary, a few points to your points

oddvisionary wrote: • 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.

oddvisionary wrote: • 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.

Posted: **Wed Oct 28, 2020 10:12 pm**

oddvisionary wrote: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.

Posted: **Thu Oct 29, 2020 1:19 pm**

oddvisionary wrote: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.

Posted: **Thu Oct 29, 2020 4:41 pm**

karu wrote: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?

Posted: **Thu Oct 29, 2020 9:24 pm**

funk wrote:
karu wrote: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?

The two halves of the color space need to match - as the text on the color management preferences screen says, "it doesn't matter which color spaces are selected as long as they match". Please interpret that text literally - you can select any two options at all as long as they refer to the same color space and it shouldn't make any difference to the render output (regardless of whether you're outputting in ACEScg or any other color space). For the standard ACES OCIO config, you can either choose "ACES2065-1" and "ACES - ACES2065-1", or "Linear sRGB" and "Utility - Linear - sRGB".

The only reason the intermediate color space settings exist is so that Octane knows how to convert between a known color space and an OCIO color space. OCIO is only capable of converting from one OCIO color space to another OCIO color space; without the intermediate color space settings we wouldn't know which OCIO color space to start with.

Imagine that Octane produces text in either English or Spanish, and OCIO can convert text between languages, but those languages have hidden names like "foo", "bar" and "baz". You'd have to select one of those names that you knew was actually English or Spanish, and tell Octane its name, and whether it's English or Spanish (so you'd say e.g. "baz is Spanish" or "bar is English" or "foo is Spanish"). Then there would be a "bridge" so that Octane could produce text in any OCIO language (even if you don't actually care about English or Spanish). That's what the intermediate color space settings are.

Regarding the PMs between me and oddvisionary, we are only PMing to get our story straight; any useful information should remain here

Posted: **Fri Oct 30, 2020 10:57 am**

karu wrote:For the standard ACES OCIO config, you can either choose "ACES2065-1" and "ACES - ACES2065-1", or "Linear sRGB" and "Utility - Linear - sRGB".

Thanks karu

I find the ACES preferences quite confusing so please bear with me.

I just did this test:

1) Color management OCIO prefs set to Octane = "ACES2065-1" + OCIO = "ACES - ACES2065-1". Imager OCIO view = "ACES: sRGB". I copied this to clipboard and pasted in PS.
2) I then changed OCIO prefs to Octane = "Linear sRGB" + OCIO = "Utility - Linear - sRGB". Imager OCIO view = "ACES: sRGB". I copied this to clipboard and pasted in PS again.

NOTE: Minor issue - While messing with other settings, I noticed that when changing prefs, you need to change the imager OCIO view to something else (eg none), then back to force the viewport to update correctly.

NOTE 2: Im only using PS so I can compare what the Octane viewport is displaying for 2 different settings, side by side. I could have used print screen + MS paint to do the same thing.

I was very surprised to see the output of both was identical. I think I'm starting to understand the Octane preferences a little better.
Using your analogy, my test just got Octane and OCIO speaking to each other in "English (1)" and "Spanish (2)", and the imager OCIO view can now translate to other "languages" in it's list (ACES: sRGB, ACES: Rec.2020 etc).

So I guess the main thing missing is conversion of input images/colors to ACES? And we can get around this by preconverting our images (in an external application) to ACES right?
(edit: what about sun/sky system colors? Don't they need some kind of conversion?)

Have I got this right?

OTOY Forums

Color Management

Re: Color Management

Re: Color Management

Re: Color Management

Re: Color Management

Re: Color Management

Re: Color Management

Re: Color Management

Re: Color Management

Re: Color Management

Re: Color Management