UI: Allow Clipboard Copy/Paste Images #105833

Merged
Harley Acheson merged 2 commits from Harley/blender:ClipboardImage into main 2023-04-14 03:48:28 +02:00
Member

Adds operators to copy and paste to and from the OS clipboard, but only
implemented for Windows.


Adds IMAGE_OT_clipboard_copy and IMAGE_OT_clipboard_paste operators that move images in and out of the Image Editor, assigned to Ctrl-C and Ctrl-V. They use new functions WM_clipboard_image_available, WM_clipboard_image_get, and 'WM_clipboard_image_set' which use Ghost to move byte buffers in and out.

This is only implemented for Windows, but it should be fairly easy for others to add the platform-specific ghost routines for Mac and Linux.

On Windows this posts and supports both standard CF_DIBV5 clipboard format and "PNG" format. Newer programs prefer the former and will do so with an alpha channel, but older programs still use the "PNG" clipboard format to support alpha.

In my tests:

  • Gimp in and out with alpha
  • Krita in and out with alpha
  • Affinity Photo 2 in and out with alpha
  • Chrome in with alpha
  • Firefox in with alpha
Adds operators to copy and paste to and from the OS clipboard, but only implemented for Windows. --- Adds `IMAGE_OT_clipboard_copy` and `IMAGE_OT_clipboard_paste` operators that move images in and out of the Image Editor, assigned to Ctrl-C and Ctrl-V. They use new functions `WM_clipboard_image_available`, `WM_clipboard_image_get`, and 'WM_clipboard_image_set' which use Ghost to move byte buffers in and out. This is only implemented for Windows, but it should be fairly easy for others to add the platform-specific ghost routines for Mac and Linux. On Windows this posts and supports both standard `CF_DIBV5` clipboard format and "PNG" format. Newer programs prefer the former and will do so with an alpha channel, but older programs still use the "PNG" clipboard format to support alpha. In my tests: * Gimp in and out with alpha * Krita in and out with alpha * Affinity Photo 2 in and out with alpha * Chrome in with alpha * Firefox in with alpha
Harley Acheson force-pushed ClipboardImage from e62bb834c8 to 2b5d76e48e 2023-03-17 04:06:47 +01:00 Compare
Harley Acheson force-pushed ClipboardImage from 2b5d76e48e to d6f7bb7b5a 2023-03-17 05:17:57 +01:00 Compare
Author
Member

@blender-bot package windows

@blender-bot package windows
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR105833) when ready.
Brecht Van Lommel reviewed 2023-03-17 15:57:15 +01:00
@ -2837,0 +2848,4 @@
}
WM_cursor_set(CTX_wm_window(C), WM_CURSOR_WAIT);
WM_clipboard_image_set(ibuf->rect, ibuf->x, ibuf->y);

Image buffers can be float precision with rect_float, in which case rect will be null. Also, the byte buffer may have various colorspaces as defined by rect_colorspace, while this probably assumes sRGB.

Image buffers can be float precision with `rect_float`, in which case `rect` will be null. Also, the byte buffer may have various colorspaces as defined by `rect_colorspace`, while this probably assumes sRGB.
Harley marked this conversation as resolved
Harley Acheson force-pushed ClipboardImage from 3800a45923 to 35acb9763d 2023-03-17 16:52:42 +01:00 Compare
Author
Member

@brecht - Image buffers can be float precision with rect_float...

Yes, I had that on my todo list to find IMB_rect_from_float. Now done.

Also, the byte buffer may have various colorspaces as defined by rect_colorspace, while this probably assumes sRGB.

Yes, not really thought through. I don't have many options on the Windows side (sRGB or "Windows default color space"). So I guess I should convert from whatever format the image is into sRGB first.

> @brecht - Image buffers can be float precision with rect_float... Yes, I had that on my todo list to find IMB_rect_from_float. Now done. > Also, the byte buffer may have various colorspaces as defined by rect_colorspace, while this probably assumes sRGB. Yes, not really thought through. I don't have many options on the Windows side (sRGB or "Windows default color space"). So I guess I should convert from whatever format the image is into sRGB first.

