Single neopixel element for all smart LEDs types and layouts (started as Gamma-Correction but got into a general solution)

[arduino12]

Is your feature request related to a problem? Please describe. I made a small RGBDuino test and found out that I must set the neopixels brightness to 12% in real life because they are too bright and takes high current, but inside the simulator the 12% shows very dim and it is hard to see the colors.

Describe the solution you'd like Adding a gamma_correction and brightness attributes to the RGB-LED and NeoPixels - so the user can set it to look good on the simulator.

[urish]

Thanks! I opened this for vote: https://wokwi.com/features#feature-1079348122

[sutaburosu]

brightness attributes

The Neopixel elements already have a brightness correction attribute: matrixBrightness. It is a multiplication factor, so if your FastLED brightness is set to 12, then 255/12 = 21.25 should be an appropriate factor to scale the LEDs to full brightness in the simulator. Or "matrixBrightness" = "8" if you really meant 12% rather than FastLED.setBrightness(12);.

It is also possible to use a scale factor that results in values brighter than 100%. The LEDs will be capped at maximum brightness if there is any overshoot. For some effects, this can make the end result even more clearly visible in the sim, but of course it can result in the colours being different. Here is a project that benefited from this.

@urish, regarding gamma correction, I've done more research and I believe my original suggestion of raising each R, G, B value to the power of 1/monitor_gamma_curve is broadly correct. I originally suggested 1/1.8 = 0.55 for the monitor's gamma exponent. I've since learned this value was specific to Apple computers/monitors; everything else seems to use 1/2.2 = 0.45 as the exponent.

The current ITU recommendation BT.709 item 3.1 says that 1/2.2 = 0.45 should be the standard for modern screens. My current monitor defaults to 2.2, and allows choices of 1.8, 2.2 and 2.6. All other sources I have found seem to agree, e.g. this discussion of colour space conversions.

So, on recent monitors, Vcorrected = ((Vfastled / 255) ** 0.45) * 255; should give a better approximation of apparent brightness of real-world LEDs. This ignores the small linear gradient in BT.709 (between 0 - 0.018, see item 1.2 of BT.709), but the visual difference should be negligible. A slightly closer to correct conversion would be Vcorrected = (((Vfastled * 1.099 / 255) - 0.099) ** 0.45) * 255;. A perfect conversion would involve an unpredictable branch or a LUT, which is probably undesirable for the minimal gain it would bring.

[urish]

Thank you so much for looking into this, Steve!

I added a temporary way to set the gamma for a neopixel-canvas, "_temp_gamma" attribute.

Here's an example with gamma correction factor set to 0.45:

https://wokwi.com/arduino/projects/318128789338980929

How does that look to you?

[sutaburosu]

Oh, that's great. Thanks, Uri. It seems to closely match what I see on my LEDs matrices.

[urish]

So I guess the only question is: how should we introduce it?

The easiest approach would probably be to make this opt-in: there's no gamma correction, unless you specify one. The more "correct" approach would probably be set to set the default gamma correction to 0.45, and remove the matrixBrightness. But this might affect existing projects.

Thoughts?

[sutaburosu]

Yeah, opt-in seems fine to me. There's no need to affect the behaviour of existing projects. Those who care about it will discover it in the docs.

[urish]

Then, what about matrixBrightness? do we need to keep both?

[sutaburosu]

I think matrixBrightness should also remain, at least until #234 allows for the sketch to select different brightness in the sim. I know I'm not the only one who likes to test at full brightness in the sim but runs real LEDs at much lower brightness (to reduce power consumption).

[arduino12]

I just play with the neopixels and here is what I got:

1. The "matrixBrightness" only works for wokwi-neopixel-canvas- but not for wokwi-neopixel and wokwi-led-ring. 2. Can't add wokwi-neopixel-canvas via the green "+" button - can only add it via the json file.

I have connected all neopixel modules to the same arduino pin and set "matrixBrightness": 30 to all of them- Only the wokwi-neopixel-canvas shows 100% red - see here :)

Gamma correction example looks good! thanks for that @urish !

[urish]

Yes, these LEDs are pretty messy at the moment. See my comments here:

https://github.com/wokwi/wokwi-features/issues/59#issuecomment-843126580 https://github.com/wokwi/wokwi-docs/issues/57#issuecomment-898702445

We had a discussion about that in discord a few months ago:

https://discord.com/channels/787627282663211009/797922013389389824/875847352169136228

My suggestion was:

We can have 3 classes of geometries: strip, ring, and matrix Then the name would be wokwi-- e.g. wokwi-ws2812-strip, wokwi-apa102-ring, etc.

Even though now there's also your request for RGBW LEDs and such: #243.

Once we decide on a good naming scheme, I can go on implementing it, making sure they are all behaving consistently (e.g. having a similar gamma correction algorithm), and documenting them / adding them to the green "+" button

[arduino12]

I see, the wokwi-neopixel-strip 3D examples looks great!

So I can only suggest not including the LED chipset in the element name - I think it is just a json attribute - like the pixel-count and many more...

How about a single neopixel element to rule them all?

