RFR: JDK-8347377 : Add validation checks for ICC_Profile header fields [v3]

[Sergey Bylokhov]

On Tue, 14 Jan 2025 17:26:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> @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.

>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.

maybe If the cooked approach always throws an exception and the current approach via "cmsSet" just ignores all errors means we are doing something wrong? Can we ask lcms maintainers why the validation is not done for this methods?

for example for the next method is it assumed that the client code should check the content of Table 10, and reject all incorrect values?:

**void cmsSetColorSpace(cmsHPROFILE hProfile, cmsColorSpaceSignature sig);**

Sets the color space signature in profile header, using ICC convention.
Parameters:
hProfile: Handle to a profile object
sig: any cmsColorSpaceSignature from Table 10
Returns:
*None*

https://www.littlecms.com/LittleCMS2.16%20API.pdf

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1915355480