Yes, always converting to sRGB when needed seems fine for now. I see there's a bunch of colorspace settings in BITMAPV5HEADER, but matching that up to OpenColorIO is going to be difficult.

Yes, always converting to sRGB when needed seems fine for now. I see there's a bunch of colorspace settings in `BITMAPV5HEADER`, but matching that up to OpenColorIO is going to be difficult.
Author
Member

@brecht - always converting to sRGB when needed seems fine for now. I see there's a bunch of colorspace settings in BITMAPV5HEADER, but matching that up to OpenColorIO is going to be difficult.

There are some nice (complex) options in there (BITMAPV5HEADER), but the REAL spoiler here will be the alpha channel.

This clipboard format (CF_DIBV5) was created specifically with alpha in mind. And I see that format coming from Chrome and Firefox and get an image with alpha from them.

But programs that have been around since before this format use PNG as the clipboard format instead. So programs like Gimp will transfer RGB with this but not RGBA. It seems wasteful to put two copies of an image on the clipboard (CF_DIBV5 and PNG), but even worse to put just PNG since that sucks. And the idea of creating/reading PNG from within GHOST_SystemWin32.cpp seems odd but wouldn't kill me. A next step is for me to use EnumClipboardFormats rather than just IsClipboardFormatAvailable and see exactly which formats are offered and in what order.

Oh well, one step at a time. What I don't want is to go from years of not having this to then getting bug reports of "no alpha channel when I copy/paste from X".

> @brecht - always converting to sRGB when needed seems fine for now. I see there's a bunch of colorspace settings in `BITMAPV5HEADER`, but matching that up to OpenColorIO is going to be difficult. There are some nice (complex) options in there (BITMAPV5HEADER), but the REAL spoiler here will be the alpha channel. This clipboard format (CF_DIBV5) was created specifically with alpha in mind. And I see that format coming from Chrome and Firefox and get an image with alpha from them. But programs that have been around since before this format use PNG as the clipboard format instead. So programs like Gimp will transfer RGB with this but not RGBA. It seems wasteful to put two copies of an image on the clipboard (CF_DIBV5 and PNG), but even worse to put just PNG since that sucks. And the idea of creating/reading PNG from within GHOST_SystemWin32.cpp seems odd but wouldn't kill me. A next step is for me to use EnumClipboardFormats rather than just IsClipboardFormatAvailable and see exactly which formats are offered and in what order. Oh well, one step at a time. What I don't want is to go from years of not having this to then getting bug reports of "no alpha channel when I copy/paste from X".

Gimp on Windows I would not use as a reference. But as you mentioned on devtalk it would be good to test alpha in Photoshop and other apps like Affinity, Krita.

Gimp on Windows I would not use as a reference. But as you mentioned on devtalk it would be good to test alpha in Photoshop and other apps like Affinity, Krita.
Harley Acheson force-pushed ClipboardImage from 35acb9763d to 5f0cc3cbd7 2023-03-19 02:49:45 +01:00 Compare
Author
Member

@blender-bot package windows

@blender-bot package windows
Member

Package build started. Download here when ready.

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

This experiment seems to point to the need for an obvious change. Instead of just adding a single type of data to the clipboard we really need to do this properly with ghost functions to "open clipboard", "add clipboard item", and "close clipboard", so that we can make multiple versions of the data available to the consumer. All other programs do so.

We'd also have the option of adding our own custom formats too. For example when you add text to the clipboard you can also add a separate LOCALE format as well. We could do similar with Blender-specific info.

If we are going to be forced to put formatted data (not just buffers) on the clipboard like the "PNG" format used by Gimp, we should also look into creating a "image/exr" format for float images.

