APhoto - wrong result with softproof absolute colorimetric

[cgidesign]

Photo 1.10.5 on Windows.

Softproofing a document with absolute colorimetric rendering intent gives wrong results.

I have a cmyk document I softproof for iso newspaper output. The ISO newspaper ICC is known to have a strong yellowish, orange whitepoint. But the softproof in APhoto does not shows this in whites. And the color itself gets a severe hue and lumance shift, which should not be there.

Cross checked with APublisher; it's wrong there as well.

Cross checked with Krita. There everything works as expected.

User error or bug?

cmyk.afphoto ISOnewspaper26v4.icc

[thomaso]

9 hours ago, cgidesign said:

The ISO newspaper ICC

Do you really mean this profile? I wonder because in the 4 captions it says "ISO coated v2" and that is also assigned in the Krita dialog window.

To me "ISO coated v2" indeed does cause a warm & slightly contrasting tint while "ISO newspaper ICC" is cooling & brightening.

[cgidesign]

Thanks for pointing this out. In the screeshot I had accidentaly hit the mouse wheel - so the profile changed. Krita takes a little time to update the softproof when the profile changes - so it still showed the ISO newspaper result, but the dialog already showed ISO coated.

Here is the correct screenshot.

[Dan C]

Hi @cgidesign,

Thanks for your report and I'm sorry to hear you're having trouble!

Firstly, can you please confirm for me, do you have a custom, or non-standard ICC profile applied to your monitor, through your OS?

Affinity performs 'document to screen' conversion, using your monitors colour profile which other applications may not - and I've seen this cause difference in colours previously.

Secondly, if you disable the Soft-proof adjustment in your document, then navigate to Document > Convert Format/ICC Profile, in the dialog that opens, select your ISOnewspaper profile, and ensure it's set to Absolute Colormetric, then convert the file.

Does this now match the document in Krita with the softproof applied, or does this still appear incorrectly, the same as the first example shown in your screenshots?

I'd just like to try and determine if this is an issue with the softproof adjustment, or perhaps a larger issue with the colour conversion itself.

Many thanks in advance

[cgidesign]

The monitor is custom profiled. Its ICC profile is assigned in Windows color management as the default profile for this device.

Settings in the profile are sRGB primaries with D65 whitepoint and gamma 2.2. instead of real sRGB gamma.

Converting the document to ISO newspaper does not give the same result as in Krita.

The next part of this post is according to my tests on my system. I do make assumptions which might be wrong and therefore my conclusion that the A apps have a limitation regarding colormanagement might be wrong as well.

I think what's wrong with the softproof (maybe even the whole color management) is, that it first tries to convert into ISO newspaper but then internally does a second conversion back to monitor ICC. I assume in absolute colorimetric intent it takes the whitepoint of the ISO newspaper (the yellowish paper color) but then it does another absolute colorimetric conversion to the D65 monitor white. But this is not how softproof should work. The intention is to simulate on the monitor how the color on a specific medium ("paper") would appear. But APhoto seems to simulate how it would look if a newpaper printing press would directly print on my monitor screen. Even though this is a, well, interesting approach, it is not really helpfull for printing work.

Here an example of an RGB document:

If you check how Krita has implemented its color management (attached screenshots), you notice it gives more control to the user. One can even control if chromatic adaption should be applied or not. On the other hand I like the concept of having adjustment layers for softproofing in Aphoto. This is more flexible than the "preferences thing" in Krita. But in its current state the function in Aphoto does not work as intended and franly speaking I can't use the A apps for final print work color decisions because of that.

Lets assume I make a brochure for a company that needs to be PDF, web online, printed RGB, printed high end CMYK. In that case I would create the document in a wide gamut RGB space (maybe Adobe RGB). I would then create several softproof layers. One for sRGB, one for the ICC profile I got from the online RGB printing company and one for the ICC profile I got from the local CMYK printing company. I can then work on the document and see how it would look when outputed to the specific final devices (avarage sRGB monitor, RGB printer, CMYK printer) - So, I have a source document and a softproof to see / judge the "device referred" outputs. This way of working is not possible with how the A apps have implemented color management.

I even tried to set everything in APhoto (color preferences, document CMYK) to ISOnewspaper with the goal to "see" the color how they would look when printed on the typical yellowish newpaper paper. It seems there is now way to do this in Aphoto.

Again, maybe I am wrong with all this. In that case I would love to hear what my mistake is.

