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

Recommended Posts

Hello everyone,

I currently own a monitor which is used for color management, but unfortunately I am still very confused on how everything works. I read so many articles, etc., and I still don't feel that things are clear to me, mainly because when I try to experiment with these things I get mixed results.

 

My monitor is capable of 99% adobeRGB and I set it in windows to always use adobeRGB.

 

My concern is that the colours I see in Affinity photo differ quite a lot to those I see in lightroom (I use a standalone version of lightroom to do cataloging and some pre-editing).
 

I read that lightroom used ProPhoto RGB as its main icc profile for the develop module. Well, I set the "RGB color profile" in the AP's color profiles as the same (I downloaded it from the icc website).

 

Nonetheless the colors are still different. Is this somehow a conversion from the higher gamut ProPhoto RGB to adobe RGB (screen's icc profile) that uses different engines and therefore the colours are different?

What are the steps between the photo's RGB values->screen when in AP?

 

I need guidance or someone to really dumb down the information and feed it to me, because I am very confused with this ordeal.

 

Thanks for anyone's time, all the best,

-JA

Link to comment
Share on other sites

Actually this is probably not a color management problem (as you can see on the attached screenshots).

 

1. AP keeps on changing the to default color workspace (it does not matter if I select ProPhoto as work profile) after restarting AP it gets back to sRGB

 

2.The colours are indeed different.

 

As you can see from this zoomed in image, the image on the right was generated by lightroom and directly opened in AP, after being sure that I chose ProPhoto RGB (as I say above, during that session, as if I restart AP it will get back to sRGB) as work space.

 

However, the two images are showing completely different renders of the same image in terms of colours.

 

The pixel that I chose was one easy to identify, and in LR it read R: 24,0%; G: 24,7%; B: 14,8%. This would correspond in an 8 bit (as the one shown in AP) as R=69, G=63, B=38.

However in AP the pixel values are R=64, G=55, B=33.

 

I also find that whichever deep shadows I can see in Lightroom, will be basically black in AP.

 

I would like to understand what is the problem and if I am doing something wrong.

 

All the best,

-JA

 

screen_1.png

screen_2.png

Link to comment
Share on other sites

Hello Jose A,

 

unfortunately, I’m no expert regarding colour management on Windows.

From what you are describing and from the look of your screenshots however, it seems to me that AP might be rendering the image onscreen in sRGB, while it might render correctly in LR.

Afaik, Windows has sRGB deeply integrated into the OS, so the solution could lie in the colour settings on the OS level.

AP probably uses this information while LR has its own solution.

 

If your monitor is calibrated, you need to make sure, that Windows uses this profile for onscreen display.

(My only experience here was during Windows Vista, which was a true nightmare regarding colour management on OS level and very hard to understand for someone that worked on MacOS ever since).

 

Did you verify that your file has a colour space tagged to it?

Because AP automatically applies the RGB colour profile from the App’s Preferences to untagged files without enquiry.

 

Sorry for being no big help here, but hopefully there is at least some information that gives you some input to continue to get closer to a solution.

Link to comment
Share on other sites

1 hour ago, Roger Simon said:

unfortunately, I’m no expert regarding colour management on Windows.

From what you are describing and from the look of your screenshots however, it seems to me that AP might be rendering the image onscreen in sRGB, while it might render correctly in LR.

Afaik, Windows has sRGB deeply integrated into the OS, so the solution could lie in the colour settings on the OS level.

AP probably uses this information while LR has its own solution.

Hey,

Thanks, I hope I did change the profile of the OS, at least I tried, and on the color management window it seems that adobeRGB is my default icc profile. My monitor is hardware calibrated, so I just need to use the profile directly at the OS. Now, if windows is truly respecting my choice is hard to say, I guess I will do a small test using a 0 255 0 field and set my monitor to sRGB and see if I see a difference when I change the profiles between sRGB and AdobeRGB in the windows dialogues.

Quote

 

Did you verify that your file has a colour space tagged to it?

Because AP automatically applies the RGB colour profile from the App’s Preferences to untagged files without enquiry.

 

In the screenshots you can also see that yes they have the 16bit  ProPhotoRGB as the file's icc profile. (top left corner). At least I understand that the small dialog there means in which color workspace I currently am.

 

56 minutes ago, dcarvalho84 said:

Hello @Jose A

Have you tried one soft proof adjustment layer?

Also on the Document menu you have the ability to assign or convert ICC profile option.

Don't know if that helps but it might worth looking.

No, I still did not try that, but I want to do some more tests tonight and I will try that as well, thanks!!

Link to comment
Share on other sites

Hello Jose A,

 

from re-reading your posts above, I try to recap your settings:

 

-You have Windows set to AdobeRGB on OS level.

(Wouldn’t you need to set your calibrated monitor’s profile here? This is the way it works on OSX/MacOS. The calibration software should offer this profile to the OS).

 

-You develop in LR (using ProPhotoRGB) and then open up in AP (RGB Colour Profile set to ProPhotoRGB in Applicaton’s Prefs).

 

From your screenshots, it seems that LR is embedding ProPhotoRGB into the exported images and AP reads that profile.

(You would notice a different Profile in the document window, if i.e. AdobeRGB or sRGB would be embedded, as AP would then read one of these profiles instead appliying ProPhotoRGB).

[I was wondering why you would need to download the ProPhoto profile, but this might be down to differences in Windows and OSX/MacOS colour management].

Just as an assumption: if LR would export without embedded profile, AP would automatically assign ProPhotoRGB, even if you had worked in a different colour space in LR. That would lead to false colours.

 

ProPhotoRGB has theoretical advantages as a working colour space as it is simply extremely wide and data will never be clipped by this colour space.

(In practice, you are down to AdobeRGB, just because this is about the maximum that you will ever see onscreen. A further limitation would be the colour space available i.e. within the colour settings of your camera. Most are limited to sRGB, higher quality cameras support AdobeRGB, some work with true 16-bit colour depth.

But no camera is able to fully use ProPhotoRGB, and no monitor is able to represent that colour space).

 

Quote

In the screenshots you can also see that yes they have the 16bit  ProPhotoRGB as the file's icc profile. (top left corner). At least I understand that the small dialog there means in which color workspace I currently am.

 

This is generally correct, it reflects the actual embedded colour profile of the opened file. [except: untagged file issue]

(If you open an image with embedded sRGB profile, sRGB will be shown regardless of your Preference settings).

 

Your idea with the different colour conversions is also correct, so I’m assuming that you already have verified, that your Export settings in LR match your colour settings in AP (i.e. Rendering Intent).

 

As long as no Affinity developer joins this thread, I would advise you to send in a bug report on that issue, so that you most likely will get help directly from the development team.

Link to comment
Share on other sites

Hey guys,

Thanks again for your comments and suggestions. Unfortunately in the end last wednesday I was not able to be home and do the testing. Tonight I will have time for sure though and I will do lots of tests, the ones suggested here and some others I thought of.

 

On 9/14/2017 at 11:20 AM, Roger Simon said:

-You have Windows set to AdobeRGB on OS level.

(Wouldn’t you need to set your calibrated monitor’s profile here? This is the way it works on OSX/MacOS. The calibration software should offer this profile to the OS).

 

 

The way I understand my monitor (Benq SW2700pt), the calibration is in the monitor itself. I can either do it "old style" with a colorimeter and correct the .icc profile, or use a colorimeter that is supported by the monitor and use a software to communicate with/calibrate the hardware instead (so, instead of correcting the .icc profile, I can keep windows on adobeRGB and the monitor knows that for example for an input for pixel X of (110,110,110) it needs to output (108,110,111) at pixel X for example). I have both possibilities. Although I still do not have a colorimeter, I am in the process of getting one, but the monitor comes factory calibrated, with a spec sheet and I did not use it for more than 60 hours I would guess. But soon I will be able to regularly calibrate it.

 

On 9/14/2017 at 11:20 AM, Roger Simon said:

-You develop in LR (using ProPhotoRGB) and then open up in AP (RGB Colour Profile set to ProPhotoRGB in Applicaton’s Prefs).

 

From your screenshots, it seems that LR is embedding ProPhotoRGB into the exported images and AP reads that profile.

(You would notice a different Profile in the document window, if i.e. AdobeRGB or sRGB would be embedded, as AP would then read one of these profiles instead appliying ProPhotoRGB).

[I was wondering why you would need to download the ProPhoto profile, but this might be down to differences in Windows and OSX/MacOS colour management].

Just as an assumption: if LR would export without embedded profile, AP would automatically assign ProPhotoRGB, even if you had worked in a different colour space in LR. That would lead to false colours.

You are correct in the assumption although I must point out 2 things:

1-I downloaded the profile from the ICC website because I wasnt aware at the time that LR was embedding the profile itself, although in the export options it was selected as the export profile (it could have been that it used the profile to encode the image, but would not embed the profile itself). Later I realized that LR is indeed embedding the profile and AP is actually using the embedded profile and not the one I downloaded, because they have different names. The one from LR just ProPhotoRGB and the one from ICC is called ROMM RGB.

 

2-AP only allows me to select a work RGB profile if I have a document opened, and at that point I can select between the default sRGB profile, the profiles I have in the past imported into AP (although I must say that the list of the icc's I imported is random. For example, right at the beginning I imported both adobe RGB and the ProPhoto from the ICC website, and sometimes only adobeRGB appears, sometimes only ProPhoto, sometimes both, sometimes none. Whenever I open AP and go directly to the color profile tab in the settings, the work space is always sRGB and I cannot choose any other profile if I do not open a document. So I still do not know what will happen when I open a document without an assigned icc profile, and this is one of the tests I will do.

 

On 9/14/2017 at 11:20 AM, Roger Simon said:

ProPhotoRGB has theoretical advantages as a working colour space as it is simply extremely wide and data will never be clipped by this colour space.

(In practice, you are down to AdobeRGB, just because this is about the maximum that you will ever see onscreen. A further limitation would be the colour space available i.e. within the colour settings of your camera. Most are limited to sRGB, higher quality cameras support AdobeRGB, some work with true 16-bit colour depth.

But no camera is able to fully use ProPhotoRGB, and no monitor is able to represent that colour space).

I am aware of this, and I own a sony alpha 6000 which has a 14 bit depth for adobeRGB (in which I shoot). I am in the process of choosing whether to post process always in ProPhoto, to be able to take full advantage of the color space, even in the future, but complicate the softproofing either for the web or printing, or if to just do everything in AdobeRGB to simplify softproofing and to know that I will have displayed either on the web (if someone used of course a calibrated adobeRGB monitor) or on a print the same I see on my monitor, without having to think that there will be more or less colours in prints for example.

 

  

On 9/14/2017 at 11:20 AM, Roger Simon said:

Your idea with the different colour conversions is also correct, so I’m assuming that you already have verified, that your Export settings in LR match your colour settings in AP (i.e. Rendering Intent).

 

Unfortunately I did not find any tab on LR to change the rendering intent. The only place I can change between just perceptual or relative intents is in a softproofing dialog of LR. I am now thinking that maybe this is the case, but changing intents should not change pixel values, as I understand, it should only change how the image is being displayed while going from the bigger color space of ProPhotoRGB to the lower spaces of the monitors. I would guess, but maybe I am wrong, that LR uses a relative intent to display the ProPhoto file, I want to test this further, as I tried with an actual photo doing some green saturation, etc. but I want to try with "fake" images filled with these color gradients (I do not know their names) and see if it keeps the gradation or if it clips the most saturated greens.

What I also do not understand, if the working space if for example ProPhoto, why are pixel values given in 8 bit depth in AP. Actually even if I would be working in any 16 bit depth work space. In LR at least it appears in percentage, which then makes sense. 

 

19 hours ago, Leigh said:

Hi Jose A, I will speak with our QA/Devs to see what I can find out. I'll try and reply ASAP.

Thank you Leigh, I really appreciate it. I also hope that my tests of tonight will help to understand where the mistake is, if mine, or somewhere else. I still think I might have done something wrong somewhere. I also do not understand the full talk between computer<->graphics card<->monitor, if they ever exchange which profile is being used or not. I also do not know as of now if my monitor is working with 10bit depth or 8, because it can use 10, but I think my HDMI cable does not support 10 bit (I do not know which version of the HDMI cable I have, as at the beginning I was connecting the HDMI to my old laptop and my laptop only has an HDMI slot, and I kept it for the new desktop I have). I will exchange it for the DisplayPort that came with the monitor which I hope should support 10 bit color depth. Then I will need to figure out what the graphics card will do, as supposedly it does support 10 bit depth, but from forums it seems that nVidia does not make it easy to set, I will see.

 

Once again, thanks for all of you who chimed in, I am truly appreciated.

-JA

Link to comment
Share on other sites

(EDIT: I did not know that the pictures would not keep the filenames. The first picture is called "experiment-1.jpg" and the second is called  "experiment-1-2.jpg". If you open them with a widegamut monitor and with a computer which manages colors/browser, you can see that -1.jpg renders as sRGB, even if the preview in the bottom is (to me in chrome) adobeRGB and the second renders just like the preview, in adobeRGB. The bottom 3 pictures are self explanatory when reading the text)

 

Ok,

I did a lot of tests, lot of tries with different things, I guess this will be a long answer, but even so I dont think I will cover everything I saw.

 

First off, talk about my monitor. (Monitor talk I) So, I am still not entirely sure whether my OS is in adobeRGB or not. It is not easy to say if it is, but, I would assume it is, because of one of the tests. Although, most of it is in sRGB, but it does not comunicate that to anything else (by anything else, I mean graphics card and monitor), it seems that they do not transfer this kind of data. My monitor always assumes that whatever comes to it is in adobeRGB. So, when I see an sRGB file which is just displayed as is, whithout taking into account that I had set up the OS to adobeRGB and needed the conversion, I just see it super saturated.

 

So, it seems that everything is hyper saturated in my OS. I noticed it right when I first turned it on when I bought it, but back then I knew I would have to do some color management and since then I got convinced that everything is ok. But it seems that things are much harder than what I thought.

 

So, the first thing I did was to create the "experiment-1.jpg" file in AP. There the greens are just from 255 down to 36 in steps of 36. The cyans are 0 255 255, 0 255 230 and 0 230 255. The document was done in adobeRGB. I proceeded to export it with embedded .icc profiles. the "experiment-1.jpg" with sRGB and "experiment-1-2.jpg" with adobeRGB. Checking them in "windows fotos" seems that the app ignores .icc profiles, however, I found out that "windows photo viewer" does not. With windows photo viewer I was able to correctly display the images. I was also not thinking it was real, because I was now used to the hyper saturated greens and it seemed that the green was too flat/yellowish. But after using my phone with an image of 0 255 0 as a reference I noticed it was correct. So, this allowed me to conclude that somewhere, Windows is indeed knowing it should be in adobeRGB, and this application knew about this and did the conversion.

 

 

Monitor talk II - My monitor has a fast switch to change between 3 custom profiles. As default they come as adobeRGB, sRGB and B&W. this is not important, but I switched the B&W for a night mode, low brightness, less blues mode. Either way, I found out, by this images, that the monitor always assumes an adobeRGB input and when I switch to sRGB it does the conversion internally to display sRGB. This is how it seems to me, because when I view the same images but with the sRGB mode on, the pic with the sRGB profile gets even less saturated, and the one with the adobeRGB is correctly displayed.

 

Continuing with the tests I made.

 

Then I did a lot of testing with real images and some test images from another thread (

)

 

What I saw is that LR also manages color. As I import the "experiment-1..." jpegs I see that they are different. But unfortunately, as with the rest of most things with the OS, AP shows the same image, be it the sRGB one, or the adobeRGB one.

 

Then I tried to export the same photo (now a real photo, which I had done some editing in LR and from which I created a tif file and did not temper with) both with LR and  AP. Here I got some weird results. So first I did some adobeRGB export and loaded it into AP. It showed correctly that the color space was adobeRGB but immediately the colors were different from LR. I then proceeded to export the image as .jpg with embedded adobeRGB and did the same in LR to compare exports in an external viewer. Weirdly, I had mixed results in the sense that the exported versions were exactly the same, but the colors did not seem to match neither AP or LR in "windows fotos". But it seemed much much closer to AP than to LR. It can also be that then, as I did not have neutral colors everywhere and my color perception was slightly different when looking to one photo on the left side and the other on the right side. It seemed that switching the viewers around was switching the color difference (i. e. the "warmer" picture always was the one on the left side, regardless if it was AP-left, windows fotos-right or vice-versa). So I would prefer to assume that although they seemed different, my color perception was being altered by the inhomogenous and strong color separation within the photo (was looking at some red mountains and blue sky). However, in the color managed windows photos, the colors now also did not seem to match, but were much closer to LR (i. e. they were quite different from AP).

 

The tests with ProPhoto just showed what I had already seen above which was that the pixel values are changed, as they should be (not meaning that its being done to the correct ones). So, if I then used "experiment-1-2.jpg" and converted it to ProPhoto, both LR and AP do change the pixel values, albeit to different ones, as seen above. So, the before 0 255 0 from adobeRGB was now 138 237 78 (edit, read ahead) in AP and in LR 37.1% 92.3% 30.1%, which in 8 bit is 95 235 77, which is a huge difference in the red channel specially. Also strange is that if I instead export the LR file with the embedded ProPhoto and load it in AP, now AP reads 77 230 60... (you can see the 3 cases in the attached pics) (EDIT: I realized now that I made a mistake and loaded "experiment-1.jpg" into AP and then did the conversion, so from sRGB to ProPhoto and not from adobeRGB to ProPhoto. By loading the correct file "experiment-1-2.jpg", I get 76 230 60, which complies with the exported version from LR and loaded into AP).

 

What this is telling me is that somehow AP renders everything as sRGB (as proof of the experiment-1.jpg which has an sRGB as embedded profile, but renders the same as a pure adobeRGB), but of course, as I said above, my monitor takes that whatever is being given to it is adobeRGB and hence the color discrepancies. Then, as it does not take into account the differences between sRGB and adobeRGB the conversion to ProPhoto goes a bit off, as well as then the rendering.

 

I did some other tests in between, but the ones that really got me thinking were some with gradients. I wanted to see the effects of render intents.

First I did a conical gradient where I went like 255 255 0 - 0 255 0 - 0 255 255 - 0 0 255 - 255 0 255 - 255 0 0 - 255 255 0. Somehow this whole gradient is out of gamut for both sRGB and adobeRGB according to the soft proof. However I was still seeing the colors even if I chose relative colorimetric (which is ok, I would just be seeing all the saturated colors) and then if I chose perceptual there was just a tiny small change in the render (now I cannot really remember if it was changing the intents or changing the target space). Either way, I was expecting that if I switched to perceptual I might have a bigger difference in display of the colors as all the colors would be compressed into the gamut.

But even more impressive and here I definitely expected to see a difference was with a linear gradient only in the green, while having the soft proof showing when I would be starting to clip adobeRGB, and it seems that at a value of 0 14 0, AP tells me that I am clipping adobeRGB (it might be true, I do not know, but this tells a lot about how huge ProPhoto is). Then I did a linear gradient across my whole document from 0 10 0 to 0 16 0 and changing intents did nothing. I was expecting to see saturated greens in a relative colorimetric intent (as from what I understand out of gamut colors are just represented as saturated colours, instead of compressing the color space into the target space as in perceptual). Maybe the color transformation is done instead in LAB and it preserves part of the L in a LAB space and this is why the whole thing stayed so dark (I was naively thinking I would see bright greens).

 

Oh well, Its super late now, I took many hours today on this matter, I need to go to bed.

 

All the best

-JA

experiment-1.jpg

experiment-1-2.jpg

AP_color_picker_sat_green.jpg

LR_color_picker_sat_green.jpg

AP_color_picker_sat_green_after_LR_export.jpg

Link to comment
Share on other sites

Hello Jose A,

(sorry for my late reply)

 

>> monitor
Assuming, that color management on Windows is somewhat similar to OSX/macOS, using a hardware calibrated monitor should work as follows:
If you calibrate the monitor with a colorimeter, this will be done right on the monitor itself, thus hardware calibration, a profile will be created and set as the default monitor profile in System Preferences (=OS level).
In your case, as you haven’t done this calibration so far, there should be at least a default monitor profile that should have been installed by your monitor’s calibration software. (I’m assuming, that Benq is doing this the same way as EIZO or x-rite i.e.).

Whenever you re-calibrate your monitor, this profile will then be „updated” with your newest colorimeter readings.
If you calibrate for different targets, you will create new additional profiles or you will update pre-installed target profiles from the monitor’s calibration software.

 

>> AP RGB Color Profile in AP Preferences:
This will represent your main working RGB color space. Whenever you load an untagged image file, this profile will be assigned to that image. (This is a potentional source for false colours, as long as AP is not asking the user about what he/she wants to do. On my Mac, I’m never asked, no matter what I set in Preferences, AP just assigns the RGB Colour Profile and just shows a tiny window for a about one second to inform me about this assignment).

If you open a tagged/profiled image in AP, this profile will be read and respected. If you are working in colour aware environment, embedding and using files with embedded profiles is key.

So, if for whatever reason, AP sets its default RGB Colour Profile to sRGB, this should not influence your work, as long as you have files with profiles embedded.
If you haven’t embedded profiles, sRGB will be automatically assigned.

 

>> AdobeRGB, ProPhotoRGB, softproofing, web display
working in ProPhoto does give you the maximum possible quality, as you never have to fear that the set Colour Space will clip away some of your image’s colours.
For exporting, you will nevertheless mostly bring your images down to a smaller Colour Space. For print, you should be able to stay with ProPhoto or reduce to AdobeRGB. If the web is the output target, sRGB is the most secure way (eventhough the colour space is smaller) for getting comparable results.
Of course, correct profiles need to be embedded with the files.
Colour management in web browsers is a different topic though.

 

>> rendering intent
You’ll need to think about that whenever you reduce from a larger to a smaller Colour Space in conjunction with the output target. Gamut Mapping transforms from source to L*a*b* and then to target space. The appropriate rendering intent is needed to correctly map the colours that are outside of the target’s colour space to appropriate values depending on the output media.

 

>> color picker
This is something that I also do not understand. I think it is meant as a simplification for the user, but I do prefer the color picker in PS, which can be set to represent both 16-bit and 32-bit colour values.

 

>> Monitor
If the monitor is properly calibrated, images will be displayed according to their embedded profile (in colour aware applications).
Whenever you notice these extremely saturated colours, it is very likely that the application is not colour-aware or i.e. is unable to read the embedded colour profile.
The latter could be the case if i.e. an ICC v.4 profile is embedded, but the application is only able to read v.2 profiles.
Btw, you did install/update the monitor’s driver to the Benq driver in Windows?

 

>> „exp 1&2”
While generating the smaller preview images for uploaded pictures, these are converted to and profiled as sRGB.
That’s the reason, why both images look exactly the same even in a completely color-aware browser like Safari.
The original image files do display differently and they have AdobeRGB (2) and sRGB (1) embedded.
Differences can only be seen in color aware applications, such as PS, LR, AP, CaptureOne Pro etc.
Web-Browser compatibility could be checked here (if you haven’t already done):
http://www.color.org/version4html.xalter

 

>> Profile conversion
Just a reminder: there is actually no sense in converting an image from a smaller Gamut into a larger one (sRGB/AdobeRGB > ProPhotoRGB), as the colours of this image are already reduced.
A larger Gamut does not „add” more colours.
The different pixel values should originate in rounding errors and different rendering intents. (Rendering intents are not standardized, meaning that each company can do the math in slightly different ways).

Link to comment
Share on other sites

34 minutes ago, owenr said:

JPG has no profile: AP assigns sRGB regardless of the default working colour profile, and does not warn the user!

The latter is surely a bug which I've only just noticed and will report.

I cannot duplicate this on my system. I have tested with 6 un-profiled jpg files so far (I don't have that many) & several different defaults in preferences (Display P3, Adobe RGB (1998), HD 709-A, etc.) & each time I open one of these files, that profile is assigned & I get a warning about it.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

I have since my last post tested quite a few more un-profiled jpeg image files I found in various places on my system, including some that are over 15 years old from FreeHand MX help files, photograph samples included with an old Mac System 7 app called Color It!, texture files included with add-ons to an old 3D app called Infini-D, & various other old & newer sources. I am reasonably sure none of these test files has ever had an embedded color profile while on my Mac -- they are all as I originally obtained them from the source.

 

I always get a warning that persists for 4 seconds or so when I open any of them with Affinity Photo v 1.5.2 for Mac, & that app always uses the default color profile I have set in AP preferences, regardless of what it is. I also tested with the current AP customer beta for Mac, & with both the current retail & beta versions of Affinity Designer, & get similar results with all of them.

 

However, this is true only if in each app's Color Profile preferences, I have enabled these options:

59bf7ad07c912_colorprefs.png.ef43d3d4e0181b2d6157c70469bd5aba.png

and the current RGB Color Profile in the preferences is not set to sRGB (specifically, the sRGB IEC61966-2.1 profile installed on my Mac).

 

But if the profile is set to sRGB, then even with the above options set, there is no warning.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

12 minutes ago, owenr said:

If your non-profiled JPEG does happen to contain colours that were defined in sRGB, then no harm will be done. However, if your non-profiled JPEG contains pixel values that were defined in, for example, Adobe RGB, then the image will be converted from sRGB to default profile, which will create the wrong colours.

Unless I am missing something, if there is no color profile in the file, then there is no way to know what the "right" colors should be. Isn't that the purpose of including color profiles in image files to begin with?

 

The only bug I see in this is the failure to warn that an sRGB profile has been assigned to an un-profiled file when sRGB is set in preferences and the warning preference for that is checked. Users should be notified of that (if they have enabled the warning preference), but the only value in that is to let them know the file includes no information about what the "right" colors might be.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

43 minutes ago, owenr said:

Exactly - that lack of warning, despite the preference to receive the warning being set, is the bug I was talking about.

It seemed as though you were talking about a somewhat more serious, if related, bug:

 

12 hours ago, owenr said:

JPG has no profile: AP assigns sRGB regardless of the default working colour profile, and does not warn the user!

The latter is surely a bug which I've only just noticed and will report.

As I explained, I can duplicate this only if the default working color profile is sRGB. I do not understand why it is different for you.

 

I am also curious why you would not use the 'convert opened files to working space' & warn about that options if you are concerned about color accuracy.

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

55 minutes ago, owenr said:
3 hours ago, R C-R said:

It seemed as though you were talking about a somewhat more serious, if related, bug.

Here is what I initially said: "JPG has no profile: AP assigns sRGB regardless of the default working colour profile, and does not warn the user!"

The bolded part of what you said is what I cannot reproduce -- as I have said as clearly as I know how, that does not happen on my Mac unless (not regardless of) the default profile is set to sRGB. I am just trying to figure out why we get different results.

 

59 minutes ago, owenr said:

You don't get it, RCR. I want files to open into a document with the profile of the file so I get the ultimate accuracy for that file.

What I do not get about that is how to get maximal color accuracy if the document is not converted to the correct working space of the app. I am not sure what, in Affinity's nomenclature, the "working space" represents -- in the help topics it sometimes seems to mean what Affinity calls the "Color format" -- what generally is known as a "color space" -- & elsewhere in the help as the specific ICC color profile in that space.

 

As I am sure you know, maintaining "ultimate" color accuracy across all devices & color spaces is impossible -- they don't rely on the same color models & each type of device has its own gamut limitations different from the others -- but it is my understanding that one must work in the appropriate color space to get useful approximations. Is that wrong?

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

Link to comment
Share on other sites

@owenr if you have such an image without color profile which yields in an unnoticed assignment I can (try to) reproduce 

 

sounds like legit issue, not knowing if a profile got assigned despite a lack of profile information is definitely a concern 

 

I'll only set ""Warn when assigning profile to unprofiled files""

and see if Affinity warns me or if it just assigns something wild 

 

btw I assume that by "working space" they mean the default values for RGB/ CMYK etc. that one sets above in the window

// e.g. a CMYK doc without profile could be automatically converted to the chosen CMYK profile which is the "working space", if the checkbox is ticked 

 

cheers 

 

 

Link to comment
Share on other sites

16 minutes ago, MBd said:

I'll only set ""Warn when assigning profile to unprofiled files""

and see if Affinity warns me or if it just assigns something wild 

For me, this setting by itself apparently has no effect -- that is, even if it is unchecked & I open an un-profiled jpeg I still get a warning ... but only(?) if 'convert opened files to working space & warn' is also checked, and something other than sRGB is set to the default. O.o

 

I also noticed that the "and warn" checkbox stays highlighted & can be enabled or disabled independently of the convert to workspace setting it is indented below, which makes no sense to me -- if convert is not enabled what would there be to warn me about? O.o:S

 

This whole thing has made me so confused in several different ways that I have no idea how to unravel it all into anything that makes sense. :(

All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7

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.