Monitor profiles and deep shadow tonality

Yes, this is true in general, a brighter screen means the deep shadow detail has been made brighter, with a greater dynamic range, hence more detail.

This is a very important part of calibrating and profiling a monitor that I’ve been wrestling with: What cd/m^2 luminance (https://en.wikipedia.org/wiki/Luminance) and also what “color of monitor white” to calibrate the monitor to have:

  • On the one hand, the right monitor brightness depends on the brightness of the ambient light: it’s important to set the monitor brightness to more or less match the brightness of the ambient light. One’s eyes get very fatigued if the monitor is brighter than the ambient light.

  • On the other hand, most of us have some control over the ambient light - at least in my little corner of the den there is some nice full-spectrum halogen track lighting controlled by a dimmer switch, plus large windows with curtains that can be opened or closed. But this also means the brightness of the room varies with the time of day, and just as bad, the color temperature of the ambient light varies with the time of day, the weather, and the season, and also depends on whether the halogen bulbs are turned all the way up as their color temp varies with the dimmer switch - lower brightness, warmer light.

  • On the third hand (well, it’s complicated, two hands aren’t enough), if the monitor brightness is too low, then shadow details are more difficult to see.

Absolutely controlled ambient light would be nice, but I’m guessing that’s not practical for most people, including me. So this latest time for calibrating my monitor, I used Displaycal to set the monitor luminance to 64cd/m^2, and also twiddled the monitor’s controls to set the “color of monitor white” to 5000K, that being somewhere between the window light on my left and the halogen light on my right. Displaycal’s monitor calibrating user interface is really, really nice, considerably easier to use than ArygllCMS colprof’s command line interface.

I’m very curious what Luminance and what “color of monitor white” other people on this forum use, and why, if anyone is willing to share. I’m guessing many people are using something like 100-120 cd/m^2 and D65/6500K?

Yes, I was trying to somewhat capture what night really looks like, and detail really is flattened when it’s dark. Also the dirt pile and gravel near the tracks is not very pretty, so not emphasizing it seemed like a good idea.

This takes the issue straight into the territory of color appearance - our eyes exaggerate contrast, which makes it easier to see shadow details if the total dynamic range is limited, and really difficult to see shadow details if there are also very bright regions in the same narrow field of view.

Moving back to the issue of what shadow tonalities monitors can actually display, the darkest color in the “Tracks at Night” image is around Lab Lightness=5, which is supposed to be around the darkest Lightness that most monitors can display (putting aside the new displays that actually can produce near zero lightness), and also is the darkest Lightness that even a really good printer with really good photographic paper can print. L=5 is the “darkest dark” that I try to set for all images that I edit.

When using sRGB as the monitor profile, the RGB color (0,0,0) is mapped to whatever happens to be the darkest dark the monitor can actually display, so paradoxically the darkest darks will appear lighter than they would if an actual monitor profile were being used.

Thanks! I changed the theme, there are only two options, yes? The “fifty shades of gray” theme uses approximately Lab Lightness=30 as the background, which coincidentally is approximately also what I set my “desktop” to display.

Thanks! for posting your xicclu graph and monitor profile. Your profile xicclu graph also has the downward hook, same as the ones I’ve been making and using. I’ll have to try using DisplayCAL to see what happens. Did you specifically request the gamma 2.2 and the D65 white point and XYZ LUT profile? I think these might be the DisplayCAL default settings?

I was a bit surprised that DisplayCAL seems to make an XYZ LUT profile by default, but maybe I had requested some such awhile back. I think I’ll try deleting the DisplayCAL configuration files and see what happens.

According to Wikipedia (https://en.wikipedia.org/wiki/Google_Chrome#Color_management), “Chrome supports color management by using the system-provided ICC v2 and v4 support on macOS, and from version 22 supports ICC v2 profiles by default on other platforms.”

So I installed Google Chrome (from Gentoo Portage). It does look color-managed, but the shadows are crushed compared to Firefox and Pale Moon browsers. This isn’t noticeable for most of the images on my Pictures in Progress page, but it’s very noticeable for the “Tracks at night” and “Sailboat on a lake” images. I wonder how this shadow-crushing is even possible if Chrome is using the same system-installed monitor profile as the other two browsers.

Do you know where in the Chrome settings color management can be disabled/enabled? I don’t intend to keep Chrome installed on my computer (Google is a little too pushy and invasive for my tastes), but I’m very curious about the crushed shadows.

Regarding Geeqie, for some reason Geeqie is showing the background of the image as black, even if I set it to some other color. But the list of files to the right of the image is on a white background. Sliding the divider between the list of files and the image is a bit amusing, because as the list of files is squeezed down to very narrow, the amount of shadow detail visible in the image correspondingly and very obviously increases, maximizing if the list of files is made invisible so there’s no solid white in the field of view.

It turns out that using black point compensation for the display does give very different results, depending on the actual monitor profile being used. This is what I found to be so surprising - I sort of thought that results of using or not using BPC would depend only on the monitor profile’s actual black point, assuming of course that one is using a monitor profile that results from using good profiling software that actually provides an accurate monitor profile black point (this is what I get from “assuming what happens” instead of “experimenting to see what really happens” :slight_smile: ). But in reality it also seems to to depend on the rate and angle at which the monitor profile xicclu curve approaches the x-axis. This “rate and angle” in turn depends on the type of profile that you make, and also on what your monitor is capable of displaying after it’s profiled, which in turn depends on the monitor’s native capabilities including its native “gamma” and black point.

I put together a test image that allows to show the difference your monitor profile makes, and also the difference between using and not using black point compensation with different monitor profiles:

For this test image, on pixls I can’t see any squares until reaching the next to the last row. In GIMP-2.9, if I use sRGB as my monitor profile, I can see a lot more squares than I can if I’m using an actual monitor profile made using ArgyllCMS or DisplayCAL. And the darkest square I can see depends very much on which monitor profile is being used, and also on whether I’m using BPC.

GIMP-2.9 allows to freely experiment with different display profiles and settings. But of course the image can be used in any imaging software including web browsers. The strange thing about Chrome is that on my system there are fewer visible squares than with Firefox, which is expected given that the shadows seem crushed more on Chrome. But also the Chrome the visible squares have a warm reddish hue instead of neutral gray like they look in Firefox. The warm hue isn’t noticeable unless I immediately switch to Firefox to look at the same image.

How many squares you might see also depends on how bright the ambient light is (in darker rooms, more squares are visible) and on how dark the surround around the image is,: to see the maximum number of squares make the surround black and the room completely dark. How many squares you can see also depends on your field of view, ohow close to the monitor you happen to be, how well your eyes have acclimated to the light level, and how well they are shielded from glare, and I’m guessing also on how bright the monitor is. Try making the room dark and even using a “viewing tube” to focus in on only one square at a time, not that this even remotely resembles how we actually view images on the web.

As an aside, at one point Firefox 4 did support black point compensation, but that was back when Firefox used LCMS as the CMS. You’d think that if they decided to use their own in-house color management, at least by now they’d have added support for all four rendering intents, it’s been many years since they dropped LCMS.

Pretty much the same here.

08

I can see 24 squares on pixls using Chrome. Irrespective of how dark or bright the ambient light is.

Thanks! @agriggio - another xicclu graph with the downward hook towards the x-axis. Given that I’m not the only person using this type of monitor profile, I feel better about continuing to use this type of profile.

Is this a custom monitor profile? I would guess yes as obviously you have ArgyllCMS installed. But my impression is that newer monitors are coming out with factory-supplied profiles that are pretty good, so perhaps not making a custom profile doesn’t carry quite the risk of “wrong colors” as it used to, and as @houz and @Morgan_Hardwood noted in the following thread, LCD monitors maintain their state of calibration a lot longer than the old CRT monitors:

Hi @Colin_Adams

I used to have an old CRT monitor that had such a light black point that I’m sure I could have seen all the patches on that monitor. But that situation of editing on a monitor with a far too light monitor black point led me to compensate by radically compressing shadow tonality, resulting in images that looked OK on my monitor but incredibly dark (completely crushed shadows) on other people’s more properly calibrated monitors. That monitor is a major reason why I came to have an interest in color management.

In times past if someone could see all the patches then I would have concluded that there’s probably something wrong with their monitor, or else there’s something else wrong in the display chain.

But today there are new sorts of monitors out there with technologies that provide a monitor black point that’s zero or very close to. Also I looked up some of your dragonfly images on pixls and they are very nice images, with nice shadow tonality, which indicates you aren’t using a monitor with serious black point issues and there’s nothing wrong with the display chain. So I’m really curious as to what kind of monitor you have, and also curious if anyone else can see all the patches.

@Elle It’s a Dell P2415Q

hi @Elle, yes it’s a custom profile. with the default one I had the same problem that you described below, ie too bright black point. I can see almost all the patches with the default profile, but that’s really bad because then my pictures turn out way too dark…

When viewed on pixls.us with firefox (colour managed) your photo of the tracks look good to me. It looks like night, I just about make out details in the darkest trees. The ground has plenty detail. When viewed on ninedegrees it’s appears a bit to bright for my liking nothing appears black.

I use a 6500 2.2 xyzlut profile (displaycal). I can’t make out the first three patches of the greyscale test on pixls but see all i Geeqie.

It does seem however that using this profile means my pictures appear dark for most people. As it seems many devices have to much contrast resulting in crushed blacks.

My display is a non fancy Eizo EV2736W which I bought to see decent srgb not high gamut.

Edit: Made a mistake! I had Geeqie configured with a curve created using the pixls.us tutorial. Using my standard d6500 xyzlut profile (same as firefox is using) I can’t make out the first two patches in the greyscale test image. Ie I gained one patch from not using a white background.

I’m using a recently compile Geeqie version set to “relative colorimetric”.

This is my curve for the d6500 2.2 xyzlut
2017-12-17-220353_500x500_scrot

This is the pxls tutorial one (matrix i believe)
2017-12-17-220619_500x500_scrot

Despite the curves being similar (identical?!) I see darker patches with the matrix one.

Yes.

I looked into this again yesterday. Chrome had a basic (i.e. broken, because IMHO it’s not color management if its only partial(ly implemented)) color management a long time ago, and then it was removed. Now as of version 61 it has support for a monitor profile, but with some severe limitations - I don’t know how it detects the “system profile” whatever that means, it doesn’t tell me which profile it detected, it doesn’t let me choose the rendering intent, it doesn’t let me turn on/off black point compensation, and it doesn’t let me specify my own monitor profile. I asked about these things in their issue trackers, see:
https://bugs.chromium.org/p/chromium/issues/detail?id=755747#c59

I also confirm that the image in Google Chrome 63.0.3239.84 looks like the image in Geeqie when color management is turned off, i.e. despite me having my monitor profile set in the X11 atom and despite having chrome://flags/#force-color-profile set to “default”, it does not work.

i.e. no surprise there, color management still doesn’t work in Chrome.

See Mr Robot add-on in Firefox - very disturbing!

I use the latest git. To get it, just run this script: https://filebin.net/crtc5rjxy65hg7cw/build-geeqie
Looks like this: https://i.imgur.com/4JwKHkd.png

I can see about 23 patches when viewed in a dark room i Geeqie with color management enabled, and about 20 patches when viewed in Google Chrome 63.0.3239.84 or in Chromium 62.0.3202.94 (the images in both Chrom*s look identical, so I grumpily conclude that color management doesn’t work in neither Google Chrome 63 nor in Chromium 62).

About 23 patches in Firefox with gfx.color “properly” set.
PA246 #1 2017-12-06 13-15 D5000 Rec. 709 VF-S XYZLUT+MTX
xicclu more or less straight.

Have fun!
Claes in Lund, Sweden

Hi, here’s a question for people that see almost all the patches: do you normally print your pictures? I ask because I see about 16-17 patches (depending on the illumination), and that is because I wanted my monitor to give me a good preview of my prints. If I set it brighter (or better, with a lower gamma), all my prints will turn out too dark. BTW, I use an online service for printing which wants pictures in sRGB. In this respect, I found this piece of documentation of displaycal quite relevant and helpful:

So if you are displaying images encoded to the sRGB standard, or displaying video through the calibration, just setting the gamma curve to sRGB or REC 709 (respectively) is probably not what you want! What you probably want to do, is to set the gamma curve to about gamma 2.4, so that the contrast range is expanded appropriately, or alternatively use sRGB or REC 709 or a gamma of 2.2 but also specify the actual ambient viewing conditions via a light level in Lux, so that an appropriate contrast enhancement can be made during calibration. If your instrument is capable of measuring ambient light levels, then you can do so.

I rarely print, but I DO print sometimes.

Prints are my #1 end goal, so my setup reflects this. Generally going from adobe rbg to sRGB for web is OK and is easier than going the other way.

On my mobile device, I see 15 patches; on the laptop, I see 20, or 22 at max brightness. Both have sad screens that aren’t profiled and Firefox with the color management settings enabled.

Addendum:
(From above: I can see about 23 patches in a profiled monitor.)
With profile turned off, i.e. when running the monitor in its native mode, I can see about 14 patches.

Have fun!
Claes in Lund, Sweden

So, answering some of the questions:

  • I do see all the shadows in the night shot just fine, at least when looking at it without the white background. Here on pixls it’s a little harder but still possible.

  • I do see all the 25 grey patches.

  • To show how little monitor profiles changed for me, here are both the one I made on 25.06.2013 and 13.09.2017. The old one was made with the X-rite software on Windows and the VCGT part uploaded into the monitor, the new one was made following Pascal’s blog post. That’s how I have been creating profiles for other monitors for years.

DELL U2413 - 25.06.2013.icc (9.4 KB)
DELL U2413 - 13.09.2017.icc (2.2 KB)

The procedure in Pascal’s blog post is the same procedure I’ve been following for a long time, except I’ve always skipped the calibration step (the colprof step) and profiled my monitor using its native TRC and color temperature) - the only calibration I’ve been doing is to set the monitor brightness to something around 64cd/m^2. My profiles have always had the same shape xicclu curve as your profiles, except the color channels were split.

Recently I’ve been experimenting with using dispcal to calibrate my monitor to have a neutral gray axis, so non-color-managed parts of the desktop will look neutral gray if their corresponding colors are supposed to be gray, such as the new GIMP-2.9 themes. My goal is to make a profile that:

  • Looks as neutral and also as smooth as possible up and down the gray scale.

  • Shows low or zero chroma values - preferably well under LCH “1” - when using GIMP’s screen “eyedropper” to color pick from the screen itself. I’m not sure exactly how this screen “eyedropper” works, but results do change as the installed system profile is changed, and the picked colors cohere with what my eyes are seeing.

It seems curious to me that using dispcal to calibrate and also at the same time make the monitor profile (using the “-o” switch: http://argyllcms.com/doc/Scenarios.html) produces a profile without that characteristic downward hook at the x-axis of the xicclu curve. Instead the xicclu curve is very close to a straight line, at least if the requested gamma is close to the native gamma reported by dispcal using the “-R” switch.

However, despite the straight-line xicclu graph, the colprof “one step calibrate and profile” monitor profile that I made last night, when black point compensation is turned on in GIMP, seems to “screen color pick” very close to the actual LCH “Lightness” values, which is a nice thing. Here’s a screenshot of the xicclu curves:

colprof-one-step

I haven’t thought this hard about monitor profiles or spent so much time trying different ways to profile the monitor, for many years. Sigh.

About “installed system monitor profile”: what I mean by “installing a system monitor profile” is using “dispwin -I whatever-filename-the-selected-monitor-profile-has.icc”, or else the equivalent process using displaycal or colord or xicc or oyranos etc. I don’t have colord/xicc/oyranos installed on my system as I find these utilities to be somewhat unpredictable and not friendly to user intervention when the user wants to do something other than what the utility thinks should be done.

In case anyone wants to experiment and doesn’t already know the Argyllcms commands:

  • The command to uninstall a system monitor profile is “dispwin -U whatever-filename-the-selected-monitor-profile-has.icc”.

  • The command to clear the video LUTS is “dispwin -c”.

  • The command to load a calibration file into the video LUTS is “dispwin name-of-cal-file.cal

  • If the monitor profile has a vcgt tag, there’s no need to also load the calibration file as the “dispwin -I” command also loads the vcgt tag information into the video LUTS.

Yes, thanks! for that link, which prompted me to set my gentoo portage “package.mask” file to not allow Firefox or Thunderbird to be updated again. I’ve been increasingly unhappy with Firefox with each “upgrade” - as @afre noted in another thread these recent updates keep changing settings and functionality. I have Pale Moon installed as an alternative to Firefox, but it doesn’t support the full range of privacy/security add-ons.

1 Like