Monitor profiles and deep shadow tonality

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

I was referring to the Chrome interface, which uses that term without explaining where it looks or what it finds there, if anything.

Ah, I thought you were speaking ironically, along the lines of “Why does some Linux software insist on enforcing the use of a system monitor profile that might have been installed without the user even knowing that any such profile had been installed.” But I gave a “straight answer” in case there was anyone reading the thread who didn’t know what “system monitor profile” actually means.

I also assumed - obviously without any good reason other than also assuming the Chrome devs used what might pass for common sense when writing their color management code - that Chrome used the actual system monitor profile if one is installed in Linux, and whatever the equivalent is in other operating systems. Making assumptions is always risky, but the alternative is not saying anything at all :slight_smile:

I want to say “Thank you” for all the feedback on the train tracks image and the 25 gray patches image and regarding xicclu curves and such. I’ve spent a good part of the last couple of weeks experimenting with making different types of profiles for my monitor, and the feedback has been very helpful.

Regarding the 25 gray patches image, I was surprised at the number of people who could see all or nearly all the patches. So I checked to see how the image looks on three uncalibrated and unprofiled displays in our house, in each case displaying the image in Firefox:

  • A low-end Windows 10 laptop: I see all 25 patches, and the background is obviously gray instead of black. Pictures look very washed out on this display.
  • A wide screen LCD TV: I see all 25 patches, and the background looks black.
  • The LCD monitor that came with a small HP Pavilion desktop, running OpenSUSE Tumbleweed: I see 22 patches, and the background looks black. Pictures look pretty good though shadow tonality could be a bit darker.
  • On my own monitor, if I clear the calibration from the video LUTS and use sRGB as the monitor profile, then I see 20 patches.

After experimenting a bit with using ArgyllCMS to make different types of monitor profiles, each time using the same calibration file (using the “multi-step” approach to making a profile that includes a calibration file), the number of patches I could see ranged from 10 to 25, depending on which profile I installed as the system monitor profile. I kept the rendering intent set to “relative colorimetric”, and when viewing the image using GIMP and other image editors, I also selected to not use black point compensation.

Well, probably none of the above is very interesting. The profiles that allowed me to see more than 14 patches (“gamma matrix” profiles made using the “-ag” and “-aG” colprof parameters) also had very large deltas near zero (as reported by “profcheck”), so weren’t exactly accurate profiles, which isn’t surprising given that my monitor’s uncalibrated black level isn’t anywhere near zero.

But here’s something that is puzzling: When using the XYZ LUT profile (the profile with the lowest deltas overall and also near zero), and with black point compensation disabled, and using relative colorimetric intent:

  • GIMP, RawTherapee, Krita, darktable, Photoflow, geeqie (built from git a couple days ago), and digiKam all showed ten visible patches, which is consistent with the actual black level of my monitor.

  • Firefox shows fifteen clearly visible patches and maybe five more “sort of visible” patches. This discrepancy between Firefox and the other image editors and geeqie was also visible in actual photographs and such, but only for predominantly low-tonality images.

I really wish Firefox hadn’t decided to roll their own QMS color management system.

Did anyone perchance check to see how many patches they could see in Firefox vs PhotoShop, or PhotoShop vs various free/libre image editors and viewers, keeping the rendering intent at relative colorimetric and not using black point compensation?

1 Like

Ha, you are wrong!!!

After experimenting a bit with using ArgyllCMS

What setting(s) would be the “optimum”, then?

Have fun!
Claes in Lund, Sweden

That would depend on what your monitor is capable of and also your own particular editing/viewing goals and also on what software you want to use with whatever monitor profile you might make. I’m still experimenting to figure out what works best with my own monitor/goals/software. I’m putting together an article with some test images and procedures/considerations for profiling monitors, but I’m not quite ready to load the article up to my live website.

Speaking of software that you might want to use when viewing images, here are two screenshots illustrating some peculiarities of Firefox/Palemoon (they both seem to handle monitor profiles the same way), vs Google Chrome:

As shown below, when the system monitor profile is a LAB LUT profile, Firefox/Palemoon and Google Chrome both use sRGB (presumably their own built-in version of sRGB) as the monitor profile. I confirmed this by opening the image in GIMP-2.9 and telling GIMP to use sRGB as the monitor profile. The sky is not supposed to be saturated turquoise blue, but rather “normal” blue sky blue:

firefox-chrome-lab-lut

As shown below, when the system monitor profile is an XYZ LUT profile, Firefox/Palemoon show correct colors, though deep shadow texture is flattened compared to what GIMP-2.9 shows. But Google Chrome shows, um, something else:

firefox-chrome-xyz-lut

The two sets of screenshots above use:

  • Google Chrome Version 63.0.3239.84 (Official Build) (64-bit), with no changes to whatever chrome does by default to color-manage images.
  • Pale Moon 27.4.1 and Firefox 52.5.0 with settings as per Viewing photographs on the web

Obviously Chrome really is picking up on the system monitor profile, else the image in Chrome would look the same in both screenshots. And just as obviously, it’s not doing the right thing for LUT profiles.

Is there a way to tell Chrome to use particular color management settings, such as what Firefox allows using about:config?

1 Like