iccPawgReport applies ICC.1 assumptions to iccMAX profiles: 7 of 32 checks affected (C5 is one symptom)

[colourbill-ctrl]

Not proposed for immediate action. Filing this as a datapoint, not as a work item. C5 is
one symptom of something broader, and the measurements below say it is very likely the tip of
the iceberg for iccMAX support in iccPawgReport. The right response is to gather a few more
of these and then plan iccMAX PAWG coverage at a level above individual defects — not to
knock off missing tags piecemeal. I would rather this sat open as evidence than got a
one-line PR.

The "tip of the iceberg" is measured, not assumed — see Evidence that C5 is not the only
check below. C5 is not even the worst affected: of 32 checks, seven show a large v5-vs-v2/v4
gap, and four of them are worse than C5.

Follow-up to #2001, which fixed one instance of this.

Summary

iccPawgReport check C5 ("Is the profile free of additional tags not required for profile
class, other than allowed optional tags") has no version dimension. Its class rule tables in
Tools/CmdLine/IccPawgReport/PawgReport.cpp are ICC.1 (v2/v4) shaped, so every iccMAX-only
tag falls through to a warning. #2001 added cicpTag, but cicp was a genuine single
omission of an ICC.1 v4.4 tag; the remaining offenders are all iccMAX tags, and adding them one
by one to kCommonOptional would be the wrong fix.

Measured on master with the #2001 fix already applied.

Evidence that C5 is not the only check

Every tracked .icc (git ls-files '*.icc') run through iccPawgReport, every check verdict
recorded, then split by profile version. "bad" = WARN or FAIL. Only checks with a >5 point gap
shown; v5 sample n=89 profiles, v2/v4 sample n=13.

check	title	v5 bad	v2/v4 bad	gap
S4	Does illuminant correspond to D50?	97% (86/89)	0% (0/13)	+97
C1	Are tag types correctly encoded?	92% (82/89)	0% (0/13)	+92
C5	Free of additional tags not required for class?	93% (83/89)	8% (1/13)	+86
C10	Does header content conform with the specification?	99% (88/89)	15% (2/13)	+83
C3	Do tags only use tag types allowed for the tag?	94% (84/89)	23% (3/13)	+71
C4	Are all required tags for profile class present?	100% (89/89)	38% (5/13)	+62
S3	Do Platform/Creator/Manufacturer/CMM correspond to registered signatures?	94% (84/89)	46% (6/13)	+48
Q3	(small sample)	33% (2/6)	9% (1/11)	+24

Representative details, all from iccMAX profiles:

• S4 → PCS illuminant is not D50. For iccMAX a non-D50 PCS illuminant is the point of
  Profile Connection Conditions and spectral viewing conditions, so this reads as an ICC.1
  assumption applied to a spec that deliberately relaxed it.
• C10 → warnings: PCS illuminant is not D50 — the same assumption surfacing again.
• C4 → missing A2B0 or matrix/TRC transform, chad when PCS illuminant is not D50 — ICC.1
  class rules applied to profiles that legitimately use MPE / D2B transforms.
• C1 / C3 → both surface the same library Validate() opinion:
  'svcn': spectralViewingConditionsTag::>illuminantXYZ - XYZNumber appears to be normalized!
  That one may be a genuine question about the library's iccMAX validation rather than about
  PawgReport's tables — which is itself an argument for looking at this whole area coherently.

So the same shape recurs across at least four independent checks: ICC.1 assumptions applied
to iccMAX profiles. Fixing C5's tag list alone would move one number in this table.

C5 specifically — 85 of 105 tracked profiles

	count
profiles C5 actually assesses	105
C5 = WARN	85 (81%)

C5 verdict	version	count
WARN	v5	83
WARN	v4	1
WARN	v0 (malformed fuzz PoC)	1
OK	v5	3
OK	v2	5
OK	v4	3

The three clean v5 profiles are simply the ones carrying none of the tags below.

The tags, and how often each is named

sig	tag	profiles
svcn	spectralViewingConditionsTag	81
s2cp	standardToCustomPccTag	81
c2sp	customToStandardPccTag	80
rfnm	referenceNameTag	3
cept	colorEncodingParamsTag	3
csnm	colorSpaceNameTag	2
gbd1	gamutBoundaryDescription1Tag	1
ICC5	embeddedV5ProfileTag	1

c2sp/s2cp/svcn are the Profile Connection Conditions trio — CIccProfile::ReadPccTags()
groups exactly those three, and iccDumpProfile prints them under its
"Version 5 / iccMAX Profile Summary" heading, along with gbd0/gbd1.

Mechanism — the same one as #2001

Not visible from the tables, so worth restating. IsSpecTag() (PawgReport.cpp:322) asks
CIccInfo::GetTagSigName, which resolves these signatures to real names through
CIccTagCreator (IccProfLib/IccTagFactory.cpp). The name does not begin with "Unknown", so
none of them is ever classified as a private tag — they fall straight through
IsAllowedForClass() to the C5 warning.

Why a piecemeal fix is the wrong move here

Every rule table in the file is ICC.1-era, and the newest entries anywhere in them are the v4
D2B0-2 / B2D0-2 set:

kCommonRequired, kMatrixTrcAlternative, kOutputRequired, kA2B0B2A0Required,
kLinkRequired, kA2B0Required, kNamedColorRequired, kCommonOptional

The rest of PawgReport.cpp does know about versions — it validates v2/v4/v5 major numbers
(~:1500) and has an explicit (raw.version >> 24) < 5 → "not an iccMAX profile" branch
(~:1004) — but none of that reaches the C5 class rules. Dropping iccMAX tags into the
common optional list would also assert they are acceptable in a v2 or v4 profile, which is a
different claim from the one C5 should be making.

One case that rules out a naive "v5 tags go in a v5 table" split

.github/ci/test-data/v5dspobs-lcddisplay.icc is a v4 profile carrying ICC5
(embeddedV5ProfileTag) — a v4 profile legitimately embedding a v5 profile. So the rule cannot
simply be keyed on the container's version: at least one v5-related tag is valid in a v4
profile. Whatever shape a fix eventually takes has to accommodate that.

(The other non-v5 warner, .github/ci/regression/poc-763-cenc-huaf.icc, is a malformed fuzz
PoC reporting version 0 and carrying rfnm/csnm/cept; listed only for completeness.)

What I am not proposing

I am deliberately not proposing an implementation. Given the table at the top, picking a shape
for C5 alone would prejudge the larger question of how PAWG assessment should treat iccMAX —
whether the class rule tables gain a version dimension, whether some checks should report
"not applicable" for v5 rather than WARN, and whether the svcn illuminant question belongs in
IccProfLib rather than here. That is worth a plan, not a patch.

Happy to keep gathering datapoints in this shape if that is useful.

Note on regression coverage, when the time comes

Any eventual fix wants the corpus sweep above as its test — assert C5 (and the other six) across
the tracked iccMAX profiles, rather than on a single fixture. The current
iccdev.pawg-c5-cicp-optional test from #2001 covers only the cicp case.

[github-actions]

Thanks for opening this issue.

The triage bot added initial labels based on the template and issue text. Maintainers may adjust labels as they review scope, reproduction details, CTest/regression needs, and security impact.

If you have questions, contact a listed Maintainer.

[xsscx]

@colourbill-ctrl Excellent write-up. Adding some context and history.

1. Starting Point - Modify: iccDumpProfile V5 Reporting #679 added V5 Support to iccDumpProfile on 08-April-2026
2. At that point in time (08-April-2026) PawgReport Code was Frozen and no further coverage was contemplated or proposed as there were significant Library findings to be addressed as a result of the PawgReport Development
3. ICC Library Code was not stable, the results nor outputs were not accurate or precise
4. ICC Tool argv, content & documentation incorrect, not aligning with Specifications
5. Agreed that PawgReport Code needs to be updated for the Q2-Q3/2026 Library Updates & Corrections, the Development identified many bugs as can be see with the Version 2.3.1.8 Release on 22-April-2026 many directly linked to PawgReport Development
6. PawgReport Code is largely based on DumpProfile, RoundTrip & ColorBleed Tooling as of 03 March 2026
7. PawgReport Commit & Merge 08-MAY-2026 in Add: iccPawgReport #1022 more than 5+ weeks had elapsed and hundreds of new defects had been identified, saturating Maintainer Resources, leaving a large gap to fix as you have correctly enumerated
8. Because the Library Bugs were significant the --read alternative was implemented by Interposing the ColorBleed Sandbox
9. LibIccTest f/k/a iccAnalyzer-Lite was the Interposing Bridge allowing for PawgReport Development Rev.A
10. 17-April-2026 started with the Gamma iccToJson: Are the gamma values of TRCTags correct? #815 - Answer - No, they were not as identified by the PawgReport Development
11. Issue Bisect: 1f0a9dd curveType #816 on 18-April-2026 indicated Bisect for Tone Response Curves marking the beginning of Quality Assurance Testing and reducing resources allocated to Fuzzing, PawgReport Development had already indicated significant need for manual Code Review and Specification Alignment
12. Issue Cannot read .icc file #987 on 05-May-2026 was the Canary for Read Issues for ICC Profiles, confirming the PawgReport Development --read Interposing Code was Correct; This datapoint further confirmed the ICC Library Code needed significant, structural revisions & calculation verification performed
13. Frozen into PawgReport Code were all bugs & assumptions from the Initial Commit & lack of Specification alignment for the points you detailed correctly above, which are significant and point to a larger set of Issues
14. Excellent write up on potential Paths forward, I have a number of items to add to the Library-focus fixes
15. Providing safe Library Code needs to be the focus, not just grooming the Tools
16. Too many library bugs prevented further development for PawgReport at the close of Q1/26
17. Q2&3/2026 spent aligning the CopyPasta Spaghetti in Library & Tooling Code which continues unabated
18. Your Report is timely, Thank You

I do have more commentary to share out-of-band on the Library Code and the timeline since initial Commit