Does anyone know of an image viewer that runs on Linux, that is capable of showing linear gamma images without distorting the shadow tonality? What I mean is, has anyone actually used an image viewer to view a high bit depth linear gamma tif or png, and can verify that the image viewer allows to see undistorted shadow tonality?
It would be nice if this potential image viewer also allowed for tagging images.
Digikam and geeqie both distort shadow tonality. These screenshots illustrate the problem with digiKam - click on the image to see the larger version:
For many images, the result of how digiKam shows the shadow tonality just makes it look like the shadows are richer, the image more saturated, than it is in reality. And of course to make comparisons with other color-managed viewers/editors, the color management settings - the conversion intent and whether to use black point compensation - must be the same.
For images with smooth gradients in the shadows, the distorted shadow tonality becomes immediately obvious.
I can’t recommend any image viewers, but would it be possible to upload the test file? Maybe scaled down and flattened to not require such a giant amount of disk space?
In this particular case I’m not actually pixel-peeping, even though I’m guilty of doing a lot of pixel-peeping. However, that HDRView looks really nice! so I’ll give installing it a try - thanks!
In the particular use case I have in mind, what I want is to make the image more or less fill my monitor’s 19" diagonal screen, and then view the image from two distances - from 2-3 feet away (normal viewing distance for the way my workstation is set up), and from about 10 feet away, which is perhaps from how far away a print on a wall might be viewed.
The angle of view an image takes up drastically affects perceived tonal contrast (as does the surrounding brightness vs the brightness of the screen). So when evaluating an image that might be printed, it’s important to look at it from a distance as well as from normal monitor viewing distance.
How big a file would you like? I just put together a 1200x1200 16-bit linear gamma png that is 2.8Mib when compressed to GIMP’s level 9 png compression. I can resize it to be smaller, but that would limit the option to change the zoom ratio.
XNView is great software - I used it back when I used Windows, and it’s wonderful that the dev also makes it available for Linux. I think it requires installing WINE? and it’s not free/libre?
Yesterday evening I solved the “find an image viewer that can show linear gamma images” by downloading and compiled digiKam from git, after first modifying a line in core/libs/dimg/filters/icc/icctransform.cpp to change the variable"transformFlags" from “0” to to “cmsFLAGS_NOOPTIMIZE”. This modification allows digiKam image previews to match GIMP and Krita displays of linear gamma images, assuming in Krita the user has unchecked the option to allow LCMS optimizations.
This sounds like a simple change in the digiKam code, and it works for me because the option to allow the LCMS optiimizations is an option I don’t ever use. But for an application like digiKam the user should be given a choice because apparently not using the optimizations can sometimes slow down the conversion and display of images. So if digiKam devs decide to offer this option (I hope they do - I’m about to send an email to the mailing list), it would require also writing a suitable user interface such as Krita and GIMP both already have.
I did some additional experimenting and realized that whatever was making the digiKam 5.7.0 thumbnails not be color-managed is strictly something on my own system, buried somewhere in a configuration file. I can reproduce the “not-color-managed” thumbnails for digiKam compiled from git “at will” by uninstalling or installing the system monitor profile while digiKam is running, combined with changing the digiKam monitor profile when there is no installed monitor profile (if there is an installed monitor profile, digiKam doesn’t allow changing the monitor profile). Restarting digiKam makes the thumbnails color-managed.
Also the thumbnails are 8-bit images, which explains the severe shadow posterization for the thumbnails.
So the only actual problem with digiKam and displaying linear gamma images is with the previews, and that problem is solvable by not allowing LCMS optimizations, either by directly modifying one file and compiling from source, or if the actual code is changed upstream to give users a choice, similar to how Krita handles this situation.
Thanks! My husband recently switched to Linux and is currently using Gwenview to view images. But he used to use XNView and liked it quite a lot, so I told him about XNViewMP.
Personally I avoid freeware for various reasons, including licenses such as the XNViewMP license:
What if I wanted to sell a photograph that I had viewed using XNViewMP? I’m not a lawyer and don’t plan to consult a lawyer for answers to these kinds of (probably very silly) questions. So I just avoid such softwares altogether.
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…
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.
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.
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.
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.
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.
However, that HDRView looks really nice! so I’ll give installing it a try - thanks!
