On Wed, 12 Mar 2025 21:09:42 GMT, Harshitha Onkar <hon...@openjdk.org> wrote:

>> * Builtin color profiles may be cached during initialization or on first 
>> use. Changing a standard profiles after initialization using 
>> ICC_Profile.setData may not have the desired effect.
>
>> > Since there is no way to check if a profile is built-in, making built-in 
>> > profiles read-only might be a better approach, similar to [java 
>> > properties](https://bugs.openjdk.org/browse/JDK-8066709).
>> 
>> But it also has its own disadvantages...
> 
> @mrserb  You mentioned earlier that there are disadvantages of using java 
> properties approach, so using builtIn flag would be better then, correct?
> 
>>  I remember we discussed this issue during the review of [this 
>> commit](https://github.com/openjdk/jdk/pull/3037/files#diff-3dd53a33889801159f43dbb990ba033066bdabaed71bbc7254f58331d3898d69R39),
>>  and the conclusion was that it was too late to change it and break apps.
> 
> I wasn't able to find the previous discussion thread so I'm not sure what are 
> the disadvantages. Can you please explain?

If we start from the beginning. The problem we are trying to solve is 
preventing changes to our standard profiles so that we can be sure one part of 
the application does not unexpectedly affect another. This could be achieved in 
two ways:

- Throw an exception if a standard profile is modified
- Ignore the requested change and use the default profile properties as is

For new applications, we could require always cloning the color profile before 
modification (via the updated specification); otherwise, the application must 
always check whether the profile is built-in or not.

However, for older applications, these two solutions lead to different outcomes:

- Throwing the new exception will most likely break the application
- Ignoring the data change allows the application to continue working, but the 
color conversion result may not be fully accurate

The next question is: how big of an issue is this inaccuracy? For example, if 
we have an sRGB profile that rejects some modifications, we would still try to 
produce valid sRGB data during conversion.

So the trade-off is: broken applications vs. inaccurate (but still 
ICC-spec-compliant) conversions.

PS: By the way, why do we want to enforce this rule only for built-in profiles? 
Why can't a library create similar profiles and mark them as "read-only"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23606#discussion_r1994532183

Reply via email to