Color management

[anon1]

yeah know that, honestly I was just too lazy to try and was not aware that this happens with every such image (thought it required some special image)

 

anyway, good to know it is sorted now 

[R C-R]

@MBd If you want, try the attached Apollo.jpg as a test file. It comes from a very old technical paper about the components used in the UMAX SuperMac S900, a Mac clone sold circa 1996-1997. I have one of those towers stored away somewhere in the attic, & (if memory serves) this jpeg file was one of many in that computer's System 8 style help "book."

 

As far as I know, none of those images ever had an embedded color profile to begin with.

[R C-R]

For some reason, the jpeg won't attach, so hopefully this zipped version will...Apollo.jpg.zip

[Jose A]

On 17/09/2017 at 11:52 PM, Roger Simon said:

>> 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.

Hello again,

I am currently on a work trip and have very limited free time.

 

In relation to the monitor and what I mean by hardware calibration, because it is different than what you described, as what you described is what I would call software calibration.
I will give a general definition of both and then a kind of example.

 

Hardware calibration: Signal from computer to monitor is standardized, independent from computer, OS, etc, which is defined by the standard ICC profile and the monitor itself applies a correction curve.

Software calibration: Signal from computer is first adjusted, by software, in accordance to the calibrated/modified ICC profile, and monitor takes values "as is", i. e. just displays those values. This kind of calibration requires the computer to have the specific corrected ICC profile for the monitor as it needs to be applied to the OS.

 

My monitor is capable, of course, of both types of calibration. However, at the moment it is still only running on the hardware calibration mode.

 

What is the actual difference between both.

Imagine that I have an image that should be displayed with sRGB and it is just an RGB signal of 50 70 90 in 8bit, which is a very well defined point in the L*a*b space. The calibration type you described above, is a software type of calibration, what happens is that the computer has a modified ICC profile installed, which was calculated from the data the colorimeter software gathered. This means that the modified sRGB profile takes the value 50 70 90 and converts it to the values your monitor needs to display the color defined in the sRGB as 50 70 90. Lets say this is for your monitor 45 72 96. Your OS will do this change and send this value to your monitor, so your monitor gets a signal which is 45 72 96, and it will display the 50 70 90 of the sRGB profile.

In a hardware calibration though, what happens is that the ICC profile is not changed, there is no correction to any RGB point. So the OS just uses the standard ICC profile and sends to the monitor 50 70 90. Now with hardware calibration, the monitor knows, as it has the calibration curves installed in its own memory that when it gets a value of 50 70 90, it needs to display 45 72 96 of its own rgb scale, and in the end the displayed color is exactly the same as the sRGB of 50 70 90.

 

In both cases the display is giving 45 72 96 to its pixels, but in one case (software) the conversion is done in OS (software) level and in the other it is done in the monitor (hardware) itself.

 

What my monitor can do, is use a supported colorimeter, and a specialzed software to upload the correction curves to the monitor. Like this I could change computers easily without needing to carry around, or have an icc profile in a cloud. Whichever computer I connect my monitor to, I know I can get a calibrated image. I can of course still do a standard (software) calibration, just using the xrite/spyder/whichever colorimeter I would choose and create a modified ICC profile.

 

I hope I was I clear enough... I don't know, I am a physicist and this seems quite straightfoward to me, but I would understand if someone would find this quite confusing if not used to stuff like this. Just tell me if you think you got it, and I can try and make a better analogy if needed.

This type of calibration of course is independent of OS, if you have a monitor capable of hardware calibration, which there aren't many.

 

On 17/09/2017 at 11:52 PM, Roger Simon said:

>> 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.

 

I know and I understand this. What seems weird for me is that when I go to the dialog this seems to change/set itself back to sRGB when I do not want that. Besides, if I start a new document from a fresh start from AP, and I want that documento to have an adobeRGB profile I need to do this:

New document->choose sRGB (I cannot choose any other profile at the new document dialog)->create document->File: import ICC profile (import adobeRGB)->Document: Convert documento to adobeRGB.
While supposedly, after importing an ICC profile it should be possible to select one at all times (e. g. at the start of a new document).

 

On 17/09/2017 at 11:52 PM, Roger Simon said:

>> 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.

Yes, I knew all this and I also agree with you regarding the color picker.

 

