Color management: Support white balance as part of the display transform #123278

Merged
Lukas Stockner merged 17 commits from LukasStockner/blender:white-balance into main 2024-06-27 23:28:14 +02:00
Member

This implements a von-Kries-style chromatic adaption using the Bradford matrix.
The adaption is performed in scene linear space in the OCIO GLSL shader, with
the matrix being computed on the host.

The parameters specify the white point of the input, which is to be mapped to
the white point of the scene linear space. The main parameter is temperature,
specified in Kelvin, which defines the blackbody spectrum that is used as the
input white point. Additionally, a tint parameter can be used to shift the
white point away from pure blackbody spectra (e.g. to match a D illuminant).

The defaults are set to match D65 so there is no immediate color shift when
enabling the option. Tint = 10 is needed since the D-series illuminants aren't
perfect blackbody emitters.

As an alternative to manually specifying the values, there's also a color
picker. When a color is selected, temperature and tint are set such that this
color ends up being balanced to white.
This only works if the color is close enough to a blackbody emitter -
specifically, for tint values within +-150. Beyond this, there can be ambiguity
in the representation.
Currently, in this case, the input is just ignored and temperature/tint aren't
changed. Ideally, we'd eventually give UI feedback for this.

Presets are supported, and all the CIE standard illuminants are included.

One part that I'm not quite happy with is that the tint parameter starts to
give weird results at moderate values when the temperature is low.
The reason for this can be seen here:
https://commons.wikimedia.org/wiki/File:Planckian-locus.png
Tint is moving along the isotherm lines (with the plot corresponding to +-150),
but below 4000K some of that range is outside of the gamut. Not much can
be done there, other than possibly clipping those values...

Adding support for this to the compositor should be quite easy and is planned
as a next step.

This implements a von-Kries-style chromatic adaption using the Bradford matrix. The adaption is performed in scene linear space in the OCIO GLSL shader, with the matrix being computed on the host. The parameters specify the white point of the input, which is to be mapped to the white point of the scene linear space. The main parameter is temperature, specified in Kelvin, which defines the blackbody spectrum that is used as the input white point. Additionally, a tint parameter can be used to shift the white point away from pure blackbody spectra (e.g. to match a D illuminant). The defaults are set to match D65 so there is no immediate color shift when enabling the option. Tint = 10 is needed since the D-series illuminants aren't perfect blackbody emitters. As an alternative to manually specifying the values, there's also a color picker. When a color is selected, temperature and tint are set such that this color ends up being balanced to white. This only works if the color is close enough to a blackbody emitter - specifically, for tint values within +-150. Beyond this, there can be ambiguity in the representation. Currently, in this case, the input is just ignored and temperature/tint aren't changed. Ideally, we'd eventually give UI feedback for this. Presets are supported, and all the CIE standard illuminants are included. One part that I'm not quite happy with is that the tint parameter starts to give weird results at moderate values when the temperature is low. The reason for this can be seen here: https://commons.wikimedia.org/wiki/File:Planckian-locus.png Tint is moving along the isotherm lines (with the plot corresponding to +-150), but below 4000K some of that range is outside of the gamut. Not much can be done there, other than possibly clipping those values... Adding support for this to the compositor should be quite easy and is planned as a next step.
Lukas Stockner added the
Module
Render & Cycles
label 2024-06-16 03:43:11 +02:00
Lukas Stockner added this to the Render & Cycles project 2024-06-16 03:43:22 +02:00
Lukas Stockner requested review from Brecht Van Lommel 2024-06-16 03:43:35 +02:00
Lukas Stockner requested review from Sergey Sharybin 2024-06-16 03:43:35 +02:00

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR123278) when ready.
Sergey Sharybin reviewed 2024-06-17 11:16:51 +02:00
Sergey Sharybin left a comment
Owner

Nice progress! Thanks for looking into it.

Either I am missing something, or the white balance is missing for the CPU implementation.
The CPU codepaths need to support it, as they are used for the file output.

For picking white color from an image is fine to implement it as a follow-up development to keep scoping of every PR small, but that is something that people would really love to see. From the implementation perspective, OCIO is supposed to provide a way to invert transform. It gives a solution anyway, as not all transforms are a bijection. We'd need to implement an inversion of RGB curves though (as they are applied outside of the OCIO pipeline).

