[usmanmateen]

Resolves #4665

_image_ref_from_odf_image passed pictures straight to ImageRef.from_pil, which can't write CMYK as PNG, so _add_odf_images dropped any CMYK picture in an ODT, ODP or ODS file with only a debug log. This normalizes the picture with normalize_image_for_png first, the same way the Word and PowerPoint backends do since #4598 (#4664 does the same for Excel).

Checklist:

• Documentation has been updated, if necessary. (not needed)
• Examples have been added, if necessary. (not needed)
• Tests have been added, if necessary.

Review evidence:

• The reproduction from OpenDocument backends drop CMYK pictures #4665 prints ConversionStatus.SUCCESS 0 on main and ConversionStatus.SUCCESS 1 with this change.
• test_cmyk_picture_is_kept builds an ODT, ODP and ODS file with one CMYK picture (in a paragraph, on a draw page and in a cell) and checks that the picture is kept at its size and colour. All 3 cases fail on main (0 pictures) and pass here. With an RGB picture, the same files keep it on main, so CMYK is the only cause.
• pytest tests/test_backend_opendocument.py tests/test_office_image_modes.py: 63 passed (60 on main plus the 3 new cases), with the same 3 warnings as main.
• make validate: all hooks pass.

Not changed: OdsDocumentBackend._find_images_in_sheet also calls ImageRef.from_pil without normalizing, but it reads the picture with img.get_data(), which odfdo's DrawImage doesn't have (odfdo 3.26.3), so that path can't add a picture today. That looks like a separate issue, so I left it out of this PR.

[github-actions]

✅ DCO Check Passed

Thanks @usmanmateen, all your commits are properly signed off. 🎉

[mergify]

Merge Protections

🟢 Merge protection satisfied — ready to merge.

Show 1 satisfied protection

🟢 Enforce conventional commit

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert)(?:\(.+\))?(!)?:

[github-actions]

AI triage (advisory)

Checked commit cad3d0c998. The analysis read the diff only. It did not run code from this pull request.

Normalize CMYK images with normalize_image_for_png in the OpenDocument backend to prevent dropped pictures.

Topic labels added: bug, odf.

CI safety: no concern found. A maintainer must still approve CI.

2 related pull request(s) in the same code

PR	State	Signal	Assessment
#4664	open	referenced as #4664	related: PR 4664 normalizes CMYK images in the XLSX backend, while this PR normalizes CMYK images in the OpenDocument backend.
#4598	merged	referenced as #4598	related: PR 4598 added ICC-aware CMYK normalization for DOCX and PPTX, while this PR applies that normalization to ODF documents.

_{The ai:* labels are advisory. They do not approve CI and they do not add tests:full. A new push runs this check again.}

[github-actions]

AI first review (advisory): no blocking issue found

This review covers the full diff at cad3d0c998. It read the code only. It did not run tests or code from this pull request.

The PR fixes CMYK image loss in ODF (ODT, ODP, ODS) conversion. _image_ref_from_odf_image passed the raw PIL image to ImageRef.from_pil, which cannot write CMYK as PNG and therefore raised an exception that _add_odf_images silently swallowed. The fix normalizes the image with the same normalize_image_for_png helper used by the Word and PowerPoint backends. Three parametrized tests verify the fix for all three ODF types. The only remaining risk is the untouched _find_images_in_sheet path in OdsDocumentBackend, which has the same ImageRef.from_pil call without normalization, but the PR body explains why that path is currently unreachable.

Findings outside the diff lines

• minor docling/backend/opendocument_backend.py:2317: _find_images_in_sheet still calls ImageRef.from_pil without normalization
  _find_images_in_sheet (line 2317) has the exact same missing normalization as the one fixed in _image_ref_from_odf_image. The PR body explains that img.get_data() does not currently return data for odfdo 3.26.3 DrawImage objects, so the bug cannot trigger today. However, if odfdo ever adds that method, or if a different image object type reaches this path, CMYK images will silently fail again with no indication that the root cause is the same as #4665.

  Consider adding normalize_image_for_png(pil_image) here as a defensive fix alongside this PR, or file a follow-up issue so the gap is tracked.

_{A maintainer makes the merge decision. This review never approves the pull request.}

[usmanmateen]

On the review's _find_images_in_sheet note: I left it out on purpose. odfdo's DrawImage has no get_data(), so that path raises before it reaches ImageRef.from_pil, and I couldn't write a test that exercises a normalization there. Whether sheet-level pictures get lost because of get_data() is worth checking on its own, so I'll look into it separately instead of widening this PR.

cc @PeterStaar-IBM since you added the OpenDocument backend in #3480 and reviewed #4598. Happy to adjust anything.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[PeterStaar-IBM]

lgtm!

[usmanmateen]

Follow-up on the _find_images_in_sheet note: it turned out to drop every picture anchored to a sheet, not only CMYK ones. Filed as #4677, with a fix in #4678.