Mix node: Color Burn & Dodge is automatically clamping Result #128
Assignees
Triager-bot
Clear assignees
Triager-bot
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Triager-bot/test#128
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/157215
System Information
Operating system: Windows-11-10.0.22621-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070 NVIDIA Corporation NVIDIA 582.28 Vulkan Backend
Blender Version
Broken: version: 5.2.0 Alpha, branch: main, commit date: 2026-02-19 20:47, hash:
9b1e92156d25Worked: (newest version of Blender that worked as expected)
Short description of error
I don't know if this is a bug or not but both color burn and dodge clamp values to 1 and 0 even though clamp result or factor isn't checked?
Here's a showcase of the possible bug where I am doing a negative emession effect and it works just fine on every setting but clamps to 0 when switched to the specified 2.
I checked and it occurs both in cycles and eevee.
Report is clear
LLM Reasoning
Got it, let's see. The bug report has a title, a body with system info (but we ignore that), Blender version, short description, steps to reproduce (the showcase image and the note about negative emission effect clamping), and mentions it happens in both Cycles and Eevee. The description is clear: it's about Color Burn and Dodge nodes automatically clamping results even when clamp isn't checked. The steps are there via the example. So the clarity is good. So the answer should be Yes.
JSON Data
{
"llm_judgement": true,
"processing_time": 6.930498000000001
}
Report is specific
LLM Reasoning
Got it, let's analyze this bug report. The title is "Mix node: Color Burn & Dodge is automatically clamping Result". The body talks about a specific issue where the Mix node's Color Burn and Dodge modes are clamping values to 1 and 0 even when clamp isn't checked. There's a mention of a negative emission effect example, which is a specific scenario. So this is about a particular problem with those mix modes in Blender. Since it's not vague (like just "crashing while rendering") but a specific issue with the Mix node's behavior, the answer should be 'Specific'.
JSON Data
{
"llm_judgement": true,
"processing_time": 8.278611999999999
}
Report flagged as duplicate by LLM
Shader Mix RGB node color burn and color dodge operations clamp incorrectly.
https://projects.blender.org/blender/blender/issues/95890
System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 431.07
Blender Version
Broken: version: 3.0.0, branch: master, commit date: 2021-12-02 18:35, hash:
f1cca30557Worked: (newest version of Blender that worked as expected)
Short description of error
Shader Mix RGB node clamps the output color when using color burn and color dodge blending mode when it shouldn't
Exact steps for others to reproduce the error
When using the mix rgb node in the shader editor the color burn and color dodge blending modes both clamp the output of the node. Color burn clamps it to a 0 to 1 range while color dodge clamps it to a -infinity to 1 range, despite the factor being 0.
Color dodge doesn't match EEVEE, which clamps the lower bound to 0 instead of -infinity.
Test file:
Color_blend_test_file_HDR_input.blend
Thank you and have a great day!
LLM Reasoning
Got it, let's analyze the two bug reports. First, look at the titles: both mention Color Burn and Dodge in Mix nodes. Then the descriptions: Bug 1 says they clamp to 0/1 even without clamping checked, and shows a negative emission example. Bug 2 says Shader Mix RGB node clamps output for those modes, with specific details about color burn (0-1) and color dodge (-infinity to 1). Both are about the same nodes (Mix node in Blender, though one is "Shader Mix RGB" but that's likely the same as the first's Mix node) having incorrect clamping. The steps to reproduce involve using those blending modes and seeing clamping. So they're describing the same issue: the Color Burn and Dodge operations in the Mix node are incorrectly clamping values when they shouldn't. So the answer is Yes.
JSON Data
{
"llm_judgement": true,
"processing_time": 12.947175,
"duplicate_report_number": "95890"
}
Report flagged as NOT a duplicate by LLM
Nodes: Exclusion (Mix Color) clamps negative values even when Clamp Result is disabled
https://projects.blender.org/blender/blender/issues/114242
System Information
Operating system: Windows 10 Home
Graphics card: Intel(R) UHD Graphics 605
Blender Version
Broken: since 3.5 when Exclusion was first implemented, (still persists in 4.0 and 4.1 daily builds)
Short description of error
When the blend type of the
Mix Colornode is set toExclusion, its output clamps all negative values to 0.0 regardless of whetherClamp Resultis toggled or not. This is true for Shader, Geometry, and Compositor versions of the node.Most sources I could find only mention that Exclusion's formula is
'A + B - 2AB', and don't explicitly mention clamping for negative numbers. This behavior is also inconsistent with other blend types from the same group (i.e. Subtract, & Divide), which allow for negative values. Difference is an exception as it has an absolute value baked into its formula.Exact steps for others to reproduce the error
Mix Colorset toExclusion. (Make sure any of the values lie outside of [0-1] so that the output value goes outside of range)An example .blend file is also attached with examples of both.
LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the key parts: description and steps to reproduce.
Bug report 1 is about Mix node (Color Burn & Dodge) clamping results even when clamp isn't checked. The issue is that Color Burn and Dodge are clamping values to 0 or 1 without the Clamp Result option being enabled. The user mentions negative emission effects clamping to 0.
Bug report 2 is about Mix Color node with Exclusion blend type clamping negative values to 0 even when Clamp Result is disabled. The steps involve using Mix Color set to Exclusion and checking for negative outputs.
Now, are these the same issue? Let's see: both are about Mix nodes (different blend modes) clamping results without Clamp Result being enabled. But wait, the blend modes are different (Color Burn/Dodge vs Exclusion). Also, the first is in 5.2 Alpha, the second since 3.5. The core problem is clamping when it shouldn't, but the specific nodes and blend types differ. So they're not the same issue. Therefore, the answer is No.
JSON Data
{
"llm_judgement": false,
"processing_time": 15.591798999999998,
"duplicate_report_number": "114242"
}
Report flagged as NOT a duplicate by LLM
Cycles Math Node : Clamp does not work
https://projects.blender.org/blender/blender/issues/32431
%%%Hi,
The Clamp option in the Math Node does not seem to work. Please find attached an example blend file, when looking at the final image, it should be a solid colour of .5, instead of 9.5.
Regards
Carlo%%%
LLM Reasoning
Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce.
Bug report 1 is about Mix node (Color Burn & Dodge) automatically clamping results even when clamp isn't checked. The issue is with those specific blend modes in the Mix node, causing values to be clamped to 0 or 1. It mentions negative emission effect and that it happens in Cycles and Eevee.
Bug report 2 is about the Math Node's Clamp option not working. The example says the final image should be .5 but is 9.5, so the clamp isn't applying. This is a different node (Math vs Mix) and a different issue (clamp not working in Math node vs automatic clamping in Mix node).
So the issues are about different nodes and different behaviors. Therefore, they aren't the same. So the answer is No.
JSON Data
{
"llm_judgement": false,
"processing_time": 11.001374,
"duplicate_report_number": "32431"
}
Report flagged as NOT a duplicate by LLM
Holding `Shift X` to sample colors over time doesn't use the drag threshold
https://projects.blender.org/blender/blender/issues/155239
System Information
Operating system: Linux-6.18.8-gentoo-dist-x86_64-AMD_Ryzen_Threadripper_1950X_16-Core_Processor-with-glibc2.41 64 Bits, WAYLAND UI
Graphics card: AMD Radeon RX 7900 XT (RADV NAVI31) Advanced Micro Devices radv Mesa 25.3.3 Vulkan Backend
Blender Version
Broken: version: 5.2.0 Alpha, branch: main, commit date: 2026-03-05 00:31, hash:
ccc8a82099acWorked: (newest version of Blender that worked as expected)
Short description of error
The feature was recently introduced to sample colors over time while holding the shortcut
Shift Xfor color sampling. The result is then mixed from all sampled colors.This regularly happens by accident, especially with a pen input where the cursor movement is faster and more erratic. If the operator would take the drag threshold (`PreferencesInput.drag_threshold_tablet) into account, maybe it would help prevent accidentally triggering it.
Exact steps for others to reproduce the error
Shift Xand minimal mouse movementLLM Reasoning
Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce.
Bug report 1 is about the Mix node (Color Burn & Dodge) clamping results automatically, even when clamp isn't checked. The issue involves color operations in Blender's nodes, affecting cycles and eevee.
Bug report 2 is about the Shift X shortcut for sampling colors over time not respecting the drag threshold, leading to accidental triggers, especially with pen input. The steps involve preferences, vertex paint mode, and mouse movement.
The descriptions are completely different: one is about node operations clamping, the other is about a color sampling shortcut's behavior with thresholds. So they're not the same issue. Therefore, the answer is No.
JSON Data
{
"llm_judgement": false,
"processing_time": 11.751862000000001,
"duplicate_report_number": "155239"
}
Report flagged as duplicate by LLM
MixRGB Color Burn and Color Dodge break HDRs even when Fac=0
https://projects.blender.org/blender/blender/issues/75875
System Information
Operating system: Win10 x64
Graphics card: GTX 1080Ti
Blender Version
Broken: 2.82 - 2.90a f96a689b3be2
Worked: Unknown
Short description of error
In my understanding, when blending Fac=0, it should have no effect on the input Color1 and pass it straight to output.
But that's not the case for Color Burn and Color Dodge modes.
When I plug an HDRI to MixRGB, even at Fac=0 the light becomes very washed out, essentially clamping HDR into LDR.
Changing the blend mode away from Color Burn/Color Dodge to anything else fixes the issue.
How it's supposed to be
How it actually is
Notice Fac=0, meaning no effect.
Cycles + Eevee.
Exact steps for others to reproduce the error
Set up HDR environment texture world background
Add MixRGB between HDRI and Background with Fac=0
Switch to rendered mode
Switch blending mode to Color Burn or Color Dodge, still keeping Fac=0
HDR is broken, now essentially LDR
LLM Reasoning
Got it, let's analyze the two bug reports. First, look at the descriptions and steps.
Bug report 1 talks about Color Burn and Dodge clamping values to 1 and 0 even when clamp isn't checked. The user mentions a negative emission effect that works but clamps when using those modes. They check in Cycles and Eevee.
Bug report 2 is about MixRGB's Color Burn/Dodge breaking HDRs even with Fac=0, causing LDR instead of passing through. Steps: set up HDR, add MixRGB between HDRI and background with Fac=0, switch to those blend modes, HDR becomes washed out (clamped).
Both are about Color Burn and Dodge in Mix node having issues with clamping or affecting output even when they shouldn't (like Fac=0). The core issue seems related to how these blend modes handle values, possibly clamping. Even though the contexts differ (one is negative emission, the other HDR), the underlying problem might be the same: Color Burn/Dodge not behaving as expected with value handling (clamping or affecting output when they shouldn't). So are they duplicates? Let's check.
The key points: both mention Color Burn and Dodge in Mix node, issues with clamping or unexpected behavior. The steps involve using those modes and seeing problems. So yes, likely the same issue.
JSON Data
{
"llm_judgement": true,
"processing_time": 17.520675999999998,
"duplicate_report_number": "75875"
}