[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] 6523398: sun.java2d.cmm.lcms.LCMS.setTagData
From:       Alexey.Ushakov () Sun ! COM (Alexey Ushakov)
Date:       2008-04-08 12:48:32
Message-ID: 47FB69A0.4060505 () sun ! com
[Download RAW message or body]

Hello Keith,

Actually, I've used littleCMS for creating GRAY profile. This library 
has internal support for GRAY and can generate it as a file. So, I think 
that alignment problem is related to this library. Probably, it's 
already fixed in newer version. If not you can submit the bug on lcms.

Best Regards,
Alexey

Dmitri Trembovetski wrote:
>
>   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



[prev in list] [next in list] [prev in thread] [next in thread]