This experiment seems to point to the need for an obvious change. Instead of just adding a single type of data to the clipboard we really need to do this properly with ghost functions to "open clipboard", "add clipboard item", and "close clipboard", so that we can make multiple versions of the data available to the consumer. All other programs do so. We'd also have the option of adding our own custom formats too. For example when you add text to the clipboard you can also add a separate [LOCALE](https://learn.microsoft.com/en-us/windows/win32/dataxchg/standard-clipboard-formats?source=recommendations) format as well. We could do similar with Blender-specific info. If we are going to be forced to put formatted data (not just buffers) on the clipboard like the "[PNG](https://www.codeproject.com/Reference/1091137/Windows-Clipboard-Formats)" format used by Gimp, we should also look into creating a "image/exr" format for float images.
Harley Acheson force-pushed ClipboardImage from db73722076 to 924897ce32 2023-03-21 22:22:22 +01:00 Compare
Author
Member

@blender-bot package windows

@blender-bot package windows
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR105833) when ready.
Harley Acheson force-pushed ClipboardImage from d75ac57ab5 to 215fba7227 2023-03-22 23:14:37 +01:00 Compare
Author
Member

@blender-bot package windows

@blender-bot package windows
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR105833) when ready.
Harley Acheson force-pushed ClipboardImage from 215fba7227 to 6b48b88b1f 2023-03-27 23:26:57 +02:00 Compare
Harley Acheson force-pushed ClipboardImage from 6b48b88b1f to 750102d0e5 2023-03-28 17:22:40 +02:00 Compare
Author
Member

Now placing registered clipboard format "PNG" on the clipboard as well as CF_DIBV5. Now able to exchange images with alpha with Gimp and other programs that used that format instead of the new format for alpha.

Currently tested:

  • Gimp in and out with alpha
  • Krita in and out with alpha
  • Affinity Photo 2 in and out with alpha
  • Chrome in with alpha
  • Firefox in with alpha
Now placing registered clipboard format "PNG" on the clipboard as well as CF_DIBV5. Now able to exchange images **with alpha** with Gimp and other programs that used that format instead of the new format for alpha. Currently tested: * Gimp in and out with alpha * Krita in and out with alpha * Affinity Photo 2 in and out with alpha * Chrome in with alpha * Firefox in with alpha
Author
Member

@blender-bot package windows

@blender-bot package windows
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR105833) when ready.
Harley Acheson force-pushed ClipboardImage from c202ee261e to e5f8ae2e1d 2023-03-28 22:27:41 +02:00 Compare
Harley Acheson changed title from WIP: UI: Allow Clipboard Copy/Paste Images to UI: Allow Clipboard Copy/Paste Images 2023-03-28 22:35:24 +02:00
Harley Acheson requested review from Campbell Barton 2023-03-28 22:35:42 +02:00
Harley Acheson force-pushed ClipboardImage from e5f8ae2e1d to 7c1c582fd1 2023-03-29 23:45:59 +02:00 Compare
First-time contributor

Any news on this?

Any news on this?
Author
Member

Any news on this?

Nothing new really. This now seems to work moving RGB between almost everything. And will transfer alpha channel too with most programs, including Gimp, Krita, Affinity Photo, Chrome, Firefox.

But Photoshop remains a spoiler as it will exchange color but not with alpha channel. There doesn't seem to be a solution to this as it looks like they just don't include it in any non-private clipboard format. And their private formats are far too complex and volitile for me to even consider implementing just for that.

Does it really matter if thing work well on everything but Photoshop. Maybe. But I'd still be getting bug reports about it not moving alpha, even though users can continue to transfer using files as they do now.

This PR had some early review and the general shape looks okay. It probably need another round of review because it is implementing PNG clipboard format since the last one.

If you are wondering when we'd get this I wouldn't hold out too much hope for 3.6, although that is still possible. I think it more likely we'll get it into 4.0. We're all just busy and this thing wasn't planned for. I think we'll get it eventually.