softproof_2.afphoto

[Dan C]

Many thanks for the further information and screenshots provided, I can certainly understand the frustration caused here and I agree this could be implemented better in Affinity - once we've determined a possible cause for the difference between the two apps, I'll be sure to log this with our developers for further consideration and investigation.

If you change the monitor profile within Windows to the default sRGB profile, then restart Affinity and apply the soft-proof adjustment once again, does it now match Krita?

[cgidesign]

Changing to standard sRGB profile in Windows color management shows the same issue. This is expected because both the default sRGB profile and my custom one are using D65 whitepoint. In general I won't call this a bug but a general limitation in how the color management in the Affinity apps work. Instead of being able to setup a workflow with a wide gammut color space as a source and then simulate how the result would be on various output device classes, I need to set the source to the specific intendet output. This is not wrong per se, but follows the traditional "device referred" workflow. But in my todays world I am faced with a more demanding situation:

E.g. just two days ago we sat together with a young team of online community managers. They offer to take care of all the activities needed to feed social media (instagram, facebook, LinkedIn, twitter etc.) - on top PDF, and printed content was discussed.

One main point of the discussion was: "Create the source content once -> and then publish it to all channels with the minimum ammount of adjustments required." Simplified that means, I need to drop a photo into my app as e.g. wide gammut Adobe RGB, simulate output for sRGB web, home printer RGB, online printer service RGB, quality printing company CMYK. Make it look good and export to the desired output with the required color conversions. This is a "scene referred" workflow.

In Affinity this workflow is not possible at the moment because the color management does not really support it.

Another detail regarding this: The color panels in Affinity are not color managed the way they need to be for a "scene referred" workflow. E.g. if I create my source document as "Adobe RGB" then I see the colors in the panels as Adobe RGB. But when I want to do adjustments for e.g. ISO newspaper I would like to pick the colors in that color space. In affinity I can't do that (and on top of that there is the issue of wide gamut monitors vs. default sRGB monitors - see this thread:

Here is how Krita handles it:

Even if my document is in e.g. Adobe RGB, I can set the color panels to show colors in e.g. ISO coated. This is great to stay in a "wide gamut scene referred" workflow but still set colors with a specific output device in mind if that is required.

It gets even more demanding if we take the 32 bit world into account. Following your forum, I noticed that Affnity seems to become one of the go to apps for quick texture painting and vfx compositing. There we are talking about ACES-cg, BT.2020, REC.709 color spaces in 32 bit linear mode. But it seems Affinity has an issue when exporting such data as a final sRGB image ("double conversion of gamma curve", of course one can workaround this, but better would be it works in the first place).

Please don't take this post as being negative. I like your APPs a lot. The selection / mask refine feature works great for me, the idea to have softproof as an adjustement layer is ingenious in my opinion, blend ranges are a masterpice of concept, the brushing / painting works on my pen display without issues, 32 bit and ocio works (even though a bit rough around the edges), the idea to have designer and photo as "plugins" for publisher is really nice and so on, if just the color managent would be a little bit more flexible.

Thanks for reading.

[Dan C]

Thanks for trying that for me @cgidesign and I'm sorry to hear the results have not changed!

I do not mind admitting that this is a little beyond my personal experience/knowledge with colour conversion workflows, and as I would not wish to provide the incorrect information I have forwarded this internally to our Affinity experts for further discussion - as firstly I'd like to learn more in this regard, and secondly I would like for us both to understand the expected results in Affinity and whether this is technically a bug or simply an area in which Affinity can improve upon.

I'll be sure to reply here regarding this once I have better information/understanding and I thank you for your patience and understanding in the meantime

[cgidesign]

Never mind, it took me a lot of time as well to get all those color conversion concepts into my head. Looking forward to hear what you and your colleagues think about it.

One more limitation I did not mention explicitely so far:

Affinity is reading the monitor ICC profile from the Windows color management settings:

But, my monitor supports various color modes.

It came with a nice plug to switch its settings. I set button 1. to adobe rgb and button 3. to my sRGB.

Unfortunately, switching the monitor's color mode does not change the Windows color managment. When I switch the monitor to adobe rgb, Windows still has sRGB as the default ICC profile.

As a result Affinity is reading the wrong profile and the color management is working with the wrong data. There is no way to tell Affinity to use a differnt monitor profile.

Here is the solution in Krita:

As default it loads the "default" profile from the Windows color managment. But I can use the drop down list to choose another one if required.

