Brightness implementation

[hallard]

Hi there
I played a lot trying to achieve some brightness suit to my needs.

Using setPanelBrightness works perfectly fine, and it's like a kind of hardware brightness. But, yes there is a but, I need some low brightness because even on full night it's too much. And with outdoor panel setting this to lower than 8 result in a "no display" on panel. With indoor it's a bit better works until value 2/3 but you may have some colors that disapears, wich makes senses.

So I tried to set the hardware to maximum (64) and then doing some king of software using nscale8 as I saw in some of your examples, but I'm not satisfied with results, sometimes it may change the color may be due to 565 implementation even if I tried to use CRGB form fast led each time I could. But I'm not specialist so may be made some mistakes on my side during implementation.

Anyway, so my question, what about adding a software brightness in this lib? I mean set a dim value and then with this value, call nscale8 before each drawPixel (or any better option)? Would this makes sense?

[mrcodetastic]

Hi @hallard. Short answer is 'no'. Software brightness is a graphics effect thing, and not what this library does. If you want software brightness, implement a graphics layer and run 'dim' over every pixel before sending to the DMA library... or use:

https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/tree/master/examples/GraphicsLayer

Avoid using 565 colours. Again look at that example I wrote - it turns a layer of CRGB's straight to the DMA library as RGB24 (drawpixel888), so no colour depth lost.

Also, percieved dimming to the eye is a function of frequency and resolution. Getting this right to the 'eye' is an art, not a science:

• Before calling .begin() for this library try reducing the refresh frequency, setMinRefreshRate(40)?
• As part of the matrix configuration set mxconfig.clk_speed = HUB75_I2S_CFG::HZ_20M

etc.

The drawback with these these 'scan line' panels is that it is difficult to get really faint darkness as it's a function of on-off frequency the ESP can transmit, and how the eye works (persistence of vision). If you shake the panel when in use, you'll see the leds flicker etc.

[hallard]

Yeah, that makes sense also. I saw afterward about the layer stuff in examples and I will use them, should fit my needs.

I'm avoiding as far as I can 565 color but only some are overloaded from Adafruit, I mean we have fillRect() overloaded with 888 but not drawRect() meaning my code using both depending on feature needed. See example below.

void drawProgressBar(uint16_t x, uint16_t y, uint16_t w, uint16_t h, uint8_t progress, CRGB rectColor, CRGB color) 
{
  uint16_t max = w * progress / 100;
  CRGB c = colorBrightness888(color);

  if (h>=3) {
    display->drawRect( x, y, w, h, colorBrightness(rectColor));
    display->fillRect( x+1, y+1, max, h-2, c.r, c.g, c.b);
  } else {
    display->fillRect( x, y, max, h, c.r, c.g, c.b);
  }
}

Anyway I like the layer approach and I will do something like that. Worth having only one layer code elsewhere to be used by examples (and other), not sure where the best place is to keep it, I mean if each dev use it's own layer or create a layer lib.

Thanks

[mrcodetastic]

The copy of Adafruit GFX that I use instead of Adafruit GFX (https://github.com/mrfaptastic/Adafruit_GFX_Lite)... I think I'll make a version so that every existing Adafruit_GFX function can take a FastLED CRGB value.

This Adafruit 565 limitation keeps coming up when people want to draw rectanges etc and use native 24 bit color.

Please note though, @vortigont implemented some adafruit functions natively in the DMA library for performance, called fillRectDMA, vlineDMA and hlineDMA - and they take r, g, b values. i.e.

void fillRectDMA(int16_t x_coord, int16_t y_coord, int16_t w, int16_t h, uint8_t r, uint8_t g, uint8_t b); 

[hallard]

That would be awesome :-)

Yeah I'm using primitive when they exists, used fillRectDMA()but no drawRectDMA() existing, that is why I was a little lost on startup, but now I got deeper into the code and learned a lot.