> Any news on this? Nothing new really. This now seems to work moving RGB between almost everything. And will transfer alpha channel too with most programs, including Gimp, Krita, Affinity Photo, Chrome, Firefox. But Photoshop remains a spoiler as it will exchange color but not with alpha channel. There doesn't seem to be a solution to this as it looks like they just don't include it in any non-private clipboard format. And their private formats are far too complex and volitile for me to even consider implementing just for that. Does it really matter if thing work well on everything but Photoshop. Maybe. But I'd still be getting bug reports about it not moving alpha, even though users can continue to transfer using files as they do now. This PR had some early review and the general shape looks okay. It probably need another round of review because it is implementing PNG clipboard format since the last one. If you are wondering when we'd get this I wouldn't hold out too much hope for 3.6, although that is still possible. I think it more likely we'll get it into 4.0. We're all just busy and this thing wasn't planned for. I think we'll get it eventually.
Member

This now seems to work moving RGB between almost everything. And will transfer alpha channel too with most programs, including Gimp, Krita, Affinity Photo, Chrome, Firefox.

But Photoshop remains a spoiler as it will exchange color but not with alpha channel. There doesn't seem to be a solution to this as it looks like they just don't include it in any non-private clipboard format. And their private formats are far too complex and volitile for me to even consider implementing just for that.

Photoshop shouldn't be a showstopper for something this useful. Major browsers, GIMP, Krita, and Affinity apps are more than enough.

Is it possible to somehow detect that "things didn't go well"? To notify the user when copying from non-supported apps into Blender that some data couldn't be retrieved/was lost. To minimize somehow the amount of potential bug reports.

> This now seems to work moving RGB between almost everything. And will transfer alpha channel too with most programs, including Gimp, Krita, Affinity Photo, Chrome, Firefox. > > But Photoshop remains a spoiler as it will exchange color but not with alpha channel. There doesn't seem to be a solution to this as it looks like they just don't include it in any non-private clipboard format. And their private formats are far too complex and volitile for me to even consider implementing just for that. Photoshop shouldn't be a showstopper for something this useful. Major browsers, GIMP, Krita, and Affinity apps are more than enough. Is it possible to somehow detect that "things didn't go well"? To notify the user when copying from non-supported apps into Blender that some data couldn't be retrieved/was lost. To minimize somehow the amount of potential bug reports.
Author
Member

Photoshop shouldn't be a showstopper for something this useful. Major browsers, GIMP, Krita, and Affinity apps are more than enough.

I think so too, but it is always a pain when a big player doesn't do it right.

Is it possible to somehow detect that "things didn't go well"? To notify the user when copying from non-supported apps into Blender that some data couldn't be retrieved/was lost. To minimize somehow the amount of potential bug reports.

With the clipboard stuff we don't get a real conversation. When we "copy to the clipboard" we are just making (two different versions of) the image available for others. Then the other program can ask the operating system "do you have anything in this format? and the operating says "yes" so the other program then asks the OS for that thing. We don't even get informed that they grabbed it. In Photoshop's case they get an image that includes alpha that they just ignore.

When we paste from clipboard, there might be a chance. We are doing the reverse, asking the OS "do you have anything on the clipboard I can use?" In the case of Photoshop there is a bunch of different formats, but all of the public ones have alpha but set to 255. So we can't tell if that alpha is correct or not.

But I can guess that we are getting data from Photoshop because of the names of the other formats it offers. So if we are pasting from Photoshop I could at least log a warning or something.

> Photoshop shouldn't be a showstopper for something this useful. Major browsers, GIMP, Krita, and Affinity apps are more than enough. I think so too, but it is always a pain when a big player doesn't do it right. > Is it possible to somehow detect that "things didn't go well"? To notify the user when copying from non-supported apps into Blender that some data couldn't be retrieved/was lost. To minimize somehow the amount of potential bug reports. With the clipboard stuff we don't get a real conversation. When we "copy to the clipboard" we are just making (two different versions of) the image available for others. Then the other program can ask the operating system "do you have anything in this format? and the operating says "yes" so the other program then asks the OS for that thing. We don't even get informed that they grabbed it. In Photoshop's case they get an image that includes alpha that they just ignore. When we **paste** from clipboard, there might be a chance. We are doing the reverse, asking the OS "do you have anything on the clipboard I can use?" In the case of Photoshop there is a bunch of different formats, but all of the public ones have alpha but set to 255. So we can't tell if that alpha is correct or not. But I can guess that we are getting data from Photoshop because of the names of the other formats it offers. So if we are pasting from Photoshop I could at least log a warning or something.
Harley Acheson added this to the User Interface project 2023-04-07 19:17:33 +02:00
Campbell Barton approved these changes 2023-04-13 08:07:13 +02:00
Campbell Barton left a comment
Owner

