Custom palette copy of "C9 2" doesn't render the same as C9 2 [fixed in 0.16]

[Sammy1Am]

What happened?

I'm attempting to make a modified version of the built-in "C9 2" palette, but I'm unable to get an identical custom palette to render the same. I initially tried copying the palette values from the source and uploading them to palette0.json on the /edit page, but the colors were off (way less green, much more red overall, if that's helpful). Then I tried duplicating C9 2 using the Custom Palette Editor in the UI, but the result was the same. I attempted to manually correct the gamma in case this was similar to #3399 , but that things substantially worse, so I don't think that's it.

The UI sort of seems to acknowledge the issue (this is just the C9 2 palette duplicated as a custom palette):

But on the Custom Palette Editor, they appear the same.
C9 2:

Custom 2:

The actual rendered colors do look more like what the UI for the palette selection is showing (darker, more pronounced reds), but I can't figure out why or what I need to adjust to mimic C9 2.

To Reproduce Bug

1. Create a custom palette with:

    0,   6, 126,   2,
   45,   6, 126,   2,
   46,   4,  30, 114,
   90,   4,  30, 114,
   91, 255,   5,   0,
  135, 255,   5,   0,
  136, 196,  57,   2,
  180, 196,  57,   2,
  181, 137,  85,   2,
  255, 137,  85,   2

2. Upload using /edit, reboot
3. Select palette
   -- or --
4. Go to Custom Palette Editor
5. Copy C9 2 to palette editor
6. Duplicate each midpoint to eliminate gradients
7. Save as a custom palette and apply.

Expected Behavior

I would expect a custom palette with the same values as the built-in C9 2 to render the same.

Install Method

Binary from WLED.me

What version of WLED?

WLED 0.15.3 (2508020)

Which microcontroller/board are you seeing the problem on?

ESP32-C3

Relevant log/trace output

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[DedeHai]

@Copilot what is the difference in built in palettes and custom palette generation in colors.cpp? what explains the discrepancy and can it be fixed?

[DedeHai]

this is a deficiency of 0.15 and is fixed in 0.16 (check nightly build). It could be fixed but it would alter all existing custom palettes of users which is not a good thing.

[Sammy1Am]

I'm a little confused. I did just try the nightly 0.16 build, but I don't see any difference; the palette selector in the UI still shows a darker preview, and the LEDs are still darker and redder than the built-in C9 2.

You said it's a deficiency in 0.15 that it is fixed in 0.16, but also that it won't be fixed because it will alter all the existing custom palettes; are these two different fixes?

I understand that any previously made custom palettes that had to work around the bug would be broken, and that is inconvenient for sure, but it would sort of be nice if the palettes worked correctly so we didn't have to work around the deficiency. If this is unfixable, could we at least get a check-box option like "treat custom palettes like normal palettes"? And if that's not feasible, can you confirm that copilot's "fix" would be how I could manually gamma correct my palette so that it's rendered correctly?

Edit: Like I guess I just want clarification on this: Does this mean the values in the source for C9 2 are already corrected, but custom palette colors are expected to not be corrected and so when I copy the values it's getting corrected twice?

[softhack007]

Like I guess I just want clarification on this: Does this mean the values in the source for C9 2 are already corrected, but custom palette colors are expected to not be corrected and so when I copy the values it's getting corrected twice?

@Sammy1Am yes the values in the source code of 0.16 are without gamma correction, and actually you will not need to take care of gamma correction yourself any more in 0.16. It is still possible that colors shown on your LEDs differ a bit from the colors you see on the computer screen. This is the "unfixable problem" I was talking about (edit: see below for a more detailed explanation from coderabbit).

WLED 0.16 does not double-apply gamma correction anymore when loading custom palettes, so its indeed best to copy color values from palettes.h into your custom paletteXYZ.json, then check the look with your LEDs. Don't rely on the screen display to exactly match the colors of the LEDs.

Edit: if you have custom paletteXYZ.json files from a previous WLED version, these may indeed need some correction - old WLED versions will load them with the gamma value set in LEDs settings (typically gamma=2.8), however the new 0.16 architecture will leave gamma correction to the hardware driver level. This means that your old palettes (meant for target gamma 2.8) may not look the same on WLED 0.16 (displayed with gamma ~2.2).

[softhack007]

@coderabbitai does the custom palettes editor (https://github.com/wled/WLED/blob/main/wled00/data/cpal/cpal.htm) adjust gamma values when the user copies a standard palette into his custom palette?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Read the custom palettes editor file
cat wled00/data/cpal/cpal.htm

Length of output: 21109

---

🏁 Script executed:

#!/bin/bash
# Search for gamma-related logic in the cpal.htm file
rg -n -C5 -i "gamma" wled00/data/cpal/cpal.htm

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Search for palette copying logic
rg -n -C10 "copy|Copy" wled00/data/cpal/cpal.htm

Length of output: 1589

---

🏁 Script executed:

#!/bin/bash
# Search for color transformation or conversion logic
rg -n -C5 "transform|convert|correction" wled00/data/cpal/cpal.htm

Length of output: 248

---

@softhack007 No, the custom palettes editor (cpal.htm) does not adjust gamma values when copying a standard palette into a custom palette.

After examining the code, when the user clicks the edit button to copy a palette, the loadEdit(i) function:

1. Reads the color array directly from the palette data
2. For hex-format colors, uses them as-is: hex = \#${colArr[j+1]}``
3. For RGB-format colors, performs a simple mathematical conversion to hex via rgbToHex(r, g, b) without any gamma correction
4. Adds the colors to the editor using addC(pos, hex)

There's no gamma correction, color space conversion, or any color transformation logic in the file. The colors are copied directly, which is consistent with the issue being reported—if the built-in palette values in 0.16 are stored without gamma correction (relying on hardware-level gamma), then copying those values as-is into custom palettes would preserve them exactly, but the rendering pipeline might handle them differently depending on the WLED version.

---

🧠 Learnings used

Learnt from: DedeHai
Repo: wled/WLED PR: 4798
File: wled00/FX.cpp:7531-7533
Timestamp: 2025-08-26T11:51:21.817Z
Learning: In WLED PR #4798, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.

---

Learnt from: mval-sg
Repo: wled/WLED PR: 4876
File: wled00/xml.cpp:0-0
Timestamp: 2025-08-28T08:09:20.630Z
Learning: The WLED codebase has opportunities for refactoring hardcoded array bounds (like the "15" used for DMX channels) to use sizeof(array)/sizeof(array[0]) for more maintainable code, but such changes should be done consistently across the entire codebase in a dedicated refactoring effort.

---

Learnt from: mval-sg
Repo: wled/WLED PR: 4876
File: wled00/wled_eeprom.cpp:0-0
Timestamp: 2025-09-01T10:26:17.959Z
Learning: In WLED PR #4876, the DMXStartLED EEPROM backward compatibility issue was partially addressed by keeping it at address 2550 and reading it as a 16-bit value, with DMXChannelsValue array moved to addresses 2552-2566. This maintains compatibility with pre-0.11 EEPROM layouts for DMXStartLED, though legacy "Set to 255" (code 6) configurations may still need migration logic.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 5105
File: wled00/FX.h:968-968
Timestamp: 2025-11-22T12:12:53.486Z
Learning: In WLED's WS2812FX class (wled00/FX.h), the _pixels array stores LED colors indexed by unmapped (logical) LED positions, not physical positions. The getPixelColor(n) function intentionally checks if the logical LED at index n maps to a valid physical position via getMappedPixelIndex(n), then accesses _pixels[n] with the unmapped index. If the mapping is invalid (e.g., -1 for gaps in LED maps, or out of bounds), it returns 0 (black). This allows peek preview to correctly show gaps in LED mappings as black pixels. The mapping from logical to physical positions is only applied when writing to the hardware bus, not when reading from the pixel buffer.
<!-- [add_learning]

[softhack007]

@coderabbitai a related question - the CSS palette preview of the webUI

WLED/wled00/data/index.js

Line 989 in bb6114e

function genPalPrevCss(id)

is not using the same code as the FastLed palettes functions. Could this explain the preview differences mentioned by the user in his initial description?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch the palette preview code from index.js around line 989
cat wled00/data/index.js | sed -n '980,1020p'

Length of output: 864

---

🏁 Script executed:

#!/bin/bash
# Search for palette rendering functions in the codebase
rg -n -C5 "ColorFromPalette|getPaletteColor" --type=cpp

Length of output: 32257

---

🏁 Script executed:

#!/bin/bash
# Look for gamma correction in palette-related code
rg -n -C5 "gamma.*palette|palette.*gamma" --type=cpp

Length of output: 1574

---

🏁 Script executed:

#!/bin/bash
# Search for the palette preview generation function more broadly
rg -n -C10 "function.*[Pp]al.*[Pp]rev|generatePalPrev" wled00/data/index.js

Length of output: 816

---

🏁 Script executed:

#!/bin/bash
# Look at how custom palettes are loaded and processed
rg -n -C10 "loadCustomPalettes|customPalettes" --type=cpp

Length of output: 38761

---

🏁 Script executed:

#!/bin/bash
# Check how palettesData is populated in JavaScript
rg -n -C10 "palettesData\s*=" wled00/data/index.js

Length of output: 1335

---

🏁 Script executed:

#!/bin/bash
# Look at the complete genPalPrevCss function
cat wled00/data/index.js | sed -n '989,1050p'

Length of output: 1609

---

@softhack007 Yes, this definitely explains the preview differences the user is experiencing! After analyzing both the JavaScript CSS preview code and the C++ palette rendering, I've identified the root cause:

The Problem

CSS Preview (JavaScript):

• The genPalPrevCss() function in index.js (lines 989-1046) generates CSS gradients using raw RGB values directly from the palette data
• No gamma correction is applied: gradient.push(rgb(${r},${g},${b}) ${index}%);
• The preview shows colors exactly as they appear in the palette data

LED Rendering (C++):

• Palettes are rendered via ColorFromPaletteWLED() which outputs to LEDs
• Hardware bus drivers then apply gamma correction (~2.2)

Built-in Palettes in 0.16:

• According to palettes.cpp lines 6-10 and line 671, built-in palettes like C9 2 have inverse gamma (2.2) already pre-applied to their source color values
• When hardware gamma is applied during LED output, this cancels out, showing the intended colors

Custom Palettes:

• Loaded directly from JSON without any gamma correction (colors.cpp lines 248-294)
• When a user copies C9 2 values to a custom palette, they're copying the already inverse-gamma-corrected values
• These then get hardware gamma applied, effectively applying correction twice
• Result: darker, more saturated reds, less green—exactly what the user reported!

Why the Previews Look Different

1. Built-in C9 2 palette selector preview: Shows the inverse-gamma-corrected values, which look darker/redder
2. Custom palette preview: Shows the same inverse-gamma-corrected values (identical in Custom Palette Editor)
3. Built-in C9 2 on LEDs: Inverse gamma + hardware gamma = correct appearance
4. Custom C9 2 copy on LEDs: Inverse gamma (from copied values) + hardware gamma = double-corrected = too dark/red

The CSS preview is accurately showing what's in the palette data, but it doesn't match what users see on LEDs because it's missing the gamma correction step that the LED hardware applies.

---

🧠 Learnings used

Learnt from: DedeHai
Repo: wled/WLED PR: 4798
File: wled00/FX.cpp:7531-7533
Timestamp: 2025-08-26T11:51:21.817Z
Learning: In WLED PR #4798, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 5105
File: wled00/FX.h:968-968
Timestamp: 2025-11-22T12:12:53.486Z
Learning: In WLED's WS2812FX class (wled00/FX.h), the _pixels array stores LED colors indexed by unmapped (logical) LED positions, not physical positions. The getPixelColor(n) function intentionally checks if the logical LED at index n maps to a valid physical position via getMappedPixelIndex(n), then accesses _pixels[n] with the unmapped index. If the mapping is invalid (e.g., -1 for gaps in LED maps, or out of bounds), it returns 0 (black). This allows peek preview to correctly show gaps in LED mappings as black pixels. The mapping from logical to physical positions is only applied when writing to the hardware bus, not when reading from the pixel buffer.
<!-- [add_learning]

---

Learnt from: mval-sg
Repo: wled/WLED PR: 4876
File: wled00/xml.cpp:0-0
Timestamp: 2025-08-28T08:09:20.630Z
Learning: The WLED codebase has opportunities for refactoring hardcoded array bounds (like the "15" used for DMX channels) to use sizeof(array)/sizeof(array[0]) for more maintainable code, but such changes should be done consistently across the entire codebase in a dedicated refactoring effort.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 4939
File: wled00/FX_fcn.cpp:1176-1187
Timestamp: 2025-09-16T18:08:42.848Z
Learning: In WLED finalizeInit() bus creation (wled00/FX_fcn.cpp), intentionally allowing memory overruns when bus configurations exceed MAX_LED_MEMORY is a deliberate design choice. The trade-off prioritizes creating buses with reduced LED counts over completely failing to create buses, which would cause no LED output and UI failures. This approach forces users to update configurations after migrating to version 0.16 while maintaining basic functionality.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 4923
File: wled00/FX.cpp:4883-4901
Timestamp: 2025-09-12T17:29:43.826Z
Learning: In WLED’s web UI, only one slider value (e.g., SEGMENT.intensity or SEGMENT.custom1) changes at a time; code relying on this may use simplified change guards, though presets/JSON can still update multiple fields atomically.

---

Learnt from: blazoncek
Repo: wled/WLED PR: 5140
File: wled00/data/settings_time.htm:66-76
Timestamp: 2025-12-01T07:01:16.949Z
Learning: In WLED PR #5134, the fix for macros being initialized with the enable bit set only handles new configurations, not existing ones. If there is a bug in timer/macro handling code (e.g., in settings_time.htm), it must be fixed to work correctly for existing configurations as well.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 4939
File: wled00/data/index.js:2406-2413
Timestamp: 2025-09-28T09:53:42.670Z
Learning: In WLED, code paths that appear unreachable may actually be safety fallbacks for low-heap conditions. These fallbacks are intentional defensive programming measures to ensure UI functionality is preserved when system resources are constrained.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-11-14T13:37:11.994Z
Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with appropriate defined constants when those constants are meaningful in the context of the PR. For example, the hardcoded value 32 should be replaced with WLED_MAX_SEGNAME_LEN when it represents a segment name length limit. This improves code maintainability and reduces the risk of inconsistencies.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 4997
File: wled00/e131.cpp:33-44
Timestamp: 2025-10-10T18:34:06.550Z
Learning: In WLED's DDP packet handling (ws.cpp and e131.cpp), only prevent out-of-bounds memory access rather than enforcing DDP spec compliance. Don't check the 1440-byte spec limit—accept out-of-spec packets assuming correct encoding. The bounds check `maxDataIndex = c + numLeds * ddpChannelsPerLed; if (maxDataIndex > dataLen) reject` is sufficient and already covers the timecode flag case (when c=4) without needing separate validation.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-11-14T13:37:30.955Z
Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with defined constants when meaningful constants exist in the codebase. For example, suggest replacing hardcoded "32" with WLED_MAX_SEGNAME_LEN if the context relates to segment name length limits.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Get the CSS palette preview code from index.js around line 989
sed -n '980,1020p' wled00/data/index.js

Length of output: 864

---

🏁 Script executed:

#!/bin/bash
# Search for palette color extraction and processing in colors.cpp
rg -n -C10 "getPaletteColor|loadPalette" wled00/colors.cpp

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Look for how palettes are loaded and processed - search for custom palette handling
rg -n -C5 "customPalettes|cust.*pal" wled00/colors.cpp

Length of output: 968

---

🏁 Script executed:

#!/bin/bash
# Search for gamma correction in palette loading
rg -n -C5 "gamma.*palette|palette.*gamma" wled00/colors.cpp

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Look at more of the genPalPrevCss function to see the full preview generation
sed -n '989,1050p' wled00/data/index.js

Length of output: 1609

---

🏁 Script executed:

#!/bin/bash
# Search for loadDynamicGradientPalette to understand how palettes are loaded
rg -n -C10 "loadDynamicGradientPalette" wled00/colors.cpp

Length of output: 826

---

🏁 Script executed:

#!/bin/bash
# Look at palettes.h to see how C9 2 palette is defined
rg -n -B2 -A10 "C9 2|C9\[2\]" wled00/palettes.h

Length of output: 57

---

🏁 Script executed:

#!/bin/bash
# Search for gamma correction application in the color processing pipeline
rg -n -C5 "gamma" wled00/colors.cpp | head -50

Length of output: 1776

---

🏁 Script executed:

#!/bin/bash
# Find palettes.h file location
fd -t f "palettes.h"

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Search for C9 palette definition
rg -n "C9" --type cpp --type h -C3 | head -100

Length of output: 5833

---

🏁 Script executed:

#!/bin/bash
# Look at how palette data is sent to the web UI
rg -n -C5 "palettesData|sendPalettesData" wled00/

Length of output: 5534

---

🏁 Script executed:

#!/bin/bash
# Check how colors are processed when displaying - search for NeoGammaWLEDMethod usage
rg -n -C3 "NeoGammaWLEDMethod|gammaCorrect" wled00/colors.cpp

Length of output: 780

---

@softhack007 Yes, this absolutely explains the preview differences the user is seeing. Here's why:

The Issue

The CSS palette preview in index.js (genPalPrevCss() function, lines 1005-1027) creates gradients using raw RGB values without any gamma correction:

gradient.push(`rgb(${r},${g},${b}) ${index}%`);

However, the actual LED rendering pipeline applies gamma correction via NeoGammaWLEDMethod::Correct() in colors.cpp (lines 597-601):

uint8_t NeoGammaWLEDMethod::Correct(uint8_t value)
{
  if (!gammaCorrectCol) return value;
  return gammaT[value];
}

Why This Creates a Discrepancy

1. Web UI Preview: Uses raw RGB values in CSS linear-gradient(), which the browser renders with its own sRGB gamma (~2.2)

2. Actual LEDs: Receive colors that have been processed through WLED's configurable gamma correction (typically 2.8 in 0.15), plus FastLED's palette interpolation

3. Different rendering paths:

   • Built-in palettes → FastLED palette system → WLED gamma correction → LEDs
   • CSS preview → browser sRGB rendering → screen
   • These are completely independent code paths

The Result

The user sees darker, redder colors on the LEDs compared to the UI because:

• Higher gamma values (2.8 vs 2.2) make mid-tones darker
• The gamma correction curves are different between WLED and the browser
• In 0.15, custom palettes may have had additional gamma applied that built-in palettes didn't

This mismatch is inherent to showing color previews in a web browser when the actual output device (LEDs) uses different gamma correction. The CSS preview can only approximate what the LEDs will show, but cannot exactly match it.

---

✏️ Learnings added

Learnt from: softhack007
URL: https://github.com/wled/WLED/issues/5195

Timestamp: 2025-12-15T20:25:25.807Z
Learning: The CSS palette preview in wled00/data/index.js genPalPrevCss() function uses raw RGB values in CSS linear-gradient() without applying WLED's gamma correction, while actual LED output goes through NeoGammaWLEDMethod gamma correction. This causes inherent discrepancies between the web UI palette preview and actual LED colors, especially noticeable with different gamma settings.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

---

🧠 Learnings used

Learnt from: DedeHai
Repo: wled/WLED PR: 4798
File: wled00/FX.cpp:7531-7533
Timestamp: 2025-08-26T11:51:21.817Z
Learning: In WLED PR #4798, DedeHai confirmed that certain gamma-related calls in FX.cpp/FX_fcn.cpp/particle systems are intentional for effect-level shaping (e.g., brightness curves, TV sim, Pride 2015 pre-mix), distinct from final output gamma. Do not flag or remove these in future reviews; add comments when feasible to clarify intent.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 5105
File: wled00/FX.h:968-968
Timestamp: 2025-11-22T12:12:53.486Z
Learning: In WLED's WS2812FX class (wled00/FX.h), the _pixels array stores LED colors indexed by unmapped (logical) LED positions, not physical positions. The getPixelColor(n) function intentionally checks if the logical LED at index n maps to a valid physical position via getMappedPixelIndex(n), then accesses _pixels[n] with the unmapped index. If the mapping is invalid (e.g., -1 for gaps in LED maps, or out of bounds), it returns 0 (black). This allows peek preview to correctly show gaps in LED mappings as black pixels. The mapping from logical to physical positions is only applied when writing to the hardware bus, not when reading from the pixel buffer.
<!-- [add_learning]

---

Learnt from: mval-sg
Repo: wled/WLED PR: 4876
File: wled00/xml.cpp:0-0
Timestamp: 2025-08-28T08:09:20.630Z
Learning: The WLED codebase has opportunities for refactoring hardcoded array bounds (like the "15" used for DMX channels) to use sizeof(array)/sizeof(array[0]) for more maintainable code, but such changes should be done consistently across the entire codebase in a dedicated refactoring effort.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 4939
File: wled00/FX_fcn.cpp:1176-1187
Timestamp: 2025-09-16T18:08:42.848Z
Learning: In WLED finalizeInit() bus creation (wled00/FX_fcn.cpp), intentionally allowing memory overruns when bus configurations exceed MAX_LED_MEMORY is a deliberate design choice. The trade-off prioritizes creating buses with reduced LED counts over completely failing to create buses, which would cause no LED output and UI failures. This approach forces users to update configurations after migrating to version 0.16 while maintaining basic functionality.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 4923
File: wled00/FX.cpp:4883-4901
Timestamp: 2025-09-12T17:29:43.826Z
Learning: In WLED’s web UI, only one slider value (e.g., SEGMENT.intensity or SEGMENT.custom1) changes at a time; code relying on this may use simplified change guards, though presets/JSON can still update multiple fields atomically.

---

Learnt from: blazoncek
Repo: wled/WLED PR: 5140
File: wled00/data/settings_time.htm:66-76
Timestamp: 2025-12-01T07:01:16.949Z
Learning: In WLED PR #5134, the fix for macros being initialized with the enable bit set only handles new configurations, not existing ones. If there is a bug in timer/macro handling code (e.g., in settings_time.htm), it must be fixed to work correctly for existing configurations as well.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 4939
File: wled00/data/index.js:2406-2413
Timestamp: 2025-09-28T09:53:42.670Z
Learning: In WLED, code paths that appear unreachable may actually be safety fallbacks for low-heap conditions. These fallbacks are intentional defensive programming measures to ensure UI functionality is preserved when system resources are constrained.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-11-14T13:37:11.994Z
Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with appropriate defined constants when those constants are meaningful in the context of the PR. For example, the hardcoded value 32 should be replaced with WLED_MAX_SEGNAME_LEN when it represents a segment name length limit. This improves code maintainability and reduces the risk of inconsistencies.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 4997
File: wled00/e131.cpp:33-44
Timestamp: 2025-10-10T18:34:06.550Z
Learning: In WLED's DDP packet handling (ws.cpp and e131.cpp), only prevent out-of-bounds memory access rather than enforcing DDP spec compliance. Don't check the 1440-byte spec limit—accept out-of-spec packets assuming correct encoding. The bounds check `maxDataIndex = c + numLeds * ddpChannelsPerLed; if (maxDataIndex > dataLen) reject` is sufficient and already covers the timecode flag case (when c=4) without needing separate validation.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-11-14T13:37:30.955Z
Learning: In WLED code reviews, when code is modified or added, look for "magic numbers" (hardcoded numeric literals) and suggest replacing them with defined constants when meaningful constants exist in the codebase. For example, suggest replacing hardcoded "32" with WLED_MAX_SEGNAME_LEN if the context relates to segment name length limits.

[Sammy1Am]

you will not need to take care of gamma correction yourself any more in 0.16

Bit of an update here, I did attempt to update to 0.16, and it rebooted so I assumed it had updated, however I just checked and I was still on 0.15.3. I updated again and it worked this time and now things appear as expected:

Custom 2 (the copy-pasted palette) appears the same (though with a gradient instead of clear lines, but that's not a big deal), and Custom 3 (which I manually inverse-gamma-corrected) appears brighter (but displayed correctly in 0.15.3).

The palette editor seems fine as well:

So it seems like things are indeed fixed 0.16, sorry for the run-around on that part, and thanks for the quick responses!

Unless there's an issue here that's spawned out of my original problem, it seems like 0.16 closes this issue for me.