How to validate Aces colorspace workflow in create?

Hello,

I am trying to validate accuracy of the Aces implementation in Create and am struggling to get accurate color. My steps:

  1. Save aces .png & .exr color in photoshop
  2. Apply to emissive part of omni surface, set to auto or raw color (only options are raw, auto, srgb). I’ve also applied linear aces rgb values in the color, but there doesn’t seem to be any options of color space in the color picker so I don’t actually know what it thinks the color is.
  3. apply to plane
  4. render with linear tonemap (aces throws it way off), turn off all other color options as that makes things worse
  5. save render through the movie options
  6. compare in photoshop

The rendered color is semi-close to what the original in photoshop was, but still quite a bit visibly off. Of course the emissive intensity will be off due to the physical representation of it, but even after accounting for exposure, the color is still off. I also don’t know how to set the colorspace of the viewer accurately to view through the icc profile of my monitor.

What are the proper steps I can follow to correctly set up aces & determine the faithfulness of the implementation? I don’t care about lighting or shading effects yet, I am only concerned about color representation at this time.

Thank you,
Jonathan

1 Like

What is your renderer? Have you disabled the environment light (default dome light which usually tint everything).

I was using the pathtracer, all lights have been turned off.

Here’s the comparison, but with and srgb screenshot because aces has issues being viewed in web. Middle band is Omniverse and outside bands are the original aces color.

If I save as a .png instead of an .exr and then apply an inverse srgb gamma of .45454 I get very close. Which tells me either I or the system is not doing something right somewhere. Here the same comparison with this method.

Hey all, I am looking to try and get this resolved quickly, if possible. Is there someone on the Nvidia side that can shed light on the ACES workflow, why the .png & .exr don’t match, and why the input color does not match the output color when no shading or lighting has been applied?

I also noticed the viewer does not seem to have any aces or monitor profile attached and just an .srgb output. Could this be part of the problem?

Hi @TheBeals. I don’t know the best way to verify this, but I’ll check with the rendering team.

1 Like

Thank you so much, I really appreciate your help! Please let me know how I can best help you as well. Let me know if there is any other data at all that would be helpful to you.

@TheBeals We don’t support a full ACES workflow currently. We only have the ACES tonemapper in our post processing. OCIO is on our roadmap which would enable the full ACES workflow you’re looking for.

1 Like

Thank you so much for your your response. Is this further in or further out on the roadmap? I would love to help test when it becomes implemented. I’ve really liked the implementation done in designer where, in the viewer, it allows you to choose the icc profile from your monitor(s). It also supports ACES and ACE, which is really nice when working with Adobe products. Hope this helps generate some ideas. Thank you again!


1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.