IMAGE_OT_new.alpha is incorrect/misleading #138
Assignees
Triager-bot
Clear assignees
Triager-bot
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Triager-bot/test#138
Reference in New Issue
Block a user
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?
Original bug report: https://projects.blender.org/blender/blender/issues/157230
Blender Version
version: 5.1
Short description of error
If you go to image editor and create a new generated image, the 'Alpha' option is misleading.
It says 'create an image with an alpha channel' but the image still has an alpha channel regardless and can have its content erased by the erase brush, showing a checkerboard. The only thing this option does is set the default output option to RGB instead of RGBA, which you can just switch back to export with transparency.
That being said, maybe the tooltip should be updated, maybe the option is not even necessary.
Exact steps for others to reproduce the error
I looked into the code to see why this is:
Report is clear
LLM Reasoning
Got it, let's see. The question is whether the bug report clearly describes the issue. First, I need to check the clarity of the text description and steps to reproduce.
The bug report has a title, short description, exact steps, and even some code investigation. The short description explains that the 'Alpha' option in the image editor's new generated image is misleading because it still creates an alpha channel (since you can erase to see checkerboard) but only changes the default export to RGB instead of RGBA. The steps are clear: open image editor, create new image with Alpha off, use erase brush, check save dialog. Also, the code explanation supports the issue.
So the description is clear. The answer should be 'Yes'.
JSON Data
{
"llm_judgement": true,
"processing_time": 9.520265
}
Report is specific
LLM Reasoning
Got it, let's figure this out. The bug report is about a specific issue: the 'Alpha' option in Blender's image editor when creating a new generated image. It details exactly what happens (misleading tooltip, behavior of the alpha channel, steps to reproduce). So it's not generic; it's about a specific feature's behavior. So the answer should be 'Specific'.
JSON Data
{
"llm_judgement": true,
"processing_time": 6.410213
}
Report flagged as NOT a duplicate by LLM
Saving PNG's with an alpha channel depends on the render settings.
https://projects.blender.org/blender/blender/issues/22691
%%%- In the scene settings set the alpha to 'RGB'
LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the description and steps for each.
Bug report 1: Talks about creating a new generated image in the Image Editor with Alpha off. The issue is that even with Alpha off, the image still has an alpha channel (since the buffer is 4 bytes per pixel), so erasing shows a checkerboard. The save dialog defaults to RGB but can be switched to RGBA.
Bug report 2: Involves scene settings setting alpha to 'RGB', making a new image with alpha 0.5, saving as PNG, then reloading—alpha is gone. So the problem here is about how render settings (scene alpha) affect saving PNGs and losing alpha.
The key difference: Report 1 is about the Image Editor's "New Image" Alpha option being misleading because the buffer still has alpha, while Report 2 is about scene render settings affecting PNG save with alpha. The steps and contexts are different—Report 1 is about image creation in Image Editor, Report 2 is about scene settings and saving as PNG. So they're not the same issue.
JSON Data
{
"llm_judgement": false,
"processing_time": 14.846532000000002,
"duplicate_report_number": "22691"
}
Report flagged as NOT a duplicate by LLM
Generated images with disabled alpha can have alpha but are saved with no alpha, losing user's work
https://projects.blender.org/blender/blender/issues/102080
Simplified Report
This can be even less clear, because some operators like the Lightmap Pack operator can create images with no alpha implicitly, and the user doesn't know this until the alpha data is lost.
Original Report
System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 516.59
Blender Version
Broken: version: 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash:
b292cfe5a9Worked: (newest version of Blender that worked as expected)
Short description of error
when you create a new image texture through the Lightmap Pack feature and paint on it can display as RGBA but the alpha channel gets discarded on save and reopening the file. Images created through other means (like the image shader node or the image panel) do save with alpha channel.
Exact steps for others to reproduce the error
The reason seems to be that lightmap pack generates an RGB file, but it can still appear as RGBA throughout blender until you hit refresh in the image panel or re-open the file. Ideally for my own workflow the lightmap pack feature would allow for creating RGBA files (perhaps an alpha checkbox if it's important for other workflows to not have an alpha channel)
attached file: white cube was made through image shader node, blue cube through image panel generate option, green cube through lightmap pack.
bug.blend
LLM Reasoning
Got it, let's analyze the two bug reports. First, look at the description and steps for each.
Bug Report 1: Talks about creating a new generated image with Alpha off in Image Editor. The issue is that even with Alpha off, the image has an alpha channel (can be erased to show checkerboard), but when saved, it defaults to RGB. The user can switch to RGBA in save dialog. The problem is the misleading tooltip and the default export setting.
Bug Report 2: Focuses on creating a new image via Lightmap Pack with Alpha disabled. When painting, it shows as RGBA, but saving loses alpha (saved as RGB). The steps involve Lightmap Pack, texture painting, then saving—all images lose alpha. Also mentions other methods (image shader node) save with alpha.
Now, check if they're the same issue. Bug 1 is about Image Editor's New Image Alpha option being misleading and defaulting to RGB on save but allowing RGBA export. Bug 2 is about Lightmap Pack creating images that lose alpha when saved, even though they appear as RGBA during use. The core issues are different: Bug 1 is about the UI/tooltip and default export setting for new images in Image Editor; Bug 2 is about Lightmap Pack generating images that discard alpha on save (even if they seem to have it). So they're not the same issue. Therefore, answer is No.
JSON Data
{
"llm_judgement": false,
"processing_time": 20.792621,
"duplicate_report_number": "102080"
}
Report flagged as duplicate by LLM
Storing png/tga images ignore Alpha settings
https://projects.blender.org/blender/blender/issues/27662
%%%When i do a texture bake with "Clear", then apparently the Alpha channel is cleared to 0.
When the bake does not cover the entire image, then all uncovered parts consequently have an Alpha value of 0 when the bake is finished.
When i create a new image and untick the Alpha checkmark, then i expect that the Alpha layer is NOT stored independent if it is filled with data or not.
For png and for tga images the alpha channel is stored.
This problem only ocurs when i bake a texture which does NOT cover the entire image.
For textures which do cover the entire image, i get RGB as expected.
Reproduce:
Remark: It would be sufficient to be able to check/uncheck RGB/RGBA during image save, but nevertheless i think it makes sense to store images with unchecked Alpha as RGB only independent if the image HAS Alpha or not.%%%
LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the descriptions and steps.
Bug report 1 is about the "Alpha" option in creating a new generated image in the Image Editor. The issue is that even when Alpha is turned off, the image still has an alpha channel (since the buffer is 4 bytes per pixel), so erasing shows the checkerboard. The export defaults to RGB but can be changed to RGBA.
Bug report 2 is about texture baking: when creating a new image with Alpha unticked, and doing a bake that doesn't cover the entire image, the alpha channel is stored (set to 0 for uncovered parts). So even though Alpha was unchecked, the alpha channel exists. The user expects that if Alpha is unticked, the image should be RGB only regardless of data.
Wait, but are these the same issue? Let's check the core problem. Bug 1 is about the "Alpha" option in new image creation leading to an alpha channel existing (so erasing shows checkerboard) and export defaulting to RGB but allowing RGBA. Bug 2 is about texture baking where even with Alpha unticked, the alpha channel is stored (because uncovered parts get alpha 0).
But the key here: are they both about the "Alpha" option not working as expected in new image creation vs. texture baking? Wait, no—bug 1 is about creating a new image via Image Editor's New button, bug 2 is about texture baking. But let's check the description of issue and steps.
Bug 1: When creating a new image with Alpha off, the image still has an alpha channel (so erasing shows checkerboard), export defaults to RGB but can be changed. The code reason is that ImBuf always creates 4 channels.
Bug 2: When baking texture on a new image with Alpha unticked, uncovered parts have alpha 0 (so alpha channel exists). So even though Alpha was unticked, the alpha channel is stored. The user expects no alpha channel if Alpha is unticked.
Wait, but are these two reports about the same underlying issue? Let's see: both involve the "Alpha" option in image creation (bug 1) or texture baking (bug 2) not preventing the alpha channel from existing. But bug 1 is about the Image Editor's New button, bug 2 is about texture baking. However, maybe they are related because both deal with the Alpha option not working as expected—i.e., even when Alpha is off, the image still has an alpha channel (so data exists in it).
But wait, let's check the steps. Bug 1's steps: create new image with Alpha off, erase shows checkerboard (alpha exists), export defaults to RGB but can switch to RGBA. Bug 2's steps: create new image with Alpha unticked, bake texture that doesn't cover entire image, alpha channel is stored (uncovered parts have alpha 0).
Are these the same issue? Let's see if the core problem is the same: the "Alpha" option not preventing the existence of an alpha channel. In bug 1, creating a new image with Alpha off still has alpha (so erasing works), in bug 2, baking on such an image stores alpha (even though it's unticked). So both are about the Alpha option not working as expected—i.e., the image still has an alpha channel even when Alpha is disabled.
But wait, maybe they are different because one is about creating a new image via Image Editor, the other via texture baking. But let's check the descriptions again. Bug 1 says "the 'Alpha' option is misleading" because it creates an image with alpha regardless. Bug 2 says "when i create a new image and untick the Alpha checkmark, then i expect that the Alpha layer is NOT stored independent if it is filled with data or not." So both are about the Alpha option not preventing the alpha channel from existing (either in creation or baking).
But wait, maybe they are duplicates? Let's see. The first report is about the Image Editor's New button: when you turn off Alpha, the image still has an alpha channel (so erasing shows checkerboard), and export defaults to RGB but can be changed. The second report is about texture baking on a new image with Alpha unticked: uncovered parts have alpha 0 (so alpha channel exists). So both are about the Alpha option not working as expected—i.e., the image still has an alpha channel even when Alpha is disabled.
But wait, maybe they are different because one is about creation via Image Editor, the other via baking. But let's check if the underlying issue is the same: the code creates an ImBuf with 4 channels regardless of Alpha setting (as per bug 1's code analysis). So in both cases, the alpha channel exists even when Alpha is off.
So are they the same? Let's see. The first report is about creating a new image via Image Editor, the second via texture baking. But the core issue is that the Alpha option doesn't prevent the alpha channel from existing (so data can be written to it). So maybe they are duplicates. Wait, but let's check the steps again.
Bug 1: Steps involve creating a new image in Image Editor, erasing, exporting. Bug 2: Steps involve texture baking on a new image with Alpha unticked. But both are about the Alpha option not working as expected—i.e., the alpha channel exists even when disabled. So maybe they are the same issue.
But wait, let's think again. The first report is about the "Alpha" option in the New Image dialog being misleading because it creates an image with alpha regardless (so erasing shows checkerboard). The second report is about texture baking on such an image storing the alpha channel (even though Alpha was unticked). So both are related to the same underlying problem: the Alpha option doesn't prevent the alpha channel from existing.
So would they be considered duplicates? Let's see. If two reports describe the same issue (Alpha option not working as expected, leading to alpha channel existing even when disabled), then yes. But let's check if there's a difference. The first report is about creating a new image via Image Editor, the second via texture baking. But maybe they are different contexts but same core issue.
Wait, but the user asked to focus on Description of issue and Steps to reproduce. Let's compare:
Bug 1 Description: "the 'Alpha' option is misleading. It says 'create an image with an alpha channel' but the image still has an alpha channel regardless... The only thing this option does is set the default output option to RGB instead of RGBA..."
Bug 2 Description: "when i create a new image and untick the Alpha checkmark, then i expect that the Alpha layer is NOT stored independent if it is filled with data or not. For png and for tga images the alpha channel is stored."
Steps:
Bug 1 Steps: Create new image with Alpha off, erase shows checkerboard (alpha exists), export defaults to RGB but can switch to RGBA.
Bug 2 Steps: Create new image with Alpha unticked, bake texture that doesn't cover entire image, check transparency (RGBA).
So both are about the Alpha option not preventing the alpha channel from existing. So maybe they are duplicates. But wait, is there a difference in context? Bug 1 is about creating a new image via Image Editor's New button, bug 2 is about texture baking on such an image. But the core issue is the same: the Alpha option doesn't work as expected (alpha channel exists even when disabled).
But let's check if they are the same. Let's see: in bug 1, the user is creating a new image and sees that erasing shows checkerboard (so alpha exists). In bug 2, the user is baking on such an image and sees that alpha is stored (uncovered parts have alpha 0). So both are about the alpha channel existing even when Alpha is off.
So maybe they are duplicates. But wait, let's think again. The first report is about the Image Editor's New button, the second about texture baking. Are these two different workflows but same issue? Let's see: the code reason in bug 1 is that ImBuf always creates 4 channels. So regardless of how you create the image (via New or via baking), if Alpha is off, the alpha channel still exists. So both reports are about the same underlying problem.
Therefore, the answer would be Yes? Wait, but wait—maybe not. Let's check again. Bug 1 is about the "Alpha" option in the New Image dialog being misleading because it creates an image with alpha regardless (so erasing shows checkerboard). Bug 2 is about texture baking on such an image storing the alpha channel (even though Alpha was unticked). So both are related to the same issue: the Alpha option doesn't prevent the alpha channel from existing.
But let's see if the steps are similar. Bug 1's step 1: create new image with Alpha off. Bug 2's step 3: create new image with Alpha unticked. Then, bug 1's step 2: erase shows checkerboard (alpha exists). Bug 2's step 4: check transparency (RGBA) (alpha exists). So both steps involve creating a new image with Alpha off/unticked and observing that alpha exists.
So yes, they are the same issue. Therefore, the answer is Yes? Wait, but wait—maybe I'm missing something. Let me recheck.
Wait, bug 1's code analysis says that ImBuf always creates 4 channels regardless of Alpha setting. So in any case where you create an image with Alpha off, the alpha channel exists. Bug 2 is about baking on such an image, which would use that existing alpha channel (setting uncovered parts to 0). So both are about the same underlying problem: the Alpha option doesn't prevent the alpha channel from existing.
Therefore, they are duplicates. So the answer is Yes? Wait, but let's confirm. The user asked for a single word: Yes or No. If unsure, No. But in this case, I think they are the same. So answer is Yes? Wait, no—wait, maybe not. Let me check again.
Wait, bug 1 is about the "Alpha" option in the New Image dialog being misleading because it creates an image with alpha regardless (so erasing shows checkerboard). Bug 2 is about texture baking on such an image storing the alpha channel (even though Alpha was unticked). So both are about the same issue: the Alpha option doesn't work as expected. So yes, they are duplicates. Therefore, the answer is Yes.
JSON Data
{
"llm_judgement": true,
"processing_time": 117.734544,
"duplicate_report_number": "27662"
}
Report flagged as NOT a duplicate by LLM
WebP export fails to preserve Straight Alpha data , unlike AVIF/PNG/JPG2000
https://projects.blender.org/blender/blender/issues/155292
System Information
Operating system: Windows-11-10.0.26100-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1660 NVIDIA Corporation NVIDIA 591.74 Vulkan Backend
Blender Version
Broken: version: 5.1.0 Beta, branch: blender-v5.1-release, commit date: 2026-02-26 00:11, hash:
d36f33c46526Worked: None (This appears to be a consistent implementation flaw in the WebP export module)
Short description of error
When exporting an image as WebP with RGBA enabled, Blender forces Alpha Premultiplication onto the RGB channels, even when:
Alpha is set to "Straight" in the export settings.
Color Management is set to "Non-Color" or "Raw".
This behavior destroys the data integrity of Channel-Packed Textures (e.g., ORM maps where R=Occlusion, G=Roughness, B=Metallic). While WebP is often associated with lossy web compression, the libwebp library supports an -exact flag (for lossless/high-quality) to preserve RGB values under transparent areas. Blender's current implementation seems to lack this data protection, leading to unrecoverable data loss where Alpha < 1.0.
In contrast, other formats like AVIF, PNG, and JPEG 2000 correctly respect the "Straight Alpha" setting in Blender, making this a specific flaw in the WebP export module.
Exact steps for others to reproduce the error
Open Blender and go to the Image Editor.
Drag and drop the attached 1.png (a channel-packed texture).
Set its properties to Alpha: Channel Packed and Color Space: Non-Color. Observe that the RGB data is intact regardless of Alpha.
Save As the image as WebP: Select RGBA, Alpha: Straight, Quality: 100 (or Lossless).
Drag the exported WebP back into Blender.
Compare the WebP with the original: Observe that in areas where Alpha is black (0.0), the RGB data is completely wiped or darkened, proving that premultiplication was forced during export.
Repeat step 4 with AVIF, PNG, or JPEG 2000—their RGB data remains 100% intact.
Observed Result:
WebP export ignores the "Straight" alpha setting and mutates RGB data based on Alpha values.
Expected Result:
WebP should support data-linear export (Straight Alpha) without modifying RGB values, similar to how AVIF and PNG are implemented in Blender.
Technical Note for Developers:
It appears the WebP wrapper in Blender does not pass the necessary flags (like -exact in cwebp) to prevent the encoder from discarding RGB info in transparent/semi-transparent areas. For data-textures (Non-Color), this is critical.
LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the descriptions and steps.
Bug report 1 is about the "Alpha" option in creating a new image in the Image Editor. The issue is that even when Alpha is turned off, the image still has an alpha channel (since the buffer is 4 bytes per pixel), so erasing shows a checkerboard, and the export default is RGB but you can switch to RGBA. The problem is about the misleading tooltip and the option's behavior in new image creation.
Bug report 2 is about WebP export not preserving Straight Alpha data—premultiplication happens even when set to Straight, unlike other formats. The steps involve exporting a channel-packed texture as WebP with Straight Alpha, and seeing RGB data lost where alpha is low. This is about the WebP export module's handling of alpha settings.
The key sections: Description of issue for 1 is about new image creation's Alpha option being misleading (still has alpha, export default). For 2, it's about WebP export not respecting Straight Alpha during export. The steps are different—1 is creating a new image and testing erase/export, 2 is exporting an existing texture as WebP vs other formats.
So they're about completely different issues: one is the UI/behavior of the "Alpha" option when creating new images, the other is WebP export's alpha handling. Therefore, not duplicates.
JSON Data
{
"llm_judgement": false,
"processing_time": 21.317263,
"duplicate_report_number": "155292"
}
Report flagged as NOT a duplicate by LLM
Jpeg 2000 Stores Alpha Transparency Channel Incorrectly
https://projects.blender.org/blender/blender/issues/19280
Group: V 2.49b release
Resolution: Fixed
Category: Rendering (intern)
%%%Discussion here:
http://blenderartists.org/forum/showthread.php?t=165700
Steps to recreate bug:
You should now see the issue in the viewer node (click 'Backdrop' to see a larger version in the background).
Instead of getting pure black (transparent) or pure white (solid) masking, there are shades of gray. Looks likes it saves the luminance channel or something instead of the alpha channel.
For comparison, link up the alpha channel from the 'Render Layer' node to a 'Viewer' node. Or perform the same steps above but saving as a PNG - you will see the alpha channel properly showing.%%%
LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the descriptions and steps.
Bug report 1 is about the "Alpha" option in creating a new image in the Image Editor. The issue is that even when Alpha is turned off, the image still has an alpha channel (since the buffer is 4 bytes per pixel), so erasing shows a checkerboard. The export defaults to RGB but can be changed to RGBA.
Bug report 2 is about Jpeg 2000 storing the alpha channel incorrectly—when saving as JP2 with RGBA, the alpha channel shows shades of gray instead of proper transparency (like black/white). It's about rendering and saving, not creating a new image in the Image Editor. The steps involve rendering a mesh, changing format to Jpeg 2000, and checking the alpha channel.
The core issues are different: one is about the "Alpha" option in new image creation (UI/behavior of the option), the other is about Jpeg 2000's alpha storage during rendering/export. So they're not the same issue.
JSON Data
{
"llm_judgement": false,
"processing_time": 15.640955000000002,
"duplicate_report_number": "19280"
}