By the way, I've done some testing for brightness, looks like now (my latest were 2 months ago) with the panels I got, hardware is fine for what I need and I can dim with LDR very easily. Much better using HW than dimming RGB colro (to my eyes)

[vortigont]

drawRect should use fastlines internally, but no RGB888 color in that case. Actually you should not call *DMA methods directly. There are rgb888 overloads compatible with Adafruit's methods.
Never thought it be useful :) If you could find it useful than I might need to consider implementing drawRect also )

[hallard]

Yeah of course I'm calling exposed functions from the library not the direct DMA ones :-)

Thanks.

[mrcodetastic]

Here's a hacked version of pattern plazma to make it super dark. You need to experiment with the right panel brightness vs. nscale mix.

Would be interested to know from your 'eyeball' testing what gives the faintest.

Seems to look ok to me. Having a smaller panel brightness, and larger nscale8 value seems to give a better result than the other way around.

#include <ESP32-HUB75-MatrixPanel-I2S-DMA.h>
#include <FastLED.h>

// Configure for your panel(s) as appropriate!
#define PANEL_WIDTH 64
#define PANEL_HEIGHT 32  	// Panel height of 64 will required PIN_E to be defined.
#define PANELS_NUMBER 1 	// Number of chained panels, if just a single panel, obviously set to 1
#define PIN_E -1

#define PANE_WIDTH PANEL_WIDTH * PANELS_NUMBER
#define PANE_HEIGHT PANEL_HEIGHT


// placeholder for the matrix object
MatrixPanel_I2S_DMA *dma_display = nullptr;


uint16_t time_counter = 0, cycles = 0, fps = 0;
unsigned long fps_timer;

CRGB currentColor;
CRGBPalette16 palettes[] = {HeatColors_p, LavaColors_p, RainbowColors_p, RainbowStripeColors_p, CloudColors_p};
CRGBPalette16 currentPalette = palettes[0];


CRGB ColorFromCurrentPalette(uint8_t index = 0, uint8_t brightness = 255, TBlendType blendType = LINEARBLEND) {
  return ColorFromPalette(currentPalette, index, brightness, blendType);
}

void setup() {
  
  Serial.begin(115200);
  
  Serial.println(F("*****************************************************"));
  Serial.println(F("*        ESP32-HUB75-MatrixPanel-I2S-DMA DEMO       *"));
  Serial.println(F("*****************************************************"));

  /*
    The configuration for MatrixPanel_I2S_DMA object is held in HUB75_I2S_CFG structure,
    pls refer to the lib header file for full details.
    All options has it's predefined default values. So we can create a new structure and redefine only the options we need 

    // those are the defaults
    mxconfig.mx_width = 64;                   // physical width of a single matrix panel module (in pixels, usually it is always 64 ;) )
    mxconfig.mx_height = 32;                  // physical height of a single matrix panel module (in pixels, usually amost always it is either 32 or 64)
    mxconfig.chain_length = 1;                // number of chained panels regardless of the topology, default 1 - a single matrix module
    mxconfig.gpio.r1 = R1;                    // pin mappings
    mxconfig.gpio.g1 = G1;
    mxconfig.gpio.b1 = B1;                    // etc
    mxconfig.driver = HUB75_I2S_CFG::SHIFT;   // shift reg driver, default is plain shift register
    mxconfig.double_buff = false;             // use double buffer (twice amount of RAM required)
    mxconfig.i2sspeed = HUB75_I2S_CFG::HZ_10M;// I2S clock speed, better leave as-is unless you want to experiment
  */

  /*
    For example we have two 64x64 panels chained, so we need to customize our setup like this

  */
  HUB75_I2S_CFG mxconfig;
  mxconfig.mx_height = PANEL_HEIGHT;      // we have 64 pix heigh panels
  mxconfig.chain_length = PANELS_NUMBER;  // we have 2 panels chained
  mxconfig.gpio.e = PIN_E;                // we MUST assign pin e to some free pin on a board to drive 64 pix height panels with 1/32 scan

  mxconfig.i2sspeed = HUB75_I2S_CFG::HZ_20M;  
  mxconfig.min_refresh_rate = 60;  
  


  // OK, now we can create our matrix object
  dma_display = new MatrixPanel_I2S_DMA(mxconfig);  

  //
  // CHANGE THIS VALUE
  //
  dma_display->setBrightness8(16);    // range is 0-255, 0 - 0%, 255 - 100% 
  

  // Allocate memory and start DMA display
  if( not dma_display->begin() )
      Serial.println("****** !KABOOM! I2S memory allocation failed ***********");
      
}

