BUG: Decode low-bit DeviceRGB images as RGB instead of palette - #3929

The failing jobs look like the usual network flakes on the download-fixture tests (there's a ConnectionResetError fetching the sample PDFs) — my added test is offline and passes. Happy to rebase or re-run whenever CI settles. @stefan6419846 let me know if you'd like me to run the fix against your original file.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.87%. Comparing base (7d80373) to head (ac5072a).

@@           Coverage Diff           @@
##             main    #3929   +/-   ##
=======================================
  Coverage   97.87%   97.87%           
=======================================
  Files          57       57           
  Lines       10779    10782    +3     
  Branches     2019     2019           
=======================================
+ Hits        10550    10553    +3     
  Misses        127      127           
  Partials      102      102           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Good catch on both counts.

Took the int(mode[0]) suggestion — cleaner, and the only low-bit modes are
2bits/4bits so it can't surprise us.

On your case: you're right, and I can reproduce it. The expansion sits in
_handle_flate, which only runs for FlateDecode/RunLengthDecode, so an
unfiltered image falls through to the plain _image_from_bytes call at the
bottom and the raw "4bits" mode goes straight to Pillow. Same for the
LZW/ASCII85 fallback and the CMYK branch — four call sites in total that
never see the conversion.

Looks like the right place is _image_from_bytes itself, since every path
goes through it. Moving it there fixes the unfiltered case here and keeps
the flate path behaving the same.

Want me to do that in this PR, or keep this one to the flate fix for #3924
and handle the inline-image path separately? Happy either way — the second
one touches more paths so I didn't want to widen the scope without asking.

Want me to do that in this PR, or keep this one to the flate fix for #3924 and handle the inline-image path separately? Happy either way — the second one touches more paths so I didn't want to widen the scope without asking.

How would this affect the new parameters you introduced in the current PR? Would they still be relevant for a general fix, or would a general fix revert these?

They'd stay as-is — a general fix doesn't revert them.

The two params are doing the actual work: colors= makes bits2byte unpack
width * colors samples per row instead of assuming one component per pixel,
and scale= stretches each sample to 0-255 when it's read as colour rather
than a palette index. Any fix still needs both, wherever it's called from.

What moves is only the dispatch — the if mode in ("2bits", "4bits") block
that picks the bit depth and the resulting mode. Right now it sits in
_handle_flate, so only FlateDecode/RunLengthDecode ever reach it. Moving it
into _image_from_bytes means every path gets it, and bits2byte stays exactly
as it is in this PR.

I tried it locally: same 4-bit DeviceRGB image comes out as RGB
[(255,0,0), (255,0,0), (255,255,0), (255,255,0)] both with and without the
Flate filter, where the unfiltered one currently raises "unrecognized image
mode". colors is already computed in _xobj_to_image before all four
_image_from_bytes calls, so nothing new needs threading through.

So it's additive rather than a revert. Happy to fold it into this PR if
you'd like it all in one, or land this and do the move separately — your
call.

Rebased on main — the conflict was with the _handle_flate reorder in #3904.
Kept the new ordering and moved the low-bit branch into it; the /Indexed
unpacking has to stay above it since the branch reads color_space.

Happy to do the general _image_from_bytes fix as a separate PR once this
lands.