I finally got off my butt to get a process in place to obtain and update security certificates using Let’s Encrypt for both pixls.us and discuss.pixls.us.
I also did some (more) work with Victor Grigas and Wikipedia to support their #Edit2015 video this year.
So it was an honor to hear from Victor Grigas again this year!
This time around there was a neat new crop of images he wanted to animate for the video.
Below you’ll find my contributions (they were all used in the final edit, just shortened to fit appropriately):
Here is the final cut of the video, just released today:
Victor chose some really neat images that were fun to work on!
Of course, all free software was used in this creation (GIMP for cutting up the images into sections and rebuilding textures as needed and Blender for re-assembling the planes and animating the camera movements).
I had previously written a tutorial on doing this with free software on my blog.
Free: Anyone who owns a domain name can use Let’s Encrypt to obtain a trusted certificate at zero cost.
Automatic: Software running on a web server can interact with Let’s Encrypt to painlessly obtain a certificate, securely configure it for use, and automatically take care of renewal.
Secure: Let’s Encrypt will serve as a platform for advancing TLS security best practices, both on the CA side and by helping site operators properly secure their servers.
Transparent: All certificates issued or revoked will be publicly recorded and available for anyone to inspect.
Open: The automatic issuance and renewal protocol will be published as an open standard that others can adopt.
Cooperative: Much like the underlying Internet protocols themselves, Let’s Encrypt is a joint effort to benefit the community, beyond the control of any one organization.
It was relatively painless to obtain the certs.
I only had to run their program to use ACME to verify my domain ownership through placing a file on my web root.
Once the certs were generated I only had to make some small changes for it to work automatically on https://discuss.pixls.us.
(And to automatically get picked up when I update the certs within 90 days).
I still had to manually copy/paste the certs into cpanel for https://pixls.us, though.
Not automated (or elegant) but it works and only takes an extra moment to do.
John Donne was the greatest English dramatic poet who never wrote a play. Here, Alan Jenkins reads a selection of his works. Find out more: www.the-tls.co.uk
Vertigo special: Toby Lichtig of The TLS introduces David Collard who compares Alfred Hitchcock's film interpretation to the original novel.The film was recently voted 'the best of all time' by 846 critics, programmers, academics and distributors. Find out more: www.the-tls.com
Linearized sRGB channel values and radiometrically correct editing
One goal for GIMP 2.10 is to make it easy for users to produce radiometrically correct editing results. “Radiometrically correct editing” reflects the way light and color combine out there in the real world, and so requires that the relevant editing operations be done on linearized RGB.
Like many commonly used RGB working spaces, the sRGB color space is encoded using perceptually uniform RGB. Unfortunately colors simply don’t blend properly in perceptually uniform color spaces. So when you open an sRGB image using GIMP 2.9.2 and start to edit, in order to produce radiometrically correct results, many GIMP 2.9 editing operations will silently linearize the RGB channel information before the editing operation is actually done.
GIMP 2.9.2 editing operations that automatically linearize the RGB channel values include scaling the image, Gaussian blur, UnSharp Mask, Channel Mixer, Auto Stretch Contrast, decomposing to LAB and LCH, all of the LCH blend modes, and quite a few other editing operations.
The GIMP 2.9.2 editing operations that automatically linearize the RGB channel values do this regardless of whether you choose “Perceptual gamma (sRGB)” or “Linear light” precision. The only thing that changes when you switch between the “Perceptual gamma (sRGB)” and “Linear light” precisions is how colors blend when painting and when blending different layers together.
(Well, what the Gamma hack actually does changes when you switch between the “Perceptual gamma (sRGB)” and “Linear light” precisions, but the way it changes varies from one operation to the next, which is why I advise to not use the Gamma hack unless you know exactly what you are doing.)
Using the “Linear light” option in the “Image/Precision” menu
Large soft disks painted on a cyan background.
Top row: Painted using “Perceptual gamma (sRGB)” precision. Notice the darker colors surrounding the red and magenta disks, and the green surrounding the yellow disk: those are “gamma” artifacts.
Bottom row: Painted using “Linear Light” precision. This is how light waves blend to make colors out there in the real world.
Circles painted on a red background.
Top row: Painted using “Perceptual gamma (sRGB)” precision. The dark edges surrounding the paint strokes are “gamma” artifacts.
Bottom row: Painted using “Linear Light” precision. This is how light waves blend to make colors out there in the real world.
In GIMP 2.9.2, when using the Normal, Multiply, Divide, Addition, and Subtract painting and Layer blending:
For radiometrically correct Layer blending and painting, use the “Image/Precision” menu to select the “Linear light” precision option.
When “Perceptual gamma (sRGB)” is selected, layers and colors will blend and paint like they blend in GIMP 2.8, which is to say there will be “gamma” artifacts.
The LCH painting and Layer blend modes will always blend using Linear light precision, regardless of what you choose in the “Image/Precision” menu.
What about all the other Layer and painting blend modes? The concept of “radiometrically correct” doesn’t really apply to those other blend modes, so choosing between “Perceptual gamma (sRGB)” and “Linear light” depends entirely on what you, the artist or photographer, actually want to accomplish. Switching back and forth is time-consuming so I tend to stay at “Linear light” precision all the time, unless I really, really, really want a blend mode to operate on perceptually uniform RGB.
A note on interoperability between Krita and GIMP
Many digital artists and photographers are switching to linear gamma image editing. Let’s say you use Krita for digital painting in a true linear gamma sRGB profile, specifically the “sRGB-elle-V4-g10.icc” profile that is supplied with recent Krita installations, and you want to export your image from Krita and open it with GIMP 2.9.2.
Upon opening the image, GIMP will automatically detect that the image is in a linear gamma color space, and will offer you the option to keep the embedded profile or convert to the GIMP built-in sRGB profile. Either way, GIMP will automatically mark the image as using “Linear light” precision.
For interoperability between Krita and GIMP, when editing a linear gamma sRGB image that was exported to disk by Krita:
Upon importing the Krita-exported linear gamma sRGB image into GIMP, elect to keep the embedded “sRGB-elle-V4-g10.icc” profile.
Keep the precision at “Linear light”.
Then assign the GIMP built-in Linear RGB profile (“Image/Color management/Assign”). The GIMP built-in Linear RGB profile is functionally exactly the same as Krita’s supplied “sRGB-elle-V4-g10.icc” profile (as are the GIMP built-in sRGB profile and Krita’s “sRGB-elle-V4-srgbtrc.icc” profile).
Once you’ve assigned the GIMP built-in Linear RGB profile to the imported linear gamma sRGB Krita image, then feel free to change the precision back and forth between “Linear light” and “Perceptual gamma (sRGB)”, as suits your editing goal.
When you are finished editing the image that was imported from Krita to GIMP:
Convert the image to one of the “Perceptual gamma (sRGB) precisions (“Image/Precision”).
Convert the image to the Krita-supplied “sRGB-elle-V4-g10.icc” profile (“Image/Color management/Convert”).
Export the image to disk and import it into Krita.
If your Krita image is in a color space other than sRGB, I would suggest that you simply not try to edit non-sRGB images in GIMP 2.9.2 because many GIMP 2.9.2 editing operations do depend on hard-coded sRGB color space parameters.
GIMP 2.9.2’s unbounded floating point ICC profile conversions (handle with care!)
The sRGB (the gray blob) and ProPhotoRGB (the multicolored wire-frame) color spaces as seen from different viewing angles inside the CIELAB reference color space.(Images produced using ArgyllCMS and View3DScene).
Every time you convert saturated colors from larger gamut RGB working spaces to GIMP’s built-in sRGB working space using floating point precision, you run the risk of producing out of gamut RGB channel values. Rather than just explaining how this works, it’s better if you experiment and see for yourself:
Open “saturated-colors.png” with GIMP 2.9.2. GIMP will report the color space profile as “LargeRGB-elle-V4-g18.icc” — this profile is functionally equivalent to ProPhotoRGB.
Immediately change the precision to 32-bit floating point precision (“Image/Precision/32-bit floating point) and check the “Perceptual gamma (sRGB)” option.
Using the Color Picker Tool, make sure the Color Picker is set to “Use info Window” in the Tools dialog. Then eye-dropper the color squares, and make sure to set one of the columns in the Color Picker info Window to “Pixel”. The red square will eye-dropper as (1.000000, 0.000000, 0.000000). The cyan square will eyedropper as (0.000000, 1.000000, 1.000000), and so on. All the channel values will be either 1.000000 or 0.000000.
While still at 32-bit floating point precision, and still using the “Perceptual gamma (sRGB)” option, convert “saturated-colors.png” to GIMP’s built-in sRGB.
Eyedropper the color squares again. The red square will now eyedropper as approximately (1.363299, -2.956852, -0.110389), the cyan square will eyedropper as approximately (-13.365499, 1.094588, 1.003746), and so on.
For extra credit, change the precision from 32-bit floating point “Perceptual gamma (sRGB)” to 32-bit floating point “Linear light” and eye-dropper the colors again. I will leave it to you as an exercise to figure out why the eye-droppered RGB “Pixel” values change so radically when you switch back and forth between “Perceptual gamma (sRGB)” and “Linear light”.
Where did the funny RGB channel values come from? At floating point precision, GIMP uses LCMS2 to do unbounded ICC profile conversions. This allows an RGB image to be converted from the source to the destination color space without clipping otherwise out of gamut colors. So instead of clipping the RGB channels values to the boundaries of the very small sRGB color gamut, the sRGB color gamut was effectively “unbounded”.
When you do an unbounded ICC profile conversion from a larger color space to sRGB, all the otherwise out of gamut colors are encoded using at least one sRGB channel value that is less than zero. And you might get one or more channel values that are greater than 1.0. Figure 11 below gives you a visual idea of the difference between bounded and unbounded ICC profile conversions:
Unbounded (unclipped floating point) and bounded (clipped integer) conversions of a very colorful red flower from the original ProPhotoRGB color space to the much smaller sRGB color space.(Images produced using ArgyllCMS and View3DScene).
Top row: Unbounded (unclipped floating point) and bounded (clipped integer) conversions of a very colorful red flower from the original ProPhotoRGB color space to the much smaller sRGB color space. The unclipped flower is on the left and the clipped flower is on the right.
Middle and bottom rows: the unclipped and clipped flower colors in the sRGB color space. The unclipped colors are shown on the left and the clipped colors are shown on the right:
The gray blobs are the boundaries of the sRGB color gamut.
The middle row shows the view inside CIELAB looking straight down the LAB Lightness axis.
The bottom row shows the view inside CIELAB looking along the plane formed by the LAB A and B axes.
The unclipped sRGB colors shown on the left are all encoded using at least one sRGB channel value that is less than zero, that is, using a negative RGB channel value.
When converting saturated colors from larger color spaces to sRGB, not clipping would seem to be much better than clipping. Unfortunately a whole lot of RGB editing operations don’t work when performed on negative RGB channel values. In particular, multiplying such colors produces meaningless results, which of course applies not just to the Multiply and Divide blend modes (division and multiplications are inverse operations), but to all editing operations that involve multiplication by a color (other than gray, which is a special case).
So here’s one workaround you can use to clip the out of gamut channel values: Change the precision of “saturated-colors.png” from 32-bit floating point to 32-bit integer precision (“Image/Precision/32-bit integer”). This will clip the out of gamut channel values (integer precision always clips out of gamut RGB channel values). Depending on your monitor profile’s color gamut, you might or might not see the displayed colors change appearance; on a wide-gamut monitor, the change will be obvious.
When switching to integer precision, all colors are clipped to fit within the sRGB color gamut. Switching back to floating point precision won’t restore the clipped colors.
As an important aside (and contrary to a distressingly popular assumption), when doing a normal “bounded” conversion to sRGB, using “Perceptual intent” does not “keep all the colors”. The regular and linear gamma sRGB working color space profiles are matrix profiles, which don’t have perceptual intent tables. When you ask for perceptual intent and the destination profile is a matrix profile, what you get is relative colorimetric intent, which clips.
Using GIMP 2.9.2’s floating point precision for unclamped editing
High bit depth GIMP’s unclamped editing: a whole realm of new editing possibilities
I’ve warned you about the bad things that can happen when you try to multiply or divide colors that are encoded using negative sRGB channel values. However, out of gamut sRGB channel values can also be incredibly useful.
GIMP 2.9.2 does provide a number of “unclamped” editing operations from which the clipping code in the equivalent GIMP 2.8 operation has been removed. For example, at floating point precision, the Levels upper and lower sliders, Unsharp Mask, Channel Mixer and “Colors/Desaturate/Luminance” do not clip out of gamut RGB channel values (however, Curves does clip). Also the Normal, Lightness, Chroma, and Hue blend modes do not clip out of gamut channel values.
Unclamped editing operations might sound more arcane than interesting, but especially for photographers this is a really big deal:
Automatically clipped RGB data produces lost detail and causes hue and saturation shifts.
Unclamped editing operations allow you, the photographer, to choose when and how to bring the colors back into gamut.
Of interest to photographers and digital artists alike, unclamped editing sets the stage for (and already allows very rudimentary) HDR scene-referred image image editing.
Having used high bit depth GIMP for quite a while now, I can’t imagine going back to editing that is constrained to only using clipped RGB channel values. The Autumn colors tutorial provides a start-to-finish editing example making full use of unclamped editing and the LCH blend modes, with a downloadable XCF file so you can follow along.
If the thought of working with unclamped RGB data is unappealing, use integer precision
If working with unclamped RGB channel data is simply not something you want to do, then use integer precision for all your image editing. At integer precision all editing operations clip. This is a function of integer encoding and so happens regardless of whether the particular editing function includes or doesn’t include clipping code.
Looking to the future: GIMP 3.0 and beyond
Even though GIMP 2.10 hasn’t yet been released, high bit depth GIMP is already an amazing image editor. GIMP 3.0 and beyond will bring many more changes, including the port to GTK+3 (for GIMP 3.0), full color management for any well-behaved RGB working space (maybe by 3.2?), plus extended LCH processing with HSV strictly for use with legacy files. Also users will eventually have the ability to choose “Perceptual” encodings other than the sRGB TRC.
If you would like to see GIMP 3.0 and beyond arrive sooner rather than later, GIMP is coded, documented, and maintained by volunteers, and GIMP needs more developers. If you are not a programmer, there are many other ways you can contribute to GIMP development.
Also, wallpapers and darktable 2.0 creeps even closer!
I got busy building a birthday present for a project I work with and all sort of neat things happened in my absence!
The UbuntuFree Culture Showcase chose winners for it’s wallpaper contest for Ubuntu 15.10 ‘Wily Werewolf’ (and quite a few community members were among those chosen).
Back in early September I posted on discuss about the Ubuntu Free Culture Showcase that was looking for wallpaper submissions from the free software community to coincide with the release of Ubuntu 15.10 ‘Wily Werewolf’.
The winners were recently chosen from among the submissions and several of our community members had their images chosen!
A big congratulations to you all for some amazing images being chosen!
If you’re running Ubuntu 15.10, you can grab the ubuntu-wallpapers package to get these images right here!
This past weekend GIMP celebrated it’s 20th anniversary!
It was twenty years ago on November 21st that Peter Mattis announced the availability of the “General Image Manipulation Program” on comp.os.linux.development.apps.
Twenty years later and GIMP doesn’t look a day older than a 1.0 release!
(Yes, there’s a double entendre there).
To celebrate, I’ve been spending the past couple of months getting a brand new website and infrastructure built for the project!
Just in case anyone was wondering where I was or why I was so quiet.
I like the way it turned out and is shaping up so go have a look if you get a moment!
To coincide with the 20th anniversary, the team also released a new stable version in the 2.8 series: 2.8.16.
Head over to the downloads page to pick up a copy!!
Still working hard and fast on PhotoFlow, Andreas took some time to record a new video tutorial.
He walks through some basic usage of the program, in particular opening an image, adding layers and layer masks, and saving the results.
Have a look and if you have a moment give him some feedback!
Andreas is working on PhotoFlow at a very fast pace, so expect some more news about his progress very soon!
Some awesome updates from the community and activity over on the forums!
People have been busy doing some really neat things (that really never fail to astound me).
The level of expertise we have floating around on so many topics is quite inspiring.
A nice Halloween weekend gift for the F/OSS photo community from darktable: a first Release Candidate for a 2.0 release is now available!
Houz made the announcement on the forums this past weekend and includes some caveats. (Edits will be preserved going up, but it won’t be possible to downgrade back to 1.6.x).
Because apparently David Tschumperlé doesn’t sleep, a new release of G’MIC was recently announced as well!
This release includes a really neat new patch-based texture resynthesizer that David has been playing with for a while now.
Re-synthesizing an input texture to an output of arbitrary size.
It will build an output texture of arbitrary size based on an input texture (and can result in some neat looking peppers apparently).
Yes, I know it’s Adobe.
Still, I can’t help but think that this might be an awesome way to introduce some people to the amazing work being done by so many F/OSS creators.
Tobias Fleischer announced on this post that he has managed to get G’MIC working with After Effects and Premier Pro.
Even some of the more intensive filters like skeleton and Rodilius appear to be working fine (if a bit sluggish)!
You might remember PhotoFlow as the project that creator Andrea Ferrero used when writing his Blended Panorama Tutorial from a few months ago.
What you might not realize is that Andrea has also been working at a furious pace improving PhotoFlow (indeed it feels like every few days he is announcing new improvements - almost as fast as G’MIC!).
Example of PhotoFlow perspective correction.
His latest release was announced a few days ago as 0.2.3.
He’s incorporated some nice new improvements in this version:
the additon of the LMMSE demosaicing method, directly derived from the algorithm implemented in RawTherapee
an impulse noise (also known as salt&pepper) reduction tool, again derived from rawTherapee. It effectively reduces isolated bright and dark pixels.
a perspective correction tool, derived from Darktable. It can simultaneously correct horizontal and vertical perspective as well as tilting, and works interactively.
We don’t hear as often from folks using LightZone, but that doesn’t mean they’re not working on things!
In fact, Doug Pardee just stopped by the forums a while ago to announce a new release is available, 4.1.3.
(Bonus fun - read that topic to see the Revised BSD License go flying right over my head!)
Damon is working hard on the next release of RPD (apparently the biggest update since the projects inception in 2007!), so go show some support and provide some feedback for him.
The RawTherapee team is testing out having a forum over here on discuss as well (we welcomed the G’MIC community a little while ago).
This is currently an alternate forum for the project (which may become the official forum in the future).
The category is quiet as we only just set it up, so drop by and say hello!
As announced on the GIMP users and developers mailing lists, the recent (November 26, 2015) GIMP 2.9.2 release is the first development release in the GIMP 2.9.x series leading to GIMP 2.10. The release announcement summarizes the many code changes that were made to port the old GIMP code over to GEGL’s high bit depth processing.
This user’s guide to high bit depth GIMP 2.9.2 introduces you to some of high bit depth GIMP’s new editing capabilities that are made possible by GEGL’s high bit depth processing. The guide also points out a few “gotchas” that you should be aware of. Please keep in mind that GIMP 2.9 really is a development branch, so many things don’t yet work exactly like they will work when GIMP 2.10 is released.
Useful links: the official GIMP website, builds for Windows and MAC, building GIMP on Linux
Precompiled versions of high bit depth GIMP are more or less widely available for the various Linux operating systems. If you run Linux and you’d like to compile high bit depth GIMP yourself, Building GIMP for artists and photographers has step-by-step instructions.
High bit depth GIMP is a work in progress. If you read the release notes for GIMP 2.9.2, you already know that the primary goal for the GIMP 2.10 release is full “Geglification” of the GIMP code base.
Editing in sRGB vs editing in other color spaces
For best results when using GIMP 2.9.2, only edit sRGB images.
GIMP 2.8 has hard-coded sRGB parameters that make many editing operations produce wrong results for images that are in RGB working spaces other than sRGB. GIMP 2.9.2 still has these hard-coded sRGB parameters. Almost certainly GIMP 2.10 also will have these same hard-coded sRGB parameters.
Full support for editing images in other RGB working spaces won’t happen
at least until GIMP 3.0, and maybe not until some time after GIMP 3.0.
The next big change for GIMP will be the change-over from GTK+2 to
GTK+3, which is a pretty critical step to make as GTK+2 is on the verge
of being retired. GIMP development is a volunteer effort, porting GIMP
over to GEGL has required an enormous amount of work, and porting from
GTK+2 to GTK+3 isn’t exactly a trivial task. More GIMP developers would help a lot, so if you have any coding skills, please consider volunteering.
If you really do want to edit in color spaces other than sRGB “right now”, and you are comfortable building GIMP from git, my patched version of GIMP 2.9 is hard-coded to use the much larger Rec.2020 color space, and it should be obvious how to modify the patches for other RGB working spaces.
A note about the “Gamma hack” that’s provided for many editing operations
A “Gamma hack” option is provided by many GIMP 2.9.2 editing operations. This option sits next to some text that says “(temp hack, please ignore)”. Unless you know exactly what you are doing, you really are better off not using the Gamma hack.
New high bit depth precision options
Menu for choosing the image precision
As shown by the screenshot below, GIMP 2.9.2 offers six different image precisions:
Three integer precisions: 8-bit integer, 16-bit integer, and 32-bit integer.
Three floating point precisions: 16-bit floating point, 32-bit floating point, and 64-bit floating point.
If you have a fast computer with a lot of RAM, I recommend that you always promote your images to 32-bit floating point before you begin editing. Here’s why:
Regardless of which precision you choose, all babl/GEGL/GIMP internal processing is done at 32-bit floating point. Read that sentence three times.
The Precision menu options dictate how much memory is used to store in RAM the results of internal calculations:
Choosing 32-bit floating point precision allows you to take full advantage of GEGL’s 32-bit floating point processing.
If you are working on a lower-RAM machine, performance will benefit from using 16-bit floating point or integer precision, but of course the price is a loss in precision as new editing operations use the results of previous edits as stored in memory.
On very low RAM systems, performance will benefit even more from using 8-bit integer precision. But if you use 8-bit integer precision, you are throwing away most of the advantages of working with a high bit depth image editor.
64-bit precision is made available mostly to accommodate importing and exporting very high bit precision images for scientific editing. You don’t gain any computational precision from using 64-bit precision for actual editing. If you choose 64-bit precision for editing, all you are really doing is wasting system RAM resources.
As discussed in Part 2 of this article, “Using GIMP 2.9.2’s floating point precision for unclamped editing” (and depending on your editing style and goals), instead of 32-bit floating point precision, sometimes you might prefer using 16-bit or 32-bit integer precision. But making full use of all of high bit depth GIMP’s new editing capabilities does require using floating point precision.
Sometimes people assume that floating point is “more precise” than integer, but this isn’t actually true: At any given bit-depth, integer precision is more precise than floating point precision, but uses about the same amount of RAM:
16-bit integer precision is more precise than 16-bit floating point precision, and the two precisions use about the same amount of RAM.
32-bit integer is more precise than 32-bit floating point precision, and the two precisions use about the same amount of RAM.
GEGL/GIMP’s internal processing uses 32-bit floating point precision, so both of GIMP’s 32-bit precisions actually provide the same degree of precision.
Using the image precision options when exporting an image to disk
The precision menu options have another extremely important use beside dictating the precision with which the results of editing operations are held in RAM. When you export the image to disk, the precision options allow you to change the bit depth of the exported image.
For example, some image editors can’t read floating point tiffs. So if you want to export an image as a tiff file that will be opened in another image editor that can only read 8-bit and 16-bit integer tiffs, and your GIMP XCF layer stack is currently using 32-bit floating point precision, you might want to change the XCF layer stack precision to 16-bit integer before exporting the tiff.
After exporting the image, don’t forget to hit “UNDO” (“Edit/Undo . . . “, or else just use the CNTL-Z keyboard shortcut) to get back to 32-bit floating point precision (or whatever other precision you were using).
New color management options
GIMP 2.9.2 automatically detects camera DCF information
For reasons only the camera manufacturers know, instead of embedding a proper ICC profile in camera-saved jpegs, usually they embed “DCF” and “maker note” information. Whenever a camera manufacturer offers the option to embed a color space that isn’t officially supported by the DCF/Exif standards, each manufacturer feels free to improvise with new tags.
GIMP 2.9.2 does detect and assign the correct color space for most camera-saved jpegs. Like all editing software, GIMP has to play “catch up” with new tags for new color spaces offered by new camera models.
Tell your camera manufacturer that you want proper ICC profiles embedded in your camera-saved jpegs.
Black point compensation
Unlike GIMP 2.8, GIMP 2.9 does offer black point compensation as an explicit option, and it’s enabled by default.
GIMP 2.9 offers black point compensation as an explicit option.
As an aside, GIMP 2.8 actually did offer black point compensation, but in a very round-about way: In GIMP 2.8, if you used the default “Perceptual intent” for the Display rendering intent, then black point compensation was disabled. And if you chose “Relative colorimetric” for the Display rendering intent, then black point compensation was enabled.
Even though black point compensation is checked by default in GIMP 2.9.2, whether you should use black point compensation partly depends on the color management settings provided by the other imaging software that you routinely use. For example, Firefox doesn’t provide for black point compensation. As far as I can tell, neither does RawTherapee or darktable. If one of your goals is to make sure that images look the same as displayed in various softwares, you need to make sure all the relevant color management settings match.
What is black point compensation? LCD monitors can’t display “zero light”. There’s always some minimum amount of light coming from the screen. Fill your screen with a solid black image, turn out all the lights and close the doors and curtains, and you’ll see what I mean.
Black point compensation compensates for the fact that RGB working spaces like sRGB allow you to produce colors (for example solid black) that are darker than your monitor can actually display. GIMP uses the LCMS black point compensation algorithm, which very sensibly scales the image tonality so that “solid black” in the image file maps to “darkest dark” in the monitor profile’s color gamut.
Non-zero and zero black points(images produced using icc_examin and ArgyllCMS).
However, depending on your monitor profile, using or not using black point compensation might not make any difference at all. The only time black point compensation makes a difference is if the Monitor profile you choose in “Preferences/Color management” actually does have a “higher than zero” black point.
Why some monitor profiles do and some don’t have “higher than zero” black points is beyond the scope of this tutorial. Suffice it to say that a very accurate LCD monitor profile will always have a higher than zero black point. But sometimes, and especially for consumer-grade monitors, a very accurate monitor profile will make displayed images look worse than they will when using a less accurate monitor profile.
New and updated algorithms for converting to Luminance, LAB, and LCH
Converting sRGB images from Color to Black and White using Luma and Luminance
Under “Colors/Desaturate”, GIMP 2.8 offers three options for converting an sRGB image to black and white: Lightness, Luminosity, and Average:
The “Lightness” option adds the lowest and highest RGB channel values and divides the result by two.
The “Luminosity” option is equal to (the Red channel times 0.213) plus (the Green channel times 0.715) plus (the Blue channel times 0.072).
The “Average” option sums all three RGB channel values and divides the result by three.
Also GIMP 2.9.2’s “Luma” option uses slightly different multipliers for calculating Luma, being (the Red channel times 0.222) plus (the Green channel times 0.717) plus (the Blue channel times 0.061). The GIMP 2.8 multipliers were wrong and the GIMP 2.9 multipliers are correct.
Since I know you won’t be able to get any sleep until someone tells you why the multipliers for calculating Luma were changed, the GIMP 2.9 multipliers have been Bradford-adapted from D65 to D50, which is required for use in an ICC profile color-managed editing application (at least until the next version of the ICC specs is released and people figure out how to deal with the new freedom to use non-D50 reference white points).
GIMP 2.9.2 also offers a fourth option for converting sRGB images to black and white, which is “Luminance”. “Luminance” is short for relative luminance. Luminance is calculated using the same channel multipliers that are used to calculate Luma. The mathematical difference between calculating Luma and Luminance is as follows:
Luma is calculated using RGB channel values that are encoded using the sRGB TRC.
Luminance is calculated using linearized RGB channel values, producing a radiometrically correct and physically meaningful conversion from color to black and white.
Of the various options in the “Colors/Desaturate” menu, “Luminance” is the only physically meaningful way to convert from color to black and white.
The Red, Blue, and Green Luma and Luminance channel multipliers are specific to the sRGB color space. These channel multipliers are actually the “Y” components of the sRGB ICC profile’s XYZ primaries. As you might expect, different RGB working spaces have different “Y” values, and so the GIMP 2.9.2 conversions to Luma and Luminance only produce correct results for sRGB images.
GIMP 2.9 sRGB Luminance and Luma conversions to black and white
Click to compare sRGB Luminance and Luma conversions to black and white: 1. “Colors/Desaturate/Luminance” conversion to black and white2. “Colors/Desaturate/Luma” conversion to black and white
Decomposing from sRGB to LAB
Decomposing to LAB does use hard-coded sRGB parameters and so will produce wrong results in other RGB working spaces.
In GIMP 2.8, decomposing an sRGB image to LAB produced flatly wrong results.
In GIMP 2.9.2, decomposing an sRGB image to LAB does produce mathematically correct results. But if you use “drag and drop” to pull the decomposed grayscale layers over to your sRGB layer stack, there is still a small error in the resulting RGB layer. Figure 3 below illustrates the problem:
Decomposing to LAB and retrieving the LAB Lightness (“L”) channel Click the links below the image to see the original color image and the results of decomposing to LAB plus “dragging and dropping the L channel” in GIMP 2.8 vs GIMP 2.9.1. Mathematically correct conversion to LAB Lightness2. GIMP 2.9.2 decompose to LAB + drag and drop (a little wrong)3. GIMP 2.8 decompose to LAB + drag and drop (not done on linearized RGB, so results are very wrong)4. The original color layer that was decomposed to LAB5. Difference between the LAB and sRGB companding curves (the reason why “drag and drop” in GIMP 2.9 produces slightly wrong results)
Assuming you start with an image in the regular sRGB color space, then:
In GIMP 2.9.2, decomposing a layer to LAB in GIMP 2.9 produces mathematically correct results.
However, dragging the resulting grayscale channels back to the RGB XCF color stack results in a slightly wrong result. This is because the dropped grayscale layer(s), which don’t have an embedded ICC profile, are assumed to be encoded using the sRGB companding curve (Tone Reproduction Curve, “TRC”), when really they are encoded using the LAB companding curve. This is a color management problem that can be solved by enabling GIMP to do grayscale color management (all that’s needed is a little developer time — did I mention that GIMP really does need more developers?).
As an incredibly important aside, a mathematically correct conversion from sRGB to LAB Lightness and back to sRGB produces exactly the same thing as using GIMP 2.9.2’s “Colors/Desaturate/Luminance” option to change an sRGB image from color to black and white.
In GIMP 2.8, decomposing a layer to LAB produces wildly mathematically incorrect results, and dragging the resulting channel(s) back to the RGB XCF color stack also produces wildly mathematically incorrect results. So older GIMP tutorials on using the LAB Lightness channel to convert an image to black and white won’t produce anywhere near the same results when using GIMP 2.9/GIMP 2.10.
If you’d like to know more about “LAB Lightness to black and white”, the following two-part article untangles the massive amounts of confusion regarding converting an RGB image to black and white using the LAB Lightness channel:
“LCH” stands for “Lightness, Chroma, Hue”. LCH is mathematically derived from the CIELAB reference color space, which in turn is a perceptually uniform transform of the CIEXYZ reference color space. Unlike HSV, LCH is a physically meaningful color space that allows you to edit separately for color and tonality.
Very roughly speaking:
LCH Lightness corresponds to HSV Value.
LCH Chroma corresponds to HSV Saturation.
LCH Hue corresponds to HSV Hue (the names are the same, but the two blend modes are based on very different mathematics).
LCH Color is a combination of LCH Chroma and Hue, and corresponds to HSV Color, which is a combination of HSV Hue and Saturation (again, the names are the same, but the two blend modes are based on very different mathematics).
LCH blend modes and painting are a game-changing addition to high bit depth GIMP editing capabilities. If you’d like to see examples of what you can do with LCH, that you can’t even come close to doing with HSV, I’ve written a couple of tutorials on using GIMP’s LCH color space capabilities:
A tutorial on GIMP’s very awesome LCH Blend Modes, which shows how to use GIMP’s new LCH blend modes to repair a badly damaged image, and then to colorize a black and white rendering of the image.
Restoring color to a damaged image: LCH Color blend mode vs the HSV Color blend mode: The LCH Color blend mode produces smooth, believable color transitions. The HSV Color blend mode produces very splotchy results.
Changing an image’s color: LCH Color blend mode vs HSV Color blend mode: The LCH Color blend mode changes the image color without modifying the image tonality, whereas the HSV Color blend mode simultaneously changes tonality along with color (HSV blending with blue made the tonality darker, HSV blending with yellow made the tonality lighter).
I’m not an especially skilled programmer. In fact I find writing code to be a painfully slow exercise. But one major reason why I maintain a patched version of high bit depth GIMP is precisely so I can use the LCH color space not just for blending and painting, but also for picking colors and as a replacement for the essentially useless HSV “Hue-Saturation” tool. These particular editing capabilities will eventually make it into an official GIMP release, but I didn’t want to wait for “eventually” to happen.
Click here to go to Part 2 of this guide to GIMP 2.9.2! Part 2 discusses using GIMP 2.9.2 to do radiometrically correct editing, unbounded ICC profile conversions, and unclamped editing.
Login