In Affinity I would need to:

• save the document
• close affinity
• go to Windows color management
• change Windows ICC default
• save changes
• open affinity
• open document

For me the Krita solution is way more flexible.

[Designer1234]

I've tried to check what you wrote and I see that there is (?) indeed a problem with absolute colorimetric intent.

But can you explain me one thing... when are these intents used? I thought that they're used during color conversion while printing... But I agree that in such case soft proofing wouldn't be possible (?)... so we can also use one of them - Absolute Colorimetric - to simulate printing media white point during soft proofing, right? And is this the thing that does not work in AP?

You wrote that "I even tried to set everything in APhoto (color preferences, document CMYK) to ISOnewspaper with the goal to "see" the color how they would look when printed on the typical yellowish newpaper paper. It seems there is now way to do this in Aphoto." That's true. 

But you also suggested, that instead of working in one color space and the soft proof your work for different usage scenarios, in AP you have to choose desired color profile on the beginning But that (see your statement above) won't let you see how yellow is your paper.
And... it's also not possible in Krita.

If I convert image color space of my example sRGB image into ISOnewspaper (Absolute Colorimetric, BlackPoint Compensation) results are the same in Krita and AP. 

Either I don't understand something as a noob, or you simply mixed to many things in your posts - because as I can see the only difference between Krita and AP is soft proofing in AC intent, setting document color profile to ISOnewspeper gives me the same extremely bright white and high contrast on the image... 

So the soft proofing in AP is broken indeed if we want simulate white color of the specific media, but as I can see "out of gamut" colors are identically marked. 

[Soulartist]

On 5/4/2022 at 6:41 AM, Dan C said:

Many thanks for the further information and screenshots provided, I can certainly understand the frustration caused here and I agree this could be implemented better in Affinity - once we've determined a possible cause for the difference between the two apps, I'll be sure to log this with our developers for further consideration and investigation.

If you change the monitor profile within Windows to the default sRGB profile, then restart Affinity and apply the soft-proof adjustment once again, does it now match Krita?

Hello: I would add that this issue has been going on for at least a few years now. 

[lacerto]

On 5/1/2022 at 10:23 AM, cgidesign said:

Softproofing a document with absolute colorimetric rendering intent gives wrong results.

Soft Proof adjustment in Affinity apps does not behave similarly as in Photoshop, and IMO it has many flaws that make it more or less useless for the kinds of jobs I'd need it (mainly to work in RGB document color mode and being able to use Soft Proof to simulate colors in document CMYK target color space -- something that can actually be worked around as long as you do not have pixel layers as you can switch between RGB and CMYK document color modes without a problem as long as all layers are either vectors or images, and have reasonably accurate color simulations in both modes).

But Affinity apps do work correctly in this specific instance: showing correctly what color conversion from RGB to CMYK using Absolute Colorimetric rendering intent is going to look like. The problem is rather that with most images the outlook of the preview shows highly desaturated (washed out) colors, which do not look much what the colors look like if and when the conversion is actually done; and that rendering intent generally does not seem to have much effect on display of out-of-gamut colors (the off-gamut marking seems to be always done based on Absolute Colorimetric rendering intent).

But as mentioned, in this specific instance the ISONewspaper color profile when used with Absolute Colorimetric rendering intent does cause decrease of ink usage (total area coverage) also in light area. Interestingly Krita shows much a different preview but when it actually converts the colors, renders much the same color values as Photoshop and Affinity Photo.

(Note: In the end of the video I switch the color modes in the Color Panel to demonstrate that there the initial RGB color value R230 G229 B218 still gets converted to CMYK using the Relative Colorimetric rendering intent, even if the document colors were converted using Absolute Colorimetric.)

[Designer1234]

On the movie above you showed that soft proof in Adobe Photoshop - without paper color simulation - looks exactly the same as in Affinity... "white" square remained bright, no yellow tint. So, the golden standard on the market works the same as the AP? Perhaps there is something wrong with Krita then, or the only thing that is missing in AP is paper color simulation?

[lacerto]

6 hours ago, Designer1234 said:

So, the golden standard on the market works the same as the AP? Perhaps there is something wrong with Krita then, or the only thing that is missing in AP is paper color simulation?

