some images not working

[osamaaj03]

Hi, missed me? So, after that last update, I'm getting this error message with some specific images:

[I] image: Using image cover_5.jpg.
[I] colors: Generating a color scheme.
[I] colors: Using wal backend.
Traceback (most recent call last):
  File "/usr/bin/wal", line 33, in <module>
    sys.exit(load_entry_point('pywal16==3.8.13', 'console_scripts', 'wal')())
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/lib/python3.14/site-packages/pywal/__main__.py", line 396, in main
    parse_args(parser)
    ~~~~~~~~~~^^^^^^^^
  File "/usr/lib/python3.14/site-packages/pywal/__main__.py", line 312, in parse_args
    colors_plain = colors.get(
        image_file,
    ...<4 lines>...
        cst=args.contrast,
    )
  File "/usr/lib/python3.14/site-packages/pywal/colors.py", line 514, in get
    colors = getattr(backend, "get")(img, light, c16=cols16)
  File "/usr/lib/python3.14/site-packages/pywal/backends/wal.py", line 127, in get
    return adjust(colors, light, c16=cols16)
  File "/usr/lib/python3.14/site-packages/pywal/backends/wal.py", line 110, in adjust
    return colors.generic_adjust(raw_colors, light, c16=cols16)
           ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.14/site-packages/pywal/colors.py", line 203, in generic_adjust
    colors[15] = colors[7]
    ~~~~~~^^^^
IndexError: list assignment index out of range

Some of them seem more on the monochrome side, so I get that, but what about the rest? Oh, and it looks like it’s loading colors much faster now, so that could be part of it. I’ll dig deeper into this later, but I thought I'd drop it here for your amusement.

Some of the images in question

[eylles]

yeh, i'm not surprised, pretty sure that is related to #198 and i have not put out a release containing #207 since i have not made the time to check every one of the images from every issue mentioned on the PR to have an idea of what works and what doesn't, been looking into adding a debug output option to pywal as while using a bunch of prints that check just for a var is one of the ways of all time to do it i've been searching if there's a more refined way to have debug info without needing to install a dedicated debugger AND that is suitable for pywal... the way things look i may have to roll out my own function and plaster every file with calls to such function...

[osamaaj03]

I came across some of the related issues before, but I didn't experience the problem at the time since the AUR lagged behind on updates (maybe that’s why, come to think of it). I'm glad to hear it's already being worked on and there's a solution in the works. I guess I’ll close this issue now—sorry for the mix-up! Let me know if you need any more images to test; I’ve got plenty!

[eylles]

it would help to know how does the current master branch work for you tho, i hope to have a fix or at least make all the images from every related issue work and then cut a release

[DiggityWerns]

Hi all. I also have this issue and have found the root cause on my system.

Here's a summary:

1. Some versions of ImageMagick print a deprecation warning to stderr when "magick convert" is run and "magick" is expected [e.g. version 7.1.2-13]
2. Wal internally redirects stderr to stdout when magick is run [wal.py : line 29]
3. Line 62 checks if len(raw_colors) > 16
   a) Line count = number of colors + 1(header) + 2 (stderr lines)
   b) If 14 or 15 colors are produced, line count is > 16
4. When hex colors are parsed in line 85, the 14 or 15 present colors are found and returned, resulting in an error when colors[15] is accessed.

Relevant magick outputs:

$ magick convert ~/.local/wallpaper.png[0] -resize 25% -colors 16 -unique-colors txt:-
WARNING: The convert command is deprecated in IMv7, use "magick" instead of "convert" or "magick convert"

# ImageMagick pixel enumeration: 15,1,0,255,srgb
0,0: (30,38,42)  #1E262A  srgb(11.9441%,14.8085%,16.3991%)
1,0: (44,49,53)  #2C3135  srgb(17.3013%,19.3921%,20.9148%)
2,0: (76,54,58)  #4C363A  srgb(29.9571%,20.9858%,22.6129%)
3,0: (51,60,68)  #333C44  srgb(20.1899%,23.532%,26.5185%)
4,0: (57,72,79)  #39484F  srgb(22.4967%,28.1953%,30.8257%)
5,0: (60,92,102)  #3C5C66  srgb(23.4533%,36.0717%,39.9218%)
6,0: (68,83,89)  #445359  srgb(26.7362%,32.5821%,35.0051%)
7,0: (79,99,105)  #4F6369  srgb(31.16%,38.8968%,41.2488%)
8,0: (83,107,113)  #536B71  srgb(32.4733%,41.8976%,44.3928%)
9,0: (168,111,104)  #A86F68  srgb(66.0404%,43.5209%,40.9159%)
10,0: (95,125,131)  #5F7D83  srgb(37.1863%,48.8569%,51.2993%)
11,0: (107,139,144)  #6B8B90  srgb(42.1353%,54.4732%,56.3516%)
12,0: (114,149,154)  #72959A  srgb(44.6273%,58.5585%,60.5447%)
13,0: (145,175,177)  #91AFB1  srgb(56.8032%,68.5522%,69.5264%)
14,0: (189,202,202)  #BDCACA  srgb(74.1939%,79.2534%,79.1462%)

Possible solutions:

1. Discard stderr (unless there is a reason to keep it?). The stderr lines won't mess with the line-counting. I've implemented this quick fix and all images that previously failed now work for me.
2. More robust: parse hex colors before length check, and check if len(colors) >= 16. The current check tests ">16" because of the header line, which is hacky to begin with.
3. Swap the order of trying magick convert and magick; the deprecation warning won't be present (see below). This may require other refactoring, though.

