Image array into ESP32

The sketch below currently works by converting a bmp into an array using this conversion tool… lcd-image-converter download | SourceForge.net however it creates a large code due to there being 8 charachters for each Led like this 0x000000, to make the code smaller I would like to express the led array values in this smaller format 0x00 which is generated using this converter File to hex converter
The problem is that using this File to hex converter creates gibberish on the leds, I have tried out various permeatations to no avail, any pointers or suggestions would be greatly appreciated.

#include "FastLED.h"       // Fastled library to control the LEDs

// How many leds are connected?
#define NUM_LEDS 256  //using 16x16 neomatrix

// Define the Data Pin
#define DATA_PIN 13  // Connected to the data pin of the first LED strip

// Define the array of leds
CRGB leds[NUM_LEDS];
//http://tomeko.net/online_tools/file_to_hex.php?lang=en
//https://sourceforge.net/projects/lcd-image-converter/

// Create array and store it in Flash memory


const long imageone[] PROGMEM =    //converter used  https://sourceforge.net/projects/lcd-image-converter/  Works! was bmp
{
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xf80305, 0x83365c, 0x355998, 0xa52744, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xfe0000, 0xc6182a, 0x2062a8, 0x026fbe, 0x644474, 0xf70406, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xf70406, 0x644474, 0x026fbe, 0x046ebd, 0x46518b, 0xbd1d31, 0xf70306, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xa92640, 0x265fa3, 0x0070c0, 0x0070c0, 0x026fbe, 0x644474, 0xf70406, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xf70406, 0x644474, 0x026fbe, 0x2f5c9d, 0xa02a47, 0x365898, 0x7e3961, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xeb080e, 0x3a5694, 0x026fbe, 0x644474, 0xf70406, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xf70406, 0x644474, 0x026fbe, 0x3a5694, 0xeb080e, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xeb080e, 0x3a5694, 0x026fbe, 0x644474, 0xf70406, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xf70406, 0x644474, 0x026fbe, 0x3a5694, 0xeb080e, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xeb080e, 0x3a5694, 0x026fbe, 0x644474, 0xf70406, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xfa0204, 0xa22846, 0x674272, 0x893358, 0xf30508, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 
0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000, 0xff0000
};

//const long imagetwo[] PROGMEM = 
const uint8_t imagetwo[] PROGMEM =     // http://tomeko.net/online_tools/file_to_hex.php?lang=en jpg mangled, gif mangled, bmp
{
0xFF, 0xD8, 0xFF, 0xE0, 0x00, 0x10, 0x4A, 0x46, 0x49, 0x46, 0x00, 0x01, 0x01, 0x01, 0x00, 0x60, 
0x00, 0x60, 0x00, 0x00, 0xFF, 0xDB, 0x00, 0x43, 0x00, 0x06, 0x04, 0x05, 0x06, 0x05, 0x04, 0x06, 
0x06, 0x05, 0x06, 0x07, 0x07, 0x06, 0x08, 0x0A, 0x10, 0x0A, 0x0A, 0x09, 0x09, 0x0A, 0x14, 0x0E, 
0x0F, 0x0C, 0x10, 0x17, 0x14, 0x18, 0x18, 0x17, 0x14, 0x16, 0x16, 0x1A, 0x1D, 0x25, 0x1F, 0x1A, 
0x1B, 0x23, 0x1C, 0x16, 0x16, 0x20, 0x2C, 0x20, 0x23, 0x26, 0x27, 0x29, 0x2A, 0x29, 0x19, 0x1F, 
0x2D, 0x30, 0x2D, 0x28, 0x30, 0x25, 0x28, 0x29, 0x28, 0xFF, 0xDB, 0x00, 0x43, 0x01, 0x07, 0x07, 
0x07, 0x0A, 0x08, 0x0A, 0x13, 0x0A, 0x0A, 0x13, 0x28, 0x1A, 0x16, 0x1A, 0x28, 0x28, 0x28, 0x28, 
0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 
0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 
0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0xFF, 0xC0, 
0x00, 0x11, 0x08, 0x00, 0x10, 0x00, 0x10, 0x03, 0x01, 0x22, 0x00, 0x02, 0x11, 0x01, 0x03, 0x11, 
0x01, 0xFF, 0xC4, 0x00, 0x16, 0x00, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x07, 0xFF, 0xC4, 0x00, 0x1C, 0x10, 0x00, 0x02, 
0x02, 0x02, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x02, 
0x00, 0x03, 0x11, 0x41, 0x12, 0x31, 0x51, 0xFF, 0xC4, 0x00, 0x15, 0x01, 0x01, 0x01, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x06, 0x07, 0xFF, 0xC4, 
0x00, 0x21, 0x11, 0x00, 0x01, 0x02, 0x05, 0x05, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x00, 0x01, 0x11, 0x41, 0x00, 0x02, 0x03, 0x12, 0x21, 0x05, 0x14, 0x23, 0x31, 0x51, 
0x24, 0xFF, 0xDA, 0x00, 0x0C, 0x03, 0x01, 0x00, 0x02, 0x11, 0x03, 0x11, 0x00, 0x3F, 0x00, 0xCF, 
0x2B, 0x42, 0xED, 0x8D, 0x42, 0xC5, 0xE2, 0xE4, 0x0D, 0x49, 0x4E, 0x18, 0x13, 0xEC, 0x6C, 0x21, 
0x9C, 0x91, 0xD4, 0x39, 0xC1, 0xB3, 0xC0, 0xE4, 0xBB, 0xD6, 0x42, 0xDE, 0x45, 0xDF, 0xED, 0x1A, 
0xB2, 0x12, 0xB4, 0x0D, 0x33, 0x84, 0xC0, 0x9A, 0xE9, 0x7B, 0x2E, 0x48, 0x54, 0xEB, 0x0C, 0xF1, 
0xFF, 0xD9
};