{
  "id": "neopixels",
  "type": "wokwi-neopixels",
  "top": 0,
  "left": 0,
  "attrs": {
    "layout": "matrix" / "ring" / "frame" / "splendida" / "custom",
    "canvas": "false",       // set true to reduce graphics and save cpu time.
    "pixelCount": "60",      // only for ring.
    "pixelCols": "16",       // only for matrix, frame.
    "pixelRows": "16",       // only for matrix, frame.
    "pixelColors": "RGB" / "RGBW" / "RGBWW" / "RGBNW" / "WW" / "CW" / "NW" / "WWA",
    "pixelChipset": "WS2812" / "SK6812" / "APA102",
    "pixelBrightness": "8",  // used to be "matrixBrightness"
    "pixelGamma": "0.45",
    "pixelSpacing": "2",
    "pixelShape": "square" / "circle"
}

And in the "+" menu we can add a "neopixels" sub-menu with some common option- that adds the same wokwi-neopixels element but with different predefined values like:	"+" -> Neopixels ->
16x16-rgb-matrix
ws2812-rgb-strip
ws2812-rgb-ring
apa102-rgb-strip
sk6812-wwa-led
splendida

This method can be used to combine others element with common base like the LCD1602 + LCD2004, LED + RGB-LED, 74hc logic IC series family...

This way there will be less items on the main "+" menu, and some docs pages can be combined :)

[urish]

Thanks for sharing your feedback!

How about a single neopixel element to rule them all?

The name NeoPixels refers to WS2812, and if I'm not wrong, it's Adafruit who came up with the name. So probably a different name would make more sense.

Also, I'm different kinds (APA102 / WS2812 / etc.) have a different number of pins / pin types, so it might be more confusing to combine them all into one part. Especially, given that the attributes depend on the type of parts you choose.

For instance, the splendida is always WS2812 with 256 pixels in a very specific arrangement. So if we try to come up with a single element that supports everything, there'll be many invalid combinations that we'll have to worry about.

This method can be used to combine others element with common base like the

In general, I'd prefer to stick with parts that match physical parts you can actually buy. So I'm not sure we'll gain anything by combining LCD1602 and LCD2004 or the LED and RGB LED. Or did you mean something else?

[arduino12]

Hi,

I am also not a fan of "NeoPixel" and "DotStar" names - I call them smart leds :)

I still think combining them is better - because they are all the same family of parts and user can easily swap the LED type or board shape without replacing the element.

About the different pinout - There are only 2 options here - single DIN or DIN+CLK - and the wokwi-7segment also support multi layouts and pinouts.

The invalid combinations are also OK - this is all the fun in the simulator vs real-world - user can try splendida with APA102 or WWA colors - and if he likes it he can proceed to make a real one :) But the simulator can always ignore the pixelRows for example when using the ring layout.

Yes I ment exactly that - just like I keep the LCD1602 and LCD2004 LCDs in a same drawer in real life- I think the better be the same element with single doc page - they only have a different flavor or layout in my opinion- So it makes more sense to group them together instead of adding their attributes to their element name. Because there are the blue LCD version, and the I2C extera module that comes behind and maybe more things that will be added.. Also from the driver side - the same arduino-lib can control both of them, like the single FastLED can control all the smart-pixels LEDs and there are no different libs for each LED type.

Sorry for long message but hope I well explained my tendency to combine common elements :)

[leftCoast]

"NeoPixel" and "DotStar" Are what the masses call them.

[sutaburosu]

@leftCoast NeoPixel is a registered trademark of Adafruit / Limor Fried in the US, Israel, UK and many other territories. I would expect them to also trademark DotStar if they start making significant profits off them. Wokwi would have to call them Neopixel-compatible to avoid any possible threats of legal action. "ARGB" (Addressable RGB) seems to be gaining in recognition as a term to distinguish addressable strips from the old RGB power bus strips.

[houseofdouglas]

Would love to see support for SK6812 IC for addressable WRGB LED arrays. Those have become so common. Would love know how I can help. I would suggest a simple strip of 6 LEDs/ICs, that would be plenty to test and develop.

[urish]

Would love to see support for SK6812 IC for addressable WRGB LED arrays. Those have become so common. Would love know how I can help. I would suggest a simple strip of 6 LEDs/ICs, that would be plenty to test and develop.

Do you have some example code that would drive such an LED? I don't have the hardware, but I could try to prototype something if I had code I know works.

[urish]

This issue has been getting a lot of votes recently and climbing up the feature list, so let's try to put together a plan how to implement it.

@sutaburosu raised a valid concern about Neopixel being Adafruit's trademark. Their website says:

For Adafruit trademark & product names such as NEOPIXEL, you may refer to the LED strips/components as NEOPIXEL(R) brand only if NEOPIXELS from Adafruit or an authorized reseller is incorporated into the project/product

I'd love to get a clarification from someone from Adafruit what they feel comfortable with. Should we drop "Neopixel" altogether, or is it okay to use it in the context of the simulator? Perhaps @ladyada could chime in and help here.

Once we figure this out, we can try to come up with a good naming scheme for the different kinds/models of LED strips/rings/matrices.

[ladyada]

hiya - you can use "NeoPixel Compatible" if that is accurate.

[sutaburosu]

Do you have some example code that would drive such an LED?

I haven't tested this myself on real hardware, but I've heard that this sketch works correctly on RGBW addressable LEDs. Or should I say GRBW, as that's the order in which those LEDs want the colour data to be presented.