I think it is much a question of in which context, RGB or CMYK, soft proofing is used. I would not use Affinity apps or Krita at all in context of CMYK print workflow as they show colors muddled (perhaps, indeed, because inherently applying paper color simulation, which does not work well in CMYK context even in Photoshop), and gamut markings without being able to take into account different rendering intents:

a) ISO Newspaper with Absolute Colorimetric and Relative Colorimetic, soft proofing turned on:

Here PS is the only one that really previews how the document will look when it is actually converted to CMYK, and its preview for "Relative Colorimetric" actually also shows reasonably well how the colors would print on a newspaper kind of media (with appr. 220% TAC). Using gamut warnings in CMYK context is also more or less non-sensical in Krita and Affinity apps:

b) RGB print workflow with printer specific media, upper row Absolute Colorimetric and lower row Relative Colorimetric, and gamut-off warnings turned on:

PS has paper color simulation turned on, and here the use of the feature seems to make sense; however its use also makes PS deviate more from the other two so it does not seem that they actually use paper simulation in their proofing. In RGB mode Krita works pretty much similarly as PS as regards gamut warnings, but Affinity apps show identical gamut warnings no matter which rendering intent is used.

[cgidesign]

18 hours ago, Soulartist said:

Hello: I would add that this issue has been going on for at least a few years now. 

That's interesting. Has there ever been a feedback from Serif about it?

[lacerto]

14 minutes ago, cgidesign said:

That's interesting. Has there ever been a feedback from Serif about it?

Probably, at least at the time these features were initially developed (i have "only" been around about three years now). Because Affinity apps have a kind of an in-built soft proof whenever the document is in CMYK mode, in which colors of native objects (vectors) can have RGB definitions (and would be exported with their native values when exported in RGB mode), and RGB images imported to CMYK mode documents also stay in RGB format even if shown with their underlying profile based CMYK target conversion values, there has obviously been less need for implementing the kind of CMYK proofing that is supported e.g. in Adobe apps. This, however, only works well in Designer and Publisher, while in Photo, which typically has Pixel layers, switching the document color mode would result in actual conversions. But why RGB proofing does not work similarly as in Photoshop (or Krita), is not clear to me, perhaps the feature simply just is not fully implemented, which is kind of understandable considering that there is also no full support for desktop printing.  

[Dan C]

Apologies for the delayed response all - I just wanted to update the thread to inform you this is still being investigated by our teams internally and I hope to have a further response for you shortly

[thomaso]

26 minutes ago, Dan C said:

is still being investigated

