sRGB display in viewport with Tone Mapping off
legarc
Posts: 45
Is there ever going to be the option to apply sRGB display in the viewport with Tone Mapping set to off?
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
If you turn off Tone Mapping, pull all the sliders to zero, when looking through a camera all you will get is a black render as there would be no light getting through the lens, a bit like taking a picture with the lens cap still on :)
Light settings typically in the 50k-100k range in lumens with the TM on get set to something like 10 when it's off no matter the light type and illuminates well except image in view port is degamma'ed. With TM off it's the only way to make use of luminance filter that when adjusted correctly clamps lunimance down so you don't get fire flies which can make for quicker renders overall. The 'DAZ team' knows exactly what I'm referring to hoping to hear from one of them, Richard, Spooky or somebody. It's been on their roadmap to include this feature for quite some time now just wondering if it will ever come to pass. I suppose I can write a ticket or submit in whatever forum for desired features in future version.
Neither Spooky nor I are developers, and I'm not quite sure what you mean - sRGB is not a flat (tone-mapping off) specification in itself.
I've reread your comments numerous times and still don't follow. I take it you've A) turned Tone Mapping off and then B) adjusted Nominal Luminance to hint the renderer. Then what? What "viewport" are you meaning? To me, the viewport is the D|S posing window, which is out of the renderer loop anyway. Do you mean the rendering window, the viewport when the NVIDIA realtime display is on, or ...?
I'm sure you have a point, but to me, no tone mapping means no explicit gamma. Is there a reason then to force gamma by applying an sRGB curve?
I do follow with the firefly issue at high light values.
It's tied in with color linear workflow. Folks that render using Maya like myself for instance have the option to display the render in sRGB or not. Color management is applied without additionally applying correction to input images for textures that are already gamma corrected. Workflow stays linear all the way to the render where the option to show final render in viewport in sRGB or not is available (this is not tone-mapping). The core non-gamma corrected, non-tone mapped image usually in a 32-bit float, exr format that's rendered is taken to a pgrm such as Nuke where sRGB is applied while maintaining true high dynamic range color workspace, whites and highlights don't get clipped as they do coming out of Daz using tone mapping. Basically I turn off tone mapping in Daz making use of the canvas feature that generates non tone-mapped images in exr format because I don't want Daz to tone map my images. For all of Daz-iRay proclaimed light and shadow accuracy, color space is not being considered. That's why your images always look flat and cartoony folks. With tone mapping off you also have access to iray's very cool feature of controlling luminance, ie, fire flies per iray blog/documentation. Without the option to display in sRGB in the viewport with tone mapping off however it's difficult to then adjust lighting accurately, gauge for noise etc. So I end up creating light groups via light paths in the Canvas section and control light intensity for my different lights in post. I'd just assume do that while the image is in the viewport displayed in sRGB, again with tone mapping off and linear just like you can in every other 3d program but it just seems I'm not being understood in this particular forum. You can only trust that you'd be very happy to have this feature as your images would then match those generated in pgrms like Maya and Max that use iRay. Off to the developers forum I go, or not...
Surely you don't want gamma-corrected textures, unless you are reversing the correction out, in a linear workflow - but I think that's just quibbling over a typo or quirk of phrasing.
My understanding is that you essentially want a preview that modifies the actual render but doesn't affect the saved image, which is not an unreasonable request but possibly a fairly niche thing (and I don't think can be done now - the Render Editor does have gamma correction but opening that, adjusting, and then having to cancel sounds like at least as much trouble as saving and viewing the image in another application).
I think I understand now. Richard points out it's niche -- I think that's true for the "hobbyist" market Daz seems to be be (primarily) after. The Maya user is going to be somewhat different from the D|S user -- the pricing is certainly a giveaway there. That said, it would be nice just in general if the program offered more settings for output, including color space, document profiles, even PPI resolution. There are ways around all these, but it always involves a third-party graphics program, and in the case of color management, a fairly sophisticated one like Photoshop. Not everyone has these tools, or knows how to use them for these tasks.
When you say "display in the viewport" I take you mean viewport NVIDIA rendering, not OpenGL rendering. It would be nice if I could use the NVIDIA viewport for such things. Sadly, no interactive rendering for Tobor. I drive a '66 VW bug in a world of Teslas and BMW 7-series.