Nice progress! Thanks for looking into it. Either I am missing something, or the white balance is missing for the CPU implementation. The CPU codepaths need to support it, as they are used for the file output. For picking white color from an image is fine to implement it as a follow-up development to keep scoping of every PR small, but that is something that people would really love to see. From the implementation perspective, OCIO is supposed to provide a way to invert transform. It gives a solution anyway, as not all transforms are a bijection. We'd need to implement an inversion of RGB curves though (as they are applied outside of the OCIO pipeline).
@ -153,0 +174,4 @@
view = scene.view_settings
layout.use_property_split = False
layout.use_property_decorate = False # No animation.

I keep seeing this used in many places of UI, even for properties which perfectly support animation. What is the reason for this?

I keep seeing this used in many places of UI, even for properties which perfectly support animation. What is the reason for this?
Author
Member

Honestly, not sure. I just copied the Curves panel.

Honestly, not sure. I just copied the Curves panel.

It's a convention for the render properties. For two reasons:

  • It adds visual clutter for no good reason.
  • Animating most render properties is bad for frame to frame coherence.
It's a convention for the render properties. For two reasons: * It adds visual clutter for no good reason. * Animating most render properties is bad for frame to frame coherence.

Apparently the build is failing (see buildbot for the complete report):
intern/opencolorio/ocio_impl_glsl.cc:786:39: error: ‘white_balance_matrix’ is not a member of ‘blender::math’

Apparently the build is failing (see buildbot for the complete report): `intern/opencolorio/ocio_impl_glsl.cc:786:39: error: ‘white_balance_matrix’ is not a member of ‘blender::math’`
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR123278) when ready.
Author
Member

For the color picking, I'm getting the feeling that instead of trying to invert the display transform, it'll be easier to read the pixel data from the viewport GPU texture before the color management is applied.

In the future, that sort of approach would also allow to do some smarter processing based on the whole viewport instead of just looking at one pixel.

I'm trying to figure out how to get the current viewport pixels (without overlays, without applied color management and without triggering a re-render), but the code is a bit confusing 😅

For the color picking, I'm getting the feeling that instead of trying to invert the display transform, it'll be easier to read the pixel data from the viewport GPU texture before the color management is applied. In the future, that sort of approach would also allow to do some smarter processing based on the whole viewport instead of just looking at one pixel. I'm trying to figure out how to get the current viewport pixels (without overlays, without applied color management and without triggering a re-render), but the code is a bit confusing 😅

I agree it's better to read the scene linear colors directly when possible. eyedropper_color.cc implements this for the image and compositing node editors, and extending that to the 3D viewport would be nice.

But I think the purpose of inverting the display transform is also to make it so that the chosen color is white after the view transform has been applied. I'm guessing that's the default behavior users would want, but I'm not certain. Making a color white in scene linear probably has applications as well.

I agree it's better to read the scene linear colors directly when possible. `eyedropper_color.cc` implements this for the image and compositing node editors, and extending that to the 3D viewport would be nice. But I think the purpose of inverting the display transform is also to make it so that the chosen color is white after the view transform has been applied. I'm guessing that's the default behavior users would want, but I'm not certain. Making a color white in scene linear probably has applications as well.
Author
Member

But I think the purpose of inverting the display transform is also to make it so that the chosen color is white after the view transform has been applied. I'm guessing that's the default behavior users would want, but I'm not certain. Making a color white in scene linear probably has applications as well.

From what I understand, the job of the white balance is to ensure that the selected area ends up being mapped to white in Scene Linear colors to adapt to illumination. What happens afterwards feels out of scope to me, and most options (exposure, gamma, tonemapping etc.) should preserve neutral colors anyways. Using white balance to e.g. counteract some wacky LUT or curves setting doesn't feel right.

> But I think the purpose of inverting the display transform is also to make it so that the chosen color is white after the view transform has been applied. I'm guessing that's the default behavior users would want, but I'm not certain. Making a color white in scene linear probably has applications as well. From what I understand, the job of the white balance is to ensure that the selected area ends up being mapped to white in Scene Linear colors to adapt to illumination. What happens afterwards feels out of scope to me, and most options (exposure, gamma, tonemapping etc.) should preserve neutral colors anyways. Using white balance to e.g. counteract some wacky LUT or curves setting doesn't feel right.

@LukasStockner thanks for the fix for the other platforms. It is still failing on Windows apparently:

