Fix loading XPM images with transparency

[nyxst4ck]

Any XPM that declares a transparent colour via a c None entry — the standard way GIMP and ImageMagick store transparency — fails to load since 11.3.0:

ValueError: tuple.index(x): x not in tuple

Root cause

#8967's palette refactor (7b459a8) replaced the fixed 256-entry black-filled palette list with a dict of only the declared colours, but the c None branch stores the character key in info["transparency"] without adding a palette entry. Decoding then calls palette_keys.index(key) for the transparent character and raises. The >256-colour RGB path (added in 395bd6b) hits the same missing entry.

Before 11.3.0 this worked, if partly by accident: the transparent character's ordinal was a valid index into the black-filled palette, so the image loaded and info["transparency"] was a usable integer index. Verified: 11.2.1 loads (transparency=32), 11.3.0 / 12.2.0 / current main all raise.

Fix

Give the transparent colour a real palette entry of black — matching pre-11.3.0 rendering — and store a usable value in info["transparency"]: the palette index in P mode, the colour tuple in RGB mode.

One design point I'd like your view on: for the RGB path, info["transparency"] = (0, 0, 0) follows the usual colour-key convention but would also key out genuine black pixels in a >256-colour transparent XPM. If you'd rather only fix the crash there and leave transparency unreported in RGB mode, I'm happy to drop that line and the corresponding assertion.

Tests

Two tests added to Tests/test_file_xpm.py, building XPM data in memory with BytesIO (same style as test_truncated_header) — no new binary fixtures:

• test_transparency: P mode; asserts the palette index in info["transparency"], and that convert("RGBA") yields (0, 0, 0, 0) for the transparent pixel and the correct opaque colours. Transparency also survives a PNG save/reload round-trip.
• test_transparency_rgb: 301 colours → RGB mode; asserts mode, transparency tuple and pixel values.

Red on main (both fail with the error above), green with the fix (10 passed). ruff and black clean on both files; mypy src/PIL/XpmImagePlugin.py clean.

[radarhere]

#8967 wasn't merged. I believe you meant #8874.

for the RGB path, info["transparency"] = (0, 0, 0) follows the usual colour-key convention but would also key out genuine black pixels in a >256-colour transparent XPM

If the palette in a P mode image can't accommodate a new entry purely for transparency, then I'd be inclined to load the image as PA.

Just my personal feeling, I don't love RGB images with transparency. For some reason it seems unintuitive to me. I'd rather load an RGB image with transparency as an RGBA image.

Any XPM that declares a transparent colour via a c None entry

For reference, this is mentioned in the specification.

None can be given as a colorname to mean “transparent”

[nyxst4ck]

Thanks — you're right, #8874 is the palette refactor I meant, apologies for the bad reference.

Reworked the >256-colour path per your preference: a transparent XPM now opens as RGBA (opaque entries get alpha 255, the None colour becomes (0, 0, 0, 0)), and info["transparency"] is no longer set there. The decoder's RGB branch now just sizes by band count so it serves both modes.

P mode is unchanged: the None colour is one of the ≤256 declared entries, so the palette always accommodates it and the palette-index colour key applies. test_transparency_rgb became test_transparency_rgba accordingly — 10/10 XPM tests green, ruff/black/mypy clean.