<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Am 25.04.2014 07:15, schrieb Ethan
Hansen:<br>
</div>
<blockquote cite="mid:000801cf6045$887172e0$995458a0$@com"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<br>
<div dir="ltr" style="font-size: 16.4px; font-family: sans-serif;
left: 120.067px; top: 318.066px; transform: rotate(0deg)
scale(0.999931, 1); transform-origin: 0% 0% 0px;" data-angle="0"
data-font-name="Helvetica" data-canvas-width="146.98991658096313">6.2.3
Element size (Spec ICC.1:2001-04)<br>
<br>
</div>
<div dir="ltr" style="font-size: 16.4px; font-family: sans-serif;
left: 120.067px; top: 356.466px; transform: rotate(0deg)
scale(0.941302, 1); transform-origin: 0% 0% 0px;" data-angle="0"
data-font-name="Helvetica" data-canvas-width="769.0435421117784">The
number of bytes in the tag data element. The element size must be
for the actual data and must not</div>
<div dir="ltr" style="font-size: 16.4px; font-family: sans-serif;
left: 815.23px; top: 376.466px; transform: rotate(0deg)
scale(0.931702, 1); transform-origin: 0% 0% 0px;" data-angle="0"
data-font-name="Helvetica" data-canvas-width="83.8531980495453">include
any padding at the end of the tag data. An element may have any
size (up to the limit imposed by</div>
<div dir="ltr" style="font-size: 16.4px; font-family: sans-serif;
left: 120.067px; top: 396.466px; transform: rotate(0deg)
scale(0.927283, 1); transform-origin: 0% 0% 0px;" data-angle="0"
data-font-name="Helvetica" data-canvas-width="133.5287968940735">the
32-bit offsets)</div>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote cite="mid:000801cf6045$887172e0$995458a0$@com"
type="cite">
<blockquote type="cite">
<pre wrap="">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).</pre>
</blockquote>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:000801cf6045$887172e0$995458a0$@com"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
</blockquote>
<br>
That change is much appreciated for many legacy profiles, which are
still widely used and IMO perfectly useable.<br>
<br>
<blockquote cite="mid:000801cf6045$887172e0$995458a0$@com"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
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.<br>
<br>
kind regards,<br>
Kai-Uwe<br>
</body>
</html>