This online webapp solves most of your 1D 2D (and some 3D) mapping head aches, and exports to various formats, including FastLED arrays.
Check it out r/FreeLED or go directly to the tool which is permanently host at freeled.org
The most common approach to handling RGBW LED strips/diodes is to simply take the minimum components of the input value, set white to that value, and subtract the residuals from R, G & B. This is not inherently incorrect but it does introduce a problem in that the white diode is not perfect. Most white diodes have different color temperatures and when actually measured you'll find using min(rgb) Channel - Residuals produces a white this is off-white.
Now the question becomes "how do we accurately extract white?" The answer is shockingly simple and it comes down to colorspaces & gamut.
In a typical RGB LED system your native gamut is a triangle where your main emitters R, G, & B are your only centroids. Each centroid lives somewhere on the CIE chart and has it's own xy coordinates. This creates a triangle where any combination of values can be created using the 3 emitters. Typical colorspaces like Rec709, Rec2020, etc.. all live somewhere either within this gamut or outside of it.
In an RGBW LED system instead we have 4 different addressable gamuts within this triangle
so the problem changes from "how do we represent a color with these 3 diodes" to "which sub-gamut does the requested color fall into, and then within the sub-gamut how do we represent the color requested using the outer 2 primary diodes + inner white diode?"
The "Color" problem:
Different RGB input values map to different places in the CIE colorspace depending on the requested colorspace and reference white. "orange" for the native gamut is not the same "orange" as Rec709, just as that same "orange" is not the same in Rec2020. If you want to represent a color in the Rec709 space (aka ambilight setup) then you need a Colorspace transform to solve for that value. This effectively maps the native-gamut to the effective colorspace.
The ratio problem:
Addressable LEDs (most strips/diodes) do not have perfect LED selections. Typically speaking the red & blue diodes are fairly weak maxing out at low brightness values, G is typically stronger, with White being strongest almost always. In the case of my recent ambilight-focused measurements, the BTF Lighting 6000k RGBW LEDs produce max Nits/ XYZ Y values of R: 154.67 G:566.27 B:129.64 W:1543.64
so given that the red diode is much less bright than the green diode you need to scale input values down appropriately to accurately reproduce the color requested. For a cyan (input 0 65535 65535) for this specific set of LEDs with the off-wall measurements, the corrected output values become: 0 65458 38474 0 which when measured with a colorimeter produces a dE of ~0.519 from the expected measurement result
for D65 white (65535, 65535, 65535) the output RGBW tuple looks something like : 4289 0 13766 65535 which also passes the dE check at 1.720% within tolerance
So to summarize:
Min(rgb) and then subtract residuals from R, B, & G is not inherently wrong if that is what the actual diode behavior is, but the correct approach is to treat the LEDs as they are: Separate emitters that form a full gamut with multiple sub-gamuts, and then only solve within the sub-gamuts for the requested color value determined by a colorspace transform if the input color isn't addressing the native gamut of the LED display.
In a typical RGBW setup the valid topology combinations are essentially as follows: R, B, G, W, RW, BW, GW, RG, RB, BG, RGW, BGW, RBW unless you specifically allow for 4-channel overdrive outputs.
I just recorded the process of mapping LEDs on a photo, in order to explain the use of FreeLED tools to a user named ButerBrott. And here's what i did:
- Upload the photo as background, dimm it for comfortable view of dots
- Use Link (L) tool and Ctrl + Mouse wheels to draw the lower half of the hex
- Then use Copy (Ctrl+C) and Paste (Ctrl+V) to create the upper half as a copy of the lower half
- Then use Flip (FX/FY) to correct the path
- Then use Invert (I) to correct the direction
- Then use Link (L) to connect the 2 halves
Use the tool freely at freeled.org
For a few years I have been using arrays of APA102C LEDs to create low resolution graphics. Does anyone have experience with the faster HD107s LEDs ? Would code written for the APA102C on the Arduino IDE also work for the HD107s ?
Hey all! Ive been working on an update for the ESP32-based Artnet node, and I am proud to show off the results! It now supports 3,4, and 5-channel LED colour types, as well as SPI-based LEDs! This basically means support for every LED strip available!
Check out the project and changes here; https://github.com/mdethmers/ESP32-Artnet-Node-receiver
Next to that, a new hardware revision is coming, supporting;
Let me know what you think and if you have any questions!
Something strange is emerging from the solver.
What started as “just some colorful smoke” slowly turned into a deep dive into numerical instability, fluid dynamics, pressure projection, divergence control and the weird art of balancing equations exactly at the edge of total chaos.
Every swirl on screen is real simulated motion.
No keyframes. No prebaked animation.
Just velocity fields, advection, pressure solves and controlled chaos.
And sometimes uncontrolled chaos.
Coming soon:
A highly stylized real-time fluid simulation system built from scratch — designed for LED visuals, generative motion and beautiful mathematical instability.
P.S. Unmute for a nice soundtrack.
P.P.S. I asked my AI crew for a little write up, what I actually did in the last weeks. Here is what they came up with, entirely based on real events:
He originally just wanted to make “some colorful smoke-like fluid motion” for LED visuals.
How hard could it possibly be?
A few days later he found himself at 6 AM still staring at several hundred megabytes of solver array dumps, trying to understand why a single velocity cell near the boundary had suddenly decided to turn the entire simulation into pixel salad.
He was naive enough to even start investigating it, and autistic enough to actually follow the problem all the way down to the point where he truly understood why the solver kept exploding.
At first everything was innocent.
A grid.
Some arrays.
A little dye.
A bit of motion.
Then came the moment he realized:
A fluid simulation is not animation at all.
It is controlled numerical instability.
Suddenly he had to learn, in depth, about:
Very quickly he learned: if you simply move velocity through the grid, everything explodes.
So he learned projection.
Pressure fields.
Divergence removal.
And for the first time the simulation actually started looking like fluid.
First Eureka moment.
Then he implemented vorticity confinement.
And suddenly the fluid had character.
Swirls. Energy. Motion. That organic “life” inside the flowfield.
For about 30 seconds.
Then everything exploded again.
That was the next lesson: Numerical solvers rarely fail instantly.
They accumulate error slowly. Invisibly. Frame by frame.
One tiny divergence error survives projection.
Advection transports it.
Vorticity confinement amplifies it.
Pressure correction overcompensates.
Energy starts feeding back into itself.
And ten seconds later the entire simulation just explodes.
So he started building debugging tools:
Not because it looked cool.
Because without them you are completely blind.
At some point he finally understood why real fluid solvers become so insanely complicated.
Because every new feature quietly destabilizes three other systems.
More swirl?
→ unstable curl amplification.
Less dissipation?
→ energy accumulation.
Larger timestep?
→ projection can’t converge fast enough.
Too few solver iterations?
→ divergence survives.
Too many iterations?
→ performance dies.
Float32 precision?
→ tiny drift accumulates forever.
And still, there were these magical moments.
Like when the three emitters interacted for the first time and suddenly formed these huge rotating structures entirely on their own. No animation. No keyframes. Just equations interacting with equations.
Or the moment he realized:
The most beautiful fluid motion exists exactly at the edge of instability.
Too stable = dead.
Too unstable = explosion.
The sweet spot in between?
That’s the actual solver.
And eventually you stop feeling like you are programming graphics.
You are dancing with differential equations.
working on a LED matrix thingy and made a mistake, my panel ended up vertical instead of horizontal.
basically:
this is what its like right now - its running left to right vertical.
but i need my code to treat it as horizontal, so like this:
is there a software way to do this or is my only solution just changing it physically?