void loop() {
  
    for (int x = 0; x < PANE_WIDTH; x++) {
            for (int y = 0; y <  PANE_HEIGHT; y++) {
                int16_t v = 0;
                uint8_t wibble = sin8(time_counter);
                v += sin16(x * wibble * 3 + time_counter);
                v += cos16(y * (128 - wibble)  + time_counter);
                v += sin16(y * x * cos8(-time_counter) / 8);

                currentColor = ColorFromPalette(currentPalette, (v >> 8) + 127); //, brightness, currentBlendType);

  //
  // CHANGE THIS VALUE
  //                
                currentColor.nscale8(64); // CHANGE THIS VALUE
                
                dma_display->drawPixelRGB888(x, y, currentColor.r, currentColor.g, currentColor.b);
            }
    }

    ++time_counter;
    ++cycles;
    ++fps;

    if (cycles >= 1024) {
        time_counter = 0;
        cycles = 0;
        currentPalette = palettes[random(0,sizeof(palettes)/sizeof(palettes[0]))];
    }

    // print FPS rate every 5 seconds
    // Note: this is NOT a matrix refresh rate, it's the number of data frames being drawn to the DMA buffer per second
    if (fps_timer + 5000 < millis()){
      Serial.printf_P(PSTR("Effect fps: %d\n"), fps/5);
      fps_timer = millis();
      fps = 0;
    }
} // end loop

[hallard]

Tested, I confirm software really change vision moreover at lower values.
But I let see by yourself, and as I understood you hate flashing for testing, I modified your example, you can change hardware and software brightness sending according commands on serial monitor:-)

example:

• sw 128 set software to 50%
• hw 64 set hardware to 25%

Here the modified code, worth adding into examples folder, have fun

#include <ESP32-HUB75-MatrixPanel-I2S-DMA.h>
#include <FastLED.h>


// Configure for your panel(s) as appropriate!
#define PANEL_WIDTH 64
#define PANEL_HEIGHT 32  	// Panel height of 64 will required PIN_E to be defined.
#define PANELS_NUMBER 1 	// Number of chained panels, if just a single panel, obviously set to 1

#define PANE_WIDTH PANEL_WIDTH * PANELS_NUMBER
#define PANE_HEIGHT PANEL_HEIGHT


// placeholder for the matrix object
MatrixPanel_I2S_DMA *dma_display = nullptr;


uint16_t time_counter = 0, cycles = 0, fps = 0;
unsigned long fps_timer;

// Default values, 50% hardware brightness 50% software 
uint8_t hw_brightness = 128;
uint8_t sw_brightness = 128;


CRGB currentColor;
CRGBPalette16 palettes[] = {HeatColors_p, LavaColors_p, RainbowColors_p, RainbowStripeColors_p, CloudColors_p};
CRGBPalette16 currentPalette = palettes[0];


CRGB ColorFromCurrentPalette(uint8_t index = 0, uint8_t brightness = 255, TBlendType blendType = LINEARBLEND) {
  return ColorFromPalette(currentPalette, index, brightness, blendType);
}

