Repository navigation
fix: flatten transparent pictures onto white before enrichment models - #4776
dolfim-ibm merged 4 commits into
Conversation
|
✅ DCO Check Passed Thanks @bunnysayzz, all your commits are properly signed off. 🎉 |
Merge Protections🟢 Merge protection satisfied — ready to merge. Show 1 satisfied protection🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
|
AI triage (advisory)Checked commit The PR moves the transparency-flattening helper CI safety: needs maintainer care before you approve CI.
1 related pull request(s) in the same code
The |
There was a problem hiding this comment.
AI first review (advisory): blocker found
This review covers the full diff at f25a0fce41. It read the code and did not run it.
The main risk is the module-boundary CI check, not the pixel logic. The three changed modules now import docling.backend from model code, and tach.toml does not declare that dependency for these modules. The human reviewer must confirm that tach check passes, or decide where the shared RGB helper belongs.
A maintainer makes the merge decision. This review never approves the pull request.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
AI first review (advisory): no blocker found
This review covers the changes since f25a0fce41 at 8b7ca5cdfd. It read the code and did not run it.
The incremental commit fixes the earlier Tach blocker. It moves _to_rgb into docling.models.utils, a foundation-layer module that the three affected modules already list in tach.toml. The main remaining risk is that no test checks the white flattening. Confirm that CI tach check passes on the new head. Also decide whether to keep two copies of _to_rgb.
Earlier findings
- fixed (blocker): New
docling.backendimports are not declared intach.toml, so the Tach check can fail - open (suggestion): No regression test checks the white flattening
A maintainer makes the merge decision. This review never approves the pull request.
chrikrah
left a comment
There was a problem hiding this comment.
@bunnysayzz I ran the #4774 repro and tach check on 8b7ca5c. The three sites now get white and tach is clean, so I'd merge this as it stands.
$ python docling_alpha_repro.py # the script from #4774, Python 3.12.6, Pillow 12.3.0, docling-core 2.101.1
picture description input (picture_description_base_model.py:106): (0, 0, 0) # base 930bf20
picture classifier input (document_picture_classifier.py:167): (0, 0, 0)
chart extraction via engine (vlm/_utils.py:131): (0, 0, 0)
picture description input (picture_description_base_model.py:106): (255, 255, 255) # head 8b7ca5c
picture classifier input (document_picture_classifier.py:167): (255, 255, 255)
chart extraction via engine (vlm/_utils.py:131): (255, 255, 255)
$ uvx [email protected] check
✅ All modules validated! # base 930bf20, head 8b7ca5c, and the one-copy variant below
non-blocking: _to_rgb now lives in two places, image_backend.py:72 and docling/models/utils/__init__.py. I tried image_backend.py importing the models.utils copy with its own deleted, and also dropped the tach.toml line this commit adds. tach passes with no new depends_on entry anywhere, and the repro still gives white at all three sites.
I'd fold that in here, since the next fix to the alpha rules would otherwise reach only one copy. @dolfim-ibm, fine by me as a follow-up too.
|
Please rebase on Three changes for the update:
|
Three picture-enrichment paths flattened RGBA with a plain
convert("RGB"), which keeps the black stored under the alpha channel,
so fully transparent pictures reached the models as solid black.
Route all three through the existing _to_rgb() helper from
docling/backend/image_backend.py (introduced for page images in docling-project#4511),
which composites transparency onto white.
Fixes docling-project#4774.
Signed-off-by: bunnysayzz <[email protected]>
Signed-off-by: bunnysayzz <[email protected]>
Signed-off-by: bunnysayzz <[email protected]>
Move the transparency-flattening helper to docling.utils.image_utils, a new foundation module, and import it from the image backend and the three enrichment call sites. This removes the duplicate copy in docling.models.utils and replaces the palette tRNS special case from docling-project#4392, which to_rgb also covers. Add pixel-level tests: a fully transparent RGBA or palette+tRNS picture must reach the picture description model, the picture classifier engine, and normalize_image_to_pil as (255, 255, 255). Signed-off-by: Michele Dolfi <[email protected]>
8b7ca5c to
2fe76af
Compare
Picture enrichment models received transparent pictures as solid black. Three paths flattened RGBA with a plain
convert("RGB"), which drops the alpha channel and keeps the black stored under it. This routes all three through the existing_to_rgb()helper indocling/backend/image_backend.py(added for page images in #4511), which composites transparency onto white.Issue resolved by this Pull Request:
Resolves #4774
Checklist:
Review evidence:
Before: a fully transparent RGBA pixel (0,0,0,0) reached the models as (0,0,0). After: it arrives as (255,255,255). Opaque RGBA, plain RGB, and L inputs pass through unchanged. Verified with a standalone pixel-level check against
_to_rgb(Pillow): transparent, semi-transparent, opaque, RGB, and L cases all behave as stated.ruff checkandruff format --checkpass on all three touched files (ruff 0.15.12). Full test suite not run on this machine (no model deps); no reference test data changed.