Darktable 3:RGB or Lab? Which Modules? Help!

Original post in French by Aurélien PIERRE, edited by the pixls community.

Darktable is slowly converging to a scene-referred RGB workflow. Why is that? What does it involve? How does the use of darktable change? Answers here…

This article begins with a 3 section introduction of the Lab space. You don’t need to understand it in detail in order to understand what happens next.

What is Lab?

The color space CIE Lab was published in 1976 by the International Commission on Illumination (CIE), in an attempt to mathematically describe the color perception of the average human being. Lab space aims to decouple the brightness information (L channel) from the chroma information (channels a and b) and takes into account the non-linear corrections that the human brain makes to the linear signal it receives from the retina. Lab space is derived from CIE XYZ space, which represents the physiological response of 3 of the 4 types of photo-sensitive cells in the retina (the cones).

The XYZ space represents what happens in the retina, and Lab represents what subsequently happens in the brain, but both color spaces are models, that is, attempts to describe reality and not the reality itself. There are always discrepancies between a model and reality, but these models are refined and improved as research progresses. Moreover, a model often represents reality only under certain conditions and assumptions, which define the area of validity of each model.

Regarding their respective areas of validity, XYZ works well almost all the time, Lab only works as long as the image has a contrast less than 100:1 (i.e. a maximum dynamic range of 6.5 EV). In the context of the creation of the Lab model in 1976, researchers were working with scanned negatives, and color negatives have a dynamic range of 6 to 7 EV. 6.5 EV is also the static contrast of the retina, and it was a little after 1976 that we realized that the brain was constantly performing HDR fusion of several images per second, meaning that static contrast as a model parameter doesn’t make much sense in the context of human vision.

What is CIE Lab for? It is intended to predict the perceptual difference between 2 colors (the delta E) and to make gamut adaptations when converting an image from one color space to another. One can then try to remap the gamut to the closest color in the target color space via strategies that minimize the delta E digitally.

The big disadvantages of Lab are:

1. It doesn’t work well for strong contrast (> 7 EV), and especially outside the range [1:100] Cd/m²,
2. It is not linear in hue, i.e. if one fixes a pixel’s a and b chromaticity components and changes only its brightness L, the same hue would be expected at a different brightness (this was the design purpose of the Lab space), however there is a slight shift in the hue, more or less marked depending on the original color of the pixel.

What is Lab doing in darktable?

The original idea was to allow separate manipulation of the brightness and chromaticity. In 2009, the year of the project’s creation, cameras had dynamic ranges quite close to Lab’s valid range; the idea was far from bad at the time, especially because darktable did not have a complex masking option then.

Advantages:

1. Lab, being a reference space and therefore independent of the display color, makes presets very easy to set up and transfer,
2. Lab sets the middle gray (18%) to 50%, so the interface is more intuitive (the middle gray is in the middle of the graph of the tones, for example).

Problems:

1. Today’s cameras have dynamic ranges that are largely outside of the conditions under which Lab is valid, which makes the defects of this space more apparent. With dynamic ranges from 10 to 14 EV at 100 ISO, any recent camera does HDR by default, and Lab is not designed to handle that much dynamic range
2. Pushing pixels in Lab space is very risky, especially when tackling compositing and image fusion with softened and feathered masks. We’ll get back to that, but it has to do with the next problem…
3. Lab is not adapted to physically realistic corrections, such as blurring, deblurring, denoising, and any filter that simulates or corrects for an optical effect.

In brief, Lab was a youthful mistake. That said, all other photo processing pieces of software seem to work by default in non-linear RGB spaces (with a “gamma” applied at the beginning of the pipe) that are basically equivalent (regarding their flaws and drawbacks for image filters).

How does Lab work?

Everything (e.g. the camera sensor) starts from a linear RGB space. We convert linear RGB to XYZ. For the purposes of the demonstration, we can consider the XYZ space as a special RGB space whose primary colors have been slightly manipulated (that’s not the case, but it behaves the same way). XYZ is also a linear space.

We then switch from XYZ to Lab by applying a “gamma correction” on the luminance channel (from Y to L), and a rotation on the channels a and b. Mathematically, Lab is like applying 2.44 gamma to linear RGB – it poses the same practical problem: it’s highly non-linear.

Summary

Lab doesn’t work for high-contrast images and doesn’t work well for images with moderate contrast. It encodes pixel values in a perceptual manner rather than physical one, which will pose a problem in the following. Lab was not designed for image processing, but only as a way to study human vision.

Precision: I have used the term “gamma” or “gamma correction” incorrectly here. Strictly, a gamma function is the specific (technical) electrico-optical transfer function (EOTF) of old-school CRT screens, which is a power function with an exponent between 1.8 and 2.2. Nowadays, people incorrectly name “gamma” any power function used for technical integers encoding or artistic lightness adjustments, which is confusing. Any encoding transfer function (using a power function or not) should be called OETF (Opto Electrical Transfer Function), and is used only to alleviate the limits of 8 bits integer file formats. Any artistic power-like brightness corrections should be called a tone curve. Even if the operation is the same, it does not have the same meaning and should not be applied at the same place in the graphics pipe. But ICC nomenclature continues to call “gamma” the exponent used to encode/decode RGB pixels when using integer file formats, so here we are, mixing unrelated concepts under an umbrella name just because the maths write the same. But, when communicating with people out of the industry, it’s often easier to use the incorrect name so that everyone sort-of understands, even if it carries on the confusion.
By the way, power-like OETF are completely unnecessary as long as you use floating point arithmetic and files format (32 bits TIFF, PFM, OpenEXR…).

The limits of non-linear spaces in image processing

First of all, what do we mean by “linear”? If y is linear with respect to x, it means there’s a relationship between x and y in the form y= a . x + b, where a and b are real constants. Linear means proportional to something plus or minus a constant.

So, when we talk about linear RGB space, we mean that the RGB values are proportional to something. But proportional to what?

The sensor counts the number of photons it receives at each photosite. Every pixel contains information on the light spectrum captured at its position, in the form of 3 intensities (red, green, blue). The coefficient of proportionality a between the number of photons and the final RGB value is the ISO sensitivity of the sensor. The constant b is the sensor noise threshold. The RGB signal is proportional to the energy of the light emission picked up by the camera sensor.

From the point of view of human perception, these intensities being proportional to the physical energy level of the light emission, does not make sense. In fact, the brain applies a non-linear, logarithmic correction that the Lab color space approximates using a cubic root. This means that we have an increased sensitivity to dim light, and reduced sensitivity to bright light.

However, all optical operations that are performed during image capture (e.g. lens blur, noise creation, or the effect of a color filter added to the lens) are applied directly to the photons. To reverse the lens blur or to simulate it when processing, we need to work on the linear RGB information, which is the closest thing to the photon data that is available to us.

See for yourself: Which one of these two computer generated bokeh (original below) seems the most natural to you? (See also a more spectacular example on Chris Brejon’s website)

Observe in particular how the dark silhouettes (bottom left) merge into the light background, or the contrast of the pentagons formed by the lens diaphragm on spotlights.

Another example, with a simple blur on smooth surfaces: Which of these gradations seems to you to be the most progressive?

These two examples were generated with Krita, which allows you to work in both linear and non-linear RGB, and has filter layers including a physically realistic lens blur.

This type of problem will occur the same way in darktable, as soon as you use the modules sharpen, high-pass, low-pass, and feathering/smoothing of drawn and/or parametric masks (which are blurs).

Blurring, deblurring, or anything else connected to optics must take place in linear RGB. There’s no mathematical model* that allows correct gradients in RGB encoded for display (with an OETF) or in Lab, due to loss of connection between pixel values and light energy.

* and just because the problems aren’t visible all the time doesn’t mean the problems aren’t always there. We can, up to a certain point, hide them with mathematical trickery (thresholds, opacity, etc.), but they will always end up coming out at the worst time. Trust me, I know exactly where to push to make it break.

This is also the problem that arises with hue zones blending in the color zones module (even if a tweak, introduced under the “smooth” process mode, attempts to hide this under the rug), which produces granular and sharp transitions.

The only darktable module that works in Lab to make a blur, and where it still works reasonably, is the local laplacian mode of the local contrast module. The price we pay for it to work is that it’s very computationally heavy and theory is like rocket science. And, even if the blur is stable, it comes with an ungracious desaturation with a hue shift to muddy grey-blue when you push the sliders a little too hard.

The benefits of a linear RGB treatment

So here’s where you say “as long as I’m not blurring my images or working only on color, I can still use Lab”.

That’s partly true, but in fact, even in those cases, working in linear RGB is simpler, with faster algorithms that can tolerate more extreme adjustments without showing annoying side-effects. Also, once again, Lab can’t support high dynamic ranges, so care must be taken to use the Lab modules after HDR tone mapping.

Strictly speaking, the only application where Lab is required is the gamut mapping, when changing color space before sending the image to a file or to the screen. And even then, since 1976, better spaces have been developed (IPT-HDR, JzAzBz) for this purpose, in HDR and with an almost perfect linearity of hues.

The current state of darktable

With the release of darktable 3.0, the default pipeline (i.e. the basic module order) has been reordered around filmic RGB. There are 4 essential steps in this pipe:

1. the demosaic module, which converts the raw file (which only contains the intensity of a single layer, R, G or B at each pixel site) to a picture (with complete RGB data for each pixel location),
2. the input color profile module, which converts the sensor’s RGB space to a standard working color space,
3. the filmic RGB (or the base curve) module, which translates between linear space (proportional to light energy) into non-linear (perceptually compressed) space,
4. the output color profile module, which converts from the standard working space to the RGB space of the screen or the image file.

Note that the base curve approach remains the one applied by default because it allows darktable to more-or-less approximate the rendering of the camera JPEG as soon as the software is opened, which seems to be the preference of many users. Nevertheless, as part of darktable 3.0, the base curve was pushed back in the pixel pipe by default, to just before the filmic RGB module, which makes it safe for the colors produced by the modules that are applied earlier. The base curve module also was provided with a color preservation mode, which produces results similar to filmic RGB. Between base curve and filmic RGB, for darktable 3.0, the difference is now only about ergonomics and on the ability to recover very low light. filmic RGB is a little more complex to understand but faster to set up (once properly understood), and is more powerful when working in deep shadows.

Modules that work in linear RGB and output in linear (thus leaving the pipeline linear after them) are:

1. exposure
2. white balance
3. channel mixer
4. tone equalizer (which is linear in parts).

The advantage of performing linear operations is that they do not affect the chrominance of the image (because changing the luminosity leaves the chrominance intact) and preserve the energy proportionality of the signal. These modules must be positioned before filmic RGB or the base curve. Exposure and tone equalizer are recommended prior to the input color profile. They can be used safely and without moderation. Note that there is a catch here on the tone equalizer, which preserves local linearity (within the image areas), but not the overall linearity (between zones). It corresponds to what would happen if we walked onto the scene with a flashlight, and hand reilluminated the objects in the scene, so we still keep the physical coherence of the signal.

Modules that work in linear RGB and carry out non-linear, but chrominance-preserving operations, (provided that the chroma preservation mode is activated) are:

1. RGB curves
2. RGB levels

The chrominance is preserved via methods that constrain the RGB ratios in and out of the module, so as to keep them identical. Note that RGB curves and RGB levels can be moved before or after filmic RGB depending on the intention, since they’re doing non-linear operations anyway. On the other hand, be careful not to use the mask feathering on modules that come later, as linearity is no longer assured and mask blurring + blending could produce unpleasant results.

Modules that work in linear RGB and carry out non-linear operations without preserving the chrominance are:

1. local tone mapping (we’ll get back to that)
2. color balance
3. LUT 3D

Color balance is designed to be applied to linear RGB data that hasn’t been corrected for contrast, i.e. before filmic RGB, tone curves etc. It does not preserve the chrominance because its explicit purpose is to adjust chrominance creatively. Similarly for LUT 3D, for which the main goal is to emulate analog film emulsions or complex aesthetic transforms.

I remind readers here that filmic RGB is a dynamic range compressor, from the high dynamic range of the camera to the low dynamic range of the screen. It is not a tone curve intended to apply an artistic correction, but a mapping of tones to force fit the sensor data into the the available screen space. filmic RGB tries to protect the details as much as possible (which we assume a priori are in the middle tones) and to keep a certain optical readability in the image.

Before filmic RGB, in the linear pipe, we still find some modules that work in Lab but perform linear operations that should (strictly speaking) be realized in linear RGB:

1. contrast equalizer
2. high pass
3. low pass
4. sharpen
5. denoise (non-local means)

These modules need to be adapted in the future to be able to work on a linear Yxy space (derived from CIE XYZ) because it is a mistake to make them work in Lab (at least, as a default). It’s a relatively easy job to do, because Yxy breaks down the luminance (Y channel) and chrominance (channels x and y) with a logic similar to Lab, minus the non-linear transformation. In the meantime, you can continue to use them, but with moderation. For the contrast equalizer, note that it uses an edge-sensitive wavelet separation, which makes it quite cumbersome to execute, but very effective at preventing halos, even considering that it works in Lab.

After filmic RGB, in the non-linear pipe, are all the other Lab modules, since they require low dynamic range. Some of these modules could also be converted to xyY and moved before filmic RGB in the future (in particular the soften, grain and fill light modules). Also note that the vignette module was left at the end of the pipe, as before, even though it works in RGB. It’s likely it’ll be better off before filmic RGB, or even before the input profile, but its code is surprisingly complex for what it does, and I haven’t had the time to unravel the imbroglio in order to understand what its working hypotheses are.

Modules not recommended

A number of modules are not recommended due to fundamental errors in design (based on my personal opinion, which is based on my practical and theoretical experience in image retouching), and in the spirit of streamlining the workflow with a minimum number of steps. There is nothing stopping you from continuing to use them, especially since users regularly introduce me to new use cases that I hadn’t thought of. But the idea here is to give you the keys to the best possible result as quickly as possible with as little fuss as possible.

Local Tone Mapping

Local tone mapping internally encodes RGB values logarithmically (they are then decoded at the output, so no problem at at this level), then applies a bilateral blur to these logarithmic values. As we saw above, theory is clear: a blur, on anything non-linear, produces halos and fringes. And as promised, the default setting range of this module is much reduced, so that users have become accustomed to merging the output of the module with low opacity – this is only hiding the misery.

Prefer the tone equalizer.

Global Tone Mapping

This module works in Lab color space to perform HDR compression, and if you have followed my explanations, you will understand that this is a contradiction in terms. In addition – and this is important – the white value is adjusted automatically from the maximum in the image, so the overall brightness of the image may change depending on the size of the export, due to the smoothing effect of the setting to scale (interpolation). To be expected: a lighter or darker JPEG than the preview in the darkroom.

Prefer filmic RGB.

Shadows and highlights

Similarly, this module works in Lab color space to perform HDR compression and uses a Gaussian or bilateral blur to isolate highlights and shadows. In practice, it gives halos quickly as soon as you push the parameters (even if the bilateral blurring lessens the problems a little), and it even tends to add local contrast (as a secondary effect) in the highlights, giving clouds a very HDR look. In the shadows, used a little hard, colors turn blue-grey. In practice, it does not work, except for minor corrections.

Prefer the tone equalizer.

Low-pass filter

The low-pass filter is actually a simple blur. A lot of people use it to invert the contrast, and then blend it with overlay or soft/hard/linear light, to compress the dynamic range. This is in fact exactly what the shadows and highlights module already does in fewer steps for the user. As mentioned above, the low-pass module works in Lab color space, so for the blur… Expect the worst.

Prefer the contrast equalizer for blur, or the tone equalizer for local dynamic range compression

High-pass filter

A lot of people use the high-pass module by blending it with overlay or soft/hard/linear light, for adding sharpness. This is in fact exactly what the sharpen module already does. The high pass is achieved by subtracting between a blur (low-pass) and the original image, so we have the same problem as for the low-pass because it’s still working in Lab.

Prefer the contrast equalizer for fine sharpness, or the local contrast for the general sharpness.

Sharpen

The sharpen module was originally intended for sensors with an optical low-pass filter as well as the smoothing due to demosaicing in some cases. First, as this module works in Lab, you need to avoid pushing it so much that it produces halos. Second, the internal sharpening method (using unsharp mask) is rather archaic and quickly artificial, even in RGB mode. Thirdly, in view of the sharpness of modern optics, given that many sensors no longer have low-pass filters, and that most of the photos will be exported at a reduction ratio of at least 8:1 (24 Mpx sensors to 3 Mpx screen), pixel-level sharpness enhancement has become practically useless. Generally speaking, the digital photographer of the 21st century would benefit from calming down with the crisp sharpness - it would be good for everyone.

Prefer to the contrast equalizer to deflect the optics via the presets provided, or the local contrast for general sharpness.

Monochrome

The monochrome module works in Lab, which it uses to define a weighted contribution of certain colours to the density of the black, in order to convert color into shades of gray. The problem is that the interface is quite sensitive to the settings, and a small correction can produce large changes and break the overall contrast in a rather ungraceful way. In practice, getting a predictable result is quite difficult and this module often results in a lot of tedious micro-adjustment sessions.

The idea of a weighted contribution of colors to the density of black comes from silver film, which behaves exactly the same way as this. But, as you saw coming, film doesn’t work in Lab and is not perceptually realistic. This idea is taken up in a physically realistic way in the channel mixer module, where several emulsion presets of commercial silver film are offered to create a grey channel. Note that, in order for the coefficients to be accurate, the colour space of the operating mode (in the module input profile) must be set to REC 709 linear, otherwise the settings will have to be adjusted.

For a black and white treatment that is based on human perceptual luminance (linear), simply lower the input or output saturation to 0% in the color balance module (right-click on the slider and enter 0 on the keypad – the setting is only up to 50% by default in the interface).

Prefer the channel mixer for a silver approach or the color balance for a perceptual approach.

Fill light/Bloom/Zone System

These three modules aim to re-illuminate a part of the image, and attempt to dilute the correction in intensity and in space by blurring in the picture. But since they’re working in the Lab color space …I won’t say it again… The results are just bad all the time, except with very soft settings, in which case you didn’t’ really need those modules in the first place.

Prefer the exposure module with masks, or the tone equalizer

Color Correction

Every photograph has at least two sources of light: a direct source (lamp, sun, candle) and a reflected source (walls, clouds, floors, ceiling). It often happens that the white balance of these two sources does not coincide. In practice, human vision has ways to correct for this this, but not the camera. So it requires a separate white balance correction for the highlights (which generally receive direct light) and the shadows (which usually receive reflected light).

This is what the color correction module offers you, again in Lab color space, and with mixed and unnatural results as soon as you push the adjustment. When you think about it carefully, the white balance can be reduced to discussions of light spectrum, and the correction is simpler in RGB, especially to manage progressively of correction.

The color balance module allows you to adjust this quickly, and not just for the shadows and the highlights, but also for midtones. Using the color-pickers, to the right of the tint sliders, it also allows you to go directly to sample neutral tones in the image (for black, gray and white) and let the software calculate the complementary color. See the manual for more details.

Prefer color balance.

Velvia

Velvia works in RGB and works on a logic quite similar to the color balance saturation. On the surface, it smells good. Except that in fact, its colorimetric equation is not perceptually correct. What it’s doing is changing the saturation (which is its intention), but at the same time it also changes the hue and brightness (which becomes awkward). The problem is that it seems to have been optimized for non-linear RGB. As a result, it is the kind of module that is typically unpredictable.

Prefer color balance.

Levels/RGB Levels

These two are working as they should, no problem with that. But when you look at the code, you can see that it duplicates exactly the slope/offset/power mode of the color balance module. The white point is scaled by a simple exposure correction, such as the slope factor or even the exposure of the exposure module. The black point is adjusted by adding a constant, such as the factor of the offset, or the black level correction of the exposure module. The grey point is adjusted by a power function (sometimes improperly called gamma), just like the power factor of the color balance. They are not just the same features, they are exactly the same math. The difference is therefore not only in ergonomics, but also in the fact that the color balance gives you the numerical value settings, making them more easily transferable from one image to another or from one application to another. Curves and levels also assume you work SDR images, with data encoded between 0 and 1. If you work HDR pictures or raised the exposure quite a lot earlier in the pipe, the pixel values will not be clipped, but the GUI will not give you control over the pixels above 1 (or 100 %).

If you already use the color balance, there is no need to add an additional level module. Finish your retouching in the same module.

Curves/RGB Curves

These also work well, but considering their classic use … are they really useful? Usually they are used to add/remove brightness, which falls in the same use case as the grey of the levels module or the power of the color balance module, or to add/remove contrast, which can be adjusted or by decreasing/increasing the interval between white and black (in a linear way) or by applying a non-linear brightness compression, again available from color balance.

Curve ergonomics is a real problem in an RGB linear workflow, because the middle gray is assumed to be in the center of the graph, which therefore assumes that we are working in non-linear RGB (where the gray at has been increased to 50%). In a linear encoding, the standard medium grey is expected at 18% (but the practice depends or where you anchored your exposure in camera), and the contrast control around this value not being centered on the graph becomes complex in the interface. In addition, the graph of the curves assumes a limited RGB signal between the values 0 and 100% (or 1)… 100% of What? White screen luminance. In a linear workflow, the HDR signal can go from 0 to infinity, and it is at filmic RGB step that we’re in charge of putting everything back between 0 and 100% of the white screen.

The contrast in the color balance module is compatible with this approach using the contrast fulcrum parameter, which allows the selection of the contrast reference. Thus when changing the contrast, we increase the light above the fulcrum, and reduce it below, but the fulcrum remains unchanged. The display workflow (in Lab or non-linear RGB) always has the implicit assumption that gray is 50%, uses it as a contrast reference, and doesn’t allow you to change that value.

Prefer color balance.

Contrast/Brightness/Saturation

Module working in Lab, which duplicates again the modules levels, curves, and color balance while adding undesirable effects on colours.

Prefer color balance.

Modules to be used with care

There is no correct replacement for the following modules for the moment, but they should be used with caution because they can be unpredictable and can cause you to lose a lot of time.

Vibrance

Vibrance works in Lab by applying a saturation correction that penalizes already saturated pixels to avoid over-saturation, but also tends to darken colors. The result is far from ugly, but the problem is that we can’t control how much we darken for the amount we resaturate.

Prefer color zones with a selection by saturation.

Color zones

This module would be awesome if the merging of colour zones were more progressive. It now has two processing modes (strong, the old, and smooth, the new) which are trying to meet this challenge of two different ways, resulting in transitions too discrete for the new, and too abrupt for the old. One more time, it works in Lab, when similar functionality in Capture One seems to be using HSL or HSV, which seems to perform better than Lab.

In some cases, color zones will benefit from being replaced by the color balance module where parametric masking may be used to isolate the shades you want to act on. Then the refinement of the guided filter parametric mask should help in difficult cases. For the rest, color balance allows us to change the shade, saturation and brightness exactly the same.

Note, however, that the color balance module, although working in RGB internally, merges the masks into Lab because this module is older than the possibility to have 100 % RGB modules, and converts from Lab to RGB internally. We’re still working on it…

Prefer color balance.

Vignetting

Adding a vignette around an image is not complicated: you just have to to gradually lower the exposure, and eventually the saturation with a drawn mask. However, the vignetting module performs incomprehensible black magic, which is much more complicated than that, with an internal homogenization which would be superfluous if things were well done. The result is rarely natural, the transition in luminosity being too violent compared to a real vignette.

You will get better results with an instance of the exposure module set to -0.5 EV, a circular mask with a large transition area whose polarity is reversed, possibly coupled with a desaturation in color balance to which you pass the same mask as used in exposure (via a rasterized mask).

Prefer the exposure (and, optionally, the color balance saturation) modules.

Mask blend modes not recommended.

Few people know this, but the blend modes lighten, darken, overlay, soft light, hard light, pin light and linear light implicitly expect the grey level to be 50% grey and are thus totally connected to the display-referred workflow. The blend modes are going to treat the pixels differently depending on whether they are above or below 50 %. Remember that the linear RGB workflow keeps the gray point at 18% (or even less). These blend modes will therefore behave in a way that is unpredictable in the scene-linear portions of the pipe.

In linear RGB, you should only use blend modes based on arithmetic operations (addition, multiplication, division, subtraction, average), on maximum/minimum comparisons (screen) or on channel separations (hue, color, chroma, etc.).

Note that the multiply mode is one of the most powerful in linear RGB. For example, to enhance the contrast of an image in a natural way, it is enough to use an instance of the exposure module blended with multiply. Set the exposure between 2 and 3 EV and the opacity between 10% and 50%. Exposure is then used to control the pivot of contrast, and opacity the intensity of the effect. It’s fast, simple and effective.

A minimal workflow for beginners

In darktable, you can choose between many modules that allow you to do the same thing in a lot of different ways. But this is merely an illusion of choice, as many of them have more disadvantages than advantages (provided you want to achieve predictable results for demanding edits). If you open the code for any of the modules not recommended above, you will see that they are almost all dated 2010-2011 - the only reason we retained them was to maintain compatibility with edits performed in prior versions of darktable.

You can perform at least 80% of your processing with just 4 modules :

1. exposure
2. white balance
3. color balance
4. filmic RGB

The reason they’re so powerful is because they’re actually extremely simple, when you look at their equations:

• Exposure: RGB_output = exposure × RGB_input + black level
• Color balance :
  • Slope/Offset/Power: RGB_output = (slope × RGB_input + offset)^power
  • Contrast: RGB_output = (RGB_input / pivot)^(contrast × pivot)
• White balance: RGB_out = coefficients × RGB_in
• filmic RGB is a little more complex, but it’s still high-school level math

With these 4 modules, you have everything you need to produce a correct image in terms of colorimetry, contrast, and artistic intent. Remember to turn off the base curve if you use the filmic RGB module. Then, if needed, finalize your edit with the following modules:

• To improve sharpness, the best option is the local contrast module in local laplacian mode
• To deblur the lens, you have deblur presets, more or less pronounced in the contrast equalizer
• To denoise, the best algorithm is in the denoise (profiled) module. Use non-local means auto mode if you don’t want to break your head
• To remove haze, you have haze removal
• To convert to black and white, the easiest way is to use the film presets in the channel mixer
• For creative control of overall contrast and re-lighting of the scene a posteriori, use the tone equalizer module

Some of the following modules have an underestimated power, and they are vastly underutilized:

1. The exposure module, with its masks, can replace all the the other methods of mapping HDR, shadows and highlights the tone equalizer, and even the tone curve and the local contrast (to some extent, when used with blend mode multiply)
2. The channel mixer module can overcome all your gamut problems, including problems with blue in stage lighting, without having to use a fake input profile, but also turn grass into snow or summer trees into fall trees
3. The color balance module can allow you to emulate the colors of a film, compensate for uneven white balance, remove redness on the skin, accentuate the depth and shape, create a split-toning effect, or to give an apocalyptic atmosphere to your images

Finally, to display only a minimal selection in the interface and modules, to the right of “More modules“, open the list of presets and select “workspace: all-purpose“.

darktable is a lot simpler when you understand that you don’t have to use all 77 of its modules at once …

If you have any doubts about the order of the modules, you should know that the default order for version 3.0 has been considered globally, and, apart from some uncertainties on the best position of the vignetting and monochrome modules, the rest is pretty solid, in theory and practice.

Conclusion

Pushing pixel values in either direction is one thing. Merging the corrections so they blend seamlessly together on the whole is another. We’ve seen that Lab or non-linear RGB allow the pixels to be pushed more or less correctly, but that it is always when doing mask blending (aka occlusion) and feathering (aka blurs) that we’re paying the price. It turns out there are a lot of blurs under the hood of darktable, sometimes where you don’t expect them. It’s especially problematic when you’re compositing, e.g. inlaying one image within another, to exchange their background without touching the foreground. And it’s precisely this kind of manipulation that led the movie industry to migrate to a scene-referred linear workflow about twenty years ago.

So darktable is in transition. It’s long, it’s sometimes painful, there are a lot of little bits to change in different places along with grumbling users who are hungry for consistency. At least now you know the why and the how. You also know what you have to win. I hope this helps you move forward.

For new users, limit yourself to the above recommended modules, and venture further when you begin to be comfortable. For older users, the new modules have a lot to offer to you, but old Lab modules are still relevant for moderate creative effects and when used with knowledge of their dangers.

The linear toolbox is being expanded. On the agenda:

• rewriting the 100% RGB color balance (including the blending), with the addition of vibrance (and a vibrance equation home-developed to preserve the color)
• conversion of the contrast equalizer and soften modules to the linear xyY space (because in fact, the Orton effect, on which the soften module is based, is very useful when it works correctly)
• a color equalizer, similar to the tone equalizer, which will allow you to adjust saturation, vibrance and Abney effect according to the pixel luminance, to pep up the filmic RGB curve
• a brand-new lens deconvolution module, respectful of the depth of field (but for that, I need to develop a special wavelet based on the guided filter), which should turn your soft 18-55 mm into a Zeiss for much less
• and of course the OpenCL version of the tone equalizer

There is more work than people to do it, so wish us good luck, don’t forget to support us, and Happy New Year 2020 to all of you!

Portrait photographer in Nancy-Metz. Calculation specialist, modeling and numerical simulation for image processing (denoising, deblurring, colour management) and thermal engineering. Developer of filmic RGB, tone equalizer, color balance, and the new themeable interface for darktable 3.0. darktable user since 2010. darktable is my job, so help me out to develop.

G'MIC 2.7 - Process Your Images with Style!

The IMAGE team at the GREYC research laboratory is pleased to announce the release of version 2.7 of G’MIC (GREYC’s Magic for Image Computing), its free, generic, extensible, and probably a little magical, framework for digital image processing.

The previous PIXLS.US article on this open-source framework was published a year ago, in August 2018. This new release is therefore a good opportunity to summarize the main features and milestones of the project’s life over the past twelve months. Fasten your seat belts, the road is long and full of surprises!

Useful links:

• The G’MIC Project
• G’MIC Twitter Feed
• G’MIC Forum on PIXLS.US

1. G’MIC in 300 words

G’MIC is a piece of software that has been developed for more than 10 years now, mainly in C++, by two members of the IMAGE team of the GREYC lab: Sébastien Fourey and David Tschumperlé. It is distributed under the terms of the CeCILL free-software license. GREYC is a French public research laboratory located in Caen, specialized in digital sciences, under the head of three academic institutions: CNRS, University of Caen, and ENSICAEN.

The IMAGE team, one of the seven teams in the laboratory, is composed of researchers, professors, Ph.D. students and engineers, all specialized in the fields of algorithmics and mathematics of image processing.

G’MIC is cross-platform (GNU/Linux, MacOS, Windows, …). It provides various user interfaces for manipulating generic image data, i.e. 2D or 3D hyperspectral images or sequences of images with floating-point values (which indeed includes “usual” color images). Around a thousand different processing functions are already available. However, arbitrarily many features can be added thanks to an integrated scripting language.

The most commonly used G’MIC interfaces are: the gmic command, that can be accessed from the command line (which is an essential complement to ImageMagick or GraphicsMagick), the G’MIC Online Web service, but above all, the plug-in G’MIC-Qt, available for the well-known image editing software GIMP, Krita, and Paint.net. It provides more than 500 different filters to apply on images.

Thanks to its extensible architecture, G’MIC is regularly enhanced with new image processing algorithms, and it is these latest additions that will be discussed in the following sections.

2. Add style to your images!

G’MIC has recently implemented a neat filter for style transfer between two images, available from the G’MIC-Qt plug-in under the “Artistic / Stylize“ entry. The concept of style transfer is quite simple: we try to transform an image (typically a photograph) by transferring the style of another image to it (for example a painting).

The implementation of such a style transfer method is relatively complex: The algorithm must be able to recompose the original photograph by “borrowing” pixels from the style image and intelligently combining them, like a puzzle to be reconstructed, to best match the content of the data to be reproduced, in terms of contours, colors and textures. How easily this is done depends of course on the compatibility between the input image and the chosen style. In computer graphics, most existing implementations of style transfer methods are based on convolutional neural networks, more particularly generative adversarial networks (GANs).

G’MIC implements style transfer in a different way (without relying on neural networks, the scientific article detailing the algorithm is currently being written!). This method is parallelizable and can therefore benefit from all the processing units (cores) available on the user’s computer. The computation time naturally depends on the input image resolution, and the accuracy of the desired reconstruction. On a standard 4-cores PC, it could take tens of seconds for low resolution images (e. g. 800x800), up to several minutes for larger pictures.

As one can imagine, it is a very versatile filter, since we can apply any style to any input image without hard constraints. Some famous paintings are available by default in the filter, in order to propose predefined styles to the user.

Let us be honest, it is not always easy to obtain satisfactory results from the first draft. It is generally necessary to choose your starting images carefully, and to play with the many parameters available to refine the type of rendering generated by the algorithm. Nevertheless, the filter is sometimes able to generate quite interesting outcomes, such as those shown below (the original photo is visible at the top left, the style chosen at the top right, and the result of the style transfer at the bottom). Imagine how long it would take for a graphic designer to make these transformations “by hand”!

Other examples of image stylization can be found on the image gallery, dedicated to this filter. To our knowledge, G’MIC is the only “mainstream” image processing software currently offering a generic style transfer filter, where any style image can be chosen.

A last funny experiment: get a picture of an Alien’s head, like Roswell, and then select a crop of the Mandelbrot fractal set as your style image. Use the transfer filter to generate a “fractal” rendering of your alien head. Then, make the whole world believe that the Mandelbrot set contains the mathematical proof of the existence of aliens… ☺

In short, this filter has a clear creative potential for all kind of artists!

3. Interactive deformation and morphing

This year, G’MIC got an implementation of the RBFs interpolation method (Radial Basis Functions), which is able to estimate a dense interpolated function in any dimension, from a known set of scattered samples (not necessarily located on a regular grid). Thus, it gave us the idea to add distortion filters where the user interaction is focused in adding and moving keypoints over the image. In a second stage, G’MIC interpolates the data represented by these keypoints in order to perform the distortion on the entire image.

Let us start with the “Deformations / Warp [interactive]” filter which, as its name suggests, allows the user to distort an image locally by creating/moving keypoints.

The animation below shows this interactive filter in use, and illustrates the fact that these keypoints can be considered as anchors to the image, when they are moved.

(For those who might be concerned about the portraits photos used in the figures above and below: all these portraits are totally artificial, randomly generated by GANs via the website This Person Does Not Not Exist. No moral prejudices to dread!).

The great advantage of using RBFs-based interpolation is that we do not have to explicitly manage a spatial structure between the keypoints, for instance by defining a mesh (i.e. a “deformation grid”). This gives a greater degree of freedom in the obtained distortion (see Fig.3.3. below). And at the same time, we keep a rather fine control on the local amplitude of the applied distortion, since adding more “identity” keypoints around a region naturally limits the distortion amplitude inside this region.

A short demonstration of this distortion filter is also visible in this Youtube video.

And why not extending this kind of distortion for two images, instead of a single one? This is precisely what the new filter “Deformations / Morph [interactive]” does. It is able to render a morphing sequence between two images (put on two separate layers), using the same interpolation technique that only asks for the user to set colored keypoints which match on both images.

In the example above, keypoints are placed on characteristic areas of both faces (tip of nose, lips, eyebrows, etc.). In practice, this takes no more than 5 minutes. Thanks to these keypoints, the algorithm is able to estimate a global deformation map from one image to another, and can generate temporally “mixed” frames where the elements of the face remain relatively well aligned during the whole morphing sequence.

By comparison, here is what we would obtain by simply averaging the two input images together, i.e. without correcting the displacement of the facial features between both images. Not a pretty sight indeed!

Thus, the morphing filter is able to quickly generate a set of intermediate frames, ranging from the “Source” to the “Target” faces, a sequence that can then be saved as an animation.

Many other use cases of this morphing filter can be considered. The following example illustrates its application to render an animation from two photographs of the same object (a garden gnome), but shot with different DOFs (Depth of Field).

Command line users will be pleased to know that these two filters can be tested very quickly from a shell, as follows:

$ gmic image.jpg x_warp
$ gmic source.jpg target.jpg x_morph
~

4. Ever more colorimetric transformations

For several years, G’MIC has contained colorimetric transformation filters able to simulate the film development process, or to give particular colorimetric moods to images (sunlight, rain, fog, morning, afternoon, evening, night, etc.). In a previous report, we already mentioned these filters, which are essentially based on the use of 3D CLUTs (Color Lookup Tables) for modeling the color transformation.

A 3D CLUT is technically a three-dimensional array that provides for each possible RGB color, a replacement color to apply to the image.

The main interest of these 3D CLUTs is the great variety of transformations they can represent: They can indeed define RGB-to-RGB functions with almost any kind of variations. The only “constraint” of these methods is that all image pixels having the same color will be transformed into pixels that also have an identical color.

The disadvantage, however, is that these 3D CLUTs are relatively data intensive. When you want to embed several hundred different ones in the same piece of software (which is the case in G’MIC), you quickly find yourself with a large volume of data to install and manage. For instance, our friends at RawTherapee offer on their website an additional pack of 294 CLUTs functions to download. All these CLUTs are stored as .png files in a .zip archive with a total size of 402 MB. Even if downloading and storing a few hundred _MB_ is no longer limiting nowadays, it is still quite large for things as simple as color changing filters.

This year, we have therefore carried out important research and development work at the GREYC lab on this topic. The result: a new lossy compression algorithm (with visually imperceptible compression losses) that can generate binary representations of CLUTs with an average compression rate of more than 99%, relative to the data already loslessy compressed. The general idea is to determine an optimal set of color keypoints from which the CLUT can be reconstructed (decompression), and this, with a minimal reconstruction error.

As a result, this original compression method allowed us to offer no less than 763 CLUTs in G’MIC, all stored in a binary file that weights less than 3 MB !

All these color variation filters have been grouped into two separate entries in the G’MIC-Qt plug-in, namely “Colors / Simulate Film” (for analog film simulations), and “Colors / Color Presets” (for other color transformations). Each of these filters provides sub-categories for a structured access to the hundreds of CLUTs available. To our knowledge, this makes G’MIC one of the image processing software with the most colorimetric transformations, while keeping a reasonable size.

Readers interested in the mathematical details of these CLUT compression/decompression algorithms may refer to the scientific paper we wrote about it, as well as the presentation slides that have been presented at the conferences GRETSI’2019 (French conference, in Lille) and CAIP’2019 (International conference, in Salerno).

To finish with this topic, note that we have made an open-source implementation of our decompression algorithm of CLUTs available online (in C++, with 716 CLUTs already included). Discussions have also been initiated for a potential integration as a Darktable module for managing 3D CLUTs.

5. Create palettes by mixing colors

Let us now talk about the recent “Colors / Colorful Blobs” filter which is directly inspired by the original concept of Playful Palette created by the Adobe Research team in 2017. This filter is intended for illustrators (designers and digital painters). The goal: Create color palettes which contain only a few main colors (the ones you want to use in an illustration), but also a few sets of intermediate shades between these colors, in the form of color gradients. An artist is theoretically able to better preserve the color coherence of its artwork, by picking colors only from this palette.

As shown on the figure above, the filter allows the artist to create and move colored “blobs” that, when merged together, create the desired color gradients. The result of the filter is thus an image that the artist can use afterward as a custom 2D color palette.

From a technical point of view, this filter is based on 2D metaballs to model the color blobs. Up to twelve separate blobs can be added and different color spaces can be chosen for the calculation of the color gradient (sRGB, Linear RGB or Lab). The filter also benefits from the recent development of the G’MIC-Qt plug-in that enhances the user interactivity inside the preview widget (a feature we mentioned in a previous report), as seen in the animation below (see also this longer video).

This filter may not be useful for most G’MIC users. But you have to admit, it’s pretty fun, isn’t it?

6. Some more filters

Let us now describe a selection of a few other filters and effects added during the year, perhaps less original than the previous ones (but not completely useless anyway!).

• First of all, the “Rendering / Symmetric 2D Shape” filter is a great help when you want to draw geometric shapes having angular symmetries.

  

  The plane can be subdivided into up to 32 angular pieces, each of which can contain a maximum of six keypoints to define a shape profile, allowing potentially complex and varied shapes to be rendered (such as the super-shuriken below!).

  

• The “Degradations / Self Glitching” filter combines an image with a shifted version of itself, to create a Glitch-art type image. Several bitwise operations (Add, Mul, And, _Or_, Xor,…) can be chosen and you can adjust the shift direction and amplitude, as well as various other controls.

  

  Again, this is not a filter that will necessarily be used every day! But it may be helpful for some people. It was actually added in response to a user request.

• In the same style, the “Degradations / Mess With Bits” filter applies some arithmetic operations to the pixel values, seen as binary numbers (for instance, bit shift and bit inversion). Always with the idea of rendering Glitch art, of course!

  

• The “Degradations / Noise [Perlin]” filter implements the generation of the Perlin noise, a very classical noise model in image synthesis, used for the generation of elevation maps for virtual terrains. Here we propose a multi-scale version of the original algorithm, with up to four simultaneous variation scales.

  

• The “Frames / Frame [Mirror]” filter is also a “tailor-made” effect, to meet the needs of a G’MIC-Qt plug-in user. This photographer wanted to resize his photos to obtain a precise width/height ratio, but without having to crop his images. The solution was instead to add image information at the edges of the picture, by symmetry, in order to obtain the desired ratio. So that’s what this filter does.

  

• Finally, let us mention the upcoming advanced image noise reduction filter, by Iain Fergusson, whose development is still in progress. Iain has been contributing to G’MIC for several years now by implementing and experimenting original denoising filters, and his latest project seems really interesting, with promising results. This video shows this filter in action, a good place to learn a little more about how it works.

Now that we’ve looked at these new filters, it seems important for us to remind that, as in many IT projects, this visible part of the iceberg hides a set of lower-level developments done to improve the interactive possibilities of the G’MIC-Qt plug-in, as well as the performance of the internal scripting language interpreter (the G’MIC language), which is how all these filters and effects are actually implemented. These improvements and incremental slight optimizations of the code base benefit to all filters (even those already available for several years) and it actually represents most of the development time we spend on G’MIC. So, dear users, do not be surprised if no new filters appear for a while. It is probably just because we are doing serious work on the G’MIC framework core!

7. Other notable points in the project life

Here are listed some other important news that have punctuated the life of the project since August 2018.

7.1. We now accept donations!

This is essential news for us: since March 2019, the G’MIC project has been granted permission to collect donations (via Paypal), to help in its maintenance and development!

This is a good thing, because until now, there was no simple way for a public research laboratory as the GREYC, to accept donations for supporting the development of a free software application such as G’MIC, an application used daily by several thousand people around the world. And we have currently no other ways to finance this piece of software in the long term.

Thus, we have partnered with LILA (Libre comme l’Art), a French non-profit organization promoting Arts, Artists and Free Software, who accepted to collect donations for us.

In practice, this is something that has been a little long to set up, but now that the donation system is operational, we hope to benefit from it in the future to make the project development even faster (the possible use of the raised funds is detailed on the donations page, this being of course very dependent on the amount of money collected).

For the sake of transparency, we will post the monthly amount of collected donations on the project website. At this point, we don’t really know what to expect in practice. We will see how these donations evolve. Of course, we would like to thank all those who have already participated (or plan to do so) in supporting our open-source framework for image processing. Our ultimate dream would be, one day, to say that the illustration below is only a distant memory!

7.2. Integrating “Smart Coloring” into GIMP

Let us also mention the work of Jehan, known to PIXLS.US readers as a regular GIMP developer. Jehan has been hired by the GREYC laboratory in September 2018, to work on G’MIC (for a 12-month fixed-term contract), thanks to a grant funded by the INS2I Institute of the CNRS (for which we are grateful).

One of its first missions was to re-implement the G’MIC “Smart Coloring” algorithm (that we had already talked about previously) as a new interactive mode integrated into the existing GIMP “Bucket Fill“ tool.

Jehan described all his work in a blog post, which is strongly recommended for reading. Of course, we don’t want to copy his post here, but we want to mention this activity, and to consider it as another original contribution of the G’MIC project to free software for graphic creation: at the GREYC laboratory, we are really happy and proud to have imagined and developed an image colorization algorithm, which artists can use through a well integrated tool into such a popular piece of software as GIMP!

This intelligent colorization algorithm has been the subject of scientific publications, presentations at the conferences GRETSI’2017, EuroGraphics VMV’2018, as well as at the Libre Graphics Meeting’2019. And it is with a great pleasure we see this algorithm is used in real life, for various realizations (as in this great video of GDQuest, for colorizing sprites for video games, for instance).

Scientific research carried out in a public laboratory, which becomes available for the general public, that is what we want to see!

7.3. Other news related to the G’MIC project

• Recently, a major improvement in the performances of G’MIC under Windows has been achieved, by recoding the random number generator (now reentrant)) and removing some slow mutex which were responsible of performance drops for all filters requiring sequences of random numbers (and there were many!). As a result, some filters are accelerated by a factor of four to six under Windows!

• Since December 2018, our G’MIC-Qt plug-in is available for Paint.net, a free graphic editing software application under Windows (not open-source though). This has been possible thanks to the work of Nicholas Hayes who wrote the glue code allowing the interaction between our G’MIC-Qt plug-in and the host software. Users of Paint.net are now able to benefit from the 500+ filters offered by G’MIC. This plug-in, available here, has already been voted “Best Plug-in of the Year 2018“ by the members of the Paint.net forum ☺ !

• Since October 2018, the G’MIC-Qt plug-in for GIMP has been compiled and proposed for MacOS by a new maintainer, Andrea Ferrero, who is also the main developer of the free software application Photoflow, a non-destructive image editor (more information here). Many thanks Andrea, for this wonderful contribution!

  • Since the announced shutdown of the Google+ social network, we have opened two new accounts, on Framasphere and Reddit, to share news about the project’s life (but the Twitter feed is still our most active account).

• Let us also thank Santa Claus, who kindly brang us a materialized version of our mascot “Gmicky” last year. That looks almost perfect!

  

• The G’MIC project was presented at the FENO, the “Fête de l’Excellence Normande“, from 12 to 14 April 2019, at the Caen Exhibition Centre. We were hosted on the stand of the CNRS Normandie, and we carried out demonstrations of style transfer (teaser) and automatic illumination of clip arts (teaser), for the general public.

  

• And to dig even deeper, here are some other external links we found interesting, and which mention G’MIC in one way or another:
  • A video presentation of the plug-in G’MIC-Qt, by Chris’ Tutorial;
  • The Youtube channel MyGimpTutorialChannel offers a lot of videos showing how to use G’MIC-Qt in GIMP to achieve various effects (mostly in German);
  • The Clinic, a Chilean weekly newspaper, apparently used G’MIC to achieve an effect on one of its covers (via the smoothing filter “Artistic / Dream Smoothing”);
  • Another video tutorial, showing how to use the G’MIC “Artistic / Rodilius” filter to create stylized animal photos.

8. The future

As you see, G’MIC is still an active open-source project, and with its 11 years of existence, it can be considered as mature enough to be used “in production” (whether artistic or scientific).

We have never defined and followed a precise roadmap for the project development: the functionalities come according to the needs of the developers and users (and the limited time we can devote to it!). At the moment, there is a lot of interest in image processing methods based on neural networks, and deep learning techniques. It is therefore possible that one day, some of these methods will be integrated into the software (for instance, we already have a prototyped code running in G’MIC that actually learns from image data with convolutional neural networks, but we are still at the prototyping stage…).

After 11 years of development (make it 20 years, if we include the development of the CImg library on which G’MIC is based), we have reached a point where the core of the project is, technically speaking, sufficiently well designed and stable, so as not to have to rewrite it completely in the next years. In addition, the number of features available in G’MIC already covers a large part of the traditional image processing needs.

The evolution of this project may therefore take several paths, depending on the human and material resources that we will be able to devote to it in the future (for the development, but also in project management, communication, etc.). Achieving an increase in these resources will undoubtedly be one of the major challenges of the coming years, if we want G’MIC to continue its progress (and we already have plenty of ideas for it!). Otherwise, this image processing framework might end up being just maintained in its current (and functional) state. It is of course with a hope for progression that we have recently set up the donation page. We also hope that other opportunities will soon arise to enable us to make this project more visible (you are invited to share this post if you like it!)

That’s it for now, this long post is now over, thank you for holding on until the end, you can resume normal activity! I’ll be happy to answer any questions in the comments.

Post-scriptum: Note that the 3D animation displayed as the teaser image for this post has been actually generated by G’MIC, via the command $ gmic x_starfield3d. An opportunity to remind that G’MIC also has its own _3D_ rendering engine capable of displaying simple objects, which is very practical for scientific visualization! We may have the occasion to talk about it again in a future post…

A special thank you for reviewing and helping to translate this article to:
Patrick David, Sébastien Fourey, Christine Porquet, Ryan Webster.

Quick digiKam Tip: Back up digikamrc file

digiKam stores the current state of the application in the ~/.config/digikamrc file. This file keeps track of pretty much everything: from the database connection profile and custom toolbar settings, to the last-used curve and sharpening parameters. So next time you install or reinstall digiKam, don’t forget to back up the digikamrc file. This way, you don’t have to configure a fresh digiKam installation from scratch. Simply copy the file to a safe location or external storage device, and drop the file into the ~/.config folder before you run digiKam.

Location Tracking for Photographers with GPS Logger and Trekarta

When it comes to Android apps for photographers, we are spoiled for choice. From depth-of-field and golden hour calculators to sun position and remote control apps – there are plenty of clever tools to choose from. But there is one particular app combination that can prove to be indispensable for any photographer on the move: a GPS logger and a GPX viewer. There are two main reasons for that.

1. Tracking your movements and saving them in the GPX format can come in handy for geotagging photos.

2. The ability to attach comments to the current location allows you to use the GPS logging app to note places you either photographed or you plan to photograph later. You can then use a GPX viewer app to see and manage bookmarked locations.

There are several apps that offer GPS logging and viewing, but you can’t go wrong with GPS Logger for Android and Trekarta. Both apps are released under an open source license, and they are available free of charge on Google Play and F-Droid.

How you set up GPS Logger for Android is a matter of personal preference. One way to go is to configure the app to automatically start tracking on boot and upload tracks to the desired destination (e.g., a NAS or a file sharing service).

Once GPS Logger for Android is running, adding a comment to the current location is as easy as pulling down the notification drawer and tapping Comment. The app saves the tracks as GPX files in the Android/data/com.mendhak.gpslogger/files directory on your Android device. To view a GPX file in Trekarta, use a file manager to navigate to the directory, and use Android’s sharing functionality to send the desired GPX file to Trekarta.

Processing a nightscape in Siril

A basic tutorial

Siril is a program for processing astronomical photographs.

In this tutorial, I’ll show you how to process a nightscape in Siril 0.9.10.

It doesn’t intend to be comprehensive tutorial but rather to present a basic general workflow that is a good starting point for those who want to learn Siril.

For this purpose, I’m sharing the raw files I used for the image I presented here, except that for this tutorial I limited the number of frames for the sake of bandwidth and processing speed.

You can find and download the raw files here (~1GB).

Setup

The raw files are placed in specific sub-folders according to their use:

• bias/offset frames → ./Bias (20 files)
• dark frames → ./Darks (15 files)
• flats field frames → ./Flats (15 files)
• main subject/light frames → ./Lights (10 files)

Bias, dark, and flat field frames are also called “calibration” frames, their purpose being to improve the quality of the image by correcting the signal-to-noise ratio (in the case of bias and dark frames) and vignetting (with the flat frames). There are several places where you can learn more about the different types of frames for astrophotography.

At the root of the folder, I placed two text files with the .ssf extension, these are scripts used by Siril for batch processing the files. Quite useful. If you want to run a script from Siril, place the .ssf files in ~/.siril/scripts. Upon restarting Siril, a new Scripts menu appears in the top menu bar, allowing you to launch the installed scripts.

I suggest you download the whole folder (~1GB), and move the scripts as indicated above. This way, if you set the working directory in Siril to the root of the folder, launching the script named processing_from_raw.ssf will automagically process the raws and create the output image in both .fit and .tif (16-bit) formats. Please note that in order to successfuly run the scripts, there must be a folder structure like the one used in this tutorial.

Step-by-step processing

I will present the steps I used to process an image of the Milky Way. I don’t know if it’s the best way, but it’s probably close to what the developers of Siril advise to do for the general case of starting from raw files (actually, I started from one of their scripts and just slightly adapted it).

We will start with processing the calibration files, and then processing the lights.

Preparing the bias frames

1. Set the working directory to the Bias sub-folder by clicking on Change dir….

2. We will use the 20 bias frames to generate a master-bias frame. To load the bias frames, click on the + button as shown (make sure that you select RAW DSLR Camera Files in the combo box) and select the bias frames located in the Bias subfolder.

3. In the “Sequence name” field, enter bias (or whatever you see fit) to set the prefix of the sequence and subsequent files, and click Convert to convert the files to the FITS format, which is the main format used by Siril. Note that you don’t need to demosaic the files yet, make sure the Debayer box is unchecked.

When done converting the bias frames, a window will pop up showing a preview of one of the bias frames. Note that since it’s not demosaiced, it will only show as a B&W channel image.

At this point, the bias frames are loaded and ready to be processed to make a master-bias frame.

4. In the Stacking tab, choose Average stacking with rejection as stacking method, and No normalisation under the normalisation combo box. You can leave the Sigma parameters at their default (unless you know or want to experiment for better values).

It should look like this:

5. Click on the Start stacking button. The resulting master-bias frame will be saved as bias_stacked.fit in the Bias subfolder.

Preparing the flat field frames

Since the flats also contain the sensor readout noise (contained in the bias frames), we should remove it by subtracting the master-bias.

1. In the File conversion tab, remove the files already loaded by clicking on the button located just below the - (minus) button, and by clicking on the + (plus) button select and load the flat frames located in the Flats subfolder.

2. Set the working directory to the Flats sub-folder by clicking on “Change dir…” and set the Sequence name as “flats”.

3. Like for the bias frames, ensure Debayer is unchecked, then click on Convert.

4. In the Pre-processing tab, check only the Use offset box, click on Browse to select the Bias/bias_stacked.fit file, and click on Start pre-processing.

5. To generate the master-flat, go to the Stacking tab, and this time set Normalisation to Multiplicative and the Stacking Method as Average with rejection.

6. Click on Start stacking to produce the pp_flat_stacked.fit master-flat frame in the Flats subfolder.

Preparing the dark frames

As with the bias and flats, you need to load the dark frames.

1. In the File conversion tab, remove the files already loaded, select and load the dark frames located in the Darks subfolder.

2. Set the working directory to the Darks sub-folder by clicking on Change dir…, and set Sequence name as darks.

3. Debayer should be unchecked.

4. Click on Convert.

5. The darks need to be stacked the same way as the bias frames. In the Stacking tab, choose Average with rejection and No normalisation.

6. Click Start Stacking.

The master-dark frame is saved as Darks/dark_stacked.fit.

Note: if you take images often in the same conditions (same air temperature, same exposure settings), you can save the dark_stacked and pp_flat_stacked files, and re-use them to process future light frames faster. I read on some forums that some astrophotographers keep their calibration files and use those for around 1 year, before taking new calibration frames.

Preparing the light frames

Now it’s time to start processing the light frames, by first subtracting the darks (which also contain the bias signal) and the flats (from which bias has already been subtracted).

1. Select the light frames in the File conversion tab.

2. Set the Sequence name to lights, and point the working directory to the Lights (Change dir...).

3. Convert the files, still without debayering.

4. Then go to the Pre-Processing tab, check Use dark, select the Darks/dark_stacked.fit file, check Use flat, and select the Flats/pp_flat_stacked.fit file.

5. Make sure that the other boxes are checked as in the following screenshot.

Note that “Cosmetic Correction” can also be done from the “Image Processing” tab.

6. Click Start pre-processing.

This will produce new FITS files with the prefix pp_light_ and the corresponding .seq file. These files are loaded.

Demosaicing the files

It’s time to demosaic our processed files. There’s something strange in the GUI, in that after pre-processing, when you uncheck “Use dark” and “Use flat” boxes, the “Debayer FITS images before saving” and the “Start pre-processing” button become grayed out.

1. In the File conversion tab, remove the selected files and load the 10 pp_light_000xx.fit files.
2. Check the Debayer box and write db_pp_light as the sequence name.
3. Click Convert.

The pre-processed lights will be saved as FITS files, and the corresponding db_pp_light.seq file loaded. Two preview windows will open this time, one with the 3 RGB channels separated, and one with the RGB composite image.

4. In the Register tab, select Global Star Alignment (deep-sky) from the registratrion method drop-down list and click Go register.

If you have more 8GB of RAM, you can try checking the Simplified Drizzle x2 box (it will up-sample the images by a factor 2, increasing the RAM usage by a factor 4). Siril will detect the stars and register each of the 10 images. The preview windows will be updated. By the way, you can play with the zoom and select AutoStretch to get a better preview of the selected image.

5. In the Stacking tab, make sure that Average with rejection is selected as the stacking method, and that Additive with scaling is set for Normalisation.

6. Click on Start stacking.

The resulting aligned and stacked image will be saved as Lights\r_db_pp_light_stacked.fit.

7. At this step, you can also save the resulting image as JPEG, TIFF, PNG, etc. for further processing in your favorite image editor. On the menu, just click on File > Save As, and pick the image format you wish (or right-click on the RGB windows and pick the format that best suits you).

Post-processing the image

Siril can do some more or less specialized post-processing to your image. I found it interesting to use.

• While the stacked image is still loaded in Siril, you can apply a log transform (it is in linear mode in Siril). I haven’t found how to do it in the GUI, but you can simply type “log” in the “Console” field at the bottom of the Output logs tab, in the main window.
• Still in the console field, you can use the command “crop” followed by the coordinates of the bounding box in pixels, to crop the image (some auto-detection tools in Siril require the image to be cropped to remove the borders introduced by aligning the images, in order to work properly). For example, my image can be cropped by typing crop 30 30 5950 3970.
• You can apply green noise removal in the “Image Processing” tab > “Remove Green Noise…”.
• Lucy-Richardson deconvolution can be applied in “Image Processing” menu option > “Deconvolution…”. 10 iterations and a Sigma value of 0.6 are a good starting point.

The resulting image can be saved as JPEG, TIFF, PNG, etc. for further processing in your favorite image editor or as a finished image if you’re satisfied.

Processing for the foreground

The problem with this whole process, is that because the images have been aligned with the stars as reference, the foreground will be blurred because earth moved between successive frames. What I do is to reprocess the light frames from just after the calibration step (i.e. after the dark and flat frames subtraction) but only skipping the stars registration step. By doing so, the foreground will undergo the same pre- and post-processing, and the resulting image will have a sharp foreground and trailing sky.

I provided a script (processing_from_raw_foreground.ssf) which will do that for you, if you already used the first script or if you use the same file naming convention as in the script.

Finally, in your favorite image editor, you can combine the “sky” and “foreground” images using a mask, to get both the sky and the foreground sharp.

Here’s what I obtained following these steps (but using the scripts), after just combining the 2 images in Gimp:

And after quick curve and saturation tweaking in Gimp:

New Topic Previews

Image previews now available for some categories

I’ve been a member of the community over at blenderartists.org (previously elysiun) for a long time (it’ll be 15 years this October according to my profile there). So it was nice to see when they finally transitioned to using Discourse a little while back.

What I really liked, though, was the work that Bart did to specific pages and tag lists to display them. Here’s what their current homepage looks like:

They use a different default main page style, “Categories” view, than we do (“Latest”). This just shows the site categories as a column on the left, then the latest posts in a column on the right.

The row of featured images along the top is actually part of a plugin that I’ll get to in a moment.

If you want to change your own default main page view of the forums, you can modify it at your account Preferences → Interface (and change it to Categories):

Fancy Category Views

The default landing page is neat, but what they did with their forum gallery page is much neater:

They set up the Topic List Previews plugin so the entire category is actually viewed as a tile of images. I think we can all agree that this is generally a much nicer way to view categories that are heavily image-based. Of course, I thought this was a natural fit for us as well!

So through the magic of having an invaluable resource like a darix, he was able to make it a reality for us!

We’ve got it implemented now on the Play Raw category (now its own sub-category under the Processing category), the Critique, and the Showcase category. If you haven’t had a chance to check it out yet, please do. (darix announced it in the thread Play raw posts and you so feel free to give us any further feedback in that topic.)

Keep in mind that for those categories, the preview image will correspond to the first image in the first post. Try to remember to make the first image in those category topics the one you’ll want in the preview.

We haven’t enabled the featured row of images after some initial feedback. We may revisit it again at some point, but hopefully the Play Raw and Showcase categories will look a little better now. It certainly makes the categories a little easier and faster to navigate now that you can see the previews directly on the page.

G'MIC Finally Accepts Donations

Help support an awesome team!

For years the incredible team over at G’MIC (GREYC’s Magic for Image Computing) have been producing an incredible image processing system and many awesome filters to go along with it. They’ve got an very active and awesome community right here on their forums and they’ve been producing all manner of neat processing filters for photographers, digital artists, and scientists.

Due to the project being under the auspices of a French Research Lab, the GREYC laboratory in Caen, France, they were limited in being able to accept any donations.

Until now!

To avoid burying the lede, go and make a donation to the fabulous folks of the G’MIC project: https://libreart.info/en/projects/gmic.

I first heard about GREYCstoration (proto-G’MIC) a long time ago (over 10 years) as the only really viable Free Software image denoising option for photographers. It allowed me to de-noise images on par (or better in many cases) with the then popular Noise Ninja. It’s been an essential part of my toolkit ever since!

Back then David Tschumperlé was really only looking for postcards from users as a “thank you” and maybe some occasional donations to pay for hot chocolates during the day. I finally got to buy him a milkshake while at the Libre Graphics Meeting 2014 in Leipzig, Germany and for the value he has provided me with his software I owe him many, many more!

Value is exactly what I want to bring up in this post. I’m sure many here have had an opportunity to use G’MIC in some form and any attempt at listing the wide range of filters and capabilities it provides would not do it justice. If you’ve realized some value from the project, now is the time to show some love.

I’ve been lucky to call David a friend for a long time now and I can personally attest to his kindness and sincerity. With that in mind I implore you: if you have a few spare dollars, euros, yen, pesos, or gold bullion please consider donating to the project and make sure the milkshakes (or hot chocolates) never stop flowing. David (and Sébastien Fourey!) are a sound investment in providing high value to Free Software artists and photographers!

Donate to the G’MIC project!

(David is too modest to really come out and ask for support but “modest” isn’t really in my vocabulary - so go donate!)

LILA

For a long time David was unable to accept donations from community members. There were some concerns from the research institution his lab is a part of in France. Just recently, though, they managed to reach an agreement where the funds flow through a French non-profit called Libre Comme L’Art, LILA, that includes the fabulous Jehan Pagès of the GIMP team as a member and where the ZeMarmot animated film is being produced.

A big “Thank You!” to Jehan and LILA for making this possible!

A Q&A with the CHDK Developers

Adding Features to a Camera: Hacker Meets Photographer

Introduction

CHDK is a free, open source software add-on that runs on Canon PowerShot cameras and expands their functionality. Some of its features are:

• Professional control: RAW files, bracketing, manual control over exposure, zebra mode, live histogram, grids, etc.
• Motion detection: Trigger exposure in response to motion, fast enough to catch lightning.
• USB remote: Simple DIY remote allows you to control your camera remotely.
• Scripting: Control CHDK and camera features using uBASIC and Lua scripts. Enables time lapse, motion detection, advanced bracketing, and more.
• PTP: Shooting control, live view, and file transfer from Linux and Windows.

I talked with the core team of developers to learn more about CHDK.

How did CHDK start? Who were the first developers? What was their role in those first steps? Do you have any information on who those people are, where they come from, or their professional background?

reyalp: That was before my time. The very first developer was VitalyB, and I don’t know much about his background.

In truth, CHDK is very loosely organized and informal, so I don’t know much about current contributors backgrounds either.

waterwingz: Before my time too. The original hack seems to have taken off in 2006/2007 when it got mention on the dpreview.com site. Many people shared random bits and pieces based on what they were personally interested in working on. There was no project organization and people did their own builds.

At some point, I believe someone with the nick GrAnd, got things organized around a wikia site and created a standardized set of build tools. Eventually an online discussion forum and autobuild server were added - not sure who gets credit for those.

But over the last 10 years, more or less, reyalp has coordinated the ongoing volunteer development efforts. There is still no real plan or schedule but there seems to be community consensus of how things get done and what gets added to the package.

Some people say that CHDK was first developed by Andrei Gratchev (here and here). I believe he is GrAnd, right? Do you know something about it? Is it possible that Andrei Gratchev is VitalyB?

reyalp: GrAnd (Andrei Gratchev) and VitalyB are definitely not the same person. They have separate accounts on assembla.com. VitalyB did the very first work on what eventually became CHDK, while GrAnd was an early developer who played a major role in organizing the project. It’s possible that GrAnd originated the name CHDK. I don’t know that history directly, but it could explain confusion over whether he was the founder.

Canon cameras run on DIGIC boards. As far as I’m aware of, at the time VitalyB did the first hack, people had already hacked DIGIC-I compact Canon cameras and could execute custom programs. What was the big leap (in terms of development or finding hooks in the DIGIC-II firmware) that VitalyB made?

reyalp: The original Digic-I cameras were actually ROM DOS running on a 16 bit x86 clone (except for S1 IS, which is VxWorks on ARM and has a partial CHDK port developed by srsa_4c).

A hack for the DOS based cameras was developed by a Czech developer.

I don’t know if VitalyB was aware of this work, but the platforms were so different there wouldn’t likely have been much overlap.

waterwingz: As far as I know, the big leap in hooking the DIGIC-II firmware was figuring out how to hack Canon’s firmware update process.

It’s stated that he hacked the firmware update process and executed his own program instead of the firmware update itself. That first program aimed to make a copy of Canon firmware. How exactly could he get a copy of the Canon firmware by blinking a LED? Why did he need a copy of Canon firmware?

waterwingz: From what I understand, he assembled a little piece of code that loaded and ran in the place of the expected firmware update code.

Once he could do that, by trial & error he learned what memory address needed to be poked to turn one of the camera’s LEDs on & off. And once he could do that, he recoded so as to dump the camera’s memory contents serially via that LED to a phototransistor interfaced to an external computer.

After that it was a matter of reverse assembly of the raw code to learn how the rest of the boot process and camera firmware worked.

reyalp: I don’t know the specifics of exactly what VitalyB did for the very first camera, but generally to make a hack work with the existing firmware, you need a copy of the firmware code to disassemble and analyze.

The advantage of using LED blinking is that the code is really simple: you just need to know how to control an LED (done writing to specific address on these cameras) and a loop.

In contrast, writing a file to the SD card requires a whole stack with an SD driver, a filesystem driver and so on.

Without having already analyzed the firmware, you don’t know how to interface with those things, and on PowerShot cameras, they aren’t really available after a firmware update file is loaded.

Blinking was used frequently in the early days of CHDK, but around 2010 Alfredo Ortega and Oren Isacson of Core Labs worked out how to run scripts in Canon’s native scripting language (which we call Canon Basic). I wrote a script to dump the original firmware from Canon Basic, and we’ve used that as the primary way of dumping firmware ever since.

Canon DSLR’s also allow this same kind of hack. Why did VitalyB start with point-and-shoot cameras?

waterwingz: I’m guessing, but probably he started there because he happened to own a PowerShot and not a DSLR. Or maybe it was just the first device that he was able to find a backdoor into.

reyalp: While Canon DSLRs and P&S use the same basic CPU and operating systems, the rest of the code is very different.

Running custom code on Canon DSLRs uses different mechanisms which weren’t figured out until much later.

My impression is VitalyB started on the camera he had (PowerShot A610?).

The lower cost of P&S also makes them more attractive to experiment with, and before the rise of smartphones, P&S were much more common than DSLRs so there was a better chance of interested developers having them.

Are there any ties between CHDK and Magic Lantern (a CHDK equivalent for Canon DSLRs)?

waterwingz: There are several people who participate in both projects and some discoveries are occasionally useful to both. But there is no coordination beyond that.

reyalp: We do share information and occasionally code, but as mentioned above, the Canon firmware up to now has been quite different. Some of the initial DSLR research took place on the CHDK forum.

CHDK was born as HDK, or Hack Development Kit, and only later the “C” was added. Regarding the idea behind the name, what exactly does it mean to say that CHDK is not a simple firmware add-on, but a development kit? Does it have to do with the capability of loading and executing custom user scripts?

waterwingz: Way before my time again - I’d only be speculating on the name’s origin. I guess the kit designation means you get the source code to do development with. I don’t think it has anything to do with user scripting capabilities.

Is this kind of hack only possible on Canon cameras? Why?

waterwingz: The exact details and mechanism will only work on Canon PowerShot cameras. They all build on how Canon supports firmware upgrades (even though CHDK does not actually modify any of the camera’s firmware).

To do something similar on a different brand of camera, you’d need to find a way to exploit any firmware update method they might provide. If there is no such mechanism, you’d need to get lucky and find some other vector.

reyalp: As waterwingz says, the specifics only apply to these cameras, but in general, most embedded devices are hackable with enough effort.

Manufacturers put varying levels of effort into preventing it, but the success of CHDK (and later Magic Lantern) involves a lot of stuff that just lined up by chance.

Another important factor in these projects is that reverse engineering is additive: the more you build and understand, the easier it is to keep up with upstream changes in new models. It’s also easier for people to add useful features, which gets more people involved and keeps the whole thing going.

Getting to that critical point on an entirely new system requires a lot of effort and/or luck.

Some of the lucky things that lined up to make CHDK take off were:

• The cameras ran VxWorks on ARM 946E-S, both of which had significant public documentation. Canon later switched to their proprietary DryOS operating system, but by that point CHDK had enough built up knowledge to carry on.
• Canon left a lot of diagnostic stuff in the code and didn’t put a lot of effort into stopping unauthorized code from running.
• There were a lot of PowerShots in circulation and they were affordable, which provided more chances of a developer with the reverse engineering skills having one.
• Canon didn’t make any effort to stop it.

Can authorized warranty repair shops refuse to service cameras because of CHDK? Does CHDK use leave any traces?

waterwingz: So far it has not been a problem as CHDK runs in RAM - it makes no permanent changes to the camera. When you turn the camera off, it disappears and you have to reload it the next time you use it.

And while Canon has made no official statements about CHDK one way or the other, there is an email somewhere from someone in Canon tech service stating that as long as CHDK did not modify the camera in any way, there was no warranty issue.

If you remove the SD card containing CHDK prior to sending your camera for service, there is really no way of anyone knowing you’ve used CHDK.

reyalp: CHDK doesn’t normally leave obvious traces, but if the camera crashes, traces of CHDK can appear in an internal crash log the Canon firmware stores in onboard flash memory.

It’s certainly possible that other traces could be present, the cameras have a lot of sub-components that could store their own diagnostic information.

I don’t recall any cases of anyone reporting having warranty service rejected for this, but that doesn’t mean it couldn’t happen.

Could you give a brief explanation of how CHDK is designed? Do you have any kind of diagram that could illustrate it?

waterwingz: CHDK is a volunteer effort and most volunteers would rather code than document in detail.

But you can learn a lot reading the For Developers section of the CHDK Wikia.

A short description is that CHDK loads by hijacking the camera’s firmware update process and then intercepts some of the camera’s RTOS tasks and replaces them with its own tasks. The CHDK tasks typically replicate the functionality of the original camera tasks but add features and functionality not included in the original Canon code.

In what language is CHDK built?

waterwingz: A combination of ARM assembler and C.

philmoz: I would add Lua to that - a lot of useful features are now in the scripts. waterwingz has built some impressive functionality with his scripts.

I suppose we should also include uBasic as we still include some testing scripts written in it. uBasic is very primitive compared to Lua, so Lua scripts are preferred.

Finally there is also the Canon Basic built into the firmware - we use this to do firmware dumping.

What were some of the difficult issues in making CHDK easier to port to new cameras?

waterwingz: Ummm… who said it was easy?

But seriously, most of CHDK is based on guesses about how the original Canon hardware and firmware works. So much of the coding was done on a “try it and see” basis.

What makes it more difficult is changes to the firmware as Canon changes RTOS’s or generations of DIGIC processors.

philmoz: The Canon firmware remained pretty stable for a while. It continued to evolve but there weren’t any real upheavals until Digic 6. This made it easier to improve the tools, and take some of the guesswork out of ports.

We have a “sig finder“ tool that analyses a firmware dump and tries to find the things needed for a port. When I first started this was pretty primitive and a lot of things had to be done manually. I spent some time improving this tool, and I think that made porting a bit quicker until Digic 6.

waterwingz also created a GUI tool for disassembling the firmware in a way that could be used in a port - I added a scripting language to this to automate the generation of some of the files needed for a port, which I think helped with new ports.

With Digic 6 the architecture changed a lot and things slowed down quite a bit. A lot of reverse engineering on the new cameras has been done by srsa_4c, reyalp, ant, and others so things are getting better again.

reyalp: One of the things that makes it difficult is how many there are. The official CHDK source supports over 150 distinct models (many with multiple firmware versions that each require distinct ports), spanning Canon releases from 2004 through 2015.

Essentially the same CHDK code runs on all of them, so if a new model does something different, you have to figure out how to accommodate it without breaking the existing cameras.

On top of that, the developers don’t own most of the cameras, so testing is difficult.

As Philmoz mentioned, with Digic 6, Canon moved to a ARMv7 architecture processor and a new display system with a TAKUMI GPU, which took a lot of work supporting. srsa_4c did much of the initial reverse engineering work, while I took the concepts from Philmoz‘s “sig finder“ and implemented them in a new tool based on the open source Capstone disassembly library.

nafraf: The scripting language developed by Philmoz helped a lot to port until Digic 5+ cameras. Using code_gen tool it was possible to port new models and improve the existing ports. On release 1.3, for example, code_gen was the key tool to add more than 60s exposure on all cameras.

In which OS do these tools run?

waterwingz: CHDK is built using the gcc compiler so I guess the tools run on anything that supports that compiler - Windows and Linux for sure.

I do all my work under Linux although I have a laptop somewhere that runs the Windows tools.

The autobuild server that rebuilds CHDK after each update and provides current downloads runs under Linux.

And there are quite a few other tools that people have created, some of which are Windows only (or using Wine under Linux) and some of which are Java based and will run on Windows, Linux, or MacOS.

philmoz: I use MacOS for CHDK development.

I also have a Linux VM I use for testing batch builds of the entire set of supported cameras, to make sure big changes don’t break the autobuild server.

reyalp: I use Windows on my primary development system, but all the core CHDK tools and build process have supported Linux for as long as I’ve been involved.

My normal CHDK development environment is MSYS shells and gvim.

I also use Linux in VMs and a Raspberry Pi for some things.

Is there any camera emulator that allows to test core code before loading it into the camera?

waterwingz: There are a couple of clever GUI emulators for testing CHDK uBASIC and Lua scripts.

But I don’t believe anyone has really succeeded in making a QEMU emulator for core code development.

All testing is done on actual cameras.

And to date, I don’t believe anyone in the dev community has bricked a camera which says something about the stability of the process!

philmoz: Magic Lantern uses QEMU to run their code in an emulator.

In theory CHDK could do this as well, but to date no-one has invested the time to create the hardware simulation bits needed.

Debugging CHDK is old school - blinking LED’s, printing messages (if you have the display working), writing log files, and lots of trial and error.

reyalp: Not emulation, but I use chdkptp a lot for interactive testing. Being able to dump bits of memory or call functions interactively from a PC console is very useful.

What’s the easiest way for someone to get involved with CHDK?

waterwingz: Download it and use it on a PowerShot.

Learn what it does and how to run scripts.

Then write some scripts on your own, or modify some existing ones.

Finally, do a port for an unsupported camera - pretty much every CHDK dev started off porting and then got hooked on doing more.

blackhole: The easiest way is to use CHDK for something creative. It’s nice to see when users show results that are the product of using CHDK. I think it’s the biggest reward for developers when they see that their work is well-used.

reyalp: The forum is the best place to get involved with the community.

To get involved with development, it really depends on your interests. If there’s something you want to add, either dive into the code or ask for suggestions on where to start.

Ports of additional cameras are always welcome too, and doing one provides a good overview of how CHDK works.

What are some tasks non-programmers can do to help the project?

waterwingz: There has been a lot of work on the CHDK wiki over the years, but there is still a ton to do.

For example, one CHDK user finds time each month to simply correct spelling and the worst of the grammar mistakes on the more popular pages and the CHDK User Manual.

reyalp: If you do something interesting with CHDK, share it in the forum. A lot of interesting projects start as riffs on something someone else explored years earlier.

Documentation always needs help, but for CHDK, a lot of it really requires careful experimentation or knowledge of the source to do well.

nafraf: If you are a CHDK user and find a bug, or a missing function on the port of your camera, please report the bug to the forum and help to test new versions.

Developers don’t have access to all models, then testing and receiving feedback from the users are necessary to help the project.

How healthy is the production of user scripts? Is it easy for a non-programmer to write a script? In what languages?

waterwingz: The huge improvements in mobile phone cameras have really impacted the market for all but the highest end or largest zoom P&S cameras.

Having said that, a core of serious photographers still work on what interests them and depend on CHDK to help capture their artistic vision.

As far as non programmers and script writing, uBASIC is about as simple as a computer language gets and there are lots of example scripts to study.

Lua provides a much richer programming environment, albeit with a bit of a learning curve.

reyalp: Easy… depends on the user.

Because CHDK is a reverse engineered hack on top of an undocumented system, many behaviors are not well specified or understood.

waterwingz improved things a lot by creating a comprehensive reference of CHDK script functions, but developing non-trivial scripts still requires significant effort and a willingness to experiment.

I’ve been using CHDK for 10+ years, and still find myself greping the CHDK source and making test cases to figure out what functions actually do.

All that said, I don’t think learning to write modest CHDK scripts is particularly harder than starting out with javascript or batch files or that sort of thing.

We should note CHDK uBASIC is based on Adam Dunkels code, not the UBASIC written by Yuji Kida for mathematical computing.

How many developers work on CHDK? How does it work?

waterwingz: There have been hundreds of contributors to CHDK over the years.

Currently there is an active core of two or three people doing original work with low level firmware stuff, a couple of people working more on the user experience, several people generating custom scripts for unique photographic opportunities, and a core of maybe ten CHDK experts not doing much coding these days but continuing to provide support to the community.

What uses are people making of CHDK? Is there any that should be highlighted?

waterwingz: There is a nice list on the main page of the CHDK Wiki - unique things like motion triggering, scripting, RAW/DNG, bracketing, and full manual exposure control.

Originally, there was a lot of interest in just getting RAW files from an inexpensive P&S camera.

More recently the focus has been on making good multi-camera rigs with full centralized control using CHDK’s PTP capability. Everything from book scanners, “bullet time” rigs, to full 3D capture for building small replicas of people. And of course the ongoing interest in time lapse videos and kite and drone photography work.

reyalp: I get a kick out of how many different things show up searching google scholar for “CHDK hack”

Currently, what is the main development effort underway? New functionality? Porting CHDK to new camera models?

waterwingz: A lot of the current development is focused on very detailed features that interest the core developers. Not really anything that will revolutionize the CHDK user experience right away unfortunately.

But there are also potentially some interesting new things in the wings if the devs working on them can ever get them finished.

reyalp: There aren’t really any major features undergoing significant development right now.

There are some ideas and experimental stuff being kicked around, like the GUI concept and some work on capturing raw outside the normal shooting process, but what eventually gets added depends on developers time and interest.

I’m trying to wrap up a few things to release CHDK 1.5 before we start major projects in the official development branch.

So there’s a new CHDK GUI underway, and it seems very interesting and more user oriented. Once finished, how will it be released to the many different camera models that already run CHDK?

waterwingz: Oh oh - you noticed that? Did you also see the comment about the dev working on it not being too good at it getting finished? ;)

For what it’s worth, there has been quite a bit of thought about keeping it generic enough so that will run on all CHDK capable cameras. That’s mostly about screen resolution issues but there will probably be other challenges. Touchscreen cameras like the PowerShot N come to mind.

What is the future of CHDK, considering the evolution of technology? How long do you think point-and-shoot cameras will stay on the market, given the rise of smartphones? Do you think the latter will replace the former?

waterwingz: As I mentioned earlier, smart phone cameras continue to improve and that has impacted the low end PowerShots that CHDK does so much for.

CHDK will continue as an interesting project as long as a people enjoy using it and creating new things with it.

blackhole: The P&S cameras with the large zoom will likely survive the competition of smartphones. Smartphones in this area will not be competitive with cameras for a long time. CHDK is likely to have a future in this area.

philmoz: I think there will also be demand for the higher end P&S cameras with larger sensors, although I don’t think the market will be huge.

The number of people with these cameras interested in CHDK is probably going to be pretty small.

Canon’s EOS-M mirrorless cameras can also run CHDK so there is some interest there.

reyalp: Low end, mass market P&S are clearly on the way out. I agree with blackhole and philmoz that higher end stuff will be around for a while to come, but the possibility of running CHDK on future cameras is always uncertain.

As I mentioned earlier, Canon DSLRs and P&S cameras have been based on different codebases, which are different enough that it doesn’t make sense to run the same hack on both.

CHDK supports the EOS M3 and M10 because they are built on the P&S codebase, while Magic Lantern does not support them.

There are signs Canon is moving to a unified codebase (likely motivated by the same market changes) in Digic 8 cameras, which may preclude CHDK as we currently know it.

However, with millions of CHDK capable P&S in circulation, there will still be potential uses for a long time to come.

Separate from smartphones, the rise of things like Rasbperry Pi, dedicated UAV and action cameras etc. have reduced cases where a hacked P&S is a clear win over other options.

In 2008, if you wanted a programmable, multi-megapixel camera with decent optics your choices were very limited and mostly expensive.

In 2019, you have a lot of options other than CHDK, but at the same time, a lot of these things can work well with CHDK too.

I think the collapse of P&S has also affected the pool of potential CHDK contributors: in 2008, a developer with a casual interest in photography would have a P&S, while today they would be more likely to have a smartphone. Someone who wants to tinker with camera software also has a lot more choices.

Could CHDK benefit from the current boom in single board computers and single board microcontrollers, like Arduino, Raspberry Pi, Esp32, Beaglebone, etc? Could those boards add even more functionality to CHDK? How?

waterwingz: Actually, there are quite a few successful projects out there using those little computers to control one or more Canon PowerShots running CHDK.

Basically anything that will support the necessary USB functionality to implement the PTP protocol and the CHDK extensions to the protocol. Applications like bookscanners, remote timelapse capture, photobooths, and multiple camera 3D image scanning.

Here is an example of Arduino and CHDK usage, with a nice PTP GUI.

reyalp: The webcams on this site are based Raspberry Pi’s using chdkptp to control CHDK cameras (chdkptp is a tool which I maintain that allows controlling CHDK cameras over USB from Linux and Windows).

One of the firsts tests with a full rig (72 cameras) shooting at same time. By nafraf, licensed under CC BY-NC 2.0.

A simple test to show the detail of a segment of the rig, how the cameras were mounted and their response after sending the turn off command using chdkptp. By nafraf, licensed under CC BY-NC 2.0.

Do you developers have time to play with CHDK? What are your preferred use?

waterwingz: There are a ton of features in CHDK and I’ve had fun playing with most of them. But for me, it’s mostly about Lua scripting when I’m actually using CHDK.

blackhole: Unfortunately my real life does not allow me to play with CHDK as much as I want.

My favorite use is when popularizing astronomy among children. It is a priceless experience when you see the glow in their eyes when they see the image of the planet they have taken themselves. For me, this is the highest value of CHDK.

reyalp: I use CHDK raw for general shooting, and scripts to do timelapse.

I’ve used motion detection for lightning and fireworks.

I also do some lo-fi astrophotography using CHDK scripts to take lots of exposures to guide and stack in software.

But what I do most is take test shots of my desk while working on the code ;)

When did you joined CHDK as a developer? Why? What is your background? What is your role?

waterwingz: July 2010 according to the records on the CHDK forum. But it seems like it was only nine years ago.

I got started because it combined two of my hobbies - computers and cameras.

Since then I’ve ported several cameras, contributed some original code, helped fix some bugs, coded many scripts, written a lot of documentation on the wiki, and helped a few newbies on the CHDK forum.

philmoz: I started with the G12 port in November 2010.

I’ve been a software developer for nearly 40 years and like waterwingz, photography is a hobby. CHDK looked like fun and I wanted something to keep me programming - my day job was more management than development.

I was pretty active until 2016, when real-life got in the way.

I now do mobile app development full time, so don’t spend much time on CHDK coding these days.

blackhole: I joined in August 2010.

Prior to that I was just reading the forum as a guest and using CHDK on the old A530 and A590 cameras. At that time I was looking for a better solution for cheap-modified webcams, which were then popular in amateur astronomy. The logical solution was to switch to something cheap with a CCD sensor, so the decision fell on Canon cameras and CHDK.

I became interested in the programming, so I started to collect knowledge on the forum and in the end I made my first port.

reyalp: Around 2008, I happened to get a Canon A540 and google “firmware hack” or something like that just for kicks. I had a background in C and assembly, and a somewhat neglected interest in photography going back to film days, so it seemed like a fun thing to play with.

For me, CHDK development was a nice change of pace, a throwback to the early PC days where if you want to draw something, you write directly to video memory instead of going through a bunch of APIs.

As people came and went from the project I somehow ended up being the chief cat herder.

nafraf: I started in June 2012. My first port was A810. I was using CHDK for a multi camera project and it was difficult to find ports of recent cameras.

With CHDK, the exposure time and ISO values can change in 1/96 EV steps. The first part of this video was made using a standard timer with exposure changes of 1/3 EV steps. The second part was made using script isoinc.lua, no post-processing. By c_joerg, licensed under CC BY-NC 2.0.

Is there anything that you would like to add?

waterwingz: Getting involved in CHDK is a bit of a trap. Once you get in, your free time just disappears. But it can be a lot of fun!

philmoz: The people who have worked on CHDK over the years are an amazingly talented, fun, and helpful group. I have learned a lot from this project and really appreciate the willingness to help, and assistance I’ve received.

reyalp: I’d like to thank all the people who have contributed over the years, and Canon for turning a blind eye to it for so long.

blackhole: CHDK is a very fun and creative project. I invite all photographers and programmers to join us and express their creativity through this project and share their experiences with us. In the end, I would like to thank the entire CHDK community for a pleasant companionship for the last ten years.

nafraf: Thanks to all people involved with this project. I have learned a lot during these years.

This video was created by changing the zoom levels between 24mm and 1200mm (35mm). For each zoom level, 2 images were taken at a time. The camera was a Canon SX50 with 200 zoom levels and CHDK. A special script was used. By c_joerg, licensed under CC BY-NC 2.0.

Thank You CHDK devs!

I want to thank CHDK devs again for taking the time and being patient enough to chat with us, as well as sharing images of their CHDK use!

I also want to thank CHDK users Garry George, Peter Laudanski, Andrew Hazelden, c_joerg, and keoeeit for having kindly shared some images and answered questions about how they shoot them!

Finally, I want to thank Pixls members paperdigits and afre for their invaluable support, without which this interview wouldn’t have been possible.

The CHDK community gathers around https://chdk.setepontos.com/ and all official CHDK documentation can be found on http://chdk.wikia.com/wiki/CHDK.

Libre Graphics Meeting 2019

Let's participate!

It’s that time of year again: Libre Graphics Meeting 2019 is fast approaching!

This year the meeting will be May 29 to June 2 in Saarbrücken, Germany. This is extra exciting because Saarbrücken is centrally located enough that we should have a nice representation from projects and community members. Members of both RawTherapee and darktable live nearby and will be in attendance (along with others from those projects and many others).

Participate!

I’m hoping to have a good representation this year, so first and foremost - please, please consider participating by giving a presentation, leading a workshop, or even a quick lightning talk! The Call for Participation page is here:

https://libregraphicsmeeting.org/2019/call-for-participation/

I will make myself available to help in any way I can. If you want a hand with the presentation, design, graphics or whatever please feel free to ping me (also - remember that we try to archive all of our presentations and material in our Github repo so you can grab any of the assets from there as well)! This is a great opportunity to spread the word about what we’re up to and the many, many awesome projects everyone has created, maintained, and contributed to for Free Software photography.

The deadline for submittal is coming up on January 15^th!
If you think you’d like to present or host a workshop please submit as soon as possible.

Cheers!

I am particularly excited about this meeting because a) I don’t get to attend every year so this is the first time I’m able to make it in a few years, and b) this is a great opportunity to really get a bunch of community members to come together! Saarbrücken is on the high-speed rail network so it’s readily accessible from many places (now you have less excuses to not make it).

I love hanging out with y’all. It’s great to nerd out about photography and catch up. Sometimes it really helps to be able to speak face-to-face and this is the perfect opportunity to also be exposed to all manner of other Free Software projects (or to expose ourselves to others?).

Besides, how else am I going to capture some fun photos of y’all?

What’s Going On

We have a few things planned for sure at the meeting and you’re going to be really sad if you miss them by not coming!

1. PIXLS.US BoF (Birds of a Feather)
   This is a special session set aside for a couple of hours for the entire community to get together and chat about what’s going on, what we’d like to do, and what’s coming up.
2. Photowalk
   I’ve been doing photowalks every year that I’ve been because this is almost the ultimate way for me to spend time with folks (unless we can do a beer drinking photowalk all at the same time…).
3. PIXLS.US Presentation/Update
   I’ll (We’ll? Anyone from the community is more than welcome to help me present on this) present on the community and what we’ve done so far and what we’d like to accomplish moving forward. This is our primary way of reporting out to the wider community who we are and what we’re doing.
4. State of the LGM
   This is a couple of slides that are included at the beginning of the program giving an overview of the state of the entire libre graphics ecosystem.

I really, really, really want to be able to add to this list with other presentations (or lightning talks, etc) that the community will give! I may even submit a couple of presentations to talk not just about the community but maybe about our technical work coordinating the forum and providing services for the projects (as well as invite other related projects to come join us).

We can make this an incredible and memorable meeting with a fantastic opportunity to meet friends in person and have a wonderful time!

Goodbye Google Analytics

A little less tracking for the new year

Over on my personal website I decided to stop using third party trackers and assets to keep from exposing visitors to unintended tracking. Third party assets expose a user to being tracked and analyzed by those third (or fourth, or more) parties and honestly this is something the web could use a little (lot) less of. I loved having stats early on when we started this crazy idea for a community and as I mentioned on my blog post, it’s a Faustian bargain to get stats at the expense of allowing Google to track what all the users of the site are doing. No thanks.

I figure it’s the eve of a new year so why not start it out right and reduce the tracking footprint of the site?

This all started by noticing that some new browser feature strips referer information from requests (thanks @darix) and we were using them to target specific areas of websites that we manage comments for. It came to my attention when I was reading the release announcement for digiKam 6.0.0 beta 3.

While fixing that problem, I found that once we fixed the referer requirement problem I was still seeing issues with Privacy Badger blocking our embed code. On further inspection it boiled down to using Google Analytics on our base domain (pixls.us) and having a cookie set by Google, which then got sent with embed requests from other websites (digiKam and darktable). This triggered the heuristic blocking by Privacy Badger.

Honestly, we derive very little value from the analytics for the price (privacy) we pay to use it. Better to simply remove it.

We still do analytics but we own the stack ourselves (thank you so much andabata!). If you want to block our own analytics the domain is: piwik.pixls.us.

2018 PlayRaw Calendar

Chris creates a new calendar for the community

Last year I got an amazing surprise in the mail. It was an awesome calendar of a handpicked selection of results from the years PlayRaw images.

Chris (@chris) put together another fantastic calendar for this year (while juggling kids, too) and it’s too nice to not have a post about it!

It was a really awesome surprise to recieve my calendar last year - and I wish I would have planned a little better to be able to grab a photo of the calendar hanging in my office (it’s my work desk calendar - it never fails to remind me that there’s more fun things to life than work - also that I need to up my processing game… ).

This year Chris has done it again by assembling a wonderfully curated collection of images and edits from the various Play Raws that were posted this year. I’ve plagiarized his post on the forums to put together this post and get some more publicity for his time and effort!

If you get a moment, please thank Chris for his work putting this together!

You can download the PDF: 2018 Play Raw Calendar

Here are the images he chose for the calendar and the edits he included:

A preview (also shamelessly lifted from Chris’s forum post):

These Play Raws are a ton of fun and one of the great aspects of having such a generous community to share the images and allowing everyone to practice and play. I am constantly humbled by the amazing work our community produces and shares with everyone.

Thank you to everyone who shared image and participated in processing (and sharing how you achieved your results)! I have really learned some neat things based on others work and look forward to even more opportunities to play (pun intended).

Fun side note: the Play Raws are actually something that began on the old RawTherapee forums. When they moved their official forums here with us it was one of those awesome things I’m glad they brought over with them (the people were pretty great too… :)).

Giving More Thanks

For an awesome community

It is a yearly tradition for us to post something giving thanks around this holiday. I think it’s because this community has become such a large part of our lives. Also, I think it helps to remind ourselves once in a while of the good things that happen to us. So in that spirit…

Financial Supporters

We are lucky enough (for now) to not have huge costs, but they are costs none-the-less. We have been very fortunate that so many of you have stepped up to help pay those costs.

The Goliath of Givers

For the last several years, Dimitrios Psychogios has graciously covered our server expenses (and then some). On behalf of the community, thank you so much! You keep the servers up and running. Your generosity will cover infrastructure costs for the year and give us room to grow as the community does.

We also have some awesome folks who support us through monthly donations (which are nice because we can plan better if we need to). Together they cover the costs of data storage + transfer in/out of Amazon AWS S3 storage (basically the storage and transfer of all of the attachments and files in the forums). So thank you, you cool friends, you make the cogs turn:

• Jonas Wagner
• elGordo
• Chris
• Christian
• Claes
• Thias
• Stephan Vidi
• ukbanko
• Bill Z
• Damon Hudac
• Luka Stojanovic (a multi-year contributor!)
• Moises Mata
• WoodShop Artisans
• Barrie Minney (He’s a long time monthly contributor!)
• Mica

It is so amazing not to have to worry about finding the capital to support our growing community; we just expand things as necessary. It is super great.

If you’d like to join them in supporting the site financially, check out the support page.

Growth

As of today, we have 3135 users, so we’ve continued to grow at a very good rate! Welcome to all the new users.

As you can see from our discuss stats, we’re approaching 500k page views per month:

And our yearly community health is very positive:

gPhoto

This year we added the gphoto project to our list of supported applications! gPhoto is an awesome library for interfacing with your camera. It is used by darktable and entangle to allow you to shoot with your camera attached to your laptop or other device. We’re thrilled that they’ve joined us on the forums!

Natron

Natron is a compositing application mostly used in 3D/video compositing. The main developer was looking to give the project more of a community focus, so of course we were happy to provide them their own spot in the forum for their users to communicate and collaborate.

darix

For another year, @darix continues to keep our stuff up and running! Do you ever notice outages? No?! Me either, and that is due to his daily diligence. We can’t thank him enough for his dedication to our community.

patdavid or Pat David

The originator of it all, thank you for the initial push to create this community where we are not divided by which application we use. And for your continued good will towards everyone here, your welcoming spirit, and passion. We’d never have done it without you! And for all the great things to come!

All of You

The community is the sum of parts + all the extra love that comes from all of you! Thank you so much continuing to stick around, share you knowledge, and spread the great community. It keeps me motivated, creative, and challenged and for that I am very thankful.

Create lens calibration data for lensfun

Adding support for your lens

[Article updated on: 2019-12-09]

Introduction

All photographic lenses have several types of errors. Three of them can be corrected by software almost losslessly: distortion, transverse chromatic aberration (TCA), and vignetting. The Lensfun library provides code to do these corrections. Lensfun is not used by the photographer directly. Instead, it is used by a photo raw development software such as darktable or RawTherapee. For example, if you import a RAW into darktable, darktable detects the lens model, focal length, aperture and focal distance used for the picture, and it then calls Lensfun to automatically correct the photograph.

Lensfun uses a database to know all the parameters needed to do the lens corrections. This database is filled by photographers like you, who took time to calibrate their lenses and to submit their findings back to the Lensfun project. If you’re lucky, your lens models are already included. If not, please use this tutorial to do the calibration and contribute your results.

Let us assume your lens isn’t covered by Lensfun yet, or the corrections are either not good enough or incomplete. The following sections will explain how to take pictures for calibration. It will also show you how to create an entry of your own. The best is to provide information for all three errors but maybe you only need distortion then this is fine too.

Checking if your lens is already supported

Before you start to calibrate new lenses or report missing cameras please check the lens database first! The list is updated daily. If your lens is already support then everything is fine and you just have to update your database.

If the lens is not supported or doesn’t provide all corrections you could add the missing data following this tutorial.

Taking pictures

Before we start you need to take a lot of images for the three errors we are able to correct. This section will explain how to take them and what you need to pay attention to.

For all pictures you should use a tripod, turn off all image correction and disable image stabilization in the camera and in the lens itself! Also make sure to that all High Dynamic Range (HDR) or Dynamic Range Optimizer (DRO) features are turned off. All those options could mess up your calibration.

Distortion

For distortion you can to take pictures of a building with several parallel straight lines. You need at least two lines, one should be at the top of the image (Nearly touching the top of frame) and the other line at about a third down from the first line. The following example demonstrates this.

The lines must be perfectly straight and aligned. You can twist and rotate the camera, but the lines must have no imperfections. Common mistakes are using tiles or bricks: to your eye they may be “straight”, but it will cause calibration defects. The best buildings turn out to be parking houses (US: parking lot, EN: garages, car parks) or modern glass buildings like fruit-technology stores.

For a fixed focal length lens, you only will require one image. For a zoom lens it is recommended to take 5 to N pictures where N is max focal length minus min focal length. You must take an image at the minimum focal length, and the maximum focal length. You can move (step backward on forward) between shots to keep the 1/3rd rule above consistent.

You should shoot at your lenses sharpest aperture - this is often f/8 to f/11. Setup your camera on a tripod. Shoot at the lowest ISO (without extended values). This will be 100 or 200. Disable any inbody lens corrections. Every vendor has a different name for this process (Fuji is modular lens optimization for example). Check your camera manual and menus.

Chromatic aberrations (TCA)

For TCA images look for a large object with sharp high-contrast edges throughout the image. Preferably, the edges should be black–white but anything close to that is sufficient. Make sure that you have hard edges from the center throughout to one of the edges. The best buildings, for taking photos, have dark windows with white or gray frames.

Here are some example pictures:

You should take your pictures being at least 8 meters away. For zoom lenses, take pictures at the same focal lengths as for distortion (5 to N). Make sure to capture really sharp photos using at least f/8. The best is to use aperture control, f/8 and ISO 100 on a tripod to avoid any color noise.

You can use e.g. a streetview service to find the right building in your town (big buildings, dark windows with white or grey frames).

Vignetting

To create pictures for vignetting you need a diffuser in front of the lens. This may be translucent milk glass, or white plastic foil on glass. Whatever, as long as it is opaque enough so that nothing can be seen through it, yet transparent enough so that light can pass through it. It must not be thicker than 3 mm and shouldn’t have a noticeable texture. It must be perfectly flush with the lens front, and it mustn’t be bent. It must be illuminated homogeneously.

I ordered a piece of acryl glass, opal white (milky), smoothly polished, 78% translucency, 3mm thick, 20 x 20 cm, which is about 8 Euro on Amazon.

However white plastic foil taped on a piece of ordinary glass for stability might be enough, if the plastic doesn’t have any texture.

I normally wait for a cloudy day with no sun, then the sky is homogeneously lit. Put the camera on a tripod and point it to the sky. Put the glass directly on the lens (remove any filters). In some places where sunlight is different you may need to shoot indoors. You should experiment to make sure your images are evenly lit (except for vignetting obviously).

Make sure that no corrections are applied by the camera (some models do this even for RAWs). Set the camera to aperture priority and the lowest real ISO (this is normally 100 or 200, don’t use extended ISO values).

Switch to manual focus and focus to infinity. This is the most critical step!

For zoom lenses, you need to take pictures at five different focal lengths. You only need pictures for five focal lengths because for the other steps it gets interpolated. For a prime lens you need to take only pictures for the single focal length.

Take the pictures as RAW at the fastest aperture (e.g. f/2.8) and at three more closed apertures at 1 EV distance, and also at the most closed aperture (e.g. f/22.0). These are often marked on your lens’ aperture ring, or on your electronic display.

If you have for example a 16-35mm lens with aperture f/2.8 - f/22, you need to take pictures at 16mm, 20mm, 24mm, 28mm and 35mm focal length (Remember you require the min and max zoom values). For each for those focal lengths you need to take five pictures at f/2.8, f/4.0, f/5.6, f/8.0 and f/22.0. This makes 25 pictures in total.

For a 50mm prime lens with f/1.4 - f/16 you need to take 5 pictures at f1.4, f/2.0, f/2.8, f/4.0, and f/16.0.

**Exposing the picture correctly

For taking the picture the middle of the area needs to be as bright as possible, but not overexposed. This can be easily +1.7 to +2.0 EV.

If your camera has a zebra setting, turn it on and set the zebra mode to ‘100’. If you start to see the zebra, then take the picure. The profile is created on a RAW file and the zebra is shown for a developed picture. So we aren’t overexposed yet. In the control mode in my camera which shows overexposure everything was fine.

Vignetting correction for the professionals

The following steps are to get really fine grained vignetting corrections. The gain in accuracy is really very small! I probably only makes sense for prime lenses used for portrait or macro photography. However this is not required, the above it absolutely enough.

Lensfun is able to correct vignetting depending on focal distance. Thus, you can achieve a bit more accuracy by shooting at different focal distances. This means you will have to take pictures at 4 different focal distances.

The first focus on the near point (The near point is the closest distance that can be brought in focus). The next focal distances are the near point multiplied by 2 and by 6 and finally focus at infinity.

Example: For a 85mm prime lens with the near point at 0.8 m. You have to take pictures at 0.8 m, 1.6 m, 4.8 m and infinity.

Create calibration data

There are two ways to perform the calibration.

Lensfun allows an upload of data to the project, and they’ll do the program work for you. They’ll also review your images to make sure they are correctly taken.

Or you can do it yourself with the lens calibration script from the lensfun project.

The script needs the following dependencies to be installed on your system:

• python3
• python3-exiv2 (py3exiv2 >= 0.2.1)
• python3-numpy
• python3-scipy
• darktable-cli (darktable >= 2.4.0)
• tca_correct (hugin >= 2018)
• convert (ImageMagick)

You can download the lens calibration script HERE or get it as a package for the major distributions HERE.

Once you have downloaded the tool create a folder for your lens calibration data, change to the directory and run:

$ lens_calibrate.py init
The following directory structure has been created in the local directory

1. distortion - Put RAW file created for distortion in here
2. tca        - Put chromatic abbreviation RAW files in here
3. vignetting - Put RAW files to calculate vignetting in here

Follow the instructions and copy your raw files in the corresponding directories.

Vignetting correction for the professionals

For each focal distance you captures pictures you have to create a folder.

Lets pick up the example from above. For a 85mm prime lens we took pictures at 0.8 m, 1.6 m, 4.8 m and infinity. For this lens you would have to create the following folder structure in the vignetting directory:

vignetting/0.8
vignetting/1.6
vignetting/4.8
vignetting/inf

The folder inf is for the focal distance at infinity.

Distortion

Once you copied the files in place it is time to generate the pictures (tif files) for distortion calculations. You can do this with the ‘distortion’ option:

$ lens_calibrate.py distortion
Running distortion corrections ...
Converting distortion/_7M32376.ARW to distortion/exported/_7M32376.tif ... DONE
A template has been created for distortion corrections as lenses.conf.

Once the tif files has been created, you can start Hugin.

Torsten Bronger created a screen cast to give an overview about the distortion process in Hugin. He uses an old Hugin version in the video. The following section of this tutorial explains how to do it with Hugin 2018. You can watch the screen cast first if you want, you can do it here (Vimeo).

If you start Hugin the first time, the windows you will get should look like in Figure 8.

First select on the menu bar Interface -> Expert to switch to the Expert mode. You will get a windows which should look like as in Figure 9.

Once in the export mode click on Add images (Figure 10) and load the first tiff from the distortion/exported folder.

By default the lens type should be set to Normal (rectiliniar) for normal standard lenses. Make sure that the focal length is correct and set the Focal length multiplier, which is the crop factor of your camera. For full frame bodies this value should be 1. If you have a crop camera you need to set the correct crop value you can find in the specifications. Next click on the Control Points tab (Figure 11).

This is the tab to set the control points so that we can tell the software what are our straight lines we are interested in. In this tab you have to make sure that auto fine-tune is disabled, auto add is enabled and auto-estimate is disabled! If this is the case zoom the image to 200% (you can also do this by pressing ‘2’ on the keyboard).

In the zoomed images you have start at the top edges. On the left go to the top left corner and to the top right corner on the right. The first straight line, from left to right, should be visible. Select the first control point on the left edge of the picture on the left page and the right edge on the right (Figure 12).

IMPORTANT: Once you have the first control point selected in both images. Select Add new Line in the mode dropdown menu! This will add the two control points as line 3! Now continue adding corresponding control points in both pictures till you’re in the middle on both sides.

Tip: The easiest and fasted is to set control points in the middle at the tiling line. This reduces the required mouse movements.

Now zoom out by pressing ‘0’ and check it if everything has been added correctly (Figure 13).

While you are zoomed out, find a line which is about 3rd into the image from the top to repeat adding a line. Zoom to 200% again, select the first control points and again Add a new line which will result in line4 (Figure 14)!

Zoom out by pressing ‘0’ and check that you have two lines, line3 and line4. Now move on to the Stitcher tab (Figure 14).

In the Stitcher tab you need to select the correct Projection for your lens. This is Rectilinear for standard lenses. Once done switch to the Photos tab (Figure 16).

At the bottom under Optimize select Custom parameters for Geometric. This will add an Optimizer tab. Switch to it once it appears (Figure 17).

Select the ‘a’, ‘b’ and ‘c’ lens parameters and click on Optimize now!. Accept the calculation with yes. Now the values for ‘a’, ‘b’ and ‘c’ will change (Figure 18).

The calculated correction values for ‘a’, ‘b’ and ‘c’ you can find in the tab need to be added to the lenses.conf. Open The file and fill out the missing options. Here is an example:

Example:

[FE 85mm F1.4 GM]
maker = Sony
mount = Sony E
cropfactor = 1.0
aspect_ratio = 3:2
type = normal

• maker is should be the lens manufacturer e.g. Sony
• mount is the mount system for the lens, check the lensfun database
• cropfactor is 1.0 for full frame cameras, if you have a crop camera find out the correct crop factor for it.
• aspect_ratio is the aspect ratio for the pictures which is normally 3:2.
• type is the type of the lens, e.g. ‘normal’ for standard rectilinear lenses. Other values are: stereographic, equisolid, stereographic, panoramic or fisheye.

If you have e.g. a 85mm there should be an entry for the focal length which is set to: 0.0, 0.0, 0.0. You need to change the values in the lenses.conf for your focal length with the calculated corrections from the Optimizer tab (Figure 16).

[FE 85mm F1.4 GM]
maker = Sony
mount = Sony E
cropfactor = 1.0
aspect_ratio = 3:2
type = normal
distortion(85mm) = 0.002, 0.001, -0.009

But I don’t want to do distortion corrections!

No problem, if you want to skip this step then you can created the lenses.conf manually. It should look like the following example:

[lens model]
maker =
mount =
cropfactor = 1.0
aspect_ratio = 3:2
type = normal

The section name is the lens model. You can find it out by running:

exiv2 -g LensModel -pt <raw image file>

The other options are:

• maker is should be the lens manufacturer e.g. Sony
• mount is the mount system for the lens, check the lensfun database
• cropfactor is 1.0 for full frame cameras, if you have a crop camera find out the correct crop factor for it.
• aspect_ratio is the aspect ratio for the pictures which is normally 3:2.
• type is the type of the lens, e.g. ‘normal’ for standard rectilinear lenses. Other values are: stereographic, equisolid, stereographic, panoramic or fisheye.

TCA

You can skip this step if you don’t want to do TCA corrections.

This step is fully automatic, all you have to do is to run the following command and wait:

$ lens_calibrate tca
Running TCA corrections for tca/exported/_7M32375.ppm ... DONE

However it possible to calculate more complex TCA corrections. For this you need to run the step it with an additional command line argument, like this:

$ lens_calibrate --complex-tca tca
Running TCA corrections for tca/exported/_7M32375.ppm ... DONE

Vignetting

You can skip this step if you don’t want to do vignetting corrections.

To calculate the vignetting corrections it is also a very simple step. All you have to do is to run the following command and wait:

$ lens_calibrate vignetting

Generating the XML

To get corrections for lensfun you need a lenses.conf with the required options to be filled out (maker, mount, cropfactor, aspect_ratio, type). And at least one of the corrections steps done. If you have this you can generate the XML file which can be consumed by lensfun. You can do it with the following command:

$ lens_calibrate generate_xml
Generating lensfun.xml

You can redo this step as many times as you want. And you can just rerun it if you add an additional correction.

Using the lensfun.xml

You may want to fine-tune the lens model name in the generated lensfun.xml file. Lensfun normalises names before any matching, so you have some freedom. For example, upper/lowercase can be changed arbitrarily. Any single f is ignored, so you may change 16-35mm 2.8 into 16-35mm f/2.8. If there was a tele converter involved, you must add “converter” into the name so that Lensfun does not try to derive allowed focal lengths from the lens name. Ordering of parts in the lens name is completely unimportant for matching. As are single punctuation characters. You may even add things (e.g. 16-35 into 16-35mm) but be conservative here. Never drop anything what exiv2 reports!

If you want to use the generated lensfun.xml file to test if the calibration you created works, you can copy to the local lensfun config folder in your home directory.

cp lensfun.xml ~/.local/share/lensfun

Make sure your camera is recognized by lensfun or you need to add an entry to the lensfun.xml file too.

Contributing your lensfun.xml

To contribute your calibration data data for your lens to the lensfun project, execute the script with the following command:

$ lens_calibrate ship
Created lensfun_calibration.tar.xz
Open a bug at https://github.com/lensfun/lensfun/issues/ with the data.

This will create a tarball with all the required data. Now go to

• https://github.com/lensfun/lensfun/issues/

and open a bug using the following subject:

Calibration data for <lens model>

And for the description just use:

Please add the attached lens data to the lensfun data base.

Attach the lensfun_calibration.tar.xz to the bugreport.

Feedback

Feedback for this article is very welcome. If you’re a lensfun developer and read this please contact me. I would like to contribute the script to lensfun and further improve the article. I still have unanswered questions.

Support Andrea Ferrero on Patreon!

Andrea is developing Photo Flow, GIMP AppImage, Hugin AppImage, and more!

Andrea Ferrero, or as we know him Carmelo_DrRaw, has been contributing to the PIXLS.US community since April of 2015. A self described developer and photography enthusiast, Andrea is the developer of the PhotoFlow image editor, and is producing AppImages for:

• The GIMP image manipulation program - weekly AppImage packages from stable releases and development branches.
• The RawTherapee editor - nightly AppImage and Windows packages from stable and development branches
• LuminanceHDR - nightly AppImage packages for Linux
• HDRMerge - nightly AppImage packages for Linux
• The Hugin panorama photo stitcher - AppImages for stable releases and development branches

Andrea is the best sort of community member, contributing six different projects (including his own)! He is always thoughtful in his responses, does his own support for PhotoFlow, and is kind and giving. He has finally started a Patreon page to support his all of his hard work. Support him now!

He was also kind enough to answer a few questions for us:

PX: When did you get into photography? What’s your favorite subject matter?

AF: I think I was about 15 when I got my first reflex, and I was immediately fascinated by macro-photography. This is still what I like to do the most, together with taking pictures of my kids. ;-) By the way, you can visit my personal free web gallery on GitHub: http://aferrero2707.github.io/photorama/gallery/ (adapted from this project).

It is still a work in progress, but you are welcome to fork it and adapt it to your needs if you find it useful!

PX: What brought you to using and developing Free/Open Source Software?

AF: I started to get interested in programming when I was at the university, in the late 90’s. At that time I quickly realized that the easiest way to write and compile my code was to throw Linux into my hard drive. Things were not as easy as today but I eventually managed to get it running, and the adventure began.

A bit later I started a scientific career (nothing related to image processing or photography, so I won’t bother with more details about my daily job), and since then I have been a user of Linux-based computing clusters for almost 20 years at the time of writing… A large majority of the software tools I use at work are free and open sourced and this definitely has marked my way of thinking and developing.

PX: What are some new/exciting features you develop in Photo Flow?

AF: Currently I am mostly focusing on HDR processing and high-quality Dynamic Range compression - what is also commonly called shadows/highlights compression.

More generally, there is still a lot of work to do on the performances side. The software is already usable and quite stable, but some of the image filters are still a bit too slow for real-time feedback, especially when combined together.

The image exporting module is also currently in a state of work in progress. It is already possible to select either Jpeg or TIFF (8, 16 or floating-point 32 bits bit depth) as the output format, to resize the image and add some post-resize sharpening, and to select the output ICC profile. What is still missing is a real-time preview of the final result, with a possibility to soft-proof the output profile. The same options need to be included in the batch processor as well.

On a longer term, and if there is some interest from the community, I am thinking about porting the code to Android in a simplified form that would be suitable for tablets and the like. The small memory footprint of the program could be an important advantage on such systems.

PX: What other applications would you like to make an AppImage for? Have you explored Snaps or Flatpaks?

AF: I am currently developing and refining AppImage packages for GIMP, RawTherapee, LuminanceHDR and HDRMerge, in addition to PhotoFlow. All packages are automatically built and deployed through Travis CI, for better reproducibility and increased security. Hugin is the next application that I plan to package as an AppImage.

All the AppImage projects are freely available on GitHub. That’s also the best place for any feedback, bug report, or suggestion.

There is an ongoing discussion with the GIMP developers about the possibility to provide the AppImage as an official download.

In addition to the AppImage packages, I am also working with the RawTherapee developers on cross-compiled Windows packages that are also automatically built on Travis CI. The goal is to help them provide up-to-date packages from the main development branches, so that more users can test them and provide feedback.

I’m also open to any suggestions for additional programs that could be packaged as AppImages, so do not hesitate to express your wishes!

Personally I am a big fan of the AppImage idea, mostly because, unlike Snap or Flatpack packages, it is not bound to any specific distribution or run-time environment. The packager has full control over the contents of the AppImage package, pretty much like MacOS bundles.

Moreover, I find the community of developers around the AppImage format very active and open-minded. I am currently collaborating to improve the packaging of GTK applications. For those who are interested in the details, the discussion can be followed here: https://github.com/linuxdeploy/linuxdeploy/issues/2

G'MIC 2.3.6

10 Years of Open Source Image Processing!

The IMAGE team of the GREYC laboratory is happy to celebrate the 10th anniversary of G’MIC with you, an open-source (CeCILL), generic and extensible framework for image processing. GREYC is a public research laboratory on digital technology located in Caen, Normandy/France, under the supervision of 3 research institutions: the CNRS (UMR 6072), the University of Caen Normandy and the ENSICAEN engineering school.

This celebration gives us the perfect opportunity to announce the release of a new version (2.3.6) of this free software and to share with you a summary of the latest notable changes since our last G’MIC report, published on PIXLS.US in February 2018.

Related links:

• The G’MIC project
• Twitter feed
• Announcement of the first version of G’MIC on LinuxFr.org [fr]
• Previous article about G’MIC on PIXLS.US

(Click on the images of the report to display them in full resolution)

1. Looking back at 10 years of development

G’MIC is a multiplatform framework (GNU/Linux, macOS, Windows…) providing various user interfaces for manipulating generic image data, such as 2D or 3D hyperspectral images or image sequences with float values (thus including “normal” color images). More than 1000 different operators for image processing are included, a number that is extensible at will since users can add their own functions by using the embedded script language.

It was at the end of July 2008 that the first lines of G’MIC code were created (in C++). At that time, I was the main developer involved in CImg, a lightweight open source C++ library for image processing, when I made the following observation:

• The initial goal of CImg, which was to propose a “minimal” library of functions to help C++ developers to develop image processing algorithms, was broadly achieved; most of the algorithms I considered as essential in image processing were integrated. CImg was initially meant to stay lightweight, so I didn’t want to include new algorithms ad vitam æternam, which would be too heavy or too specific, thus betraying the initial concept of the library.
• However, this would only cater to a rather small community of people with both C++ knowledge and image processing knowledge! One of the natural evolutions of the project, creating bindings of CImg to other programming languages, didn’t appeal much to me given the lack of interest I had in writing the code. And these potential bindings still only concerned an audience with some development expertise.

My ideas were starting to take shape: I needed to find a way to provide CImg processing features for non-programmers. Why not attempt to build a tool that could be used on the command line (like the famous convert command from Imagemagick)? A first attempt in June 2008 (inrcast, presented on the French news site LinuxFR), while unsuccessful, allowed me to better understand what would be required for this type of tool to easily process images from the command line.

In particular, it occurred to me that conciseness and coherence of the command syntax were the two most important things to build upon. These were the aspects that required the most effort in research and development (the actual image processing features were already implemented in CImg). In the end, the focus on conciseness and coherence took me much further than originally planned as G’MIC got an interpreter) of its own scripting language, and then a JIT compiler for the evaluation of mathematical expressions and image processing algorithms working at the pixel level.

With these ideas, by the end of July 2008, I was happy to announce the first draft of G’MIC. The project was officially up and running!

A few months later, in January 2009, enriched by my previous development experience on GREYCstoration (a free tool for nonlinear image denoising and interpolation, from which a plug-in was made for GIMP), and in the hopes of reaching an even larger public, I published a G’MIC GTK plug-in for GIMP. This step proved to be a defining moment for the G’MIC project, giving it a significant boost in popularity as seen below (the project was hosted on Sourceforge at the time).

The sudden interest in the plugin from different users of GIMP (photographers, illustrators and other types of artists) was indeed a real launchpad for the project, with the rapid appearance of various contributions and external suggestions (for the code, management of the forums, web pages, writing of tutorials and realization of videos, etc.). The often idealized community effect of free software finally began to take off! Users and developers began to take a closer look at the operation of the original command-line interface and its associated scripting language (which admittedly did not interest many people until that moment!). From there, many of them took the plunge and began to implement new image processing filters in the G’MIC language, continuously integrated them into the GIMP plugin. Today, these contributions represent almost half of the filters available in the plugin.

Meanwhile, the important and repeated contributions of Sébastien Fourey, colleague of the GREYC IMAGE team (and experienced C++ developer) significantly improved the user experience of G’MIC. Sébastien is indeed at the heart of the main graphical interface development of the project, namely:

• The G’MIC Online web service (which was later re-organised by GREYC’s Development Department).
• Free Software ZArt, a graphical interface - based on the _Qt_ library - for the application of G’MIC filters to video sequences (from files or digital camera streams).
• And above all, at the end of 2016, Sébastien tackled a complete rewrite of the G’MIC plugin for GIMP in a more generic form called G’MIC-Qt. This component, also based on the _Qt_ library (as the name suggests), is a single plugin that works equally well with both GIMP and Krita, two of the leading free applications for photo retouching/editing and digital painting. G’MIC-Qt has now completely supplanted the original GTK plugin thanks to its many features: built-in filter search engine, better preview, superior interactivity, etc. Today it is the most successful interface of the G’MIC project and we hope to be able to offer it in the future for other host applications (contact us if you are interested in this subject!).

The purpose of this article is not to go into too much detail about the history of the project. Suffice it to say that we have not really had time to become bored in the last ten years!

Today, Sébastien and I are the two primary maintainers of the G’MIC project (Sébastien mainly for the interface aspects, myself for the development and improvement of filters and the core development), in addition to our main professional activity (research and teaching/supervision).

Let’s face it, managing a free project like G’MIC takes a considerable amount of time, despite its modest size (~120k lines of code). But the original goal has been achieved: thousands of non-programming users have the opportunity to freely and easily use our image processing algorithms in many different areas: image editing, photo manipulation, illustration and digital painting, video processing, scientific illustration, procedural generation, glitch art…

The milestone of 3.5 million total downloads was exceeded last year, with a current average of about 400 daily downloads from the official website (figures have been steadily declining in recent years as G’MIC is becoming more commonly downloaded and installed via alternative external sources).

It is sometimes difficult to keep a steady pace of development and the motivation that has to go with it, but we persisted, thinking back to the happy users who from time to time share their enthusiasm for the project!

Obviously we can’t name all the individual contributors to G’MIC whom we would like to thank, and with whom we’ve enjoyed exchanging during these ten years, but our heart is with them! Let’s also thank the GREYC laboratory and INS2I institute of CNRS for their strong support for this free project. A big thank you also to all the community of PIXLS.US who did a great job supporting the project (hosting the forum and publishing our articles on G’MIC).

But let’s stop reminiscing and get down to business: new features since our last article about the release of version 2.2!

2. Automatic illumination of flat-colored drawings

G’MIC recently gained a quite impressive new filter named « Illuminate 2D shape », the objective of which is to automatically add lit zones and clean shadows to flat-colored 2D drawings, in order to give a 3D appearance.

First, the user provides an object to illuminate, in the form of an image on a transparent background (typically a drawing of a character or animal). By analyzing the shape and content of the image, G’MIC then tries to deduce a concordant 3D elevation map (“ bumpmap “). The map of elevations obtained is obviously not exact, since a 2D drawing colored in solid areas does not contain explicit information about an associated 3D structure! From the estimated 3D elevations it is easy to deduce a map of normals (“ normalmap “) which is used in turn to generate an illumination layer associated with the drawing (following a Phong Shading model).

This new filter is very flexible and allows the user to have a fairly fine control over the lighting parameters (position and light source rendering type) and estimation of the 3D elevation. In addition the filter gives the artist the opportunity to rework the generated illumination layer, or even directly modify the elevation maps and estimated 3D normals. The figure below illustrates the process as a whole; using the solid colored beetle image (top left), the filter fully automatically estimates an associated 3D normal map (top right). This allows it to generate renditions based on the drawing (bottom row) with two different rendering styles: smooth and quantized.

Despite the difficulty inherent in the problem of converting a 2D image into 3D elevation information, the algorithm used is surprisingly effective in a good many cases. The estimation of the 3D elevation map obtained is sufficiently consistent to automatically generate plausible 2D drawing illuminations, as illustrated by the two examples below - obtained in just a few clicks!

It occurs, of course, that the estimated 3D elevation map does not always match what one might want. Fear not, the filter allows the user to provide “guides” in the form of an additional layer composed of colored lines, giving more precise information to the algorithm about the structure of the drawing to be analyzed. The figure below illustrates the usefulness of these guides for illuminating a drawing of a hand (top left); the automatic illumination (top right) does not account for information in the lines of the hand. Including these few lines in an additional layer of “guides” (in red, bottom left) helps the algorithm to illuminate the drawing more satisfactorily.

If we analyze more precisely the differences obtained between estimated 3D elevation maps with and without guides (illustrated below as symmetrical 3D objects), there is no comparison: we go from a very round boxing glove to a much more detailed 3D hand estimation!

Finally, note that this filter also has an interactive preview mode, allowing the user to move the light source (with the mouse) and have a preview of the drawing illuminated in real time. By modifying the position parameters of the light source, it is thus possible to obtain the type of animations below in a very short time, which gives a fairly accurate idea of the 3D structure estimated by the algorithm from the original drawing.

A video showing the various possible ways to edit the illumination allowed by this filter is visible here. The hope is this new feature of G’MIC allows artists to accelerate the illumation and shading stage of their future drawings!

3. Stereographic projection

In a completely different genre, we have also added a filter implementing stereographic projection, suitably named “Stereographic projection“. This type of cartographic projection makes it possible to project planar defined image data onto a sphere. It should be noted that this is the usual projection used to generate images of “mini-planets” from equirectangular panoramas, like the one illustrated in the figure below.

If we launch the G’MIC plugin with this panorama and select the filter “Stereographic projection“, we get:

The filter allows precise adjustments of the projection center, the rotation angle, and the radius of the sphere, all interactively displayed directly on the preview window (we will come back to this later). In a few clicks, and after applying the filter, we get the desired “mini-planet”:

It is also intruiging to note that simply by reversing the vertical axis of the images, we transform a “mini-planet” into a “max-tunnel”!

Again, we made this short video which shows this filter used in practice. Note that G’MIC already had a similar filter (called “Sphere“), which could be used for the creation of “mini-planets”, but with a type of projection less suitable than the stereographic projection now available.

4. Even more possibilities for color manipulation

Manipulating the colors of images is a recurring occupation among photographers and illustrators, and G’MIC already had several dozen filters for this particular activity - grouped in a dedicated category (the originally named “Colors“ category!). This category is still growing, with two new filters having recently appeared:

• The “CLUT from after-before layers“ filter tries to model the color transformation performed between two images. For example, suppose we have the following pair of images:

Problem: we do not remember at all how we went from the the original image to the modified image, but we would like to apply the same process to another image. Well, no more worries, call G’MIC to the rescue! The filter in question will seek to better model the modification of the colors in the form of a HaldCLUT, which happens to be a classic way to represent any colorimetric transformation.

The HaldCLUT generated by the filter can be saved and re-applied on other images, with the desired property that the application of the HaldCLUT on the original image produces the target model image originally used to learn the transformation. From there, we are able to apply an equivalent color change to any other image:

This filter makes it possible in the end to create HaldCLUT “by example”, and could therefore interest many photographers (in particular those who distribute compilations of HaldCLUT files, freely or otherwise!).

• A second color manipulation filter, named “Mixer [PCA]“ was also recently integrated into G’MIC. It acts as a classic color channel mixer, but rather than working in a predefined color space (like sRGB, HSV, Lab…), it acts on the “natural” color space of the input image, obtained by principal component analysis (PCA) of its RGB colors. Thus each image will be associated with a different color space. For example, if we take the “lion” image below and look at the distribution of its colors in the RGB cube (right image), we see that the main axis of color variation is defined by a straight line from dark orange to light beige (axis symbolized by the red arrow in the figure).

The secondary axis of variation (green arrow) goes from blue to orange, and the tertiary axis (blue arrow) from green to pink. It is these axes of variation (rather than the RGB axes) that will define the color basis used in this channel mix filter.

It would be wrong to suggest that it is always better to consider the color basis obtained by PCA for the mixing of channels, and this new filter is obviously not intended to be the “ultimate” mixer that would replace all others. It simply exists as an alternative to the usual tools for mixing color channels, an alternative whose results proved to be quite interesting in tests of several images used during the development of this filter. It does no harm to try in any case…

5. Filter mishmash

This section is about a few other filters improved or included lately in G’MIC which deserve to be talked about, without dwelling too much on them.

• Filter “Local processing” applies a color normalization or equalization process on the local image neighborhoods (with possible overlapping). This is an additional filter to make details pop up from under or over-exposed photographs, but it may create strong and unpleasant halo artefacts with non-optimal parameters.

  

• If you think that the number of layer blending modes available in GIMP or Krita is not enough, and dream about defining your own blending mode formula, then the recent improvement of the G’MIC filter « Blend [standard] » will please you! This filter now gets a new option « Custom formula » allowing the user to specify their own mathematical formula when blending two layers together. All of your blending wishes become possible!

  

• Also note the complete re-implementation of the nice “Sketch“ filter, which had existed for several years but could be a little slow on large images. The new implementation is much faster, taking advantage of multi-core processing when possible.

  

• A large amount of work has also gone into the re-implementation of the “Mandelbrot - Julia sets“ filter, since the navigation interface has been entirely redesigned, making exploration of the Mandelbrot set much more comfortable (as illustrated by this video). New options for choosing colors have also appeared.

  

• In addition, the “Polygonize [Delaunay]“ filter that generates polygonized renderings of color images has a new rendering mode, using linearly interpolated colors in the Delaunay triangles produced.

  

6. Other important highlights

6.1. Improvements of the plug-in

Of course, the new features in G’MIC are not limited to just image processing filters! For instance, a lot of work has been done on the graphical interface of the plug-in G’MIC-Qt for GIMP and Krita:

• Filters of the plug-in are now allowed to define a new parameter type point(), which displays as a small colored circle over the preview window. The user can drag this circle and move it with the mouse. As a result this can give the preview widget a completely new type of user interaction, which is no small thing! A lot of filters now use this feature, making them more pleasant to use and intuitive (look at this video for some examples). The animation below shows for instance how these new interactive points has been used in the filter « Stereographic projection » described in previous sections.

• In addition, introducing these interactive points has allowed improving the split preview modes, available in many filters to display the « before/ after » views side by side when setting the filter parameters in the plug-in. It is now possible to move this « before/ after » separator, as illustrated by the animation below. Two new splitting modes (« Checkered » and « Inverse checkered » ) have been also included alongside it.

A lot of other improvements have been made to the plug-in: the support of the most recent version of GIMP (2.10), of Qt 5.11, improved handling of the error messages displayed over the preview widget, a cleaner designed interface, and other small changes have been made under the hood, which are not necessarily visible but slightly improve the user experience (e.g. an image cache mechanism for the preview widget). In short, that’s pretty good!

6.2. Improvements in the software core

Some new refinements of the G’MIC computational core have been done recently:

• The “standard library” of the G’MIC script language was given new commands for computing the inverse hyperbolic functions (acoss, asinh and atanh), as well as a command tsp (travelling salesman problem) which estimates an acceptable solution to the well-known Travelling salesman problem, and this, for a point cloud of any size and dimension.

  

  

• The demonstration window, which appears when gmic is run without any arguments from the command line, has been also redesigned from scratch.

• The embedded JIT compiler used for the evaluation of mathematical expressions has not been left out and was given new functions to draw polygons (function polygon()) and ellipses (function ellipse()) in images. These mathematical expressions can in fact define small programs (with local variables, user-defined functions and control flow). One can for instance easily generate synthetic images from the command line, as shown by the two examples below.

Example 1

$ gmic 400,400,1,3 eval "for (k = 0, k<300, ++k, polygon(3,u([vector10(0),[w,h,w,h,w,h,0.5,255,255,255])))"

Result:

Example 2

$ gmic 400,400,1,3 eval "for (k=0, k<20, ++k, ellipse(w/2,h/2,w/2,w/8,k*360/20,0.1,255))"

Result:

• Note also that NaN values are now better managed when doing calculus in the core, meaning G’MIC maintains coherent behavior even when it has been compiled with the optimisation -ffast-math. Thus, G’MIC can be flawlessly compiled now the maximum optimization level -Ofast supported by the compiler g++, whereas we were restricted to the use of -O3 before. The improvement in computation speed is clearly visible for some of the offered filters !

6.3. Distribution channels

A lot of changes have also been made to the distribution channels used by the project:

• First of all, the project web pages (which are now using secured https connections by default) have a new image gallery. This gallery shows both filtered image results from G’MIC and the way to reproduce them (from the command line). Note that these gallery pages are automatically generated by a dedicated G’MIC script, which ensures the displayed command syntax is correct.

  

This gallery is split into several sections, depending on the type of processing done (Artistic, Black & White, Deformations, Filtering, etc.). The last section « Code sample » is my personal favorite, as it exhibits small animations (shown as looping animated GIFs) which have been completely generated from scratch by short scripts, written in the G’MIC language. Quite a surprising use of G’MIC that shows its potential for generative art.

• We have also moved the main git source repository of the project to Framagit, still keeping one synchronized mirror on Github at the same place as before (to benefit from the fact that a lot of developers have already an account on Github which makes it easier for them to fork the project and write bug reports).

7. Conclusions and Perspectives

Voilà! Our tour of news (and the last six months of work) on the G’MIC project comes to an end.

We are happy to be celebrating 10 years with the creation and evolution of this Free Software project, and to be able to share with everyone all of these advanced image processing techniques. We hope to continue doing so for many years to come!

Note that next year, we will also be celebrating the 20th anniversary of CImg, the C++ image processing library (started in November 1999) on which the G’MIC project is based, proof that interest in free software is enduring.

As we wait for the next release of G’MIC, don’t hesitate to test the current version. Freely and creatively play with and manipulate your images to your heart’s content!

Thank you, Translators: (ChameleonScales, Pat David)

From Russia with Love

An Interview with Photographer Ilya Varivchenko

Ilya Varivchenko is a fashion and portrait photographer from Ivanovo, Russian Federation. He’s a UNIX administrator with a long-time passion for photography that has now become a second part-time job for him. Working on location and in his studio, he’s been producing a wonderful body of work specializing in portraiture, model tests, and more.

He’s a member of the community here (@viv), and he was kind enough to spare some time and answer a few questions (plus it gives me a good excuse to showcase some of his great work!).

Much of your work feels very classical in posing and light, particularly your studio portraits. What would you say are your biggest influences?

I am influenced by several classical painters and great modern photographers. Some of them are: Patrick Demarchelier, Steven Meisel and Peter Lindbergh. The general mood defines what I see around me. Russia is a very neglected but beautiful country and women around are an inexhaustible source of inspiration.

How would you describe your own style overall?

My style is certainly a classic portrait in its modern performance.

What motivates you when deciding who/how you shoot?

I usually plan shooting in advance. The range of models is rather narrow and it’s not so easy to get there. However, I am constantly looking for new faces. I choose the style and direction of a particular shooting based on my vision of the model and the current mood.

Why portraits? What about portraiture draws you to it?

I shoot portraits because people interest me. For me, photography is an instrument of knowing people and a means of communication.

If you had to pick your own favorite 3 photographs of your work, which ones would you choose and why?

It’s difficult to choose only three photographs, but maybe these:

If you had to pick 3 favorite images from someone else, which ones would you choose and why?

It is very difficult to choose only three photos. The choice in any case will be incomplete, but here’s the first ones that comes to mind:

1. The portrait of Heather Stewart-Whyte by Friedemann Hauss:

2. The portrait of Monica Bellucci by Chico Bialas:

3) The portrait of Nicole Kidman by Patrick Demarchelier

How do you find your models usually?

Via social media which is the best means for model searching, but if I meet a girl I really like in the street, I can try and talk to her straight away. In fact, the problem is not to find a model, but to choose how to reject a request without offending a prospect model that is of no interest to me.

Do you pre-visualize and plan your shoots ahead of time usually, or is there a more organic interaction with the model and the space you’re shooting in?

It’s always good to have a plan. It is also very good to have a spare plan.

Usually I discuss some common points with the model and stylist before shooting. But these plans are more connected with the mood and the general idea of the session. So when the magic of shooting begins, usually all the plans fly to hell. ;)

Do you have a shooting assistant with you, or is normally just you and the model?

The preparatory stage of shooting often requires participation of many people: a makeup artist, a hair stylist, etc., but shooting itself goes better when only two persons are involved. This is a fairly intimate process. Just like sex. :)

On the other hand, if we do a fashion shoot on order, then the presence of the customer representatives is a must.

Many shots have a strong editorial fashion feel to them: are those works for magazine/editorial use - or were they personal works you were planning to be that way?

I take pictures for local magazines and advertising agencies sometimes. Maybe it somehow influenced my other work.

What do you do with the photos you shoot?

Most of my works are for personal use. However, I often print them in a large format and I’ve also had two solo exhibitions. Prints with my works are sold and they can always be ordered. I also publish in photo magazines sometimes, but these magazines are Russian ones so they are hardly known to you.

By the way: I periodically take part in the events held by Olympus Russia, where I demonstrate my workflow.

This video shows that I use the RawTherapee as a raw converter :)

You’re shooting on Olympus gear quite a bit, are you officially affiliated with Olympus in some way?

On occasions I hold workshops as a part of the Olympus company marketing activities. Sometimes the Olympus company provides me with their products for testing and I am expected to follow up with a review.

Is your choice to use Free Software for pragmatic reasons, or more idealistic?

The choice was dictated by purely practical considerations. I found a tool, the results of which I am almost completely satisfied with. Detail for example is outstanding, comfortable work with color grading, excellent black and white conversion, and much more.

The fact that the product is free and (which is more important to me) I have an opportunity to communicate with its developers is a huge plus!

For example, with the output of Fuji X-T20, when it was required to add a new DCP profile to the converter I simply contacted the developers, shot the test target and got what I wanted.

Would you describe your workflow a bit? Which projects do you use regularly?

My workflow is quite simple:

1. Shooting. I try to shoot in a way which will not require heavy postprocessing at all. It is much easier to set up light properly than to fix it in Photoshop later.

2. Raw development with RawTherapee. My goal is to develop the image in a way which makes it as close to final as possible. Sometimes this is the end of my workflow. ;)

3. Color correction (if necessary) with 3DLutCreator. In rare cases, it is more convenient to make complex color correction with the help of LUTs.

4. Retouching with Adobe Photoshop. Nothing special. Removal of skin and hair defects, etc. Dodge and burn technique with a Wacom Intuos Pro.

Speaking of gear, what are you shooting with currently?

I have two systems now: Micro Four Thirds system from Olympus and X Series from Fujifilm. Typical setups are:

Studio: Olympus PEN-F + Panasonic G 42.5/1.7 Planair: Olympus PEN-F + M.Zuiko 75/1.8 or FujiFilm X-T20 + Fujinon 35/1.4

Many of your images appear make great use of natural light. For your studio lighting setup, what type of lighting gear are you using?

My studio equipment is a mix of Aurora Codis and Bowens studio lights + a lot of modifiers from large 2 meters parabolic octobox to narrow 40x150 strip boxes and so on.

Is there something outside your comfort zone you wish you could try/shoot more of?

It is definitely landscape photography. And macro photography also attracts me - ants and snails are all great models in fact. :)

What is one piece of advice you would offer to another photographer?

Find in yourself what you want to share with others. Beauty is in the eye of the beholder. No beautiful models will help if you are empty inside.

I want to thank Ilya for taking the time to chat with me! Take some time to have a look through his blog and work (it’s chock full of wonderful work)!

All images copyright Ilya Varivchenko and used with permission.

Welcoming the gPhoto Project to the PIXLS.US community!

Helping the community one project at a time

A major goal of the PIXLS.US effort is to do whatever we can do to help developers of projects unburden themselves from administrating their project. We do this, in part, by providing forum hosting, participating in support, providing web design, and doing community outreach. With that in mind, we are excited to welcome the gPhoto Projects to our discuss forum!

The Entangle interface, which makes use of libgphoto.

You may not have heard of gPhoto, but there is a high chance that you’ve used the project’s software. At the heart of the project is libgphoto2, a portable library that gives application access to hundreds of digital cameras. On top of the foundational library is gphoto2, a command line interface to your camera that supports almost everything that the library can do. The library is used in a bunch of awesome photography applications, such as digiKam, darktable, entangle, and GIMP. There is even a FUSE module, so you can mount your camera storage as a normal filesystem.

gPhoto was recruited to the PIXLS.US community when @darix was sitting next to gPhoto developer Marcus. Marcus was using darix’s Fuji camera to test integration into libgphoto, then the magic happened! Not only will some Fuji models be supported, but our community is growing larger. This is also a reminder that one person can make a huge difference. Thanks darix!

Welcome, gPhoto, and thank you for the years and years of development!

(NSFW) What Stefan Sees

An Interview with Photographer Stefan Schmitz

Stefan Schmitz is a photographer living in Northern France and specializing in sensual and nude portraits. I stumbled upon his work during one of my searches for photographers using Free Software on Flickr, and as someone who loves shooting portraits his work was an instant draw for me.

He’s a member of the forums here (@beachbum) and was gracious enough recently to spare some time chatting with me. Here is our conversation (edited for clarity)…

Are you shooting professionally?

Nope, I’m not a professional photographer, and I think I’m quite happy about that. I do happen to photograph my surroundings for ±40 years now, and I have a basic idea about camera-handling and light. Being a pro is about paying invoices by shooting photos, and I fear that the pressure at the end of some months or quarters can easily take the fun out of photography. I’m an engineer and photography is my second love behind wife and kids.

Every now and then some of my pictures are requested and published by some sort of magazine, press or web-service, and I appreciate the attention and exposure, but there is no (or very little) money in the kind of photography I specialize in, so … everything’s OK the way it is.

What would you say are your biggest influences?

Starting with photographers: Andreas Feininger, Peter Lindbergh and Alfred Stieglitz. Check out the portrait of Georgia O’Keeffe by Alfred Stieglitz: it’s 100 years old and it’s all there. Pose, light, intensity, personality - nobody has invented anything [like it] afterwards. We all just try to get close. I feel the same when I look at images taken by Peter Lindbergh, but my eternal #1 is Andreas Feininger.

I got the photo-virus from my father and I learned nearly everything from daddy’s well-worn copy of The Complete Photographer ^[amzn] (Feininger) from 1965. Every single photo in that book is a masterpiece, even the strictly “instructional” ones. You measure every photo-book in the world against this one and they all finish second. Get your copy!

How would you describe your own style overall?

I shoot portraits of women and most of the time they don’t wear clothes. The portrait-part is very important for me: the model must connect with the viewer and ideally the communication goes beyond skin-deep. I want to see (and show) more than just the surface, and when that happens, I just press the shutter-button and try to get out of the way of the model’s performance.

What motivates you when deciding what/how/who to shoot?

I like women, so I take photos of women. If I were interested in beetles, I’d buy a macro lens and shoot beetles. All kidding aside, I think it’s a natural thing to do. I am married to a beautiful woman, an ex-model, and when she got fed-up with my eternal “can we do one more shoot” requests, we discussed things and she allowed me to go ahead and shoot models. Her support is very important to me, but her taste is very different from mine. I really never asked myself “why” I shoot sensual portraits and nudes. It just feels like “I want to do that” and I feel comfy with it. Does there have to be a reason?

The location is very important for me. Nothing is more boring than blinding a person with a flashlight in front of a gray wallpaper. A room, a window-sill, a landmark - there’s a lot of inspiration out there, and I often think “this is where I want to shoot”. Sometimes my wife tells me of some place she has been to or seen, and I check that out.

If you had to pick your own favorite 3 images of your work, which ones would you choose and why?

Jennifer is a very professional and inspiring model. We’ve worked together quite a number of times and while you may think that this shot was inspired by The Who’s “Pinball Wizard”, I’d answer “right band, wrong song”. It’s The Who, alright, but the song’s “A quick one while he’s away”. I chose this photo because it’s all about Jennifer’s pose and facial expression. It’s sensual, even sexy, but looking at Jennifer’s face you forget about the naked skin and all. There’s beauty, there’s depth … that’s what I’m after.

This shot of Alice is an example for the importance of natural light. There are photographers out there who can arrange light in a similar way, but I doubt that Alice would express this natural serenity in a studio setup with cables and stands and electric-transformers humming. She’s at ease, the light is perfect - I just try to be invisible because I don’t want to ruin the moment.

Try to escape Khiara’s eyes. Go, do it. It’s all there, the pose, the room, the ribbon-chair and the little icon, but those eyes make the picture. I did NOT whiten the eyeballs nor did I dodge the iris, and of course it’s all natural/available light.

If you had to pick 3 favorite images from someone else, which ones would you choose and why?

I already named Stieglitz’ Georgia O’Keeffe as an inspiration further up - next to that there’s Helmut Newton’s Big Nude III, Henrietta and Kim Basinger’s striptease in 9 ¹⁄₂ weeks (white silk nighty and all). Each one a masterpiece, each one very influential for me. Imagine the truth and depth of Georgia with the force and pride of Henrietta and the erotic playfulness of Kim Basinger. That photo would rule the world.

Is there something outside of your comfort zone you wish you could try/shoot more of?

I would like to work more with women above the age of 35, but it’s hard to find them. In general they stop modeling nude when the kids arrive.

Shooting more often outdoors would be cool, too, but that’s not easy here in northern France - there is no guarantee for good weather, and it’s frustrating when you organize a shoot two weeks in advance just to call it off in the very last minute due to bad weather.

Last but not least there’s a special competition among photographers; it’s totally unofficial and called “the white shirt contest”. Shoot a woman in a white shirt and make everybody “feel” the texture of that shirt. I give it a try on every shoot and very few pictures come out the way I wish. Go for it - it’s way harder than I thought!

How do you find your models usually?

There are websites where models and photographers can present their work and get in contact. The biggest-one worldwide is modelmayhem.com, and I highly recommend to become a member. Another good place is tumblr.com, but you have to go through a lot of dirt before you find some true gems. I have made contact via both sites and I recommend them.

You will need some pictures in your portfolio in order to show that you are - in fact - a photographer with a basic idea of portrait-work. If you shoot portraits (I mean really portraits, not some snapshots of granny and the kids under the Christmas-tree), you probably have enough photos on your disk to state the point. But if you don’t and you want to start (nude) portraits, spend some money on a workshop. I did that twice and it really helped me in several ways: communication with the model, how to start a session, do’s and don’ts - and at the end of the day you will drive home with a handful of pictures for your portfolio.

Speaking of gear, what are you shooting with currently (or what is your favorite setup)?

Gear is overrated. I am with Nikon since 1979 and today I own and use two bodies: a 1975 Nikon F2 photomic (bought used in 82), loaded with Kodak Tri-X and a Nikon D610 DSLR. 90% of my pictures are shot with a 50mm standard lens. Next on the list is the 35mm - you will need that in small rooms when the 50mm is already a bit too long and you want to keep some distance. I happen to own a 85mm, but the locations I book and shoot rarely offer enough space to make use of that lens.

There are these cheap, circular 1m silver reflectors on amazon. They cost about 15 €/$ and you get a crappy stand for the same price. That stuff is pure gold - I use the reflector a lot and I highly recommend to learn how to work with it. It’s my little secret weapon when I shoot against the light (see Alice here above).

A camera with a reasonably fast standard lens, a second battery and a silver reflector is all I need. The rest is luxury for me, but I am pretty much a one-trick-pony. Other photographers will benefit more from a bigger kit.

Most of your images appear to be making great use of natural light. Do you use other lighting gear (speedlights, monoblocks, modifiers, etc)?

Right - available light is where it’s at. I very rarely shoot with a flash kit today because it distracts me from the work with the model. I’m a loner on the set, no assistants or friends who come and help, so everything must be totally simple and foolproof.

Saying that, I own an alarming number of speedlights, umbrellas, triggers and softboxes, but I don’t need that gear very often. I try to visit the locations before I shoot. I check the directions and plan for a realistic timeframe, so today I will neither find myself in a totally dark dungeon nor in a sun-filled room with contrasts à gogo. Windows to the west - shoot in the morning, windows facing south-east: shooting in the (late) afternoon.

Here’s a shot of Karolina Lewschenko. We took this photo in a hotel room by the end of October and the available (window) light got too weak, so I used an Aurora Firefly 65 cm softbox with a Metz speedlight and set-up some classic Rembrandt-Light. I packed that gear because I knew that our timeframe wasn’t guaranteed to work out perfectly. “Better be safe than sorry”.

Do you pre-visualize and plan your shoots ahead of time usually, or is there a more organic interaction with the model and the space you’re shooting in?

Yes, I do. When I visit a place, a possible location, I have some Ideas of where to shoot, what furniture to push around and what pose to try. I can pretty much see the final picture (or my idea of it) before I book the model. Having said that, you know that no battle-plan has ever survived the first shot fired…

When the model arrives, we take some time to walk around the locations and discuss possible sets. We will then start to shoot fully clothed in order to get used to another and see how the light will be on the final shots. It’s very important for me to get feedback from the model. She might say that a pose is difficult for her or hurts after a few seconds, that she’s not comfy with something or that she would like to try a totally different thing here. I always pay a lot of attention to those ideas and - out of experience - those shots based on the model’s ideas are in general among the best of the day.

I mean we’re not here because I shoot bugs or furniture, you don’t give me the opportunity to express myself here because you are a fan of crickets; all the attention is linked to the beautiful women on my photos and how they connect with the beholder. I am just the one who captures the moments, it’s the models who fill those moments with intensity and beauty. It would be very stupid of me not to cooperate with a model who knows how to present herself and who comes up with her own ideas.

Always listen to the model, always communicate, never go quiet.

The discussion with the model also includes what degree of nudity we consider. So the second round of photos starts with the “open shirt” or topless shots before the model undresses completely. If we take photos in lingerie, we do that last (after the nudes) because lingerie often leaves traces on the skin and we don’t want that to show.

It is important to know what to do and in what order. You don’t want to have a nude model standing in front of you, asking “what’s next?” and you answer “I dunno - maybe (!) try this or that again”. If you lose your directions for a moment, just say so or say “please get your bathrobe and let’s have a look at the last pictures together”. If you are “not sure”, the model might be “not comfy”, and that’s something we want to avoid.

Would you describe your workflow a bit? Which projects do you use regularly?

A typical session is 90 to 120 minutes and I will end-up with about 500 exposures on the SD-card and maybe a roll of exposed Kodak Tri-X. The film goes to a lab and I will get the negatives and scans back within 15 to 30 days.

There’s two SD-cards, one with RAW files that I import with gThumb to /photos/year/month/day. The other card holds fine-quality JPG and those go to /pictures/year/name_of_model. My camera is already set to monochrome, I get every picture I shoot in b/w on the camera-screen and the JPG-files are also monochrome.

Next step is a pre-selection in Geeqie. That’s one great picture viewer and I delete all the missed shots (bad framing, out of focus etc.) and note/mark all the promising/good shots here. This is normally the end of day one.

Switching from RAWstudio to darktable has been a giant step for me. dt is just a great program and I still learn about new functions and modules every day. The file comes in, is converted to monochrome and afterwards color saturation and lights (red and yellow) are manipulated . This way I can treat the skin (brighter or darker) without influencing the general brightness of the picture. Highlights and lowlights may be pushed a bit to the left and I add the signature and a frame 0,5% wide, lens correction is set automatically. That’s the whole deal. On very rare occasions I add some vignette or drop the brightness gradually from top to bottom, but again: it doesn’t happen all that often. I never cut, crop or re-frame a shot. WYSIWYG. Cropping something out, turning the picture in order to get perfectly vertical lines or the likes - it all feels like cheating. I have no client to please, no deadline to meet, I can take a second longer and frame my photo when I look through the viewfinder.

The photos will then be treated in the GIMP. Some dodge and burn (especially when there are problematic, very high or low contrasts), maybe stamp an electric plug away and in the end I re-size them down to 2560 on the long side (big enough for A3 prints) and (sometimes) apply the sharpening tool with value 20 or 25. Done. I can’t save a crappy shot in post-prod and I won’t try. Out of the 500 or so frames, 10 to 15 will be processed like that and it feels like nothing has changed over the last 40 years. The golden rule was “one good shot per roll of film” and I happen to be there, too. Spot-on!

I load those 15 pictures up on my Flickr account and about once or twice a week I place a shot in the many Flickr groups. Also once a week (or every ten days) I post a photo on my Tumblr account. Today I have about 5k followers and my photos are seen between 500’000 and one million times a month, depending on the time of year and weather. There’s less traffic on warm summer days and more during cold and rainy winter-nights.

It takes me some time before I add a shot to my own website. In comparison I show few photos there, every one for a reason and I point point people to that address, so I hope I only show the best.

Is your choice to use Free Software for pragmatic reasons, or more idealistic?

I owned an Apple II in 1983 and a digital MicroVax in 1990 or so. My way to FOSS started out pragmatic and it became a conviction later on. In the late 90’s and early 2000’s I had my own small business and worked with MS Office on a Win NT machine. Photos were processed with a Nikon film-scanner through the proprietary software into an illegal copy of Adobe PS4. It was OK, stable and I didn’t fear anything, but I wasn’t really happy neither. One day I swung over to Star-Office/OpenOffice.org for financial reasons and I also got rid of that unlicensed PS and installed the GIMP (I don’t know what version, but I upgraded some time later to 1.2, that’s for sure). I had internet access and an email address since 1994, but in the late 90’s big programs still came on CDs attached to computer-magazines. Downloading the GIMP was out of question.

Gaming was never my thing and when I installed Win XP, all hell broke lose - keeping a computer safe, virus-free and running wasn’t easy before the first service pack, but MS reacted way too slow in my opinion - I tried debian (10 CD kit) on my notebook, got it running, found the GIMP and OOo - and that was it. It took a bit of trial and error and I had to buy a number of W-Lan sticks because very few were supported and so on, but in the end I got the machines running.

Later on I got hold of an Ubuntu 7.10 CD, tried that and never looked back. The few changes on my system were from Gnome to XFCE desktop and from Thunderbird to a browser-based mail-client. Xubuntu is a no-brainer, it runs stable and fast. I contribute every December 100.- € to FOSS. That’s in general 50 and 40 to two projects and a tenner to Wikipedia. I’d spend an extra tenner to any project that helps to convert old star-office files (.sdw and so on) to today’s standards (odt…), but nobody seems interested.

What is one piece of advice you would offer to another photographer?

Don’t take any advise from me, i’m still learning myself. Or wait: be kind and a gentleman with the models. They all - each and everyone of them - have had bad experiences with photographers who forgot that the models are nude for the camera, not for the man behind it. They all have been in a room with a photographer who breathes a bit too hard and doesn’t get his gear working … don’t be that arsewipe!

Arrange for a place where the model can undress in privacy - she didn’t come for a strip-show and you shouldn’t try to make it one. Have some bottles of water at hand and talk about your plans, poses and sets with the model. Few people can read minds, so communication works best when you say what you have in mind and the model says how she thinks this can be realized. The more you talk, the better you communicate, the better the pictures. No good photo has ever been shot during a quiet session, believe me.

In general the model will check your portfolio/website and expect to do more or less the same kind of work with you. If you want to do something different, say so when booking the model. If your website shows a lot of nude portraits, models will expect to do that kind of photos. They may be a bit upset if you ask them out of nowhere to wear a latex suit because it’s fetish-Friday in your world. The more open and honest you are from the beginning, the better the shooting will go down.

Don’t overdo the gear-thingy. 90% of my photos are taken with the 50mm standard lens. Period. Sometimes I have to switch to 35mm because the room is a bit to small and the distance too close for the one four-fifty, so everything I bring to an indoor-shooting is the camera, a 50, a 35, an el-cheap-o 100cm reflector from amazon (+/- 15 €/$) and an even cheaper stand for the reflector. Gear is not important, communication is.

Want to spend 300 €/$ on new gear? Spend it on a workshop. Learn how to communicate, get inspiration and fill your portfolio with a first set of pictures, so the next model you email can see that you already have some experience in the field of (nude) portraits. That’s more important than a new flashlight in your bag.

Thank You Stefan!

I want to thank Stefan again for taking the time and being patient enough to chat with me!

Stefan is currently living in Northern France. Before that he lived and worked in Miami, FL, and Northern Germany where he is from, went to school, and met his wife. His main website is at https://whatstefansees.com/, and he can be found on Flickr, Facebook, Twitter, Instagram, and Tumblr.

Unless otherwise noted, all of the images are copyright Stefan Schmitz (all rights reserved) and are used with permission.

Profiling a camera with darktable-chart

Figure out the development process of your camera

[Article updated on: 2019-06-18]

What is a camera profile?

A camera profile is often a combination of a color lookup table (LUT) and a tone curve which is applied to a RAW file to get a developed image. It translates the colors that a camera captures into the colors they should look like. If you shoot in RAW and JPEG at the same time, the JPEG file is already a developed picture. Your camera can do color corrections to the data it gets from the sensor when developing a picture. In other words, if a certain camera tends to turn blue into turquoise, the manufacturers internal profile will correct for the color shift and convert those turquoise values back to their proper hue.

The camera manufacturer creates a tone curve for the camera and understands what color drifts the camera tends to capture and can correct it. Also RAW files normally look very dull and the profile will allow it to look more pleasing with just one click. We can mimic what the camera does using a tone curve and a color LUT. We want to do this as the base curves provided by darktable are generalized for a manufacturers sensor behavior, but individually profiling your camera can provide better color results.

Why do we want a color profile?

The camera captures light as linear RGB values. RAW development software needs to transform those into CIE XYZ tristimulus values for mathematical calculations. The color transformation is often done under the assumption that the conversion from camera RGB to CIE XYZ is a linear 3x3 mapping. Unfortunately it is not because the process is spectral and the camera sensor sensitivity also absorbs spectral light. In darktable the conversion is done the following way: The camera RGB values are transformed using the color matrix (either coming from the Adobe DNG Converter or dcraw) to arrive at approximately profiled XYZ values. darktable provides color lookup table in Lab color space to fix inaccuracies or implement styles which are semi-camera independent. A very cool feature is that a user can edit the color LUT. This color LUT can be created by darktable-chart as this article will show so that you don’t have to create it yourself.

What we want to have is the same knowledge about colors in our raw development software as the manufacturer put into the camera. Therefore we have two ways to achieve this. Either we fit to a JPEG generated by the camera, which can also apply creative styles (such as film emulations, filters), or we profile against real color reproduction. For real color a color target ships with a file providing the color values for each patch it has.

In summary, we can create a profile that emulates the manufactures color processing inside the body, or we can create a profile that renders real color as accurately as possible.

The process for both is nearly identical, and we will note when it diverges in the instructions.

Creating pictures for color profiling

To create the required pictures for camera profiling we need a color chart (aka Color Checker) or an IT8 chart as our target. The difference between a color chart and IT8 chart is the number of patches and often the price. As the IT8 chart has more patches the result will be much better. Optimal would be if the color target comes with a grey card for creating a custom White Balance. I can recommend the X-Rite ColorChecker Passport Photo. It is small, lightweight, all plastic, a good quality tool and also has a gray card. An alternative is the Spyder Checkr. If you want a better profiling result, you can buy a good IT8 chart from Coloraid (you want C1) or invest for example in the ColorChecker Digital SG. (Please share you experience if you buy a Coloraid C1!). I recommend getting a gray card as this makes profiling easier.

Note: ArgllCMS offers CIE and CHT files for different color charts, if you already have one or are going to buy one, check if ArgyllCMS offers support for it first! You can always add support to your color chart to ArgylCMS, but the process is much more complex. This will be very important later! You can find these files (generally) in:

/usr/share/color/argyll/ref/

The path might differ depending on the distribution you’re using. Your package management tool should provide a way to list all files of a package so it should be easy to find.

find /usr/share -name "*.cht"

is a possible alternative to track down where the files are located.

We are creating a color profile for direct sunlight conditions (D50) which can be used as a general purpose profile. For this we need some special conditions.

The Color Checker needs to be photographed in direct sunlight at 5000K (K = Kelvin), which helps to reduce any metamerism of colors on the target and ensures a good match to the data file that tells the profiling software what the colors on the target should look like. However a major concern is glare, but we can reduce it with some tricks.

One of the things we can do to reduce glare, is to build a simple shooting box. For this we need a cardboard box and at least three black T-Shirts. The box should be open on the top and on the front like in the following picture (Figure 1).

Normally you just need to cut one side open. However it is better if you use one big cardboard and build the box yourself. This way you can make the box so it widens up in the front, see Figure 1. Then coat the inside of the box with black T-Shirts like this:

To further reduce glare we just need the right location to shoot the picture. We want to shoot the target when the sun provides a temperature of 5000K (D50). We get that in the morning hours when the sun is at about 45° in the sky. It varies on where on earth you are located and on the season of the year.

I took my shots in central Europe in mid October at 09:45.

To measure 5000K I used a gray card for white balancing. When I shoot the gray card, my camera displayed which temperature the profile has.

Try to shoot on a day with minimal clouds so the sun isn’t changing intensity while you shoot. The higher the temperature the more water is in the atmosphere, which means the quality of the images for profiling might be reduced. Temperatures below 20°C are better than above.

In some countries it may not be possible to accurately produce these images with sunlight. This could be due to air pollution (or lack of), temperature, humidity, latitude, and atmospheric conditions. For example, in Australia, one might be unable to use direct sunlight to create this profile, and would have to use a set of color balanced bulbs with the same box setup to create this.

Shooting outdoor

If you want to shoot outdoor, look for an empty tared parking lot or a lonely road. The parking lot should be pretty big, like from a mall, without any cars or trees! You should be far away from walls, trees or anything which could possibly reflect. Put the box on the ground or a small chair and shoot with the sun above your right or left shoulder behind you. You can use a black fabric (bed sheets) if the ground reflects.

Shooting indoor with artificial light

Avoid all windows and stained glass. Create the box as mentioned, and arrange it in a V shape with your tripod. At the top left of the V is the camera, at the bottom is the color target, and at the top right is the light source. The right source should be bright and even across the room and your setup. Position yourself underneath it to avoid all shadows.

How to shoot the target?

Outdoor preparations

1. Start white balancing your camera outside your house, office etc. with a gray card every hour or 30 mintues in the morning and write down the time and temperature. This way you will find out when the sun provides the right temperatue (5000K) to take pictures for your target.

Taking the pictures

Preparations at home

If you’re shooting outdoor, do the following preparations at home. You will not have much time for taking the pictures of your target. You only have a Window of about 10 minutes. An assitent in the field can be useful.

1. You should use a prime lens for taking the pictures. If possible a 50 mm or 85 mm lens (or anything in between, numbers are for full frame). The less glass the light has to travel through the better it is for profiling. Thus those two lenses are a good choice in the number of glass elements they have and their field of view and also vignetting! With a tele lens we would be too far away and with a wide angle lens we would need to be too near to have just the black box in the picture.

2. Set your metering mode to matrix metering (evaluative metering or multi metering - this is often a symbol with 4 boxes and a circle in the center) and use an aperture of f/8.0 (+/- 1/3 EV). [If you have a spot metering mode which isn’t fixed on the center, then you can point it to the neutral gray patch of the color checker, that’s the one we want to have exposed correctly.]

3. Make sure that Dynamic Range Optimization (DRO) and Auto HDR (High Dynamic Range) or anything like that are turned off!

4. Set the camera to capture “RAW & JPEG” and disable lens corrections (vignetting corrections) for JPEG files if possible. This is important for JPEG and real color fitting. You can leave corrections for color failures turned on.

5. Set your camera to color profile to AdobeRGB.

6. Set the ISO to the lowest possible value. Some cameras have an extended ISO range, don’t use any of those values. For example my camera offers ISO 50, ISO 64 and ISO 80. Those are extended ISO values. The lowest ISO not in the extended range for my camera is ISO 100. Check your camera manual!

7. Wear dark cloths, the best is a black hoody with long sleeves :-)

In the field

Be there in advance so you have time to prepare everything.

1. Set up your shooting box and mount your camera on a tripod. The best is to have the camera looking down on the color chart like in the following picture:

2. Make sure the color chart is parallel to plane of the camera sensors so all patches of the chart are in focus. The color chart should be in the middle of the image using about 1/3 of the screen so that vignetting is not an issue.

3. Shoot the target, zoom to 100% and check for glare and reposition if necessary! In Figure 3b you can see a patch with extreme glare. In Figure 3c you can see a patch with a bit of glare. You should try to get no glare at all. Make sure the sun is shining at an angle on the Color Checker. Change the angle of the target in to box till you get no glare!

3. If your camera has a custom white balance feature and you have a gray card, create a custom white balance profiles till you get 5000K (D50) and use it (see figure 3). Put the gray card in your black box in the sunlight or artificial light at the same position as the Color Checker. If you don’t have a gray card, you have to use Auto White Balance (AWB) and find other ways how to measure when you get 5000K from the sun.

   Once you get 5000K from the the sun, you have about 10 minutes to take the pictures of your target!

Now you want to begin taking images. Normally we want to have a camera profile just for the lowest ISO value.

Note: I created profiles for ISO 100 to ISO 640, because my camera has a gain switch at ISO 640. I learned about that by inspecting the charts which have been measured by DPReview.

You need to take 5 pictures of your target. This is so that if an image is over or under exposed, you have an image with a stop above or below that is then exposed correctly. One photo for -0.3 EV, 0 EV, 0.3 EV, 0.7 EV and 1.0 EV. Some cameras (Fuji) ISO 100 is an Extended value, so use ISO 200. Normally Extended ISO values are captured with the lowest physical ISO and overexposed and then exposure is reduced with image processing. Use the lowest ISO profile for them.

Hint: Some cameras have a “Continues Bracketing” feature. You can set this to 0.3EV and 5 Images. Then the camera will automatically capture 5 images in 0.3 EV stops (-0.3 EV, 0.0 EV, 0.3 EV, 0.7 EV, 1.0 EV) for you.

Once you have done all the required shots, it is time to download the RAW and JPEG files to your computer.

Verifying correct images in darktable

For verifying the images we need to know the L-value from the Lab color space of the neutral gray field in the gray ramp of our color target. For the ColorChecker Passport we can look it up in the color information (CIE) file (ColorCheckerPassport.cie) shipping with ArgyllCMS, which should be located at:

/usr/share/color/argyll/ref/ColorCheckerPassport.cie

The ColorChecker Passport has actually two gray ramps. The neutral gray field is the field on the bottom right of the color target ramp and is called D1 (see Figure 4). For the ColorChecker SG it is the patch E5 and for Wolf Faust’s IT8 target the one on the left of the gray ramp (GS0). It should be described in the specification of your target.

If we check the CIE file, we will find out that the neutral gray field D1 has an L-value of: L=96.260066. Lets round it to L=96. For other color targets you can find the L-value in the description or specification of your target, often it is L=92 (e.g. Wolf Faust’s IT8 GS0). Better check the CIE or CGATS file!

You then open the RAW file in darktable and disable the base curve and all other modules which might be applied automatically! You can leave the Orientation module turned on. Select the standard input matrix in the input color profile module and disable gamut clipping. Make sure “camera white balance” in the white balance module is selected. If lens corrections are automatically applied to your JPEG files, you need to enable lens corrections for your RAW files too! Only apply what has been applied to the JPEG file too.

For my configuration I was left with the following modules enabled:

Output Color Profile
Input Color Profile
Lens Correction (Optional)
Crop & Rotate (Optional)
Demosaic
White Balance
Raw Black/White Point

Apply the changes to all RAW files you have created!

You could consider making a “profiling” style and applying it en-masse.

You can also crop the image but you need to apply exactly the same crop to the RAW and JPEG file! (This is why you use a tripod!)

Now we need to use the global color picker module in darkroom to find out the value of the natural white field on the color target.

• Open the first RAW file in darkroom and expand the global color picker module on the left.
• Select area, mean and Lab in the color picker and use the eye-dropper to select the natural gray field of your target. On the Color Checker it’s on the bottom right. Here is an example:

• If the value displayed in the color picker module matches the L-value of the field or is close (+0/-2. This means L=94 to L=96 is acceptable), give the RAW file and the corresponding JPEG file 5 stars. In the picture above it is the first value of: (96.491, -0.431, 3.020). This means L=96.491, which is what you’re looking for on this color target. You might be looking for e.g. L=92 if you are using a different Color Checker. See above how to find out the L-value for your target.

• For real color profiling this is very important to get right. Additionally you want to check the JPEG is registering a L value between 96 and 98 (0/+2 tolerance). You do not want overexposure here (L=100 is white)! If your images are over exposed, your profile will actually darken the images (this is not what you want).

• For profile extraction, this is less important as darktable-chart will extract the differences between the raw and the JPEG, and will assume the camera’s exposure level was correct. This means if your camera “thinks” a good exposure is L=98 for the JPEG, and the RAW reads as L=85, then your profile needs to create the difference here so you get the same effect.

Exporting images for darktable-chart

For exporting we need to select Lab as output color profile. This color space is not visible in the combo box by default. You can enable it by starting darktable with the following command line argument:

darktable --conf allow_lab_output=true

Or you always enable it by setting allow_lab_output to TRUE in darktablerc. Make sure that you have closed darktable before making this change, then reopen it ( darktable writes to this file and may erase your change if you edit while darktable is running).

~/.config/darktable/darktablerc
allow_lab_output=TRUE

As the output format select “PFM (float)” and for the export path you can use:

$(FILE_FOLDER)/PFM/$(MODEL)_ISO$(EXIF_ISO)_$(FILE_EXTENSION)

Remember to select the Lab output color profile here as well.

You need to export all the RAW and JPEG files, not just the RAWs.

Select all 5 star RAW and JPEG files and export them.

Profiling with darktable-chart

Before we can start you need the chart file for your color target. The chart file contains the layout of the color checker. For example it tells the profiling software where the gray ramp is located or which field contains which color. For the “X-Rite Colorchecker Passport Photo” there is a (ColorCheckerPassport.cht) file provided by ArgyllCMS. You can find it here:

/usr/share/color/argyll/ref/ColorCheckerPassport.cht

Now it is time to start darktable-chart. The initial screen will look like this:

Source Image

In the source image tab, select your PFM exported RAW file as image and for chart your Color Checker chart file. Then fit the displayed grid on your image.

Make sure that the inner rectangular of the grid is completely inside of the color field, see Figure 8. If it is too big, you can use the size slider in the top right corner to adjust it. Better too small than too large.

Reference values

This is the only step where the process diverges for real color vs camera profile creation.

If you are creating a color profile to match the manufacturers color processing in body, you will want to select color chart image and as the reference image select the PFM exported JPEG file which corresponds to the RAW file in the source image tab. Once opened you need to resize the grid again to match the Color Checker in your image. Adjust the size with the slider if necessary.

If you are creating a color profile for real color, select the mode as cie/it8 file and load the corresponding CIE file for your color target. If you have issues with this, run darktable-chart from the CLI and check the output. I found that my chart would not open with:

error with the IT8 file, can't find the SAMPLE_ID column

It’s worth checking the ‘Lab (reference)’ values at the bottom of the display to ensure they match what you expect and were correctly loaded. I saw some cool (but incorrect) results when they did not load!

Process

In this tab you’re asked to select the patches with the gray ramp. For the ‘X-Rite Color Checker Passport’ these are the ‘NEU1 .. NEU8’ fields. Newer version of darktable automatically detect the gray ramps! The input field number of final patches defines how many editable color patches the resulting style will use within the color look up table module. More patches give a better result but slows down the process. I think 28 is a good compromise but you might want to user the maxium of 49.

Once you have done this click on ‘process’ to start the calculation. The quality of the result in terms of average delta E and maximum delta E are displayed below the button. These data show how close the resulting style applied to the source image will be able to match the reference values – the lower the better.

You must click process each time you change source images or reference chart to generate the new profiles. Sometimes process is “greyed out”, so simply toggling the grey ramp setting will reactivate it.

After running ‘process’, click on ‘export’ to save the darktable style.

In the export window you should already get a good name for the style. Add a leading zero for ISO values smaller than 1000 get correct sorting in the styles module, for example: ILCE-7M3_ISO0100_JPG.dtstyle. The JPG in the name should indicate that we fitted against a JPG file. If you fitted against a CIE file, remove the CIE filename from the style name. If you applied a creative style (for example, a film emulation or filter in the camera). to the JPG, probably add it at the end of the file name and style name.

Importing your dtstyle in darktable

To use your just created style, you need to import it in the style module in the lighttable. In the lighttable open the module on the right and click on ‘import’. Select the dtstyle file you created to add it. Once imported you can select a raw file and then double click on the style in the ‘style module’ to apply it.

Open the image in darkroom and you will notice that the base curve has been disabled and a few modules been enabled. The additional modules activated are normally: input color profile, color lookup table and tone curve.

Verifying your profile

To verify the style you created you can either apply it to one of the RAW files you created for profiling. Then use the global color picker to compare the color in the RAW with the style applied to the one in the JPEG file.

I also shoot a few normal pictures with nice colors like flowers in RAW and JPEG and then compare the result. Sometimes some colors can be off which can indicate that your pictures for profiling are not the best. This can be because there were some kind of clouds, glare or the wrong daytime. Redo the shots till you get the result you’re satisfied with.

Sadly this is a trial and error process, so you will have to create some number of profiles before you find the results you want. It’s a good idea to read this article again to see if you missed any important steps.

How does the result look like?

In the following screenshot (Figure 11) you can see the calculated tone curve by darktable chart and the Sony base curve of darktable. The tone curve is based on the color LUT. It will look flat if you apply it without the LUT.

Here is a comparison between the base curve for Sony on the left and the dtstyle (color LUT + tone curve) created with darktable-chart:

Other ideas

This process will work for extracting in-body black and white profiles, as well as creative color profiles. I see a significant improvment in black and white profiles from this process over the use of some of the black and white modules in darktable.

You may find that the lowest ISO profile may provide pretty good results for higher ISO values. This will save you a lot of time profiling, and allows you to blanket-apply your profile to all your images quickly - you only need one profile now! This is highly dependant on your camera however, so experiment with this.

These profiles should work in all light conditions, provided your white balance is correct. Given you now have a color target, you should always take one photo of it, so you can correct the whitebalance later.

Discussion

As always the ways to get better colors are open for discussion an it can be improved in collaboration.

Feedback is very welcome.

Thanks to the darktable developers for such a great piece of software! :-)

William Brown has contributed to the article, based on his profiling experience following this tutorial.

How to create camera noise profiles for darktable

An easy way to create correct profiling pictures

[Article updated on: 2019-11-26]

What is noise?

Noise in digital images is similar to film grain in analogue photography. In digital cameras, noise is either created by the amplification of digital signals or heat produced by the sensor. It appears as random, colored speckles on an otherwise smooth surface and can significantly degrade image quality.

Noise is always present, and if it gets too pronounced, it detracts from the image and needs to be mitigated. Removing noise can decrease image quality or sharpness. There are different algorithms to reduce noise, but the best option is if having profiles for a camera to understand the noise patterns a camera model produces.

Noise reduction is an image restoration process. You want to remove the digital artifacts from the image in such a way that the original image is discernible. These artifacts can be just some kind of grain (luminance noise) or colorful, disturbing dots (chroma noise). It can either add to a picture or detract from it. If the noise is disturbing, we want to remove it. The following pictures show a picture with noise and a denoised version:

To get the best noise reduction, we need to generate noise profiles for each ISO value for a camera.

Creating the pictures for noise profiling

For every ISO value your camera has, you have to take a picture. The pictures need to be exposed a particular way to gather the information correctly. The photos need to be out of focus with a widespread histogram like in the following image:

We need overexposed and underexposed areas, but mostly particularly the grey areas in between. These areas contain the information we are looking for.

Let’s go through the noise profile generation step by step. For easier creation of the required pictures, we will create a stencil which will make it easier to capture the photos.

Building a profiling testbed

Requiements

• A dark room (wait till night time)
• Monitor
• Printer
• Sheets of black thick paper (DIN A3, >= 200g/m²)
• White paper
• Scissors
• Sellotape (Tesafilm)

First you need to get some thicker black paper or cardboard. No light should shine through it! Then you need to print out a gradient on white paper. Light should shine through the white paper!

Print this black to white gradient (PDF)

I got black thick paper (DIN A3, >= 200g/m²) and used two sheets. You need to be able to cover your monitor with the black paper. Put the printed gradient in the middle and draw around it. From three sides (bottom, left, top) make the window smaller by 1 cm, see Figure 1. On the right we need to have a gap.

Next is to cut out the window and type the gradient onto the black paper like in Figure 2. It is important that there is a gap between the white and the black paper on the white side of the gradient. We need light for an overexposed area.

Once you have done that go to your monitor and make it all white. You can an all white image for that. Then tape the sheets to your monitor like in Figure 3.

Taking the pictures

It is time to get your camera. You need to shoot in RAW. It is best to turn off any noise reduction especially long exposure noise reduction. Mount the camera on a tripod and use a lens between 35 mm to 85 mm (full frame). I used a 85 mm f/1.4 lens.

Make sure the gradient fills most of the frame. Set your camera to manual focus and focus on infinity. Select the manual mode of your camera and choose the fastest aperture and ISO100. Depending on the lens you’re using you might want to close the aperture. For me f/1.4 was too blurry and I closed it till f/4.0. You don’t want to see any edges or any structure on the paper but be too blurry. You want to still see the gradient but we want nice transitions between different lightning zone black -> grey -> white like in Figure 4.

Now you need to set the shutter speed. Make the picture really dark and then make the shutter speed longer till the gap which gives us the white from the monitor is overexposed, pure white see Figure 4. The black around the white paper should be underexposed (pure black).

Now you need to take a picture for each ISO value of your camera. When you increase the ISO value you need to decrease the shutter speed!

Creating the noise profiles

STEP 1

Run

/usr/lib/darktable/tools/darktable-gen-noiseprofile --help

If this gives you the help of the tool, continue with STEP 2 otherwise go to STEP 1a. Packages for openSUSE, Fedora, Ubuntu and Debian packaging the noise tools can be found here.

STEP 1a

Your darktable installation doesn’t offer the noise tools so you need to compile it yourself. Before you start make sure that you have the following dependencies installed on your system:

• git
• gcc
• make
• gnuplot
• convert (ImageMagick)
• darktable-cli

Get the darktable source code using git:

git clone https://github.com/darktable-org/darktable.git

Now change to the source and build the tools for creating noise profiles using:

mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX=/opt/darktable -DBUILD_NOISE_TOOLS=ON ..
cd tools/noise
make
sudo make install

STEP 2

Download the pictures from your camera and change to the directory on the command line:

cd /path/to/noise_pictures

and run the following command:

/usr/lib/darktable/tools/darktable-gen-noiseprofile -d $(pwd)

or if you had to download and build the source, run:

/opt/darktable_source/lib/tools/darktable-gen-noiseprofile -d $(pwd)

This will automatically do everything for you. Note that this can take quite some time to finish. I think it took 15 to 20 minutes on my machine. If a picture is not exposed correctly, the tool will tell you the image name and you have to recapture the picture with that ISO. Remove the non-working picture.

The tool will tell you, once completed, how to test and verify the noise profiles you created.

Once the tool finished, you end up with a tarball you can send to darktable for inclusion. You can open a bug here

The interesting files are the presets.json file (darktable input) and, for the developers, the noise_result.pdf file. You can find an example PDF here. It is a collection of diagrams showing the histogram for each picture and the results of the calculations.

A detailed explanation of the diagrams and the math behind it can be found in the original noise profile tutorial by Johannes Hanika.

Feedback is very much welcome in the comments below!

G'MIC 2.2

New features and filters!

The IMAGE team of the GREYC laboratory (UMR CNRS 6072, Caen, France) is pleased to announce the release of a new 2.2 version of G’MIC, its open-source, generic, and extensible framework for image processing. As we already did in the past, we take this opportunity to look at the latest notable features added since the previous major release (2.0, last June).

• The G’MIC project
• Twitter feed
• The G’MIC Online Web Service

Note 1: click on a picture to view a larger version. Note 2: This is a translation of an original article, in French, published on Linuxfr.

1. Context and recent evolutions

G’MIC is a free and open-source software developed since August 2008 (distributed under the CeCILL license), by folks in the IMAGE team at the GREYC, a French public research laboratory located in Caen and supervised by three institutions: the CNRS, the University of Caen, and the ENSICAEN engineering school. This team is made up of researchers and lecturers specialized in the fields of algorithms and mathematics for image processing. As one of the main developer of G’MIC, I wanted to sum up the work we’ve made on this software during these last months.

G’MIC is multi-platform (GNU/Linux, MacOS, Windows …) and provides many ways of manipulating generic image data, i.e. still images or image sequences acquired as hyperspectral 2D or 3D floating-point arrays (including usual color images). More than 950 different image processing functions are already available in the G’MIC framework, this number being expandable through the use of the G’MIC scripting capabilities.

Since the last major version release there have been two important events in the project life:

1.1. Port of the G’MIC-Qt plugin to Krita

When we released version 2.0 of G’MIC a few months ago, we were happy to announce a complete rewrite (in Qt) of the plugin code for GIMP. An extra step has been taken, since this plugin has been extended to fit into the open-source digital painting software Krita. This has been made possible thanks to the development work of Boudewijn Rempt (maintainer of Krita) and Sébastien Fourey (developer of the plugin). The G’MIC-Qt plugin is now available for Krita versions 3.3+ and, although it does not yet implement all the I/O functionality of its GIMP counterpart, the feedback we’ve had so far is rather positive. This new port replaces the old G’MIC plugin for Krita which has not been maintained for some time. The good news for Krita users (and developers) is that they now have an up-to-date plugin whose code is common with the one running in GIMP and for which we will be able to ensure the maintenance and further developments. Note this port required the writing of a source file host_krita.cpp (in C++) implementing the communication between the host software and the plugin, and it is reasonable to think that a similar effort would allow other programs to get their own version of the G’MIC plugin (and the 500 image filters that come with it!).

1.2. CeCILL-C, a more permissive license

Another major event concerns the new license of use : The CeCILL-C license (that is in the spirit of the LGPL) is now available for some components of the G’MIC framework. This license is more permissive than the previously proposed CeCILL license (which is GPL-compatible) and is more suitable for the distribution of software libraries. This license extension (now double licensing) applies precisely to the core files of G’MIC, i.e. its C++ library libgmic. Thus, the integration of the libgmic features (therefore, all G’MIC image filters) is now allowed in software that are not themselves licensed under GPL/CeCILL (including closed source products). The source code of the G’MIC-Qt plugin, meanwhile, remains distributed under the single CeCILL license (GPL-like).

2. Fruitful collaboration with David Revoy

If you’ve followed us for a while, you may have noticed that we very often refer to the work of illustrator David Revoy for his multiple contributions to G’MIC: mascot design, ideas of filters, articles or video tutorials, tests of all kinds, etc. More generally, David is a major contributor to the world of free digital art, as much with the comic Pepper & Carrot he produces (distributed under free license CC -BY), as with his suggestions and ongoing bug reports for the open-source software he uses. Therefore, it seems quite natural to devote a special section to him in this article, summarizing the different ideas, contributions and experiments he has brought to G’MIC just recently. A big thank you, David for your availability, the sharing of your ideas, and for all your work in general!

2.1. Improving the lineart colorization filter

Let’s first mention the progress made on the Black & White / Colorize lineart (smart-coloring) filter that had appeared at the time of the 2.0 G’MIC release. This filter is basically a lineart colorization assistant which was developed in collaboration with David. It tries to automatically generate a colorization layer for a given lineart, from the analysis of the contours and the geometry of that lineart. Following David‘s suggestions, we were able to add a new colorization mode, named “Autoclean“. The idea is to try to automatically “clean” a coloring layer (made roughly by the user) provided in addition to the lineart layer, using the same geometric analysis as for the previous colorization modes. The use of this new mode is illustrated below, where a given lineart (left) has been colorized approximately by the user. From the two layers line art + color layer, our “Autoclean“ algorithm generates an image (right), where the colors do not overflow the lineart contours (even for “virtual” contours that are not closed). The result is not always perfect, but nevertheless reduces the time spent in the tedious process of colorization.

Note that this filter is also equipped with a new hatch detection module, which makes it possible to avoid generating too many small areas when using the previously available random colorization mode, particularly when the input lineart contains a large number of hatches (see figure below).

2.2. Color equalizer in HSI, HSL and HSV spaces

More recently, David suggested the idea of a filter to separately vary the hue and saturation of colors having certain levels of luminosity. The underlying idea is to give the artist the ability to draw or paint digitally using only grayscale, then colorize his masterpiece afterwards by re-assigning specific colors to the different gray values of the image. The obtained result has of course a limited color range, but the overall color mood is already in place. The artist only has to retouch the colors locally rather than having to colorize the entire painting by hand. The figure below illustrates the use of this new filter Colors/Equalize HSI/HSL/HSV available in the G’MIC plugin : each category of values can be finely adjusted, resulting in preliminary colorizations of black and white paintings.

Note that the effect is equivalent to applying a color gradient to the different gray values of the image. This is something that could already be done quite easily in GIMP. But the main interest here is we can ensure that the pixel brightness remains unchanged during the color transformation, which is not an obvious property to preserve when using a gradient map. What is nice about this filter is that it can apply to color photographs as well. You can change the hue and saturation of colors with a certain brightness, with an effect that can sometimes be surprising, like with the landscape photography shown below.

2.3. Angular deformations

Another one of the David‘s ideas concerned the development of a random local deformation filter, having the ability to generate angular deformations. From an algorithmic point of view, it seemed relatively simple to achieve. Note that once the implementation has been done (in concise style: 12 lines!) and pushed into the official filter updates, David just had to press the “Update Filters“ button of his G’MIC-Qt plug-in, and the new effect Deformations/Crease was there immediately for testing. This is one of the practical side of developing new filters using the G’MIC script language!

However, I must admit I didn’t really have an idea on what this could be useful for in practice. But the good thing about cooperating with David is that HE knows exactly what he’s going to do with it! For instance, to give a crispy look to the edges of his comics, or for improving the render of his alien death ray.

3. Filters, filters, filters…

David Revoy is not the only user of G’MIC: we sometimes count up to 900 daily downloads from the main project website. So it happens, of course, that other enthusiastic users inspire us new effects, especially during those lovely discussions that take place on our forum, kindly made available by the PIXLS.US community.

3.1. Bring out the details without creating “halos”

Many photographers will tell you that it is not always easy to enhance the details in digital photographs without creating naughty artifacts that often have to be masked manually afterwards. Conventional contrast enhancement algorithms are most often based on increasing the local variance of pixel lightness, or on the equalization of their local histograms. Unfortunately, these operations are generally done by considering neighborhoods with a fixed size and geometry, where each pixel of a neighborhood is always considered with the same weight in the statistical calculations related to these algorithms. It is simpler and faster, but from a qualitative point of view it is not an excellent idea: we often get “halos” around contours that were already very contrasted in the image. This classic phenomenon is illustrated below with the application of the Unsharp mask filter (the one present by default in GIMP) on a part of a landscape image. This generates an undesirable “halo” effect at the frontier between the mountain and the sky (this is particularly visible in full resolution images).

The challenge of the detail enhancement algorithms is to be able to analyze the geometry of the local image structures in a more fine way, to take into account geometry-adaptive local weights for each pixel of a given neighborhood. To make it simple, we want to create anisotropic versions of the usual enhancement methods, orienting them by the edges detected in the images. Following this logic, we have added two new G’MIC filters recently, namely Details/Magic details and Details/Equalize local histograms, which try to better take the geometric content of the image into account for local detail enhancement (e.g. using the bilateral filter).

Thus, the application of the new G’MIC local histogram equalization on the landscape image shown before gives something slightly different : a more contrasted result both in geometric details and colors, and reduced halos.

3.2. Different types of image deformations

New filters to apply geometric deformations on images are added to G’MIC on a regular basis, and this new major version 2.2 offers therefore a bunch of new deformation filters. So let’s start with Deformations/Spherize, a filter which allows to locally distort an image to give the impression that it is projected on a 3D sphere or ellipsoid. This is the perfect filter to turn your obnoxious office colleague into a Mr. Potato Head!

On the other hand, the filter Deformations/Square to circle implements the direct and inverse transformations from a square domain (or rectangle) to a disk (as mathematically described on this page), which makes it possible to generate this type of deformations.

The effect Degradations/Streak replaces an image area masked by the user (filled with a constant color) with one or more copies of a neighboring area. It works mainly as the GIMP clone tool but prevents the user to fill the entire mask manually.

3.3. Artistic Abstractions

You might say that image deformations are nice, but sometimes you want to transform an image in a more radical way. Let’s introduce now the new effects that turn an image into a more abstract version (simplification and re-rendering). These filters have in common the analysis of the local image geometry, followed by a step of image synthesis.

For example, G’MIC filter Contours/Super-pixels locally gathers the image pixels with the same color to form a partitioned image, like a puzzle, with geometric shapes that stick to the contours. This partition is obtained using the SLIC method (Simple Linear Iterative Clustering), a classic image partitioning algorithm, which has the advantage of being relatively fast to compute.

The filter Artistic/Linify tries to redraw an input image by superimposing semi-transparent colored lines on an initially white canvas, as shown in the figure below. This effect is the re-implementation of the smart algorithm initially proposed on the site http://linify.me (initially implemented in JavaScript).

The effect Artistic/Quadtree variations first decomposes an image as a quadtree, then re-synthesize it by drawing oriented and plain ellipses on a canvas, one ellipse for each quadtree leaf. This renders a rather interesting “painting” effect. It is likely that with more complex shapes, even more attractive renderings could be synthesized. Surely an idea to keep in mind for the next filters update :)

3.4. “Are there any more?”

And now that you have processed so many beautiful pictures, why not arrange them in the form of a superb photo montage? This is precisely the role of the filter Arrays & tiles/Drawn montage, which allows to create a juxtaposition of photographs very quickly, for any kind of shapes. The idea is to provide the filter with a colored template in addition to the serie of photographs (Fig.3.10a), and then to associate each photograph with a different color of the template (Fig.3.10b). Next, the arrangement is done automatically by G’MIC, by resizing the images so that they appear best framed within the shapes defined in the given montage template (Fig.3.10c). We made a video tutorial illustrating the use of this specific filter.

But let’s go back to more essential questions: have you ever needed to draw gears? No?! It’s quite normal, that’s not something we do everyday! But just in case, the new G’MIC filter Rendering/Gear will be glad to help, with different settings to adjust gear size, colors and number of teeth. Perfectly useless, so totally indispensable!

Need a satin texture right now? No?! Too bad, the filter Patterns / Satin could have been of a great help!

And finally, to end up with the series of these “effects that are useless until we need them”, note the apparition of the new filter Degradations/JPEG artifacts which simulates the appearance of JPEG compression artifacts due to the quantization of the DCT coefficients encoding 8×8 image blocks (yes, you will get almost the same result saving your image as a JPEG file with the desired quality).

4. Other notable improvements

This review of these new available G’MIC filters should not overshadow the various improvements that have been made “under the hood” and that are equally important, even if they are less visible in practice for the user.

4.1. A better G’MIC-Qt plugin interface

A big effort of cleaning and restructuring the G’MIC-Qt plugin code has been realized, with a lot of little inconsistencies fixed in the GUI. Let’s also mention in bulk order some new interesting features that have appeared in the plugin:

• The ability to set a timeout) when trying to preview some computationnaly intensive filters.
• A better management of the input-output parameters for each filter (with persistence, better menu location, and a reset button).
• Maximizing the size of the preview area is now easier. Editing its zoom level manually is now possible, as well as chosing the language of the interface (regardless of the language used for the system), etc.

All these little things gathered together globally improves the user experience.

4.2. Improvements in the G’MIC core

Even less visible, but just as important, many improvements have appeared in the G’MIC computational core and its associated G’MIC script language interpreter. You have to know that all of the available filters are actually written in the form of scripts in the G’MIC language, and each small improvement brought to the interpreter may have a beneficial consequence for all filters at once. Without going too much into the technical details of these internal improvements, we can highlight those points:

• The notable improvement in the syntax of the language itself, which goes along with better performances for the analysis of the language syntax (therefore for the script executions), all this with a smaller memory footprint.

• The G’MIC built-in mathematical expression evaluator is also experiencing various optimizations and new features, to consider even more possibilities for performing non-trivial operations at the pixel level.

• A better support of raw video input/outputs (.yuv format) with support for4:2:2 and 4:4:4 formats, in addition to4:2:0 which was the only mode supported before.

• Finally, two new animations have been added to the G’MIC demos menu (which is displayed e.g. when invoking gmic without arguments from the command-line):

  • First, a 3D starfield animation:

  

  • Second, a playable 3D version of the Tower of Hanoi:

  

• Finally, let us mention the introduction of the command tensors3d dedicated to the 3D representation of second order tensor fields. In practice, it does not only serve to make you want to eat Smarties^®! It can be used for example to visualize certain regions of MRI volumes of diffusion tensors:

  

4.3. New design for G’MIC Online

To finish this tour, let us also mention the complete redesign of G’MIC Online during the year 2017, done by Christophe Couronne and Véronique Robert from the development departement of the GREYC laboratory. G’MIC Online is a web service allowing you to apply a subset of G’MIC filters on your images, directly inside a web browser. These web pages now have a responsive design, which makes them more enjoyable than before on mobile devices (smartphones and tablets). Shown below is a screenshot of this service running in Chrome/Android, on a 10’’ tablet.

5. Conclusion and perspectives

The overview of this new version 2.2 of G’MIC is now over. One possible conclusion could be: “There are plenty of perspectives!“.

G’MIC is a free project that can be considered as mature: the first lines of code were composed almost ten years ago, and today we have a good idea of the possibilities (and limits) of the beast. We hope to see more and more interest from FOSS users and developers, for example for integrating the G’MIC-Qt generic plugin in various software focused on image or video processing.

The possibility of using the G’MIC core under a more permissive CeCILL-C license can also be a source of interesting collaborations in the future (some companies have already approached us about this). While waiting for potential collaborations, we will do our best to continue developping G’MIC and feed it with new filters and effects, according to the suggestions of our enthusiastic users. A big thanks to them for their help and constant encouragement (the motivation to write code or articles, past 11pm, would not be the same without them!).

“Long live open-source image processing and artistic creation!”

LGM and Libre Graphics at SCaLE 16x

All the libre graphics!

There are two libre graphics related meetings coming up early next year. The annual Libre Graphics Meeting (in Spain this year), and something entirely new: a libre graphics track at SCaLE. How exciting!

Libre Graphics Meeting 2018

The Libre Graphics Meeting is going to be in Seville, Spain this year. They recently published their Call for Participation and are accepting presentation and talk proposals now. Unfortunately, I won’t be able to attend this year, but there’s a pretty good chance some friendlier folks from the community will be! We’ll update more about who will be making it out as soon as we know, and maybe we can convince someone to run another photowalk with everyone. (On a side note, if anyone from the community is going to make it and wants a hand putting anything together for a presentation just let us know - we’re here to help.)

Libre Graphics at SCaLE (California, USA)

This year we have a neat announcement - due to some prodding from Nate Willis, we have been given a day at the Southern California Linux Expo (SCaLE) to hold a Libre Graphics focused track! The expo is at the Pasadena Convention Center, March 8-11, 2018.

We first had a chance to hang out with LWN editor Nate Willis during the Libre Graphics Meeting 2016 in London, and later out at the Texas Linux Fest. GIMP was able to have both Akkana Peck and myself out to present on GIMPy stuff and host a photowalk as well.

The organizer for SCaLE, Ilan, was kind enough to give us a day (Friday, March 9^th) and a room for all the libre graphics artists, designers, programmers, and hackers.

I will be in attendance promoting GIMP stuff in the main track, Dr. Ullah (Isaac Ullah) will hopefully be presenting, and Mica will be there (@paperdigits) as well. I’m pretty certain we’ll be holding a photowalk for attendees while we’re there - and we may even setup a nice headshot booth in the expo to take free headshots for folks.

We would love to see some folks out there. If you think you might be able to make it, or even better submit a talk proposal, please come and join us! (I was thinking about getting an AirBnB to stay in, so if folks let me know they are going to make it out we can coordinate a place to all stay together.)

SCaLE Libre Graphics Track Call for Participation

The libre graphics community is thrilled to announce that a special, one-day track at SCaLE 16x will be dedicated to libre graphics software and artists. All those who work with free and open-source tools for creative graphics projects are invited to submit a proposal and join us for the day!

SCaLE 16x will take place from March 8 to 11 of 2018 in Pasadena California. Libre Graphics Day: SCaLE will take place at the main SCaLE venue on Friday, March 9.

The libre graphics track is an opportunity for teams, contributors and practitioners involved in Libre Graphics projects to share their experiences, showcase new developments, and hear new and inspiring ideas.

By libre graphics we mean “free, Libre and Open Source tools for creative uses”. Libre graphics is not just about software, but extends to standards and file formats used in creative work.

People from around the world who are passionate about Free/Libre tools and their creative applications are encouraged to submit a talk proposal. Sessions will be 30 minutes in length.

Developers, artists, and activists alike are invited. First-time presenters and established projects of all sizes are welcome to submit.

We are looking for:

• Reflections and practical sessions on promoting the philosophy and use of Libre Graphics tools.
• Technical presentations and workshops for developers.
• Showcases of excellent work made using Libre Graphics tools.
• New tools and workflows for graphics and code.
• Reflections on the activities of existing Free/Libre and Open Source communities.

Submit

Please submit your proposal to graphics-cfp@socallinuxexpo.org.

If you have any questions feel free to reach out to me on the forum.

Deadline

The deadline for submissions is January 10th, 2018, and participants will be notified by the end of January 2018.

Simple Exposure Mapping in GIMP

A simple approach to blending exposures

There are many different approaches to blending exposures in the various projects, and they can range from extremely detailed and complex to quick and simple. Today we’re going to look at the latter.

I was recently lucky enough to attend an old friends wedding in upstate NY. Mairi got married! (For those not familiar with her, she’s the model from An Open Source Portrait as well as A Chiaroscuro Portrait tutorials.)

I had originally planned on celebrating with everyone and wrangling my two kids, so I left my camera gear at home. Turns out Mairi was hoping that I’d be shooting photos. Not wanting to disappoint, I quickly secured a kit from a local rental shop. (Thank goodness for friends new and old to help wrangle a very busy 2 year old.)

During the rehearsal I was experimenting with views to get a feel for the room I’d have and how framing would work out. One of the shots looked from the audience and right into a late afternoon sun. My inner nerd kicked in and I thought, “This might be a neat image to use for a tutorial!”.

Exposure Fusion (Mapping)

The idea behind exposure fusion (or mapping) is to extend the dynamic range represented in an image by utilizing more than one exposure of the same subject and choosing relevant bits to fit in the final output.

I say “fit” because usually you are trying to put a larger amount of data than a single image might have been able to capture. So you choose which parts you want to use to get something that you’ll like. For example, here we have two images that will be used in this article where the image showing the foreground correctly causes the sky to blow out, while exposing for the sky causes the foreground to go almost black. By selectively combining these two images, we can get something that might show a larger dynamic range than would have been possible in a single exposure:

This is one common use case scenario for creating HDR/EXR imaging (and tonemapping is the term for doing exactly what we’re describing here - squishing data into the viewable range in a way that we like). In fact, at the end of this article I’ll show how Enfuse handled merging these image exposures (spoiler: pretty darn well).

Exposing

In exposing for the subjects in this image, I used the structure to block the sun from direct view (though there’s still a loss of contrast and flaring). The straight out of the camera jpg looks like this:

This gave me a well exposed foreground and subjects. I then gave the shutter speed a quick spin to ¹⁄₁₀₀₀ (about 4-stops) to get the sky better exposed. The camera jpg for the sky looked like this:

In retrospect I probably would have been better to shoot for 2-stops difference to keep the sky exposed higher in the histogram, but c’est la vie. It also helps to avoid going too far in the extremes when exposing, so as to avoid making it look too unrealistic (yes - the example above probably skirts that pretty close, but it’s exaggerated to make a good article). This gives us a nice enough starting point to play with some simple exposure mapping.

Alignment

For this to work properly the images do need to line up as perfectly as possible. Imperfect alignment can be worked around to some extent, usually determined by how complex your masking will have to be, but the better aligned the images are the easier your job will be.

As usual I have had good luck using the align_image_stack script that’s included as part of Hugin. This makes short work of getting the images aligned properly for just this sort of work:

/path/to/hugin/align_image_stack -m -a OUT FILE1 FILE2

On Windows, this looks like:

c:\Program Files\Hugin\bin\align_image_stack.exe -m -a OUT FILE1 FILE2

Once it finishes up, you’ll end up with some new files like OUT0001.tif. These are your aligned images that we’ll now bring into GIMP!

Masking

The heart of fusing these exposures is going to rely entirely on masking. This is where it usually pays off nicely to take your time and consider carefully an approach that will keep things looking clean and with a natural transition between the exposures.

If this had simple geometry it would be an easy problem to solve, but the inclusion of the trees in the background makes it slightly more complex (but not nearly as bad as hair masking can get). The foreground and sky are very simple things to mask overall, where we know we may want 100% of the foreground to come from one image, and 100% of the sky from another. This helps simplifies things greatly.

I tend to keep the darker sky layer on the bottom and the lighter foreground layer above that.

The hard edges of the structure make it an easy masking job there, so the main area of concern here is getting a good blend with the treeline in the background. There are a couple of approaches we can take to try and get a good blend, so let’s have a look…

Luminosity (Grayscale) Mask

A common approach would be to apply an inverted grayscale mask to the foreground layer. If there’s a decent amount of contrast between the foreground/sky layers then this is a quick and easy way to get something to use as a base for further work:

Applying this mask yields pretty good looking results right away:

You can also investigate some of the other color channel options to see if there might be something that works better to create a clean mask with. In GIMP 2.9.x I also found that using Colors > Components > Extract Component using CMYK Key produced another finely separated option.

This makes a nice starting point. As we said we wanted all of the sky from one exposure and the rest of the image from the other exposure, we can start roughing in the overall mask.

For this simple walkthrough we can make our job a bit easier by using two copies of the foreground layer and selectively blending them over the sky layer.

Why Two Layers?

If you take your foreground layer and start cleaning up the mask for the sky by painting in black, it should be relatively easy. Until you get down to the treeline. You can use a soft-edged brush and try to blend in smoothly, but in order to let the sky come through nicely you may find yourself getting more of the dark exposure trees showing through. This will show as a dark halo on the tops of the trees:

A nice way to adjust the falloff along the tops of the trees is by using a second copy of the foreground layer, and using a gradient on the mask that will blend smoothly from full sky to full foreground along the tops of the trees. This will ease the dark halo a bit until the transition looks good to you. You can then modify/update the gradient on the copy until the transition is smooth or to your liking.

At this point my layers would look like this in GIMP:

The results of using a second fore layer with a gradient to help ease the transition:

When pixel-peeping it may not seem perfect, but in the context of the entire image it’s a nice way to get an easy blend for not too much extra work.

At this point most of the exposure is blended nicely. The only place in this particular image I would work some more would be to darken the structure a little bit to lessen the flaring and maybe bring back a little darkness.

This can be accomplished by painting over the top mask. I used black with a smaller opacity of around 25% to paint over the structure and allow the darker version underneath to show through a bit more:

Enfuse Comparison

I have previously used Enfuse and gotten great results even more quickly. For comparison here is the result of running Enfuse against the same images:

I prefer our manually blended result personally, but I could see another future article or post about using the Enfuse blend for areas of complexity and blending the Enfuse output into the final image to help. Might be interesting.

(I prefer our blended result because Enfuse considered extremely bright areas as candidates for fusion with the other exposure - so the bricks and tent highlights got pushed down automatically.)

Fin

From here any further fiddling with the image is purely for fun. The two versions of the image have been merged nicely. If you wanted to adjust the result to not appear quite as extreme you could modify each of the layers to taste.

For instance, you could lighten the sky layer to decrease the extreme range difference between it and the foreground layer. Where’s the fun in keeping it too realistic though? :)

For reference, here’s my final version after masking with a bit of a Portra tone thrown in for good measure:

Resources

This wouldn’t be complete with some resources and further reading for folks!

I have saved the GIMP 2.9.x .XCF file I used to write this. It has all of the masks and layers I used to create the final version of the image:

• Download the GIMP 2.9 .XCF file (116MB).
• Download the GIMP 2.9 .XCF file (half resolution) (38MB)

Further Reading

• Luminosity Masking in darktable
• Basic Exposure Blending with GIMP and G’MIC
• A Blended Panorama with PhotoFlow
• HDR Photography with Free Software

@McCap also created a YouTube video walking through how he approached exposure blending:

The image Wedding Rehearsal by Pat David is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Permissions beyond the scope of this license may be available at https://patdavid.net/about.

Giving Thanks

For a wonderful community

This is becoming a sort of tradition for me to post something giving thanks around this holiday. I think it’s because this community has become such a large part of my life (even if I don’t have nearly as much time to spend on it as I’d like). Also, I think it helps to remind ourselves once in a while of the good things that happen to us. So in that spirit…

Financial Supporters

I want to start things off by acknowledging those that go the extra mile and help offset the costs of the infrastructure to keep this crazy ship afloat (sorry, I’m an ocean engineer by training and a sailor - so nautical metaphors abound!).

Holy Benefactors, Batman!

Once again the amazing Dimitrios Psychogios has graciously covered our server expenses (and then some) for another full year. On behalf of the community, and particularly myself, thank you so much! Your generosity will cover infrastructure costs for the year and give us room to grow as the community does.

We also have some awesome folks who support us through monthly donations (which are nice because we can plan better if we need to). Together they cover the costs of data storage + transfer in/out of Amazon AWS S3 storage (basically the storage and transfer of all of the attachments and files in the forums). So thank you, you cool froods, you really know where your towels are:

• Mica (@paperdigits - https://silentumbrella.com)
• Luka S.
• Barrie (@bminney)

Thank you all! If you happen to see any of these great folks around the forum consider taking a moment to thank them for their generosity! If you’d like to join them in supporting the site financially, check out the support page.

Growth

The community has just been amazing, and we’ve seen nice growth this past year. Since the end of August we’ve seen about a 50% increase in weekly sessions on discuss. We’re currently hovering around 2,500 daily pageviews on the forums:

We’ve added almost 950 new users, or almost 3 new users every day!

There have been quite a few interesting discussions happening on the forums as well. The RawTherapee folks have some neat conversations going on (Local Lab build, New Windows builds, and Pixel Shift!), and @Carmelo_DrRaw (creator of the PhotoFlow editor) has been packaging a GIMP 2.9.X AppImage as well!

Of course, the fun news for many was @houz finally pushing out a Windows version of darktable that was made possible through the help of Peter Budai.

raw.pixls.us

I figure @LebedevRI will yell at me if I forget to mention raw.pixls.us (RPU) again. Back in January @andabata built a new site to help pick up the work of the old rawsamples.ch website to collect raw sample files for testing.

So thank you @andabata and @LebedevRI for your work on this! A big thank you to everyone who has taken the time to check the site and upload missing (or non-freely licensed) raw files to include!

While we’re talking about RPU, please consider having a look at this post about it on discuss and take a few minutes to see if you might be able to contribute by providing raw samples that we are missing or need (see the post for more details). If you don’t have something we need, please consider sharing the post on social media to help us raise awareness of RPU! Thank you!

digiKam

If you’re not aware of it, one of the things we try to do here beside run the site and forum is to assist projects with websites and design work if they want it. Earlier this year the digiKam team needed to migrate their old Drupal website to something more modern (and secure) and @paperdigits figured, “why not”?

So we rolled up our sleeves and got them setup with a newly designed static website built using Hugo (which was completely new to me). We were also able to manage their comments on the website for them by embedding topics from right here on discuss. This way their users can still own their comments and we can manage spam and moderate things for them.

The best part, though, is the addition of their users and knowledge to the community!

darix

I want to personally take a moment to thank @darix for all the work he does keeping things running smoothly here. If you don’t see him, it means all the work he’s doing is paying off.

I speak with him daily and see firsthand the great work he’s doing to make sure all of us have a nice place to call home. Thank you so much, @darix!

Mica

As usual @paperdigits (https://silentumbrella.com) also has a great attitude and pro-active approach to the community which I am super thankful for. He also does things that aren’t always visible, but are essential to keeping things running smoothly, like moderating the forum, checking the health of sites we are helping to manage, and writing/editing posts.

I can’t stress enough how much it helps to keep your interest and spirits engaged in the community when you have someone else around who’s so positive and helpful. Thank you so much, @paperdigits!

All of You

At the end of the day this is a community, and it’s vibrancy and health is a direct result of all of you, its members. So above all else this is by far the thing I am most thankful for - getting to meet, learn, and interact with all of you.

Faces of Open Source

Peter Adams’s Portraits of Revolutionaries

Recently, @houz posted about an amazing project by photographer Peter Adams called Faces of Open Source.

Peter really (ahem) throws a light on many amazing luminaries from not only the Free/Open Source Software community, but in some cases the history and roots of all modern computing. He has managed to coordinate portrait sessions with many people that may be unassuming to a layperson, but take a moment to read any of the short bios on the site and the gravity of the contributions from the subjects to modern computing becomes apparent.

It’s easy for non-technical folks to spot a Bill Gates or Steve Jobs, but what about those who invented the most-used programming language, created the web server that runs the majority of the internet, or mapped the human genome?

He is acutely aware that his subjects represent an important part of the history of Open Source, and in his artist statement for the project he notes:

This project is my attempt to highlight a revolution whose importance is not broadly understood by a world that relies heavily upon the fruits of its labor.

That’s really what Peter has done here. He has collected individuals whose contributions all add up to something far greater than their collective sums to shape the digital world many take for granted these days, and is presenting them in a powerful and thoughtful way more befitting their gifts.

A Chat with Peter Adams

I was lucky enough to be able to get a little bit of time with Peter recently, and with some help from the community had a few questions to present to him. He was kind enough to take some time out of his day and be patient while I prattled on…

What was the motivation for this particular project for you? Why these people?

I had a long career working in the tech industry, and kind of grew up on a lot of this software when I was in college.
Then got to apply it throughout a career as senior technologist or CTO at a bunch of different companies in the valley. So I went from learning about it in college, to being someone that used it, to then being somebody that contributed to it and starting my own open source project back in 2006. That open source ethos, the software, and the people that created, maintained and promoted it - it’s something that’s been right there in my face for, really, the last 25 years.

I wanted to marry my knowledge of it with my passion for photography, and shine a light on it. I went through a few different chapters of the story myself in the 80’s and then the mid-90’s with linux. I kind of felt like the story was starting to slip into obscurity, not because it’s less important - in fact I think it’s more important now than it’s ever been.

The software is actually used by more people now than it has ever been. The smartphone revolution, mobile, has brought that to a forefront and all of these mobile platforms are based on this open source technology. Everything Apple does is based on BSD, and everything Google/Android does is based on Linux.

I feel like it’s a more impactful story now than ever, but very few people are telling the story. As a photographer I’ve always cringed at the photographic response to the story. Podium shot after podium shot of these incredible people.

So I wanted to put some faces to names, bring these people to life in a more impactful way than I think anyone has done before. Hopefully that’s what the project is doing!

P: It absolutely does!

How long have you been shooting the project?

I started this project in 2013/2014, in earnest probably late 2014.

Of all of the people that you’ve shot, I’m curious, who would you say is one that maybe stuck out with you the most, or even better, did you get any cool stories out of some of the subjects?

Everyone that I’ve photographed has been absolutely wonderful. I mean, that’s the first thing about this community: it’s a very gracious community. Everybody was very gracious with their time, and eager to participate. I think people recognize that this is a community they belong to and they really want me to be a part of it, which is really great.

So, I enjoyed my time with everybody. Everybody brought a different, interesting story about things. The UNIX crew from Bell Labs had particularly colorful stories, very interesting sort of historical tidbits about UNIX and Free Software.

I talked to Ken Thompson about going to Russia and flying MIGs right after the collapse of the Soviet Union. Wonderful stories from Doug McIlroy about the team and the engineering - how they worked together at Bell labs. Just a countless list of cool stories and cool people for sure.

P: It must have been fascinating!

It’s been really fun. A lot of these folks, I’ve really looked up to them over the years as sort of heroes, and so when you get people in front of your lens like that, it’s a really wonderful experience. It’s also a challenging experience because you want to do justice to them. Many of these folks that I’ve thought about for 20+ years, finally getting to shoot them is a real treat.

Where are you shooting these? Are you mostly bringing them into your studio in the valley?

I shot a lot of people when I had a studio in Silicon Valley. I brought a lot of people there and that was great. Now typically I’m doing shoots on the coasts. So I’ll do shoots in NY and I’ll rent a studio and bring 6 or 7 people in there or we’ll do a studio up in SF for some people. But I’ve done shoots in back alleyways, I’ve done shoots in tiny little conference rooms, I’ll bring the studio to people if that’s what I have to do. So I’d say so far it’s been about 50-50.

The lighting setups are wonderful and do justice to the subjects, and I think somebody in the community was curious if you had decided on B&W from the beginning for this series of photos? Was this a conscious decision early on?

B&W on a white background was a conscious choice right from the beginning. Knowing the group, I felt like that was going to be the best way to explore the people and the faces. Every one of these faces just tells, I think, a really interesting story. I try to bring the personality of the person into the photo, and B&W has always been my favorite way to do that. The white background just puts the emphasis right on the person.

How much of it would you say is you that goes into the final pose and setup of the person, or do you let the subject feel out the room and get comfortable and shoot from there?

It’s a little bit of both. I wish I got to spend a lot of time up front with the person before we started shooting, but the way everybody’s schedule worked is - none of these shoots are more than an hour and many of them are much shorter than an hour. There’s definitely the pleasantries up front and talking for a little bit, but then I try to get people right in front of the camera as quick as possible.

I don’t really pose them. My process is to sit back and observe, and I always tell people “if I’m not taking photos, it’s not because you’re doing anything wrong - I’m just waiting for you to settle or looking, examining”. Which is, for most people, a really uncomfortable process, I try to make it as comfortable as possible. Then we’ll start taking pictures. I may move them a little bit, or we may setup a table so they can rest their hand on their chin or something like that. Generally the photos that come out are not pre-meditated.

It’s very rare that I go into any of these shoots with an actual “I want the person like this, setup like that, etc…”. I’d say 99% of these shots, the expressions, the feeling that comes out, that I’m capturing is organic. It’s something that comes up in the shoot. I just try to capture it whenever I see it by clicking the shutter, that’s basically what I’m doing there.

You list what equipment you shot each portrait with, but I’m curious about the lighting setup. Is there a “go-to” lighting setup that you like to use?

The lighting is literally the same on every shot, though there’s slightly different positions. It’s a six light setup: there are four lights on the background, there’s a beauty dish overhead, and generally a fill light. The fill is either a big Photek or PLM, basically a big umbrella, or a ringflash depending on how small the room is. That’s the same lighting setup on all of them. Four lights on the background, two lights on the subject. I’ll vary the two lights on the subject positionally, but for the most part they’re pretty close.

Do you use Free Software in your normal photographic workflow at all?

I don’t use as much Free Software as I’d like in my own workflow. My workflow, because I shoot with Phase One, the files go into Capture One and then from there they go into Photoshop for final edits. I have used GIMP in the past. I really would like to use more Free Software, so I’m a learner in that regard for what tools would make sense.

Did that habit grow out of the professional need of having those tools available to you?

Phase One, which makes the Medium Format digital back and camera that I use for all of my portrait work, also makes Capture One. They have basically customized the software to get the most of their own files. That’s pretty much why I’ve wound up there instead of Lightroom or another tool. It’s just that that software tends to bring out the tonality, especially in the B&W side, better I’ve found than any other tool.

This project was self financed to start with?

Yes, this is a self-financed project. I do hope that we’ll get some sponsors, especially for the book, just because it tends to be a pretty heavy upfront outlay to produce a book. I’m going to think about things like Kickstarter but the corporate sponsors I think will be really helpful for the exhibits and the book.

Speaking of the book, is it ready - have you already gone to print?

No, the book isn’t ready yet. I still have probably another 10-12 people that I need to photograph and then we’ll start producing it. I’ve done some prototypes and things on it but it’s still a little bit of a ways away. The biggest hurdle on this project is actually scheduling and logistics. Getting access to people in a way that is economical. Instead of me flying all over the place for one shot, I try to stack up a number of people into a day. It’s tough - this is a busy crowd, very in demand.

Did your working in open source teach you anything beyond computer code in some way? Was there an influence from the people you may have worked around, or the ethos of Free Software in general that stuck with you? Working with this crowd, was there a takeaway for you beyond just the photographic aspects of it?

Absolutely! First of all it’s an incredibly inspiring group of people. This is a group of people that have dedicated, in some cases most of, their lives to the development of software that they give away to the world, and don’t monetize themselves. The work they’re doing is effectively a donation to humanity. That’s incredibly inspiring when you look at how much time goes into these projects and how much time this group of people spends on that. It’s a very humbling thing.

I’d say the other big lesson is that Open Source is such a unique thing. There’s really nothing like it. It’s starting to take over other industries and moving beyond just software - it’s gone into hardware. I’ve started to photograph some of the open source hardware pioneers. It’s going into bio-tech, pharmaceuticals, agriculture (there’s an open source seed project). I think that the lessons that are learned here and that this group of people is teaching is really affecting humanity on a much much larger level than the fact that this stuff is powering your cell phone or is powering your computer.

Open source is really sort of a way of doing business now. Even more than doing business it’s a way of operating in the world. More and more people, industries, and companies are choosing that. In today’s world where all you read is bad news, that’s a lot of really good news. It’s an awesome thing to see that accelerating and catching on. It’s been incredibly inspiring to me.

P: I think even all the way back to the Polio vaccine, is one of those things. The effect that it had on humanity was immeasurable, and the fact that it wasn’t monetized by Salk was amazing.

Look at how many lives were saved because of that. If you think about the acceleration of the innovation we’ve had just in the technology sector - could things like the iPhone or the Android operating system - would these things have happened now, or over the last decade, without this [open source], or would we be looking at those types of innovations happening twenty years from now? I think that’s a question you have to ask.

I don’t think it’s an obvious answer that Apple or Google or somebody else would have just come up with this without the open source [contributions]. This stuff is so fundamental, it’s such a basic building block for everything that’s happening now. It may be responsible for the golden age that we’re seeing now. I think it is.

The average teenager they pick up and post a photo to Instagram - they don’t realize that there’s a hundred open source projects at work to make that possible.

P: And the fact that the people that underlay that entire stack gave it away.

Right. And that giving it away was necessary to create the Instagrams to create all these networks. It wasn’t just this happenstance thing where people didn’t know any better. In some cases obviously that did exist, but it’s the fact that consciously people are contributing into a commons that makes it so powerful and enables all of this innovation to happen. It’s really cool.

To close, is there another photographer, book, organization - that you’d like any of the readers to know about and maybe spend some time to go and check out. Something that maybe you’ve long admired or recently discovered?

Sure! You’ve mentioned Martin Schoeller, who is one of my personal favorites and inspirations out there. I’d say the other photographer who has had probably the most impact on my photography over the years has been Richard Avedon. For people that aren’t familiar with his work I’d say definitely go check out the Avedon foundation. Pick up any of his books which are just wonderful. You’ll definitely see that influence on my photography, especially this project, since he shot black and white on white background. Such stunning work. I’d say that those are two great ones to start with.

Alright! Avedon and Schoeller - I can certainly think of worse people to go start a journey with. Thank you so much for taking time with me today!

Hey no problem! It’s been fun to talk to you.

There are many more fascinating portraits awaiting you over on the project site, and every one of them is worth your time! See them all at:

http://facesofopensource.com/

You can also connect with the project on

• Facebook
• Twitter
• Instagram

Find more of Peters work at his website.

All images from “Faces of Open Source” by Peter Adams, licensed CC BY NC SA 4.0.

Keep the Raws Coming

Moar samples!

Our friendly neighborhood @LebedevRI pointed out to me a little while ago that we had reached some nice milestones for https://raw.pixls.us. Not surprisingly I had spaced out and not written anything about it (or really any sort of social posts). Bad Pat!

So let’s talk about raw.pixls.us (RPU) a bit!

Recap

For anyone not familiar with RPU, a quick recap (we had previously written about raw.pixls.us earlier this year). There used to be a website for housing a repository of raw files for as many digital cameras as possible called rawsamples.ch. It was created by Jakob Rohrbach and had been running since March of 2007. Back in 2016 the site was hit with a SQL injection attack that left the Joomla database corrupted (in a teachable moment, the site also didn’t have a database backup).

With the rawsamples.ch site down, @LebedevRI and @andabata worked to get a replacement option in-place and working: https://raw.pixls.us!

Sexy Stats

We grabbed all the files we could salvage from rawsamples.ch and @andabata setup the new page. We’ve had a slowly growing response as folks have filled in gaps for camera models we still don’t have.

For reference, we currently have unique cameras, and unique samples.

Moar samples!

As @LebedevRI has said, we still really need folks to check RPU and send us more samples!

• We currently only have about 77% coverage.
• We want to replace any non-CC0 (public domain) samples with CC0 licensed samples.
• We are still missing some rarer samples like any medium-format or Sigma samples.

Our hope is that some casual reader out there might look at the list and say “Hey! I’ve got that camera lying around - let me submit a sample!”.

Here’s the current list of missing camera samples:

If you have any of the cameras on this list and don’t mind spending a few minutes uploading a sample file, we would be very grateful for the help!

Don’t forget that we are looking for:

• Lens mounted on the camera, cap off
• Image in focus and properly exposed
• Landscape orientation

and we are not looking for:

• Series of images with different ISO, aperture, shutter, wb, lighting, or different lenses
• DNG files created with Adobe DNG Converter
• Photographs of people, for legal reasons.

If you don’t see your camera on this list, you’re not off the hook yet! We are also looking for files that are licensed very freely…

Non Creative-Commons Zero (CC0)

We have many raw samples that were not licensed as freely as we would like. Ideally we are looking for images that have been released Creative Commons Zero (CC0). This list is all samples we already have that are not licensed CC0, so if you happen to have one of the cameras listed below please consider uploading some new samples for us!

We are really working hard to make sure we are a good resource of freely available raw samples for all Free Software imaging projects to use. Thank you so much for helping out if you can!

G'MIC 2.0

A second breath for open-source image processing.

The IMAGE team of the research laboratory GREYC in Caen/France is pleased to announce the release of a new major version (numbered 2.0) of its project G’MIC: a generic, extensible, and open source framework for image processing. Here, we present the main advances made in the software since our last article. The new features presented here include the work carried out over the last twelve months (versions 2.0.0 and 1.7.x, for _x_ varying from _2_ to _9_).

Links:

• G’MIC main project page
• Twitter feed
• G’MIC plug-in for GIMP
• G’MIC Online web service
• Changelog for the 2.0.0 version

1. G’MIC: A brief overview

G’MIC is an open-source project started in August 2008, by the IMAGE team. This French research team specializes in the fields of algorithms and mathematics for image processing. G’MIC is distributed under the CeCILL license (which is GPL compatible) and is available for multiple platforms (GNU/Linux, MacOS and Windows). It provides a variety of user interfaces for manipulating generic image data, that is to say, _2D_ or _3D_ multispectral images (or sequences) with floating-point pixel values. This includes, of course, “classic” color images.

The popularity of G’MIC mostly comes from the plug-in it provides for GIMP (since 2009). To date, there are more than 480 different filters and effects to apply to your images, which considerably enlarges the list of image processing filters available by default in GIMP.

G’MIC also provides a powerful and autonomous command-line interface, which is complementary to the CLI tools you can find in the famous ImageMagick or GraphicsMagick projects. There is also a web service G’MIC Online, allowing to apply image processing effects directly from a browser. Other (but less well known) G’MIC-based interfaces exist: a webcam streaming tool ZArt, a plug-in for Krita, a subset of filters available in Photoflow, Blender or Natron… All these interfaces are based on the CImg and libgmic libraries, that are portable, thread-safe and multi-threaded, via the use of OpenMP.

G’MIC has more than 950 different and configurable processing functions, for a library of only 6.5Mio, representing a bit more than 180 kloc. The processing functions cover a wide spectrum of the image processing field, offering algorithms for geometric manipulations, colorimetric changes, image filtering (denoising and detail enhancement by spectral, variational, non-local methods, etc.), motion estimation and registration, display of primitives (_2D_ or _3D_ mesh objects), edge detection, object segmentation, artistic rendering, etc. It is therefore a very generic tool for various uses, useful on the one hand for converting, visualizing and exploring image data, and on the other hand for designing complex image processing pipelines and algorithms (see these project slides for details).

2. A new versatile interface, based on Qt

One of the major new features of this version 2.0 is the re-implementation of the plug-in code, from scratch. The repository G’MIC-Qt developed by Sébastien (an experienced member of the team) is a _Qt_-based version of the plug-in interface, being as independent as possible of the widget API provided by GIMP.

This has several interesting consequences:

• The plug-in uses its own widgets (in _Qt_) which makes it possible to have a more flexible and customizable interface than with the GTK widgets used by the GIMP plug-in API: for instance, the preview window becomes resizable at will, manages zooming by mouse wheel, and can be freely moved to the left or to the right. A filter search engine by keywords has been added, as well as the possibility of choosing between a light or dark theme. The management of favorite filters has been also improved and the interface even offers a new mode for setting the visibility of the filters. Interface personalization is now a reality.

• The plug-in also defines its own API, which is used to facilitate its integration in third party software (other than GIMP). In practice, a software developer has to write a single file host_software.cpp implementing the functions of the API to make the link between the plug-in and the host application. Currently, the file host_gimp.cpp does this for GIMP as a host. But there is now also a stand-alone version available (file host_none.cpp that runs this _Qt_ interface in solo mode, from a shell (with command gmic_qt).

• Boudewijn Rempt, project manager and developer of the marvelous painting software Krita, has also started writing such a file host_krita.cpp to make this “new generation” plug-in communicate with Krita. In the long term, this should replace the previous G’MIC plug-in implementation they made (currently distributed with Krita), which is aging and poses maintenance problems for developers.

Minimizing the integration effort for developers, sharing the G’MIC plug-in code between different applications, and offering a user interface that is as comfortable as possible, have been the main objectives of this complete redesign. As you can imagine, this rewriting required a long and sustained effort, and we can only hope that this will raise interest among other software developers, where having a consistent set of image processing filters could be useful (a file host_blender.cpp available soon ? We can dream!). The animation below illustrates some of the features offered by this new _Qt_-based interface.

Note that the old plug-in code written in GTK was updated also to work with the new version 2.0 of G’MIC, but has fewer features and probably will not evolve anymore in the future, unlike the _Qt_ version.

3. Easing the work of cartoonists…

One of G’MIC’s purposes is to offer more filters and functions to process images. And that is precisely something where we have not relaxed our efforts, despite the number of filters already available in the previous versions!

In particular, this version comes with new and improved filters to ease the colorization of line-art. Indeed, we had the chance to host the artist David Revoy for a few days at the lab. David is well known to lovers of art and free software by his multiple contributions in these fields (in particular, his web comic Pepper & Carrot is a must-read!). In collaboration with David, we worked on the design of an original automatic line-art coloring filter, named Smart Coloring.

When drawing comics, the colorization of line-art is carried out in two successive steps: The original drawing in gray levels (Fig.3.2.[1]) is first pre-colored with solid areas, i.e. by assigning a unique color to each region or distinct object in the drawing (Fig.3.2.[3]). In a second step, the colourist reworks this pre-coloring, adding shadows, lights and modifying the colorimetric ambiance, in order to obtain the final colorization result (Fig.3.2.[4]). Practically, flat coloring results in the creation of a new layer that contains only piecewise constant color zones, thus forming a colored partition of the plane. This layer is then merged with the original line-art to get the colored rendering (merging both in multiplication mode, typically).

Artists admit it themselves: flat coloring is a long and tedious process, requiring patience and precision. Classical tools available in digital painting or image editing software do not make this task easy. For example, even most filling tools (bucket fill) do not handle discontinuities in drawn lines very well (Fig.3.3.a), and even worse when lines are anti-aliased. It is then common for the artist to perform flat coloring by painting the colors manually with a brush on a separate layer (Fig.3.3.b), with all the precision problems that this supposes (especially around the contour lines, Fig.3.3.c). See also this link for more details.

It may even happen that the artist decides to explicitly constrain his style of drawing, for instance by using aliased brushes in a higher resolution image, and/or by forcing himself to draw only connected contours, in order to ease the flat colorization work that has to be done afterwards.

The Smart Coloring filter developed in version 2.0 of G’MIC allows to automatically pre-color an input line-art without much work. First, it analyses the local geometry of the contour lines (estimating their normals and curvatures). Second, it (virtually) does contour auto-completion using spline curves. This virtual closure allows then the algorithm to fill objects with disconnected contour plots. Besides, this filter has the advantage of being quite fast to compute and gives coloring results of similar quality to more expensive optimization techniques used in some proprietary software. This algorithm smoothly manages anti-aliased contour lines, and has two modes of colorization: by random colors (Fig.3.2.[2] and Fig.3.4) or guided by color markers placed beforehand by the user (Fig.3.5).

In “random” mode, the filter generates a piecewise constant layer that is very easy to recolor with correct hues afterwards. This layer indeed contains only flat color regions, and the classic bucket fill tool is effective here to quickly reassign a coherent color to each existing region synthesized by the algorithm.

In the user-guided markers mode, color spots placed by the user are extrapolated in such a way that it respects the geometry of the original drawing as much as possible, taking into account the discontinuities in the pencil lines, as this is clearly illustrated by the figure below:

This innovative, flat coloring algorithm has been pre-published on HAL (in French): A semi-guided high-performance flat coloring algorithm for line-arts. Curious people could find there all the technical details of the algorithm used. The recurring discussions we had with David Revoy on the development of this filter enabled us to improve the algorithm step by step, until it became really usable in production. This method has been used successfully (and therefore validated) for the pre-colorization of the whole episode 22 of the webcomic Pepper & Carrot.

The wisest of you know that G’MIC already had a line-art colorization filter! True, but unfortunately it did not manage disconnected contour lines so well (such as the example in Fig.3.5), and could then require the user to place a large number of color spots to guide the algorithm properly. In practice, the performance of the new flat coloring algorithm is far superior.

And since it does not see any objection to anti-aliased lines, why not create ones? That is the purpose of another new filter “Repair / Smooth [antialias]“ able to add anti-aliasing to lines in cartoons that would have been originally drawn with aliased brushes.

4. …Not to forget the photographers!

“Colorizing drawings is nice, but my photos are already in color!”, kindly remarks the impatient photographer. Don’t be cruel! Many new filters related to the transformation and enhancement of photos have been also added in G’MIC 2.0. Let’s take a quick look of what we have.

4.1. CLUTs and colorimetric transformations

CLUTs (Color Lookup Tables) are functions for colorimetric transformations defined in the RGB cube: for each color (Rs,Gs,Bs) of a source image _Is_, a CLUT assigns a new color (Rd,Gd,Bd) transferred to the destination image _Id_ at the same position. These processing functions may be truly arbitrary, thus very different effects can be obtained according to the different CLUTs used. Photographers are therefore generally fond of them (especially since these CLUTs are also a good way to simulate the color rendering of certain old films).

In practice, a CLUT is stored as a _3D_ volumetric color image (possibly “unwrapped” along the z = B axis to get a _2D_ version). This may quickly become cumbersome when several hundreds of CLUTs have to be managed. Fortunately, G’MIC has a quite efficient CLUT compression algorithm (already mentioned in a previous article), which has been improved version after version. So it was finally in a quite relax atmosphere that we added more than 60 new CLUT-based transformations in G’MIC, for a total of 359 CLUTs usable, all stored in a data file that does exceed 1.2 Mio. By the way, let us thank Pat David, Marc Roovers and Stuart Sowerby for their contributions to these color transformations.

But what if you already have your own CLUT files and want to use them in GIMP? No problem ! The new filter “Film emulation / User-defined“ allows to apply such transformations from CLUT data file, with a partial support of files with extension .cube (CLUT file format proposed by Adobe, and encoded in ASCII o_O!).

And for the most demanding, who are not satisfied with the existing pre-defined CLUTs, we have designed a very versatile filter “Colors / Customize CLUT“, that allows the user to build their own custom CLUT from scratch: the user places colored keypoints in the RGB color cube and these markers are interpolated in _3D_ (according to a Delaunay triangulation) in order to rebuild a complete CLUT, i.e. a dense function in RGB. This is extremely flexible, as in the example below, where the filter has been used to change the colorimetric ambiance of a landscape, mainly altering the color of the sky. Of course, the synthesized CLUT can be saved as a file and reused later for other photographs, or even in other software supporting this type of color transformations (for example RawTherapee or Darktable).

To stay in the field of color manipulation, let us also mention the appearance of the filter “Colors / Retro fade“ which creates a “retro” rendering of an image with grain generated by successive averages of random quantizations of an input color image.

4.2. Making the details pop out

Many photographers are looking for ways to process their digital photographs so as to bring out the smallest details of their images, sometimes even to exaggeration, and we can find some of them in the pixls.us forum. Looking at how they perform allowed us to add several new filters for detail and contrast enhancement in G’MIC. In particular, we can mention the filters “Artistic / Illustration look“ and “Artistic / Highlight bloom“, which are direct re-implementations of the tutorials and scripts written by Sébastien Guyader as well as the filter “Light & Shadows / Pop shadows“ suggested by Morgan Hardwood. Being immersed in such a community of photographers and cool guys always gives opportunities to implement interesting new effects!

In the same vein, G’MIC gets its own implementation of the Multi-scale Retinex algorithm, something that was already present in GIMP, but here enriched with additional controls to improve the luminance consistency in images.

Our friend and great contributor to G’MIC, Jérome Boulanger, also implemented and added a dehazing filter “Details / Dcp dehaze“ to attenuate the fog effect in photographs, based on the Dark Channel Prior algorithm. Setting the parameters of this filter is kinda hard, but the filter gives sometimes spectacular results.

And to finish with this subsection, let us mention the implementation in G’MIC of the Rolling Guidance algorithm, a method to simplify images that has become a key step used in many newly added filters. This was especially the case in this quite cool filter for image sharpening, available in “Details / Sharpen [texture]“. This filter works in two successive steps: First, the image is separated into a texture component + a color component, then the details of the texture component only are enhanced before the image is recomposed. This approach makes it possible to highlight all the small details of an image, while minimizing the undesired halos near the contours, a recurring problem happening with more classical sharpening methods (such as the well known Unsharp Mask).

4.3. Masking by color

As you may know, a lot of photograph retouching techniques require the creation of one or several “masks”, that is, the isolation of specific areas of an image to receive differentiated processing. For example, the very common technique of luminosity masks is a way to treat differently shadows and highlights in an image. G’MIC 2.0 introduces a new interesting filter “Colors / Color mask [interactive]“ that implements a relatively sophisticated algorithm (albeit computationally demanding) to help creating complex masks. This filter asks the user to hover the mouse over a few pixels that are representative of the region to keep. The algorithm learns in real time the corresponding set of colors or luminosities and deduces then the set of pixels that composes the mask for the whole image (using Principal Component Analysis on the RGB samples).

Once the mask has been generated by the filter, the user can easily modify the corresponding pixels with any type of processing. The example below illustrates the use of this filter to drastically change the color of a car

It takes no more than a minute and a half to complete, as shown in the video below:

This other video exposes an identical technique to change the color of the sky in a landscape.

5. And for the others…

Since illustrators and photographers are now satisfied, let’s move on to some more exotic filters, recently added to G’MIC, with interesting outcomes!

5.1. Average and median of a series of images

Have you ever wondered how to easily estimate the average or median frame of a sequence of input images? The libre aficionado Pat David, creator of the site pixls.us often asked the question. First of all when he tried to denoise images by combining several shots of a same scene. Then he wanted to simulate a longer exposure time by averaging photographs taken successively. And finally, calculating averages of various kind of images for artistic purposes (for example, frames of music video clips, covers of Playboy magazine or celebrity portraits).

Hence, with his cooperation, we added new commands -median_files,-median_videos, -average_files and-average_videos to compute all these image features very easily using the CLI tool gmic. The example below shows the results obtained from a sub-sequence of the « Big Buck Bunny“ video. We have simply invoked the following commands from the Bash shell:

$ gmic -average_video bigbuckbunny.mp4 -normalize 0.255 -o average.jpg
$ gmic -median_video bigbuckbunny.mp4 -normalize 0.255 -o median.jpg

And to stay in the field of video processing, we can also mention the addition of the commands -morph_files and -morph_video that render temporal interpolations of video sequences, taking the estimated intra-frame object motion into account, thanks to a quite smart variational and multi-scale estimation algorithm.

The video below illustrates the rendering difference obtained for the retiming of a sequence using temporal interpolation, with (right) and without (left) motion estimation.

5.2. Deformations and “Glitch Art”

Those who like to mistreat their images aggressively will be delighted to learn that a bunch of new image deformation and degradation effects have appeared in G’MIC.

First of all, the filter “Deformations / Conformal maps“ allows one to distort an image using conformal maps. These deformations have the property of preserving the angles locally, and are most often expressed as functions of complex numbers. In addition to playing with predefined deformations, this filter allows budding mathematicians to experiment with their own complex formulas.

Fans of Glitch Art may also be concerned by several new filters whose rendering look like image encoding or compression artifacts. The effect “Degradations / Pixel sort“ sorts the pixels of a picture by row or by column according to different criteria and to possibly masked regions, as initially described on this page.

Degradations / /Pixel sort also has two little brothers, filters “Degradations / Flip & rotate blocks“ and “Degradations / Warp by intensity“. The first divides an image into blocks and allows to rotate or mirror them, potentially only for certain color characteristics (like hue or saturation, for instance).

The second locally deforms an image with more or less amplitude, according to its local geometry. Here again, this can lead to the generation of very strange images.

It should be noted that these filters were largely inspired by the Polyglitch plug-in, available for Paint.NET, and have been implemented after a suggestion from a friendly user (yes, yes, we try to listen to our most friendly users!).

5.3. Image simplification

What else do we have in store? A new image abstraction filter, Artistic / Sharp abstract, based on the Rolling Guidance algorithm mentioned before. This filter applies contour-preserving smoothing to an image, and its main consequence is to remove the texture. The figure below illustrates its use to generate several levels of abstraction of the same input image, at different smoothing scales.

In the same vein, G’MIC also gets a filter Artistic / Posterize which degrades an image to simulate posterization. Unlike the filter with same name available by default in GIMP (which mainly tries to reduce the number of colors, i.e. do color quantization), our version adds spatial simplification and filtering to approach a little more the rendering of old posters.

5.4. Other filters

If you still want more (and in this case one could say you are damn greedy!), we will end this section by discussing some of the new, but unclassifiable filters.

We start with the filter “Artistic / Diffusion tensors“, which displays a field of diffusion tensors, calculated from the structure tensors of an image (structure tensors are symmetric and positive definite matrices, classically used for estimating the local image geometry). To be quite honest, this feature had not been originally developed for an artistic purpose, but users of the plug-in came across it by chance and asked to make a GIMP filter from it. And yes, this is finally quite pretty, isn’t it?

From a technical point of view, this filter was actually an opportunity to introduce new drawing features into the G’MIC mathematical evaluator, and it has now become quite easy to develop G’MIC scripts for rendering custom visualizations of various image data. This is what has been done for instance, with the command -display_quiver reimplemented from scratch, and which allows to generate this type of rendering:

For lovers of textures, we can mention the apparition of two new fun effects: First, the “Patterns / Camouflage“ filter. As its name suggests, this filter produces a military camouflage texture.

Second, the filter “Patterns / Crystal background“ overlays several randomly colored polygons in order to synthesize a texture that vaguely looks like a crystal seen under a microscope. Pretty useful to quickly render colored image backgrounds.

And to end this long overview of new G’MIC filters developed since last year, let us mention “Rendering / Barnsley fern“. This filter renders the well-known Barnsley fern fractal. For curious people, note that the related algorithm is available on Rosetta Code, with even a code version written in the G’MIC script language, namely:

# Put this into a new file 'fern.gmic' and invoke it from the command line, like this:
# $ gmic fern.gmic -barnsley_fern
barnsley_fern :
  1024,2048
  -skip {"
      f1 = [ 0,0,0,0.16 ];           g1 = [ 0,0 ];
      f2 = [ 0.2,-0.26,0.23,0.22 ];  g2 = [ 0,1.6 ];
      f3 = [ -0.15,0.28,0.26,0.24 ]; g3 = [ 0,0.44 ];
      f4 = [ 0.85,0.04,-0.04,0.85 ]; g4 = [ 0,1.6 ];
      xy = [ 0,0 ];
      for (n = 0, n<2e6, ++n,
        r = u(100);
        xy = r<=1?((f1**xy)+=g1):
             r<=8?((f2**xy)+=g2):
             r<=15?((f3**xy)+=g3):
                   ((f4**xy)+=g4);
        uv = xy*200 + [ 480,0 ];
        uv[1] = h - uv[1];
        I(uv) = 0.7*I(uv) + 0.3*255;
      )"}
  -r 40%,40%,1,1,2

And here is the rendering generated by this function:

6. Overall project improvements

All filters presented throughout this article constitute only the visible part of the G’MIC iceberg. They are in fact the result of many developments and improvements made “under the hood”, i.e., directly on the code of the G’MIC script language interpreter. This interpreter defines the basic language used to write all G’MIC filters and commands available to users. Over the past year, a lot of work has been done to improve the performances and the capabilities of this interpreter:

• The mathematical expressions evaluator has been considerably enriched and optimized, with more functions available (especially for matrix calculus), the support of strings, the introduction of const variables for faster evaluation, the ability to write variadic macros, to allocate dynamic buffers, and so on.

• New optimizations have been also introduced in the CImg library, including the parallelization of new functions (via the use of OpenMP). This C++ library provides the implementations of the “critical” image processing algorithms and its optimization has a direct impact on the performance of G’MIC (in this respect, note that CImg is also released with a major version 2.0).

• Compiling G’MIC on Windows now uses a more recent version of g++ (6.2 rather than 4.5), with the help of Sylvie Alexandre. This has actually a huge impact on the performances of the compiled executables: some filters run up to 60 times faster than with the previous binaries (this is the case for example, with the Deformations / Conformal Maps filter, discussed in section 5.2).

• The support of large .tiff images (format BigTIFF, with files that can be larger than 4Gb) is now enabled (read and write), as it is for 64-bit floating-point TIFF images

• The 3D rendering engine built into G’MIC has also been slightly improved, with the support for bump mapping. No filter currently uses this feature, but we never know, and prepare ourselves for the future!

• And as it is always good to relax after a hard day’s work, we added the game of Connect Four to G’MIC :). It can be launched via the shell command $ gmic -x_connect4 or via the plug-in filter “Various / Games & demos / Connect-4“. Note that it is even possible to play against the computer, which has a decent but not unbeatable skill (the very simple _AI_ uses the Minimax algorithm with a two-level decision tree).

Finally, let us mention the undergoing redesign work of the G’MIC Online web service, with a beta version already available for testing. This re-development of the site, done by Christophe Couronne and Véronique Robert (both members of the GREYC laboratory), has been designed to better adapt to mobile devices. The first tests are more than encouraging. Feel free to experiment and share your impressions!

7. What to remember?

First, the version 2.0 of G’MIC is clearly an important step in the project life, and the recent improvements are promising for the future developments. It seems that the number of users are increasing (and they are apparently satisfied!), and we hope that this will encourage open-source software developers to integrate our new G’MIC-Qt interface as a plug-in for their own software. In particular, we are hopeful to see the new G’MIC in action under Krita soon, this would be already a great step!

Second, G’MIC continues to be an active project, and evolve through meetings and discussions with members of artists and photographers communities (particularly those who populate the forums and IRC of pixls.us and GimpChat). You will likely able to find us there if you need more information, or just if you want to discuss things related to (open-source) image processing.

And while waiting for a future hypothetical article about a future release of G’MIC, you can always follow the day-after-day progress of the project via our Twitter feed.

Until then, long live open-source image processing!

Credit: Unless explicitly stated, the various non-synthetic images that illustrate this post come from Pixabay.

Happy 2nd Birthday Discuss

Time keeps on slippin'

I was idling in our IRC chat room earlier when @Morgan_Hardwood wished us all a “Happy Discuss Anniversary”. Wouldn’t you know it, another year slipped right by! (Surely there’s no way it could already be a year since the last birthday post? Where does the time go?)

We’ve had a bunch of neat things happen in the community over the past year! Let’s look at some of the highlights.

Support

I want to start with this topic because it’s the perfect opportunity to recognize some folks who have been supporting the community financially…

When I started all of this I decided that I definitely didn’t want ads to be on the site anywhere. I had gotten enough donations from my old blog and GIMP tutorials that I could cover costs for a while entirely from those funds (I also re-did my personal blog recently and removed all ads from there as well).

I don’t like ads. You don’t like ads. We’re a big enough community that we can keep things going without having to bring those crappy things into our lives. So to reiterate, we’re not going to run ads on the site.

We are hosting the main website on Stablehost, the forums (discuss) are on a VPS at Digital Ocean, and our file storage for discuss is out on Amazon S3(see below). All told our costs are about $30 per month. Not so bad!

Thank You!

Even so, we have had some folks who have donated to help us offset these costs and I want to take a moment to recognize their generosity and graciousness!

Dimitrios Psychogios has been a supporter of the site since the beginning. This past year he covered (more than) our hosting costs for the entire year, and for that I am infinitely grateful (yes, I have infinite gratitude). It also helps that based on his postings on G+ our musical tastes are very similarly aligned. As soon as I get the supporters page up you’re going to the top of the list! Thank you, Dimitrios, for your support of the community!

Jonas Wagner (@Jonas_Wagner) and McCap (@McCap) both donated this past year as well. Which is doubly-awesome because they are both active in the community and have written some great content for everyone as well (@McCap is the author of the article A Masashi Wakui look with GIMP, and has been active in the community since the beginning as well).

Mica (@paperdigits) and Luka are both recurring donators which I am particularly grateful for. It really helps for planning to know we have some recurring support like that.

I have a bunch of donations where the donators didn’t leave me a name to use for attribution and I don’t want to just assume it’s ok. If you know you donated and see your first name in the list below (and are ok with me using your full name and a link if you want) then please let me know and I’ll update this post (and for the donators page later).

These are the folks who are really making a difference by taking the time and being gracious enough to support us. Even if you don’t want your full name out here, I know who you are and am very, very grateful and humbled by your generosity and kindness. Thank you all so much!

• Marc W. (you rock!)
• Ulrich P.
• Luc V.
• Ben E.
• Keith A.
• Philipp H.
• Christian M.
• Matthieu M.
• Christian M.
• Christian K.
• Maria J.
• Kevin P.
• Maciej D.
• Christian K.
• Egbert G.
• Michael H.
• Jörn H.
• Boris H.
• Norman S.
• David O.
• Walfrido C.
• Philip S.
• David S.
• Keith B.
• Andrea V.
• Stephan R.
• David M.
• Bastian H.
• Chance J.
• Luka S.
• Nathanael S.
• Sven K.
• Pepijn V.
• Benjamin W.
• Jörg W.
• Patrick B.
• Joop K.
• Alain V.
• Egor S.
• Samuel S.

On that note. If anyone wanted to join the folks above in supporting what we’re up to, we have a page specifically for that:

https://pixls.us/support/

Remember, no amount is too small!

Libre Graphics Meeting Rio

I wasn’t able to attend LGM this year, being held down in Rio (but the GIMP team did). That’s not to say that we didn’t have folks from the community there: Farid (@frd) from Estúdio Gunga was there!

I was able to help coordinate a presentation by Robin Mills (@clanmills) about the state (and future) of Exiv2. They’re looking for a maintainer to join the project, as Robin will be stepping down at the end of the year for studies. If you think you’d be interested in helping out, please get in touch with Robin on the forums and let him know!

I also put together (quickly) a few slides on the community that were included in the “State of the Libre Graphics” presentation that kicks off the meeting (presented this year by GIMPer Simon Budig):

This was just a short overview of the community and I think it makes sense to include it here was well. Since we stood the forum up two years ago we’ve seen about 3.2 million pageviews and have just under 1,400 users in the community. Which is just awesome to me.

@LebedevRI was also going to be mad if I didn’t take the time to at least let folks know about raw.pixls.us, where we currently have 693 raw files across 477 cameras. Please, take a moment to check raw.pixls.us and see if we are missing (or need better) files from a camera you may have, and get us samples for testing!

raw.pixls.us

We set up raw.pixls.us so we can gather camera raw samples for regression testing of rawspeed as well to have a place for any other project that might need raw files to test with. As we blogged about previously, the new site is also a replacement for the now defunct rawsamples.ch website.

Stop in and see if we’re missing a sample you can provide, or if you can provide a better (or better licensed) version for your camera. We’re focusing specifically on CC0 contributions.

Welcome digiKam!

As I mentioned in my last blog post, we learned that the digiKam team was looking for a new webmaster through a post on discuss. @Andrius posted a heads up on the digiKam 5.5.0 release in this thread.

Needless to say, less than a month or so later, @paperdigits had already finished up a nice new website for them! This is something we’re really trying to help out the community with and are super glad to be able to help out the digiKam team with this. The less time they have to worry about web infrastructure and security for it, the more time they can spend on awesome new features for their project and users.

Yes, we used a static site generator (Hugo in this case), and we were also able to move their commenting system to use discuss as its back-end! This is the same way we’re doing comments for PIXLS.US right now (scroll to the bottom of this post).

They’ve got their own category on discuss for both general digiKam discussion as well as their linked comments from their website.

Speaking of using discourse as a commenting system…

Discourse upstream

We’ve been using discourse as our forum software from the beginning. It’s a modern, open, and full-featured forum software that I think works incredibly well as a modern web application.

The ability to embed comments in a website that are part of the forum was one of the main reasons I went with it. I didn’t want to expose users to unnecessary privacy concerns by embedding a third-party commenting system (cough, disqus, cough). If I was going to go through the trouble of setting up a way to comment on things, I wanted to homogenize it with a full community-building effort.

This past year they (the discourse devs) added the ability to embed comments in multiple hosts (it was only one host when we first stood things up). This means that we can now manage the comments for anyone else thay may need them! Of course, building out a new website for digiKam meant that this was a perfect time to test things.

It all works beautifully, with one minor nitpick. The ability to style the embedded comments was limited to a single style for all the places that they might be embedded. This may be fine if all of the sites look similar, but if you visit www.digikam.org and compare it to here, you can see they are a little bit different… (we’re on white, digikam.org is on a dark background).

We needed a way to isolate the styling on a per-host basis, which after much help from @darix (yet again :)) I was able to finally hack something together that worked and get it pushed upstream (and merged finally)!

Play Raw

When RawTherapee migrated their official forums over to pixls they brought something really fun with them: Play Raw. They would share a single raw file amongst the community and then have everyone process and share their results (including their processing steps and associated .pp3 settings file).

If you haven’t seen it yet, we’ve had quite a few Play Raw posts over the past year with all sorts of wonderful images to practice on and share! There are portraits, children, dogs, cats, landscapes, HDR, and phở! There’s over 19 different raw files being shared right now, so come try your hand at processing (or even share a file of your own)!

The full list of play_raw posts can always be found here:
https://discuss.pixls.us/tags/play_raw

Amazon S3

We are a photography forum, so it only made sense that we made it as easy as possible for community members to upload and share images (raw files, and more). It’s one of the things I love about discourse that it’s so easy to add these things to your posts (simply drag-and-drop into the post editor) and upload them.

While this is easy to do, it does mean that we have to store all of this data. The VPS we use from Digital Ocean only has a 40GB SSD and it has to include all of the main forum running on it. We did have a little space for a while, but to help alleviate the local storage as a possible problem down the line, I moved our file storage out to Amazon S3.

This means that we can upload all we want and won’t really hit a wall with actual available storage space. It costs more each month than trying to store it all on local storage for the site, but then we don’t have to worry about expansion (or migration) later. Plus our current upload size limit per file is 100MB!

As you can see, we’re only looking at about $5USD/month on average in storage and transfer costs for the site with Amazon.

We’re also averaging about $22usd/month in hosting costs with Digital Ocean, so we’re still only about $27/month in total hosting costs. Maybe $30 if we include the hosting for the main website which is at Stablehost.

IRC

We’ve had an IRC room for a long time (longer than discuss I think), but I only just got around to including a link on the site for folks to be able to join through a nice web client (Kiwi IRC).

It was included as part of an oft-requested set of links to get back to various parts of the main site from the forums. I also added these links in the menu for the site as well (the header links are hidden when on mobile, so this way you can still access the links from whatever device you’re using):

If you have your own IRC client then you can reach us on irc.freenode.net #pixls.us. Come and join us in the chat room! If you’re not there you are definitely missing out on a ton of stimulating conversation and enlightening discussions!

Welcome digiKam!

Lending a helping hand

One of the goals we have here at PIXLS.US is to help Free Software projects however we can, and one of those ways is to focus on things that we can do well that might help make things easier for the projects. It may not be much fun for project developers to deal with websites or community outreach necessarily. This is something I think we can help with, and recently we had an opportunity to do just that with the awesome folks over at the photo management project digiKam.

As part of a post announcing the release of digiKam 5.5.0 on discuss. we learned that they were in need of a new webmaster, and they needed something soon to migrate away from Drupal 6 for security reasons. They had a rudimentary Drupal 7 theme setup, but it was severely lacking (non-responsive and not adapted to the existing content).

Mica (@paperdigits) reached out to Gilles Caulier and the digiKam community and offered our help, which they accepted! At that point Mica gathered requirements from them and found in the end that a static website would be more than sufficient for their needs. We coordinated with the KDE folks to get a git repo setup for the new website, and rolled up our sleeves to start building!

Mica chose to use the Hugo static-site generator to build the site with. This was something new for us, but turned out to be quite fast and fun to work with (it generates the entire digiKam site in just about 5 seconds). Coupled with a version of the Foundation 6 blog theme we were able to get a base site framework up and running fairly quickly. We scraped all of the old site content to make sure that we could port everything as well as make sure we didn’t break any urls along the way.

We iterated some design stuff along the way, ported all of the old posts to markdown files, hacked at the theme a bit, and finally included comments that are now hosted on discuss. What’s wild is that we managed to pull the entire thing together in about 6 weeks total (of part-time working on it). The digiKam team seems happy with the results so far, and we’re looking forward to continue helping them by managing this infrastructure for them.

A big kudos to Mica for driving the new site and getting everything up and running. This was really all due to his hard work and drive.

Also, speaking of discuss, we also have a new category created specifically for digiKam users and hackers: https://discuss.pixls.us/c/software/digikam.

This is the same category that news posts from the website will post in, so feel free to drop in and say hello or share some neat things you may be working on with digiKam!

GIMP is Going to LGM!

Tall and tan and young and lovely...

This years Libre Graphics Meeting (2017) is going to be held in the lovely city seen above, Rio de Janeiro, Brazil! This is an important meeting for so many people in the Free/Libre art community as it’s one of the only times they have an opportunity to meet face to face.

We’ve had some folks attending the past LGM’s (Leipzig and London) and it’s a wonderful opportunity to spend some time with friends. (Also, @frd from the community will be there!)

So in the spirit of camaraderie, I have a request…

Donate

The GIMP team will be in attendance this year. I happen to have a fondness for them so I’m asking anyone reading this to please head over and donate to the project.

That link is for the GNOME PayPal account, but there are other ways to donate as well.

This is one of the few times that the GIMP team gets a chance to meet in person. They use the time to hack at GIMP and to manage internal business. The time they get to spend together is invaluable to the project and by extension everyone that uses GIMP.

Just look at these faces! Surely this (Brady) Bunch of folks is worth helping to get a better GIMP?

Attending

Besides @frd I’m not sure who else from the community might be attending, so if I’ve missed you I apologize! Please feel free to use this topic to communicate and coordinate if you’d like.

It appears that personally I’m on a biennial schedule with attending LGM - so I’m looking forward to next year to be able to catch up with everyone!

RawTherapee and Pentax Pixel Shift

Supporting multi-file raw formats

What is Pixel Shift?

Modern digital sensors (with a few exceptions) use an arrangement of RGB filters over a square grid of photosites. For a given 2x2 square of photosites the filters are designed to allow two green, and one each red and blue colors through to the photosite. These are arranged on a grid:

The pattern is known as a Bayer pattern (after the creator Bryce Bayer of Eastman Kodak). The resulting pattern shows how each RGB is offset into the grid.

Each of the pixel sites captures a single color. In order to produce a full color representation at each pixel, the other color values need to be interpolated from the surrounding grid. This interpolation and methods for calculating it are referred to as demosaicing. The methods for accomplishing this vary across different algorithms.

Unfortunately, this can often result in problems. There can be chromatic aliasing problems resulting in odd color fringing and roughness on edges or a loss of detail and sharpness.

Pixel Shift

Pentax‘s Pixel Shift (Available on the K-1, K-3 II, KP, K-70) attempts to alleviate some of these problems through a novel approach of capturing four images quickly in succession and by moving the entire camera sensor a single pixel for each shot. This has the effect of capturing a full RGB value at each pixel location:

This means a full RGB value for a pixel location can be created without having to interpolate from neighboring values.

Advantages

Less Noise

If you look carefully at the Bayer pattern, you’ll notice that when shifting to adjacent pixels there will always be two green values captured per pixel. The average of these green values helps to suppress noise that may have been interpolated and spread through a normal, single-shot raw file.

Less Moiré

Avoiding the interpolation of pixel colors from surrounding photosites helps to reduce the appearance of Moiré in the final result:

Increased Resolution

This method is similar in concept to what was previously seen when Olympus announced their “High Resolution” mode for the OMD E-M5mkII camera (or manually as we previously described in this blog post). In that case they combine 8 frames moved by sub-pixel amounts to increase the overall resolution. The difference here is that Olympus generates a single, combined raw file from the results, while Pixel Shift gets you access to each of the four raw files before they’re combined.

In each case, a higher resolution image can be created from the results:

Disadvantages

Movement

As with most approaches for capturing multiple images and combining them, a particularly problematic area is when there are objects in motion between the frames being captured. This is a common problem when stitching panoramic photography, when creating image stacks for noise reduction, and when combining images using methods such as Pixel Shift.

Although…

The RawTherapee Approach

Simply combining four static frames together is really trivial, and is something that all the other Pixel Shift-capable software can do without issue. The real world is not often so accommodating as a studio setup, and that is where the recent work done by @Ingo and @Ilias on RawTherapee really begins to shine.

What they’ve been working on in RawTherapee is to improve the detection of movement in a scene. There are several types of movement possible:

• Objects showing at different places in a scene such as fast moving cars.
• Partly moving objects like foliage in the wind.
• Moving objects reflecting light onto static objects in the scene
• Changing illumination conditions such as long exposures at sunset.

All of these types of movement need to be detected to avoid the artifacts they may cause in the final shot.

One of the key features of Pixel Shift movement detection in RawTherapee is that it allows you to show the movement mask, so you get feedback on which regions of the image are detected as movement and which are static. For the regions with movement RawTherapee will then use the demosaiced frame of your choice to fill it in, and for regions without movement it will use the Pixel Shift combined image with more detail and less noise.

The accuracy of movement detection in RawTherapee leads to much better handling of motion artifacts that works well in places where proprietary solutions fall short. For most cases the Automatic motion correction mode works well, but you can also fine tune the parameters in custom mode to correctly detect motion in high ISO shots.

Besides being the only option (barring dcrawps possibly) to process Pixel Shift files in Linux, RawTherapee has some other neat options that aren’t found in other solutions. One of them is the ability to export the actual movement mask separate from the image. This will let users generate separate outputs from RT, and to combine them later using the movement mask. Another option is the ability to choose which of the other frames to use for filling in the movement areas on the image.

Pixel Shift Support in Other Software

Pentax’s own Digital Camera Utility (a rebranded version of SilkyPix) naturally supports Pixel Shift, but as with most vendor-bundled software it can be slow, unwieldy, and a little buggy sometimes. Having said that, the results do look good, and at least the “Motion Correction” is able to be utilized with this software.

Adobe Camera Raw (ACR) got support for Pixel Shift files in version 9.5.1 (but doesn’t utilize the “Motion Correction”). In fact, ACR didn’t have support at the time that DPReview.com looked at the feature last year, causing them to retract the article and re-post when they had a chance to use a version of ACR with support.

A recent look at Pixel Shift processing over at DPReview.com showed some interesting results.

We’re going to look at some 100% crops from that article and compare them to the results available using RawTherapee (the latest development version, to be released as 5.1 in April). The RawTherapee versions were set to the most neutral settings with only an exposure adjustment to match other samples better.

Looking first at an area of foliage with motion, the places where there are issues becomes apparent.

For reference, here is the Adobe Camera Raw (ACR) version of a single frame from a Pixel Shift file:

The results with Pixel Shift on, and motion correction on, from straight-out-of-camera (SOOC), Adobe Camera Raw (ACR), SilkyPix, and RawTherapee (RT) are decidedly mixed. In all but the RT version, there’s a very clear problem with effective blending and masking of the frames in areas with motion:

Things look much worse for Adobe Camera Raw when looking at high-motion areas like the water spray at the foot of the waterfall, though SilkyPix does a much better job here.

The ACR version of a single frame for reference:

Both the SOOC and SilkyPix versions handle all of the movement well here. RawTherapee also does a great job blending the frames despite all of the movement. Adobe Camera Raw is not doing well at all…

Finally, in a frame full of movement, such as the surface of the water.

The ACR version of a single frame for reference:

In a frame full of movement the SOOC, ACR, and SilkyPix processing all struggle to combine a clean set of frames. They exhibit a pixel pattern from the processing, and the ACR version begins to introduce odd colors:

As mentioned earlier, a unique feature of RawTherapee is the ability to show the motion mask. Here is an example of the motion mask for this image

Also worth mentioning is the “Smooth Transitions” feature in RawTherapee. When there are regions with and without motion, the regions with motion are masked and filled in with data from a demosaiced frame of your choice. The other regions are taken from the Pixel Shift combined image. This can occasionally lead to harsh transitions between the two.

For instance, a transition as processed in SilkyPix:

RawTherapee’s “Smooth Transitions” feature does a much better job handling the transition:

In Conclusion

In another example of the power and community of Free/Libre and Open Source Software we have a great enhancement to a project based on feedback and input from the users. In this case, it all started with a post on the RawTherapee forums.

Thanks to the hard work of @Ingo and @Ilias Pentax shooters now have a Pixel Shift capable software that is not only FLOSS but also produces better results than the proprietary solutions!

Not so coincidentally, community member @nosle gave permission to use one of his PS files for everyone to try processing on the Play pixelshift thread. If you’d like to practice consider heading over to get his file and feedback from others!

Pixel Shift is currently in the development branch of RawTherapee and is slated for release with version 5.1.

Find us at SCaLE 15x

The Southern California Linux Expo (SCaLE) 15x is returning to the Pasadena Convention Center on March 2-5, 2017. SCaLE is one of the largest community-organized conferences in North America, with some 3,500 attendees last year.

If you’re attending the conference this year, find me, @paperdigits and lets talk shop or grab a meal!

From the Community Vol. 2

Welcome to the second installment of From the Community, a (hopefully) quarterly-ish blog post to highlight a few of the things our community members have been doing!

Improving grain simulation

@arctic has posted some research about how to better simulate grain in our digital images and the ensuing conversation is both fascinating and way above my head! This discussion is thus far raw processor independent and more input and code is welcome!

A tutorial on RBG color mixing

We’ve somewhat recently welcomed the painters into the fold on the pixls’ forum and @Elle rewarded us all with a tutorial RGB color mixing. She delves into subjects such as mixing color pigments like a traditional painter and how to handle that in the digital darkroom. You can read the whole article here.

Working to support Pentax Pixel Shift files in RawTherapee

There has been a lot of on-going work to bring support for Pentax Pixel Shift files in RawTherapee; the thread has now reached 234 posts and it is inspiring to see the community and developers coming together to bring support for an interesting technology. The feature set has been evolving pretty rapidly and it will be exiting when it makes it to a stable release.

Midi controller support for Darktable

Some preliminary work has begun to bring generic midi controller support to darktable. The funding for the midi controller to spur the development of this feature is a direct result of the members of the forum directly giving to further community causes. Once the darktable developers are finished with the midi controller, it’ll be offered to other developers to use to help implement support!

Methods for dealing with clipped highlights

@Morgan_Hardwood has written a very nice post detailing several methods for dealing with clipped highlights in RawTherapee. These include tone-mapping, highlights and shadows, and using the CIECAM02 mode.

New Year, New Raw Samples Website

A replacement for rawsamples.ch

Happy New Year, and I hope everyone has had a wonderful holiday!

We’ve been busy working on various things ourselves, including migrating RawPedia to a new server as well as building a replacement raw sample database/website to alleviate the problems that rawsamples.ch was having…

rawsamples.ch Replacement

Rawsamples.ch is a website with the goal to:

…provide RAW-Files of nearly all available Digitalcameras mainly to software-developers. [sic]

It was created by Jakob Rohrbach and had been running since March 2007, having amassed over 360 raw files in that time from various manufacturers and cameras. Unfortunately, back in 2016 the site was hit with a SQL-injection that ended up corrupting the database for the Joomla install that hosted the site. To compound the pain, there were no database backups… :(

On the good side, the PIXLS.US community has some dangerous folks with idle hands. Our friendly, neighborhood @andabata (Kees Guequierre) had some time off at the end of the year and a desire to build something. You may know @andabata as the fellow responsible for the super-useful dtstyle website, which is chock full of darktable styles to peruse and download (if you haven’t heard of it before – you’re welcome!). He’s also my go-to for macro photography and is responsible for this awesome image used on a slide for the Libre Graphics Meeting:

Luckily, he decided to build a site where contributors could upload sample raw files from their cameras for everyone to use – particularly developers. We downloaded the archive of the raw files kept at rawsamples.ch to include with files that we already had. The biggest difference between the files from rawsamples.ch and raw.pixls.us is the licensing. The existing files, and the preference for any new contributions, are licensed as Creative Commons Zero - Public Domain (as opposed to CC-BY-NC-SA).

After some hacking, with input and guidance from darktable developer Roman Lebedev, the site was finally ready. The repository for it can be found on GitHub: raw.pixls.us repo.

raw.pixls.us

The site is now live at https://raw.pixls.us.

You can look at the submitted files and search/sort through all of them (and download the ones you want).

In addition to browsing the archive, it would be fantastic if you were able to supplement the database by uploading sample images. Many of the files from the rawsamples.ch archive are licensed CC-BY-NC-SA, but we’d rather have the files licensed Creative Commons Zero - Public Domain. CC0 is preferable because if the sample raw files are separated from the database, they can safely be redistributed without attribution. So if you have a camera that is already in the list with the more restrictive license, then please consider uploading a replacement for us!

We are looking for shots that are:

• Lens mounted on the camera
• Lens cap off
• In focus
• Properly exposed (not over/under)
• Landscape orientation
• Licensed under the Creative Commons Zero

We are not looking for:

• Series of images with different ISO, aperture, shutter, wb, or lighting
  (Even if it’s a shot of a color target)
• DNG files created with Adobe DNG Converter

Please take a moment and see if you can provide samples to help the developers!

Welcome Digital Painters

You mean there's art outside photography?

Yes, there really is art outside photography. :)

The history and evolution of painting has undergone a similar transformation as most things adapting to a digital age. As photographers, we adapted techniques and tools commonly used in the darkroom to software, and found new ways to extend what was possible to help us achieve a vision. Just as we tried to adapt skills to a new environment, so too did traditional artists, like painters.

These artists adapted by not only emulating the results of various techniques, but by pushing forward the boundaries of what was possible through these new (Free Software) tools.

Impetus

Digital painting discussions with Free Software lacks a good outlet for collaboration that can open the discussion for others to learn from and participate in. This is a similar situation the Free Software + photography world was in that prompted the creation of pixls.us.

Due to this, both Americo Gobbo and Elle Stone reached out to us to see if we could create a new category in the community about Digital Painting with a focus on promoting serious discussion around techniques, processes, and associated tools.

Both of them have been working hard on advancing the capabilities and quality of various Free Software tools for years now. Americo brings with him the interest of other painters who want to help accelerate the growth and adoption of Free Software projects for painting (and more) in a high-quality and professional capacity. A little background about them:

Americo Gobbo studied Fine Arts in Bologna, Italy. Today he lives and works in Brazil, where he continues to develop studies and create experimentation with painting and drawing mainly within the digital medium in which he tries to replicate the traditional effects and techniques from the real world to the virtual.

Elle Stone is an amateur photographer with a long-standing interest in the history of photography and print making, and in combining painting and photography. She’s been contributing to GIMP development since 2012, mostly in the areas of color management and proper color mixing and blending.

Artists

With this introductory post to the new Digital painting category forum we feature Gustavo Deveze, who is a Visual Artist using free software. Deveze’s work is characterized by mixing different medias and techniques. With future posts we want to continue featuring artists using free software.

Gustavo Deveze

Gustavo Deveze is a visual artist and lives in Buenos Aires. He trained as a draftsman at the National School of Fine Arts “Manuel Belgrano”, and filmmaker at IDAC - Instituto de Arte Cinematográfica in Avellaneda, Argentina.

His works utilize different materials and supports and he is published by different publishers. Although in the last years he works mainly in digital format and with free software. He has participated in national and international shows and exhibitions of graphics and cinema with many awards. His last exposition can be seen on issuu.com: https://issuu.com/gustavodeveze/docs/inadecuado2edicion

Website: http://www.deveze.com.ar

• Blog: http://jeneverito.blogspot.com.ar/
• Google+: https://plus.google.com/107589083968107443043
• Facebook: https://www.facebook.com/gustavo.deveze

Digital Painting Category

The new Digital Painting category is for discussing painting techniques, processes, and associated tools in a digital environment using Free/Libre software. Some relevant topics might include:

• Emulating non-digital art, drawing on diverse historical and cultural genres and styles of art.

• Emulating traditional “wet darkroom” photography, drawing on the rich history of photographic and printmaking techniques.

• Exploring ways of making images that were difficult or impossible before the advent of new algorithms and fast computers to run them on, including averaging over large collections of images.

• Discussion of topics that transcend “just photography” or “just painting”, such as composition, creating a sense of volume or distance, depicting or emphasizing light and shadow, color mixing, color management, and so forth.

• Combining painting and photography: Long before digital image editing artists already used photographs as aids to and part of making paintings and illustrations, and photographers incorporated painting techniques into their photographic processing and printmaking.

• An important goal is also to encourage artists to submit tutorials and videos about Digital Painting with Free Software and to also submit high-quality finished works.

Say Hello!

Please feel free to stop into the new [Digital Painting category][dp-forum], introduce yourself, and say hello! I look forward to seeing what our fellow artists are up to.

All images not otherwise specified are licensed [CC-BY-NC-SA][] [CC-BY-NC-SA]: https://creativecommons.org/licenses/by-nc-sa/4.0/ [dp-forum]: https://discuss.pixls.us/c/digital-painting

A Masashi Wakui look with GIMP

A color bloom fit for night urban landscapes

This tutorial explains how to achieve an effect based on the post processing by photographer Masashi Wakui. His primary subjects appear as urban landscape views of Japan where he uses some pretty and aggressive color toning to complement his scenes along with a soft ‘bloom’ effect on the highlights. The results evoke a strong feeling of an almost cyberpunk or futuristic aesthetic (particularly for fans of Bladerunner or Akira!).

This tutorial started its life in the pixls.us forum, which was inspired by a forum post seeking assistance on replicating the color grading and overall look/feel of Masashi’s photography.

Prerequisites

To follow along will require a couple of plugins for GIMP.

The Luminosity Mask filter will be used to target color grading to specific tones. You can find out more about luminosity masks in GIMP at Pat David’s blog post and his follow-up blog post. If you need to install the script, directions can be found (along with the scripts) at the PIXLS.US GIMP scripts git repository.

You will also need the Wavelet decompose plugin. The easiest way to get this plugin is to use the one available in G’MIC. As a bonus you’ll get access to many other incredible filters as well! Once you’ve installed G’MIC the filter can be found under
Details → Split details [wavelets].

We will do some basic toning and then apply Gimp’s wavelet decompose filter to do some magic. Two things will be used from the wavelet decompose results:

• the residual
• the coarsest wavelet scale (number 8 in this case)

The basic idea is to use the residual of the the wavelet decompose filter to color the image. What this does is average and blur the colors. The trick strengthens the effect of the surroundings being colored by the lights. The number of wavelet scales to use depends on the pixel size of the picture; the relative size of the coarsest wavelet scale compared to the picture is the defining parameter. The wavelet scale 8 will then produce overemphasised local contrasts, which will accentuate the lights further. This works nicely in pictures with lights as the brightest areas will be around lights. Used on daytime picture this effect will also accentuate brighter areas which will lead to a kind of “glow” effect. I tried this as well and it does look good on some pictures while on others it looks just wrong. Try it!

We will be applying all the following steps to this picture, taken in Akihabara, Tokyo.

1. Apply the luminosity mask filter to the base picture. We will use this later.

   Filters → Generic → Luminosity Masks

2. Duplicate the base picture (Ctrl+Shift+D).

   Layer → Duplicate Layer

3. Tone the shadows of the duplicated picture using the tone curve by lowering the reds in the shadows. If you want your shadows to be less green, slightly raise the blues in the shadows.

   Colors → Curves

   

   

4. Apply a layer mask to the duplicated and toned picture. Choose the DD luminosity mask from a channel.

   Layer → Mask → Add Layer Mask

   

5. With both layers visible, create a new layer from what is visible. Call this layer the “blended” layer.

   Layer → New from Visible

   

6. Apply the wavelet decompose filter to the “blended” layer and choose 9 as number of detail scales. Set the G’MIC output mode to “New layer(s)” (see below).

   Filters → G’MIC
   Details → Split Details [wavelets]

   

7. Make the blended and blended [residual] layers visible. Then set the mode of the blended [residual] layer to color. This will give you a picture with averaged, blurred colors.

   

8. Turn the opacity of the blended [residual] down to 70%, or any other value to your taste, to bring back some color detail.

   

9. Turn on the blended [scale #8] layer, set the mode to grain merge, and see how the lights start shining. Adjust opacity to taste.

   

10. Optional: Turn the wavelet scale 3 (or any other) on to sharpen the picture and blend to taste.

11. Make sure the following layers are visible:

    • blended
    • residual
    • wavelet scale 8
    • Any other wavelet scale you want to use for sharpening

12. Make a new layer from visible

    Layer → New from Visible

13. Raise and slightly crush the shadows using the tone curve.

    

14. Optional: Adjust saturation to taste. If there are predominantly white lights and the colors come mainly from other objects, the residual will be washed out, as is the case with this picture.

    I noticed that the reds and yellows were very dominant compared to greens and blues. So using the Hue-Saturation dialog I raised the master saturation by +70 and lowered the yellow saturation by -50 and lowered the red saturation by -40 all using an overlap of _60_.

The final result:

Giving Thanks

For an awesome community!

Here in the U.S., we have a big holiday coming up this week: Thanksgiving. Serendipitously, this holiday also happens to fall when a few neat things are happening around the community, and what better time is there to recognize some folks and to give thanks of our own? No time like the present!

A Special Thanks

I feel a special “Thank You” should first go to a photographer and fantastic supporter of the community, Dimitrios Psychogios. Last year for our trip to Libre Graphics Meeting, London he stepped up with an awesome donation to help us bring some fun folks together.

This year he was incredibly kind by offering a donation to the community (completely unsolicited) that covers our hosting and infrastructure costs for an entire year! So on behalf of the community, Thank You for your support, Dimitrios!

I’ll be creating a page soon that will list our supporters as a means of showing our gratitude. Speaking of supporters and a new page on the site…

A Support Page

Someone had asked about the possibility of donating to the community on a post. We were talking about providing support in darktable for using a midi controller deck and the costs for some of the options weren’t too extravagant. This got us thinking that enough small donations could probably cover something like this pretty easily, and if it was community hardware we could make sure it got passed around to each of the projects that would be interested in creating support for it.

That conversation had me thinking about ways to allow folks to support the community. In particular, ways to make it easy to provide support on an on-going basis if possible (in addition to simple, single donations). There are goal-oriented options out there that folks are probably already familiar with (Kickstarter, Indiegogo and others) but the model for us is less goal-oriented and more about continuous support.

Patreon was an option as well (and I already had a skeleton Patreon account set up), but the fees were just too much in the end. They wanted a flat 5% along with the regular PayPal fees. The general consensus among the staff was that we wanted to maximize the funds getting to the community.

The best option in the end was to create a merchant account on PayPal and manually set up the various payment options. I’ve set them up similar to how a service like Patreon might run with four different recurring funding levels and an option for a single one-time payment of whatever a user would like. Recurring levels are nice because they make it easier to plan with.

We’re Not Asking

Our requirements for the infrastructure of the site are modest and we haven’t actively pursued support or donations for the site before. That hasn’t changed.

We’re not asking for support now. The best way that someone can help the community is by being an active part of it.

Engaging others, sharing what you’ve done or learned, and helping other users out wherever you can. This is the best way to support the community.

I purposely didn’t talk about funding before because I don’t want folks to have to worry or think about it. And before you ask: no, we are not and will not run any advertising on the site. I’d honestly rather just keep paying for things out of my pocket instead.

We’re not asking for support, but we’ll accept it.

With that being said, I understand that there’s still some folks that would like to contribute to the infrastructure or help us to get hardware to add support in projects and more. So if you do want to contribute, the page for doing so can be found here:

https://pixls.us/support

There are four recurring funding levels of $1, $3, $5, and $10 per month. There is also a one-time contribution option as well.

We also have an Amazon Affiliate link option. If you’re not familiar with it, you simply click the link to go to Amazon.com. Then anything you buy for the next 24 hours will give us some small percentage of your purchase price. It doesn’t affect the price of what you’re buying at all. So if you were going to purchase something from Amazon anyway, and don’t mind - then by all means use our link first to help out!

1000 Users

This week we also finally hit 1,000 users registered on discuss! Which is just bananas to me. I am super thankful for each and every member of the community that has taken the time to participate, share, and generally make one of the better parts of my day catching up on what’s been going on. You all rock!

While we’re talking about a number “1” with bunch of zeros after it, we recently made some neat improvements to the forums…

100 Megabytes

We are a photography community and it seemed stupid to have to restrict users from uploading full quality images or raw files. Previously it was a concern because the server the forums are hosted on have limited disk space (40GB). Luckily, Discourse has an option for storing all uploads to the forum on Amazon S3 buckets.

I went ahead and created some S3 buckets so that any uploads to the forums will now be hosted on Amazon instead of taking up precious space on the server. The costs are quite reasonable (around $0.30/GB right now), and it also means that I’ve been able to bump the upload size to 100MB for forum posts! You can now just drag and drop full resolution raw files directly into the post editor to include the file!

Travis CI Automation

On a slightly geekier note, did you know that the code for the entire website is available on Github? It’s also licensed liberally (CC-BY-SA), so no reason not to come and fiddle with things with us! One of the features of using Github is integration with Travis CI (Continuous Integration).

What this basically means is that every commit to the Github repo for the website gets picked up by Travis and built to test that everything is working ok. You can actually see the history of the website builds there.

I’ve now got it set up so that when a build is successful on Travis, it will automatically publish the results to the main webserver and make it live. Our build system, Metalsmith, is a static site generator. This means that we build the entire website on our local computers when we make changes, and then publish all of those changes to the webserver. This change automates that process for us now by handling the building and publishing if everything is ok.

In fact, if everything is working the way I think it should, this very blog post will be the first one published using the new automated system! Hooray!

You can poke me or @paperdigits on discuss if you want more details or feel like playing with the website.

Mica

Speaking of @paperdigits, I want to close this blog post with a great big “Thank You!“ to him as well. He’s the only other person insane enough to try and make sense of all the stuff I’ve done building the site so far, and he’s been extremely helpful hacking at the website code, writing articles, make good infrastructure suggestions, taking the initiative on things (t-shirts and github repos), and generally being awesome all around.

João Almeida's darktable Presets

A gorgeous set of film emulation for darktable

I realize that I’m a little late to this, but photographer João Almeida has created a wonderful set of film emulation presets for darktable that he uses in his own workflow for personal and commisioned work. Even more wonderful is that he has graciously released them for everyone to use.

These film emulations started as a personal side project for João, and he adds a disclaimer to them that he did not optimize them all for each brand or model of his cameras. His end goal was for these to be as simple as possible by using a few darktable modules. He describes it best on his blog post about them:

The end goal of these presets is to be as simple as possible by using few Darktable modules, it works solely by manipulating Lab Tone Curves for color manipulation, black & white films rely heavily on Channel Mixer. Since I what I was aiming for was the color profiles of each film, other traits related with processing, lenses and others are unlikely to be implemented, this includes: grain, vignetting, light leaks, cross-processing, etc.

Some before/after samples from his blog post:

You can read more on João’s website and you can see many more images on Flickr with the #t3mujinpack tag. The full list of film emulations included with his pack:

• AGFA APX 25, 100
• Fuji Astia 100F
• Fuji Neopan 1600, Acros 100
• Fuji Pro 160C, 400H, 800Z
• Fuji Provia 100F, 400F, 400X
• Fuji Sensia 100
• Fuji Superia 100, 200, 400, 800, 1600, HG 1600
• Fuji Velvia 50, 100
• Ilford Delta 100, 400, 3200
• Ilford FP4 125
• Ilford HP5 Plus 400
• Ilford XP2
• Kodak Ektachrome 100 GX, VS
• Kodak Ektar 100
• Kodak Elite Chrome 400
• Kodak Kodachrome 25, 64, 200
• Kodak Portra 160 NC, VC
• Kodak Portra 400 NC, UC, VC
• Kodak Portra 800
• Kodak T-Max 3200
• Kodak Tri-X 400

If you see João around the forums stop and say hi (and maybe a thank you). Even better, if you find these useful, consider buying him a beer (donation link is on his blog post)!

Related Reading

• color manipulation with the colour checker lut module (darktable)
• Pat David’s film emulation LUTs (G’MIC)
• Common Color Curves (Portra, Provia, Velvia) (RawTherapee)
• Pascal’s colormatch

Aligning Images with Hugin

Easily process your bracketed exposures

Hugin is an excellent tool for for aligning and stitching images. In this article, we’ll focus on aligning a stack of images. Aligning a stack of images can be useful for achieving several results, such as:

• bracketed exposures to make an HDR or fused exposure (using enfuse/enblend), or manually blending the images together in an image editor
• photographs taken at different focal distances to extend the depth of field, which can be very useful when taking macros
• photographs taken over a period of time to make a time-lapse movie

For the example images included with this tutorial, the focal length is 12mm and the focal length multiplier is 1. A big thank you to @isaac for providing these images.

You can download a zip file of all of the sample Beach Umbrellas images here:

Download Outdoor_Beach_Umbrella.zip (62MB)

Other sample images to try with this tutorial can be found at the end of the post.

These instructions were adapted from the original forum post by @Carmelo_DrRaw; many thanks to him as well.

We’re going to align these bracked exposures so we can blend them:

1. Select Interface → Expert to set the interface to Expert mode. This will expose all of the options offered by Hugin.

2. Select the Add images… button to load your bracketed images. Select your images from the file chooser dialog and click Open.

3. Set the optimal setting for aligning images:

   • Feature Matching Settings: Align image stack
   • Optimize Geometric: Custom parameters
   • Optimize Photometric: Low dynamic range

4. Select the Optimizer tab.

5. In the Image Orientation section, select the following variables for each image:

   • Roll
   • X (TrX) [horizontal translation]
   • Y (TrY) [vertical translation]

   You can Ctrl + left mouse click to enable or disable the variables.

   

   Note that you do not need to select the parameters for the anchor image:

   

6. Select Optimize now! and wait for the software to finish the calculations. Select Yes to apply the changes.

7. Select the Stitcher tab.

8. Select the Calculate Field of View button.

9. Select the Calculate Optimal Size button.

10. Select the Fit Crop to Images button.

11. To have the maximum number of post-processing options, select the following image outputs:

    • Panorama Outputs: Exposure fused from any arrangement
      • Format: TIFF
      • Compression: LZW
    • Panorama Outputs: High dynamic range
      • Format: EXR

    • Remapped Images: No exposure correction, low dynamic range

      

12. Select the Stitch! button and choose a place to save the files. Since Hugin generates quite a few temporary images, save the PTO file in it’s own folder.

Hugin will output the following images:

• a tif file blended by enfuse/enblend
• an HDR image in the EXR format
• the individual images after remapping and without any exposure correction that you can import into the GIMP as layers and blend manually.

You can see the result of the image blended with enblend/enfuse:

With the output images, you can:

• edit the enfuse/enblend tif file further in the GIMP or RawTherapee
• tone map the EXR file in LuminanceHDR
• manually blend the remapped tif files in the GIMP or PhotoFlow

Image files

• Camera: Olympus E-M10 mark ii
• Lens: Samyang 12mm F2.0

Indoor_Guitars

Download Indoor_Guitars.zip (75MB)

• 5 brackets
• ±0.3 EV increments
• f5.6
• focus at about 1m
• center priority metering
• exposed for guitars, bracketed for the sky, outdoor area, and indoor area
• manual mode (shutter speed recorded in EXIF)
• shot in burst mode, handheld

Outdoor_Beach_Umbrella

Download Outdoor_Beach_Umbrella.zip (62MB)

• 3 brackets
• ±1 EV increments
• f11
• focus at infinity
• center priority metering
• exposed for the water, bracketed for umbrella and sky
• manual mode (shutter speed recorded in EXIF)
• shot in burst mode, handheld

Outdoor_Sunset_Over_Ocean

Download Outdoor_Sunset_Over_Ocean.zip (60MB)

• 3 brackets
• ±1 EV increments
• f11
• focus at infinity
• center priority metering
• exposed for the darker clouds, bracketed for darker water and lighter sky areas and sun
• manual mode (shutter speed recorded in EXIF)
• shot in burst mode, handheld

Licencing Information

• Images created by Isaac I. Ullah, 2016, and released under the Creative Commons Attribution-ShareAlike 4.0 licence (cba).

The Royal Photographic Society Journal

Who let us in here?

The Journal of the Photographic Society is the journal for one of oldest photographic societies in the world: the Royal Photographic Society. First published in 1853, the RPS Journal is the oldest photographic periodical in the world (just edging out the British Journal of Photography by about a year).

So you can imagine my doubt when confronted with an email about using some material from pixls.us for their latest issue…

If the name sounds familiar to anyone it may be from a recent post by Joe McNally who is featured prominently in the September 2016 issue. He was also just inducted as a fellow into the society!

It turns out my initial doubts were completely unfounded, and they really wanted to run a page based off one of our tutorials. The editors liked the Open Source Portrait tutorial. In particular, the section on using Wavelet Decompose to touch up the skin tones:

How cool is that? I actually searched the archive and the only other mention I can find of GIMP (or any other F/OSS) is from a “Step By Step” article written by Peter Gawthrop (Vol. 149, February 2009). I think it’s pretty awesome that we can promote a little more exposure for Free Software alternatives. Especially in more mainstream publications and to a broader audience!

Arnold Newman Portraits

The beginnings of "Environmental Portraits"

Anyone that has spent any time around me would realize that I’m particularly fond of portraits. From the wonderful works of Martin Schoeller to the sublime Dan Winters, I am simply fascinated by a well executed portrait. So I thought it would be fun to take a look at some selections from the “father” of environmental portraits - Arnold Newman.

Newman wanted to become a painter before needing to drop out of college after only two years to take a job shooting portraits in a photo studio in Philadelphia. This experience apparently taught him what he did not want to do with photography…

Luckily it may have started defining what he did want to do with his photography. Namely, his approach to capturing his subjects alongside (or within) the context of the things that made them notable in some way. This would became known as “Environmental Portraiture”. He described it best in an interview for American Photo in 2000:

I didn’t just want to make a photograph with some things in the background. The surroundings had to add to the composition and the understanding of the person. No matter who the subject was, it had to be an interesting photograph. Just to simply do a portrait of a famous person doesn’t mean a thing. ¹

Though he has felt that the term might be unnecessarily restrictive (and possibly overshadows his other pursuits including abstractions and photojournalism), there’s no denying the impact of the results. Possibly his most famous portrait, of composer Igor Stravinsky, illustrates this wonderfully. The overall tones are almost monotone (flat - pun intended, and likely intentional on behalf of Newman) and are dominated by the stark duality of the white wall with the black piano.

Newman realized that the open lid of the piano “…is like the shape of a musical flat symbol—strong, linear, and beautiful, just like Stravinsky’s work.” ¹ The geometric construction of the image instantly captures the eye and the aggressive crop makes the final composition even more interesting. In this case the crop was a fundamental part of the original composition as shot, but it was not uncommon for him to find new life in images with different crops.

In a similar theme his portraits of both Salador Dalí and John F. Kennedy show a willingness to allow the crop to bring in different defining characteristics of his subjects. In the case of Dalí it allows an abstraction to hang there mimicking the pose of the artist himself. Kennedy is mostly the only organic form, striking a relaxed pose, while dwarfed by the imposing architecture and hard lines surrounding him.

He manages to bring the same deft handling of placing his subjects in the context of their work with other photographers as well. His portrait of Ansel Adams shows the photographer just outside his studio with the surrounding wilderness not only visible around the frame but reflected in the glass of the doors behind him (and the photographers glasses). Perhaps an indication of the nature of Adams work being to capture natural scenes through glass?

For anyone familiar with the pioneer of another form of photography, Newman’s portrait of (the usually camera shy) Henri Cartier-Bresson will instantly evoke a sense of the artists candid street images. In it, Bresson appears to take the place of one of his subjects caught briefly on the streets in a fleeting moment. The portrait has an almost spontaneous feeling to it, (again) mirroring the style of the work of its subject.

Eight years after his portrait of surrealist painter Dali, Newman shot another famous (abstraction) artist, Pablo Picasso. This particular portrait is much more intimate and more classically composed, framing the subject as a headshot with little of the surrounding environment as before. I can’t help but think that the placement of the hand being similar in both images is intentional; a nod to the unconventional views both artists brought to the world.

The eloquent Gregory Heisler had a wonderful discussion about Newman for Atlanta Celebrates Photography at the High Musuem in 2008:

Arnold Newman produced an amazing body of work that warrants some time and consideration for anyone interested in portraiture. These few examples simply do not do his collection of portraits justice. If you have a few moments to peruse some amazing images head over to his website and have a look (I’m particularly fond of his extremely design-oriented portrait of chinese-american architect I.M. Pei):

Of historical interest is a look at Newman’s contact sheet for the Stravinsky image showing various compositions and approaches to his subject with the piano. (I would have easily chosen the last image in the first row as my pick.) I have seen the second image in the second row cropped as indicated, which was also a very strong choice. I adore being able to investigate contact sheets from shoots like this - it helps me to humanize these amazing photographers while simultaneously allowing me an opportunity to learn a little about their thought process and how I might incorporate it into my own photography.

To close, a quote from his interview with American Photo magazine back in 2000 that will likely remain relevant to photographers for a long time:

But a lot of photographers think that if they buy a better camera they’ll be able to take better photographs. A better camera won’t do a thing for you if you don’t have anything in your head or in your heart. ¹

¹ Harris, Mark. “Arnold Newman: The Stories Behind Some of the Most Famous Portraits of the 20th Century.” American Photo, March/April 2000, pp. 36-38

Highlight Bloom and Photoillustration Look

Replicating a 'Lucisart'/Dave Hill type illustrative look

Over in the forums community member Sebastien Guyader (@sguyader) posted a neat workflow for emulating a photo-illustrative look popularized by photographers like Dave Hill where the resulting images often seem to have a sort of hyper-real feeling to them. Some of this feeling comes from a local-contrast boost and slight ‘blooming’ of the lighter tones in the image (though arguably most of the look is due to lighting and compositing of multiple elements).

To illustrate, here are a few representative samples of Dave Hill’s work that reflects this feeling:

A video of Dave presenting on how he brought together the idea and images for the series the first image above is from:

This effect is also popularized in Photoshop^® filters such as LucisArt in an effort to attain what some would (erroneously) call an “HDR” effect. Really what they likely mean is a not-so-subtle tone-mapping. In particular the exaggerated local contrasts is often what garners folks attention.

We had previously posted about a method for exaggerating fine local contrasts and details using the “Freaky Details” method described by Calvin Hollywood. This workflow provides a similar idea but different results that many might find more appealing (it’s not as gritty as the Freaky Details approach).

Sebastien produced some great looking preview images to give folks a feeling for what the process would produce:

Replicating a “Dave Hill”/“LucasArt” effect

Sebastien’s approach relies only on having the always useful G’MIC plugin for GIMP. The general workflow is to do a high-pass frequency separation, and to apply some effects like local contrast enhancement and some smoothing on the residual low-pass layer. Then recombine the high+low pass layers to get the final result.

1. Open the image.
2. Duplicate the base layer.
   Rename it to “Lowpass”.
3. With the top layer (“Lowpass”) active, open G’MIC.
4. Use the Photocomix smoothing filter:

   Testing → Photocomix → Photocomix smoothing

   Set the Amplitude to 10. Apply.
   This is to taste, but a good startig place might be around 1% of the image dimensions (so a 2000px wide image - try using an Amplitude of 20).
5. Change the “Lowpass” layer blend mode to Grain extract.
6. Right-Click on the layer and choose New from visible.
   Rename this layer from “Visible“ to something more memorable like “Highpass” and set its layer mode to Grain merge.
   Turn off this layer visibility for now.
7. Activate the “Lowpass” layer and set its layer blend mode back to Normal.
   The rest of the filters are applied to this “Lowpass” layer.
8. Open G’MIC again.
   Apply the Simple local contrast filter:

   Details → Simple local contrast

   Using:
   • Edge Sensitivity to 25
   • Iterations to 1
   • Paint effect to 50
   • Post-gamma to 1.20
9. Open G’MIC again.
   Now apply the Graphic novel filter:

   Artistic → Graphic novel

   Using:
   • check the Skip this step checkbox for Apply Local Normalization
   • Pencil size to 1
   • Pencil amplitude to 100-200
   • Pencil smoother sharpness/edge protection/smoothness
     to 0
   • Boost merging options Mixer to Soft light
   • Painter’s touch sharpness to 1.26
   • Painter’s edge protection flow to 0.37
   • Painter’s smoothness to 1.05
10. Finally, make the “Highpass” layer visible again to bring back the fine details.

Trying It Out!

Let’s walk through the process. Sebastien got his sample images from the website https://pixabay.com, so I thought I would follow suit and find something suitable from there also. After some searching I found this neat image from Jerzy Gorecki licensed Create Commons 0/Public Domain.

Frequency Separation

The first steps (1—7) are to create a High/Low pass frequency separation of the image. If you have a different method for obtaining the separation then feel free to use it. Sebastien uses the Photocomix smoothing filter to create his low-pass layer (other options might be Gaussian blur, bi-lateral smoothing, or even wavelets).

The basic steps to do this are to duplicate the base layer, blur it, then set the layer blend mode to Grain extract and create a new layer from visible. The new layer will be the Highpass (high-frequency) details and should have its layer blend mode set to Grain merge. The original blurred layer is the Lowpass (low-frequency) information and should have its layer blend mode set back to Normal.

So, following Sebastien’s steps, duplicate the base layer and rename the layer to “lowpass”. Then open G’MIC and apply:

Testing → Photocomix → Photocomix smoothing

with an amplitude of around 20. Change this to suit your own taste, but about 1% of the image width is a decent starting point. You’ll now have the base layer and the “lowpass” layer above it that has been smoothed:

Setting the “lowpass” layer blend mode to Grain extract will reveal the high-frequency details:

Now create a new layer from what is currently visible. Either right-click the “lowpass” layer and choose “New from visible” or from the menus:

Layer → New from Visible

Rename this new layer from “Visible” to “highpass” and set its layer blend mode to Grain merge. Select the “lowpass” layer and set its layer blend mode back to Normal.

The visible result should be back to what your starting image looked like. The rest of the steps for this tutorial will operate on the “lowpass” layer. You can leave the “highpass” filter visible during the rest of the steps to see what your results will look like.

Modifying the Low-Frequency Layer

These next steps will modify the underlying low-frequency image information to smooth it out and give it a bit of a contrast boost. First the “Simple local contrast” filter will separate tones and do some preliminary smoothing, while the “Graphic novel” filter will provide a nice boost to light tones along with further smoothing.

Simple Local Contrast

On the “lowpass” layer, open G’MIC and find the “Simple local contrast” filter:

Details → Simple local contrast

Change the following settings:

• Edge Sensitivity to 25
• Iterations to 1
• Paint effect to 50
• Post-gamma to 1.20

This will smooth out overall tones while simultaneously providing a nice local contrast boost. This is the step that causes small lighting details to “pop”:

The contrast increase provides a nice visual punch to the image. The addition of the “Graphic novel” filter will push the overall image much closer to a feeling of a photo-illustration.

Graphic Novel

Still on the “lowpass” layer, re-open G’MIC and open the “Graphic Novel” filter:

Artistic → Graphic novel

Change the following settings:

• check the Skip this step checkbox for Apply Local Normalization
• Pencil size to 1
• Pencil amplitude to 100-200
• Pencil smoother sharpness/edge protection/smoothness
  to 0
• Boost merging options Mixer to Soft light
• Painter’s touch sharpness to 1.26
• Painter’s edge protection flow to 0.37
• Painter’s smoothness to 1.05

The intent with this filter is to further smooth the overall tones, simplify details, and to give a nice boost to the light tones of the image:

The effect at 100% opacity can be a little strong. If so, simply adjust the opacity of the “lowpass” layer to taste. In some cases it would probably be desirable to mask areas you don’t want the effect applied to.

I’ve included the GIMP .xcf.bz2 file of this image while I was working on it for this article. You can download the file here (34.9MB). I did each step on a new layer so if you want to see the results of each effect step-by-step, simply turn that layer on/off:

Finally, a great big Thank You! to Sebastien Guyader (@sguyader) for sharing this with everyone in the community!

A G’MIC Command

Of course, this wouldn’t be complete if someone didn’t come along with the direct G’MIC commands to get a similar result! And we can thank Iain Fergusson (@Iain) for coming up with the commands:

--gimp_anisotropic_smoothing[0] 10,0.16,0.63,0.6,2.35,0.8,30,2,0,1,1,0,1

-sub[0] [1]

-simplelocalcontrast_p[1] 25,1,50,1,1,1.2,1,1,1,1,1,1
-gimp_graphic_novelfxl[1] 1,2,6,5,20,0,1,100,0,1,0,0.78,1.92,0,0,2,1,1,1,1.26,0.37,1.05
-add
-c 0,255

From the Community Vol. 1

Welcome to the first installment of From the Community, a (hopefully) quarterly blog post to highlight a few of the things our community members have been doing!

Rapid Photo Downloader Process Model

@damonlynch has a great write up of Rapid Photo Download’s process model. Rapid Photo Downloader is built using Python, so if you’re looking for a good way to add threads to your Python program, this write up has some good information for you, check it out!

Community-built Software downloads page

Free Software development tends to move at a pretty good pace, so there is always something new to try out! Not all of the new things warrant a new release, but our community steps up and builds the software so that others can use and test! Instead of random links to dropboxes and such, we’ve created a Community-built Software page to help centralize and make it easy for our users to help find and download the freshest builds of software from our great community members. Keep in mind that support may be limited for these builds and they’re considered testing, so quality may vary, but if you covet the newest, shiniest things, this is the place for you!

Glitch art filters coming to G’MIC

G’MIC will be getting some cool glitch art filters in 1.7.6. @thething is interested in glitch art and requested some new filters in G’MIC, and @David_Tschumperle delivered very quickly!

You can flip blocks:

and warp your images:

An Alternative to Watermarking

Watermarking is ugly and takes focus away from your image. Why not try and add an attribution bar to your images? In this post, @patdavid lays out how to add a bar underneath your image with your name, the image title, and a little logo. @David_Tschumperle followed that effort up with an alternate implementation using G’MIC instead of imagemagic. Lastly, @vato rolled the imagemagick version into a bash script with the necessary parameters exposed as variables at the beginning of the script.

Here is an example image by @Morgan_Hardwood:

Help Author a Tutorial for Beginners

Finally, we’re still working on our beginner article to help new users navigate the myriad of free software photography software that is out there. If you have ideas, or better yet, want to author a bit of content with our community, please join and help out! The post is community wiki and has complete revision control, so don’t be afraid to jump in and contribute!

A Chiaroscuro Portrait

Following the Old Masters

Introduction (Concept/Theory)

The term Chiaroscuro is derived from the Italian chiaro meaning ‘clear, bright’ and oscuro meaning ‘dark, obscure’. In art the term has come to refer to the use of bold contrasts between light and shadow, particularly across an entire composition, where they are a prominent feature of the work.

This interplay of shadow and light is particularly important in allowing the viewer to extrapolate volume from a flat image. The use of a single light source helps to accentuate the perception of volume as well as adding drama and dynamics to the scene.

Historically the use of chiaroscuro can often be associated with the works of old masters such as Rembrandt and Caravaggio. The use of such extreme lighting immediately evokes a sense of shape and volume, while focusing the attention of the viewer.

The aim of this tutorial will be to emulate the lighting characteristics of chiaroscuro in producing a portrait to evoke the feeling of an old master painting.

Equipment

In examining chiaroscuro portraiture, it becomes apparent that a strong characteristic of the images is the use of single light source on the scene. So this tutorial will focus on using a single source to illuminate the portrait.

Getting the keylight off the camera is essential. The closer the keylight is to the axis of the camera the larger the reduction in shadows. This is counter to the intention of this workflow. Shadows are an essential component in producing this look, and on-camera lighting simply will not work.

The reason to choose a softbox versus the myriad of other light modifiers available is simple: control. Umbrellas can soften the light, but due to their open nature have a tendency to spill light everywhere while doing so. A softbox allows the light to be softened while also retaining a higher level of spill control.

Light spill can still occur with a softbox, so the best option is to bring the light in as close as possible to the subject. Due to the inverse square nature of light attenuation, this will help to drop the background very dark (or black) when exposing properly for the subject.

Left
For example, in the sample images above, a 20 inch softbox was initially located about 18 inches away from the subject (first). The rear wall was approximately 48 inches away from the subject or just over twice the distance from the softbox. Thus, on a proper exposure for the subject, the background would be around 3 stops lower in light. This is seen as the background in the first image has dropped to a dark gray.

Middle
When the light distance to the subject is doubled and the light distance to the rear wall stays the same, the ratio is not as extreme between them. The light distance from the subject is now 36 inches, while the light distance to the rear wall is still 48 inches. When properly exposing for the subject, the rear wall is now only about 1 stop lower in light.

Right
In the final example, the distance from the light to both the subject and the rear wall are very close. As such, a proper exposure for the subject almost brings the wall to a middle exposure.

What this example provides is a good visual guide for how to position the subject and light relative to the surroundings to create the desired look. To accentuate the ratio between dark and light in the image it would be best to move the light as close to the subject as possible.

If there is nothing to reflect light on the shadow side of the subject, then the shadows would fall to very dark or black. Usually, there are at least walls and ceilings in a space that will reflect some light, and the amount falling on the shadow side can be attenuated by either moving the subject nearer to a wall on that side, or using a bounce/reflector as desired.

Shooting

Planning

The setup for the shot would be to push the key light in very close to the model, while still allowing some bounce to slightly fill the shadows.

As noted previously, having the key light close to the model would allow the rest of the scene to become much darker. The softbox is arranged such that the face is almost completely vertical and the bottom edge is just above the models eyes. This was to feather the lower edge of the light falloff along the front of the model.

There are 2 main adjustments that can be made to fine-tune the image result with this setup.

The first is the key light distance/orientation to the subject. This will dictate the proper exposure for the subject. For this image the intention is to push the key light in as close as possible without being in frame. There is also the option of angling the key light relative to the subject. In the diagram above, the softbox is actually angled away from the subject. The intention here was to feather the edge of the light in order to control spill onto the rest of the model (putting more emphasis on her face).

The second adjustment, once the key light is in a good location, is the distance from the key light and subject together, to the surrounding walls (or a reflector if one is being used). Moving both subject and keylight closer to the side wall will increase the amount of reflected light being bounced into the shadows.

Mood Board

If possible, it can be extremely helpful to both the model and photographer to have a Mood Board available. This is usually just a collection or collage of images that help to convey the desired feeling or desired result from the session. For help in directing the model, the images do not necessarily need the same lighting setup. The intention is to help the model understand what your vision is for the pose and facial expressions.

The Shoot

The lighting is set up and the model understands what type of look is desired, so all that’s left is to shoot the image!

In the end, I favored the last image in the sequence for a combination of the models head position/body language and the slight smile she has.

Postprocessing

Having chosen the final image from the contact sheet, it’s now time to proceed with developing the image and retouching as needed.

If you’d like to follow along you can download the raw .ORF file:

Mairi_Troisieme.ORF (13MB)

This file is licensed (Creative Commons, By-Attribution, Non-Commercial, Share-Alike), and is the same image that I shared with everyone on the forums for a PlayRaw processing practice. You can see how other folks approached processing this image in the topic on discuss. If you decide to try this out for yourself, come share your results with us!

Raw Development

There are various Free raw processing tools available and for this tutorial I will be using the wonderful darktable.

Base Curve

Not surprisingly the initial image loaded without any modifications is a bit dark and rather flat looking. By default darktable should have recognized that the file is from Olympus, and attempted to apply a sane base curve to the linear raw data. If it doesn’t you can choose the preset “olympus like alternate”.

I found that the preset tended to crush the darkest tones a bit too much, and instead opted for a simple curve with a single point as seen here:

Resist the temptation to try and adjust overall exposure and contrast with the base curve. These parameters will be adjusted shortly in the appropriate modules. The base curve is only intended to transform the linear raw rgb to something that looks good on your output device. The base curve will affect how the contrasts, colors, and saturation all relate in the final output. For the purposes of this tutorial, it is enough to simply choose a preset.

The next series of steps focus on adjusting various exposure parameters for the image. Conceptually they start with the most broad adjustment, exposure, then to slightly more targeted adjustments such as contrast, brightness, and saturation, then finish with targeted tonal adjustments in tone curves.

darktable manual: base curve

Exposure

Once the base curve is set, the next module to adjust would be the overall exposure of the image (and the black point). This is done in the “exposure” module (below the base curve).

The important area to watch while adjusting the exposure for the image is the histogram. The image was exposed a little dark, so increase the exposure overall for the image. In the histogram, avoid clipping any channels by allowing them to be pushed outside the range. In this case, the desire is to provide a nice mid-level brightness to the models face. The exposure can be raised until the channels begin to clip on the far right of the histogram, then brought back down a bit to leave some headroom.

The darkest areas of the histogram on the left are clipped a bit, so raising the black level brings the detail back in the darkest shadows. When in doubt try to let the histogram guide you with data from the image. Particularly around the highest and lowest values (avoid clipping if possible).

An easy way to think of the exposure module is that it allows the entire image exposure to be shifted along with compressing/expanding the overall range by modifying the black point.

darktable manual: exposure

Contrast Brightness Saturation

Where the Exposure module shifts the overall image values from a global perspective, modules such as the “contrast brightness saturation” allow finer tuning of the image within the range of the exposure.

To emphasis the models face, while also strengthening the interplay of shadow and light on the image, drop the brightness down to taste. I brought the brightness levels down quite a bit (-0.31) to push almost all of the image below medium brightness.

Overall this helps to emphasis the models face over the rest of the image initially. While the rest of the image is comprised of various dark/neutral tones, the models face is not. Pushing the saturation down as well will remove much of the color from the scene and face. This is done to bring the skin tones back down to something slightly more natural looking, while also muting some of those tones.

The skin now looks a bit more natural but muted. The background tones have become more neutral as well. A very slight bump in contrast to taste finishes out this module.

darktable manual: contrast brightness saturation

Tone Curve

A final modification to the exposure of the image is through a tone curve adjustment. This gives us the ability to make some slight changes to particular tonal ranges. In this case pushing the darker tones down a bit more while boosting the upper mid and high tones.

This is actually a type of contrast increase, but controlled to specific tones based on the curve. The darkest darks (bottom of the curve) get pushed a little bit darker, which will include most of the sweater, background, and shadow side of the models face. The very slight rolling boost to the lighter tones primarily helps to allow the face to brighten up against the background even more.

The changes are very slight and to taste. The tone curve is very sensitive to changes, and often only very small modifications are required to achieve a given result.

darktable manual: tone curve

Sharpen

By default the sharpen module will apply a small amount of sharpening to the image. The module uses unsharp mask for sharpening, so the radius parameter is the blur radius into the unsharp mask. I wanted to sharpen lightly very fine details, so set the radius to ~1, with an amount around 0.9 and no threshold. This produced results that are very hard to distinguish from the default settings, but appears to sharpen smaller structures just slightly more.

I personally include a final sharpening step as a side effect of using wavelet decompose for skin retouching later in the process with GIMP. As such I am not usually as concerned about sharpening here as much. If I were, there are better modules for adjusting sharpening from wavelets using the equalizer module.

darktable manual: sharpen

Denoise (profiled)

The darktable team and its users profiled many different cameras for noise profiles at various ISOs to build a statistical model with brightness across the three color channels. Using these profiles, darktable can then do a better job at efficiently denoising images. In the case of my camera (Olympus OM-D E-M5), there was a profile already captured for ISO200.

In this case, the chroma noise wasn’t too bad, and a very slight reduction in luma noise would be sufficient for the image. As such, I used a non-local means with a large patch size (to retain sharpness) and a low strength. This was all applied uniformly against the HSV lightness option.

darktable manual: denoise - profiled

Export

Finally! The image tones and exposure are in a desirable state, so export the results to a new file. I tend to use either TIF or PNG at 16 bit. This is in case I want to work in a full 16 bit workflow with the latest GIMP, or may want to in the future.

GIMP

When there are still some pixel-level modifications that need to be done to the image, the go-to software is GIMP.

• Skin retouching
• spot healing/touchups
• Background rebuild

Skin Retouching with Wavelet Decompose

This step is not always needed, but who doesn’t want their skin to look a little nicer if possible?

The ability to modify an image based on detail scales isolated on their own layers is a very powerful tool. The approach is similar to frequency separation, but has the advantage of providing multiple frequencies to modify simultaneously of progressively larger and larger detail scales. This offers a large range of flexibility and an easier workflow vs. frequency separation (you can work on any detail scale simply by switching to a different layer).

I used to use the wonderful Wavelet Decompose plugin from marcor on the GIMP plugin registry. I have since switched to using the same result from G’MIC once David Tschumperlé added it in for me. It can be found in G’MIC under:

Details → Split details [wavelets]

Running Split details [wavelets] against the image to produce 5 wavelet scales and a residual layer yields (cropped):

The plugin (or script) will produce 5 layers of isolated details plus a residual layer of low-frequency color information. Seen here in ascending size of detail scales. The finest scales (1 & 2) will be hard to discern the details as they are quite fine.

To help visualizing what the different scale levels look like here is a view of the same levels above, normalized:

The normalized view shows clearly the various types of detail scales on each layer.

There are various types of changes that can be made to the final image from these details scales. In this image, we are going to focus on evening out the skin tones overall. The scales with the biggest impact on even skin tones for this image are 4 and 5.

A good workflow when smoothing overall skin tones and using wavelet scales is to work on smoothing from the largest detail scales and working down to finer scales. Usually, a nice amount of pleasing tonal smoothing can be accomplished in the first couple of coarse detail scales.

Skin Retouching Zones

Different portions of a face will often require different levels of smoothing. Below is a rough map of facial contours to consider when retouching. Not all faces will require the exact same regions, but it is a good starting point to consider when approaching a new image.

The selections are made with the Free Select Tool with the “Feather edges” option on and set to roughly 30px.

Smoothing

A good starting point to consider is the forehead on the largest detail scale (5). The basic workflow is to select a region of interest and a layer of detail, then to suppress the features on that detail level. The method of suppressing features is a matter of personal taste but is usually done across the entire selection using a blur filter of some sort.

A good first choice would be to use a gaussian blur (or Selective Gaussian Blur) to smooth the selection. A better choice, if G’MIC is installed, is to use a bilateral blur for its edge-preserving properties. The rest of these examples will use the bilateral blur for smoothing.

Considering the forehead region:

The first image is the original. The second image is after running a bilateral blur (in G’MIC: Smooth [bilateral]), with the default parameter values:

• Spatial variance: 10
• Value variance: 7
• Iterations: 2

These values were chosen from experience using this filter for the same purpose across many, many images. The results of running a single blur on the largest wavelet scale is immediately obvious. The unevenness of the skin and tones overall are smoothed in a pleasing way, while still retaining the finer details that allow the eye to see a realistic skin texture.

The last image is the result of working on the next detail scale layer down (Wavelet scale 4), with much softer blur parameters:

• Spatial variance: 5
• Value variance: 2
• Iterations: 1

This pass does a good job of finishing off the skin tones globally. The overall impression of the skin is much smoother than the original, but crucial fine details are all left intact (wrinkles, pores) to keep the it looking realistic.

This same process is repeated for each of the facial regions described. In some cases the results of running the first bilateral blur on the largest scale level is enough to even out the tones (the cheeks and upper lip for example). The chin got the same treatment as the forehead. The process is entirely subjective, and will vary from person to person for the parameters. Experimentation is encouraged here.

More importantly, the key word to consider while working on skin tones is moderation. It is also important to check your results zoomed out, as this will give you an impression of the image as seen when scaled to something more web-sized. A good rule of thumb might be:

“If it looks good to you, go back and reduce the effect more”.

The original vs. results after wavelet smoothing:

When the work is finished on the wavelet scales, a new layer from all of the visible layers can be created to continue touching up spot areas that may need it.

Layer → New from Visible

Spot Touchups

The use of wavelets is good for a large-scale selection area smoothing but a different set of tools is required for spot touchups where needed. For example, there is a stray hair that runs across the models forehead that can be removed using the Heal tool.

For best results when using the Heal tool, use a hard edged brush. Soft edges can sometimes lead to a slight smearing in the feathered edge of a brush that is undesirable. Due to the nature of the heal algorithm sampling, it is also advisable to avoid trying to heal across hard/contrasty edges.

This is also a good tool to use for small blemishes that might have been tedious to repair across all of the wavelet scales from the previous section. This is also a good time to repair hot-spots, fly-away hairs, or other small details.

Sweater Enhancement

The model is wearing a nicely textured sweater but the details and texture are a slightly muted. A small increase in contrast and local details will help to bring some enhancement to the textures and tones. One method of enhancing local details would be to use the Unsharp Mask enhancement with a high radius and low amount (HiRaLoAm is an acronym some might use for this).

Create a duplicate of the “Spot Healing” layer that was worked on in the previous step, and apply an Unsharp Mask to the layer using HiRaLoAm values.

For example, a good starting point for parameters might be:

• Radius: 200
• Amount: 0.25

With these parameters the sharpen function will instead tend to increase local contrast more, providing more “presence” or “pop” to the sweater texture.

Background Rebuild

The background of the image is a little too uniformly dark and could benefit from some lightening and variation. A nice lighter background gradient will enhance the subject a little.

Normally this could be obtained through the use of a second strobe (probably gridded or with a snoot) firing at the background. In our case we will have to fake the same result through some masking.

First, a crop is chosen to focus the composition a little stronger on the subject. I placed the center of the models face along the right-side golden section vertical and tried to place things near the center of the frame:

The slight-centered crop is to emulate the type of crop that might be expected from a classical painting (thereby strengthening the overall theme of the portrait further).

Subject Isolation

There are a few different methods to approach the background modification. The method I describe here is simply one of them.

The image at this point is duplicated and the duplicate has the levels raised to brighten it up considerably. In this way, a simple layer mask can control the brightness and where it occurs in the image at this point.

This is what will give our background a gradient of light. To get our subject back to dark will require masking the subject on a layer mask again. A quick way to get a mask to work from is to add a layer mask to the “Over” layer, letting the background show through, but turning the subject opaque.

Add a layer mask to the “Over” layer as a “Grayscale copy of layer”, and check the “Invert mask” option:

With an initial mask in place, a quick use of the tool:

Colors → Threshold

will allow you to modify the mask to define the shoulder of the model as a good transition. The mask will be quite narrow. Adjust the threshold until the lighter background is speckle-free and there is a good definition of the edge of the sweater against the background.

Once the initial mask is in place it can be cleaned up further by making the subject entirely opaque (white on the mask), and the background fully transparent (black on the mask). This can be done with paint tools easily. For not much work a decent mask and result can be had:

This provides a nice contrast of the background being lighter behind the darker portions of the model and the opposite on the lighter subjects face.

Lighten Face Highlights

Speaking of the subjects face, there’s a nice simple method for applying a small accent on the highlighted portions of the models face in order to draw more attention to her.

Duplicate the lightened layer that was used to create the background gradient, move it to the top of the layer stack, and remove the layer mask from it.

Set the layer mode of the copied layer to “Lighten only.

As before, add a new layer mask to it, “Grayscale copy of layer”, but don’t check the “Invert mask” option. This time use the Levels tool:

Colors → Levels

to raise the blacks of the mask up to about mid-way or more. This will isolate the lightening mask to the brightest tones in the image that happen to correspond to the models face. You should see your adjustments modify the mask on-canvas in real-time. When you are happy with the highlights, apply.

Last Sharpening Pass + Grain

Finally, using I like to apply a last pass of sharpening to the image, and to overlay some grain from a grain field I have to help add some structure to the image as well as mask any gradient issues when rebuilding the background. For this particular image the grain step isn’t really needed as there’s already sufficient luma noise to provide its own structure.

Usually, I will use the smallest of the wavelet scales from the prior steps and sometimes the next largest scale as well (Wavelet scale 1 & 2). I’ll leave Wavelet scale 1 at 100% opacity, and scale 2 usually around 50% opacity (to taste, of course).

Minor touchups that could still be done might include darkening the chair in the bottom right corner, darkening the gradient in the bottom left corner, and possibly adding a slight white overlay to the eyes to subtly give them a small pop.

As it stands now I think the image is a decent representation of a chiaroscuro portrait that mimics the style of a classical composition and interplay between light and shadows across the subject.

HD Photo Slideshow with Blender

Because who doesn't love a challenge?

While I was out at Texas Linux Fest this past weekend I got to watch a fun presentation from the one and only Brian Beck. He walked through an introduction to Blender, including an overview of creating his great The Lady in the Roses image that was a part of the 2015 Libre Calendar project.

Coincidentally, during my trip home community member @Fotonut asked about software to create an HD slideshow with images. The first answer that jumped into my mind was to consider using Blender (a very close second was OpenShot because I had just spent some time talking with Jon Thomas about it).

I figured this much Blender being talked about deserved at least a post to answer @Fotonut‘s question in greater detail. I know that many community members likely abuse Blender in various ways as well – so please let me know if I get something way off!

Enter Blender

The reason that Blender was the first thing that popped into many folks minds when the question was posed is likely because it has been a go-to swiss-army knife of image and video creation for a long, long time. For some it was the only viable video editing application for heavy use (not that there weren’t other projects out there as well). This is partly due to to the fact that it integrates so much capability into a single project.

The part that we’re interested in for the context of Fotonut’s original question is the Video Sequence Editor (VSE). This is a very powerful (though often neglected) part of Blender that lets you arrange audio and video (and image!) assets along a timeline for rendering and some simple effects. Which is actually perfect for creating a simple HD slideshow of images, as we’ll see.

The Plan

Blenders interface is likely to take some getting used to for newcomers (right-click!) but we’ll be focusing on a very small subset of the overall program—so hopefully nobody gets lost. The overall plan will be:

1. Setup the environment for video sequence editing
2. Include assets (images) and how to manipulate them on the timeline
3. Add effects such as cross-fades between images
4. Setup exporting options

There’s also an option of using a very helpful add-on for automatically resizing images to the correct size to maintain their aspect ratios. Luckily, Blender’s add-on system makes it trivially easy to set up.

Setup

On opening Blender for the first time we’re presented with the comforting view of the default cube in 3D space. Don’t get too cozy, though. We’re about to switch up to a different screen layout that’s already been created for us by default for Video Editing.

The developers were nice enough to include various default “Screen Layout” options for different tasks, and one of them happens to be for Video Editing. We can click on the screen layout option on the top menu bar and choose the one we want from the list (Video Editing):

Our screen will then change to the new layout where the top left pane is the F-curve window, the top right is the video preview, the large center section is the sequencer, and the very bottom is a timeline. Blender will let you arrange, combine, and collapse all the various panes into just about any layout that you might want, including changing what each of them are showing. For our example we will mostly leave it all as-is with the exception of the F-curve pane, which we won’t be using and don’t need.

What we can do now is to define what the resolution and framerate of our project should be. This is done in the Properties pane, which isn’t shown right now. So we will change the F-Curve pane into the Properties pane by clicking on the button shown in red above to change the panel type. We want to choose Properties from the options in the list:

Which will turn the old F-Curve pane into the Properties pane:

You’ll want to set the appropriate X and Y resolution for your intended output (don’t forget to set the scaling from the default 50% to 100% now as well) as well as your intended framerate. Common rates might be 23.976 (23.98), 25, 30, or even 60 frames per second. If your intended target is something like YouTube or an HD television you can probably safely use 30 or 60 (just remember that a higher frame rate means a longer render time!).

For our example I’m going to set the output resolution to 1920 × 1080 at 30fps.

One Extra Thing

Blender does need a little bit of help when it comes to using images on the sequence editor. It has a habit of scaling images to whatever the output resolution is set to (ignoring the original aspect ratios). This can be fixed by simply applying a transform to the images but normally requires us to manually compute and enter the correct scaling factors to get the images back to their original aspect ratios.

I did find a nice small add-on on this thread at blenderartists.org that binds some handy shortcuts onto the VSE for us. The author kgeogeo has the add-on hosted on Github, and you can download the Python file directly from here: VSE Transform Tool (you can Right-Click and save the link). Save the .py file somewhere easy to find.

To load the add-on manually we’re going to change the Properties panel to User Preferences:

Click on the Add-ons tab to open that window and at the bottom of the panel is an option to “Install from File…”. Click that and navigate to the VSE_Transform_Tool.py file that you downloaded previously.

Once loaded, you’ll still need to Activate the plugin by clicking on the box:

That’s it! You’re now all set up to begin adding images and creating a slideshow. You can set the User Preferences pane back to Properties if you want to.

Adding Images

Let’s have a look at adding images onto the sequencer.

You can add images by either choosing Add → Image from the VSE menu and navigating to your images location, choosing them:

Or by drag-and-dropping your images onto the sequencer timeline from Nautilus, Finder, Explorer, etc…

When you do, you’ll find that a strip now appears on the VSE window (purple in my case) that represents your image. You should also see a preview of your video in the top-right preview window (sorry for the subject).

At this point we can use the handy add-on we installed previously by Right-Clicking on the purple strip to make sure it’s activated and then hitting the “T” key on the keyboard. This will automatically add a transform to the image that scales it to the correct aspect ratio for you. A small green Transform strip will appear above your purple image strip now:

Your image should now also be scaled to fit at the correct aspect ratio.

Adjusting the Image

If you scroll your mouse wheel in the VSE window, you will zoom in and out of time editor based on time (the x-axis in the sequencer window). You’ll notice that the time compresses or expands as you scroll the mouse wheel.

The middle-mouse button will let you pan around the sequencer.

The right-mouse button will select things. You can try this now by extending how long your image is displayed in the video. Right-Click on the small arrow on the end of the purple strip to activate it. A small number will appear above it indicating which frame it is currently on (26 in my example):

With the right handle active you can now either press “G” on the keyboard and drag the mouse to re-position the end of the strip, or Right-Click and drag to do the same thing. The timeline in seconds is shown along the bottom of the window for reference. If we wanted to let the image be visible for 5 seconds total, we could drag the end to the 5+00 mark on the sequencer window.

Since I set the framerate to 30 frames per second, I can also drag the end to frame 150 (30fps * 5s = 150 frames).

When you drag the image strip, the transform strip will automatically adjust to fit (so you don’t have to worry about it).

If you had selected the center of the image strip instead of the handle on one end and tried to move it, you would find that you can move the entire strip around instead of one end. This is how you can re-position image strips, which you may want to do when you add a second image to your sequencer.

Add a new image to your sequencer now following the same steps as above.

When I do, it adds a new strip back at the beginning of the timeline (basically where the current time is set):

I want to move this new strip so that it overlaps my first image by about half a second (or 15 frames). Then I will pull the right handle to resize the display time to about 5 seconds also.

Click on the new strip (center, not the ends), and press the “G” key to move it. Drag it right until the left side overlaps the previous image strip by a little bit:

When you click on the strip right handle to modify it’s length, notice the window on the far right of the VSE. The Edit Strip window should also show the strip “Length” parameter in case you want to change it by manually inputting a value (like 150):

I forgot to use the add-on to automatically fix the aspect ratio. With the strip selected I can press “T” at any time to invoke the add-on and fix the aspect ratio.

Adding a Transition Effect

With the two image strips slightly overlapping, we now want to define a simple cross fade between the two images as a transition effect. This is actually something alreayd built into the Blender VSE for us, and is easy to add. We _do_ need to be careful to select the right things to get the transition working correctly, though.

Once you’ve added a transform effect to a strip, you’ll need to make sure that subsequent operations use the transform strip as opposed to the original image strip.

For instance, to add a cross fade transition between these two images, click the first image strip transform (green), then Shift-Click on the second image transform strip (green). Now they are both selected, so add a Gamma Cross by using the Add menu in the VSE (Add → Effect Strip… → Gamma Cross):

This will add a Gamma Cross effect as a new strip that is locked to the two images overlap. It will do a cross-fade between the two images for the duration of the overlap. You can Left-Click now and scrub over the cross-fade strip to see it rendered in the preview window if you’d like:

At any time you can also use the hotkey “Alt-A” to view a render preview. This may run slow if your machine is not super-fast, but it should run enough to give you a general sense of what you’ll get.

If you want to modify the transition effect by changing its length, you can just increase the overlap between the strips as desired (using the original image strip — if you try to drag the transform strip you’ll find it locked to the original image strip and won’t move).

Repeat Repeat

You can basically follow these same steps for as many images as you’d like to include.

Exporting

To generate your output you’ll still need to change a couple of things to get what you want…

Render Length

You may notice on the VSE that there are vertical lines outside of which things will appear slightly grayed out. This is a visual indicator of the total start/end of the output. This is controlled via the Start and End frame settings on the timeline (bottom pane):

You’ll need to set the End value to match your last output frame from your video sequence. You can find this value by selecting the last strip in your sequence and pressing the “G” key: the start/end frame numbers of that last strip will be visible (you’ll want the last frame value, of course).

In my example above, my anticipated last frame should be 284, but the last render frame is currently set to 250. I would need to update that End frame to match my video to get output as expected.

Render Format

Back on the Properties panel (assuming you set the top-left panel back to Properties earlier—if not do so now), if we scroll down a bit we should see a section dedicated to Output.

You can change the various output options here to do frame-by-frame dumps or to encode everything into a video container of some sort. You can set the output directory to be something different if you don’t want it rendered into /tmp here.

For my example I will encode the video with H.264:

By choosing this option, Blender will then expose a new section of the Properties panel for setting the Encoding options:

I will often use the H264 preset and will enable the Lossless Output checkbox option. If I don’t have the disk space to spare I can also set different options to shrink the resulting filesize down further. The Bitrate option will have the largest effect on final file size and image quality.

When everything is ready (or you just want to test it out), you can render your output by scrolling back to the top of the Properties window and pressing the Animation button, or by hitting Ctrl-F12.

The Results

After adding portraits of all of the GIMP team from LGM London and adding gamma cross fade transitions, here are my results:

In Summary

This may seem overly complicated, but in reality much of what I covered here is the setup to get started and the settings for output. Once you’ve done this successfully it becomes pretty quick to use. One thing you can do is set up the environment the way you like it and then save the .blend file to use as a template for further work like this in the future. The next time you need to generate a slideshow you’ll have everything all ready to go and will only need to start adding images to the editor.

While looking for information on some VSE shortcuts I did run across a really interesting looking set of functions that I want to try out: the Blender Velvets. I’m going to go off and give it a good look when I get a chance as there’s quite a few interesting additions available.

For Blender users: did I miss anything?

Texas Linux Fest 2016

Everything's Bigger in Texas!

While in London this past April I got a chance to hang out a bit with LWN.net editor and fellow countryman, Nathan Willis. (It sounds like the setup for a bad joke: “An Alabamian and Texan meet in a London pub…”). Which was awesome because even though we were both at LGM2014, we never got a chance to sit down and chat.

So it was super-exciting for me to hear from Nate about possibly doing a photowalk and Free Software photo workshop at the 2016 Texas Linux Fest, and as soon as I cleared it with my boss, I agreed!

So… mosey on down to Austin, Texas on July 8-9 for Texas Linux Fest and join Akkana Peck and myself for a photowalk first thing of the morning on Friday (July 8) to be immediately followed by workshops from both of us. I’ll be talking about Free Software photography workflows and projects and Akkana will be focusing on a GIMP workshop.

This is part of a larger “Open Graphics” track on the entire first day that also includes Ted Gould creating technical diagrams using Inkscape, Brian Beck doing a Blender tutorial, and Jonathon Thomas showing off OpenShot 2.0. You can find the full schedule on their website.

I hope to see some of you there!

Color Manipulation with the Colour Checker LUT Module

hanatos tinkering in darktable again...

I was lucky to get to spend some time in London with the darktable crew. Being the wonderful nerds they are, they were constantly working on something while we were there. One of the things that Johannes was working on was the colour checker module for darktable.

Having recently acquired a Fuji camera, he was working on matching color styles from the built-in rendering on the camera. Here he presents some of the results of what he was working on.

This was originally published on the darktable blog, and is being republished here with permission. —Pat

motivation

for raw photography there exist great presets for nice colour rendition:

• in-camera colour processing such as canon picture styles
• fuji film-emulation-like presets (provia velvia astia classic-chrome)
• pat david’s film emulation luts

unfortunately these are eat-it-or-die canned styles or icc lut profiles. you have to apply them and be happy or tweak them with other tools. but can we extract meaning from these presets? can we have understandable and tweakable styles like these?

in a first attempt, i used a non-linear optimiser to control the parameters of the modules in darktable’s processing pipeline and try to match the output of such styles. while this worked reasonably well for some of pat’s film luts, it failed completely on canon’s picture styles. it was very hard to reproduce generic colour-mapping styles in darktable without parametric blending.

that is, we require a generic colour to colour mapping function. this should be equally powerful as colour look up tables, but enable us to inspect it and change small aspects of it (for instance only the way blue tones are treated).

overview

in git master, there is a new module to implement generic colour mappings: the colour checker lut module (lut: look up table). the following will be a description how it works internally, how you can use it, and what this is good for.

in short, it is a colour lut that remains understandable and editable. that is, it is not a black-box look up table, but you get to see what it actually does and change the bits that you don’t like about it.

the main use cases are precise control over source colour to target colour mapping, as well as matching in-camera styles that process raws to jpg in a certain way to achieve a particular look. an example of this are the fuji film emulation modes. to this end, we will fit a colour checker lut to achieve their colour rendition, as well as a tone curve to achieve the tonal contrast.

to create the colour lut, it is currently necessary to take a picture of an it8 target (well, technically we support any similar target, but didn’t try them yet so i won’t really comment on it). this gives us a raw picture with colour values for a few colour patches, as well as a in-camera jpg reference (in the raw thumbnail..), and measured reference values (what we know it should look like).

to map all the other colours (that fell in between the patches on the chart) to meaningful output colours, too, we will need to interpolate this measured mapping.

theory

we want to express a smooth mapping from input colours \(\mathbf{s}\) to target colours \(\mathbf{t}\), defined by a couple of sample points (which will in our case be the 288 patches of an it8 chart).

the following is a quick summary of what we implemented and much better described in JP’s siggraph course [0].

radial basis functions

radial basis functions are a means of interpolating between sample points via

$$f(x) = \sum_i c_i\cdot\phi(| x - s_i|),$$

with some appropriate kernel \(\phi(r)\) (we’ll get to that later) and a set of coefficients \(c_i\) chosen to make the mapping \(f(x)\) behave like we want it at and in between the source colour positions \(s_i\). now to make sure the function actually passes through the target colours, i.e. \(f(s_i) = t_i\), we need to solve a linear system. because we want the function to take on a simple form for simple problems, we also add a polynomial part to it. this makes sure that black and white profiles turn out to be black and white and don’t oscillate around zero saturation colours wildly. the system is

$$ \left(\begin{array}{cc}A &P\\P^t & 0\end{array}\right) \cdot \left(\begin{array}{c}\mathbf{c}\\\mathbf{d}\end{array}\right) = \left(\begin{array}{c}\mathbf{t}\\0\end{array}\right)$$

where

$$ A=\left(\begin{array}{ccc} \phi(r_{00})& \phi(r_{10})& \cdots \\ \phi(r_{01})& \phi(r_{11})& \cdots \\ \phi(r_{02})& \phi(r_{12})& \cdots \\ \cdots & & \cdots \end{array}\right),$$

and \(r_{ij} = | s_i - t_j |\) is the distance (CIE 76 \(\Delta\)E, \(\sqrt{(L_s - L_t)^2 + (a_s - a_t)^2 + (b_s - b_t)^2}\) ) between source colour \(s_i\) and target colour \(t_j\), in our case

$$P=\left(\begin{array}{cccc} L_{s_0}& a_{s_0}& b_{s_0}& 1\\ L_{s_1}& a_{s_1}& b_{s_1}& 1\\ \cdots \end{array}\right)$$

is the polynomial part, and \(\mathbf{d}\) are the coefficients to the polynomial part. these are here so we can for instance easily reproduce \(t = s\) by setting \(\mathbf{d} = (1, 1, 1, 0)\) in the respective row. we will need to solve this system for the coefficients \(\mathbf{c}=(c_0,c_1,\cdots)^t\) and \(\mathbf{d}\).

many options will do the trick and solve the system here. we use singular value decomposition in our implementation. one advantage is that it is robust against singular matrices as input (accidentally map the same source colour to different target colours for instance).

thin plate splines

we didn’t yet define the radial basis function kernel. it turns out so-called thin plate splines have very good behaviour in terms of low oscillation/low curvature of the resulting function. the associated kernel is

$$\phi(r) = r^2 \log r.$$

note that there is a similar functionality in gimp as a gegl colour mapping operation (which i believe is using a shepard-interpolation-like scheme).

creating a sparse solution

we will feed this system with 288 patches of an it8 colour chart. that means, with the added four polynomial coefficients, we have a total of 292 source/target colour pairs to manage here. apart from performance issues when executing the interpolation, we didn’t want that to show up in the gui like this, so we were looking to reduce this number without introducing large error.

indeed this is possible, and literature provides a nice algorithm to do so, which is called orthogonal matching pursuit [1].

this algorithm will select the most important hand full of coefficients \(\in \mathbf{c},\mathbf{d}\), to keep the overall error low. In practice we run it up to a predefined number of patches (\(24=6\times 4\) or \(49=7\times 7\)), to make best use of gui real estate.

the colour checker lut module

gui elements

when you select the module in darkroom mode, it should look something like the image above (configurations with more than 24 patches are shown in a 7\(\times\)7 grid instead). by default, it will load the 24 patches of a colour checker classic and initialise the mapping to identity (no change to the image).

• the grid shows a list of coloured patches. the colours of the patches are the source points \(\mathbf{s}\).
• the target colour \(t_i\) of the selected patch \(i\) is shown as offset controlled by sliders in the ui under the grid of patches.
• an outline is drawn around patches that have been altered, i.e. the source and target colours differ.
• the selected patch is marked with a white square, and the number shows in the combo box below.

interaction

to interact with the colour mapping, you can change both source and target colours. the main use case is to change the target colours however, and start with an appropriate palette (see the presets menu, or download a style somewhere).

• you can change lightness (L), green-red (a), blue-yellow (b), or saturation (C) of the target colour via sliders.
• select a patch by left clicking on it, or using the combo box, or using the colour picker
• to change source colour, select a new colour from your image by using the colour picker, and shift-left-click on the patch you want to replace.
• to reset a patch, double-click it.
• right-click a patch to delete it.
• shift-left-click on empty space to add a new patch (with the currently picked colour as source colour).

example use cases

example 1: dodging and burning with the skin tones preset

to process the following image i took of pat in the overground, i started with the skin tones preset in the colour checker module (right click on nothing in the gui or click on the icon with the three horizontal lines in the header and select the preset).

then, i used the colour picker (little icon to the right of the patch# combo box) to select two skin tones: very bright highlights and dark shadow tones. the former i dragged the brightness down a bit, the latter i brightened up a bit via the lightness (L) slider. this is the result:

example 2: skin tones and eyes

in this image, i started with the fuji classic chrome-like style (see below for a download link), to achieve the subdued look in the skin tones. then, i picked the iris colour and saturated this tone via the saturation slider.

as a side note, the flash didn’t fire in this image (iso 800) so i needed to stop it up by 2.5ev and the rest is all natural lighting..

use darktable-chart to create a style

as a starting point, i matched a colour checker lut interpolation function to the in-camera processing of fuji cameras. these have the names of old film and generally do a good job at creating pleasant colours. this was done using the darktable-chart utility, by matching raw colours to the jpg output (both in Lab space in the darktable pipeline).

here is the link to the fuji styles, and how to use them. i should be doing pat’s film emulation presets with this, too, and maybe styles from other cameras (canon picture styles?). darktable-chart will output a dtstyle file, with the mapping split into tone curve and colour checker module. this allows us to tweak the contrast (tone curve) in isolation from the colours (lut module).

these styles were created with the X100T model, and reportedly they work so/so with different camera models. the idea is to create a Lab-space mapping which is well configured for all cameras. but apparently there may be sufficient differences between the output of different cameras after applying their colour matrices (after all these matrices are just an approximation of the real camera to XYZ mapping).

so if you’re really after maximum precision, you may have to create the styles yourself for your camera model. here’s how:

step-by-step tutorial to match the in-camera jpg engine

note that this is essentially similar to pascal’s colormatch script, but will result in an editable style for darktable instead of a fixed icc lut.

• need an it8 (sorry, could lift that, maybe, similar to what we do for basecurve fitting)

• shoot the chart with your camera:

  • shoot raw + jpg
  • avoid glare and shadow and extreme angles, potentially the rims of your image altogether
  • shoot a lot of exposures, try to match L=92 for G00 (or look that up in your it8 description)

• develop the images in darktable:

  • lens and vignetting correction needed on both or on neither of raw + jpg
  • (i calibrated for vignetting, see lensfun)
  • output colour space to Lab (set the secret option in darktablerc: allow_lab_output=true)
  • standard input matrix and camera white balance for the raw, srgb for jpg.
  • no gamut clipping, no basecurve, no anything else.
  • maybe do perspective correction and crop the chart
  • export as float pfm

• darktable-chart

  • load the pfm for the raw image and the jpg target in the second tab
  • drag the corners to make the mask match the patches in the image
  • maybe adjust the security margin using the slider in the top right, to avoid stray colours being blurred into the patch readout
  • you need to select the gray ramp in the combo box (not auto-detected)
  • export csv

edit the csv in a text editor and manually add two fixed fake patches HDR00 and HDR01:

name;fuji classic chrome-like
description;fuji classic chrome-like colorchecker
num_gray;24
patch;L_source;a_source;b_source;L_reference;a_reference;b_reference
A01;22.22;13.18;0.61;21.65;17.48;3.62
A02;23.00;24.16;4.18;26.92;32.39;11.96
...
HDR00;100;0;0;100;0;0
HDR01;200;0;0;200;0;0
...

this is to make sure we can process high-dynamic range images and not destroy the bright spots with the lut. this is needed since the it8 does not deliver any information out of the reflective gamut and for very bright input. to fix wide gamut input, it may be needed to enable gamut clipping in the input colour profile module when applying the resulting style to an image with highly saturated colours. darktable-chart does that automatically in the style it writes.

• fix up style description in csv if you want
• run darktable-chart --csv
• outputs a .dtstyle with everything properly switched off, and two modules on: colour checker + tonecurve in Lab

fitting error

when processing the list of colour pairs into a set of coefficients for the thin plate spline, the program will output the approximation error, indicated by average and maximum CIE 76 \(\Delta\)E for the input patches (the it8 in the examples here). of course we don’t know anything about colours which aren’t represented in the patch. the hope would be that the sampling is dense enough for all intents and purposes (but nothing is holding us back from using a target with even more patches).

for the fuji styles, these errors are typically in the range of mean \(\Delta E\approx 2\) and max \(\Delta E \approx 10\) for 24 patches and a bit less for 49. unfortunately the error does not decrease very fast in the number of patches (and will of course drop to zero when using all the patches of the input chart).

provia 24:rank 28/24 avg DE 2.42189 max DE 7.57084
provia 49:rank 53/49 avg DE 1.44376 max DE 5.39751

astia-24:rank 27/24 avg DE 2.12006 max DE 10.0213
astia-49:rank 52/49 avg DE 1.34278 max DE 7.05165

velvia-24:rank 27/24 avg DE 2.87005 max DE 16.7967
velvia-49:rank 53/49 avg DE 1.62934 max DE 6.84697

classic chrome-24:rank 28/24 avg DE 1.99688 max DE 8.76036
classic chrome-49:rank 53/49 avg DE 1.13703 max DE 6.3298

mono-24:rank 27/24 avg DE 0.547846 max DE 3.42563
mono-49:rank 52/49 avg DE 0.339011 max DE 2.08548

future work

it is possible to match the reference values of the it8 instead of a reference jpg output, to calibrate the camera more precisely than the colour matrix would.

• there is a button for this in the darktable-chart tool
• needs careful shooting, to match brightness of reference value closely.
• at this point it’s not clear to me how white balance should best be handled here.
• need reference reflectances of the it8 (wolf faust ships some for a few illuminants).

another next step we would like to take with this is to match real film footage (porta etc). both reference and film matching will require some global exposure calibration though.

references

• [0] Ken Anjyo and J. P. Lewis and Frédéric Pighin, “Scattered data interpolation for computer graphics” in Proceedings of SIGGRAPH 2014 Courses, Article No. 27, 2014. pdf
• [1] J. A. Tropp and A. C. Gilbert, “Signal Recovery From Random Measurements Via Orthogonal Matching Pursuit”, in IEEE Transactions on Information Theory, vol. 53, no. 12, pp. 4655-4666, Dec. 2007.

links

• pat david’s film emulation luts
• download fuji styles
• darktable’s user manual on styles
• it8 target
• pascal’s colormatch
• lensfun calibration
• perspective correction in darktable
• fit basecurves for darktable

Sharing is Caring

Letting it all hang out

It was always my intention to make the entire PIXLS.US website available under a permissive license. The content is already all licensed Creative Commons, By Attribution, Share-Alike (unless otherwise noted). I just hadn’t gotten around to actually posting the site source.

Until now(ish). I say “ish“ because I apparently released the code back in April and am just now getting around to talking about it.

Also, we finally have a category specifically for all those darktable weenies on discuss!

Don’t Laugh

I finally got around to pushing my code for this site up to Github on April 27 (I’m basing this off git logs because my memory is likely suspect). It took a while, but better late than never? I think part of the delay was a bit of minor embarrassment on my part for being so sloppy with the site code. In fact, I’m still embarrassed - so don’t laugh at me too hard (and if you do, at least don’t point while laughing too).

So really this post is just a reminder to anyone that was interested that this site is available on Github:

https://github.com/pixlsus/

In fact, we’ve got a couple of other repositories under the Github Organization PIXLS.US including this website, presentation assets, lighting diagram SVG’s, and more. If you’ve got a Github account or wanted to join in with hacking at things, by all means send me a note and we’ll get you added to the organization asap.

Note: you don’t need to do anything special if you just want to grab the site code. You can do this quickly and easily with:

git clone https://github.com/pixlsus/website.git

You actually don’t even need a Github account to clone the repo, but you will need one if you want to fork it on Github itself, or to send pull-requests. You can also feel free to simply email/post patches to us as well:

git format-patch testing --stdout > your_awesome_work.patch

Being on Github means that we also now have an issue tracker to report any bugs or enhancements you’d like to see for the site.

So no more excuses - if you’d like to lend a hand just dive right in! We’re all here to help! :)

Speaking of Helping

Speaking of which, I wanted to give a special shout-out to community member @paperdigits (Mica), who has been active in sharing presentation materials in the Presentations repo and has been actively hacking at the website. Mica’s recommendations and pull requests are helping to make the site code cleaner and better for everyone, and I really appreciate all the help (even if I _am_ scared of change).

Thank you, Mica! You rock!

Those Stinky darktable People

Yes, after member Claes asked the question on discuss about why we didn’t have a darktable category on the forums, I relented and created one. Normally I want to make sure that any category is going to have active people to maintain and monitor the topics there. I feel like having an empty forum can sometimes be detrimental to the perception of a project/community.

In this case, any topics in the darktable category will also show up in the more general Software category as well. This way the visibility and interactions are still there, but with the added benefit that we can now choose to see only darktable posts, ignore them, or let all those stinky users do what they want in there.

Besides, now we can say that we’ve sufficiently appeased Morgan Hardwood‘s organizational needs…

So, come on by and say hello in the brand new darktable category!

Sharing Galore

or, Why This Community is Awesome

Community member and RawTherapee hacker Morgan Hardwood brings us a great tutorial + assets from one of his strolls near the Söderåsen National Park (Sweden!). Ofnuts is apparently trying to get me to burn the forum down by sharing his raw file of a questionable subject. After bugging David Tschumperlé he managed to find a neat solution to generating a median (pixel) blend of a large number of images without making your computer throw itself out a window.

So much neat content being shared for everyone to play with and learn from! Come see what everyone is doing!

Old Oak - A Tutorial

Sometimes you’re just hanging out minding your own business and talking photography with friends and other Free Software nuts when someone comes running by and drops a great tutorial in your lap. Just as Morgan Hardwood did on the forums a few days ago!

He introduces the image and post:

There is an old oak by the southern entrance to the Söderåsen National Park. Rumor has it that this is the oak under which Gandalf sat as he smoked his pipe and penned the famous saga about J.R.R. Tolkien. I don’t know about that, but the valley rabbits sure love it.

The image itself is a treat. I personally love images where the lighting does interesting things and there are some gorgeous things going on in this image. The diffused light flooding in under the canopy on the right with the edge highlights from the light filtering down make this a pleasure to look at.

Of course, Morgan doesn’t stop there. You should absolutely go read his entire post. He not only walks through his entire thought process and workflow starting at his rationale for lens selection (50mm f/2.8) all the way through his corrections and post-processing choices. To top it all off, he has graciously shared his assets for anyone to follow along! He provides the raw file, the flat-field, a shot of his color target + DCP, and finally his RawTherapee .PP3 file with all of his settings! Whew!

If you’re interested I urge you to go check out (and participate!) in his topic on the forums: Old Oak - A Tutorial.

I Will Burn This Place to the Ground

Speaking of sharing material, Ofnuts has decided that he apparently wants me to burn the forums to the ground, put the ashes in a spaceship, fly the spaceship into the sun, and to detonate the entire solar system into a singularity. Why do I say this?

Because he started a topic appropriately entitled: “NSFPAOA (Not Suitable for Pat and Other Arachnophobes)”, in which he shares his raw .CR2 file for everyone to try their hand at processing that cute little spider above. There have already been quite a few awesome interpretations from folks in the community like:

Of course, I had a chance to try processing it as well. Here’s what I ended up with:

Ahhhh, just writing this post is a giant bag of NOPE^*. If you’d like to join in on the fun(?) and share your processing as well - go check out the topic!

Now let’s move on to something more cute and fuzzy, like an ALOT…

^* I kid, I’m not really an arachnophobe (within reason), but I can totally see why someone would be.

Median Blending ALOT of Images with G’MIC

I count myself lucky to have so many smart friends that I can lean on to figure out or help me do things (more on that in the next post). One of those friends is G’MIC creator and community member David Tschumperlé.

A few years back he helped me with some artwork I was generating with imagemagick at the time. I was averaging images together to see what an amalgamation would look like. For instance, here is what all of the Sports Illustrated swimsuit edition (NSFW) covers (through 2000) look like, all at once:

A natural progression of this idea was to consider doing a median blend vs. mean. The problem is that a mean average is very easy and fast to calculate as you advance through the image stack, but the median is not. This is relevant because I began to look at these for videos (in particular music videos), where the image stack was 5,000+ images for a video easily (that is ALOT of frames!).

It’s relatively easy to generate a running average for a series of numbers, but generating the median value requires that the entire stack of numbers be loaded and sorted. This makes it prohibitive to do on a huge number of images, particularly at HD resolutions.

So it’s awesome that, yet again, David has found a solution to the problem! He explains it in greater detail on his topic:

A guide about computing the temporal average/median of video frames with G’MIC

He basically chops up the image frame into regions, then computes the pixel-median value for those regions. Here’s an example of his result:

Now I can start utilizing median blends more often in my experiments, and I’m quite sure folks will find other interesting uses for this type of blending!