BUG: Keep the Adobe CMYK inversion when an explicit /Decode is present - #3943

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.89%. Comparing base (aa2f37d) to head (e4ec79e).
⚠️ Report is 7 commits behind head on main.

@@           Coverage Diff           @@
##             main    #3943   +/-   ##
=======================================
  Coverage   97.88%   97.89%           
=======================================
  Files          57       57           
  Lines       10829    10871   +42     
  Branches     2028     2033    +5     
=======================================
+ Hits        10600    10642   +42     
  Misses        127      127           
  Partials      102      102           

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

Thanks — all five addressed.

On the even-length guard: you're right that it made no sense. An odd /Decode
array is already caught further down and dropped with a warning, so guarding
here only meant the inversion was skipped silently while the malformed array
still got reported. Removed, and the loop now stops at len(decode) - 1 so it
cannot read past the end either way.

Reworded the comment — you're right that [1 0] implied two entries. It now
says the substitution explicitly: putting s -> 1-s into
dmin + s*(dmax-dmin) gives dmax + s*(dmin-dmax), which is the same pair
swapped, for any even length. Em dash replaced with a hyphen.

On invert_color deciding the order: I looked at this and I don't think it can
discriminate here. _get_image_mode returns mode == "CMYK" as invert_color,
so it is True for every DeviceCMYK image, and this branch already requires
img.mode == "CMYK". So inside it invert_color is always True and the order is
always the swapped one. That may be why your earlier commented-out attempt
had no clear condition — there isn't one at this point in the flow. If you
know of a CMYK DCT case where the values are not Adobe-inverted, that would
change it and I'd rather handle it explicitly than guess.

On the pixel assertion: good catch, the range check was weak. It now asserts
the exact raw CMYK samples, (121, 102, 114, 42) and (153, 137, 74, 82). I
used the raw values rather than an RGB conversion deliberately — they come
out of pypdf's own decode, so they don't move with Pillow's colour
management, whereas convert("RGB") does. Documented in the test.

Checked the test still bites: reverting the fix gives (134, 151, 142, 214)
for that pixel, roughly the complement.

Both addressed.

On the swap order — I traced every path in _get_image_mode. The final
return is mode == "CMYK", and the two early returns that can produce
CMYK (/Separation, /DeviceN with a CMYK base) both hardcode True.
/Indexed with a CMYK base returns "P", so the img.mode == "CMYK" guard
here excludes it. So there's no path that reaches this branch with
invert_color False, and keying the order off it would be dead code.
Happy to add it if you know of a case I've missed.

On the pixel values — agreed, they can move between libjpeg builds.
Now asserted with a tolerance of 8, which is well inside the ~170-210
shift the missing inversion causes. Confirmed it still fails without
the fix: got (134, 151, 142, 214) against an expected (121, 102, 114, 42).