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!

Books, culture and more from the TLS podcast, with Stig Abell and Thea Lenarduzzi – this week featuring: Athelstan – Britain's forgotten king; Mary Beard on the ancient precedent of our very modern referendum; a philosophical look at the ugly; English Country Houses, real and literary; and a poem, "Visiting Europe", by Bill Manhire

---

Hosted on Acast. See acast.com/privacy for more information.

💾

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

Books, culture and more from the TLS podcast – this week featuring: responses to the refugee crisis, political and literary; the new Tate in London; Turkey's secular spaces; and a poem by Stephen Knight.

---

Hosted on Acast. See acast.com/privacy for more information.

💾

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!

Display Color Profiling on Linux

A work in progress

This article by Pascal de Bruijn was originally published on his site and is reproduced here with permission.  —Pat

---

Attention: This article is a work in progress, based on my own practical experience up until the time of writing, so you may want to check back periodically to see if it has been updated.

This article outlines how you can calibrate and profile your display on Linux, assuming you have the right equipment (either a colorimeter like for example the i1 Display Pro or a spectrophotometer like for example the ColorMunki Photo). For a general overview of what color management is and details about some of its parlance you may want to read this before continuing.

A Fresh Start

First you may want to check if any kind of color management is already active on your machine, if you see the following then you’re fine:

$ xprop -display :0.0 -len 14 -root _ICC_PROFILE
_ICC_PROFILE: no such atom on any window.

However if you see something like this, then there is already another color management system active:

$ xprop -display :0.0 -len 14 -root _ICC_PROFILE
_ICC_PROFILE(CARDINAL) = 0, 0, 72, 212, 108, 99, 109, 115, 2, 32, 0, 0, 109, 110

If this is the case you need to figure out what and why… For GNOME/Unity based desktops this is fairly typical, since they extract a simple profile from the display hardware itself via EDID and use that by default. I’m guessing KDE users may want to look into this before proceeding. I can’t give much advice about other desktop environments though, as I’m not particularly familiar with them. That said, I tested most of the examples in this article with XFCE 4.10 on Xubuntu 14.04 “Trusty”.

Display Types

Modern flat panel displays are comprised of two major components for purposes of our discussion, the backlight and the panel itself. There are various types of backlights, White LED (most common nowadays), CCFL (most common a few years ago), RGB LED and Wide Gamut CCFL, the latter two of which you’d typically find on higher end displays. The backlight primarily defines a displays gamut and maximum brightness. The panel on the other hand primarily defines the maximum contrast and acceptable viewing angles. Most common types are variants of IPS (usually good contrast and viewing angles) and TN (typically mediocre contrast and poor viewing angles).

Display Setup

There are two main cases, there are laptop displays, which usually allow for little configuration, and regular desktop displays. For regular displays there are a few steps to prepare your display to be profiled, first you need to reset your display to its factory defaults. We leave the contrast at its default value. If your display has a feature called dynamic contrast you need to disable it, this is critical, if you’re unlucky enough to have a display for which this cannot be disabled, then there is no use in proceeding any further. Then we set the color temperature setting to custom and set the R/G/B values to equal values (often 100/100/100 or 255/255/255). As for the brightness, set it to a level which is comfortable for prolonged viewing, typically this means reducing the brightness from its default setting, this will often be somewhere around 25–50 on a 0–100 scale. Laptops are a different story, often you’ll be fighting different lighting conditions, so you may want to consider profiling your laptop at its full brightness. We’ll get back to the brightness setting later on.

Before continuing any further, let the display settle for at least half an hour (as its color rendition may change while the backlight is warming up) and make sure the display doesn’t go into power saving mode during this time.

Another point worth considering is cleaning the display before starting the calibration and profiling process, do keep in mind that displays often have relatively fragile coatings, which may be deteriorated by traditional cleaning products, or easily scratched using regular cleaning cloths. There are specialist products available for safely cleaning computer displays.

You may also want to consider dimming the ambient lighting while running the calibration and profiling procedure to prevent (potential) glare from being an issue.

Software

If you’re in a GNOME or Unity environment it’s highly recommend to use GNOME Color Manager (with colord and argyll). If you have recent versions (3.8.3, 1.0.5, 1.6.2 respectively), you can profile and setup your display completely graphically via the Color applet in System Settings. It’s fully wizard driven and couldn’t be much easier in most cases. This is what I personally use and recommend. The rest of this article focuses on the case where you are not using it.

Xubuntu users in particular can get experimental packages for the latest argyll and optionally xiccd from my xiccd-testing PPAs. If you’re using a different distribution you’ll need to source help from its respective community.

Report On The Uncalibrated Display

To get an idea of the displays uncalibrated capabilities we use argyll’s dispcal:

$ dispcal -H -y l -R
Uncalibrated response:
Black level = 0.4179 cd/m^2
50%   level = 42.93 cd/m^2
White level = 189.08 cd/m^2
Aprox. gamma = 2.14
Contrast ratio = 452:1
White     Visual Daylight Temperature = 7465K, DE 2K to locus =  3.2

Here we see the display has a fairly high uncalibrated native whitepoint at almost 7500K, which means the display is bluer than it should be. When we’re done you’ll notice the display becoming more yellow. If your displays uncalibrated native whitepoint is below 6500K you’ll notice it becoming more blue when loading the profile.

Another point to note is the fairly high white level (brightness) of almost 190 cd/m², it’s fairly typical to target 120 cd/m² for the final calibration, keeping in mind that we’ll lose 10 cd/m² or so because of the calibration itself. So if your display reports a brightness significantly higher than 130 cd/m² you may want to considering turning down the brightness another notch.

Calibrating And Profiling Your Display