void setup() {
  
  Serial.begin(115200);
  
  Serial.println(F("*****************************************************"));
  Serial.println(F("*        ESP32-HUB75-MatrixPanel-I2S-DMA DEMO       *"));
  Serial.println(F("*****************************************************"));

  /*
    The configuration for MatrixPanel_I2S_DMA object is held in HUB75_I2S_CFG structure,
    pls refer to the lib header file for full details.
    All options has it's predefined default values. So we can create a new structure and redefine only the options we need 

    // those are the defaults
    mxconfig.mx_width = 64;                   // physical width of a single matrix panel module (in pixels, usually it is always 64 ;) )
    mxconfig.mx_height = 32;                  // physical height of a single matrix panel module (in pixels, usually amost always it is either 32 or 64)
    mxconfig.chain_length = 1;                // number of chained panels regardless of the topology, default 1 - a single matrix module
    mxconfig.gpio.r1 = R1;                    // pin mappings
    mxconfig.gpio.g1 = G1;
    mxconfig.gpio.b1 = B1;                    // etc
    mxconfig.driver = HUB75_I2S_CFG::SHIFT;   // shift reg driver, default is plain shift register
    mxconfig.double_buff = false;             // use double buffer (twice amount of RAM required)
    mxconfig.i2sspeed = HUB75_I2S_CFG::HZ_10M;// I2S clock speed, better leave as-is unless you want to experiment

    // ElectroDragon Board with ESP32 Pico D4
    mxconfig.gpio.d = 22;
    mxconfig.gpio.e = 9;
    mxconfig.gpio.clk = 21;
    // ElectroDragon Board with ESP32 DevKit
    mxconfig.gpio.d = 17;
    mxconfig.gpio.e = 18;
    mxconfig.gpio.clk = 16;
  */

  /*
    For example we have two 64x64 panels chained, so we need to customize our setup like this

  */
  HUB75_I2S_CFG mxconfig;
  mxconfig.mx_height = PANEL_HEIGHT;      // we have 64 pix heigh panels
  mxconfig.chain_length = PANELS_NUMBER;  // we have 2 panels chained

  mxconfig.gpio.e = E_PIN;                // we MUST assign pin e to some free pin on a board to drive 64 pix height panels with 1/32 scan

  mxconfig.i2sspeed = HUB75_I2S_CFG::HZ_20M;  
  mxconfig.min_refresh_rate = 60;  
  

  // OK, now we can create our matrix object
  dma_display = new MatrixPanel_I2S_DMA(mxconfig);  

  dma_display->setBrightness8(hw_brightness);    // range is 0-255, 0 - 0%, 255 - 100% 

  // Allocate memory and start DMA display
  if( not dma_display->begin() )
      Serial.println("****** !KABOOM! I2S memory allocation failed ***********");
      
}

void loop() {
    static String str ;

    while (Serial.available() ) {
       str = Serial.readString();

       if (str.startsWith("hw")) {
           hw_brightness = str.substring(2).toInt();
           Serial.printf_P(PSTR("hw brightness %d\n"), hw_brightness);
           dma_display->setBrightness8(hw_brightness);    
       } else if (str.startsWith("sw")) {
           sw_brightness = str.substring(2).toInt();
          Serial.printf_P(PSTR("sw brightness %d\n"), sw_brightness);
       } else {
          Serial.println("bad input");
       }
    }

    for (int x = 0; x < PANE_WIDTH; x++) {
            for (int y = 0; y <  PANE_HEIGHT; y++) {
                int16_t v = 0;
                uint8_t wibble = sin8(time_counter);
                v += sin16(x * wibble * 3 + time_counter);
                v += cos16(y * (128 - wibble)  + time_counter);
                v += sin16(y * x * cos8(-time_counter) / 8);

                currentColor = ColorFromPalette(currentPalette, (v >> 8) + 127); //, brightness, currentBlendType);

                if (sw_brightness<255) {
                  currentColor.nscale8(sw_brightness); 
                }
                
                dma_display->drawPixelRGB888(x, y, currentColor.r, currentColor.g, currentColor.b);
            }
    }

    ++time_counter;
    ++cycles;
    ++fps;

    if (cycles >= 1024) {
        time_counter = 0;
        cycles = 0;
        currentPalette = palettes[random(0,sizeof(palettes)/sizeof(palettes[0]))];
    }

    // print FPS rate every 5 seconds
    // Note: this is NOT a matrix refresh rate, it's the number of data frames being drawn to the DMA buffer per second
    if (fps_timer + 5000 < millis()){
      Serial.printf_P(PSTR("Effect fps: %3d  Brightness(hw:%3d, sw:%3d)\n"), fps/5, hw_brightness, sw_brightness);
      fps_timer = millis();
      fps = 0;
    }
} // end loop

