The two blue dots on my matrix are black dots on the original and the blue eye dot looks very light blue on my matrix
Do you have a Teensy with SD card that you could try the code on and compare? There could be something specific to the ESP8266 environment or libraries that is breaking the decoder. I’ve most recently run this code on ESP32 and didn’t notice any of the issues you’ve seen.
@Louis_Beaudoin so, I just spent some time porting my code to work on teensy 3.6, and still have the same problem. Some gifs look just fine, and some look white-ish and the colors are wrong.
Did you try chasm1 on your current branch?
Given the decoding numbers I gave above and that seem wrong, this is not a smartmatrix vs neomatrix problem from what I can tell, would you agree?
The GIF is being decoded correctly, you can open it in http://Piskelapp.com and check the pixels:
missing/deleted image from Google+
The issue is likely because your libraries don’t have color correction (aka gamma correction) enabled, like SmartMatrix Library does. Compare these two pictures, one has SmartMatrix color correction enabled and one doesn’t:
missing/deleted image from Google+
missing/deleted image from Google+
Those pictures have a piece of printer paper above the LEDs for diffusion. Without the paper the no-color-correction example is extremely washed out, like your example photo
@Louis_Beaudoin first I wanted to thank you again for your patience and your time.
On gamma correction, I do think FastLED has it enabled, I use uFastLED.addLeds<WS2811_PORTA,3>(matrixleds, NUMMATRIX/3).setCorrection(TypicalLEDStrip)
which does gamma correction
However, looking at your screenshots (thanks for posting), even your “bad” screenshot is much better than mine
I think there is another problem here, let me give you my decoding numbers for the raw gifs pixels before they get displayed, so we can compare those.
missing/deleted image from Google+
Let’s take line #11, which has the blue dot for the eye. My code outputs the bad result below, note that 9,11 (8,10 when counting from 0), unless I’m counting wrong is the blue dot for the eye, which does not show up either in the picture I pasted above, or here in those rgb values for chasm1.gif:
0,10>21,27,41
1,10>30,34,50
2,10>38,42,59
3,10>30,34,50
4,10>21,27,41
5,10>30,34,50
6,10>127,83,78
7,10>98,58,52
8,10>255,207,170
9,10>255,207,170
10,10>255,207,170
11,10>181,119,95
12,10>15,21,33
13,10>15,21,33
14,10>15,21,33
15,10>30,34,50
16,10>38,42,59
17,10>66,62,65
18,10>30,34,50
19,10>38,42,59
20,10>38,42,59
21,10>66,62,65
22,10>66,62,65
23,10>30,34,50
24,10>30,34,50
25,10>30,34,50
26,10>30,34,50
27,10>30,34,50
28,10>38,42,59
29,10>38,42,59
30,10>30,34,50
31,10>30,34,50
The values for pixels 8,9,10 on line 10 (line 11 starting from 1) are the same, this just doesn’t match the image :-/
Can you try this patch on your code?
void drawPixelCallback(int16_t x, int16_t y, uint8_t red, uint8_t green, uint8_t blue) {
if (y == 10) {
Serial.print(x);
Serial.print(“,”);
Serial.print(y);
Serial.print(“>”);
Serial.print(red);
Serial.print(“,”);
Serial.print(green);
Serial.print(“,”);
Serial.print(blue);
Serial.println(“”);
}
}
Then after decoder.decodeFrame();
add a delay (10000000)
so that you can capture the output like I did, and force the index to display chasm1.
FastLED has color balance correction, not gamma correction:
You can compare what you decode to the values in the image using http://piskelapp.com. LMK if you see any specific pixels that are wrong
@Louis_Beaudoin please correct me, but I posted decoded pixels from your library before they went to Fastled. Can you make sure those aren’t wrong? (because they look wrong). I’ll check piskelapp tonight but a manual check I did twice and posted, did look wrong
@Louis_Beaudoin so I used piskelapp, and basically repeated what I was already saying above 
The first decode frame of chasm1.gif by your app has the blue pixel for the eye at 8,10 (starting from 0,0): 86,123,150 as decoded by piskelapp
the adjacent skin pixels at 9,10 and 10,10 are both 255,207,170 as decoded by piskelapp
11,10 is 218,146,115 as decoded by piskelapp
The pixels decode by your library, are:
8,10>255,207,170
9,10>255,207,170
10,10>255,207,170
11,10>181,119,95
2 of those (50%) are very wrong, so the library seems broken. I ran your code again on teensy, and same output:
8,10>255,207,170
9,10>255,207,170
10,10>255,207,170
11,10>181,119,95
I filed a bug here: https://github.com/pixelmatix/AnimatedGIFs/issues/21
Line 10 is the chin, not the eye. Line 8 has a blue pixel for the eye. The blue pixel is at 8,8. I compared the output from the GIF decoder with Piskelapp for line 10 and line 8, and they’re identical. Are you mixing up the row and column somehow? Anyway, I don’t think there’s a GIF decoding issue.
@Louis_Beaudoin you are correct on the pixel location, the confusion came from gimp showing me the last frame of the GIF, and me looking at the last frame in piskel, but indeed your library (and my picture of the decoded image) are the first frame, sorry about that (the displayed decoded frame looks so bad on my neomatrix that I missed the fact that they were different).
My apologies for this mistake.
Now, the decoded values seem to match the pixel locations, but indeed the colors are wrong.
Now, the good news is that FastLED does have gamma support, and it makes things much better (not perfect, but better for sure).
The bad news is that it seems quite slow, I only get 3-4fps with an ESP8266 at 160Mhz.
@Daniel_Garcia , about gamma support being slow:
All I did was this:
void drawPixelCallback(int16_t x, int16_t y, uint8_t red, uint8_t green, uint8_t blue) {
+#ifdef NEOMATRIX
- CRGB color = applyGamma_video(CRGB(red, green, blue), matrix_gamma);
- matrix->setPassThruColor(red65536 + green256 + blue);
- matrix->setPassThruColor(color.red65536 + color.green256 + color.blue);
It’s a 768 pixel array, and removing the gamma computation brings me back to something 2-3x faster (but the colors look wrong)
I can see that uint8_t applyGamma_video( uint8_t brightness, float gamma) uses floating point math, which seems too slow, even on an ESP8266 (never mind a slower arduino).
I guess I know why most people use precomputed tables, but then you can’t feed a gamma factor and try different values easily.
Seems like the best solution is to init fastLED with a gamma correction, this would create a 255 element array (one per color channel if people care, but I only care about one global one), and pre-fill it with the computed values. Then it would be a much faster lookup instead of re-calculating the gamma value over and over again.
@Louis_Beaudoin I already sent you a PR for your code to add support for teensy 3.6 SD and neomatrix. I still have more code I can send to support built in flash on ESP8266 or ESP32 instead of SD. Are you interested? If so, I’ll do more integration work and send you another PR after the current one has been merged (they build on top of one another)
Gamma curves are one of those things that people have enough opinions about that, for the most part, I’d rather let them deal with gamma on their own before they hand the leds off to FastLED to write out : ) – which is why it’s there as a color utility function but not actually worked into FastLED’s output pipeline. (Also - there isn’t really a “best” solution - because it depends on platform, source image material (I don’t make use of gamma because of the way I write my own animations - and I don’t do image display with any of the work that I do), cpu requirements, memory requirements, etc… etc… etc…)
Anyway, there’s a cheating way to get a psuedo gamma curve (I forget what it lines up with) by scaling a value by itself - you’d want two CRGB arrays - one that’s your working array, and one that’s your output array, then you can do something like:
for(int i = 0; i < NUM_LEDS; i++) {
out_leds[i] = work_leds[i].scale8(work_leds[i]);
}
But it’s effectively a fixed gamma curve. @Mark_Kriegsman worked out what kind of gamma it was - it might have been a 2.0 gamma curve? But don’t quote me on that.
Actually you might want something more like:
for(int i = 0; i < NUM_LEDS; i++) {
out_leds[i].r = scale8_video(work_leds[i].r, work_leds[i],r);
out_leds[i].g = scale8_video(work_leds[i].g, work_leds[i],g);
out_leds[i].b = scale8_video(work_leds[i].b, work_leds[i],b);
}
But anyway it’s all integer math - not floating point.
Thanks @Daniel_Garcia , glad to know about this way too. In my case, I found out I need a gamma of 3 for things to look ok, so I’ll probably go the pre-computed array route, but that’s another interesting way of doing it.
Marc, I’m definitely interested in the built in flash support, though I can’t promise when I’ll be able to merge the PR. Thanks for the contributions!