Accepting with minor requests.

Note that image clipboard support should be added to WM_capabilities_flag(..) which could Python could access via context.window_manager.capabilities. This then we can avoid platform checks in the UI.

This can be done separately though.

Accepting with minor requests. Note that image clipboard support should be added to `WM_capabilities_flag(..)` which could Python could access via `context.window_manager.capabilities`. This then we can avoid platform checks in the UI. This can be done separately though.
@ -2308,0 +2363,4 @@
for (int h = 0; h < height; h++) {
for (int w = 0; w < width; w++, target += 4, source += 4) {
DWORD *pix = (DWORD *)source;
target[0] = (uchar)((*pix & ColorMasks[0]) >> ColorShifts[0]);

picky use function style casts uchar(...) instead of (char).... In case uint8_t(...) makes more sense too.

*picky* use function style casts `uchar(...)` instead of `(char)...`. In case `uint8_t(...)` makes more sense too.
Harley marked this conversation as resolved
@ -207,6 +207,11 @@ class IMAGE_MT_image(Menu):
layout.separator()
layout.operator("image.clipboard_copy", text="Copy")

As this only works on windows, better only show these items on windows.

As this only works on windows, better only show these items on windows.
Harley marked this conversation as resolved
@ -2837,0 +2871,4 @@
return false;
}
if (G.is_rendering) {

This check makes more sense to add into the exec function, reporting an error on failure. This way when pressing Ctrl-C shortcut while rendering - an error will show in the status bar. Also, if the user opens a menu just before render completes, the menu-item won't be outdated.

This check makes more sense to add into the exec function, reporting an error on failure. This way when pressing Ctrl-C shortcut while rendering - an error will show in the status bar. Also, if the user opens a menu just before render completes, the menu-item won't be outdated.
Harley marked this conversation as resolved
Campbell Barton requested changes 2023-04-13 14:53:09 +02:00
@ -1885,6 +1885,8 @@ def km_image_generic(params):
("image.new", {"type": 'N', "value": 'PRESS', "alt": True}, None),
("image.open", {"type": 'O', "value": 'PRESS', "alt": True}, None),
("image.reload", {"type": 'R', "value": 'PRESS', "alt": True}, None),
("image.clipboard_copy", {"type": 'C', "value": 'PRESS', "ctrl": True}, None),

I'd rather leave these disabled for now, as we might want to prioritize Ctrl-C/V keys for UV copy paste when UV editing.

I'd rather leave these disabled for now, as we might want to prioritize Ctrl-C/V keys for UV copy paste when UV editing.
Member

we might want to prioritize Ctrl-C/V keys for UV copy paste when UV editing

Don't the UV Editor and Image Editor have different keymaps?

Copy/Paste UVs is only available in the UV Editor (only Edit mode even), while Copy/Paste images should work in the Image Editor under View (and probably Paint) mode.

The same way that while in Pose mode, Ctrl+C copies the pose to buffer, but in Object mode copies the object.

> we might want to prioritize Ctrl-C/V keys for UV copy paste when UV editing Don't the UV Editor and Image Editor have different keymaps? Copy/Paste UVs is only available in the UV Editor (only Edit mode even), while Copy/Paste images should work in the Image Editor under View (and probably Paint) mode. The same way that while in Pose mode, Ctrl+C copies the pose to buffer, but in Object mode copies the object.
Harley marked this conversation as resolved
@ -2837,0 +2871,4 @@
return false;
}
if (G.is_rendering) {

This check makes more sense to add into the exec function, reporting an error on failure. This way when pressing Ctrl-C shortcut while rendering - an error will show in the status bar. Also, if the user opens a menu just before render completes, the menu-item won't be outdated.

This check makes more sense to add into the exec function, reporting an error on failure. This way when pressing Ctrl-C shortcut while rendering - an error will show in the status bar. Also, if the user opens a menu just before render completes, the menu-item won't be outdated.
Harley marked this conversation as resolved
Author
Member

@ideasman42 - Note that image clipboard support should be added to WM_capabilities_flag(..) which could Python could access via context.window_manager.capabilities. This then we can avoid platform checks in the UI. This can be done separately though.

It seems like the way we use GHOST_CAPABILITY_FLAG_ALL means that we can't add a new flag without touching all the platform files, so hoping you don't mind we do this separately. I could make a PR that not only does that but also adds (empty) functions to the other platforms with nice comments on what they need to do? That way someone with no knowledge of ghost or Blender code can implement on them as easily as possible.

(Re: keymapping) I'd rather leave these disabled for now, as we might want to prioritize Ctrl-C/V keys for UV copy paste when UV editing.

I've taken out those keymap entries and (hopefully) we can get back them in in some fashion before the end of June. We just to be careful that Mac and Linux users don't see an error message if they click an unimplemented ctrl/Command-C.

> @ideasman42 - Note that image clipboard support should be added to WM_capabilities_flag(..) which could Python could access via context.window_manager.capabilities. This then we can avoid platform checks in the UI. This can be done separately though. It _seems_ like the way we use `GHOST_CAPABILITY_FLAG_ALL` means that we can't add a new flag without touching all the platform files, so hoping you don't mind we do this separately. I could make a PR that not only does that but also adds (empty) functions to the other platforms with nice comments on what they need to do? That way someone with no knowledge of ghost or Blender code can implement on them as easily as possible. > (Re: keymapping) I'd rather leave these disabled for now, as we might want to prioritize Ctrl-C/V keys for UV copy paste when UV editing. I've taken out those keymap entries and (hopefully) we can get back them in in some fashion before the end of June. We just to be careful that Mac and Linux users don't see an error message if they click an unimplemented ctrl/Command-C.
Harley Acheson force-pushed ClipboardImage from c38b56e3cf to 7a3846e990 2023-04-14 00:21:39 +02:00 Compare
Campbell Barton approved these changes 2023-04-14 00:45:01 +02:00
Campbell Barton left a comment
Owner

Approving with a minor request.

Approving with a minor request.
@ -2308,0 +2332,4 @@
int offset = bitmapV5Header->bV5Size + bitmapV5Header->bV5ClrUsed * sizeof(RGBQUAD);
if (bitmapV5Header->bV5Compression == BI_BITFIELDS)

picky use braces with all statements.

*picky* use braces with all statements.
Harley marked this conversation as resolved
@ -2065,0 +2087,4 @@
bool WM_clipboard_image_set(ImBuf *ibuf)
{
IMB_rect_from_float(ibuf);

Since this function doesn't know anything else about the ibuf, I think it would be best not to keep the byte-buffer (if it's created).

This can call imb_freerectImBuf(..); in the case there was previously no byte-buffer.

Since this function doesn't know anything else about the `ibuf`, I think it would be best not to keep the byte-buffer (if it's created). This can call `imb_freerectImBuf(..);` in the case there was previously no byte-buffer.
Harley marked this conversation as resolved
Harley Acheson added 1 commit 2023-04-14 03:20:16 +02:00
Changes requested by review.
All checks were successful
buildbot/vexp-code-patch-coordinator Build done.
a8db9ec742
Author
Member

@blender-bot build

@blender-bot build
Harley Acheson merged commit 39bcf6bdc9 into main 2023-04-14 03:48:28 +02:00
Harley Acheson deleted branch ClipboardImage 2023-04-14 03:48:29 +02:00
Sign in to join this conversation.
No reviewers
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Code Documentation
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
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
Viewport & EEVEE
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
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
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
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
Type
Report
Type
To Do
No Milestone
No project
No Assignees
6 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#105833
No description provided.