Hi Keith,
thanks for looking into this.
I suspect that the problem is with the GRAY.pf profile
which came with openjdk. I believe Alexey who worked on
this stuff generated it himself and might have made
a mistake or the file got mangled later somehow
(may be during mercurial conversion or something).
According to this bug:
6523402: OSS CMM: Some quality problems with GRAY, PYCC and CIEXYZ color
spaces with lcms library
it should have worked with GRAY profile (albeit with some
quality issues).
Thanks,
Dmitri
Keith Seitz wrote:
Hi,
I've been working on fixing this bug, and while it is clear that LCMS
was never written to do this, it can be made to work. I've got a patch
that passes the JCK tests in this area.
While writing jtreg tests for this, though, I've stumbled across
something odd, and I was hoping that someone on this list with more
knowledge about ICC profiles would help me. The ICC specification
(ICC.1:2004-10) states:
"All tagged element data, including the last, shall be padded by no more
than three following pad bytes to reach a 4-byte boundary"
and
"This implies that the length must be a multiple of four"
However, if one looks at GRAY.pf supplied with OpenJDK, it is only 554
bytes long, which is NOT a multiple of four. Dumping the contents of the
file and parsing by hand, I see that the last tagged element data in
this file is (all other data is properly padded):
63 75 72 76 00 00 00 00 00 00 00 01 01 00
This is clearly not padded to a four-byte boundary. Am I
misunderstanding something or is this a known problem? [I have not
investigated the cause of this: it could simply be a bug in the profile
or it could be a more serious LCMS bug with padding the last tagged
element data.]
Keith
