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).
Preliminary notes from houz (and Github):
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.
It will build an output texture of arbitrary size based on an input texture (and can result in some neat looking peppers apparently).
Speaking of G’MIC…
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!).
His latest release was announced a few days ago as 0.2.3. He’s incorporated some nice new improvements in this version:
Head on over to the PhotoFlow Blog to check things out!
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!)
Head over to [their announcement] to see what they’re up to. [their announcement]: http://lightzoneproject.org/content/september-27-2015-lightzone-v413-now-available
We also had the developer of Rapid Photo Downloader, Damon Lynch, stop by the forums to solicit feedback from users just the other day. A nice discussion ensued and is well worth reading (or even contributing to!).
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!
Speaking of RawTherapee…
I want to thank Morgan Hardwood (LondonLight.org) for providing us a wonderful view of Röstånga, Sweden as a background image on the main page.
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.
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.
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 “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.
As shown by the screenshot below, GIMP 2.9.2 offers six different image precisions:
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:
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:
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.
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).
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.
Unlike GIMP 2.8, GIMP 2.9 does offer black point compensation as an explicit option, and it’s enabled by default.
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.
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.
Under “Colors/Desaturate”, GIMP 2.8 offers three options for converting an sRGB image to black and white: Lightness, Luminosity, and Average:
GIMP 2.9.2 still offers all three options for converting an sRGB image to black and white. But the “Luminosity” option has been renamed Luma, which is the technically correct term (though various image editors use the term “Luminosity” in various incorrect ways.
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:
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.
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:
Assuming you start with an image in the regular sRGB color space, then:
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.
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 calculations do use hard-coded sRGB parameters, and so will produce wrong results in other RGB working spaces.
HSV (“Hue/Saturation/Value”) is a sad little color space designed for fast processing on slow computers, way back in the stone age of digital processing. HSV is OK for picking colors from a color wheel. But it’s really wretched for just about any other editing application, because despite the fact that “HSV” stands for “Hue/Saturation/Value”, you actually can’t adjust color and tonality separately in the HSV color space.
“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 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:
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.
All text and images ©2015 Elle Stone, all rights reserved.
Hosted on Acast. See acast.com/privacy for more information.
Many moons ago I had written about acquiring a YN-560 speedlight for playing around with off-camera lighting. At the time I wanted to experiment with how different modifiers might be used in a portrait setting. Unfortunately, these were lighting modifiers that I didn’t own yet.
I wasn’t going to let that slow me down, though!
If you want to skip the how and why to get straight to the cheat sheets, click here.
Infinite Realities had released a full 3D scan by Lee Perry-Smith of his head that was graciously licensed under a Creative Commons Attribution 3.0 Unported License. For reference, here is a link to the object file and textures (80MB) and the displacement maps (65MB) from the Infinite Realities website.
What I did was to bring the high resolution scan and displacement maps into Blender and manually created my lights with modifiers in a virtual space. Then I could simply render what a particular light/modifier would look like with a realistic person being lit in any way I wanted.
This leads to all sorts of neat freedom to experiment with things to see how they might come out. Here’s another look at the lede image:
I had originally intended to make a nice bundled application that would allow someone to try all sorts of different lighting setups, but my skill in Blender only go so far. My skills at convincing others to help me didn’t go very far either. :)
So, if you’re ok with navigating around Blender already, feel free to check out my original blog post to download the .blend file and give it try! Jimmy Gunawan even took it further and modified the .blend to work with Blender cycles rendering as well.
With the power to create a lighting visualization of any scenario I then had to see if there was something cool I could make for others to use…
I couldn’t help but generate some lighting cheat sheets to help others use as a reference. I’ve seen some different ones around but I took advantage of having the most patient model in the world to do this with. :)
These were generated by rotating a 20” (virtual) softbox in a circle around the subject at 3 different elevations (0, 30°, and 60°).
Click the caption title for a link to the full resolution files:
Hopefully these might prove useful as a reference for some folks. Share them, print them out, tape them to your lighting setups! :) I wonder if we could get some cool folks from the community to make something neat with them?
Login