$ magick ~/.local/wallpaper.png[0] -resize 25% -colors 16 -unique-colors txt:-
# ImageMagick pixel enumeration: 15,1,0,255,srgb
0,0: (30,38,42)  #1E262A  srgb(11.9441%,14.8085%,16.3991%)
1,0: (44,49,53)  #2C3135  srgb(17.3013%,19.3921%,20.9148%)
2,0: (76,54,58)  #4C363A  srgb(29.9571%,20.9858%,22.6129%)
3,0: (51,60,68)  #333C44  srgb(20.1899%,23.532%,26.5185%)
4,0: (57,72,79)  #39484F  srgb(22.4967%,28.1953%,30.8257%)
5,0: (60,92,102)  #3C5C66  srgb(23.4533%,36.0717%,39.9218%)
6,0: (68,83,89)  #445359  srgb(26.7362%,32.5821%,35.0051%)
7,0: (79,99,105)  #4F6369  srgb(31.16%,38.8968%,41.2488%)
8,0: (83,107,113)  #536B71  srgb(32.4733%,41.8976%,44.3928%)
9,0: (168,111,104)  #A86F68  srgb(66.0404%,43.5209%,40.9159%)
10,0: (95,125,131)  #5F7D83  srgb(37.1863%,48.8569%,51.2993%)
11,0: (107,139,144)  #6B8B90  srgb(42.1353%,54.4732%,56.3516%)
12,0: (114,149,154)  #72959A  srgb(44.6273%,58.5585%,60.5447%)
13,0: (145,175,177)  #91AFB1  srgb(56.8032%,68.5522%,69.5264%)
14,0: (189,202,202)  #BDCACA  srgb(74.1939%,79.2534%,79.1462%)

Cheers!

[eylles]

@DiggityWerns thanks for the insight, just out of curiosity the lines you are refferencing are for the last release version wal.py@3.8.13 or for the last commit that modified the file wal.py@ae5662f ?

i ask now as i plan to work on that tomorrow so i can work off a specific diff

[DiggityWerns]

@eylles , I was looking at the last commit, wal.py@ae5662f

EDIT: Line numbers are from that commit, but I was working locally from last release. Given that, it looks like you already did 3 above, but I don't think that fixes the issue because all commands are tried regardless if one succeeds.

Is there a reason why we wouldn't want to return hex_colors before line 98 (HEAD commit above) after the first attempt that succeeds?

[eylles]

@DiggityWerns well that ought to be a question for @NecRaul as honestly i didn't fully review the PR #207 before merging as after reading the comment i went with "will merge and fix it later down the line before a release" cuz don't let perfect be the enemy of good and all that, still there is more stuff to do before a release so for the time being PR #214 is up i will be testing all the previous static images and gifs that failed to see if any other change is needed before merging and considering this as fixed for good.

[NecRaul]

@DiggityWerns

1. Discard stderr (unless there is a reason to keep it?). The stderr lines won't mess with the line-counting. I've implemented this quick fix and all images that previously failed now work for me.

There are essentially two ways to do this:

1. Throw out stderr.

diff --git i/pywal/backends/wal.py w/pywal/backends/wal.py
index f958e90..ef79631 100644
--- i/pywal/backends/wal.py
+++ w/pywal/backends/wal.py
@@ -26,7 +26,7 @@ def imagemagick(color_count, img, magick_command):
 
     try:
         output = subprocess.check_output(
-            [*magick_command.split(), img, *flags], stderr=subprocess.STDOUT
+            [*magick_command.split(), img, *flags], stderr=subprocess.DEVNULL
         ).splitlines()
     except subprocess.CalledProcessError as Err:
         logging.error("Imagemagick error: %s", Err)

2. Handle the non-hex lines in try_gen_in_range before returning them to gen_colors.

Second one is the better approach in my opinion. Instead of parsing the output of raw_colors in gen_colors it could be done within try_gen_in_range with the same (or a more robust) regex search.

2. More robust: parse hex colors before length check, and check if len(colors) >= 16. The current check tests ">16" because of the header line, which is hacky to begin with.

I completely agree with this. I tried to make my previous PR #207 very minimal, but as I mentioned in the message, that was a partial fix. I don't know if I could even set gifs as my wallpaper while some of the problematic images in prior issues were gifs, so I didn't even work to remedy that.

3. Swap the order of trying magick convert and magick; the deprecation warning won't be present (see below). This may require other refactoring, though.

This is already the case. magick is run before magick convert.

pywal16/pywal/backends/wal.py

Lines 40 to 45 in ae5662f

	def has_im():
	"""Check to see if the user has im installed."""
	magick_commands = []
	if shutil.which("magick"):
	magick_commands.extend(["magick", "magick convert"])

[...] but I don't think that fixes the issue because all commands are tried regardless if one succeeds.

Is there a reason why we wouldn't want to return hex_colors before line 98 (HEAD commit above) after the first attempt that succeeds?

That is entirely my blunder. I don't know what to say other than it simply escaped my attention.

---

On another matter, I tried all images in the issue and they worked fine without any changes to the code. I believe as @osamaaj03 mentioned, this was due to AUR package lagging behind.

2026-01-30.11-56-02.mp4

---

@eylles I have written a patch on top of your #214 branch. #215

[eylles]

that was fast

[NecRaul]

I woke up with a notification from Github and had nothing else to do, so I thought I should fix my own mistake.

I hadn't noticed the wal backend not returning when it should because I have a wrapper script (along with a postrun script) for setting wallpapers and I had just assumed some other change made it slightly slower.

[eylles]

it all should hopefully be fixed now, will try to have a release out in a while.