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

[Harshitha Onkar]

On Fri, 24 Jan 2025 00:57:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Did the upstream provide any feedback/comments about this validation?
>
> BTW
>>Typically, the user or application will set the rendering intent dynamically at runtime or embedding time. Therefore, this flag may not have any meaning until the profile is used in some context, e.g. in a DeviceLink or an embedded source profile."
> 
> Why this usecase should not be covered by the java? As of the current version of patch it will not be possible to load the profile and then set the intent, right?

> I don't think this is right. It's not a javase spec, and there may be a reason why the most common library for icc profiles accepts thad data. We shouldn't be more strict than that, it will limit java applications compared to the alternatives.

The path that you mentioned in LCMSTransformfor RenderingIntent  involves creating a new color space transform using 2 or more profiles and does not involve creating or updating a profile. 
Moreover when a random value is added for rendering intent in LCMSTransform as below, LCMS throws CMMException , but when I change to any other value (ICC Intent or Non-ICC Intents as specified in the table 41 above) it passes.  If LCMS validates the Rendering Intent while creating  a new color space transform then wouldn't it be better to validate it while creating/updating a ICC_Profile.

And as for the different values specified in ICC_Spec vs LCMS API doc, @prrace confirmed that jdk is required to follow ICC_Spec.

> Did the upstream provide any feedback/comments about this validation?

Discussed with @prrace, in this case it was decided that contacting upstream is not required since we are choosing to do validations in any case (whether or not LCMS validates).

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

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