Some of you may know I exclusively use Contax manual focus lenses on my Canon cameras. I have had one reliable adapter from the start, that just happened to be perfect in every way: perfectly parallel, and lets my lenses focus exactly to infinity, and none of my lenses hit the mirror on my 5D.
However, swapping adapters between cameras gets mighty tedious, so recently I have been trying a variety of different adapters for my cameras, several quality tiers ranging from the cheapest ($15) up to the most expensive ($70).
However, I wasn’t satisfied with any of them. In order to assure that the adapted lenses can focus to infinity even with manufacturing tolerances, they’re made thinner than necessary. This means that they focus past infinity, and with some lenses the mirror of my 5D would hit the back of the lens, needing me to wiggle it to free the mirror after taking a photo.
I measured my fancier Fotodiox Pro adapter, and found that not only was it too thin, but it was unevenly thick! The top was 8 thousandths of an inch thin, the bottom right was 2 thousandth of an inch thin, and the bottom left was exactly the right thickness.
I decided I could do something about it.
I bought some shim stock from McMaster Carr, plastic and 2 thousandths of an inch thick, figuring I might be able to fold it to build up thickness if necessary. (Spoiler: it does fold.) It comes as a giant sheet five by twenty inches, but you’ll only need the tiniest amount of it.
Then I went about removing the screws that hold the two sides together.
The screws are incredibly small.
Here you can see that there are only three points on the ring that actually control the thickness; I point to one with the scissors. I had to be careful when measuring the thickness to only measure it between the screws, and that was challenging because the EF mount diameter is larger than the C/Y mount diameter, and there was only the slightest overlap between the outside of the C/Y registration surface and the inside of the EF mount.
Next I just cut a narrow strip out of this piece of shim stock using scissors, and put slits in it so it could fold more easily.
The right hand shim is folded in the shape of a W, and the left hand shim is only one layer.
The thicker shim went on the top, and the thinner shim went on the bottom-right.
Put the ring back on, and then…
Reinstall the screws.
Test your lenses for infinity focus and, if applicable, mirror slap, and rejoice if they’re good!
If you don’t have a perfect adapter as a reference for the proper thickness, you can first adjust the adapter to be perfectly even thickness all the way around, and then you can add thickness uniformly until your lenses just barely focus to infinity. It might be time consuming, but it’s very rewarding being able to trust the infinity stop on your lenses.
This method isn’t only applicable to the two-part SLR->SLR Fotodiox adapters; it should also work for SLR or rangefinder to mirrorless adapters as well.
I’ve seen it written that you can’t be sure whether or not your adapters are even thickness all the way around, but with this technique, you can make sure that your adapters are perfect.
Carlo originally posted this as a thread on the forums but I thought it would be useful as a post. He has graciously allowed us to re-publish it here. –Pat
Mike Howard, the host and creator of the jpeg2RAW podcast reached out to me last week to see if I might be able to come on the show to talk about Free Software Photography and what we’ve been up to here.
One of the primary reasons for creating this site was to be able to raise awareness of the Free Software community to a wider audience.
So this is a great opportunity for us to expose ourselves!
The podcast airs live this Tuesday, February 23rd at 8PM Eastern (-0500). You can join us at the jpeg2RAW live podcast page!
Mike has the live feed available to watch on that page and also has a chat server set up so viewers can interact with us live during the broadcast.
If you are free on Tuesday night then come on by and join us! I’ll be happy to field any questions you want answered (and that Mike asks) and will do my best to not embarrass myself (or our community). If you would like to make sure I address something in particular (or just don’t forget something), I also have a thread on discuss where you can make sure I know it.
I’m also looking for community members to submit some photos to help highlight our work and what’s possible with Free Software. Feel free to link them in the same thread as above. I’ve already convinced andabata to point us to some of his great macro shots (like that awesome lede image) and I’ll be submitting a few of my own images as well. If you have some works that you’d like to share please let me know!
Mike has all of his prior podcasts archived on his Podcasts page. So if you miss the live show it looks like you’ll be able to catch up later at your convenience.
As mentioned previously we are heading to London for Libre Graphics Meeting 2016! We’ve got a flat rented for a great crew to be able to stay together and we’re on track for a PIXLS meet up before LGM!
Speaking of people, I’m looking forward to being able to spend some time with some great folks again this year! We’ve got Tobias, Johannes, and Pascal making it out (I’m not sure that Simon, top below, will be making it out) from darktable, DrSlony and qogniw from RawTherapee, Andrea Ferrero creator of PhotoFlow, even Ofnuts (how cool is that?) may make it out!
Pascal, Johannes, and Tobias (left to right, bottom row) will be there!
We’ve also already had a great response so far on our Pledgie campaign. The campaign is still running if you want to help out!
If anyone is thinking they’d like to make it out to join us, please let me know as soon as possible so we can plan for space!
My friend and model Mairi will also be making it out for the meeting. She’ll be on hand to help us practice lighting setups, model interactions, and will likely be shooting right along with the rest of us as well!
I’ll also be assembling slides for my presentation during LGM. I’ve got a 20 minute time slot to talk about the community we’ve been building here and the neat things our members have been up to (Filmulator, PhotoFlow, and more).
I’ve setup a Github Pixls organization so that we can begin to share various things. This came about after talking with @paperdigits on the post about the upcoming podcast at jpeg2RAW. We were talking about ways to share information and assets for creating/delivering presentations about Free Software photography.
At the moment there is only the single repository Presentations as we are figuring out structure. I’ve uploaded my slides and notes from the LGM2015 State of the Libre Graphics presentation announcing PIXLS. If you’re on Github and want to join us just let me know!
A first approach to creating and mapping HDR images
I have a mostly love/hate relationship with HDR images (well, tonemapping HDR more than the HDR themselves).
I think the problem is that it’s very easy to create really bad HDR images that the photographer thinks look really good.
I know because I’ve been there:
Don’t judge me, it was a weird time in my life…
The best term I’ve heard used to describe over-processed images created from an HDR is “clown vomit” (which would also be a great name for a band, by the way).
They are easily spotted with some tell-tale signs such as the halos at high-contrast edges, the unrealistically hyper-saturated colors that make your eyes bleed, and a general affront to good taste.
In fact, while I’m putting up embarrassing images that I’ve done in the past, here’s one that scores on all the points for a crappy image from an HDR:
Crap-tastic!
Of course, the allure here is that it provides first timers a glimpse into something new, and they feel the desire to crank every setting up to 11 with no regards to good taste or aesthetics.
If you take anything away from this post, let it be this: “Turn it DOWN“.
If it looks good to you, then it’s too much. ;)
HDR lightprobes are used in movie fx compositing to ensure that the lighting on CG models matches exactly the lighting for a live-action scene. By using an HDR lightprobe, you can match the lighting exactly to what is filmed.
I originally learned about, and used, HDR images when I would use them to illuminate a scene in Blender. In fact, I will still often use Paul Debevec’s Uffizi gallery lightprobe to light scene renders in Blender today.
For example, you may be able to record 10-12 stops of light information using a modern camera. Some old films could record 12-13 stops of light, while your eyes can approximately see up to 14 stops.
HDR images are intended to capture more than this number of stops. (Depending on your patience, significantly more in some cases).
I can go on a bit about the technical aspects of HDR imaging, but I won’t. It’s boring. Plus, I’m sure you can use Wikipedia, or Google yourselves. :)
In the end, just realize that an HDR image is simply one where there is a greater amount of light information being stored than is able to be captured by your camera sensor in one shot.
Taking an HDR image(s)
More light information than my camera can record in one shot? Then how do I take an HDR photo?
You don’t.
You take multiple photos of a scene, and combine them to create the final HDR image.
Before I get into the process of capturing these photos to create an HDR with, consider something:
When/Why to use HDR
An HDR image is most useful to you when the scene you want to capture has bright and dark areas that fall outside the range of a single exposure, and you feel that there is something important enough outside that range to include in your final image.
That last part is important, because sometimes it’s OK to have some of your photo be too dark for details (or too light). This is an aesthetic decision of course, but keep it in mind…
Here’s what happens. Say you have a pretty scene you would like to photograph. Maybe it’s the Lower Chapel of Sainte Chapelle:
You may setup to take the shot, but when you are setting your exposure you may run into a problem. To expose for the brighter parts of the image means that the shadows fall to black too quickly, crushing out the details there.
If you expose for the shadows, then the brighter parts of the image quickly clip beyond white.
The use case for an HDR is when you can’t find a happy medium between those two exposures.
A similar situation comes up when you want to shoot any ground details against a bright sky, but you want to keep the details in both. Have a look at this example:
In the first column, if you expose for the ground, the sky blows out.
In the second, you can drop the exposure to bring the sky in a bit, but the ground is getting too dark.
In the third, the sky is exposed nicely, but the ground has gone to mostly black.
If you wanted to keep the details in the sky and ground at the same time, you might use an HDR (you could technically also use exposure blending with just a couple of exposures and blend them by hand, but I digress) to arrive at the last column.
Shooting Images for an HDR
Many cameras have an auto-bracketing feature that will let you quickly shoot a number of photos while changing the exposure value (EV) of each. You can also do this by hand simply by changing one parameter of your exposure each time.
You can technically change any of ISO, shutter speed, or aperture to modify the exposure, but I’d recommend you change only the shutter speed (or EV value when in Aperture Priority modes).
The reason is that changing the shutter speed will not alter the depth-of-field (DoF) of your view or introduce any extra noise the way changing the aperture or ISO would.
When considering your scene, you will also want to try to stick to static scenes if possible.
The reason is that objects that move around (swaying trees, people, cars, fast moving clouds, etc.) could end up as ghosts or mis-alignments in your final image.
So as you’re starting out, choose your scene to help you achieve success.
Set up your camera someplace very steady (like a tripod), dial in your exposure and take a shot.
If you let your camera meter your scene for you then this is a good middle starting point.
For example, if you setup your camera and meter your scene, it might report a 1⁄160 second exposure. This is our starting point (0EV).
The base exposure, 1⁄160 s, 0EV
To capture the lower values, just cut your shutter speed in half ( 1⁄80 second, +1EV), and take a photo. Repeat if you’d like ( 1⁄40 second, +2EV).
To capture the upper values, just double your starting point shutter speed ( 1⁄320, -1EV) and take a photo. Repeat if you’d like again ( 1⁄640, -2EV).
1⁄320, -1EV (left), 1⁄640, -2EV (right)
This will give you 5 images covering a range of -2EV to +2EV:
Shutter Speed
Exposure Value
1⁄640
-2EV
1⁄320
-1EV
1⁄160
0EV
1⁄80
+1EV
1⁄40
+2EV
Your values don’t have to be exactly 1EV each time, LuminanceHDR is usually smart enough to figure out what’s going on from the EXIF data in your image - I chose full EV stops here to simplify the example.
So armed with your images, it’s time to turn them into an HDR image!
Creating an HDR Image
You kids have it too easy these days. We used to have to bring all the images into Hugin and align them before we could save an hdr/exr file. Nowadays you’ve got a phenomenal piece of Free/Open Source Software to handle this for you:
After installing it, open it up and hit “New HDR Image“:
This will open up the “HDR Creation Wizard” that will walk you through the steps of creating the HDR. The splash screen notes a couple of constraints.
On the next screen, you’ll be able to load up all of the images in your stack. Just hit the big green “+“ button in the middle, and choose all of your images:
LuminanceHDR will load up each of your files, and investigate them to try and determine the EV values for each one. It usually does a good job of this on its own, but if there a problem you can always manually specify what the actual EV value is for each image.
Also notice that because I only adjusted my shutter speed by half or double, that each of the relative EV values is neatly spaced 1EV apart. They don’t have to be, though. I could have just as easily done ½ EV or ⅓ EV steps as well.
If there is even the remotest question about how well your images will line up, I’d recommend that you check the box for “Autoalign images”, and let Hugin’s align_image_stack do it’s magic.
You really need all of your images to line up perfectly for the best results.
Hit “Next“, and if you are aligning the images be patient.
Hugin’s align_image_stack will find control points between the images and remap them so they are all aligned.
When it’s done you’ll be presented with some editing tools to tweak the final result before the HDR is created.
You are basically looking at a difference view between images in your stack at the moment. You can choose which two images to difference compare by choosing them in the list on the left. You can now shift an image horizontally/vertically if it’s needed, or even generate a ghosting mask (a mask to handle portions of an image where objects may have shifted between frames).
If you are careful, and there’s not much movement in your image stacks, then you can safely click through this screen. Hit the “Next“ button.
This is the final screen of the HDR Creation Wizard.
There are a few different ways to calculate the pixel values that make up an HDR image, and this is where you can choose which ones to use.
For the most part, people far smarter than I had a look at a bunch of creation methods, and created the predefined profiles.
Unless you know what you’re doing, I would stick with those.
Hit “Finish“, and you’re all done!
You’ll now be presented with your HDR image in LuminanceHDR, ready to be tonemapped so us mere mortals can actually make sense of the HDR values present in the image.
At this point, I would hit the “Save As…” button, and save your work.
Tonemapping the HDR
So now you’ve got an HDR image. Congratulations!
The problem is, you can’t really view it with your puny little monitor.
The reason is that the HDRi now contains more information than can be represented within the limited range of your monitor (and eyeballs, likely). So we need to find a way to represent all of that extra light-goodness so that we can actually view it on our monitors. This is where tonemapping comes in.
We basically have to take our HDRi and use a method for compressing all of that radiance data down into something we can view on our monitors/prints/eyeballs. We need to create a Low Dynamic Range (LDR) image from our HDR.
Yes - we just went through all the trouble of stacking together a bunch of LDR images to create the HDRi, and now we’re going back to LDR ? We are - but this time we are armed with way more radiance data than we had to begin with!
The question is, how do we represent all that extra data in an LDR? Well, there’s quite a few different ways. LuminanceHDR provides for 9 different tonemapping operators (TMO’s) to represent your HDRi as an LDR image:
Just a small reminder, there’s a ton of math involved in how to map these values to an LDR image.
I’m going to skip the math.
The references are out there if you want them.
I’ll try to give examples of each of the operators below, and a little comment here and there. If you want more information, you can always check out the list on the Open Source Photography wikidot page.
Before we get started, let’s have a look at the window we’ll be working in:
Tonemap is the section where you can choose which TMO you want to use, and will expose the various parameters you can change for each TMO. This is the section you will likely be spending most of your time, tweaking the settings for whichever TMO you decide to play with.
Process gives you two things you’ll want to adjust. The first is the size of the output that you want to create (Result Size). While you are trying things out and dialing in settings you’ll probably want to use a smaller size here (some operators will take a while to run against the full resolution image). The second is any pre-gamma you want to apply to the image. I’ll talk about this setting a bit later on.
Oh, and this section also has the “Tonemap” button to apply your settings and generate a preview. I’ll also usually keep the “Update current LDR” checked while I rough in parameters. When I’m fine-tuning I may uncheck this (it will create a new image every time you hit the “Tonemap” button).
Results are shown in this big center section of the window. The result will be whatever Result Size you set in the previous section.
Previews are automatically generated and shown in this column for each of the TMO. If you click on one, it will automatically apply that TMO to your image and display it (at a reduced resolution - I think the default is 400px, but you can change it if you want). It’s a nice way to quickly get a preview overview of what all the different TMOs are doing to your image.
Ok, with that out of the way, let’s dive into the TMOs and have a look at what we can do. I’m going to try to aim for a reasonably realistic output here that (hopefully) won’t make your eyeballs bleed. No promises, though.
Need an HDR to follow along?
I figured it might be more fun (easier?) to follow along if you had the same file I do.
So here it is, don’t say I never gave you anything (This hdr is licensed cc-by-sa-nc by me):
Download from Google Drive (41MB .hdr)
Another note - all of the operators can have their results tweaked by modification of the pre-gamma value ahead of time. This is applied the image before the TMO is applied, and will make a difference in the final output. Usually pushing the pre-gamma value down will increase contrast/brightness in the image, while increasing it will do the opposite. I find it better to start with pre-gamma set to 1 as I experiment, just remember that it is another factor that you use to modify your final result.
Mantiuk ‘06
I’m starting with this one because it’s the first in the list of TMOs. Let’s see what the defaults from this operator look like against our base HDRi:
Default Mantiuk ‘06 applied
By default Mantiuk ‘06 produces a muted color result that seems pleasing to my eye. Overall the image feels like it’s almost “dirty” or “gritty” with these results. The default settings produce a bit of extra local contrast boosting as well.
Let’s see what the parameters do to our image.
Contrast Factor
The default factor is 0.10.
Pushing this value down to as low as 0.01 produces just a slight increase in contrast across the image from the default. Not that much overall.
Pushing this value up, though, will tone down the contrast overall. I think this helps to add some moderation to the image, as hard contrasts can be jarring to the eyes sometimes. Here is the image with only the Contrast Factor pushed up to 0.40:
Mantiuk ‘06 - Contrast Factor increased to 0.40
(click to compare to defaults)
Saturation Factor
The default value is 0.80.
This factor just scales the saturation in the image, and behaves as expected. If you find the colors a bit muted using this TMO, you can bump this value a bit (don’t get crazy). For example, here is the Saturation Factor bumped to 1.10:
Mantiuk ‘06 - Saturation Factor increased to 1.10
(click to compare to defaults)
Of course, you can also go the other way if you want to mute the colors a bit more:
Mantiuk ‘06 - Saturation Factor decreased to 0.40
(click to compare to defaults)
Detail Factor
The default is 1.0.
The Detail Factor appears to control local contrast intensity. It gets overpowering very quickly, so make small movements here (if at all). Here is what pushing the Detail Factor up to 10.0 produces:
Don’t do this. Mantiuk ‘06 - Detail Factor increased to 10.0
(click to compare to defaults)
Contrast Equalization
This is supposed to equalize the contrast if there are heavy swings of light/dark across the image on a global scale, but in my example did little to the image (other than a strange lightening in the upper left corner).
My Final Version
I played a bit starting from the defaults. First I wanted to push down the contrast a bit to make everything just a bit more realistic, so I pushed Contrast Factor up to 0.30. I slightly bumped the Saturation Factor to 0.95 as well.
I liked the textures of the tree and house, so I wanted to bring those back up a bit after decreasing the Contrast Factor, so I pushed the Detail Factor up to 5.0.
Here is what I ended up with in the end:
My final output (Contrast 0.3, Saturation 0.95, Detail 5.0)
(click to compare to defaults)
Mantiuk ‘08
Mantiuk ‘08 is a global contrast TMO (for comparison, Mantiuk ‘06 uses local contrast heavily). Being a global operator, it’s very quick to apply.
Default Mantiuk ‘08 applied
As you can see, the effect of this TMO is to compress the dynamic range into an LDR output using a function that operates across the entire image globally. This will produce a more realistic result I think, overall.
The default output is not bad at all, where brights seem appropriately bright, and darks are dark while still retaining details. It does feel like the resulting output is a little over-sharp to my eye, however.
There are only a couple of parameters for this TMO (unless you specifically override the Luminance Level with the checkbox, Mantiuk ‘08 will automatically adjust it for you):
Predefined Display
There are options for LCD Office, LCD, LCD Bright, and CRT but they didn’t seem to make any difference in my final output at all.
Color Saturation
The default is 1.0.
Color Saturation operates exactly how you’d expect. Dropping this value decreases the saturation, and vice versa. Here’s a version with the Color Saturation bumped to 1.50:
Mantiuk ‘08 - Color Saturation increased to 1.50
(click to compare to defaults)
Contrast Enhancement
The default value is 1.0.
This will affect the global contrast across the image. The default seemed to have a bit too much contrast, so it’s worth it to dial this value in. For instance, here is the Contrast Enhancement dialed down to 0.51:
Mantiuk ‘08 - Contrast Enhancement decreased to 0.51
(click to compare to defaults)
Compared to the default settings I feel like this operator can work better if the contrast is turned down just a bit to make it all a little less harsh.
Enable Luminance Level
This checkbox/slider allows you to manually specify the Luminance Level in the image. The problem that I ran into was that with this enabled, I couldn’t adjust the Luminance far enough to keep bright areas in the image from blowing out. if I let the default behavior of automatically adjusting Luminanace, then it kept things more under control.
My Final Version
Starting from the defaults, I pushed down the Contrast Enhancement to 0.61 to even out the overall contrast. I bumped the Color Saturation to 1.10 to bring out the colors a bit more as well.
I also dropped the pre-gamma correction to 0.91 in order to bring back some of the contrast lost from the Contrast Enhancement.
My final Mantiuk ‘08 output
(pre-gamma 0.91, Contrast Enhancement 0.61, Color Saturation 1.10)
(click to compare to defaults)
Fattal
Crap. Time for this TMO I guess…
THIS is the TMO responsible for some of the greatest sins of HDR images.
Did you see the first two images in this post? Those were Fattal.
The problem is that it’s really easy to get stupid with this TMO.
Fattal (like the other local contrast operators) is dependent on the final output size of the image.
When testing this operator, do it at the full resolution you will want to export.
The results will not match up if you change size.
I’m also going to focus on using only the newer v.2.3.0 version, not the old one.
Here is what the default values look like on our image:
Default Fattal applied
The defaults are pretty contrasty, and the color seems saturated quite a bit as well. Maybe we can get something useful out of this operator. Let’s have a look at the parameters.
Alpha
The default is 1.00.
This parameter is supposed to be a threshold against which to apply the effect. According to the wikidot, decreasing this value should increase the level of details in the output and vice versa. Here is an example with the Alpha turned down to 0.25:
Fattal - Alpha decreased to 0.25
(click to compare to defaults)
Increasing the Alpha value seems to darken the image a bit as well.
Beta
The default value is 0.90.
This parameter is supposed to control the amount of the algorithm applied on the image. A value of 1 is no effect on the image (straight gamma=1 mapping). Lower values will increase the amount of the effect. Recommended values are between 0.8 and 0.9. As the values get lower, the image gets more cartoonish looking.
Here is an example with Beta dropped down to 0.75:
Fattal - Beta decreased to 0.75
(click to compare to defaults)
Color Saturation
The default value is 1.0.
This parameter does exactly what’s described. Nothing interesting to see here.
Noise Reduction
The default value is 0.
This should suppress fine detail noise from being picked up by the algorithm for enhancement. I’ve noticed that it will slightly affect the image brightness as well. Fine details may be lost if this value is too high. Here the Noise Reduction has been turned up to 0.15:
Fattal - Noise Reduction increased to 0.15
(click to compare to defaults)
My Final Version
This TMO is sensitive to changes in its parameters. Small changes can swing the results far, so proceed lightly.
I increased the Noise Reduction a little bit up front, which lightened up the image. Then I dropped the Beta value to let the algorithm work to brighten up the image even further. To offset the increase, I pushed Alpha up a bit to keep the local contrasts from getting too harsh. A few minutes of adjustments yielded this:
My Fattal output - Alpha 1.07, Beta 0.86, Saturation 0.7, Noise red. 0.02
(click to compare to defaults)
Overall, Fattal can be easily abused. Don’t abuse the Fattal TMO. If you find your values sliding too far outside of the norm, step away from your computer, get a coffee, take a walk, then come back and see if it still hurts your eyes.
Drago
Drago is another of the global TMOs. It also has just one control: bias.
Here is what the default values produce:
Default Drago applied
The default values produced a very washed out appearance to the image. The black points are heavily lifted, resulting in a muddy gray in dark areas.
Bias is the only parameter for this operator. The default value is 0.85. Decreasing this value will lighten the image significantly, while increasing it will darken it. For my image, even pushing the Bias value all the way up to 1.0 only produced marginal results:
Drago - Bias 1.0
(click to compare to defaults)
Even at this level the image still appears very washed out. The only other parameter to change would be the pre-gamma before the TMO can operate. After adjusting values for a bit, I settled on a pre-gamma of 0.67 in addition to the Bias being set to 1:
My Final Version
My result: Drago - Bias 1.0, pre-gamma 0.67
(click to compare to defaults)
Durand
Most of the older documentation/posts that I can find describe Durand as the most realistic of the TMOs, yielding good results that do not appear overly processed.
Indeed the default settings immediately look reasonably natural, though it does exhibit a bit of blowing out in very bright areas - which I imagine can be fixed by adjustment of the correct parameters. Here is the default Durand output:
Default Durand applied
There are three parameters that can be adjusted for this TMO, let’s have a look:
Base Contrast
The default is 5.00.
This value is considered a little high from most sources I’ve read. Usually recommending to drop this value to the 3-4 range. Here is the image with the Base Contrast dropped to 3.0:
Durand - Base Contrast decreased to 3.5
(click to compare to defaults)
The Base Contrast does appear to drop the contrast in the image, but it also drops the blown-out high values on the house to more reasonable levels.
Spatial Kernel Sigma
The default value is 2.00.
This parameter seems to produce a change to contrast in the image. Large value swings are required to notice some changes, depending on the other parameter values. Pushing the value up to 65.00 looks like this:
Durand - Spatial Kernel Sigma increased to 65.00
(click to compare to defaults)
Range Kernel Sigma
The default value is 2.00.
My limited testing shows that this parameters doesn’t quite operate correctly. Changes will not modify the output image until you reach a certain threshold in the upper bounds, where it will overexpose the image. I am assuming there is a bug in the implementation, but will have to test further before filing a bug report.
My Final Version
In experiment I found that pre-gamma adjustments can affect the saturation in the output image. Pushing pre-gamma down a bit will increase the saturation.
My Durand results - pre-gamma 0.88, Contrast 3.6, Spatial Sigma 5.00
(click to compare to defaults)
I pulled the Base Contrast back to keep the sides of the house from blowing out. Once I had done that, I also dropped the pre-gamma to 0.88 to bump the saturation slightly in the colors. A slight boost to Spatial Kernel Sigma let me increase local contrasts slightly as well.
Finally, I used the Adjust Levels dialog to modify the levels slightly by raising the black point a small amount (hey - I’m the one writing about all these #@$%ing operators, I deserve a chance to cheat a little).
Reinhard ‘02
This is supposed to be another very natural looking operator. The initial default result looks good with medium-low contrast and nothing blowing out immediately:
Default Reinhard ‘02 applied
Even though many parameters are listed, they don’t really appear to make a difference. At least with my test HDR. Even worse, attempting to use the “Use Scales” option usually just crashes my LuminanceHDR.
Key Value
The default is 0.18.
This appears to be the only operator that does anything in my image at the moment. Increasing it will increase the brightness of the image, and decreasing it will darken the image.
Here is the image with Key Value turned down to 0.05:
Reinhard ‘02 - Key Value 0.05
(click to compare to defaults)
Phi
The default is 1.00.
This parameter does not appear to have any affect on my image.
Use Scales
Turning this option on currently crashes my session in LuminanceHDR.
My Final Version
I started by setting the Key Value very low (0.01), and adjusted it up slowly until I got the highlights about where I wanted them. Due to this being the only parameter that modified the image, I then started adjusting pre-gamma up until I got to roughly the exposure I thought looked best (1.09).
Final Reinhard ‘02 version - Key Value 0.09, pre-gamma 1.09
(click to compare to defaults)
Reinhard ‘05
Reinhard ‘05 is supposed to be another more ‘natural’ looking TMO, and also operates globally on the image. The default settings produce an image that looks under-exposed and very saturated:
Default Reinhard ‘05 applied
There are three parameters for this TMO that can be adjusted.
Brightness
The default value is -10.00.
Interestingly, pushing this parameter down (all the way to its lowest setting, -20) did not darken my image at all. Pulling it up, however, did increase the brightness overall. Here the brightness is increased to -2.00:
Reinhard ‘05 - Brightness increased to -2.00
(click to compare to defaults)
Chromatic Adaptation
The default is 0.00.
This parameter appears to affect the saturation in the image. Increasing it desaturates the results, which is fine given that the default value of 0.00 shows a fairly saturated image to begin with. Here is the Chromatic Adaptation turned up to 0.60:
Reinhard ‘05 - Chromatic Adaptation increased to 0.6
(click to compare to defaults)
Light Adaptation
The default is 1.00.
This parameter modifies the global contrast in the final output. It starts at the maximum of 1.00, and decreasing this value will increase the contrast in the image. Pushing the value down to 0.5 does this to the test image:
Reinhard ‘05 - Light Adaptation decreased to 0.50
(click to compare to defaults)
My Final Version
My Reinhard ‘05 - Brightness -5.00, Chromatic Adapt. 0.60, Light Adapt. 0.75
(click to compare to defaults)
Starting from the defaults, I raised the Brightness to -5.00 to lift the darker areas of the image, while keeping an eye on the highlights to keep them from blowing out. I then decreased the Light Adaptation until the scene had a reasonable amount of contrast without becoming overpowering to 0.75. At that point I turned up the Chromatic Adaptation to reduce the saturation in the image to be more realistic, and finished at 0.60.
Ashikhmin
This TMO has little in the way of controls - just options for two different equations that can be used, and a slider. The default (Eqn. 2) image is very dark and heavily saturated:
Default Ashikhmin applied
There is a checkbox option for using a “Simple” method (that produces identical results regardless of which Eqn is checked - I’m thinking it doesn’t use that information).
Simple
Checking the Simple checkbox removes any control over the image parameters, and yields this image:
Ashikhmin - Simple
(click to compare to defaults)
Fairly saturated, but exposed reasonably well. It lacks some contrast, but the tones are all there. This result could use some further massaging to knock down the saturation and to bump the contrast slightly (or adjust pre-gamma).
Equation 4
This is the result of choosing Equation 4 instead:
Ashikhmin - Equation 4
(click to compare to defaults)
There is a large loss of local contrast details in the scene, and some of the edges appear very soft. Overall the exposure remains very similar.
Local Contrast Threshold
The default value is 0.50.
This parameter modifies the local contrast being applied to the image. The result will be different depending on which Equation is being used.
Here is Equation 2 with the Local Contrast Threshold reduced to 0.20:
Ashikhmin - Eqn 2, Local Contrast Threshold 0.20
(click to compare to defaults)
Lower values will decrease the amount of local contrast in the final output.
Equation 4 with Local Contrast Threshold reduced to 0.20:
Ashikhmin - Eqn 4, Local Contrast Threshold 0.20
(click to compare to defaults)
My Final Version
After playing with the options, the overall best version I feel is had by just using the Simple option. Further tweaking may be necessary to get usable results beyond this.
Pattanaik
This TMO appears to attempt to mimic the behavior of human eyes with the inclusion of terminology like “Rod” and “Cone”. There are quite a few different parameters to adjust if wanted. The default TMO results in an image like this:
Default Pattanaik applied
The default results are very desaturated, and tends to blow out in the highlights. The dark areas appear well exposed, with the problems (in my test hdr) being mostly constrained to highlights for this example. On first glance, the results look like something that could be worked with.
There are quite a few different parameters for this TMO. Let’s have a look at them:
Multiplier
The default value is 1.00.
This parameter appears to modify the overall contrast in the image. Decreasing the value will decrease contrast, and vice versa. It also appears to slightly modify the brightness in the image as well (pushing the highlights to a less blown-out value). Here is the Multiplier decreased to 0.03:
Pattanaik - Multiplier 0.03
(click to compare to defaults)
Local Tone Mapping
This parameter is just a checkbox, with no controls. The result is a washed out image with heavy local contrast adjustments:
Pattanaik - Local Tone Mapping
(click to compare to defaults)
Cone/Rod Levels
The default is to have Auto Cone/Rod checked, greying out the options to change the parameters manually.
Turning off Auto Cone/Rod will get the default manual values of 0.50 for both applied:
Pattanaik - Manual Cone/Rod (0.50 for each)
(click to compare to defaults)
The image gets very blown out everywhere, and modification of the Cone/Rod values does not significantly reduce brightness across the image.
My Final Version
Starting with the defaults, I reduced the Multiplier to bring the highlights under control. This reduced contrast and saturation in the image.
My final Pattanaik - Multiplier 0.03, pre-gamma 0.91
(click to compare to defaults)
To bring back contrast and some saturation, I decreased the pre-gamma to 0.91. The results are not too far off of the defualt settings. The results could still use some further help with global contrast and saturation, and might benefit from layering or modifications in GIMP.
Closing Thoughts
Looking through all of the results shows just how different each TMO will operate across the same image. Here are all of the final results in a single image:
I personally like the results from Mantiuk ‘06. The problem is that it’s still a little more extreme than I would care for in a final result. For a really good, realistic result that I think can be massaged into a great image, I would go to Mantiuk ‘08 or Reinhard.
I could also do something with Fattal, but would have to tone a few things down a bit.
While you’re working, remember to occasionally open up the Levels Adjustment to keep an eye on the histogram. Look for highlights blowing out, and shadows becoming too murky. All the normal rules of image processing still apply here - so use them!
You’re trying to use HDR as a tool for you to capture more information, but remember to still keep it looking realistic. If you’re new to HDR processing, then I can’t recommend enough to stop occasionally, get away from the monitor, and come back to look at your progress.
If it hurts your eyes, dial it all back. Heck, if you think it looks good, still dial it back .
If I can head off even one clown-vomit image, then I’ll consider my mission accomplished with this post.
A Couple of Further Resources
Here’s a few things I’ve found scattered around the internet if you want to read more.
I don’t ever do this normally, but you’ve got to start somewhere, right?
It’s my long-term desire to be able to hold a PIXLS meetup/event every year where the community can get together.
Where we can hold workshops, photowalks, and generally share knowledge and information.
For free, for anyone.
For now though, we need support.
LGM is a great opportunity for us to meet with many different projects usually having representatives there.
Donations will help us to offset travel costs to attend LGM as well as a pre-LGM meetup we are holding (more below).
Anything further will go to creating new content and to cover hosting costs for the site.
Here’s the fancy little widget they make available:
If you want to help by adding this button places, here’s the code to do it:
<a href='https://pledgie.com/campaigns/30905'>
<img alt='Click here to lend your support to: PIXLS.US at Libre Graphics Meeting 2016 and make a donation at pledgie.com !' src='https://pledgie.com/campaigns/30905.png?skin_name=chrome' border='0' style='width: initial;'>
</a>
Feel free to use it wherever you think it might help. :)
I realize that not everyone will be able to donate funds. No sweat!
If you’d still like to help out then perhaps you can help us raise awareness for the campaign?
The more folks that know about it the better!
Re-tweeting, blogging, linking, yelling on a street corner all help to raise awareness of what we are doing here.
Heck, just invite folks to come read and participate in the community. Let’s help even more people learn about free software!
I am going to arrive a day early so that we can have a gathering of PIXLS community folks and anyone else who wants to join us for some photographic fun!
Thanks to the local organizers in London (yay Lara!), we have facilities for us to use.
We will be meeting on Thursday, April 14th at the Furtherfield Commons.
The facilities will be available from 1000 – 1800 for us to use.
Furtherfield Commons
Finsbury Gate – Finsbury Park
Finsbury Park, London, N4 2NQ
As near as I can tell, here’s a street view of the Finsbury Gate:
I believe the Commons building is just inside this gate, and on the left.
In 2014 I held a photowalk with LGM attendees in Leipzig the day before the event that was great fun.
Let’s expand the idea and do even more!
Nikolaikirche, Leipzig, from the 2014 LGM photowalk.
(That’s houz in the bottom right)
This year I plan on bringing a model along to shoot while we are out and about (my friend Mairi if she’s available - or a local model if not).
I will also be doing a photowalk again, either in the morning or afternoon.
I am also looking for folks from the community to suggest holding their own photoshoots or workshops, so please step forward and let me know if you’d be interested in doing something!
The facilities have bench seating for approximately 20 people, a big desk, and a projector as well.
Three things that I personally will be doing are (in no particular order):
Natural + flash portraits and model shooting workshop.
Photowalk around the park + surrounding environs.
Portraits + architectural photos for Furtherfield (the hosts).
I am hoping to possibly record some of these workshops and interactions for posterity and others that might not be able to make it to London.
It might be fun to record some shoots for the community to be able to use!
I am also 100% open to suggestions for content that you, the community, might be interested in seeing.
If you have something you’d like me to try (and record), please let me know!
Hopefully Mairi will be able to make it to London to model for us!
Sneaking a release out on Christmas Eve, the darktable team have announced their feature release of darktable 2.0!
After quite a few months of Release Candidates the 2.0 is finally here.
Please join me in saying Congratulations and a hearty Thank You! for all of their work bringing this release to us.
Alex Prokoudine of Libre Graphics World has a more in-depth look at the release including a nice interview with part of the team: Johannes Hanika, Tobias Ellinghaus, Roman Lebedev, and Jeremy Rosen. My favorite tidbit from the interview:
There is a lot less planning involved than many might think.
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.
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.
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.
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:
Various lighting setups test in Blender.
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?
A small update on how things are progressing (hint: well!) and some neat things the community is playing with.
I have been quiet these past few weeks because I decided I didn’t have enough to do and thought a rebuild/redesign of the GIMP website would be fun, apparently.
Well, it _is_ fun and something that couldn’t hurt to do.
So I stepped up to help out.
There was a thread recently on a certain large social network in a group dedicated to off-camera flash.
The thread was started by someone with the comment:
The most important thing you can do with your speed light is to put some rib [sic] stop sail cloth over the speed light to soften the light.
Which just about gave me an aneurysm (those that know me and lighting can probably understand why).
Despite some sound explanations about why this won’t work to “soften” the light, there was a bit of back and forth about it.
To make matters worse, even after over 100 comments, nobody bothered to just go out and shoot some sample images to see it for themselves.
So I finally went out and shot some to illustrate and I figured they would be more fun if they were shared
(I did actually post these on our forum).
I quickly set a lightstand up with a YN560 on it pointed at my garden statue.
I then took a shot with bare flash, one with diffusion material pulled over the flash head, and one with a 20” diy softbox attached.
Here’s what the setup looked like with the softbox in place:
Simple light test setup (with a DIY softbox in place).
Remember, this was done to demonstrate that simply placing some diffusion fabric over the head of a speedlight does nothing to “soften” the resulting light:
Bare flash result. Click to compare with diffusion material.
This shows clearly that diffusion material over the flash head does nothing to affect the “softness” of the resulting light.
For a comparison, here is the same shot with the softbox being used:
Same image with the softbox in place. Click to compare with diffusion material.
I also created some crops to help illustrate the difference up close:
Click to compare:
Bare FlashWith DiffusionWith Softbox
Click to compare:
Bare FlashWith DiffusionWith Softbox
Hopefully this demonstration can help put to rest any notion of softening a light through close-set diffusion material (at not-close flash-to-subject distances). At the end of the day, the “softness” quality of a light is a function of the apparent size of the light source relative to the subject. (The sun is the biggest light source I know of, but it’s so far it’s quality is quite harsh.)
On discuss, member Micaasked an awesome question about what our workflows are for adding resolution (upsizing) to an image.
There were a bunch of great suggestions from the community.
One I wanted to talk about briefly I thought was interesting from a technical perspective.
Both Hasselblad and Olympus announced not too long ago the ability to drastically increase the resolution of images in their cameras that used a “sensor-shift” technology to shift the sensor by a pixel or so while shooting multiple frames, then combing the results into a much larger megapixel image (200MP in the case of Hasselblad, and 40MP in the Olympus).
It turns out we can do the same thing manually by burst shooting a series of images while handholding the camera (the subtle movement of our hand while shooting provides the requisite “shift” to the sensor).
Then we simply combine the images, upscale, and average the results to get a higher resolution result.
The basic workflow uses Huginalign_image_stack, Imagemagickmogrify, and G’MICmean blend script to achieve the results.
Shoot a bunch of handheld images in burst mode (if available).
Develop raw files if that’s what you shot.
Scale images up to 4x resolution (200% in width and height). Straight nearest-neighbor type of upscale is fine.
In your directory of images, create a new sub-directory called resized.
In your directory of images, run mogrify -scale 200% -format tif -path ./resized *.jpg if you use jpg’s, otherwise change as needed.
This will create a directory full of upscaled images.
Align the images using Hugin’s align_image_stack script.
In the resized directory, run /path/to/align_image_stack -a OUT file1.tif file2.tif ... fileX.tif
The -a OUT option will prefix all your new images with OUT.
I move all of the OUT* files to a new sub-directory called aligned.
In the aligned directory, you now only need to mean average all of the images together.
Using Imagemagick: convert OUTfile*.tif -evaluate-sequence mean output.bmp
Using G’MIC: gmic video-avg.gmic -avg \" *.tif \" -o output.bmp
I used 7 burst capture images from an iPhone 6+ (default resolution 3264x2448).
This is the test image:
Sample image, red boxes show 100% crop areas.
Here is a 100% crop of the first area:
100% crop of the base image, straight upscale.
100% crop, super resolution process result.
The second area crop:
100% crop, super resolution process result.
100% crop, super resolution process result.
Obviously this doesn’t replace the ability to have that many raw pixels available in a single exposure, but if the subject is relatively static this method can do quite well to help increase the resolution.
As with any mean/median blending technique, a nice side-effect of the process is great noise reduction as well…
Not sure if this warrants a full article post, but may consider it for later.
Replicating Calvin Hollywood's Freaky Details in GIMP
German photographer/digital artist/photoshop trainer Calvin Hollywood has a rather unique style to his photography. It’s a sort of edgy, gritty, hyper-realistic result, almost a blend between illustration and photography.
As part of one of his courses, he talks about a technique for accentuating details in an image that he calls “Freaky Details”.
Here is Calvin describing this technique using Photoshop:
In my meandering around different retouching tutorials I came across it a while ago, and wanted to replicate the results in GIMP if possible. There were a couple of problems that I ran into for replicating the exact same workflow:
Lack of a “Vivid Light” layer blend mode in GIMP
Lack of a “Surface Blur” in GIMP
Those problems have been rectified (and I have more patience these days to figure out what exactly was going on), so let’s see what it takes to replicate this effect in GIMP!
Replicating Freaky Details
Requirements
The only extra thing you’ll need to be able to replicate this effect is G’MIC for GIMP.
You don’t technically need G’MIC to make this work, but the process of manually creating a Vivid Light layer is tedious and error-prone in GIMP right now.
Also, you won’t have access to G’MIC’s Bilateral Blur for smoothing.
And, seriously, it’s G’MIC - you should have it anyway for all the other cool stuff it does!
Summary of Steps
Here’s the summary of steps we are about to walk through to create this effect in GIMP:
Duplicate the background layer.
Invert the colors of the top layer.
Apply “Surface Blur” to top layer.
Set top layer blend mode to “Vivid Light”.
New layer from visible.
Set layer blend mode of new layer to “Overlay”, hide intermediate layer.
There are just a couple of small things to point out though, so keep reading to be aware of them!
Detailed Steps
I’m going to walk through each step to make sure it’s clear, but first we need an image to work with!
New York National Guard by U.S. National Guard/Staff Sergeant Christopher Muncy
on Flickr (cb).
Airman First Class Anthony Pisano, a firefighter with the New York National Guard’s 106th Civil Engineering Squadron, 106th Rescue Wing conducts a daily equipment test during a major snowstorm on February 17, 2015.
(New York Air National Guard / Staff Sergeant Christopher S Muncy / released)
This is a great image to test the effect, and to hopefully bring out the details and gritty-ness of the portrait.
1./2. Duplicate background layer, and invert colors
So, duplicate your base image layer (Background in my example).
Layer → Duplicate (Shift-Ctrl-D,Shift-⌘-D)
I will usually name the duplicate layer something descriptive, like “Temp” ;).
Next we’ll just invert the colors on this “Temp” layer.
Colors → Invert
So right now, we should be looking at this on our canvas:
The inverted duplicate of the base layer.
What the Layers dialog should look like.
Now that we’ve got our inverted “Temp” layer, we just need to apply a little blur.
3. Apply “Surface Blur” to Temp Layer
There’s a couple of different ways you could approach this. Calvin Hollywood’s tutorial explicitly calls for a Photoshop Surface Blur. I think part of the reason to use a Surface Blur vs. Gaussian Blur is to cut down on any halos that will occur along edges of high contrast.
There are three main methods of blurring this layer that you could use:
Straight Gaussian Blur (easiest/fastest, but may halo - worst results)
Filters → Blur → Gaussian Blur
Selective Gaussian Blur (closer to true “Surface Blur”)
Filters → Blur → Selective Gaussian Blur
G’MIC’s Smooth [bilateral] (closest to true “Surface Blur”)
Filters → G’MIC → Repair → Smooth [bilateral]
I’ll leave it as an exercise for the reader to try some different methods and choose one they like. (At this point I personally pretty much just always use G’MIC’s Smooth [bilateral] - this produces the best results by far).
For the Gaussian Blurs, I’ve had good luck with radius values around 20% - 30% of an image dimension. As the blur radius increases, you’ll be acting more on larger local contrasts (as opposed to smaller details) and run the risk of halos. So just keep an eye on that.
So, let’s try applying some G’MIC Bilateral Smoothing to the “Temp” layer and see how it looks!
Run the command:
Filters → G’MIC → Repair → Smooth [bilateral]
The values I used in this example for Spatial/Value Variance.
The values you want to fiddle with are the Spatial Variance and Value Variance (25 and 20 respectively in my example). You can see the values I tried for this walkthrough, but I encourage you to experiment a bit on your own as well!
Now we should see our canvas look like this:
Our “Temp” layer after applying G’MIC Smoothing [bilateral]
Layers should still look like this.
Now we just need to blend the “Temp” layer with the base background layer using a “Vivid Light” blending mode…
4./5. Set Temp Layer Blend Mode to Vivid Light & New Layer
Now we need to blend the “Temp” layer with the Background layer using a “Vivid Light” blending mode. Lucky for me, I’m friendly with the G’MIC devs, so I asked nicely, and David Tschumperlé added this blend mode for me.
G’MIC Vivid Light blending mode, pay attention to Input/Output!
Pay careful attention to the Input/Output portion of the dialog. You’ll want to set the Input Layers to All visibles so it picks up the Temp and Background layers. You’ll also probably want to set the Output to New layer(s).
When it’s done, you’re going to be staring at a very strange looking layer, for sure:
Well, sure it looks weird out of context…
The layers should now look like this.
Now all that’s left is to hide the “Temp” layer, and set the new Vivid Light result layer to Overlay layer blending mode…
6. Set Vivid Light Result to Overlay, Hide Temp Layer
We’re just about done. Go ahead and hide the “Temp” layer from view (we won’t need it anymore - you could delete it as well if you wanted to).
Finally, set the G’MIC Vivid Light layer output to Overlay layer blend mode:
Set the resulting G’MIC output layer to Overlay blend mode.
The results we should be seeing will have enhanced details and contrasts, and should look like this (mouseover to compare the original image):
Our final results (whew!)
(click to compare to original)
This technique will emphasize any noise in an image so there may be some masking and selective application required for a good final effect.
Summary
This is not an effect for everyone. I can’t stress that enough. It’s also not an effect for every image. But if you find an image it works well on, I think it can really do some interesting things. It can definitely bring out a very dramatic, gritty effect (it works well with nice hard rim lighting and textures).
The original image used for this article is another great example of one that works well with this technique:
I had muted the colors in this image before applying some Portra-esque color curves to the final result..
Finally, a BIG THANK YOU to David Tschumperlé for taking the time to add a Vivid Light blend mode in G’MIC.
Try the method out and let me know what you think or how it works out for you! And as always, if you found this useful in any way, please share it, pin it, like it, or whatever you kids do these days…
For those looking for a faster/easier way to achieve this effect, it has now been integrated as a filter into G’MIC. (Again, thanks to David Tschumperlé!)
We recently posted about the Open Source Photography Course from photographer Riley Brandt.
We now also have a review of the course as well.
This review is actually by one of the darktable developers, houz!
He had originally posted it on discuss as a topic but I think it deserves a blog post instead.
(When a developer from a favorite project speaks up, it’s usually worth listening…)
First of all, as a darktable developer I am biased so take everything I write with a grain of salt. Second, I didn’t pay for my copy of the videos but Riley was kind enough to provide a free copy for me to review. So add another pinch of salt. I will therefore not tell you if I would encourage you to buy the course. You can have my impressions nevertheless.
I won’t say anything about the GIMP part, not because it wouldn’t know how to use that software but it’s relatively short and I just didn’t notice anything to comment on. It’s solid basics of how to use GIMP and the emphasis on layer masks is really important in real world usage.
Now for the darktable part, I have to say that I liked it a lot. It showcases a viable workflow and is relatively complete – not by explaining every module and becoming the audio book of the user manual but by showing at least one tool for every task. And as we all know, in darktable there are many ways to skin a cat, so concentrating on your favourites is a good thing.
What I also appreciate is that Riley managed to cut the single topics to manageable chunks of around 10 minutes or less so you can easily watch them in your lunch break and have no problem to come back to one topic later and easily find what you are looking for.
Before this starts to sound like an advertisement I will just point out some small nitpicking things I noticed while watching the videos. Most of these were not errors in the videos but are just extra bits of information that might make your workflow even smoother, so it’s more of an addendum than an erratum.
When going through your images on lighttable you can either zoom in till you only see a single image (alt-1 is a shortcut for that) or hold the z key pressed. Both are shown in the videos. The latter can quickly become tedious since releasing z just once bring you back to where you were. There are however two more keyboard shortcuts that are not assigned by default under views>lighttable: ‘sticky preview’ and ‘sticky preview with focus detection’. Both work just like normal z and ctrl-z, just without the need to keep the key pressed. You can assign a key to these, for example by reusing z and ctrl-z.
Color labels can be set with F1 .. F5, similar to rating.
Basecurve and tonecurve allow very fine up/down movement of points with the mouse wheel. Hover over a node and scroll.
Gaussian in shadows&highlights tends to give stronger halos than bilateral in normal use, see the darktable blog for an example.
For profiled denoising better use ‘HSV color’ instead of ‘color’ and ‘HSV lightness’ instead of ‘lightness’, see the user manual for details.
When using the mouse wheel to zoom the image you can hold ctrl to get it smaller than fitting to the screen. That’s handy to draw masks over the image border.
When moving the triangles in color zones apart you actually widen the scope of affected values since the curve gets moved off the center line on a wider range.
Also color zones: You can also change reds and greens in the same instance, no need for multiple instances. Riley knows that and used two instances to be able to control the two changes separately.
When loading sidecar files from lighttable, you can even treat a JPEG that was exported from darktable like an XMP file and manually select that since the JPEGs get the processing data embedded. It’s like a backup of the XMP with a preview. Caveat: When using LOTS of mask nodes (mostly with the brush mask) the XMP data might get too big so it’s no longer possible to embed in the JPEG, but in general it works.
The collect module allows to store presets so you can quickly access often used search rules. And since presets only store the module settings and not
the resulting image set these will be updated when new images are imported.
In neutral density you can draw a line with the right mouse button, similar to rotating images.
Styles can also be created from darkroom, there is a small button next to the history compression button.
So, that’s it from me. Did you watch the videos, too? What was your impression? Do you have any remarks?
In my previous post on Color Curves for Toning/Grading, I looked at the basics of what the Curves dialog lets you do in GIMP.
I had been meaning to revisit the subject with a little more restraint (the color curve in that post was a little rough and gross, but it was for illustration so I hope it served its purpose).
This time I want to look at the use of curves a little more carefully.
You’d be amazed at the subtlety that gentle curves can produce in toning your images.
Even small changes in your curves can have quite the impact on your final result.
For instance, have a look at the four film emulation curves created by Petteri Sulonen (if you haven’t read his page yet on creating these curves, it’s well worth your time):
Original
Portraesque (Kodak Portra NC400 Film)
Proviaesque (Fujichrome Provia)
Velviaesque (Fujichrome Velvia)
Crossprocess (E6 slide film in C-41 neg. processing)
I can’t thank Petteri enough for releasing these curves for everyone to use (for us GIMP users, there is a .zip file at the bottom of his post that contains these curves packaged up).
Personally I am a huge fan of the Portraesque curve that he has created.
If there is a person in my images, it’s usually my go-to curve as a starting point.
It really does generate some wonderful skin tones overall.
The problem in generating these curves is that one has to be very, very familiar with the characteristics of the film stocks you are trying to emulate.
I never shot Velvia personally, so it is hard for me to have a reference point to start from when attempting to emulate this type of film.
What we can do, however, is to use our personal vision or sense of aesthetic to begin toning our images to something that we like. GIMP has some great tools for helping us to become more aware of color and the effects of each channel on our final image. That is what we are going to explore…
Disclaimer
I cannot stress enough that what we are approaching here is an entirely subjective interpretation of what is pleasing to our own eyes. Color is a very complex subject and deserves study to really understand. Hopefully some of the things I talk about here will help pique your interest to push further and experiment!
There is no right or wrong, but rather what you find pleasing to your own eye.
Approximating Tones
What we will be doing is using Sample Points and the Curves dialog to modify the color curves in my image above to emulate something else. It could be another photograph, or even a painting.
I’ll be focusing on the skin tones, but the method can certainly be used for other things as well.
My wonderful model.
With an image you have, begin considering what you might like to approximate the tones on. For instance, in my image above I want to work on the skin tones to see where it leads me.
Now find an image that you like, and would like to approximate the tones from. It helps if the image you are targeting already has tones somewhat similar to what you are starting with (for instance, I would look for another Caucasian image with similar tones to start from, as opposed to Asian). Keeping tones at least similar will reduce the violence you’ll do to your final image.
So for my first example, perhaps I would like to use the knowledge that the Old Masters already had in regards to color, and would like to emulate the skin tones from Vermeer’s Girl with the Pearl Earring.
In GIMP I will have my original image already opened, and will then open my target image as a new layer. I’ll pull this layer to one side of my image to give me a view of the areas I am interested in (faces and skin).
I will be using Sample Points extensively as I proceed. Read up on them if you haven’t used them before. They are basically a means of giving you real-time feedback of the values of a pixel in your image (you can track up to four points at one time).
I will put a first sample point somewhere on the higher skin tones of my base image. In this case, I will put one on my models forehead (we’ll be moving it around shortly, so somewhere in the neighborhood is fine).
Ctrl + Left Click in the ruler area of your main window (shown in green above), and drag out into your image. There should be crosshairs across your entire image screen showing you where you are dragging.
When you release the mouse button, you’ve dropped a Sample Point onto your image. You can see it in my image above as a small crosshair with the number 1 next to it.
GIMP should open the sample points dialog for you when you create the first point, but if not you can access it from the image menu under:
Windows → Dockable Dialogs → Sample Points
This is what the dialog looks like.
You can see the RGB pixel data for the first sample point that I have already placed.
As you place more sample points, they will each be reflecting their data on this dialog.
You can go ahead and place more sample points on your image now. I’ll place another sample point, but this time I will put it on my target image where the tones seem similar in brightness.
What I’ll then do is change the data being shown in the Sample Points dialog to show HSV data instead of Pixel data.
Now, I will shoot for around 85% value on my source image, and try to find a similar value level in similar tones from my target image as well. Once you’ve placed a sample point, you can continue to move it around and see what types of values it gives you. (If you use another tool in the meantime, and can no longer move just the sample point - you can just select the Color Picker Tool to be able to move them again).
Move the points around your skin tones until you get about the same Value for both points.
Once you have them, make sure your original image layer is active, then start up the curves dialog.
Colors → Curves…
Now here is something really handy to know while using the Curves dialog: if you hover your mouse over your image, you’ll notice that the cursor is a dropper - you can click and drag on an area of your image, and the corresponding value will show up in your curves dialog for that pixel (or averaged area of pixels if you turn that on).
So click and drag to about the same pixel you chose in your original image for the sample point.
Curves dialog with a value point (217) for my sampled pixel.
Here is what my working area currently looks like:
I have my curves dialog open, and an area around my sample point chosen so that the values will be visible in the dialog, my images with their associated sample points, and the sample points dialog showing me the values of those points.
The basic idea now is to adjust my RGB channels to get my original image sample point (#1) to match my target image sample point (#2).
Because I selected an area around my sample point with the curves dialog open, I will know roughly where those values need to be adjusted. Let’s start with the Red channel.
First, set the Sample Points dialog back to Pixel to see the RGBA data for that pixel.
We can now see that to match the pixel colors we will need to make some adjustments to each channel. Specifically,
the Red channel will have to come down a bit (218 → 216),
the Green down some as well (188 → 178),
and Blue much more (171 → 155).
You may want to resize your Curves dialog window larger to be able to more finely control the curves. If we look at the Red channel in my example, we would want to adjust the curve down slightly at the vertical line that shows us where our pixel values are:
We can adjust the red channel curve along this vertical axis (marked x:217) until our pixel red value matches the target (216).
Then just change over to the green channel and do the same:
Here we are adjusting the green curve vertically along the axis marked x:190 until our pixel green value matches the target (178).
Finally, follow the same procedure for the blue channel:
As before, we adjust along the vertical axis x:173 until our blue channel matches the target (155).
At this point, our first sample point pixel should be the same color as from our target.
The important thing to take away from this exercise is to be watching your image as you are adjusting these channels to see what types of effects they produce. Dropping the green channel should have seen a slight addition of magenta to your image, and dropping the blue channel should have shown you the addition of a yellow to balance it.
Watch your image as you make these changes.
Don’t hit OK on your curves dialog yet!
You’ll want to repeat this procedure, but using some sample points that are darker than the previous ones. Our first sample points had values of about 85%, so now let’s see if we can match pixels down below 50% as well.
Without closing your curves dialog, you should be able to click and drag your sample points around still. So I would set your Sample Points dialog to show you HSV values again, and now drag your first point around on your image until you find some skin that’s in a darker value, maybe around 40-45%.
Once you do, try to find a corresponding value in your target image (or something close at least).
I managed to find skin tones with values around 45% in both of my images:
In these darker tones, I can see that the adjustments I will have to make are for:
Red down a bit (116 → 114),
Green bumped up some (60 → 73),
Blue slightly down (55 → 53).
With the curves dialog still active, I then click and drag on my original image until I am in the same area as my sample point again. This give me my vertical line showing me the value location in my curves dialog, just as before:
Red down to 114.
Green up to 73.
Blue down to 53.
At this point you should have something similar to the tones of your target image. Here is my image after these adjustments so far:
Effects of the curves so far (click to compare to original).
Once you’ve got things in a state that you like, it would be a good idea to save your progress.
At the top of the Curves dialog there is a “+” symbol.
This will let you add the current settings to your favorites.
This will allow you to recall these settings later to continue working on them.
However, you’re results might not quite look right at the moment. So why not?
Well, the first problem is that Sample Points will only allow you to sample a single pixel value. There’s a chance that the pixels you pick are not truly representative of the correct skin tones in that range (for instance you may have inadvertently clicked a pixel that represents the oil paint cracks in the image). It would be nice if there were an option for Sample Points to allow an adjustable sample radius (if there is an option I haven’t found it yet).
The second issue is that similar value points might be very different colors overall. Hopefully your sources will be nice for you to pick in areas that you know are relatively consistent and representative of the tones you want, but it’s not always a guarantee.
If the results are not quite what you want at the moment, you can do what I will sometimes do and go back to the beginning…
While still keeping the curves dialog open you can pull your sample points to another location, and match the target again. Try choosing another sample point with a similar value as the first one. This time instead of adding new points the curve as you make adjustments, just drag the existing points you previously placed.
It’s an Iterative Process
Depending on how interested you are in tweaking your resulting curve, you may find yourself going around a couple of times. That’s ok.
I would recommend keeping your curves to having two control points at first. You want your curves to be smooth across the range (any abrupt changes will do strange things to your final image).
If you are doing a couple of iterations, try modifying existing points on your curves instead of adding new ones. It may not be an exact match, but it doesn’t have to be. It only needs to look nice to your eyes.
There won’t be a perfect solution for a perfect color matching between images, but we can produce pleasing curves that emulate the results we are looking for.
In Conclusion
I personally have found the process of doing this with different images to be quite instructive in how the curves will affect my image.
If you try this out and pay careful attention to what is happening while you do it, I’m hopeful you will come away with a similar appreciation of what these curves will do.
Most importantly, don’t be constrained by what you are targeting, but rather use it as a stepping off point for inspiration and experimentation for your own expression!
And finally, as promised, here’s the video tutorial that steps through everything I’ve explained above:
From a request, I’ve packaged up some of the curves from this tutorial (Pearl Earring, St. Michael, the previous Orange/Teal Hell, and another I was playing with from a Norman Rockwell painting):
Download the Curves (7zip .7z)
Hot on the heels of our last post about welcoming G’MIC to the forums at discuss.pixls.us, I thought I should speak briefly about some other additions I’ve recently made.
These were tough for me to finally make a decision about.
I want to be careful and not get crazy with over-categorization.
At the same time, I do want to make good logical breakdowns for people that is still intuitive.
Here is what the current category breakdown looks like for discuss:
PIXLS.US The comment/posts from articles/blogposts here on the main site.
Processing Processing and managing images after they’ve been captured.
Capturing Capturing an image and the ways we go about doing it.
Along with the addition of the Software category (and the G’MIC subcategory), I decided that the Help! category would make more sense under the Meta category.
That is, the Help! section is for website/forum help, which is more of a Meta topic (hence moving it).
As we’ve already seen, there is now a Software category for all discussions about the various software we use.
The first sub-category to this is of course, the G’MIC subcategory.
If there is enough interest in it, I am open to creating more sub-categories as needed to support particular software projects (GIMP, darktable, RawTherapee, etc…).
I will wait until there is some interest before adding more categories here.
This category had some interest from members and I agree that it’s a good idea.
It’s intended as a place for members to showcase the works they’re proud of and to hopefully serve as a nice example of what we’re capable of producing using F/OSS tools.
A couple of examples from the Showcase category so far:
This is intended as a place for members to solicit advice and critiques on their works from others.
It took me a little work to come up with an initial take on the overall description for the category.
I can promise that I will do my best to give honest and constructive feedback to anyone that asks in this category.
I also promise to do my best to make sure that no post goes un-answered here (I know how beneficial feedback has been to me in the past, so it’s the least I could do to help others out in return).
I also bit the bullet this week and finally caved to sign up for a Facebook account.
The only reason was because I had to have a personal account to get an API key to allow people to log in using their FB account (with OAuth).
We can now use Google, Facebook, Twitter, and Yahoo! to Log In.
On the other hand, we now accept four different methods of logging in automatically along with signing up for a normal account.
I have been trying to make it as frictionless as possible to join the conversation and hopefully this most recent addition (FB) will help in some small way.
Color has this amazing ability to evoke emotional responses from us.
From the warm glow of a sunny summer afternoon to a cool refreshing early evening in fall.
We associate colors with certain moods, places, feelings, and memories (consciously or not).
Volumes have been written on color and I am in no ways even remotely qualified to speak on it.
So I won’t.
Instead, we are going to take a look at the use of the Curves tool in GIMP.
Even though GIMP is used to demonstrate these ideas, the principles are generic to just about any RGB curve adjustments.
Your Pixels and You
First there’s something you need to consider if you haven’t before, and that’s what goes into representing a colored pixel on your screen.
Open up an image in GIMP.
Now zoom in.
Nope - don’t be shy now, zoom in more!
Aaand there’s your pixel.
So let’s investigate what goes into making your pixel.
Remember, each pixel is represented by a combination of 3 colors: Red, Green, and Blue.
In GIMP (currently at 8-bit), that means that each RGB color can have a value from 0 - 255, and combining these three colors with varying levels in each channel will result in all the colors you can see in your image.
If all three channels have a value of 255 - then the resulting color will be pure white.
If all three channels have a value of 0 - then the resulting color will be pure black.
If all three channels have the same value, then you will get a shade of gray (128,128,128 would be a middle gray color for instance).
So now let’s see what goes into making up your pixel:
The RGB components that mix into your final blue pixel.
As you can see, there is more blue than anything else (it is a blue-ish pixel after all), followed by green, then a dash of red.
If we were to change the values of each channel, but kept ratio the same between Red, Green, and Blue, then we would keep the same color and just lighten or darken the pixel by some amount.
Curves: Value
So let’s leave your pixel alone for the time being, and actually have a look at the Curves dialog.
I’ll be using this wonderful image by Eric from Flickr.
Opening up my Curves dialog shows me the following:
We can see that I start off with the curve for the Value of the pixels.
I could also use the drop down for “Channel” to change to red, green or blue curves if I wanted to.
For now let’s look at Value, though.
In the main area of the dialog I am presented with a linear curve, behind which I will see a histogram of the value data for the entire image (showing the amount of each value across my image).
Notice a spike in the high values on the right, and a small gap at the brightest values.
What we can do right now is to adjust the values of each pixel in the image using this curve.
The best way to visualize it is to remember that the bottom range from black to white represents the current value of the pixels, and the left range is the value to be mapped to.
So to show an example of how this curve will affect your image, suppose I wanted to remap all the values in the image that were in the midtones, and to make them all lighter.
I can do this by clicking on the curve near the midtones, and dragging the curve higher in the Y direction:
What this curve does is takes the values around the midtones, and pushes their values to be much lighter than they were.
In this case, values around 128 were re-mapped to now be closer to 192.
Because the curve is set Smooth, there will be a gradual transition for all the tones surrounding my point to be pulled in the same direction (this makes for a smoother fall-off as opposed to an abrupt change at one value).
Because there is only a single point in the curve right now, this means that all values will be pulled higher.
The results of pushing the midtones of the value curve higher (click to compare to original).
Care should be taken when fiddling with these curves to not blow things out or destroy detail, of course.
I only push the curves here to illustrate what they do.
A very common curve adjustment you may hear about is to apply a slight “S” curve to your values.
The effect of this curve would be to darken the dark tones, and to lighten the light tones - in effect increasing global contrast on your image.
For instance, if I click on another point in the curves, and adjust the points to form a shape like so:
A slight “S” curve
This will now cause dark values to become even darker, while the light values get a small boost.
The curve still passes through the midpoint, so middle tones will stay closer to what they were.
Slight “S” curve increases global contrast (click for original).
In general, I find it easiest to visualize in terms of which regions in the curve will effect different tones in your image.
Here is a quick way to visualize it (that is true for value as well as RGB curves):
If there is one thing you take away from reading this, let it be the image above.
Curves: Colors
So how does this apply to other channels? Let’s have a look.
The exact same theory applies in the RGB channels as it did with values.
The relative positions of the darks, midtones, and lights are still the same in the curve dialog.
The primary difference now is that you can control the contribution of color in specific tonal regions of your image.
Value, Red, Green, Blue channel picker.
You choose which channel you want to adjust from the “Channel” drop-down.
To begin demonstrating what happens here it helps to have an idea of generally what effect you would like to apply to your image.
This is often the hardest part of adjusting the color tones if you don’t have a clear idea to start with.
For example, perhaps we wanted to “cool” down the shadows of our image.
“Cool” shadows are commonly seen during the day in shadows out of direct sunlight.
The light that does fall in shadows is mostly reflected light from a blue-ish sky, so the shadows will trend slightly more blue.
To try this, let’s adjust the Blue channel to be a little more prominent in the darker tones of our image, but to get back to normal around the midtones and lighter.
Boosting blues in darker tones
Pushing up blues in darker tones (click for original).
Now, here’s a question: If I wanted to “cool” the darker tones with more blue, what if I wanted to “warm” the lighter tones by adding a little yellow?
Well, there’s no “Yellow” curve to modify, so how to approach that? Have a look at this HSV color wheel below:
The thing to look out for here is that opposite your blue tones on this wheel, you’ll find yellow.
In fact, for each of the Red, Green, and Blue channels, the opposite colors on the color wheel will show you what an absence of that color will do to your image.
So remember:
Red → CyanGreen → MagentaBlue → Yellow
What this means to you while manipulating curves is that if you drag a curve for blue up, you will boost the blue in that region of your image.
If instead you drag the curve for blue down, you will be removing blues (or boosting the Yellows in that region of your image).
So to boost the blues in the dark tones, but increase the yellow in the lighter tones, you could create a sort of “reverse” S-curve in the blue channel:
Boost blues in darks, boost yellow in high tones (click for original).
In the green channel for instance, you can begin to introduce more magenta into the tones by decreasing the curve.
So dropping the green curve in the dark tones, and letting it settle back to normal towards the high tones will produce results like this:
Suppressing the green channel in darks/mids adds a bit of magenta (click for original).
In isolation, these curves are fun to play with, but I think that perhaps walking through some actual examples of color toning/grading would help to illustrate what I’m talking about here.
I’ll choose a couple of common toning examples to show what happens when you begin mixing all three channels up.
Color Toning/Grading
Orange and Teal Hell
I use the (cinema film) term color grading here because the first adjustment we will have a look at to illustrate curves is a horrible hollywood trend that is best described by Todd Miro on his blog.
Grading is a term for color toning on film, and Todd’s post is a funny look at the prevalence of orange and teal in modern film palettes.
So it’s worth a look just to see how silly this is (and hopefully to raise awareness of the obnoxiousness of this practice).
The general thought here is that caucasian skin tones trend towards orange, and if you have a look at a complementary color on the color wheel, you’ll notice that directly opposite orange is a teal color.
If you don’t already know about it, Adobe has online a fantastic tool for color visualization and palette creation called KulerAdobe Color CC.
It lets you work on colors based on some classic rules, or even generate a color palette from images.
Well worth a visit and a fantastic bookmark for fiddling with color.
So a quick look at the desired effect would be to keep/boost the skin tones into a sort of orange-y pinkish color, and to push the darker tones into a teal/cyan combination.
(Colorists on films tend to use a Lift, Gamma, Gain model, but we’ll just try this out with our curves here).
Quick disclaimer - I am purposefully exaggerating these modifications to illustrate what they do.
Like most things, moderation and restraint will go a long ways towards not causing your viewers eyeballs to bleed.
Remember - light touch!
So I know that I want to see my skin tones head into an orange-ish color.
In my image the skin tones are in the upper mids/low highs range of values, so I will start around there.
What I’ve done is put a point around the low midtones to anchor the curve closer to normal for those tones.
This lets me fiddle with the red channel and to isolate it roughly to the mid and high tones only.
The skin tones in this image in the red channel will fall toward the upper end of the mids, so I’ve boosted the reds there.
Things may look a little weird at first:
If you look back at the color wheel again, you’ll notice that between red and green, there is a yellow, and if you go a bit closer towards red the yellow turns to more of an orange.
What this means is that if we add some more green to those same tones, the overall colors will start to shift towards an orange.
So we can switch to the green channel now, put a point in the lower midtones again to hold things around normal, and slightly boost the green.
Don’t boost it all the way to the reds, but about 2/3rds or so to taste.
This puts a little more red/orange-y color into the tones around the skin.
You could further adjust this by perhaps including a bit more yellow as well.
To do this, I would again put an anchor point in the low mid tones on the blue channel, then slightly drop the blue curve in the upper tones to introduce a bit of yellow.
Remember, we’re experimenting here so feel free to try things out as we move along.
I may consider the upper tones to be finished at the moment, and now I would want to look at introducing a more blue/teal color into the darker tones.
I can start by boosting a bit of blues in the dark tones.
I’m going to use the anchor point I already created, and just push things up a bit.
Now I want to make the darker tones a bit more teal in color.
Remember the color wheel - teal is the absence of red - so we will drop down the red channel in the lower tones as well.
And finally to push a very slight magenta into the dark tones as well, I’ll push down the green channel a bit.
If I wanted to go a step further, I could also put an anchor point up close to the highest values to keep the brightest parts of the image closer to a white instead of carrying over a color cast from our previous operations.
If your previous operations also darkened the image a bit, you could also now revisit the Value channel, and make modifications there as well.
In my case I bumped the midtones of the image just a bit to brighten things up slightly.
Finally to end up at something like this.
After fooling around a bit - disgusting, isn’t it?
(click for original).
I am exaggerating things here to illustrate a point.
Please don’t do this to your photos. :)
If you’d like to download the curves file of the results we reached above, get it here: Orange Teal Hell Color Curves
Conclusion
Remember, think about what the color curves represent in your image to help you achieve your final results.
Begin looking at the different tonalities in your image and how you’d like them to appear as part of your final vision.
For even more fun - realize that the colors in your images can help to evoke emotional responses in the viewer, and adjust things accordingly.
I’ll leave it as an exercise for the reader to determine some of the associations between colors and different emotions.
Anyone who’s followed me for a while likely knows that I’m friends with G’MIC (GREYC’s Magic for Image Computing) creator David Tschumperlé.
I was also able to release all of my film emulationpresets on G’MIC for everyone to use with David’s help and we collaborated on a bunch of different fun processing filters for photographers in G’MIC (split details/wavelet decompose, freaky details, film emulation, mean/median averaging, and more).
It’s also David that helped me by writing a G’MIC script to mean average images for me when I started making my amalgamations
(Thus moving me away from my previous method of using Imagemagick):
So when the forums here on discuss.pixls.us were finally up and running, it only made sense to offer G’MIC its own part of the forums.
They had previously been using a combination of Flickr groups and gimpchat.com.
These are great forums, they were just a little cumbersome to use.
To the winners of the Open Source Photography Course Giveaway
I compiled the list of entries this afternoon across the various social networks and let random.org pick an integer in the domain of all of the entries…
I’ll be contacting you shortly (assuming you don’t read this announcement here first…)!
I will need a valid email address from you both in order to send your download links.
You can reach me at pixlsus@pixls.us.
Thank you to everyone who shared the post to help raise awareness!
The lessons are still on sale until August 1st for $35USD over on Riley’s site.
Photographer Riley Brandt recently released his Open Source Photography Course.
I managed to get a little bit of his time to answer some questions for us about his photography and the course itself.
You can read the full interview right here:
Riley went above and beyond for us.
He has graciously offered us an opportunity for 2 readers to win a free copy of the course (one in an open format like WebM/VP8, and another in a popular format like MP4/H.264)!
For a chance to win, I’m asking you to share a link to this post on:
with the hashtag #PIXLSGiveAway (you can click those links to share to those networks).
Each social network counts as one entry, so you can triple your chances by posting across all three.
Next week (Monday, 2015-07-20 Wednesday, 2015-07-22 to give folks a full week), I will search those networks for all the posts and compile a list of people, from which I’ll pick the winners (using random.org).
Make sure you get that hashtag right! :)
Login
