On Thu, 3 Mar 2022 21:27:36 GMT, Phil Race <p...@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
