[Openicc] iccProfileDump: NonCompliant! - Bad Header File Size

[Ethan Hansen]

> From: Max Derhak
> Sent: Thursday, April 24, 2014 20:21
> Subject: Re: [Openicc] iccProfileDump: NonCompliant! - Bad Header File
> Size
> 
> My understanding of the padding requirement in ICC.1:1998 comes from the
> following section.
> 
> 6.2.4 Tag Data Requirements
> 
> All tag data is required to start on a 4-byte boundary (relative to the
> start of the profile header) so that a tag starting with a 32 bit value
> will be properly aligned without the tag handler needing to know the
> contents of the tag. This means that the least-significant two bits of
> the beginning offset must be zero. The element size must be for the
> actual data and must not include any padding at the end of the tag data.
> 
> This implies to me that tag data should always end on a 4-byte boundary
> (with padding).  However, I agree that this is indirect as it relates to
> file size (hence the specification revisions to clarify things).
> 
> I could make a change in the CheckFileSize() function to only check the
> alignment of the file size if the version is 4.2 or greater.
> 
> Max Derhak
> Principal Scientist
> max.derhak at onyxgfx.com 

The same requirements appear in later revisions of the V2 spec
(ICC.1:2001-04) and the initial V4.0.0 spec (ICC.1:2001-12) in section
6.2.2. The version 4.0.0 spec included in the preamble of Section 6 states:

There are additional requirements on the structure of the profile.
1) The first tagged element data must immediately follow the tag table.
2) All tagged element data, including the last, must be padded by no more
than three following pad bytes
to reach a 4-byte boundary.
3) All pad bytes must be NULL.

Later V4 specs moved this wording to Section 7. So it is safe to assume that
all version 4.x profiles must honor the 4-byte alignment. None of the V2
specs spelled out the alignment requirements as explicitly. As you noted
above, a rational reading of Section 6.2.2/6.2.4 implies that all tags must
end on a 4-byte boundary. Section 6.5 (V2 spec ICC.1:2001-04) notes:

An effort was made to make sure one-byte, two-byte and four-byte data lies
on
one-byte, two-byte and four-byte boundaries respectively. This required
occasionally including extra
spaces indicated with "reserved for padding" in some tag type definitions.
Value 0 is defined to be of
"unknown value" for all enumerated data structures.

Were I to guess, profiles such as the old sRGB one Kai-Uwe found are the
reason V4 specs made the 4-byte alignment explicit.

Cheers,
Ethan