blender/blender
blender/blender
192
605
Fork 947
Code Issues 6.4k Pull Requests 1.1k Projects 22 Wiki Activity

Blender applies color management to AOVs, effectively destroying them #83842

New Issue
Closed
opened 2020-12-16 13:07:16 +01:00 by Ludvik Koutny · 30 comments
Ludvik Koutny commented 2020-12-16 13:07:16 +01:00
Contributor
Copy Link

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.79

Blender Version
Broken: version: 2.91.0, branch: master (modified), commit date: 2020-11-25 11:06, hash: b50598bc78
Worked: probably never

Short description of error
Blender applies color management to AOV output, effectively destroying the data. When user uses non standard view transform, such as filmic, which is in fact default now, and then wants to output the AOVs at once using compositor, so they don't have to be manually saved from framebuffer one by one, the filmic color transform is applied to AOVs saved this way, and they end up being useless.
image.png

While regular image save dialog has an option to prevent this, called "Save As Render"
image.png
...the compositor File Output node does not have have this option, and defaults to wrong behavior out of the box, as it would likely be more often used for saving AOV passes, rather than color corrected beauty passes.

Only workaround is to disable Blender-wide color management completely, making it in turn useless, because workflow of constantly turning it off and on whenever user wants to output AOVs is just not acceptable.

Exact steps for others to reproduce the error

  1. Open attached .blend file: ImageToMaterial.zip
  2. Select the plane, and replace the color texture with any arbitrary texture, as I could not share the copyrighted one.
  3. In compositing node, set the file output path to an existing destination
  4. Press render
  5. Compare rendered texture to original source texture
    Result: Texture AOV has different color tones to the original texture due to applied color mapping
    Expected: Color mapping is never ever applied to AOVs
**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.79 **Blender Version** Broken: version: 2.91.0, branch: master (modified), commit date: 2020-11-25 11:06, hash: `b50598bc78` Worked: probably never **Short description of error** Blender applies color management to AOV output, effectively destroying the data. When user uses non standard view transform, such as filmic, which is in fact default now, and then wants to output the AOVs at once using compositor, so they don't have to be manually saved from framebuffer one by one, the filmic color transform is applied to AOVs saved this way, and they end up being useless. ![image.png](https://archive.blender.org/developer/F9512893/image.png) While regular image save dialog has an option to prevent this, called "Save As Render" ![image.png](https://archive.blender.org/developer/F9512895/image.png) ...the compositor File Output node does not have have this option, and defaults to wrong behavior out of the box, as it would likely be more often used for saving AOV passes, rather than color corrected beauty passes. Only workaround is to disable Blender-wide color management completely, making it in turn useless, because workflow of constantly turning it off and on whenever user wants to output AOVs is just not acceptable. **Exact steps for others to reproduce the error** 1. Open attached .blend file: [ImageToMaterial.zip](https://archive.blender.org/developer/F9512900/ImageToMaterial.zip) 2. Select the plane, and replace the color texture with any arbitrary texture, as I could not share the copyrighted one. 3. In compositing node, set the file output path to an existing destination 4. Press render 5. Compare rendered texture to original source texture Result: Texture AOV has different color tones to the original texture due to applied color mapping Expected: Color mapping is never ever applied to AOVs
Ludvik Koutny commented 2020-12-16 13:07:16 +01:00
Author
Contributor
Copy Link

Added subscriber: @Rawalanche

Added subscriber: @Rawalanche
Robert Guetzkow commented 2020-12-16 13:14:00 +01:00
Member
Copy Link

Added subscriber: @rjg

Added subscriber: @rjg
Robert Guetzkow commented 2020-12-16 13:14:00 +01:00
Member
Copy Link

@Rawalanche as far as I'm aware the file output node doesn't have any knowledge about the source of the data you're passing into it and thus can't / doesn't treat the input from AOVs differently. You would want to use OpenEXR as output format as this stores the values as is. Besides the view transform being applied on other formats, it's generally not advisable to use PNG for AOVs, even when setting the view transform to RAW, as all values have to be mapped to integer values in the [0, 255] range. This means you will always be losing information / precision in the process when using PNG and won't get the exact same results back as the original AOV when loading the saved image into Blender or another application.

