On Tue, 14 Jan 2025 17:57:39 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
>>>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 > > probably the answer will be that not all profiles are used for > transformation, and just to read some of its properties it is not necessary > to reject unexpected data such as intent/etc. @mrserb The location mentioned in LCMSTransform involves creating a new color space transform using 2 or more profiles and DOES NOT involve creating or updating a profile. Moreover LCMSTrandorm throws CMMException for invalid rendering intents so this case won't be an issue. > 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? We are choosing to add these validation checks to jdk irrespective for whether lcms validates or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23044#discussion_r1920884736
