"Update Render Settings" should change Color Management settings

[Midnight Arrow]

Today I discovered I am “rendering wrong”. Doing some comparison renders to match skin between Iray and Cycles I changed some of the Color Management settings to experiment. To my surprise, changing view transform from filmic (the default) to standard (the old sRGB transform) made my renders almost indistinguishable from Iray.

The following two renders were both made with the default Daz HDRI rotated 90 degrees. Skin material is Zsazsa by Mousso.

Iray:

‌

Cycles:

‌

For the Cycles render I brought the skydome strength down to 0.5. The Color Management I set to standard transform, medium contrast, 1.75 exposure, 1.25 gamma. I did not change the tonemapping on the Iray image.

Same scene, same color settings with the skydome replaced with a spotlight.

Iray:

‌

Cycles:

‌

Despite the imported light having a different angle the skin tone is still remarkably similar. My main criticism is the gray eyes. I think the shader was made to look good at a different color transform than standard.

I searched the blogspot for “filmic”, “sRGB”, “color management”, etc. Nothing about this whatsoever. All I found was an old, closed issue from Padone (#22) on here casually mentioning sRGB gives closer results to Iray. If I had known about this months ago, #857 would not have been an issue probably.

I understand this is a hobby and Thomas is too busy to move the documentation to a proper wiki format and keep it updated. But I spent months thinking either Cycles is fundamentally different to Iray or the node setups the importer creates aren’t good enough to match Iray. I did not know I deliberately need to enable an outdated color profile to crush my dynamic range.

If the purpose of this importer is to do things as close as Iray does, Update Render Settings should by default change the View Transform to sRGB/Standard and boost the exposure/gamma to match Iray. I agree Filmic is better but (if the documention can’t be moved to a wiki and made thorough and up to date) the stated intention of the importer is to preserve scenes as much as it can. This behavior does not fit and confuses new users. For experienced users a (properly documented) global toggle to turn this off would be better.

Unfortunately this does not work as well for skins with Mono SSS like iSourceTexture’s Evangeliya. But seeing the skin tones are at least in the right range compared to #857, I consider it an improvement.

‌

‌

‌

‌

[Alessandro Padovani]

The plugin does not convert tone mapping. Because this is impossible to do since iray uses custom curves, that we may try to match with “use curves“ in the color management but would require extensive tests to find something similar with equations to match iray and cycles.

The standard view transform is more similar to the default iray tonemapping with the default hdri, but daz users often change that at least for the exposure value. And the default filmic transform is in general “better” to mimic the human eyes perception. So using the standard view trasform would only work in some cases and not others.

It may be added #22 to the docs. Or simply a note that tone mapping is not converted. As for #857 that is an implementation for the weighted mode that has nothing to do with tone mapping.

‌

note. To partially justify the “lack of information“ in the docs, there’s no converter in the known universe that converts tone mapping among rendering engines so this is quite expected.

note. We could easily convert the exposure value though as explained in #22, since in real cameras the exposure is a camera setting. But since exposure is in the tone mapping section both in iray and cycles then it is not converted. This is consistent if we decide to don’t convert tone mapping.

[Midnight Arrow]

It’s implied the skin shaders are meant to look good in default/filmic mode, but all of them come in paler and yellower/bluer by default compared to Iray. Converting to sRGB crushes the dynamic range and makes the skin look more vivid and red like Iray. I did no tweaking to either of these skin shaders and several more. All of them look more like Iray renders just by adjusting the Color Management closer to Iray’s sRGB.

What you think is “expected”, as somebody who’s been involved with this for years, is not the same as what somebody else expects. If they hear the exporter tries to convert Iray figures as closely as possible, only to find drab yellow characters and a material editor, naturally they (like I did) will think the solution is to tweak the materials since the importer isn’t good enough to do it correctly.

If you feel this shouldn’t be automatic (fine), then I agree it should be made clear the figures aren’t meant to look the same in Iray and will need to be tonemapped, rather than starting to adjust the materials to make them look in filmic just like they do in Iray sRGB.

[Alessandro Padovani]

Not at all. It’s implied materials are meant to look the same as iray in various lighting conditions, excluding tone mapping. That is, tone mapping is left to the user. And again changing to the standard view transform only works in some cases, as you say yourself in your previous comment.

I would like too much myself to convert tone mapping but this is too complex. There’s nothing to be fixed here. Apart may be a note in the docs.

[Midnight Arrow]

One common complaint about Diffeomoprhic is that materials don’t convert well. It’s a complaint I myself had until today despite using it over half a year. I’d recommend more than just a note or people will continue to think the program is incapable of exporting materials properly.

[Alessandro Padovani]

Then Thomas would you like to add a blog post with #22 ? There’s also #994. Or I could do it if you can provide access to the blog. Please let us know.

[Thomas Larsson]

If you send me your email address again I can invite you as an author. It seems that Bitbucket didn’t save it.

[Thomas Larsson]

You should have an invitation in your email.

[Alessandro Padovani]

Thank you Thomas for the invitation. Seems to work I’m in. Of course I will limit my activity only to things you approve as #22 and #994. Will update later and I’m deleting my email here since it’s no more necessary.

[Midnight Arrow]

I did a little research and found Iray uses a curve called Reinhard controlled by the burn highlights value.

https://rsdoc.migenius.com/doc/resources/general/iray/relnotes.pdf

“Employ a more flexible compression curve, controlled via mip_compression_variant. Default is reinhard and yields the previous behavior, controlled by mip_burn_highlights”.

I assume previous means how Iray rendered until this version released in December 2021. The same thing gets a mention in Iray release notes on the Daz forum so Daz must be using it too.

Many Blender tutorials and non-Daz assets are based on making materials look good in the default (filmic) view transform. They rarely do tonemapping techniques. Just something to keep in mind and clarify for new users.

[Alessandro Padovani]

Yes that’s the custom curve I was talking about. I have no idea if/how we could mimic this in blender. My impression is that blender just uses its own custom curves that are different from iray and there’s no way to match them. Unless the blender team can implement different tone mapping features than “filmic“.

https://docs.omniverse.nvidia.com/app_create/prod_materials-and-rendering/render-settings_post-processing.html

[Midnight Arrow]

Blender gets used in industry pipelines and supports OCIO which (far as I understand) lets you supply any color profile you want. Not sure how much trouble it’d be to make though.

[Alessandro Padovani]

A color profile has nothing to do with tone mapping. Tone mapping is a transfer function that goes from linear hdri to a output space. A color profile defines the output space but it’s not a transfer function. That is, tone mapping is “independent“ from the color profile.

[Midnight Arrow]

I meant to write “color space”.

[Midnight Arrow]

Blog post has been posted.

[AnonymousBlender]

Just read the blog post. It’s a good one. I wanted to add that not only would matching the tone mapping be pointless. This is also something most people should be doing as a part of their post-processing work anyway. With stills, you use Photoshop, for Movie files you use things like Nuke, the Blender compositor, or Resolve. The point being is that no matter what, color management is always handled elsewhere. This is different in Daz as it is intended to be an “all in one solution“. So, you get all those settings. A big part of getting the Daz to Blender pipeline working smooth, or what makes it difficult is the fact they are two very different ideologies, theories, or methods of getting the job done.

It is standard practice to do all your color correction work in a completely different piece of software. Daz is actually the oddball in this situation.

Sorry if this was covered elsewhere. I just thought of it when I finished reading the blog post.

[Midnight Arrow]

@William Hurst

It’s more an issue of, we need an accurate reference between the two render engines to compare skin materials. It wasn’t explained to us how to create that reference frame.

[Alessandro Padovani]

Thank you @William, adding a note in the blog to make this clear. It is obvious to me but may be not to others.