RFR: 8282577: ICC_Profile.setData(int, byte[]) invalidates the profile [v3]

[Phil Race]

On Thu, 3 Mar 2022 21:27:36 GMT, Phil Race <prr at openjdk.org> wrote:

>> As per the bug eval, we are returning a pointer to a native raw LittleCMS profile and it should be a cooked one.
>> The simple test fails before the fix with
>> ~/jdk17/Contents/Home/bin/java SetTagDataValidation                               
>> Exception in thread "main" java.awt.color.CMMException: LCMS error 13: Couldn't link the profiles
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createNativeTransform(Native Method)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMS.createTransform(LCMS.java:104)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.doTransform(LCMSTransform.java:143)
>> 	at java.desktop/sun.java2d.cmm.lcms.LCMSTransform.colorConvert(LCMSTransform.java:633)
>> 	at java.desktop/java.awt.color.ICC_ColorSpace.toRGB(ICC_ColorSpace.java:224)
>> 	at SetTagDataValidation.main(SetTagDataValidation.java:61)
>> 
>> and with the fix  just prints 
>> java SetTagDataValidation
>> 0.4
>> 0.5000076
>> 0.6
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282577: ICC_Profile.setData(int, byte[]) invalidates the profile

I'm not sure if everything in that github issue is 100% accurate or understood by me but Marti's point is

So you use RAW functions in copyProfile() and then access them using cmsReadTag in test().
This is the case described in the manual.

> If we will create a new profile it will not be possible to use it by the ColorTransform,
> because the LCMS will call cmsReadTag under the hood.

Well this seems to have been the long-standing bug I am trying to fix - because we
copied a profile and what we *returned* is not the result of
"you will need to dump the profile to memory or disk and then reopen it."

The new code does that and so it works.

> But even if it will work the content of the tag will be changed.

Yes, any tags that are read by the implementation (or by the client) *may* be changed.

I am saying that if our "pfSanity" test profile did not call cmsReadTag() and returned
pfSanity directly - or directly called cmsReadRawTag() - it will get back the same
data it set. We don't want to "skip" that sanity since it is what tells use we want
to throw IAE. So just "recreate" the profile. Then ReadWriteProfileTest will be happy
*so long* as it does its comparisons BEFORE trying a ColorConvertOp.

There is nothing I can do to fix that short of us maintaining a Java level cache
of all the raw tags and never asking the CMM for any data that may have been cooked
and serialised. That might work too but I am not sure it is important enough to try.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7668