Jump to content
You must now use your email address to sign in [click for more info] ×

[2.1.0] Temporary incorrect appearance of Image object after assigning new profile to document


Recommended Posts

AP 2.1.0 (Affinity store version) and AP 1.10.6 (Apple Mac store version)

macOS 12.6.5

 

Colour managed rendering of a placed Image object requires a transformation of colour component values from the Image's colour space to the document colour space. However, the Affinity apps temporarily behave incorrectly with regard to that.


Expected behaviour:

The appearance of an Image object should not change when the hosting document's colour profile is changed by assignment (distinct from conversion) when the colours of the Image are within the gamut of the before and after document profiles. The software should immediately compute a transformation of values from the Image colour space to the new colour space of the document in order to preserve the appearance of the Image object.  


Actual behaviour:

The appearance of an Image object does temporarily change when the hosting document's colour profile is changed by assignment (distinct from conversion), even when the colours of the Image are within the gamut of the before and after document profiles. The incorrect appearance persists until the document is saved and closed. When the document is re-opened, the Image gets rendered with the correct appearance.


Suspicions (can be ignored by the developers, of course):

When an Image is initially placed in a host document, the software immediately computes and caches a transform of the image's values from Image colour space to document colour space, and that cache is the source of values for subsequent computations involving the Image.
When a document already containing an Image is opened, the aforementioned cache is rebuilt.
When an Image hosting document's profile is changed by assignment, the software should immediately rebuild the aforementioned cache, but fails/neglects to do so.


Simply reporting a bug. Not looking for any workarounds.

Additionally, to be clear, there is no problem with profile conversions. The problem involves profile assignment.

Link to comment
Share on other sites

Hi @lepr,

What are the two profiles in quesion, i.e., the image's colour space and the document's colour space?

Affinity Designer 2.4.2 | Affinity Photo 2.4.2 | Affinity Publisher 2.4.2
Affinity Designer  Beta 2.5.0 (2402) | Affinity Photo Beta 2.5.0 (2402) | Affinity Publisher Beta 2.5.0 (2402)

Affinity Designer 1.7.3 | Affinity Photo 1.7.3 | Affinity Publisher 1.10.8
MacBook Pro 16GB, macOS Monterey 12.7.4, Magic Mouse

Link to comment
Share on other sites

24 minutes ago, Hangman said:

What are the two profiles in quesion, i.e., the image's colour space and the document's colour space?

 

If you have a display with wide gamut, such as P3, so the anomaly is not hidden/reduced by a narrow device gamut, an example to try is:

  1. new sRGB document
  2. place an Image which has embedded sRGB profile in the document - the image is rendered with correct appearance
  3. assign the profile named 'Display P3' (that is the name of a document class profile, not to be confused with a device profile for a P3 monitor) to the document - the Image object immediately appears oversaturated with the same appearance as if the 'Display P3' profile had also been assigned to the image
  4. save and close the document
  5. open the document - the Image is now rendered with correct, not oversaturated, appearance

 

Link to comment
Share on other sites

On 5/28/2023 at 1:38 PM, lepr said:

Expected behaviour:

The appearance of an Image object should not change when the hosting document's colour profile is changed by assignment (distinct from conversion) when the colours of the Image are within the gamut of the before and after document profiles. The software should immediately compute a transformation of values from the Image colour space to the new colour space of the document in order to preserve the appearance of the Image object.  

I don't believe this is the case, the numeric colour values for any pixel will remain the same when the hosting document's colour profile is changed by assignment which is correct but you are now viewing the document in a different colour space so it will look visually different regardless of the colours of the image being within gamut of the before and after document profiles.

The image will only look visually the same when converting the profile (not when assigning it) but in doing so the numeric colour values for any pixel will change.

On 5/28/2023 at 1:38 PM, lepr said:

Actual behaviour:

The appearance of an Image object does temporarily change when the hosting document's colour profile is changed by assignment (distinct from conversion), even when the colours of the Image are within the gamut of the before and after document profiles. The incorrect appearance persists until the document is saved and closed. When the document is re-opened, the Image gets rendered with the correct appearance.

When the document with the assigned profile is saved, closed an reopened, despite the image looking the same as the original, less saturated sRGB image, the numeric colour values for the pixels will be different i.e., they will be the same as if you had converted the Image using the Display P3 profile.

Because the numeric colour values don't change when assigning a profile if you consider where 0 and 255 sit in the two different gamut's it is inevitable that the visual appearance will change, in this instance the image will become more saturated, unlike when converting the image.

I may have missed the point you are trying to make but this is my take on it at least... :)

Affinity Designer 2.4.2 | Affinity Photo 2.4.2 | Affinity Publisher 2.4.2
Affinity Designer  Beta 2.5.0 (2402) | Affinity Photo Beta 2.5.0 (2402) | Affinity Publisher Beta 2.5.0 (2402)

Affinity Designer 1.7.3 | Affinity Photo 1.7.3 | Affinity Publisher 1.10.8
MacBook Pro 16GB, macOS Monterey 12.7.4, Magic Mouse

Link to comment
Share on other sites

3 hours ago, Hangman said:

I may have missed the point you are trying to make but this is my take on it at least... :)

You possibly are missing my point. I may be misunderstanding you, but you appear to be confused about what to expect from properly functioning colour management. As I said, I may be misunderstanding you, so let's leave it at that. No more discussion or points of view in this particular thread, please.

This thread was intended as a bug report only. It's for the developers to deal with. They can decide for themselves whether my point of view is valid or not.

You are entitled to your opinion, of course, but I'm not going to discuss colour management with anyone in this particular thread.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.