@Rawalanche as far as I'm aware the file output node doesn't have any knowledge about the source of the data you're passing into it and thus can't / doesn't treat the input from AOVs differently. You would want to use OpenEXR as output format as this stores the values as is. Besides the view transform being applied on other formats, it's generally not advisable to use PNG for AOVs, even when setting the view transform to RAW, as all values have to be mapped to integer values in the [0, 255] range. This means you will always be losing information / precision in the process when using PNG and won't get the exact same results back as the original AOV when loading the saved image into Blender or another application.
Ludvik Koutny commented 2020-12-16 13:49:18 +01:00
Author
Contributor
Copy Link

In #83842#1076371, @rjg wrote:
@Rawalanche as far as I'm aware the file output node doesn't have any knowledge about the source of the data you're passing into it and thus can't / doesn't treat the input from AOVs differently. You would want to use OpenEXR as output format as this stores the values as is. Besides the view transform being applied on other formats, it's generally not advisable to use PNG for AOVs, even when setting the view transform to RAW, as all values have to be mapped to integer values in the [0, 255] range. This means you will always be losing information / precision in the process when using PNG and won't get the exact same results back as the original AOV when loading the saved image into Blender or another application.

That does not apply when you use AOVs for example to generate texture sets for games, where EXR is (often incompatible and/or harder to edit in image editing software) overkill. PNG is nothing more than a data container, so there is absolutely no excuse for making assumptions of whether or not user wants to store color managed data within it. I guess that when you look at the render layers, and see "BaseColor", "Roughness" and "Normal", you can already tell what I am trying to achieve. I am trying to bypass Blender's unusable texture baking tools using AOVs, but even when trying to output those, Blender throws sticks under my feet.

Let me put it differently. Ask yourself if there is any excuse to not have the "Save As Render" switch present in the File Output compositor node, when it's present in all other places where Blender outputs texture files.

> In #83842#1076371, @rjg wrote: > @Rawalanche as far as I'm aware the file output node doesn't have any knowledge about the source of the data you're passing into it and thus can't / doesn't treat the input from AOVs differently. You would want to use OpenEXR as output format as this stores the values as is. Besides the view transform being applied on other formats, it's generally not advisable to use PNG for AOVs, even when setting the view transform to RAW, as all values have to be mapped to integer values in the [0, 255] range. This means you will always be losing information / precision in the process when using PNG and won't get the exact same results back as the original AOV when loading the saved image into Blender or another application. That does not apply when you use AOVs for example to generate texture sets for games, where EXR is (often incompatible and/or harder to edit in image editing software) overkill. PNG is nothing more than a data container, so there is absolutely no excuse for making assumptions of whether or not user wants to store color managed data within it. I guess that when you look at the render layers, and see "BaseColor", "Roughness" and "Normal", you can already tell what I am trying to achieve. I am trying to bypass Blender's unusable texture baking tools using AOVs, but even when trying to output those, Blender throws sticks under my feet. Let me put it differently. Ask yourself if there is any excuse to not have the "Save As Render" switch present in the File Output compositor node, when it's present in all other places where Blender outputs texture files.
Robert Guetzkow commented 2020-12-16 14:00:30 +01:00
Member
Copy Link

@Rawalanche it's a missing feature as the node currently has no way of knowing that you don't want the view transform to be applied.

@Rawalanche it's a missing feature as the node currently has no way of knowing that you don't want the view transform to be applied.
Ludvik Koutny commented 2020-12-16 14:41:42 +01:00
Author
Contributor
Copy Link

In #83842#1076435, @rjg wrote:
@Rawalanche it's a missing feature as the node currently has no way of knowing that you don't want the view transform to be applied.

Inability for user to prevent certain image formats from being saved with color transform walks a line between missing feature and a bug.

There's a difference between new feature as in user being able to do something they were not able to do before, and new feature as in being able to use existing feature without problems.

> In #83842#1076435, @rjg wrote: > @Rawalanche it's a missing feature as the node currently has no way of knowing that you don't want the view transform to be applied. Inability for user to prevent certain image formats from being saved with color transform walks a line between missing feature and a bug. There's a difference between new feature as in user being able to do something they were not able to do before, and new feature as in being able to use existing feature without problems.
Philipp Oeser commented 2020-12-16 15:14:07 +01:00
Member
Copy Link

Added subscriber: @lichtwerk

Added subscriber: @lichtwerk
Philipp Oeser commented 2020-12-16 15:14:07 +01:00
Member
Copy Link

