Color Management topic and article

Color management is still an obscure and difficult topic for many people working with digital images. So Patrick and myself have started to think about a possible article(s) centered on “Color management for photographers”, with the goal to explain the basic and not-so-basic concepts behind color management to people who are using photo retouching programs but have little or no knowledge of this very technical aspect of digital photography.

Do you have questions about color management (color spaces, icc profiles, gamma correction, etc…)? Ask them here, and help us organise the content of the article!

I’ll be drafting the article on GitHub, so that the progress can be easily previewed here.
EDIT: here is the link to the GitHub repository.

Anyone who is willing to contribute, with new text, proof-reading, corrections, sample pictures or whatever else might be relevant is warmly welcome!

@patdavid
P.S: I hope to have posted the topic in the most appropriate category, otherwise feel free to move it around

4 Likes

This looks like a perfect place for it to me! :slight_smile:

You may want to include a link to the repo in case anyone wanted to add to it and issue pull requests:

I’ve also just made some notes and issued a PR from my repo that you forked from. Just some thoughts around an introduction.

PR merged. I think I’ll start some real work on the article some time next week.

Thanks!

I edited the topic title and first post to make it a bit more general: not just an announcement for an article, but also a place for discussing and answering questions.

This sounds like a nice thing to have. I am looking forward to reading what you will come up with. :slight_smile:

2 Likes

A moment of zen (with a coffee in hand this cool morning - nothing makes me happier than feeling like the oppression of summer is finally beginning to break in favor of fall weather).

Talking with @houz and pmjdebruijn this morning. Pascal made good point

pmjdebruijn: @colorspaces though, unless people thoroughly understand the topic, they really should stick with sRGB regardless of any benefits
pmjdebruijn: using non-sRGB-colorspaces and not understand CM leads to much pain and suffering

So I would, when considering the article breakdown, consider some aspects of reader expectations.

When/Why would(/should) a user deviate from an sRGB workflow?
What is the benefit of doing so?

Can we demonstrate a good/best practices managed sRGB workflow first? I am guessing that the majority of users will be aiming for online distribution of images (sRGB is the target colorspace).

If there’s a deeper explanation needed, I think it should always be given within the context of the current topic and level of understanding. For example, if it makes more sense to work in a different colorspace, mention it possibly when talking about an sRGB workflow, but defer deeper explanations until a more appropriate time.

It also probably makes sense to build the topic up from simple, basic blocks of understanding. This helps a reader build up their confidence in understanding the material before moving on (and if structured this way correctly a reader won’t even notice this is happening - just that they get it.).

More to come…

Hi Folks,
I think to had understood quite about monitor color management but I have still some doubts. I try to explain what I know (or what I think to know:roll_eyes: ) and what I still don’t understand… OK…

  1. Actually LCD monitors could be linear but they are made with native “perceptual” gamma of 2.2-2.4 for back compatibility. In this way if I download an image from internet which is gamma corrected I display it correctly even I haven’t color management.

  2. Because this gamma could not be precise I have to “calibrate” the monitor. I create therefore a gamma corrected table … the vcgt table. These values will be loaded into LUT monitor. At this point I have a established gamma I want.

  3. Then I create some tables with values which tell me how a device behave.

  4. All things above are tagged into an ICC profile.

OK, when the system boots someone, could be Argyll dispwin command loads vcgt table values into the monitor LUT. Then graphic color managed softwares ( Gimp, Rawtherapee ans so on…) will use those tables (in effect the CM will) to translate color numbers of an image into values to send the Video graphic card.

I read there are CM software which works at OS level as Oyranos… What do they works? If I install and configure Oyranos how Gimp, Rawtherapee have to be set about color management?

Cheers
Gabriele

No. Everything is correct except this part. The VCGT is in the GPU, so everything on that monitor is changed, doesn’t matter whether it comes from RT or notepad.exe.

All color-managed programs must use the monitor profile. How do they find it? Either by checking the _ICC_PROFILE X11 atom, or by querying a color management daemon such as colord or oyranos.

I tried Oyranos every ~3 years in KDE. Tried it again last week. Still doesn’t work correctly. I’m told colord works, but haven’t tried it because I don’t need it (neither does RawTherapee).

Hi Morgan,
thanks for the quickly reply :slightly_smiling_face:

Ok, I intended GPU… I know accessible luts are into high level monitor ( my brother have one ) …

Who does set _ICC_PROFILE atom? Can do dispwin -dx -I?
Do software as colord or Oyranos set the X11 atom?
When I set display profile into Gimp and Rawtherapee they do not search X11 atom, do not they?

I installed Oyranos to install iccexamin to view icc profiles… Does it bother X11 atom if it isn’t set?

Indeed, some monitors allow to set such a LUT in the monitor directly. When that is done the display profile has either no VCGT or a linear one to not double correct the image.

Yes, and yes. Both dispwin as well as colord do set the X atom. I suppose Oyranos does the same but I don’t know for sure. Please keep in mind that at least colord only sets the X atom for the primary monitor. If you have several monitors connected you have to take care and double check that the right profile is picked up by the programs using it.

When setting a profile manually most programs use that. The X atom (or colord) are only queried when there is no explicit profile set in the program.

Gamma correction was not added to match the human visual system, it was a native issue with CRT display drivers. It just happened that it was quite a good match.

There needs to be something about viewing environments - the signal when displayed on a calibrated monitor is only correct under a single viewing condition. ITU-R BT.2100 and ICCmax both try to transform to none reference conditions.

With the proliferation of capture profiles and screen types, you probably need to explain how systems like ICC, ACES etc. attempt to manage colours.