First we’ll use argyll’s dispcal to measure and adjust (calibrate) the display, compensating for the displays whitepoint (targeting 6500K) and gamma (targeting industry standard 2.2, more info on gamma here):

$ dispcal -v -m -H -y l -q l -t 6500 -g 2.2 asus_eee_pc_1215p

Next we’ll use argyll’s targen to generate measurement patches to determine its gamut:

$ targen -v -d 3 -G -f 128 asus_eee_pc_1215p

Then we’ll use argyll’s dispread to apply the calibration file generated by dispcal, and measure (profile) the displays gamut using the patches generated by targen:

$ dispread -v -N -H -y l -k asus_eee_pc_1215p.cal asus_eee_pc_1215p

Finally we’ll use argyll’s colprof to generate a standardized ICC (version 2) color profile:

$ colprof -v -D "Asus Eee PC 1215P" -C "Copyright 2013 Pascal de Bruijn" \
          -q m -a G -n c asus_eee_pc_1215p
Profile check complete, peak err = 9.771535, avg err = 3.383640, RMS = 4.094142

The parameters used to generate the ICC color profile are fairly conservative and should be fairly robust. They will likely provide good results for most use-cases. If you’re after better accuracy you may want to try replacing -a G with -a S or even -a s, but I very strongly recommend starting out using -a G.

You can inspect the contents of a standardized ICC (version 2 only) color profile using argyll’s iccdump:

$ iccdump -v 3 asus_eee_pc_1215p.icc

To try the color profile we just generated we can quickly load it using argyll’s dispwin:

$ dispwin -I asus_eee_pc_1215p.icc

Now you’ll likely see a color shift toward the yellow side. For some possibly aged displays you may notice it shifting toward the blue side.

If you’ve used a colorimeter (as opposed to a spectrophotometer) to profile your display and if you feel the profile might be off, you may want to consider reading this and this.

Report On The Calibrated Display

Next we can use argyll’s dispcal again to check our newly calibrated display:

$ dispcal -H -y l -r
Current calibration response:
Black level = 0.3432 cd/m^2
50%   level = 40.44 cd/m^2
White level = 179.63 cd/m^2
Aprox. gamma = 2.15
Contrast ratio = 523:1
White     Visual Daylight Temperature = 6420K, DE 2K to locus =  1.9

Here we see the calibrated displays whitepoint nicely around 6500K as it should be.

Loading The Profile In Your User Session

If your desktop environment is XDG autostart compliant, you may want to considering creating a .desktop file which will load the ICC color profile during all users session login:

$ cat /etc/xdg/autostart/dispwin.desktop
[Desktop Entry]
Encoding=UTF-8
Name=Argyll dispwin load color profile
Exec=dispwin -I /usr/share/color/icc/asus_eee_pc_1215p.icc
Terminal=false
Type=Application
Categories=

Alternatively you could use colord and xiccd for a more sophisticated setup. If you do make sure you have recent versions of both, particularly for xiccd as it’s still a fairly young project.

First we’ll need to start xiccd (in the background), which detects your connected displays and adds it to colord‘s device inventory:

$ nohup xiccd &

Then we can query colord for its list of available devices:

$ colormgr get-devices

Next we need to query colord for its list of available profiles (or alternatively search by a profile’s full filename):

$ colormgr get-profiles
$ colormgr find-profile-by-filename /usr/share/color/icc/asus_eee_pc_1215p.icc

Next we’ll need to assign our profile’s object path to our display’s object path:

$ colormgr device-add-profile \
   /org/freedesktop/ColorManager/devices/xrandr_HSD121PHW1_70842_pmjdebruijn_1000 \
   /org/freedesktop/ColorManager/profiles/icc_e7fc40cb41ddd25c8d79f1c8d453ec3f

You should notice your displays color shift within a second or so (xiccd applies it asynchronously), assuming you haven’t already applied it via dispwin earlier (in which case you’ll notice no change).

If you suspect xiccd isn’t properly working, you may be able to debug the issue by stopping all xiccd background processes, and starting it in debug mode in the foreground:

$ killall xiccd
$ G_MESSAGES_DEBUG=all xiccd

Also in xiccd‘s case you’ll need to create a .desktop file to load xiccd during all users session login:

$ cat /etc/xdg/autostart/xiccd.desktop
[Desktop Entry]
Encoding=UTF-8
Name=xiccd
GenericName=X11 ICC Daemon
Comment=Applies color management profiles to your session
Exec=xiccd
Terminal=false
Type=Application
Categories=
OnlyShowIn=XFCE;

You’ll note that xiccd does not need any parameters, since it will query colord‘s database what profile to load.

If your desktop environment is not XDG autostart compliant, you need to ask them how to start custom commands (dispwin or xiccd respectively) during session login.

Dual Screen Caveats

Currently having a dual screen color managed setup is complicated at best. Most programs use the _ICC_PROFILE atom to get the system display profile, and there’s only one such atom. To resolve this issue new atoms were defined to support multiple displays, but not all applications actually honor them. So with a dual screen setup there is always a risk of applications applying the profile for your first display to your second display or vice versa.

So practically speaking, if you need a reliable color managed setup, you should probably avoid dual screen setups altogether.

That said, most of argyll’s commands support a -d parameter for selecting which display to work with during calibration and profiling, but I have no personal experience with them whatsoever, since I purposefully don’t have a dual screen setup.

Application Support Caveats

As my other article explains display color profiles consist of two parts, one part (whitepoint & gamma correction) is applied via X11 and thus benefits all applications. There is however a second part (gamut correction) that needs to be applied by the application. And application support for both input and display color management vary wildly. Many consumer grade applications have no color management awareness whatsoever.

Firefox can do color management and it’s half-enabled by default, read this to properly configure Firefox.