On 17/09/2017 at 11:52 PM, Roger Simon said:

Btw, you did install/update the monitor’s driver to the Benq driver in Windows?

I thought of this and I tried to find an actual driver from Benq but I wasnt able to do it. I am not even sure I found the driver (I found a driver but it seemed that it was a driver for something else regarding the monitor, not the monitor itself).

 

On 17/09/2017 at 11:52 PM, Roger Simon said:

>> 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).

This is true, but it is not me who sets the default working space to ProPhoto....adobe does, by making it their default working color space. I do understand that you in "theory" do not need to supposedly convert lower gamuts to higher gamuts, but if you do, then you are able to do more manipulation and pull data from the lower gamut, which is smaller than the human eye can see, to higher gamuts where the human eye can still perceive them and printers are also able to actually print. It kind of makes sense to me, as you can make more realistic (and as well irrealistic) photos. My camera cannot access some gamut, but I was there in location and I for example know that the cyan was way more cyan than my monitor/gamut can display, then being able to pull the data from a lower gamut to a higher one makes sense.

 

Rendering intent should not change a pixel value, should only change the way it is displayed, and there I can agree that if it is not standardized it may display things slight differently. And rounding errors from lets say adobeRBG to ProPhoto makes no sense to me if its more than 1 for an 8 bit scale (as it is in the differences I see between AP and LR. I would accept values which would be X±1, but not more). This is simply because adobeRGB with certain illuminant are very well defined in the L*a*b color space for a certain illuminant. Therefore there are no significant rounding errors. There should be only one way to do it. Maybe I am underestimating how easy/hard it is, but from what I understand L*a*b space are very well defined quantities and the points of the adobeRGB/sRGB/ProPhotoRGB are also well definied in this space, there should be no wiggle room.

[Roger Simon]

@owenr

Quote

Sorry, but that's not correct. This forum's smaller preview images are not conversions to sRGB. The original file's profile is simply discarded.

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.

[Jose A]

@Roger Simon

Hey again.

Now I understand! From your description it seemed to me that Mac's would only support the software type of calibration, but being them good monitors, and a good integration of color management in the OS level, make it quite an effortless thing to change between profiles. And although I know that at the moment I might have some deviations from the proper profiles (the colorimeter is on its way) I still would regard my monitor as calibrated, as it is closer to a correct representation of sRGB and adobeRGB than 99% of the monitors out there. I wonder if the changes will be noticeable at all when I do a recalibration. It does not change the fact that something wrong is happening when it comes to color management between AP, windows and other apps.

 

On 9/20/2017 at 2:04 AM, Roger Simon said:

>>> 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.

I do not understand how this can happen, unless if you keep the number of bits of the file. But as usually sRGB is in 8 bit and ProPhoto in 16 (I mean, if you keep using 8 bit scales on a ProPhoto colorspace...i mean...that makes no sense) you never destroy any information. Apart from maybe some really, really really small correction term, which in the end it does not matter either way because a space divided into 256 just has such a big step between adjacent values. I tried to find relative volumes of ProPhoto and sRGB but I couldnt find any kind of easy answer, but the "average maximum" correction term would be (2^-8)(Prophoto_volume/sRGB_volume)^1/3. In other words the correction term would be how many times bigger ProPhoto is than sRGB then divided by 256 (in terms of ProPhoto color space). This would be quite a small number. Now going from adobeRGB 16 bit to ProPhoto 16 bit then yes I would understand if the colors would shift, but then due to how big the colorspaces are and due to the really small stepping, I guess this shift would probably be imperceptible.

 

And yes I am aware that the rendering intents are important in that case. I will soon print a couple of pictures and will have to do some soft proofing .

 

Thanks again for all the input everyone! I am deeply appreciated by this. However I still think that I need someone from Serif to chime in!

[R C-R]

2 hours ago, Jose A said:

But as usually sRGB is in 8 bit and ProPhoto in 16 (I mean, if you keep using 8 bit scales on a ProPhoto colorspace...i mean...that makes no sense) you never destroy any information.

As long as you don't export the file opened in Affinity to some other file format or reduce a higher bit depth file to a lower one, it should not destroy any color information. This should be true whether or not the file has an embedded color profile or if you assign or convert one to the file.

 

After all, a color profile is just metadata that indicates how the pixel data in the file should be rendered.