[vortigont]

That's an interesting topic.
Recently I was into this a little bit and it is not as simple as it may seem at first. It is much easier to display high brightness picture on LED matrixes than to get a dim but still fine gradients. I wrote about some of my finding here and there. Avoid "software" brightness as much as possible - it kills dynamic range in low colors, that is exactly your case if I understood you right.
There are still lot's of "dark places" in this area for me, but I you might wanna test it the other way around - "raise the color value, but reduce hardware brightness". I.e. shift color values 1 or 2 bits towards MSB to enhance shadows, but reduce HW brightness control to the minimum. It may seems strange at first, but makes sense in some specific cases. Also you might find shadows looking better at low brightness looking better with NO_CIE1931 compile-time option. But it's a one way ticket - either better under low brightness or juicy color with high brightness. Or taking it over in your hands and implementing some kind of software HDR :) (quite a task for a tiny MCU, huh?)
Also the is a feature of "true" hardware brightness control for FM6126A chips, which could make a really darker image indeed. But I'm still out of spare time to deep dive into this to implement a full support.
Pls, share your findings, that could be interesting...
@mrfaptastic maybe we should try that new guthub feature as "discussions"? Such topics could be useful to have around for others also than just bury it under closed issues, what do you think?

[mrcodetastic]

Good idea. Welcome to the forum! :)

[hallard]

@mrfaptastic thanks I'll try this one ASAP and report back
@vortigont absolutely my issue and conclusion not simple has I thought. I even thought (but not tested yet) to use HW because I prefer HW as much as I can not touching RGB values, and then on the lowest (minimum HW brightness) if it's too high reduce with software. Not the proper way but could work.
Anyway current HW minimal mode are fine for me for indoor panels I can live with that, my deal is with outdoors ones, I need to do more testing.
BTW, for sure on ESP32 (not 328P), I think we can leave 565 as far as we can :-)

[vortigont]

Never tried outdoors, what's the difference between two? I mean besides physical size/casing. Does it uses some specific drivers/amplifiers?

[hallard]

Brightness is amazing and bigger leds (and may be kind of waterproof), despite that, all looks identical, always driving panels with same code whatever indoor or outdoor

[mrcodetastic]

The outdoor panels will be difficult to get them very dim I think. They're supposed to be super bright to combat outdoor sunlight.

[hallard]

@mrfaptastic just a little trick in case you're not aware, if you want your code to be syntax colored in github, just add langage after triple back quote like that ```cpp, you can edit this comment to see :-)

void main(void)

[mrcodetastic]

I learn something new every day !

[hallard]

Guys,
May be a stupid question, but when I change the brightness (hardware) I need to clear display as states the documentation. So this mean I need to refresh all screen with values. I'm afraid of answer, but in my case I got values from MQTT broker, and until I receive new values I can't display back except if I get into ram all values displayed so I can refresh them.

Am I correct?

[vortigont]

Nah... It has been changed some time ago. Docs might be outdated, but no need to clear screen now. Brightness applied directly to DMA data w/o loosing color data.

[hallard]

OMG yeah it's working fine now, you saved my day (and my code size) :-)