FWIW (and not covered already by @lacerto's documentation)…

I am using the German print provider "Saal-Digital" for quite a while, they became known years ago for reliable, color consistent prints and have initially been specialized in fine art prints on various papers, as e.g. Hahnemühle,, offering softproof profiles for each of their printers respectively materials and the differing settings (Color space | Preserve Numbers | Rendering Intent | Black Point Compensation | Simulate Paper Color).

https://www.saal-digital.co.uk/service/icc-profile/

In Dec. 2021 I run into issues with softproof their CMYK-profile for prints on alu-dibond. In Affinity it appeared a bit 'pale' (contrast reduced / missing black). I contacted their support, including various screenshots of softproof in Affinity vs. Photoshop (CS6).   saal aludibond softproof 1-4.pdf

Finally the support recommended not to use Affinity for softproofing because of the missing option "Simulate paper color".

Quote

Thank you for your patience. We have now received the feedback from our department. Unfortunately, we cannot recommend Affinity Photo for the softproof of our products. If you create the softproof in Photoshop, we advise to deactivate "Simulate paper colour" or "Simulate black ink" to get the best softproof result.

With kind regards, Kristina from Saal Digital, support@saal-digital.de

(translated from Germany)

Meanwhile there is an according note on their website: https://www.saal-digital.com/support/article/softproof-in-affinity-photo/

[Dan C]

Thanks for your patience here!

On 5/4/2022 at 12:45 AM, cgidesign said:

I think what's wrong with the softproof (maybe even the whole color management) is, that it first tries to convert into ISO newspaper but then internally does a second conversion back to monitor ICC. I assume in absolute colorimetric intent it takes the whitepoint of the ISO newspaper (the yellowish paper color) but then it does another absolute colorimetric conversion to the D65 monitor white.

Our team believe this is the cause for the softproof rendering differently from other creative apps, and I'm tentative logging this as a bug, as I cannot see a use case for this method when physically printing the document.

Within this report I'm also requesting that the feature has in-depth testing done, as this isn't the only issue mentioned in this thread (and others similar) regarding Soft Proofing for print.

On 5/5/2022 at 7:44 AM, cgidesign said:

This is a "scene referred" workflow.

In Affinity this workflow is not possible at the moment because the color management does not really support it.

On 5/6/2022 at 8:06 AM, cgidesign said:

Unfortunately, switching the monitor's color mode does not change the Windows color managment. When I switch the monitor to adobe rgb, Windows still has sRGB as the default ICC profile.

As a result Affinity is reading the wrong profile and the color management is working with the wrong data. There is no way to tell Affinity to use a differnt monitor profile.

Here is the solution in Krita:

As default it loads the "default" profile from the Windows color managment. But I can use the drop down list to choose another one if required.

As you've mentioned the above 2 points aren't currently possible in Affinity, however I can certainly see the benefits of this monitor profile switching tech and 'scene referred' workflows, so I'm logging these as improvements for our devs to see and consider for a future update.

On 5/13/2022 at 3:04 PM, thomaso said:

Finally the support recommended not to use Affinity for softproofing because of the missing option "Simulate paper color".

I can confirm that this is already logged as an improvement with our developers, so I'll be adding a few additional 'votes' to this now. 

 

I hope I have covered all the points raised here, please do let me know if I have missed, or misunderstood any of these

[cgidesign]

@Dan C Thanks a lot for the feedback. Are you going to update this thread once there are news about the topic or, if something changes, will it be in the release notes?

[Dan C]

No problem at all, I'd recommend keeping an eye on the release notes regarding this

[Designer1234]

So, as i thought, the main problem is a problem with paper color simulation that is not working in AP  It was really hard to understand these complicated, wordy descriptions above  (OK, some additional color management settings will be perhaps useful, more options is usually a good think in such software)

[cgidesign]

As far as I know there is no "paper color simulation" in the ICC world. ICC profiles contain a white point tag. This one can be considered the paper color. In a correct colormanagment this tag is used to simulate the paper color if "absolute colorimetric rendering intent" is used. It think this is one part where AP fails which makes the softproof disfunctional.

[PixelEngineer]

On 5/3/2022 at 7:45 PM, cgidesign said:

I think what's wrong with the softproof (maybe even the whole color management) is, that it first tries to convert into ISO newspaper but then internally does a second conversion back to monitor ICC

I can see why you would think that but I don't see anything wrong at the moment when using the softproof feature in regards to the way AP converts to other color spaces though on my end. If you recreate that color in a brand new document from scratch directly from within Affinity Photo and run the soft proof again under relative colorimetric you will not see the dramatic color shift.

One thing is for certain. The file that you uploaded has very unusual characteristics. That's for sure. It went through a process.

I would check the following:
How are your profiles set up in Affinity Photo > Edit > Preferences > Color.
Was this document exported from Krita and imported to Affinity Photo. If so, in Krita what are the profile settings. Is it what you posted earlier in the screenshots ? The monitor profiles itself?

The issue that you are having can most likely be easily fixed. Just need to know the details above for the most part I believe. 

 

[PixelEngineer]

On 5/8/2022 at 6:08 PM, lacerto said:

Soft Proof adjustment in Affinity apps does not behave similarly as in Photoshop

That's Interesting . . .  I followed the steps in the video and Affinity Photo produced CMYK 2020 the exact values that Adobe Photoshop generated in the video. I got these results working with the cmyk.afphoto "unusual document" that the user uploaded.  

I believe that this document is "corrupted" and has an offset because of the environment that it was coming from in regards to a possibly mismanaged (Color Management System ) CMS setup. After running several tests on my end, the video is actually showing the programs using a bad file creating an illusion that something is wrong with either program. 

Anyone can test this. Using the same app either AP or PS, run the test again with the document that was uploaded by the user. After running the first half of this test running off of the corrupt file that was uploaded in the beginning of this thread cmyk.afphoto, create a brand new document from scratch on another tab and run the same test. You will see two different results in the same program. You can do this test in either program(PS or AP) and you will get the same results. 

Note: When working with this particular "corrupted document" that the user uploaded, the RGB eye dropper tool will become unreliable and cannot be trusted in either program (PS or AP) because of an error introduced during the color management workflow that created this unusual document. I was able to recreate this anomaly by simulating incorrect use of color management on my computer. Very strange and very interesting. Its a good example on why it is very important to setup your color management correctly in the OS and within the applications. Just thought I mention this.