Note: even EXR has its issues with multiple layers, see #68239 (Cryptomatte affected by Color Space change in OpenEXR multilayer.)

Note: even EXR has its issues with multiple layers, see #68239 (Cryptomatte affected by Color Space change in OpenEXR multilayer.)
Robert Guetzkow commented 2020-12-16 15:33:32 +01:00
Member
Copy Link

@lichtwerk From my understanding this is a different issue, as this happens when loading an existing multi-layer image and selecting the color space that is then indiscriminately applied to all layers. The problem in this ticket is just that the file output node has no option to disable the view transform for non-color data (except for when using OpenEXR as output format).

@lichtwerk From my understanding this is a different issue, as this happens when loading an existing multi-layer image and selecting the color space that is then indiscriminately applied to all layers. The problem in this ticket is just that the file output node has no option to disable the view transform for non-color data (except for when using OpenEXR as output format).
Philipp Oeser commented 2020-12-16 15:39:36 +01:00
Member
Copy Link

Yep, they are different issues, was just noting that it is always necessary to be able to specify which data is being colormanaged and which is not [but admit I was a bit off-topic here]

Yep, they are different issues, was just noting that it is always necessary to be able to specify which data is being colormanaged and which is not [but admit I was a bit off-topic here]
Brecht Van Lommel commented 2020-12-16 19:05:22 +01:00
Owner
Copy Link

Added subscriber: @brecht

Added subscriber: @brecht
Brecht Van Lommel commented 2020-12-16 19:05:22 +01:00
Owner
Copy Link

Changed status from 'Needs Triage' to: 'Archived'

Changed status from 'Needs Triage' to: 'Archived'
Brecht Van Lommel commented 2020-12-16 19:05:22 +01:00
Owner
Copy Link

I've added this issue to the list in #68926 (Color Management Improvements) now.

We recommend using OpenEXR for digital intermediates, which avoids this problem.

Also note that when saving to PNG, color management is in fact needed. It needs to write sRGB per the PNG spec, and because 8bit can not store linear colors without significant data loss. What you want in this case would be an option to skip the artistic choices like Filmic, but still convert linear to sRGB.

I've added this issue to the list in #68926 (Color Management Improvements) now. We recommend using OpenEXR for digital intermediates, which avoids this problem. Also note that when saving to PNG, color management is in fact needed. It needs to write sRGB per the PNG spec, and because 8bit can not store linear colors without significant data loss. What you want in this case would be an option to skip the artistic choices like Filmic, but still convert linear to sRGB.
Ludvik Koutny commented 2020-12-17 09:53:50 +01:00
Author
Contributor
Copy Link

In #83842#1076710, @brecht wrote:
I've added this issue to the list in #68926 (Color Management Improvements) now.

We recommend using OpenEXR for digital intermediates, which avoids this problem.

Also note that when saving to PNG, color management is in fact needed. It needs to write sRGB per the PNG spec, and because 8bit can not store linear colors without significant data loss. What you want in this case would be an option to skip the artistic choices like Filmic, but still convert linear to sRGB.

As I wrote, my intention for it was to output PBR texture sets. You can not make assumptions about what user wants to use certain image format for. sRGB is something most engines have direct option to remove on load. I mean most normal maps for games come in 8bit PNGs. EXRs are unacceptable for regular game textures, for many reasons. They are harder to edit in average image editing packages, some engines do not even properly support them, and they don't even display preview thumbnail in Windows file explorer, due to how exotic of a format they are, so that managing a texture libraries becomes complete hell.

Of course I want to convert linear to sRGB. Yes, PNG is dependent on that. But exactly as there is a need to write sRGB per the PNG spec, there is also nothing in the PNG specs saying other color transforms should be written too, so doing this directly, without user's choice is actually against PNG spec. Lastly, the "Save As Render" checkbox already does exactly that, it still applies sRGB to PNG, just not the transforms which are meant for view only.