FAILED: source/blender/blenlib/CMakeFiles/bf_blenlib.dir/intern/math_color.cc.obj 
C:\Users\blender\git\blender-vexp\blender.git\source\blender\blenlib\intern\math_color.cc(893): error C4244: 'initializing': conversion from '__int64' to 'long', possible loss of data
C:\Users\blender\git\blender-vexp\blender.git\source\blender\blenlib\intern\math_color.cc(893): error C4244: 'initializing': conversion from '__int64' to 'const long', possible loss of data
@LukasStockner thanks for the fix for the other platforms. It is still failing on Windows apparently: ``` FAILED: source/blender/blenlib/CMakeFiles/bf_blenlib.dir/intern/math_color.cc.obj C:\Users\blender\git\blender-vexp\blender.git\source\blender\blenlib\intern\math_color.cc(893): error C4244: 'initializing': conversion from '__int64' to 'long', possible loss of data C:\Users\blender\git\blender-vexp\blender.git\source\blender\blenlib\intern\math_color.cc(893): error C4244: 'initializing': conversion from '__int64' to 'const long', possible loss of data ```

From what I understand, the job of the white balance is to ensure that the selected area ends up being mapped to white in Scene Linear colors to adapt to illumination. What happens afterwards feels out of scope to me, and most options (exposure, gamma, tonemapping etc.) should preserve neutral colors anyways. Using white balance to e.g. counteract some wacky LUT or curves setting doesn't feel right.

Ah yeah, I agree. If the view transform maps white to white it should be ok.

> From what I understand, the job of the white balance is to ensure that the selected area ends up being mapped to white in Scene Linear colors to adapt to illumination. What happens afterwards feels out of scope to me, and most options (exposure, gamma, tonemapping etc.) should preserve neutral colors anyways. Using white balance to e.g. counteract some wacky LUT or curves setting doesn't feel right. Ah yeah, I agree. If the view transform maps white to white it should be ok.
Lukas Stockner force-pushed white-balance from 4a3295f069 to 3e36ed5ee2 2024-06-19 02:00:30 +02:00 Compare
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR123278) when ready.
Sergey Sharybin requested changes 2024-06-19 10:59:22 +02:00
Sergey Sharybin left a comment
Owner

The versioning is lacking a subversion check, which needs to be resolved, and it also makes it harder to demonstrate some other failing case.

The file output seems to behave unexpectedly:

  • Open attached file
  • Set temperature to 9000 and tint to 100 (just some high values, to make colors bvious)
  • Ctrl-F12
  • Compare result in the render window and in the saved .png

Unexpectedly the saved PNG looks different from the render result.

The versioning is lacking a subversion check, which needs to be resolved, and it also makes it harder to demonstrate some other failing case. The file output seems to behave unexpectedly: - Open attached file - Set temperature to 9000 and tint to 100 (just some high values, to make colors bvious) - Ctrl-F12 - Compare result in the render window and in the saved .png Unexpectedly the saved PNG looks different from the render result.
@ -695,0 +714,4 @@
matrix *= xyz_to_scene;
matrix *= blender::math::chromatic_adaption_matrix(temperature, tint, target);
matrix *= scene_to_xyz;
std::cout << matrix << std::endl;

Remove debug print.

Remove debug print.
LukasStockner marked this conversation as resolved
@ -4226,6 +4226,11 @@ void blo_do_versions_400(FileData *fd, Library * /*lib*/, Main *bmain)
* \note Keep this message at the bottom of the function.
*/
LISTBASE_FOREACH (Scene *, scene, &bmain->scenes) {

This needs to happen within a subversion check, and the subversion is to be increased.

This needs to happen within a subversion check, and the subversion is to be increased.
Author
Member

Right, I had skipped it for the initial PR since it probably would have been outdated by the end. I'll add it now.

Right, I had skipped it for the initial PR since it probably would have been outdated by the end. I'll add it now.
Author
Member

Turns out that OCIO expects row-major matrices, so a transpose was missing. Output matches now.

Turns out that OCIO expects row-major matrices, so a transpose was missing. Output matches now.

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR123278) when ready.

@LukasStockner Thanks for the updates. I'll have a closer look tomorrow, and hopefully we can land it soon!

@LukasStockner Thanks for the updates. I'll have a closer look tomorrow, and hopefully we can land it soon!
Brecht Van Lommel approved these changes 2024-06-19 19:54:08 +02:00
Brecht Van Lommel left a comment
Owner

Looks good to me. After Sergey approves this is ok to go in.

Looks good to me. After Sergey approves this is ok to go in.
@ -151,2 +151,4 @@
class RENDER_PT_color_management_white_balance(RenderButtonsPanel, Panel):
bl_label = "Use White Balance"

I think this should just be "White Balance", and "Use Curves" should be changed to "Curves" too.

I think this should just be "White Balance", and "Use Curves" should be changed to "Curves" too.
Lukas Stockner force-pushed white-balance from 6d2d3acde8 to 3ab6107a64 2024-06-20 00:11:59 +02:00 Compare
Author
Member

