Ethcap
-
Posts
11 -
Joined
-
Last visited
Posts posted by Ethcap
-
-
I have now tested with multiple images, using multiple ICC profiles and the results stay consistent, e.g. switching from Absolute Colorimetric to Relative or Perceptual does nothing to bring out of gamut colours into gamut in Affinity Photo. I should note it is not as sever on all profiles and acceptable on some (depending on the image), however when compared to Lightroom or Photoshop the differences are simply too great to ignore, at least to me, as illustrated in the chart I posted originally.
In the end one of apps must be having some form of bug/problem in my opinion, and since no one seems to be interested in answering this thread I will open a new post in the bug and well linking back to this one.
-
Anyone else experiencing this other than myself and Roger C? Anyone else with suggestions or anyone from the Affinity Photo team themselves that can chime in?
Anyone out there?
-
Hi firstdefence
Quotein Photoshop if I select View > Proof Setup > Working CMYK I can turn on the Gamut Warning and then Photoshop shows me the same greying as in Affinity Photo.
I am still getting different results, in fact, choosing ‘Working CMYK’ sets up the image to what is defined in Photoshop’s ‘Colour Settings’ dialogue (Edit > Color Settings…), which in my case happens to be U.S. Web Coated (SWOP) v2 and Relative Colorimetric and changes the mode of the image to CMYK. If I select the same ICC profile in Affinity Photo’s soft proof adjustment later I get the same result as the chart I posted shows, I.e. the same result.
QuoteUsing sRGB disables the Gamut Warning option in Photoshop.
Seemingly not on mine
The ICC profile name from Hahnemühle is ‘Photo Rag’, for your convenience I have attached it to the post here, the lab uses SC-P8000.
Please bear in mind that as I stated, I have tested with multiple profiles from both Hahnemühle and Canson with different EPSON printers the SC-P800, SC-P8000 and the Stylus R3000 including some of the built-in profiles, all with the same result, so it doesn’t really seem to be a profile issue per-say.HFA_Eps3000_MK_PhotoRag.icc
HFA_EpsSC-P800_MK_PhotoRag.icc
HFA_EpsSC-P8000_MK_PhotoRag.iccIt seems to me that Affinity Photo isn't even trying to map the out of gamut colours, from the source colour space to the destination media colour space, at least when selecting a render intent other than Absolute Colorimetric, as I would expect colours to be compressed to the nearest possible colours in the destination profiles colour space when using Relative, Perceptual or Saturation rending intents as explained in this Affinity Photo video; https://vimeo.com/152413642
That said if I am doing something wrong please enlighten me how I should do it.
Thanks.
-
To rule out possible issue with the Hahnemüehle Photo Rag ICC I downloaded additional Hahnemüehle profiles. I also downloaded three Canson profiles as well as testing with some built in profiles such as FOGRA27, U.S. Web coated (SWOP) v2 etc, all with the same results, e.g.; on papers where colours show as out of gamut using Absolute Colorimetric rendering shows no change at all when choosing Perceptual or Relative Colorimetric rendering intent in Affinity Photo, while doing the same in Photoshop, most of the out of gamut colours are shifted into the profiles gamut, in other words the same behaviour as the post and attachment details.
Hope this additional information might help in solving the issue.
-
Hoping someone can shed some light on an apparent issue with Soft Proofing in Affinity Photo, but first a little background; I am looking to switch from Adobe products and Affinity Photo will be taking over the role Photoshop has played so far in my workflow, and so far so good.
Then recently I was contacted by a client that wishes to purchase a print of one of my photos. This is the first time I am making a large size print for a client so I am doing this via a gallery print lab (I have done printing on my home printer before so I know the basics of Soft Proofing, however it’s a home printer Epson XP-235 so no ICC profiles for that consumer model). So I though this is the perfect time to test out the soft proofing in Affinity Photo.
However I am getting very strange, and what I assume are incorrect results out of Affinity Photo.
The colour space required by the lab is sRGB and a TIF file with a DPI of 300 which will be printed on Hahnemüehle Photo Rag and are soft proofing using the ICC profile for the given paper and printer at the gallery, so far so good or so I thought.
What first got me thinking something was off was when I changed rendering intent, in Affinity Photo and there was little to no difference between any of the intents and huge amount of out of gamut colour.
So I went back to Lightroom and sure enough in Lightroom there was far from the same amount of clipping using the same ICC profile and rending intent. Hence I opened the file in Photoshop and here results were the same as Lightroom’s rendering intents (relative and perceptual), while Absolute matches what I see in Affinity Photo.
I would have assumed since I use the same file with the same colour space and the same ICC profile on the same computer the results should be the same, unless one software is interpreting colours and the ICC profile differently which in that case begs the question;
which is closest to the truth?
Or is this a bug in Affinity Photo’s soft proof adjustment layer?(And yes I know that soft proof will never match the true to life print, however I like to get an as close to the print rendition as possible, but I now have a very hard time trustingt what I am seeing in Affinity Photo).
Pictures speak louder than words, so here is a chart detailing the results I am seeing and as you can see it's a huge difference.
Hope someone can answer this or if I am missing something in the workflow.
Software versions:
Affinity Photo: 1.6.7
Photoshop: CC 19.1.5
Lightroom: 6.14 standaloneThanks.
Unexpected behaviour from soft proof adjustment layer
in Pre-V2 Archive of Affinity on Desktop Questions (macOS and Windows)
Posted
@stokerg thanks for you response. I also got a response from your colleague @JFisher on my post in the Bug section. I am happy to hear this is being investigated so we move forward