On Fri, 24 Jan 2025 00:57:47 GMT, Sergey Bylokhov <s...@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
