I don’t think there is a “linear gamma” image viewer. There are properly color managed viewers, and those can deal with linear and gamma encoded images with equal results. Ideally, high-bit-depth images should look the same independently of the fact that they are linear or not, once converted to the display profile…
1 Like
Thanks. That is what I thought but kind of got confused when reading the thread.
That sounds like a good size.
Yes, exactly. My apologies for the misleading subject line for this post. The context was my frustration at having made “png sidecar files” for keeping track of XCF files using digiKam, only to discover that digiKam was showing distorted shadow tonality.
In the meantime I figured out how to modify the digiKam source code to make this problem go away for digiKam, by modifying the code (a one-line change) to not use the LCMS optimizations. And it looks like the digiKam devs are going to provide a user option to disable these optimizations - see the last posts to this long thread: http://digikam.1695700.n4.nabble.com/Thumbnails-not-color-managed-severely-distorted-shadow-tonality-for-thumbs-previews-td4704410.html - and please forgive the misleading subject line.
As many times as I’ve encountered this same issue in other software, when I realized the shadow tonality was wrong in the digiKam preview images, you’d think my first thought (instead of my last thought) would have been “Oh, LCMS optimizations are at work”.
As this issue of using or not using LCMS optimizations when viewing linear gamma images does transcend digiKam, perhaps the subject line of this thread could be changed to something more informative, such as “How to set up color-managed image editors and viewers for viewing linear gamma images”?
Another thing to watch out for when coding image viewers/editors to properly display linear gamma images is to make sure the ICC profile conversion from the image to the display profile is done at the same bit depth (or higher) as the image (and of course the only reason anyone should ever have an 8-bit linear gamma image is to demonstrate problems with trying to encode linear gamma images using only 8-bits). For example, at one time GIMP-2.9 had the problem that the images were converted to 8-bit integer before being converted to the display profile, resulting in posterized shadows for linear gamma images. But this problem was fixed a long time ago, and GIMP-2.9 does display linear gamma images correctly.
Here are two linear gamma pngs. One has blocks and linear gradients, and the other has smooth radial gradients.
Blocks and linear gradients:
Smooth radial gradients:
Notice that especially for the second image as displayed in the browser (at least in my Firefox browser), the gradients look anything but smooth. To see what the images really are supposed to look like, you have to actually download the images and open them in an image editor that is set up for properly displaying linear gamma images.
The reason I included the second much larger image is because this image very clearly shows the results of using the LCMS optimizations not just in the deep shadow areas, but also in the transitions between lighter shadow areas. This is the type of image that actually made me realize that something was very wrong with how digiKam was displaying shadow tonality.
Checking whether the shadow tonality is correctly displayed is made more difficult by any number of factors:
-
If you are comparing the image as shown in different softwares, the first problem is that both softwares need to have black point compensation enabled, though this only affects users who are using monitor profiles with non-zero black points. As an aside, Firefox hasn’t been able to use black point compensation since Firefox 4, when Mozilla dumped LCMS and decided to code their own color management software. They still haven’t got things straightened out and done right. Sigh.
-
The monitor itself needs to be of a type where slight changes in viewing angle don’t affect the display of side-by-side images. Even relatively high-end photographic-quality monitors can be affected by the angle of view, though less so than very low end consumer displays. And perhaps newer technologies have mitigated this issue? Anyway, putting the images side-by-side and viewing from a distance can help with the “viewing angle” problem.
-
The surround (background color) for comparing the images as displayed by different image editors and viewers needs to be the same, preferably have the images overlapping to eliminate surround differences as much as possible. A solid white surround is not good for discerning shadow tonality, middle gray is much better.
-
Viewing conditions should be controlled - in particular the room shouldn’t be brighter than the monitor itself.
Please assume the two images are licenced appropriately - CC-BY-SA? CC0?
If it would help, I can put up some screenshots showing “right and wrong” displays of the two test images.
Google Chrome 62.0.3202.94 vs Geeqie v1.2-403-ge702a744
Color management turned off:
Color management turned on, use profile from image:
Color management turned on, sRGB:
Here’s my monitor profile:
B133HAN02.1 #1 2016-10-19 21-46 D6500 2.2 F-S XYZLUT MTX.icc (788.0 KB)
But there’s nothing wrong with what Geeqie shows me. I see posterization because the image has posterization. @Elle did you perhaps upload a 16-bit image and the forum converted it to JPG?
To not leave @Morgan_Hardwood 's question hanging in midair without an answer, the second image that I uploaded (a 16-bit png) is not the image that’s currently available to download (a resized jpeg), at least as of this post - follow the split topic to see what’s going on.
Did anyone try Viewnior?
http://siyanpanayotov.com/project/viewnior
I just tried out how your two JPGs did in Viewnior, and it renders them without the banding, but that apparently means nothing because of the change.
I hope it turns out it does it right, since Viewnior is probably the fastest option out there - one of my colleagues at work needed a solution for stitching many, many automated microscope scans together, and after some searching we found this as the simplest solution. It turns out that it performs so good that we can just generate a ridiculously large PNG, and still pan and zoom with good responsiveness. The image quality when zooming out is also really good (hopefully a sign of proper colour management…)
From curiosity I downloaded the source code Viewnior and searched the code for “lcms” but didn’t find the usual statement about including lcms2.h, which means if it’s color-managed, it’s not using lcms, which would be highly unlikely for a linux application. I installed it anyway and opened a linear gamma png, which it displayed with the usual too-dark tonality for image viewers that aren’t color-managed. So Viewnior isn’t color-managed.
I’m guessing the automated microscope scans are output as more or less perceptually uniformly encoded images, so for the task you described, probably actual color management isn’t needed, though in this scenario what the monitor shows will vary from monitor to monitor.
Which jpgs do you mean? I uploaded two linear gamma pngs, one of which got turned into a highly posterized reduced-size sRGB jpeg - there are obvious discrete steps in the shadows, whereas in the original png there is a smooth continuous gradient from dark to light.
I believe the only color-managed image viewers are geeqie and nomacs. I don’t think eye of gnome/mate, gweenview, etc are color managed.
Gwenview is color managed, though currently perceptual rendering is hard-coded (same as with the latest stable Geeqie-1.3, though I already got Geeqie to fix it in git, but am still trying to get Gwenview to see the light) and the monitor profile is taken from the X11 atom, not manually selectable.
I meant to say “because of the change from PNG to JPG”, sorry about the confusion.
However, even with the JPGs the banding is only visible in the browser, opening it in Viewnior or GIMP removes the banding.
This thread got me thinking about whether my Firefox is color managed. Sure enough, when I checked http://www.color.org/version4html.xalter, I knew I needed to tweak the settings.
about:config
I left display_profile empty because I don’t have one and the rest as default.
1 Like
2 Likes
@Claes is right, that gfx.color_management.mode should be 1. It’s “2” by default, which disables color management for images that don’t have embedded ICC profiles, instead of assuming these images are sRGB images. Without an actual monitor profile, I’m not sure it will make any difference. The default “2” has been politely referred to as “half-fast” color management.
I haven’t checked in the last year or so to see if everything is still the same for Firefox Color Management, so maybe something is now different than it used to be. I wonder what that quantum version of Firefox will do.
I use “1” relative colorimetric for the rendering intent, but that’s a matter of personal preference.
2 Likes
Thanks for the info @Claes and @Elle. On the reference site (last updated in 2010), it says
0 Disable color management.
1 Enable color management for rendered graphics.
2 Enable color management for tagged graphics only. (Default)
PS I forgot to mention that you need to restart Firefox before the settings come into effect.
Here are two versions of the same image. The first is sRGB, with metadata that says its gamma is 0.454545, and its average pixel value is 0.488162 (on a scale 0 to 1.0).
The second is linear RGB, with gamma 1, average value 0.232402.
The images should look the same.
They look the same on my usual browser, the current Firefox (v57.0).
If your browser ignores the gamma seting, the second image will look like this (which has gamma=0.45454 but average value 0.232402):
5 posts were merged into an existing topic: Hardware calibration, how to set Gnome Color/Darktable ?