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

[Kai-Uwe Behrmann]

Am 25.04.2014 07:15, schrieb 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.

6.2.3 Element size (Spec ICC.1:2001-04)

The number of bytes in the tag data element. The element size must be
for the actual data and must not
include any padding at the end of the tag data. An element may have any
size (up to the limit imposed by
the 32-bit offsets)

6.5.4 dataType, 6.5.18 textType, 6.5.21 uInt16ArrayType and possibly
more the tag types can vary in size and are not required to end on
4-byte boundaries in Spec ICC.1:2001-04. For instance "ICC v2" is
completely valid content of seven bytes including the terminating zero,
for a textType tag with a resultig size of 15 and not 16 bytes, which
would be prohibited by the 6.2.3 and 6.5.18 sections.

So I read ICC v2 as having no 4-byte padding requirement to the above
mentioned tag end, which means in my reading, the profile can have any
size as well.

>> 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).

Well, we talk here about the end of the profile, which is not handled by
any offset. So the ICCv2 spec (ICC.1:2001-04) can be read about being
completely optional to do padding at the end of profiles. And that is
what some implementations did.

>> 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.
>>

That change is much appreciated for many legacy profiles, which are
still widely used and IMO perfectly useable.

> 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.

My understanding is, that ICC v4 is a major spec change, with a newly
introduced requirement for 4-byte padding at the end of tag and profile
sizes, which was absent in ICC v2.

kind regards,
Kai-Uwe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20140425/9bf2256f/attachment.html>