Monitor profiles and deep shadow tonality

Calibrating and profiling a monitor is something I don’t like doing. So I’ve used the same profiling process for a long time. But recently I’ve been experimenting with various ways to calibrate and profile my monitor and discovered (well, this surely isn’t news to most people!) that way the profile is made fairly radically affects deep shadow tonality as displayed on the screen.

Here are two “xicclu” curves, from two profiles made using Argyllcms. Both profiles use a calibration file to create a neutral gray axis. Actually both profiles use the same calibration file. Both profiles are shaper matrix profiles. Similar xicclu curves result from using Displaycal, depending on the parameters used to profile the monitor:

The xicclu curve on the left is from a calibration+profile done in one step using just the colprof utility. I requested a gamma=2.16 TRC for the calibration file as this gamma is roughly the “native” gamma for my monitor, so requires less correction to get a neutral gray axis.

The curve on the right uses the same calibration file as the curve on the left, but was done in several steps using targen, dispread, and colprof.

Notice that where the two curves reach the x-axis, the left curve is almost a 45-degree straight line, and the right curve has a pronounced downward hook.

The xicclu curve on the right resembles the xicclu curves for the monitor profiles I’ve used until recently. The presence or absence of the downward hook makes a huge difference in the deep shadow tonality:

  • In Firefox, which doesn’t allow for black point compensation, the following image has totally crushed shadows if I use the monitor profile with the xicclu curve shown on the left. But the shadows aren’t crushed if I use the monitor profile with the xicclu curve shown on the right.

  • In GIMP, using the monitor profile for the xicclu curve on left with black point compensation, makes the image look very close to how the image looks using the monitor profile for the xicclu curve on the right, when black point compensation is not enabled.

Actually, as surrounded by white on the pixls webste, the shadows in the image look crushed no matter what, so the same image is on this page, about the fourth image down: Pictures in progress

As the point of putting an image on the web is so other people can look at it, I wanted to ask a couple of questions:

  • Does image above have completely crushed shadows when viewed on your monitor?

  • Whether yes or no, what does your monitor’s xicclu curve look like? Here’s the command to ask xicclu to draw the curve:

xicclu -ir -fif -g nec-20171216-1242-as-qh.icc

At least on Gentoo, you have to write this instead, unless you downloaded ArgyllCMS from the argyllcms.com website and put the executables in /usr/local/bin:

argyll-xicclu -ir -fif -g nec-20171216-1242-as-qh.icc

1 Like

I’m using Firefox on a laptop with fairly good LCD screen, and the forum web page has a white background. The shadows across the ground, and in most of the trees, look totally crushed. I see rails and stars, half the ground, and some fuzzy things between the ground and stars.

But I have cataracts. When I shield my eyes from the white background, detail pops out. I see details in almost all the ground, except thin shadows along the edges of the railways sleepers (I think Americans call them “ties”), and detail in almost of the trees.

Pictures in progress is better, but still too light. The only way I can judge shadows is against black backgrounds.

Sorry, I don’t have xicclu or argyll.

I am also using Firefox on laptop with a decent LCD screen. I’m using a dark theme here.

Warning I have done no work whatsoever on calibrating the monitor or color management, so take anything I say with several grains of salt…

For me, the image in this thread has a lot more detail in the shadows than the one in ninedegreesbelow.com. Here, the gravel bed for the tracks has good definition, while there it’s just slightly mottled dirt.

Side note: I love this image. It captures the feel of night time in the country so well.

Hi @snibgo
Even without cataracts, as displayed on pixls I can’t see any details in the trees except for some of the brightest leaves, but white-background websites are very difficult for me to look at - the glare and contrast are extremely tiring. On my Galleries page I changed the outline around the image from white to gray, which helps.

I asked about this specific image because that’s the image that has the greatest “shadow crush” with profiles that have the “straight line to zero” xicclu curves. I’ve always made and used profiles with the “downward hook”. But I also always profiled my monitor using the native gamma curves and white point, without any calibration curves, using the multistep process described in the ArgyllCMS documentation (Argyll Usage Scenarios).

Over the last couple of days I’ve been experimenting with using calibration curves to make a neutral gray axis. Asking for the Lab L curve or the sRGB TRC or even gamma=2.4 during the one-step calibration-profile produces a flat angle - a downward dip just before the curve flattens to approach the x-axis, which makes the shadows even more crushed in Firefox. For example, here’s the curve for a one-step calibration-profile with the lab L curve:
xicclu-monitor-curve-one-step-gl

At first I thought using a calibration curve to make a gray axis was causing the straight line/downward dip, but it seems to be more a case of using the one-step vs the multistep profile-making process.

If most people’s monitor profiles are showing crushed shadows in Firefox, maybe I should switch the way I make my monitor profile, though I’d prefer to stick with profiles that are similar to what I’ve been using all along.

Is this dark theme on pixls? If so, how does one activate it?

Is sRGB is set as the monitor profile? Or some other monitor profile, perhaps pulled from EDID? Anyway, at least on my Linux system, uninstalling the system monitor profile and restarting Firefox results in sRGB being used as the monitor profile, and the shadows are not crushed at all - way better than using the wrong type of monitor profile with images that were prepared for the web using a completely different type of monitor profile!

Thanks so much! It was a very experimental way to process an image and I wasn’t sure if anyone beside me would like it. Well, my husband likes it, but he is maybe a bit biased :slight_smile: .

@Elle I am using a sad screen right now so take this with a grain of paprika. Remarks:

  1. Screen brightness affects how much deep shadow detail I see. The brighter the better.

  2. When I turn on color management v4 in Firefox, the shadows become more subdued, but not exactly crushed, and overall detail flattens. With it off, I see everything clearly.

  3. Like @elGordo, I see mottled dirt and the details are rather soft but I guess that is understandable for such a darkly lit scene.

  4. Like @snibgo, the darker the surround the better.

  5. Change theme by going to Profile > Pref > Interface. I don’t exactly like the dark theme; it is less consistent than the default one. I have been meaning to make a custom theme but the CSS is too long for me to get a feel for what does what and there is no way of loading your own theme.

  6. Isn’t BPC what prevents the shadows from being crushed? So, if Firefox doesn’t support it, some profiles would fail in displaying the shadows properly.

    PS From a quick web search it appears that to BPC or not to BPC doesn’t have a straight forward answer. It could depend on a number of things like the profiler, image processor, image viewer and color management. This last statement is a non-answer, sorry, lol.

    PPS Random thought: Looking at some of my PlayRaws, it seems that, in post, I tend to boost the local contrast of my shadows, which happens to have a positive side effect in preventing them from appearing crushed in Firefox using the default discuss theme.

    Actually, in general, when I do a PlayRaw, every time I upload my version, it is always darker than everyone’s entries, so that is why I boost the contrast, esp. in the shadows.

@Elle
My DisplayCAL profile:
B133HAN02.1 #1 2016-10-19 21-46 D6500 2.2 F-S XYZLUT MTX.icc (788.0 KB)

I see details everywhere when viewing in Google Chrome 63.0.3239.84. If I open the image from your website in Geeqie and turn color management off, it looks like the one in Chrome. If I turn CM on, its lighter than in Chrome.

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