void setup() { 
FastLED.addLeds<NEOPIXEL,DATA_PIN>(leds, NUM_LEDS);  // Init of the Fastled library
FastLED.setBrightness(15);
}

void loop() { 


// Put imageone first frame
for(int passtime = 0; passtime < 8; passtime++) { // Display it 8 times

FastLED.clear();
for(int i = 0; i < NUM_LEDS; i++) {
    leds[i] = pgm_read_dword(&(imageone[i]));  // Read array from Flash
  }

FastLED.show();
delay(500);

// Put imagetwo second frame
FastLED.clear();
for(int i = 0; i < NUM_LEDS; i++) {
    leds[i] = pgm_read_dword(&(imagetwo[i]));
  }

FastLED.show();
delay(400);



}

}

A typical addressable RGB LED requires 24 bits to specify 3 colors of 8 bits each. Are you proposing to squeeze that information into 8 bits? How will that work?

Sorry I know close to nothing at all about this, I,m using ws2812b leds, I just tried const uint32_t still getting gibberish on "imagetwo" whilst "imageone" comes up alternatly and displays correctly

WS2812B LEDs require 24 bits per pixel. That’s what imageone gives you. You’re trying to solve a problem that you don’t have.

Although, I would change it from ‘const long’ to ‘const unsigned long’ or ‘const uint32_t’.

EDIT:
WS2812b Datasheet Attached.

WS2812B.pdf (335 KB)

Are you saying that the File to hex converter converter outputting this 4 charachter 0x00 code is incapable of driving ws2812b ?? thanks

Short answer - that's what I'm saying. But, again, I don't know what problem you're trying to solve. What you have for imageone is correct.

You can't just switch image converters and expect things to work. You have to use the right one for the output module that you have. The second one doesn't work? Well yeah, it's not providing the same data as the first working one, why would you expect it to?

My ambition is to create a side show, 3 slides each 180 pixels high x 360 pixels wide 180x360=64800 ws28i2b leds, divided up to come off most of the pins on the esp32, this is why i,m obsessing about the file size of the array and looking at ways to minimise the code array, i,m told by the fastledders that the code cant play gifs in psram or sd card because it isnt fast enough.
the working imageone code always begins with 0x , the lcd-image-converter download | SourceForge.net converter permits me to remove this 0x portion so is there a way of coding to assume it all begins with the 0x thus reducing the array file size by 25% ? thanks

A little knowledge is a dangerous thing. Your obsession with the 0x is misplaced. That's just the syntax for constants expressed in hex notation. It's the data types that set the amount of data memory your program occupies. Also, quit worrying about the size of the ASCII source file.

The important thing to understand is the memory required for you images. Each WS2812B pixel needs 24 bits (3 bytes) of memory. When you store images as constants, each pixel actually occupies a 32-bit (4 byte) word in memory since there is no 24-bit data type and it would be too much messing around to pack 4 pixels into 3 32-bit words. So, 4 bytes / pixel x 64800 pixels / Slide x 3 Slides = 777600 bytes. Plus, the FastLED CRGB array will take another 194400 bytes for a total of 972000 bytes.

Obviously, that's bigger than the ESP32's RAM. The CRGB array must be in RAM. So, you'll need to store the Slides in FLASH and load them, one at a time to RAM when needed.

yes very quickly out of my depth re the inner workings of the esp32, i,m using "Huge App (3m No OTA/1mbspiffs" partition if that helps, if I had a slide show of just two 360x180 images would that help ?

Again, how do you know there's a problem? What has the compiler told you? 3M of FLASH for program and image storage seems like things would work

your right I dont know if theres a problem yet but i can waste an awful lot of time if i,m on the wrong path, you say that this 0x000000 over this 0x00 doesnt buy me any advantage so i reckon i,ll just proceed with my original imageone format.

I did discover an hour ago scintillating_heatshrink sketch which offers a complex route to 0x00

My fallback position on this would be to have lets say quantity 4 esp32 synchronised with perhaps a relay switch across the reset pads, my showtime is up to 21 seconds then reset so the 4 images should look in synch to the human eye over this relativly short display period

Yea, if you can live with 256 different colors instead of 16 Million, you can represent each pixel with a byte value that indexes in to a Color Map table.

But, seriously, the more I think about this the more I get the impression that you're in way over your head. Programming competence aside, how are you even going to power 64000+ WS2812B LEDs? Conservatively speaking, you're talking north of 1000 Amps at 5V. And, you just can't inject 5V at one end of that string and expect to see anything more than 0V at the other end.

You may want to check out what some folks who know what they are doing have done: OctoWS2811 LED Library, Driving Hundreds to Thousands of WS2811 LEDs with Teensy 3.0

My approach is to create smaller modules lets say 180 pixels wide x 90 pixels high to start with then add 3 more to create the 180x360 matrix.
Regarding the amps I would use the 12 volts ws2815, yes I,m aware of the teensy which from recollection can drive up to 900 leds per and the teensy is around £40 or something like that.

Because I am not using psram (have it disabled) or OTA is there a way to utilise all of the esp32,s 4mb ??

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.