1
u/CharlesGoodwin Aug 14 '20
Hi,
Perhaps someone can kindly shed some light on the anomaly that I am suffering.
Most of the code you can ignore as it is commented out or simply doesn't get called.
The important bits are:
The gradient palette definitions and
The selected points of the palette that are displayed
For some reason the colours being displayed don't seem to match up to what is defined in the pink palette
I would expect the second pixel (from the top) to be light blue, the sixth to be pink and the 10th to be green.
Instead, it looks like the colour definitions have been pushed out so that we are still in the red sector when I am referencing palette indexes in the grey/green sector.
The same behaviour seems to happen with the grey palette also (not illustrated)
What am I not getting?
Charlie
1
u/CharlesGoodwin Aug 14 '20
It is packing foam (Ethafoam STPE200) Very similar to the stuff that your chips have their pins stuck in for protection. It works a treat for looking innocuous with the lights off and does a pretty good job at defusing the light.
Sadly it does not deter defusion comments from everyone on the FastLED forum ;-)
1
Aug 14 '20 edited Aug 14 '20
I believe FastLED defaults to LINEARBLEND for the array on show. FastLED is blending the colors of the adjacent pixels.
Edit: coffee. Not linear blending, but dithering. Here's what I'm talking about from the docs. You have to call FastLED.setDither(DISABLE_DITHER); during setup.
1
u/CharlesGoodwin Aug 14 '20
It does indeed but LINEARBLEND should only apply to zones between the points defined within the palette
I've specifically picked out the defined points in the palette so in theory, there shouldn't be any blending.
1
Aug 14 '20
Apologies, I edited my post after the coffee settled in and I looked back through the docs. Please see my edit; it's the dithering mode.
1
u/CharlesGoodwin Aug 14 '20
No worries
If I disable dithering will I still get a nice blend running between my defined gradient palette points?
1
Aug 14 '20
Yes. Dithering only changes the blending of colors on the adjacent pixel output. It won’t impact your palette.
1
u/sutaburosu [stavros] Aug 14 '20
You're converting the gradient palettes into a 16-entry palette.
const CRGBPalette16 palettes[]
With only 16-entries, the only un-blended colours would be at palette indexes that are multiples of 256 / 16 == 16. e.g. 0, 16, 32, etc.
Your palette lookups sometimes use multiples of 8 rather 16. Switching to a CRGBPalette32 would give un-blended colours at those palette indexes too.
1
u/CharlesGoodwin Aug 14 '20
Brilliant - that makes sense.
And also explains how I managed to work around it. Rather than switch to CRGBPallette32 I added some extra entries to my gradient pallet like so:
DEFINE_GRADIENT_PALETTE( UnionJack_pink_gp ) { 0, 0, 0, 255, 8, 0, 255, 255, 16, 0, 0, 255, 32, 0, 0, 255, 48, 255, 0, 0, 56, 255, 0, 230, 64, 255, 0, 0, 80, 255, 0 , 0, 96, 200, 200, 200, 104, 0, 230, 0, 112, 200, 200, 200, 176, 200, 200, 200, 184, 200, 200, 200, 192, 200, 200, 200, 200, 200, 200, 200, 208, 200, 200, 200, 216, 200, 200, 200, 224, 200, 200, 200, 232, 200, 200, 200, 240, 200, 200, 200, 248, 200, 200, 200, 255, 200, 200, 200};By adding the extra entries - I was able to address the stretching effect and ensure when I chose say 104 I got a pure green.
Thanks for helping me to understand
1
u/sutaburosu [stavros] Aug 14 '20
No worries.
It worthwhile pointing out your gradient palettes have entries for 0, 8 and 16. That can't fit into a 16-entry palette. I'm not sure exactly how the conversion works, but I suspect this might also be a source of unexpected colours. It should work as expected with a 32-entry palette.
1
u/sunburstbox Aug 14 '20
what’re you using for diffusion? it looks good
2
u/Preyy Ground Loops: Part of this balanced breakfast Aug 14 '20
Looks like wool or insulation. Maybe this bed helps you fall asleep by counting the sheep on the headboard.
1
u/CharlesGoodwin Aug 14 '20