What are you doing is that you are treating both image format essential standardized transform like sRGB and random, artistic, non standardized transform like Filmic (at least Blender's implementation is non standard) as the same thing, and applying them both forcibly, without user's choice. When you load 8bit file, Unreal Engine has a simple checkbox to counter sRGB transform for linear data saved in 8bit image files:
image.png
But there's nothing to remove Blender's arbitrary filmic transform.

And saying to use EXR for game image textures to solve this issue is like telling person stuck in a highway traffic they should have used a helicopter instead to avoid the problem.

This is LITERALLY just about adding the already existing "Save As Render" checkbox to the File Output compositor node. So please do not just clean this up into some old Color Management Improvements task where it will rot for several years before the task will eventually be forgotten.

> In #83842#1076710, @brecht wrote: > I've added this issue to the list in #68926 (Color Management Improvements) now. > > We recommend using OpenEXR for digital intermediates, which avoids this problem. > > Also note that when saving to PNG, color management is in fact needed. It needs to write sRGB per the PNG spec, and because 8bit can not store linear colors without significant data loss. What you want in this case would be an option to skip the artistic choices like Filmic, but still convert linear to sRGB. As I wrote, my intention for it was to output PBR texture sets. You can not make assumptions about what user wants to use certain image format for. sRGB is something most engines have direct option to remove on load. I mean most normal maps for games come in 8bit PNGs. EXRs are unacceptable for regular game textures, for many reasons. They are harder to edit in average image editing packages, some engines do not even properly support them, and they don't even display preview thumbnail in Windows file explorer, due to how exotic of a format they are, so that managing a texture libraries becomes complete hell. Of course I want to convert linear to sRGB. Yes, PNG is dependent on that. But exactly as there is a need to write sRGB per the PNG spec, there is also nothing in the PNG specs saying other color transforms should be written too, so doing this directly, without user's choice is actually against PNG spec. Lastly, the "Save As Render" checkbox already does exactly that, it still applies sRGB to PNG, just not the transforms which are meant for view only. What are you doing is that you are treating both image format essential standardized transform like sRGB and random, artistic, non standardized transform like Filmic (at least Blender's implementation is non standard) as the same thing, and applying them both forcibly, without user's choice. When you load 8bit file, Unreal Engine has a simple checkbox to counter sRGB transform for linear data saved in 8bit image files: ![image.png](https://archive.blender.org/developer/F9514621/image.png) But there's nothing to remove Blender's arbitrary filmic transform. And saying to use EXR for game image textures to solve this issue is like telling person stuck in a highway traffic they should have used a helicopter instead to avoid the problem. This is LITERALLY just about adding the already existing "Save As Render" checkbox to the File Output compositor node. So please do not just clean this up into some old Color Management Improvements task where it will rot for several years before the task will eventually be forgotten.
Robert Guetzkow commented 2020-12-17 10:03:34 +01:00
Member
Copy Link

@Rawalanche We recognize that there is a need for this so it has been added to the ToDo task. It will be worked on when developers have time to look into this, just as it would with a bug report. While we understand that you consider this a very important issue that is best solved right away, we still need to organize the development and prioritize tasks.

@Rawalanche We recognize that there is a need for this so it has been added to the *ToDo* task. It will be worked on when developers have time to look into this, just as it would with a bug report. While we understand that you consider this a very important issue that is best solved right away, we still need to organize the development and prioritize tasks.
Robert Guetzkow commented 2020-12-17 10:16:30 +01:00
Member
Copy Link

In the meantime, until this feature is added, I would suggest you set the View Transform to Raw and the file output format to PNG. This should give you the desired result for your intended use case with the AOVs. The current downside is that this applies globally and your render / composite will also be affected by this setting.

In the meantime, until this feature is added, I would suggest you set the *View Transform* to *Raw* and the file output format to PNG. This should give you the desired result for your intended use case with the AOVs. The current downside is that this applies globally and your render / composite will also be affected by this setting.
Ludvik Koutny commented 2020-12-17 12:33:36 +01:00
Author
Contributor
Copy Link

In #83842#1077086, @rjg wrote:
In the meantime, until this feature is added, I would suggest you set the View Transform to Raw and the file output format to PNG. This should give you the desired result for your intended use case with the AOVs. The current downside is that this applies globally and your render / composite will also be affected by this setting.

Yes, I am aware of the workaround, that's what I am doing, but currently, for this particular use case of baking PBR texture sets, I want to be able to do both outputting of the correct data as well as viewing what I am working on in a color managed environment at the same time. Users should not be forced to make a choice between one of these two things or have to do constant chores of turning color management off and on all over again depending of if they are about to save the output. So that's why this is important.

> In #83842#1077086, @rjg wrote: > In the meantime, until this feature is added, I would suggest you set the *View Transform* to *Raw* and the file output format to PNG. This should give you the desired result for your intended use case with the AOVs. The current downside is that this applies globally and your render / composite will also be affected by this setting. Yes, I am aware of the workaround, that's what I am doing, but currently, for this particular use case of baking PBR texture sets, I want to be able to do both outputting of the correct data as well as viewing what I am working on in a color managed environment at the same time. Users should not be forced to make a choice between one of these two things or have to do constant chores of turning color management off and on all over again depending of if they are about to save the output. So that's why this is important.
blender-admin commented 2021-01-13 11:01:44 +01:00
Copy Link

This issue was referenced by 27b78c9c94

This issue was referenced by 27b78c9c94baf6fa43268e851de58da96f7d7123
Martynas Žiemys commented 2021-01-22 17:13:47 +01:00
Copy Link

Added subscriber: @MartinZ

Added subscriber: @MartinZ
Martynas Žiemys commented 2021-01-22 17:13:47 +01:00
Copy Link

This comment was removed by @MartinZ

*This comment was removed by @MartinZ*
Brecht Van Lommel commented 2021-01-22 17:24:31 +01:00
Owner
Copy Link

Feel free to comment if you have a constructive suggestion for a better name and description, developer.blender.org is not the place to rant.

Feel free to comment if you have a constructive suggestion for a better name and description, developer.blender.org is not the place to rant.
Martynas Žiemys commented 2021-01-22 17:32:54 +01:00
Copy Link

Well, I would gladly do that, but I am afraid it seems I have no way of knowing what it does exactly like most users without deep understanding how Blender's code works and ability to program in C. I am guessing it disables color transforms set in Color Management settings and outputs raw values, is this what it does? In that case why not call it "Disable color transforms" ? Or if it applies other transforms, why not say "Apply x color transforms" where x is those color transforms...

Well, I would gladly do that, but I am afraid it seems I have no way of knowing what it does exactly like most users without deep understanding how Blender's code works and ability to program in C. I am guessing it disables color transforms set in Color Management settings and outputs raw values, is this what it does? In that case why not call it "Disable color transforms" ? Or if it applies other transforms, why not say "Apply x color transforms" where x is those color transforms...
Robert Guetzkow commented 2021-01-22 18:28:27 +01:00
Member
Copy Link

@MartinZ This has been partly discussed in D9921.

In D9921#248137, @rjg wrote:
I think I would rename "Save As Render" to "Apply Color Management Settings" and have the description read "Apply the scene's color management settings such as view transform, look and exposure. If this option is disable it will still use the Standard view transform to map the data into the target color space of the image format."

This should get addressed in the near future.

@MartinZ This has been partly discussed in [D9921](https://archive.blender.org/developer/D9921). > In [D9921](https://archive.blender.org/developer/D9921)#248137, @rjg wrote: > I think I would rename "Save As Render" to "Apply Color Management Settings" and have the description read "Apply the scene's color management settings such as view transform, look and exposure. If this option is disable it will still use the Standard view transform to map the data into the target color space of the image format." This should get addressed in the near future.
Martynas Žiemys commented 2021-01-22 18:52:24 +01:00
Copy Link

Sounds better. Of course "Standard view transform" is just as meaningless, if the standard is not defined. This is another big issue. What is standard? Why not specify the standard just there? Is it sRGB IEC61966-2.1? Or is it any other standard? Why hide it?..

Sounds better. Of course "Standard view transform" is just as meaningless, if the standard is not defined. This is another big issue. What is standard? Why not specify the standard just there? Is it sRGB IEC61966-2.1? Or is it any other standard? Why hide it?..
Robert Guetzkow commented 2021-01-22 19:03:21 +01:00
Member
Copy Link

@MartinZ The "Standard" in this context refers to the view transform named "Standard" not a specific specification standard. Technically this would depend on the OCIO config used. For Blender without any modifications this would be sRGB as defined by the srgb.spi1d lookup table when using an sRGB display (and a different one when using a different color space for display).

If we were to make larger changes, like renaming the "Standard" view transform, this should rather be planned and addressed in context of #68926 and not just by a single patch without design task.

@MartinZ The "Standard" in this context refers to the [view transform named "Standard" ](https://docs.blender.org/manual/en/dev/render/color_management.html#render) not a specific specification standard. Technically this would depend on the OCIO config used. For Blender without any modifications this would be sRGB as defined by the `srgb.spi1d` lookup table when using an sRGB display (and a different one when using a different color space for display). If we were to make larger changes, like renaming the "Standard" view transform, this should rather be planned and addressed in context of #68926 and not just by a single patch without design task.
Brecht Van Lommel commented 2021-01-22 19:15:02 +01:00
Owner
Copy Link

The OpenColorIO design is have the display device and view transform as independent choices, so that you can switch display devices and keep other color management settings the same. That means "sRGB" should not be in the view transform name.

The OpenColorIO design is have the display device and view transform as independent choices, so that you can switch display devices and keep other color management settings the same. That means "sRGB" should not be in the view transform name.
Martynas Žiemys commented 2021-01-22 19:44:07 +01:00
Copy Link

That makes sense. As long as it's not "Save as Render" with the current tooltip it's way better. I think "Standard" might not be the best choice for the name and it would make more sense to just call it Display Device Transform directly if it is, but what do I know. Even if it is a bit confussing and named "Standard" at least it makes a whole lot more sense than what it is right now.

That makes sense. As long as it's not "Save as Render" with the current tooltip it's way better. I think "Standard" might not be the best choice for the name and it would make more sense to just call it Display Device Transform directly if it is, but what do I know. Even if it is a bit confussing and named "Standard" at least it makes a whole lot more sense than what it is right now.
Evan Wilson commented 2021-01-22 22:42:04 +01:00
Member
Copy Link

Added subscriber: @EAW

Added subscriber: @EAW
Evan Wilson commented 2021-01-22 22:42:04 +01:00
Member
Copy Link

Just a note: OCIO is starting a UX working group to

document a "standard" way of implementing OCIO in an application.

Hopefully it will help users of multiple programs to have a more consistent CM user experience.

Just a note: OCIO is starting a UX working group to >document a "standard" way of implementing OCIO in an application. Hopefully it will help users of multiple programs to have a more consistent CM user experience.
Ludvik Koutny commented 2021-01-23 23:43:24 +01:00
Author
Contributor
Copy Link

From my experience, the output without any color transform is generally referred to in the industry simply as "Linear", so that's what I would call it. "Save as Render" label indeed makes absolutely no sense. Render just means rendered picture, and rendered picture can be color managed or not, depending on how the user intends to use it.

From my experience, the output without any color transform is generally referred to in the industry simply as "Linear", so that's what I would call it. "Save as Render" label indeed makes absolutely no sense. Render just means rendered picture, and rendered picture can be color managed or not, depending on how the user intends to use it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Asset datablocks, libraries, browser and shelf
Interest
Audio
Interest
Automated Testing
Interest
BlendFile
Interest
Blender Asset Bundle
Interest
Code Documentation
Code comments, Python/RNA API descriptions
Interest
Collada
Interest
Compatibility
Backward and forward compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
FBX
FBX I/O related topics
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 & IO
Interest
Platforms & Builds
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
USD
Interest
UV Editing
Interest
Undo
Interest
User Interface
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Wayland windowing on Unix
Interest
Workbench
Interest
glTF
glTF format I/O topics
Interest: X11
Xorg/X11 windowing
Legacy
Asset Browser Project
Archived
Legacy
Blender 2.8 Project
Archived
Legacy
Milestone 1: Basic, Local Asset Browser
Archived
Legacy
OpenGL Error
Archived
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Related to security, see policy: https://developer.blender.org/docs/handbook/bug_reports/vulnerability_reports/
Module
Animation & Rigging
Module
Asset System
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline & IO
Module
Platforms & Builds
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
Windows
Platform
macOS
Severity
High
Severity
Low
Severity
Normal
Severity
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
Archived
Type
Report
Archived
Type
To Do
No Label
Interest
VFX & Video
Module
VFX & Video
Severity
Normal
Status
Archived
Type
Report
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Hoshinova James-McCarthy-4 Sebastian-Herholz casey-bianco-davis gandalf3 Blendify Aaron Carlisle quantimoney Aditya Y Jeppu Alaska Alaska angavrilov Alexander Gavrilov frogstomp Aleš Jelovčan amelief Amélie Fondevilla elubie Andrea Weikert Andy_Goralczyk Andy Goralczyk ankitm Ankit Meel Anthony-Roberts Anthony Roberts antoniov Antonio Vazquez aras_p Aras Pranckevicius Arnd Arnd Marijnissen bartvdbraak Bart van der Braak mont29 Bastien Montagne blender-bot Blender Bot bnagirniak Bogdan Nagirniak BClark Brad Clark brecht Brecht Van Lommel BrianSavery Brian Savery (AMD) ideasman42 Campbell Barton CharlesWardlaw Charles Wardlaw CharlieJolly Charlie Jolly Chris_Blackbourn Chris Blackbourn lateasusual Chris Clyne (Lateasusual) ChrisLend Christoph Lendenfeld HobbesOS Cian Jinks fclem Clément Foucault cmbasnett Colin Basnett Kdaf Colin Marmond dfelinto Dalai Felinto pioverfour Damien Picard DanielBystedt Daniel Bystedt pepe-school-land Daniel Martinez Lara zanqdo Daniel Salazar Mets Demeter Dzadik erik85 Erik Abrahamsson EAW Evan Wilson filedescriptor Falk David fsiddi Francesco Siddi GaiaClary Gaia Clary DagerD Georgiy Markelov mano-wii Germano Cavalcante zazizizou Habib Gahbiche HooglyBoogly Hans Goudey Harley Harley Acheson weasel Henrik D. Hjalti Hjalti Hjálmarsson howardt Howard Trickey nirved-1 Hristo Gueorguiev mod_moder Iliya Katushenock brita Inês Almeida JacquesLucke Jacques Lucke Jason-Fielder Jason Fielder JasonSchleifer Jason schleifer Jebbly Jeffrey Liu Jeroen-Bakker Jeroen Bakker deadpin Jesse Yurkovich neXyon Joerg Mueller eliphaz John Kiril Swenson guitargeek Johnny Matthews Brainzman Jonas Holzman JoniMercado Jonatan Mercado JorgeBernalMartinez Jorge Bernal JosephEagar Joseph Eagar JoshuaLeung Joshua Leung Bone-Studio Juan Gea jpbouza-4 Juan Pablo Bouza JulianEisel Julian Eisel JulienDuroure Julien Duroure JulienKaspar Julien Kaspar kevindietrich Kévin Dietrich lone_noel Leon Schittek LucianoMunoz Luciano Muñoz Sessarego LukasStockner Lukas Stockner LukasTonne Lukas Tönne LunaRood Luna Rood MaiLavelle Mai Lavelle EosFoxx Marion Stalke Baardaap Martijn Versteegh scorpion81 Martin Felke mendio Matias Mendiola Matt-McLin Matt McLin MetinSeven Metin Seven wave Michael B Johnson Michael-Jones Michael Jones (Apple) makowalski Michael Kowalski pragma37 Miguel Pozo nrupsis Nate Rupsis jesterking Nathan Letwory nathanvegdahl Nathan Vegdahl PrototypeNM1 Nicholas Rishel nickberckley Nika Kutsniashvili Sirgienko Nikita Sirgienko OmarEmaraDev Omar Emara pablovazquez Pablo Vazquez PaoloAcampora Paolo Acampora PascalSchon Pascal Schön pmoursnv Patrick Mours muxed-reality Peter Kim lichtwerk Philipp Oeser P2design Pierrick PICAUT PratikPB2123 Pratik Borhade Limarest Ramil Roosileht farsthary Raul Fernandez Hernandez LazyDodo Ray molenkamp iss Richard Antalik rjg Robert Guetzkow salipour Sahar A. Kashi Sayak-Biswas Sayak Biswas Sean-Kim Sean Kim sherholz Sebastian Herholz sebastian_k Sebastian Koenig ZedDB Sebastian Parborg sebbas Sebastián Barschkis Sergey Sergey Sharybin IRIEShinsuke Shinsuke Irie sidd017 Siddhartha Jejurkar SietseB Sietse Brouwer SimonThommes Simon Thommes SonnyCampbell_Unity Sonny Campbell Stefan_Werner Stefan Werner Lockal Sv. Lockal dr.sybren Sybren A. Stüvel ThomasDinges Thomas Dinges Ton Ton Roosendaal BassamKurdali Ursula kurdali Vasyl-Pidhirskyi Vasyl Pidhirskyi WannesMalfait Wannes Malfait wbmoss_dev Wayde Moss weizhen Weizhen Huang leesonw William Leeson xavierh Xavier Hallade jenkm Yevgeny Makarov ChengduLittleA YimingWu gfxcoder jon denning
No Assignees
7 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: blender/blender#83842
No description provided.
Delete Branch "%!s()"

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?