GIMP for example has display color management disabled by default, you need to enable it via its preferences.

Eye of GNOME has display color management enabled by default, but it has nasty corner case behaviors, for example when a file has no metadata no color management is done at all (instead of assuming sRGB input). Some of these issues seem to have been resolved on Ubuntu Trusty (LP #272584).

Darktable has display color management enabled by default and is one of the few applications which directly support colord and the display specific atoms as well as the generic _ICC_PROFILE atom as fallback. There are however a few caveats for darktable as well, documented here.

---

This article by Pascal de Bruijn was originally published on his site and is reproduced here with permission.

Svetlana Alexievich, winner of the Nobel Prize in Literature, gives the Elliott Lecture at St Antony's College Oxford, taking as her subject "The history of the Russian-Soviet soul".

---

Hosted on Acast. See acast.com/privacy for more information.

💾

Michael Caines talks to two authors who have been shortlisted for the 2016 South Bank Sky Arts Awards.Find out more: www.the-tls.co.uk

---

Hosted on Acast. See acast.com/privacy for more information.

💾

Matthew Beaumont, Michael Caines, Chloe Houston and Nicole Pohl discuss Thomas More's Utopia, first published 500 years ago in 1516, and utopianism in its many and varied forms.Find out more: www.the-tls.co.uk

---

Hosted on Acast. See acast.com/privacy for more information.

💾

New Rapid Photo Downloader

Damon Lynch brings us a new release!

Community member Damon Lynch happens to make an awesome program called Rapid Photo Downloader in his “spare” time. In fact you may have heard mention of it as part of Riley Brandt’s “The Open Source Photography Course”^*. It is a program that specializes in downloading photo and video from media in as efficient a manner as possible while extending the process with extra functionality.

^* Riley donates a portion of the proceeds from his course to various projects, and Rapid Photo Downloader is one of them!

Work Smart, not Dumb

The main features of Rapid Photo Downloader are listed on the website:

1. Generates meaningful, user configurable file and folder names
2. Downloads photos and videos from multiple devices simultaneously
3. Backs up photos and videos as they are downloaded
4. Is carefully optimized to download and back up at high speed
5. Easy to configure and use
6. Runs under Unity, Gnome, KDE and other Linux desktops
7. Available in thirty languages
8. Program configuration and use is fully documented

Damon announced his 0.9.0a1 release on the forums, and Riley Brandt even recorded a short overview of the new features:

(Shortly after announcing the 0.9.0a1 release, he followed it up with a 0.9.0a2 release with some bug fixes).

Some of the neat new features include being able to preview the download subfolder and storage space of devices before you download:

Also being able to download from multiple devices in parallel, including from all cameras supported by gphoto2:

There is much, much more in this release. Damon goes into much further detail on his post in the forum, copied here:

---

How about its Timeline, which groups photos and videos based on how much time elapsed between consecutive shots. Use it to identify photos and videos taken at different periods in a single day or over consecutive days.

You can adjust the time elapsed between consecutive shots that is used to build the Timeline to match your shooting sessions.

How about a modern look?

Download instructions: http://damonlynch.net/rapid/download.html

For those who’ve used the older version, I’m copying and pasting from the ChangeLog, which covers most but not all changes:

• New features compared to the previous release, version 0.4.11:

  • Every aspect of the user interface has been revised and modernized.

  • Files can be downloaded from all cameras supported by gPhoto2, including smartphones. Unfortunately the previous version could download from only some cameras.

  • Files that have already been downloaded are remembered. You can still select previously downloaded files to download again, but they are unchecked by default, and their thumbnails are dimmed so you can differentiate them from files that are yet to be downloaded.

  • The thumbnails for previously downloaded files can be hidden.

  • Unique to Rapid Photo Downloader is its Timeline, which groups photos and videos based on how much time elapsed between consecutive shots. Use it to identify photos and videos taken at different periods in a single day or over consecutive days. A slider adjusts the time elapsed between consecutive shots that is used to build the Timeline. Time periods can be selected to filter which thumbnails are displayed.

  • Thumbnails are bigger, and different file types are easier to distinguish.

  • Thumbnails can be sorted using a variety of criteria, including by device and file type.

  • Destination folders are previewed before a download starts, showing which subfolders photos and videos will be downloaded to. Newly created folders have their names italicized.

  • The storage space used by photos, videos, and other files on the devices being downloaded from is displayed for each device. The projected storage space on the computer to be used by photos and videos about to be downloaded is also displayed.

  • Downloading is disabled when the projected storage space required is more than the capacity of the download destination.

  • When downloading from more than one device, thumbnails for a particular device are briefly highlighted when the mouse is moved over the device.

  • The order in which thumbnails are generated prioritizes representative samples, based on time, which is useful for those who download very large numbers of files at a time.

  • Thumbnails are generated asynchronously and in parallel, using a load balancer to assign work to processes utilizing up to 4 CPU cores. Thumbnail generation is faster than the 0.4 series of program releases, especially when reading from fast memory cards or SSDs. (Unfortunately generating thumbnails for a smartphone’s photos is painfully slow. Unlike photos produced by cameras, smartphone photos do not contain embedded preview images, which means the entire photo must be downloaded and cached for its thumbnail to be generated. Although Rapid Photo Downloader does this for you, nothing can be done to speed it up).

  • Thumbnails generated when a device is scanned are cached, making thumbnail generation quicker on subsequent scans.

  • Libraw is used to render RAW images from which a preview cannot be extracted, which is the case with Android DNG files, for instance.

  • Freedesktop.org thumbnails for RAW and TIFF photos are generated once they have been downloaded, which means they will have thumbnails in programs like Gnome Files, Nemo, Caja, Thunar, PCManFM and Dolphin. If the path files are being downloaded to contains symbolic links, a thumbnail will be created for the path with and without the links. While generating these thumbnails does slow the download process a little, it’s a worthwhile tradeoff because Linux desktops typically do not generate thumbnails for RAW images, and thumbnails only for small TIFFs.

  • The program can now handle hundreds of thousands of files at a time.

  • Tooltips display information about the file including name, modification time, shot taken time, and file size.

  • Right click on thumbnails to open the file in a file browser or copy the path.

  • When downloading from a camera with dual memory cards, an emblem beneath the thumbnail indicates which memory cards the photo or video is on

  • Audio files that accompany photos on professional cameras like the Canon EOS-1D series of cameras are now also downloaded. XMP files associated with a photo or video on any device are also downloaded.

  • Comprehensive log files are generated that allow easier diagnosis of program problems in bug reports. Messages optionally logged to a terminal window are displayed in color.

  • When running under Ubuntu‘s Unity desktop, a progress bar and count of files available for download is displayed on the program’s launcher.

  • Status bar messages have been significantly revamped.

  • Determining a video’s correct creation date and time has been improved, using a combination of the tools MediaInfo and ExifTool. Getting the right date and time is trickier than it might appear. Depending on the video file and the camera that produced it, neither MediaInfo nor ExifTool always give the correct result. Moreover some cameras always use the UTC time zone when recording the creation date and time in the video’s metadata, whereas other cameras use the time zone the video was created in, while others ignore time zones altogether.

  • The time remaining until a download is complete (which is shown in the status bar) is more stable and more accurate. The algorithm is modelled on that used by Mozilla Firefox.

  • The installer has been totally rewritten to take advantage of Python‘s tool pip, which installs Python packages. Rapid Photo Downloader can now be easily installed and uninstalled. On Ubuntu, Debian and Fedora-like Linux distributions, the installation of all dependencies is automated. On other Linux distrubtions, dependency installation is partially automated.

  • When choosing a Job Code, whether to remember the choice or not can be specified.

• Removed feature:

  • Rotate Jpeg images - to apply lossless rotation, this feature requires the program jpegtran. Some users reported jpegtran corrupted their jpegs’ metadata – which is bad under any circumstances, but terrible when applied to the only copy of a file. To preserve file integrity under all circumstances, unfortunately the rotate jpeg option must therefore be removed.

• Under the hood, the code now uses:

  • PyQt 5.4 +

  • gPhoto2 to download from cameras

  • Python 3.4 +

  • ZeroMQ for interprocess communication

  • GExiv2 for photo metadata

  • Exiftool for video metadata

  • Gstreamer for video thumbnail generation

• Please note if you use a system monitor that displays network activity, don’t be alarmed if it shows increased local network activity while the program is running. The program uses ZeroMQ over TCP/IP for its interprocess messaging. Rapid Photo Downloader’s network traffic is strictly between its own processes, all running solely on your computer.

• Missing features, which will be implemented in future releases:

  • Components of the user interface that are used to configure file renaming, download subfolder generation, backups, and miscellaneous other program preferences. While they can be configured by manually editing the program’s configuration file, that’s far from easy and is error prone. Meanwhile, some options can be configured using the command line.

  • There are no full size photo and video previews.

  • There is no error log window.

  • Some main menu items do nothing.

  • Files can only be copied, not moved.

---

Of course, Damon doesn’t sit still. He quickly followed up the 0.9.0a1 announcement by announcing 0.9.0a2 which included a few bug fixes from the previous release:

• Added command line option to import preferences from from an old program version (0.4.11 or earlier).

• Implemented auto unmount using GIO (which is used on most Linux desktops) and UDisks2 (all those desktops that don’t use GIO, e.g. KDE).

• Fixed bug while logging processes being forcefully terminated.

• Fixed bug where stored sequence number was not being correctly used when renaming files.

• Fixed bug where download would crash on Python 3.4 systems due to use of Python 3.5 only math.inf

---

If you’ve been considering optimizing your workflow for photo import and initial sorting now is as good a time as any - particularly with all of the great new features that have been packed into this release! Head on over to the Rapid Photo Downloader website to have a look and see the instructions for getting a copy:

http://damonlynch.net/rapid/download.html

Remember, this is Alpha software still (though most of the functionality is all in place). If you do run into any problems, please drop in and let Damon know in the forums!

G'MIC 1.7.1

When the flowers are blooming, image filters abound!

A new version 1.7.1 “Spring 2016” of G’MIC (GREYC’s Magic for Image Computing), the open-source framework for image processing, has been released recently (26 April 2016). This is a great opportunity to summarize some of the latest advances and features over the last 5 months.

G’MIC: A brief overview

G’MIC is an open-source project started in August 2008. It has been developed in the IMAGE team of the GREYC laboratory from the CNRS (one of the major French public research institutes). This team is made up of researchers and teachers specializing in the algorithms and mathematics of image processing. G’MIC is released under the free software licence CeCILL (GPL-compatible) for various platforms (Linux, Mac and Windows). It provides a set of various user interfaces for the manipulation of generic image data, that is images or image sequences of multispectral data being _2D_ or _3D_, and with high-bit precision (up to 32bits floats per channel). Of course, it manages “classical” color images as well.

Note that the project just got a redesign of its mascot Gmicky, drawn by David Revoy, a French illustrator well-known to free graphics lovers for being responsible for the great libre webcomics Pepper&Carott.

G’MIC is probably best known for it’s GIMP plug-in, first released in 2009. Today, this popular GIMP extension proposes more than 460 customizable filters and effects to apply on your images.

But G’MIC is not a plug-in for GIMP only. It also offers a command-line interface, that can be used in addition with the CLI tools from ImageMagick or GraphicsMagick (this is undoubtly the most powerful and flexible interface of the framework). G’MIC also has a web service G’MIC Online to apply effects on your images directly from a web browser. Other G’MIC-based interfaces also exist (ZArt, a plug-in for Krita, filters for Photoflow…). All these interfaces are based on the generic C++ libraries CImg and libgmic which are portable, thread-safe and multi-threaded (through the use of OpenMP). Today, G’MIC has more than 900 functions to process images, all being fully configurable, for a library of only approximately 150 kloc of source code. It’s features cover a wide spectrum of the image processing field, with algorithms for geometric and color manipulations, image filtering (denoising/sharpening with spectral, variational or patch-based approaches…), motion estimation and registration, drawing of graphic primitives (up to 3d vector objects), edge detection, object segmentation, artistic rendering, etc. This is a versatile tool, useful to visualize and explore complex image data, as well as elaborate custom image processing pipelines (see these slides to get more information about the motivations and goals of the G’MIC project).

A selection of some new filters and effects

Here we look at the descriptions of some of the most significant filters recently added. We illustrate their usage from the G’MIC plug-in for GIMP. All of these filters are of course available from other interfaces as well (in particular within the CLI tool gmic).

Painterly rendering of photographs

The filter Artistic / Brushify tries to transform an image into a painting. Here, the idea is to simulate the process of painting with brushes on a white canvas. One provides a template image and the algorithm first analyzes the image geometry (local contrasts and orientations of the contours), then attempt to reproduce the image with a single brush that will be locally rotated and scaled accordingly to the contour geometry. By simulating enough of brushstrokes, one gets a “painted” version of the template image, which is more or less close to the original one, depending on the brush shape, its size, the number of allowed orientations, etc. All these settings being customizable by the user as parameters of the algorithm: This filter allows thus to render a wide variety of painting effects.

The animation below illustrates the diversity of results one can get with this filter, applied on the same input picture of a lion. Various brush shapes and geometries have been supplied to the algorithm. Brushify is computationally expensive so its implementation is parallelized (each core gives several brushstrokes simultaneously).

Note that it’s particularly fun to invoke this filter from the command line interface (using the option -brushify available in gmic) to process a sequence of video frames (see this example of “ brushified “ video):

Reconstructing missing data from sparse samples

G’MIC gets a new algorithm to reconstruct missing data in images. This is a classical problem in image processing, often named “Image Inpainting“, and G’MIC already had a lot of useful filters to solve this problem. Here, the newly added interpolation method assumes only a sparse set of image data is known, for instance a few scattered pixels over the image (instead of continuous chuncks of image data). The analysis and the reconstruction of the global image geometry is then particularly tough.

The new option -solidify in G’MIC allows the reconstruction of dense image data from such a sparse sampling, based on a multi-scale diffusion PDE’s-based technique. The figure below illustrates the ability of the algorithm with an example of image reconstruction. We start from an input image of a waterdrop, and we keep only 2.7% of the image data (a very little amount of data!). The algorithm is able to reconstruct a whole image that looks like the input, even if all the small details have not been fully reconstructed (of course!). The more samples we have, the finer details we can recover.

As this reconstruction technique is quite generic, several new G’MIC filters takes advantage of it:

• Filter Repair / Solidify applies the algorithm in a direct manner, by reconstructing transparent areas from the interpolation of opaque regions. The animation below shows how this filter can be used to create an artistic blur on the image borders.

From an artistic point of view, there are many possibilities offered by this filters. For instance, it becomes really easy to generate color gradients with complex shapes, as shown with the two examples below (also in this video that details the whole process).

• Filter Artistic / Smooth abstract uses same idea as the one with the waterdrop image: it purposely sub-samples the image in a sparse way, by choosing keypoints mainly on the image edges, then use the reconstruction algorithm to get the image back. With a low number of samples, the filter can only render a piecewise smooth image, i.e. a smooth abstraction of the input image.

• Filter Rendering / Gradient [random] is able to synthetize random colored backgrounds. Here again, the filter initializes a set of colors keypoints randomly chosen over the image, then interpolate them with the new reconstruction algorithm. We end up with a psychedelic background composed of randomly oriented color gradients.

• Simulation of analog films : the new reconstruction algorithm also allowed a major improvement for all the analog film emulation filters that have been present in G’MIC for years. The section Film emulation/ proposes a wide variety of filters for this purpose. Their goal is to apply color transformations to simulate the look of a picture shot by an analogue camera with a certain kind of film. Below, you can see for instance a few of the 300 colorimetric transformations that are available in G’MIC.

From an algorithmic point of view, such a color mapping is extremely simple to implement : for each of the 300+ presets, G’MIC actually has an HaldCLUT, that is a function defining for each possible color (R,G,B) (of the original image), a new color (R’,G’,B’) color to set instead. As this function is not necessarily analytic, a HaldCLUT is stored in a discrete manner as a lookup table that gives the result of the mapping for all possible colors of the RGB cube (that is 2^24 = 16777216 values if we work with a 8bits precision per color component). This HaldCLUT-based color mapping is illustrated below for all values of the RGB color cube.

This is a large amount of data: even by subsampling the RGB space (e.g. with 6 bits per component) and compressing the corresponding HaldCLUT file, you ends up with approximately 200 and 300 kB for each mapping file. Multiply this number by 300+ (the number of available mappings in G’MIC), and you get a total of 85MB of data, to store all these color transformations. Definitely not convenient to spread and package!

The idea was then to develop a new lossy compression technique focused on HaldCLUT files, that is volumetric discretised vector-valued functions which are piecewise smooth by nature. And that what has been done in G’MIC, thanks to the new sparse reconstruction algorithm. Indeed, the reconstruction technique also works with _3D_ image data (such as a HaldCLUT!), so one simply has to extract a sufficient number of significant keypoints in the RGB cube and interpolate them afterwards to allow the reconstruction of a whole HaldCLUT (taking care to have a reconstruction error small enough to be sure that the color mapping we get with the compressed HaldCLUT is indistinguishable from the non-compressed one).

Thus, G’MIC doesn’t need to store all the color data from a HaldCLUT, but only a sparse sampling of it (i.e. a sequence of { rgb_keypoint, new_rgb_color }). Depending on the geometric complexity of the HaldCLUTs to encode, more or less keypoints are necessary (roughly from _30_ to 2000). As a result, the storage of the 300+ HaldCLUTs in G’MIC requires now only 850 KiB of data (instead of 85 MiB), that is a compression gain of 99% ! That makes the whole HaldCLUT data storable in a single file that is easy to ship with the G’MIC package. Now, a user can then apply all the G’MIC color transformations while being offline (previously, each HaldCLUT had to be downloaded separately from the G’MIC server when requested).

It looks like this new reconstruction algorithm from sparse samples is really great, and no doubts it will be used in other filters in the future.

Make textures tileable

Filter Arrays & tiles / Make seamless [patch-based] tries to transform an input texture to make it tileable, so that it can be duplicated as tiles along the horizontal and vertical axes without visible seams on the borders of adjacent tiles. Note that this is something that can be extremely hard to achieve, if the input texture has few auto-similarity or glaring luminosity changes spatially. That is the case for instance with the “Salmon” texture shown below as four adjacent tiles (configuration 2x2) with a lighting that goes from dark (on the left) to bright (on the right). Here, the algorithm modifies the texture so that the tiling shows no seams, but where the aspect of the original texture is preserved as much as possible (only the texture borders are modified).

We can imagine some great uses of this filter, for instance in video games, where texture tiling is common to render large virtual worlds.

Image decomposition into several levels of details

A “new” filter Details / Split details [wavelets] has been added to decompose an image into several levels of details. It is based on the so-called “à trous” wavelet decomposition. For those who already know the popular Wavelet Decompose plug-in for GIMP, there won’t be so much novelty here, as it is mainly the same kind of decomposition technique that has been implemented. Having it directly in G’MIC is still a great news: it offers now a preview of the different scales that will be computed, and the implementation is parallelized to take advantage of multiple cores.

The filter outputs several layers, so that each layer contains the details of the image at a given scale. All those layers blended together gives the original image back.

Thus, one can work on those output layers separately and modify the image details only for a given scale. There are a lot of applications for this kind of image decomposition, one of the most spectacular being the ability to retouch the skin in portraits : the flaws of the skin are indeed often present in layers with middle-sized scales, while the natural skin texture (the pores) are present in the fine details. By selectively removing the flaws while keeping the pores, the skin aspect stays natural after the retouch (see this wonderful link for a detailed tutorial about skin retouching techniques, with GIMP).

Image denoising based on “Patch-PCA”

G’MIC is also well known to offer a wide range of algorithms for image denoising and smoothing (currently more than a dozen). And he got one more ! Filter Repair / Smooth [patch-pca] proposed a new image denoising algorithm that is both efficient and computationally intensive (despite its multi-threaded implementation, you probably should avoid it on a machine with less than 8 cores…). In return, it sometimes does magic to suppress noise while preserving small details.

The “Droste” effect

The Droste effect (also known as “mise en abyme“ in art) is the effect of a picture appearing within itself recursively. To achieve this, a new filter Deformations / Continuous droste has been added into G’MIC. It’s actually a complete rewrite of the popular Mathmap’s Droste filter that has existed for years. Mathmap was a very popular plug-in for GIMP, but it seems to be not maintained anymore. The Droste effect was one of its most iconic and complex filter. Martin “Souphead”, one former user of Mathmap then took the bull by the horns and converted the complex code of this filter specifically into a G’MIC script, resulting in a parallelized implementation of the filter.

This filter allows all artistic delusions. For instance, it becomes trivial to create the result below in a few steps: create a selection around the clock, move it on a transparent background, run the Droste filter, et voilà!.

Equirectangular to nadir-zenith transformation

The filter Deformations / Equirectangular to nadir-zenith is another filter converted from Mathmap to G’MIC. It is specifically used for the processing of panoramas: it reconstructs both the Zenith and the Nadir regions of a panorama so that they can be easily modified (for instance to reconstruct missing parts), before being reprojected back into the input panorama.

Morgan Hardwood has wrote a quite detailled tutorial, here on pixls.us, about the reconstruction of missing parts in the Zenith/Nadir of an equirectangular panorama. Check it out!

Other various improvements

Finally, here are other highlights about the G’MIC project:

• Filter Rendering / Kitaoka Spin Illusion is another Mathmap filter converted to G’MIC by Martin “Souphead”. It generates a certain kind of optical illusions as shown below (close your eyes if you are epileptic!)

• Filter Colors / Color blindness transforms the colors of an image to simulate different types of color blindness. This can be very helpful to check the accessibility of a web site or a graphical document for colorblind people. The color transformations used here are the same as defined on Coblis, a website that proposes to apply this kind of simulation online. The G’MIC filter gives strictly identical results, but it ease the batch processing of several images at once.

• Since a few years now, G’MIC has its own parser of mathematical expression, a really convenient module to perform complex calculations when applying image filters This core feature gets new functionalities: the ability to manage variables that can be complex, vector or matrix-valued, but also the creation of user-defined mathematical functions. For instance, the classical rendering of the Mandelbrot fractal set (done by estimating the divergence of a sequence of complex numbers) can be implemented like this, directly on the command line:

  $ gmic 512,512,1,1,"c = 2.4*[x/w,y/h] - [1.8,1.2]; z = [0,0]; for (iter = 0, cabs(z)<=2 && ++iter<256, z = z**z + c); 6*iter" -map 7,2
  

This clearly enlarge the math evaluator ability, as you are not limited to scalar variables anymore. You can now create complex filters which are able to solve linear systems or compute eigenvalues/eigenvectors, and this, for each pixel of an input image. It’s a bit like having a micro-(micro!)-Octave inside G’MIC. Note that the Brushify filter described earlier uses these new features extensively. It’s also interesting to know that the G’MIC math expression evaluator has its own JIT compiler to achieve a fast evaluation of expressions when applied on thousands of image values simultaneously.

• Another great contribution has been proposed by Tobias Fleischer, with the creation of a new _C_ API to invoke the functions of the libgmic library (which is the library containing all the G’MIC features, initially available through a C++ API only). As the _C_ ABI is standardized (unlike C++), this basically means G’MIC can be interfaced more easily with languages other than C++. In the future, we can imagine the development of G’MIC APIs for languages such as Python for instance. Tobias is currently using this new _C_ API to develop G’MIC-based plug-ins compatible with the OpenFX standard. Those plug-ins should be usable indifferently in video editing software such as After effects, Sony Vegas Pro or Natron. This is still an on-going work though.

• Another contributor Robin “Starfall Robles” started to develop a Python script to provide some of the G’MIC filters directly in the Blender video sequence editor. This work is still in a early stage, but you can already apply different G’MIC effects on image sequences (see this video for a demonstration).

• You can find out G’MIC filters also in the opensource nonlinear video editor Flowblade, thanks to the hard work of Janne Liljeblad (Flowblade project leader). Here again, the goal is to allow the application of G’MIC effects and filters directly on image sequences, mainly for artistic purposes (as shown in this video or this one).

What’s next ?

As you see, the G’MIC project is doing well, with an active development and cool new features added months after months. You can find and use interfaces to G’MIC in more and more opensource software, as GIMP, Krita, Blender, Photoflow, Flowblade, Veejay, EKD and Natron in a near future (at least we hope so!).

At the same time, we can see more and more external resources available for G’MIC : tutorials, blog articles (here, here, here,…), or demonstration videos (here, here, here, here,…). This shows the project becoming more useful to users of opensource software for graphics and photography.

The development of version 1.7.2 already hit the ground running, so stay tuned and visit the official G’MIC forum on pixls.us to get more info about the project developement and get answers to your questions. Meanwhile, feel the power of free software for image processing!

Links:

• G’MIC home page
• G’MIC plug-in for GIMP
• Introduction to the CLI interface of G’MIC
• Technical reference documentation
• G’MIC 1.7.1 release article on linuxfr.org

Alan Jenkins introduces and reads a selection of the poems of Gerard Manley Hopkins.

---

Hosted on Acast. See acast.com/privacy for more information.

💾

Adrian Tahourdin and Mika Ross-Southall dip their toes in Casanova's celebrated memoirs.Find out more: www.the-tis.co.uk

---

Hosted on Acast. See acast.com/privacy for more information.

💾

Catharine Morris and Michael Caines take a look at the English essayist, best known for his Confessions of an English Opium-Eater.Find out more at the-tis.co.uk

---

Hosted on Acast. See acast.com/privacy for more information.

💾

Post Libre Graphics Meeting

What a trip!

What a blast!

This trip report is long overdue, but I wanted to process some of my images to share with everyone before I posted.

It had been a couple of years since I had an opportunity to travel and meet with the GIMP team again (Leipzig was awesome) so I was really looking forward to this trip. I missed the opportunity to head up to the great white North for last years meeting in Toronto.

London Calling

I was going to attend the pre-LGM photowalk again this year so this time I decided to pack some bigger off-camera lighting modifiers for everyone to play with. Here’s a neat travelling photographer pro-tip: most airlines will let you carry on an umbrella as a “freebie” item. They just don’t specify that it has to be an umbrella to keep the rain off you. So I carried on my big Photek Softlighter II (luckily my light stands fit in my checked luggage). Just be sure not to leave it behind somewhere (which I was paranoid about for most of my trip). Luckily I was only changing planes in Atlanta.

A couple of (bad) movies and hours later I was in Heathrow. I figured it wouldn’t be much trouble getting through border control.

I may have been a little optimistic about that.

The Border Force agent was quite nice and super inquisitive. So much so that I actually began to worry at some point (I think I must have spent almost 20 minutes talking to her) that she might not let me in!

She kept asking what I was coming to London for and I kept trying to explain to her what a “Libre Graphics Meeting“ was. This was almost a tragic comedy. The idea of Free Software did not seem to compute to her and I was sorry I had even made the passing mention. Her attention then turned to my umbrella and photography. What was I there to photograph? Who? Why? (Come to think of it, I should start asking myself those same questions more often… It was an existential visit to the border control.)

In the end I think she got bored with my answers and figured that I was far too awkward to be a threat to anything. Which pretty much sums up my entire college dating life.

Photowalk

In what I hope will become a tradition we had our photowalk the day before LGM officially kicked off and we could not have asked for a better day of weather! It was partly cloudy and just gorgeous (pretty much the complete opposite to what I was expecting for London weather).

Furtherfield Commons

I want to thank Ruth Catlow (http://ruthcatlow.net/) for allowing us to use the awesome space at Furtherfield Commons in Finsbury Park as a base for our photowalk! They were amazingly accommodating and we had a wonderful time chatting in general about art and what they were up to at the gallery and space.

They have some really neat things going on at the gallery and space so be sure to check them out if you can!

Going for a Walk with Friends

This is one of my favorite things about being able to attend LGM. I get to take a stroll and talk about photography with friends that I only usually get to interact with through an IRC window. I also feel like I can finally contribute something back to these awesome people that provide software I use every day.

We meandered through the park and chatted a bit about various things. Simon had brought along his external flash and wanted to play with off-camera lighting. So we convinced Liam to stand in front of a tree for us and Simon ended up taking one of my favorite images from the entire trip. This was Liam standing in front of the tree under the shade with me holding the flash slightly above him and to the camera right.

We even managed to run into Barrie Minney while on our way back to the Commons building. Aryeom and I started talking a little bit while walking when we crossed paths with some locals hanging out in the park. One man in particular was quite outgoing and let Aryeom take his photo, leading to another fun image!

Upon returning to the Commons building we experimented with some of the pretty window light coming into the building along with some black panels and a model (Mairi). This was quite fun as we were experimenting with various setups for the black panels and speedlights. Everyone had a chance to try some shots out and to direct Mairi (who was super patient and accommodating while we played).

Towards the end of our day I decided get my big Softlighter out and to try a few things in the lane outside the Commons building. Luckily Michael Schumacher grabbed an image of us while we were testing some shots with Mairi outside.

I loved the lane receding in the background and thought it might make for some fun images of Mairi. I had two YN-560 flashes in the Softlighter both firing around ¾ power. I had to balance the ambient sky with the softlighter so needed the extra power of a second flash (it also helps to keep the cycle times down).

The day was awesome and I really enjoyed being able to just hang out with everyone and take some neat photos. The evening at the pub was pretty great also (I got to hang out with Barrie and his friend and have a couple of pints - thanks again Barrie!).

LGM

It never fails to amaze me how every year the LGM organizers manage to put together such a great meeting for everyone. The venue was great and the people were just fantastic at the University of Westminster.

The opening “State of the Libre Graphics“ presentation was done by our (the GIMP teams) very own João Bueno who did a fantastic job! João will also be the local organizer for the 2017 LGM in Rio.

Thanks to contributions from community members Kees Guequierre, Jonas Wagner, and Philipp Haegi I had some great images to use for the PIXLS.US community slides for the “State of the Libre Graphics“. If anyone is curious, here is what I submitted:

These slides can be found on our Github PIXLS.US Presentations page (along with all of our other presentations that relate to PIXLS.US and promoting the community).

Speaking of presentations…

Presentation

I was given some time to talk about and present our community to everyone at the meeting. (See embedded slides below):

I started by looking at what my primary motivation was to begin the site and what the state of free software photography was like at that time (or not like). Mainly that the majority of resources online for photographers that were high quality (and focused on high-quality results) were usually aimed at proprietary software users. Worse still, in some cases these websites locked away their best tutorials and learning content behind paywalls and subscriptions. I finished by looking at what was done to build this site and forum as a community for everyone to learn and share with each other freely.

I think the presentation went well and people seemed to be interested in what we were doing! Nate Willis even published an article about the presentation at LWN.net, “Refactoring the open-source photography community”:

Exhibition

A nice change this year was the inclusion of an exhibition space to display works by LGM members and artists. We even got an opportunity to hang a couple of prints (for some reason they really wanted my quad-print of pippin). I was particularly happy that we were able to print and display the Green Tiger Beetle by community member Kees Guequierre:

Portraits

In Leipzig I thought it would be nice to offer portraits/headshots of folks that attended the meeting. I think it’s a great opportunity to get a (hopefully) nice photograph that people can use in social media, avatars, websites, etc. Here’s a sample of portraits from LGM2014 of the GIMP team that sat for me:

In 2014 I was lucky that houz had brought along an umbrella and stand to use, so this time I figured it was only fair that I bring along some gear myself. I had the Softlighter setup on the last couple of days for anyone that was interested in sitting for us. I say us because Marek Kubica (@Leonidas) from the community was right there to shoot with me along with the very famous @Ofnuts (well - famous to me - I’ve lost count of the neat things I’ve picked up from his advice)! Marek took quite a few portraits and managed the subjects very well - he was conversational, engaged, and managed to get some great personality from them.

A couple of samples from the images that I got are here as well, and they are the local organizer Lara with students from the University! I simply can’t thank them enough for the efforts and generosity in making us feel so welcome.

I’m still working through the portraits I took, but I’ll have them uploaded to my Flickr soon to share with everyone!

GIMPers

One of the best parts of attendance is getting to spend some time with the rest of the GIMP crew. Here’s an action shot during the GIMP meeting over lunch with a neat, glitchy schumaml:

It was great to see everyone at the flat on our last evening there as well…

Wrap up

Overall this was another incredible meeting bringing together great folks who are building and supporting Free Software and Libre Graphics. Just my kind of crowd!

I even got a chance to speak a bit with the wonderful Susan Spencer of the Valentina project and we roughed out some thoughts about getting together at some point. It turns out she lives just up the same state as me (Alabama)! This is simply too great to not take advantage of - Free Software Fashion + Photography?! That will have to be a fun story (and photos) for another day…

Keep watching the blog for some more images from the trip - up next are the portraits of everyone and some more shots of the venue and exhibition!

Sam Graydon looks at the poet Robert Browning, exploring the major role he played in the development of the dramatic monologue, with a selection of readings from his works.

---

Hosted on Acast. See acast.com/privacy for more information.

💾

To mark the 400th anniversary of the death of Shakespeare and Cervantes, Mika Ross-Southall introduces a talk on these two giants of world literature.

---

Hosted on Acast. See acast.com/privacy for more information.

💾

Michael Caines and Lucy Dallas take a tour of Thomas More's imaginary commonwealth, where private property has been abolished and reason rules all.

---

Hosted on Acast. See acast.com/privacy for more information.

💾