On Tue, 14 Jan 2025 00:22:15 GMT, Harshitha Onkar <hon...@openjdk.org> wrote:
>>> The ICC spec. defines only these 4 intents, so I don't see a problem here. >> >> our own profiles do not strictly follow these specification, so if lcms >> ignores that we can do the same, especially since we fallback to the >> "Perceptual intent" >> https://github.com/openjdk/jdk/blob/13a1775718f329b02cdeb82f9d3f7d878ac5e771/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L75 > > @mrserb >> Then probably we can use approach similar to 8282577: >> https://github.com/openjdk/jdk/commit/f66070b00d4311c6e3a6fbf38956fa2d5da5fada >> and try to rely on lcms for validation. > > The cooked approach doesn't work for ICC_Profile header data. In case header > data is updated using the cooked approach we run into `IAE- cannot write tag > data` for both invalid as well as valid header field values. There are > separate LCMS APIs to set header fields `cmsSetHeaderRenderingIntent(..), > cmsSetDeviceClass(...)` so I don't think we should be using cooked approach > to set header data. > > Additionally, it is more efficient if these validation checks are added > early on rather than process the data, go all the way to native side - LCMS.c > just to return with IAE in case of invalid header data. > > The cooked approach involves copying over the data to a new profile, writing > it to a memory buffer and then loading it back to check for profile > correctness. This seems to be a lot of work for header data when simple > validation checks in setData() can prevent invalid data. > "our own profiles do not strictly follow these specification" > > What you are pointing to isn't a profile. It is code that accepts a requested > rendering intent. I don't see how it is related. the new code will be called when loading raw data for a profile, so if that profile was previously accepted and used some default values, the new code will reject it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915300959
