One-level RGB differences in AGG embedder expectations on macOS 26.6.2 arm64
21 views
Skip to first unread message
Sean Wang
Sep 12, 2026, 1:17:40 PMSep 12
to pdfium
We are investigating strict image-expectation failures with pinned PDFium commit d13ede8e6034ed7a65c4cbd0ab7b76211a63a600 in a macOS 26.6.2 (25G83) arm64 virtual machine, using the AGG renderer. We have not changed the checked-in expectations or comparison tolerances. We are not claiming this is a confirmed upstream rendering defect.
Two preserved complete embedder runs each executed 865 tests with 64 failing testcases and 268 failed image assertions. A later read-only analysis of the actual/expected PNGs embedded in both reports found:
- 40 distinct actual/expected PNG byte-hash pairs across both reports;
- matching per-assertion rows, including PNG hashes, between the reports;
- maximum absolute RGB channel delta of 1 for every failed image assertion;
- no alpha-channel differences;
- exact differing-pixel counts between 1 and 71 per assertion.
These measurements describe the retained failures, not passing tests. They do not establish that all mismatches share the same cause. The independent PNG analysis is a diagnostic helper, not a replacement for PDFium's test oracle.
For a focused reproduction, the existing upstream test is:
out/probe/pdfium_embeddertests --gtest_filter=CPDFSecurityHandlerEmbedderTest.PasswordAfterGenerateSave
Run from the checkout root after building that target with the pinned local configuration. out/probe is just the output-directory name, not an upstream requirement. Full GN/toolchain details would need to be supplied separately if requested; this is not yet a standalone hermetic reproduction package.
This testcase was repeatedly observed to execute once, fail three image assertions, and exit 1. In the inspected 612×792 image pair, the expected RGBA pixels exactly matched encrypted_agg_mac.png. Six pixels differed, with actual R/G/B each one level greater than expected and unchanged alpha:
(25,43), (57,783), (93,783), (209,784), (11,786), (171,786) (top-left origin).
The pinned upstream exact PNG comparator also reported six differing pixels.
We found commits 5ac3decf717d0ede9e8e7572d49db435a26c353d and b36037aa16b525827df524e2cbda80ec00a9b4fd discussing opt-in fuzzy comparisons for small macOS differences. Our pinned revision already has comparison options, but the focused testcase uses the default exact comparison.
Could you advise whether this pattern is consistent with a known macOS rasterization/platform expectation issue, and which controlled checks would best distinguish that from a rendering regression? In particular, is there an existing issue or supported OS/toolchain reference configuration we should compare against before considering any expectation or tolerance change?
No PDFs, logs, PNG attachments, private material, or source archives are included in this initial inquiry. The named test and fixture are already part of the upstream repository.
We tried the issue-reporting link in the PDFium README, but the Chromium > PDFium component displayed “You do not have permission to create issues in this component.” Please also advise on the appropriate reporting route.
Two preserved complete embedder runs each executed 865 tests with 64 failing testcases and 268 failed image assertions. A later read-only analysis of the actual/expected PNGs embedded in both reports found:
- 40 distinct actual/expected PNG byte-hash pairs across both reports;
- matching per-assertion rows, including PNG hashes, between the reports;
- maximum absolute RGB channel delta of 1 for every failed image assertion;
- no alpha-channel differences;
- exact differing-pixel counts between 1 and 71 per assertion.
These measurements describe the retained failures, not passing tests. They do not establish that all mismatches share the same cause. The independent PNG analysis is a diagnostic helper, not a replacement for PDFium's test oracle.
For a focused reproduction, the existing upstream test is:
out/probe/pdfium_embeddertests --gtest_filter=CPDFSecurityHandlerEmbedderTest.PasswordAfterGenerateSave
Run from the checkout root after building that target with the pinned local configuration. out/probe is just the output-directory name, not an upstream requirement. Full GN/toolchain details would need to be supplied separately if requested; this is not yet a standalone hermetic reproduction package.
This testcase was repeatedly observed to execute once, fail three image assertions, and exit 1. In the inspected 612×792 image pair, the expected RGBA pixels exactly matched encrypted_agg_mac.png. Six pixels differed, with actual R/G/B each one level greater than expected and unchanged alpha:
(25,43), (57,783), (93,783), (209,784), (11,786), (171,786) (top-left origin).
The pinned upstream exact PNG comparator also reported six differing pixels.
We found commits 5ac3decf717d0ede9e8e7572d49db435a26c353d and b36037aa16b525827df524e2cbda80ec00a9b4fd discussing opt-in fuzzy comparisons for small macOS differences. Our pinned revision already has comparison options, but the focused testcase uses the default exact comparison.
Could you advise whether this pattern is consistent with a known macOS rasterization/platform expectation issue, and which controlled checks would best distinguish that from a rendering regression? In particular, is there an existing issue or supported OS/toolchain reference configuration we should compare against before considering any expectation or tolerance change?
No PDFs, logs, PNG attachments, private material, or source archives are included in this initial inquiry. The named test and fixture are already part of the upstream repository.
We tried the issue-reporting link in the PDFium README, but the Chromium > PDFium component displayed “You do not have permission to create issues in this component.” Please also advise on the appropriate reporting route.
geisserml
Sep 13, 2026, 6:31:20 AM (14 days ago) Sep 13
to pdfium
> We tried the issue-reporting link in the PDFium README, but the Chromium > PDFium component displayed “You do not have permission to create issues in this component.” Please also advise on the appropriate reporting route.
The bug tracker is at https://bugs.chromium.org/p/pdfium/issues/list (works fine at my end).Reply all
Reply to author
Forward
0 new messages