Add Khronos PBR Neutral tone mapper #118936
No reviewers
Brecht Van Lommel
Sergey Sharybin
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#118936
Loading…
Reference in New Issue
No description provided.
Delete Branch "Emmett-Lalish/blender:pbrNeutral"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes #118824 - devtalk discussion.
I developed a new tone mapping function, on behalf of Khronos, specifically to address the color accuracy needs of 3D e-commerce: getting PBR base colors to show through faithfully in the output render under grayscale lighting, without saturation loss, hue skews, or visual artifacts. It now has the official name Khronos PBR Neutral Tone Mapper, or PBR Neutral for short. For details, please see my writeup.
This is in no way a competitor to AgX or other filmic tone mappers; think of it instead as an improvement for anyone who currently disables tone mapping, what I believe is referred to as the Standard view transform in Blender. The addition of a PBR Neutral view transform would allow artists to easily see their PBR models in a color-neutral way without blown-out highlights, that can exactly match common end-point renderers that have adopted this new standard, e.g. Three.js and Filament.
As an example using my 3D Macbeth color chart model, here is the Material Preview mode using this PBR Neutral view transform:
The unlit spheres are less useful as comparisons here, as they are also going through the tone mapping function, unfortunately. However, I did do a manual verification using a white furnace test that these colors are indeed coming to the screen precisely correct.
Compare to the Standard view transform (no tone mapping):
You can see the strange hue skews (top row most obviously) and some loss of contrast and saturation in the darker colors.
AgX is better, but severely desaturates the colors:
Edit: note that I'm using the Blender default lighting environment here, which is not grayscale. As you can see, the tone mapper works well for general lighting, but for exact hue reproduction, a grayscale studio lighting environment is also needed.
@blender-bot build
Only blender organization members with write access can start builds. See documentation for details.
By the way, thank you Blender devs! I had nearly given up on generating an OpenColorIO config for this tone mapper, as their documentation is so utterly useless, when it occurred to me that Blender might already have an OCIO config. Turns out I learned the format much quicker by reading your well-organized file than with anything from the standards.
@blender-bot package
Package build started. Download here when ready.
By the way, if there's anyone here who would like to nerd out about HDR displays and wide color gamuts, please let me know. I have an M1 Macbook Pro and I was playing with Blender's HDR support, which is cool. I would like to extend this neutral tone mapping to work for other displays beyond sRGB, but I would need to pick someone's brain first who knows more about the space.
@Emmett-Lalish We have a task for support of HDR workflows in Blender: #105714 which should give you some background information. We can also talk in the
#blender-codersroom of blender.chat about it, as it is probably the easiest. I am not sure yet we should be mixing the HDR story into this PR.Perfect, thanks @Sergey. That will definitely be follow-on work; not sure how long it'll take and I think we should be sure everyone's happy with this first PR before getting started.
@blender-bot package
Package build started. Download here when ready.
@blender-bot package
Package build started. Download here when ready.
Overall this seems fine and a useful addition.
The only thing I'm wondering is about the "PBR Neutral" name, because I can imagine this getting used for NPR as well. Maybe in the context of Blender, more often than for PBR even.
I see that in three.js it's called "Khronos Neutral", and in Filament "PBR Neutral". Do you have any strong opinion on the naming, if you think it should include the term PBR, or if "Khronos Neutral" makes sense?
Greetings to all. I noticed when testing some images that the shadow tones at a certain value suddenly stop being noticeable but the black level does not reach zero (or at least a minimum value, like sRGB view), an example:
PBR Tone Mapper
sRGB View
Is this the expected behavior or is it a bug?
@brecht Thank you, and the answer to your naming question is actually related to @JoelR_VC's question about the blacks. Khronos did hold a vote and officially name this the Khronos PBR Neutral Tone Mapper, or PBR Neutral for short. I don't have a strong opinion on how you shorten the name for Blender, but the reason we chose "PBR Neutral" is due to exactly the compensation that @JoelR_VC noticed.
Unlike traditional tone mappers that compare an input HDR image to an output SDR image, this tone mapper was designed by comparing PBR baseColor textures to the output SDR render. As such, it contains a saturation and contrast boost that gives an average compensation for the Fresnel effect (part of PBR), which otherwise desaturates baseColors and makes deep blacks almost unattainable. So yes, @JoelR_VC, what you observe is very much intentional, but you'll get a better sense of its utility if you make your color sweep into a PBR material and use grayscale lighting.
As for NPR (Non Photo Realistic, I presume?) - it would help to know more about this, since defining something by what it's not leaves a lot open to interpretation. If you mean effectively unlit, then I would say Standard (no tone mapping) would be better since the colors aren't HDR in the first place and there's no Fresnel effect to compensate for. I would only recommend PBR Neutral for shaders that contain the Fresnel effect. I would love to know more about popular shaders in Blender and whether they use Fresnel.
From what I can tell, this maps scene linear
0 0 0to0.0196 0.0196 0.0196. Which makes pure black unattainable, because you can't go lower for the scene linear color? Is that really intentional?NPR is very broad, it covers everything that is not photorealistic. Some NPR styles may use HDR and Fresnel, others not.
Anyway, I suggest we call this "Khronos PBR Neutral" in the user interface, if that's the official name.
No indeed! Taking a look at the official equations,
0 0 0definitely maps to0 0 0. Looks like I need to take a closer look at my OCIO approximation. Thanks for the pointer! How did you determine this? Might be good fodder for a test.SG - I'll update the PR with these two changes next week.
In Blender I just set rendered with the world background color set to black, and then sampled the colors in the image editor.
This tone mapper/view transform is treated as "supporting HDR" on macOS, yet it doesn't produce any HDR values.
This should be added to the list of view transforms that don't support HDR (See
967e36cf68for an example of how this was done for theFalse Colorview transform).Or @brecht / @Sergey this Python script should be adjusted to enable the HDR toggle for supported view transforms rather than disabling it for unsupported view transforms. Although this has the consequence of greying out the HDR toggle for custom OCIO configs with HDR compatible view transforms.
That's the reason we didn't do it, we don't want to break custom OCIO configs.
I've been testing the view transform and have come across some issues. Some of them are specific to the OCIO version, but others are also present in the GLSL version provided in the write-up.
In the OCIO version there is colour fringing around the edges of the stripes when going out of focus. There is also a pronounced hue shift present where the stripes go into shadow.
In both versions there are issues with gradients, which become too dark. This is especially apparent where the differently coloured stripes meet.
There also seems to be an issue where white edges appear at the edge of the overlapping region in the spotlights.
These issues can probably appear whenever there is a transition between a saturated colour and a grey or complementary colour present in a render. Such transition can be created by things such as depth of field or motion blur.
There is also a problem with the intensity of the stripes in shadow. Looking at the RGB values of the coloured stripes in the shadow region and compare to the surrounding background of the surface some of the values are higher for the coloured stripes. This results in the stripes appearing to either "separate" from the surface or the white part of the surface becoming less reflective, neither of which were intended. It is a lot more pronounced in the GLSL version.
None of these issues were visible when using the standard (or Filmic or AgX) view transform. The gradient and intensity issues which are also present in the GLSL version seem problematic for a view transform because they can lead to the image "misrepresenting" the scene, which, if I understand correctly, would go against the goal of this view transform. From a user's perspective this could be confusing when their renders sometimes have odd artefacts in them.
@jorn Thank you for the detailed analysis! You're absolutely correct about the tradeoffs vs Standard, and thanks for the excellent test image showing the errors in my OCIO approximation - I'll use that to fix it.
As I'm sure you know, tone mapping is all tradeoffs - there is no right way. The issues with darkened gradients where dark, saturated colors interpolate across gray is caused by the Fresnel correction and specifically the contrast toe applied based on the minimum of R, G, and B. Basically the problem is that linear interpolation with an applied nonlinear tone mapping curve no longer generates linear gradients. Of course this could be accounted for with nonlinear blending of colors, but few would want to bother. It's closely related to why sharp HDR brightness gradients in environment images tend to look highly pixelated with all tone mappers - since the interpolation happens in linear space, and the nonlinear tone mapping destroys the interpolation gradients.
Of course we can also design test images that showcase the problems of Standard tone mapping that PBR Neutral fixes - @JoelR_VC's HSV sweep is a simple example, particularly for the high end. I'm not proposing that PBR Neutral is better than Standard for every situation - we should absolutely have both. However, for realistic product models under marketing-style lighting, we find it to be a dramatic improvement, despite the tradeoffs you've noted.
Okay, I've improved the OCIO approximation by extending to lower values that cover the low end of sRGB better. Of course it could be further improved by increasing the resolution of the LUT, but I don't think that's necessary. @brecht I've verified I now get
0, 0, 0out for black, and @jorn you can see that the OCIO blender output now matches the GLSL much better:Thanks for the update. Creating a new build for users to test:
@blender-bot package
Package build started. Download here when ready.
So still remaining to be done:
967e36cf68.@brecht Thanks for the pointer - done!
@blender-bot build
One last small update - we just got some feedback that it's very useful to have analytical inverses for tone mapping functions. Ours was difficult to invert, but with a tiny change, it becomes trivial. I've made that change here, as it is effectively imperceptible (maximum deviation of < 1%). It corresponds to a one-line change in the GLSL version of the code - details can be found here: https://github.com/google/model-viewer/pull/4716
Khronos now has an official repo for this spec as well: https://github.com/KhronosGroup/ToneMapping
Is great to be analytically invertible, and also great to see an official repository for it!
I do not really see any stoppers from landing this mapper.