Okay, I got the color picking inversion working, and it changes the existing code enough that updating this PR makes more sense than creating a follow-up.

Panel names are also changed.

@blender-bot package

Okay, I got the color picking inversion working, and it changes the existing code enough that updating this PR makes more sense than creating a follow-up. Panel names are also changed. @blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR123278) when ready.

Not a blocker for this, just thinking out loud.

It would be nice if there was a color picker button in the top right of the panel (same place as presets button). However that would require implementing either:

  • A new WM_OT_context_eyedropper_color operator, using an RNA path like similar operators
  • Making UI_OT_eyedropper_color read from context somehow, perhaps by supporting overriding the result of UI_context_active_but_prop_get through context_pointer_set and context_string_set
Not a blocker for this, just thinking out loud. It would be nice if there was a color picker button in the top right of the panel (same place as presets button). However that would require implementing either: * A new `WM_OT_context_eyedropper_color` operator, using an RNA path like similar operators * Making `UI_OT_eyedropper_color` read from context somehow, perhaps by supporting overriding the result of `UI_context_active_but_prop_get` through `context_pointer_set` and `context_string_set`

UI Labels: "Must use English MLA title case"

For this PR it means that: "White point" should be renamed to "White Point".

[UI Labels: "Must use English MLA title case" ](https://developer.blender.org/docs/features/interface/human_interface_guidelines/writing_style/#ui-labels) For this PR it means that: "White point" should be renamed to "White Point".
Dalai Felinto reviewed 2024-06-20 10:02:36 +02:00
@ -1312,0 +1351,4 @@
"rna_ColorManagedViewSettings_whitepoint_set",
nullptr);
RNA_def_property_ui_text(prop,
"White point",

Here ^

Here ^

Happy to see that this works for EEVEE as well, not only Cycles. Good job!

Happy to see that this works for EEVEE as well, not only Cycles. Good job!
Sergey Sharybin reviewed 2024-06-20 10:11:45 +02:00
Sergey Sharybin left a comment
Owner

There are some confusing things about the color wheel used for the white point:

  • The tweakable range is surely much more narrow than the wheel itself
  • Tweaking the color might also tweak brightnbess
  • Color picker only really works when picking colors near the white

Maybe it is not that unexpected, so perhaps more matter of explaining in the documentation what the expected usage is.
One thing which can be improved (not in this PR, but in general) is the "recovering" from the "invalid" state of the color wheel.

Another aspect I wanted to confirm is the fact that it is considered to be a View Transform. Meaning, when saving renders in EXR the white point is not applied. I think this is correct. But perhaps we'd need to have an ability to override white point as part of the file IO?

There are some confusing things about the color wheel used for the white point: - The tweakable range is surely much more narrow than the wheel itself - Tweaking the color might also tweak brightnbess - Color picker only really works when picking colors near the white Maybe it is not that unexpected, so perhaps more matter of explaining in the documentation what the expected usage is. One thing which can be improved (not in this PR, but in general) is the "recovering" from the "invalid" state of the color wheel. Another aspect I wanted to confirm is the fact that it is considered to be a View Transform. Meaning, when saving renders in EXR the white point is not applied. I think this is correct. But perhaps we'd need to have an ability to override white point as part of the file IO?
@ -659,3 +665,3 @@
config, input, ROLE_SCENE_LINEAR);
OCIO_ConstProcessorRcPtr *processor_to_display = OCIO_createDisplayProcessor(
config, ROLE_SCENE_LINEAR, view, display, look, 1.0f, 1.0f, false);
config, ROLE_SCENE_LINEAR, view, display, look, 1.0f, 1.0f, 0.0f, 0.0f, false, false);

Add a note above that it is scale, exponent, and white balance which are handled outside of the OCIO shader.

