Again, you’re correct.
I simply had opened both preview images in ColorSync-Utility and within this app, both have sRGB assigned. But obviously, this assignment is made by ColorSync-Util itself. (lesson learned: always use PS).
@owenr, @R C-R,
Can verify, that AP either *assignes* or *converts* unprofiled jpgs to a) the set RGB color profile or b) sRGB, based on what the user sets in the application’s preferences.
With unprofiled png however, AP *always assigns* the RGB Colour Profile set in Preferences, no matter if „Convert” is checked or not.
(At least, that’s the behaviour I’m experiencing here on OSX 10.11.6).
These behaviours -in my eyes- are unwanted, as the user has no chance to intervene.
(And I haven’t checked the behaviour for unprofiled tifs…)
Say, a jpeg file originates in AdobeRGB but does not have an embedded profile.
If AP is set to sRGB (or conversion is turned off), the file would open with wrong colours, as sRGB would be assumed as the source colour space.
If AP is set to convert, then the application would do this error possibly twice: first, it would wrongly assume sRGB as colour space and then would do a conversion to i.e. AdobeRGB or ProPhotoRGB based on these wrong colours.
Profile Warnings btw now seem to me pretty random. During my tests, I was experiencing all sorts of combinations with/without warnings either on jpg or png.
(But probably AP just does not like when preferences are switched that often, even if the application is closed in between).
@ Jose A:
Hardware calibration: the measured color values from the colorimeter are written into the LUT of the monitor.
On OSX, you can switch between different hardware calibrated profiles either by the buttons on the monitor or via OSX System Preferences.
I do not know, how this is exactly handled on Windows though.
Software calibration: An icc profile is generated and used on System Level to overwrite the GPU’s color rendering. Depending on the monitor used and its capabilities (i.e. whitepoint setting, R-G-B sliders available or not), this leads to more or less good, but always reduced colour rendition (due to whitepoint setting). It’s the only way available on most displays.
As far as I understood, your monitor is actually used with the default factory profiles. This cannot be seen as hardware calibrated, as long as these profiles aren’t verified with a colorimeter. At least during the next 2-3 months, colours will have changed.
>>> Your issue with sRGB:
I’m wondering if this is probably an actual limitation of the Windows version of AP?
On OSX, it’s possible to choose any installed icc profile as the document’s colour space right from the beginning. I’m actually asking myself, if your way can result in correct colours as you are switching from a smaller to a wider colour space. If colours would already be present in the file, these colours would be desaturated that way. But I have to admit that I don’t know what actually happens to an empty file.
>>> ProPhotoRGB
Adobe choses that Colour Space as it is wide enough to contain every colour that a camera can produce and will ever produce in the future. This is the reason, why they left their own AdobeRGB. Working right from the beginning in ProPhoto is a good way, but one has to be aware that one most likely needs to reduce to a smaller Gamut on export, depending on the output target.
If you convert a sRGB file into ProPhotoRGB, you can do more destructive work on that file. It’s similar as converting from 8-bit into 32-bit. You don’t get more information into the file, you can just destruct it more.
>>> Rendering intents are especially important when converting from RGB to CMYK for print.
(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.
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).
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.
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.
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.
Jose A got a reaction from pruus in Color management