Add tests for remap_palette()'s explicit source_palette argument

[pranjalm37]

Fixes #9865.

#9865 suggests that remap_palette()'s palette-mode detection is off by one and should use >= instead of >:

Pillow/src/PIL/Image.py

Lines 2234 to 2236 in c8c74c8

	elif len(source_palette) > 768:
	bands = 4
	palette_mode = "RGBA"

I looked into it, and the current > is correct — changing it to >= would be a regression. The issue asked for tests, so this PR adds them rather than changing the behaviour.

Why > is right

A full 256-entry palette is 768 bytes in RGB and 1024 bytes in RGBA, so the boundary sits at 768, not above it:

source_palette	length	> 768	correct?
256-entry RGB	768	RGB	✅
256-entry RGBA	1024	RGBA	✅

With >=, the first row flips to RGBA and a completely ordinary 256-colour RGB palette gets re-read 4 bytes at a time, shifting every colour. Verified against 12.3.0:

from PIL import Image
pal = bytearray()
for i in range(256):
    pal += bytes([i, (100 + i) % 256, (200 + i) % 256])   # 768 bytes, RGB

im = Image.new("P", (2, 2))
out = im.remap_palette(list(range(256)), bytes(pal))
print(out.palette.mode)   # '>' (current): RGB   -- correct
                          # '>=':          RGBA  -- wrong

There is a real ambiguity underneath the report — a 192-entry RGBA palette is also exactly 768 bytes, and is read as RGB. But that's inherent to inferring the mode from a bare bytes length, and no choice of comparison operator fixes it; distinguishing those two cases would need the caller to say which mode it means. That seems like a separate API question, so I've left it alone here.

Changes proposed in this pull request

• Add test_remap_palette_source_palette, parametrized over RGB/RGBA, covering remap_palette()'s source_palette argument. The existing test_remap_palette only exercises the source_palette=None path, so this branch had no coverage at all.
• Both sides of the 768-byte boundary are asserted, so the resulting test fails if the comparison is ever changed to >= (confirmed: the RGB case fails with that edit, and passes on main as-is).

Full Tests/test_image.py passes (185 passed, 1 skipped — IPython not installed locally). ruff check / ruff format --check clean; mypy reports no new errors (the 4 it emits are pre-existing missing-IPython-stub errors, identical on a clean tree).

---

🤖 Generated with Claude Code

[radarhere]

The issue asked for tests

I think the issue wanted us to write tests to check the poster's understanding. If their understanding was incorrect, which we've established it was, I don't think they necessarily felt a need to update our test suite.

Do you yourself feel this is a valuable addition?

so this branch had no coverage at all.

There is currently no direct test for source_palette. The code is being tested indirectly - other tests call Pillow functionality that use source_palette.

If you go to https://app.codecov.io/gh/python-pillow/Pillow/blob/main/src%2FPIL%2FImage.py#L2204, you will see that codecov identifies all code within this method as already covered.

[radarhere]

Could you explain this line? It seems like any palette would have sufficed.

[pranjalm37]

You're right on both counts, and I should have checked branch coverage instead of assuming from the absence of a direct test.

I ran the existing suite (without this PR) under coverage run --branch and inspected the annotated output for the elif len(source_palette) > 768: block directly — both bands = 4 and palette_mode = "RGBA" are marked executed. I traced it further: several existing GIF tests (test_dispose2_diff, test_dispose2_background_frame, test_transparency_in_second_frame, test_roundtrip_info_duration, test_empty_string_comment, and others) call im.save(..., save_all=True) on an RGBA-paletted image, which flows through GifImagePlugin._save_all → remap_palette(optimized_palette_colors, source_palette) with a 1024-byte source_palette — hitting the exact branch this issue is about. So "completely untested" was wrong; withdrawn.

Do you yourself feel this is a valuable addition?

Honestly: less than I claimed, now that I've seen it's indirectly covered. What it still adds is a direct, boundary-pinned test of the public remap_palette(dest_map, source_palette) argument itself — today the only coverage of this exact branch runs through GIF-saving internals, so a change to that internal plumbing (not to remap_palette) could silently drop coverage of this branch without any test failing. But that's a fairly marginal defense-in-depth argument, not a "this is currently broken" one, and I don't want to push a maintainer's time on something you don't see value in.

Your call — happy to close this if you'd rather not carry it, no hard feelings either way.