Apollo M-1 Image are showing in orange red colour

[robvdl]

What happened?

I have an Apollo M-1 with a 64x64 MuonOpto panel. Everything seems to be working just fine with the exception when I use "Image" the picture shows normal briefly and then an orange effect is applied.

All images are shown in red/orange colour, but everything else works fine so it isn't the panel configuration.

I've tried various things but all images always come up in orange red colour. Even if it is the only segment used.

To Reproduce Bug

1. Create an Image segment and assign a simple GIF image
2. Default blend mode used: Top/Default
3. The picture shows in orange/red

Sometimes you notice it briefly showing in the correct colours then then red colour is applied.

It is only happening when "Image" is used.

Expected Behavior

Show the image in it's normal colours.

Install Method

Binary from WLED.me

What version of WLED?

WLED version 16.0.1

Which microcontroller/board are you seeing the problem on?

ESP32-S3

Relevant log/trace output

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[robvdl]

I just would like to add that "peek" shows the image correctly.

It only shows red/orange on the screen.

But it isn't a panel configuration issue because every other effect works perfectly. Only Image effect shows in red/orange.

[softhack007]

@robvdl we need to know how you configured everything in LEDs & Hardware settings. Also we need your gif image file, and a screenshot of WLED's "info" when the image effect runs.

[DedeHai]

If peek is correct and all other effects work (and if these statements are correct) then it can only be
a) an issue with HUB75 driver (unlikely as this would have been reported a long time ago)
b) issue with your setup / power (most likely)

[softhack007]

@DedeHai or maybe c) ABL is enabled and milliamps per led are way too high.

[DedeHai]

@DedeHai or maybe c) ABL is enabled and milliamps per led are way too high.

that should not turn them red, unless double gamma is somehow involved. Last time I checked 16.x it all worked perfectly. I can run a quick check but I highly doubt this is bug related.

[softhack007]

@DedeHai @robvdl I could not reproduce the problem with my test setup. So my idea about ABL killing colors seems incorrect,

I see a few possible explanations

• the GIF file that @robvdl uses may be rather big, may contain transparent pixels, or maybe has features that stress WLED's gif decoder. This could lead to the first frame showing correctly, but all others having bad colors --> please upload the specific GIF file here, so we can cross-check.
• WLEDs GIF decoder running out of memory --> try to re-size your gif file to 32x32 or 64x64 pixels maximum, and check the "free heap" showing in "info".
• hardware problems --> Please contact apollo automation for support
  • wiring problems, including too thin 5V/GND wires
  • your PSU may break down when high-brightness images require more power than the supply can deliver
  • Thermal stress - check if your fixture gets very warm
  • some M-1 boards have broken PSRAM. These boards don't work well in vanilla WLED.
  • the panel hardware might be incompatible (shiftreg chipset not supported yet in WLED).

Edit: @DedeHai I agree we can exclude an issue with the HUB75 bus driver - the driver itself is rock solid from my experience with different panels, its 90% the same code in WLED and WLED-MM.

[softhack007]

@robvdl please also check if solid blue, solid cyan, solid magenta, or solid white cause problems on your panel. Start with low brightness, then turn up the brightness gradually, and check if colors change or start to flicker.

[robvdl]

One thing though I would like to add this is an image that is already on the device when you get it from Apollo. I tried multiple images obviously to make sure it isn't just that one image.

I also see the image correctly briefly and then the red colour is applied to it. Like you can definitly tell it is a software thing, not hardware. I could be wrong, but that is just my observation.

I do understand I am using a MuenOpto panel with the HUB75 but every other effect is showing fine. Only the "Image" effect does this.

Which is why it does look like software. But I can always try flashing my own firmware, compile it myself, see what is going on.

[robvdl]

What you may not actually be able to see very well in the photo unless I mention it. It isn't just applying a solid red colour. There are 3 distinct lines as well. But I'm pretty sure it is software applying this to the image. It's just what it looks like from the observer.

The reason why I think it might be software is because if I do set the blend mode to "Average" the image displays a bit better, though there is still some of this orange shining through.. But it's a bit different if I change the blend mode. Obviously this is the only layer I have enabled, which is what I don't quite understand.

I've been playing around a bit with the other effects and none do this except for "Image".

[softhack007]

@robvdl you read my requests above ?

#5830 (comment) #5830 (comment)

This information is necessary - we need to reproduce the problem, otherwise we can't help. I think no maintainer has your Apollo M-1 with a 64x64 MuonOpto panel, your PSU and exactly your wiring.

[robvdl]

The solid colour tests are the only meaningful tests that got some information something is wrong. Things that effects don't easily show.

The other things like "image too big" or GIF decoder running out of memory, I don't think it's any of those. PSU is also good (5V 5amp). I don't see the panel warming up either. So we can safely eliminate those I think.

So here goes the colours:

• solid blue - OK
• solid cyan - wrong, same as solid green
• solid green - OK
• solid magenta - wrong, same as solid red
• solid white - wrong, same as solid red

Wiring

• Apollo M-1 modules you just plug them in with a single plug, so not much wiring to test really

[robvdl]

I do find it odd the image showed correctly briefly. But then I don't know the code. The colour tests definitly show something misconfigured.