Add a note above that it is scale, exponent, and white balance which are handled outside of the OCIO shader.
@ -86,2 +86,4 @@
const float *IMB_colormanagement_get_xyz_to_scene_linear();
/**
* White balance helper functions.

It would be better to explain what they do than to mention it is a helper function. Like, "Set temperature and tint from the given white point".

It would be better to explain what they do than to mention it is a helper function. Like, "Set temperature and tint from the given white point".
Author
Member

The restriction in range is intentional, +-150 tint (technically +- 0.05 delta_uv, but that's the same) is the official CIE threshold for whether expressing a color as a temperature is meaningful. Beyond that, you can get into situations where the inverse mapping isn't unique. I'm not enforcing that in the forward direction, but the inverse might start to act weird otherwise.

In theory, we could also make it so that users can enter any color. For example, Darktable has an enum for Blackbody Temp/Tint, Daylight Temp/Tint or Direct Color. However, I'm not convinced that it makes sense to complicate this feature further, I'd rather keep it simple. In fact, I'd actually like to not display the color and just have a color picker button as Brecht suggested, but this was the easiest to implement for now.

Regarding feedback - I'd like to at least display a "Failed to convert to temperature/tint" report, but I don't think there's a way to access reports from an RNA setter?

Regarding resetting, it might make sense to have presets here for common illuminants.

Regarding EXR outputs, I think an obvious next step would be to add this as an operation to the compositor, similar to the existing colorspace transform node (maybe as a new enum option in the Color Balance node). That way, it would apply to HDR output files as well.

The restriction in range is intentional, +-150 tint (technically +- 0.05 delta_uv, but that's the same) is the official CIE threshold for whether expressing a color as a temperature is meaningful. Beyond that, you can get into situations where the inverse mapping isn't unique. I'm not enforcing that in the forward direction, but the inverse might start to act weird otherwise. In theory, we could also make it so that users can enter any color. For example, Darktable has an enum for Blackbody Temp/Tint, Daylight Temp/Tint or Direct Color. However, I'm not convinced that it makes sense to complicate this feature further, I'd rather keep it simple. In fact, I'd actually like to not display the color and just have a color picker button as Brecht suggested, but this was the easiest to implement for now. Regarding feedback - I'd like to at least display a "Failed to convert to temperature/tint" report, but I don't think there's a way to access reports from an RNA setter? Regarding resetting, it might make sense to have presets here for common illuminants. Regarding EXR outputs, I think an obvious next step would be to add this as an operation to the compositor, similar to the existing colorspace transform node (maybe as a new enum option in the Color Balance node). That way, it would apply to HDR output files as well.
Lukas Stockner added 5 commits 2024-06-20 21:51:11 +02:00
Add Eyedropper operator to panel header
Some checks failed
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
fc04eb4c34
Author
Member

Update:

  • Fix property capitalization
  • Add preset support
  • Add presets for all CIE illuminants
  • Improve comments
  • Support prop_data_path in UI_OT_eyedropper_color
  • Add eyedropper icon to White Balance panel header
Update: - Fix property capitalization - Add preset support - Add presets for all CIE illuminants - Improve comments - Support `prop_data_path` in `UI_OT_eyedropper_color` - Add eyedropper icon to White Balance panel header

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR123278) when ready.
Sergey Sharybin approved these changes 2024-06-26 17:46:31 +02:00
Sergey Sharybin left a comment
Owner

Wow, that is quite a list of presets. But guess people would love to have them all.

The description needs to be updated as the color picker has been implemented. And maybe mentioned the fact that picking might silently fail or do weird thing when picking something that can't be "decomposed" into the blackbody+tint.

There is also some tweak in the UI file, to make things more consistent with usage in other areas.

I don't think it all worth an extra review iteration.

Wow, that is quite a list of presets. But guess people would love to have them all. The description needs to be updated as the color picker has been implemented. And maybe mentioned the fact that picking might silently fail or do weird thing when picking something that can't be "decomposed" into the blackbody+tint. There is also some tweak in the UI file, to make things more consistent with usage in other areas. I don't think it all worth an extra review iteration.
@ -153,0 +194,4 @@
layout.use_property_split = True
layout.use_property_decorate = False # No animation.
layout.enabled = view.use_white_balance

Technically it should be layout.active. The enabled is kind of only for cases when tweaking is not possible at all, without some big consequence (like crash). The Curves aleady use enabled, and I am not sure wy.

Technically it should be `layout.active`. The `enabled` is kind of only for cases when tweaking is not possible at all, without some big consequence (like crash). The Curves aleady use `enabled`, and I am not sure wy.
Author
Member

Wow, that is quite a list of presets. But guess people would love to have them all.

To be honest, I had no idea which ones are relevant in practice so I just took all of them.

> Wow, that is quite a list of presets. But guess people would love to have them all. To be honest, I had no idea which ones are relevant in practice so I just took all of them.
Lukas Stockner force-pushed white-balance from fc04eb4c34 to c9b405587d 2024-06-27 23:22:05 +02:00 Compare
Lukas Stockner merged commit 6967255906 into main 2024-06-27 23:28:14 +02:00
Lukas Stockner deleted branch white-balance 2024-06-27 23:28:17 +02:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
Asset Browser Project
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 Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#123278
No description provided.