Hosted on Acast. See acast.com/privacy for more information.
Hosted on Acast. See acast.com/privacy for more information.
Hosted on Acast. See acast.com/privacy for more information.
We’re heading to London!
I missed LGM last year in Toronto (having a baby - well, my wife was). I am going to be there this year for LGM/London!
I don’t ever do this normally, but you’ve got to start somewhere, right?
It’s my long-term desire to be able to hold a PIXLS meetup/event every year where the community can get together. Where we can hold workshops, photowalks, and generally share knowledge and information. For free, for anyone.
For now though, we need support. LGM is a great opportunity for us to meet with many different projects usually having representatives there.
Donations will help us to offset travel costs to attend LGM as well as a pre-LGM meetup we are holding (more below). Anything further will go to creating new content and to cover hosting costs for the site.
I have started a Pledgie campaign to help ease the solicitation of donations:
https://pledgie.com/campaigns/30905
Here’s the fancy little widget they make available:
If you want to help by adding this button places, here’s the code to do it:
Login<a href='https://pledgie.com/campaigns/30905'>
<img alt='Click here to lend your support to: PIXLS.US at Libre Graphics Meeting 2016 and make a donation at pledgie.com !' src='https://pledgie.com/campaigns/30905.png?skin_name=chrome' border='0' style='width: initial;'>
</a>
Feel free to use it wherever you think it might help. :)
You can also donate directly via PayPal if you want:
I realize that not everyone will be able to donate funds. No sweat! If you’d still like to help out then perhaps you can help us raise awareness for the campaign? The more folks that know about it the better!
Re-tweeting, blogging, linking, yelling on a street corner all help to raise awareness of what we are doing here. Heck, just invite folks to come read and participate in the community. Let’s help even more people learn about free software!
Of course, even better if you are able to make your way to London and actually join us at the Libre Graphics Meeting 2016!
The event will be April 15th — 18th, hosted by Westminster School of Media Arts and Design, University of Westminster at the Harrow Campus (red marker on the map).
The little checkered flag on the map is for something really neat: a PIXLS meetup!
I am going to arrive a day early so that we can have a gathering of PIXLS community folks and anyone else who wants to join us for some photographic fun!
Thanks to the local organizers in London (yay Lara!), we have facilities for us to use. We will be meeting on Thursday, April 14th at the Furtherfield Commons. The facilities will be available from 1000 – 1800 for us to use.
Furtherfield Commons
Finsbury Gate – Finsbury Park
Finsbury Park, London, N4 2NQ
As near as I can tell, here’s a street view of the Finsbury Gate:
I believe the Commons building is just inside this gate, and on the left.
In 2014 I held a photowalk with LGM attendees in Leipzig the day before the event that was great fun. Let’s expand the idea and do even more!
Here’s a Flickr album of my images from LGM2014 in Leipzig:
This year I plan on bringing a model along to shoot while we are out and about (my friend Mairi if she’s available - or a local model if not). I will also be doing a photowalk again, either in the morning or afternoon.
I am also looking for folks from the community to suggest holding their own photoshoots or workshops, so please step forward and let me know if you’d be interested in doing something! The facilities have bench seating for approximately 20 people, a big desk, and a projector as well.
Three things that I personally will be doing are (in no particular order):
I am hoping to possibly record some of these workshops and interactions for posterity and others that might not be able to make it to London. It might be fun to record some shoots for the community to be able to use!
I am also 100% open to suggestions for content that you, the community, might be interested in seeing. If you have something you’d like me to try (and record), please let me know!
Sneaking a release out on Christmas Eve, the darktable team have announced their feature release of darktable 2.0! After quite a few months of Release Candidates the 2.0 is finally here. Please join me in saying Congratulations and a hearty Thank You! for all of their work bringing this release to us.
Alex Prokoudine of Libre Graphics World has a more in-depth look at the release including a nice interview with part of the team: Johannes Hanika, Tobias Ellinghaus, Roman Lebedev, and Jeremy Rosen. My favorite tidbit from the interview:
There is a lot less planning involved than many might think.
— Tobias Ellinghaus
Robert Hutton has taken the time to produce a video covering the new features and other changes between 1.6 and 2.0 as well:
A high-level look at the changes and improvements from the release post on the darktable site:
The source is available now as well as a .dmg for OS X.
Various Linux distro builds are either already available or will be soon!
I finally got off my butt to get a process in place to obtain and update security certificates using Let’s Encrypt for both pixls.us and discuss.pixls.us. I also did some (more) work with Victor Grigas and Wikipedia to support their #Edit2015 video this year.
Last year, I did some 2.5 parallax animations for Wikipedia to help with their first-ever end-of-the-year retrospective video (see the blog post from last year). Here is the retrospective from #Edit2014:
So it was an honor to hear from Victor Grigas again this year! This time around there was a neat new crop of images he wanted to animate for the video. Below you’ll find my contributions (they were all used in the final edit, just shortened to fit appropriately):
Here is the final cut of the video, just released today:
Victor chose some really neat images that were fun to work on! Of course, all free software was used in this creation (GIMP for cutting up the images into sections and rebuilding textures as needed and Blender for re-assembling the planes and animating the camera movements). I had previously written a tutorial on doing this with free software on my blog.
You can read more on the wikimedia.org blog!
Yes, this is not very exciting I’ll concede. I think it _is_ important though.
I recently took advantage of my beta invite to Let’s Encrypt. It’s a certificate authority that provides free X.509 certs for domain owners that was founded by the Electronic Frontier Foundation, Mozilla, and the University of Michigan.
The key principles behind Let’s Encrypt are:
It was relatively painless to obtain the certs. I only had to run their program to use ACME to verify my domain ownership through placing a file on my web root. Once the certs were generated I only had to make some small changes for it to work automatically on https://discuss.pixls.us. (And to automatically get picked up when I update the certs within 90 days).
I still had to manually copy/paste the certs into cpanel for https://pixls.us, though. Not automated (or elegant) but it works and only takes an extra moment to do.
Hosted on Acast. See acast.com/privacy for more information.
Hosted on Acast. See acast.com/privacy for more information.
This is Part 2 of a two-part guide to high bit depth editing in GIMP 2.9.2 with Elle Stone. The first part of this article can be found here: Part 1.
One goal for GIMP 2.10 is to make it easy for users to produce radiometrically correct editing results. “Radiometrically correct editing” reflects the way light and color combine out there in the real world, and so requires that the relevant editing operations be done on linearized RGB.
Like many commonly used RGB working spaces, the sRGB color space is encoded using perceptually uniform RGB. Unfortunately colors simply don’t blend properly in perceptually uniform color spaces. So when you open an sRGB image using GIMP 2.9.2 and start to edit, in order to produce radiometrically correct results, many GIMP 2.9 editing operations will silently linearize the RGB channel information before the editing operation is actually done.
GIMP 2.9.2 editing operations that automatically linearize the RGB channel values include scaling the image, Gaussian blur, UnSharp Mask, Channel Mixer, Auto Stretch Contrast, decomposing to LAB and LCH, all of the LCH blend modes, and quite a few other editing operations.
GIMP 2.9.2 editing operations that ought to, but don’t yet, linearize the RGB channels include the all-important Curves and Levels operations. For Levels and Curves, to operate on linearized RGB, change the precision to “Linear light” and use the Gamma hack. However, the displayed histogram will be misleading.
The GIMP 2.9.2 editing operations that automatically linearize the RGB channel values do this regardless of whether you choose “Perceptual gamma (sRGB)” or “Linear light” precision. The only thing that changes when you switch between the “Perceptual gamma (sRGB)” and “Linear light” precisions is how colors blend when painting and when blending different layers together.
(Well, what the Gamma hack actually does changes when you switch between the “Perceptual gamma (sRGB)” and “Linear light” precisions, but the way it changes varies from one operation to the next, which is why I advise to not use the Gamma hack unless you know exactly what you are doing.)
In GIMP 2.9.2, when using the Normal, Multiply, Divide, Addition, and Subtract painting and Layer blending:
The LCH painting and Layer blend modes will always blend using Linear light precision, regardless of what you choose in the “Image/Precision” menu.
What about all the other Layer and painting blend modes? The concept of “radiometrically correct” doesn’t really apply to those other blend modes, so choosing between “Perceptual gamma (sRGB)” and “Linear light” depends entirely on what you, the artist or photographer, actually want to accomplish. Switching back and forth is time-consuming so I tend to stay at “Linear light” precision all the time, unless I really, really, really want a blend mode to operate on perceptually uniform RGB.
Many digital artists and photographers are switching to linear gamma image editing. Let’s say you use Krita for digital painting in a true linear gamma sRGB profile, specifically the “sRGB-elle-V4-g10.icc” profile that is supplied with recent Krita installations, and you want to export your image from Krita and open it with GIMP 2.9.2.
Upon opening the image, GIMP will automatically detect that the image is in a linear gamma color space, and will offer you the option to keep the embedded profile or convert to the GIMP built-in sRGB profile. Either way, GIMP will automatically mark the image as using “Linear light” precision.
For interoperability between Krita and GIMP, when editing a linear gamma sRGB image that was exported to disk by Krita:
Once you’ve assigned the GIMP built-in Linear RGB profile to the imported linear gamma sRGB Krita image, then feel free to change the precision back and forth between “Linear light” and “Perceptual gamma (sRGB)”, as suits your editing goal.
When you are finished editing the image that was imported from Krita to GIMP:
If your Krita image is in a color space other than sRGB, I would suggest that you simply not try to edit non-sRGB images in GIMP 2.9.2 because many GIMP 2.9.2 editing operations do depend on hard-coded sRGB color space parameters.
Compared to most other RGB color spaces, the sRGB color space gamut is very small. When shooting raw, it’s incredibly easy to capture colors that exceed the sRGB color space.
Every time you convert saturated colors from larger gamut RGB working spaces to GIMP’s built-in sRGB working space using floating point precision, you run the risk of producing out of gamut RGB channel values. Rather than just explaining how this works, it’s better if you experiment and see for yourself:
Where did the funny RGB channel values come from? At floating point precision, GIMP uses LCMS2 to do unbounded ICC profile conversions. This allows an RGB image to be converted from the source to the destination color space without clipping otherwise out of gamut colors. So instead of clipping the RGB channels values to the boundaries of the very small sRGB color gamut, the sRGB color gamut was effectively “unbounded”.
When you do an unbounded ICC profile conversion from a larger color space to sRGB, all the otherwise out of gamut colors are encoded using at least one sRGB channel value that is less than zero. And you might get one or more channel values that are greater than 1.0. Figure 11 below gives you a visual idea of the difference between bounded and unbounded ICC profile conversions:
When converting saturated colors from larger color spaces to sRGB, not clipping would seem to be much better than clipping. Unfortunately a whole lot of RGB editing operations don’t work when performed on negative RGB channel values. In particular, multiplying such colors produces meaningless results, which of course applies not just to the Multiply and Divide blend modes (division and multiplications are inverse operations), but to all editing operations that involve multiplication by a color (other than gray, which is a special case).
So here’s one workaround you can use to clip the out of gamut channel values: Change the precision of “saturated-colors.png” from 32-bit floating point to 32-bit integer precision (“Image/Precision/32-bit integer”). This will clip the out of gamut channel values (integer precision always clips out of gamut RGB channel values). Depending on your monitor profile’s color gamut, you might or might not see the displayed colors change appearance; on a wide-gamut monitor, the change will be obvious.
When switching to integer precision, all colors are clipped to fit within the sRGB color gamut. Switching back to floating point precision won’t restore the clipped colors.
As an important aside (and contrary to a distressingly popular assumption), when doing a normal “bounded” conversion to sRGB, using “Perceptual intent” does not “keep all the colors”. The regular and linear gamma sRGB working color space profiles are matrix profiles, which don’t have perceptual intent tables. When you ask for perceptual intent and the destination profile is a matrix profile, what you get is relative colorimetric intent, which clips.
I’ve warned you about the bad things that can happen when you try to multiply or divide colors that are encoded using negative sRGB channel values. However, out of gamut sRGB channel values can also be incredibly useful.
GIMP 2.9.2 does provide a number of “unclamped” editing operations from which the clipping code in the equivalent GIMP 2.8 operation has been removed. For example, at floating point precision, the Levels upper and lower sliders, Unsharp Mask, Channel Mixer and “Colors/Desaturate/Luminance” do not clip out of gamut RGB channel values (however, Curves does clip). Also the Normal, Lightness, Chroma, and Hue blend modes do not clip out of gamut channel values.
Unclamped editing opens up a whole realm of new editing possibilities. Quoting from Autumn colors: An Introduction to High Bit Depth GIMP’s New Editing Capabilities:
Unclamped editing operations might sound more arcane than interesting, but especially for photographers this is a really big deal:
- Automatically clipped RGB data produces lost detail and causes hue and saturation shifts.
- Unclamped editing operations allow you, the photographer, to choose when and how to bring the colors back into gamut.
- Of interest to photographers and digital artists alike, unclamped editing sets the stage for (and already allows very rudimentary) HDR scene-referred image image editing.
Having used high bit depth GIMP for quite a while now, I can’t imagine going back to editing that is constrained to only using clipped RGB channel values. The Autumn colors tutorial provides a start-to-finish editing example making full use of unclamped editing and the LCH blend modes, with a downloadable XCF file so you can follow along.
If working with unclamped RGB channel data is simply not something you want to do, then use integer precision for all your image editing. At integer precision all editing operations clip. This is a function of integer encoding and so happens regardless of whether the particular editing function includes or doesn’t include clipping code.
Even though GIMP 2.10 hasn’t yet been released, high bit depth GIMP is already an amazing image editor. GIMP 3.0 and beyond will bring many more changes, including the port to GTK+3 (for GIMP 3.0), full color management for any well-behaved RGB working space (maybe by 3.2?), plus extended LCH processing with HSV strictly for use with legacy files. Also users will eventually have the ability to choose “Perceptual” encodings other than the sRGB TRC.
If you would like to see GIMP 3.0 and beyond arrive sooner rather than later, GIMP is coded, documented, and maintained by volunteers, and GIMP needs more developers. If you are not a programmer, there are many other ways you can contribute to GIMP development.
All text and images ©2015 Elle Stone, all rights reserved.
I got busy building a birthday present for a project I work with and all sort of neat things happened in my absence! The Ubuntu Free Culture Showcase chose winners for it’s wallpaper contest for Ubuntu 15.10 ‘Wily Werewolf’ (and quite a few community members were among those chosen).
The darktable crew is speeding along to a 2.0 release with a new RC2 being released.
Also, a great big HAPPY 20th BIRTHDAY GIMP! I made you a present. I hope it fits and you like it! :)
Back in early September I posted on discuss about the Ubuntu Free Culture Showcase that was looking for wallpaper submissions from the free software community to coincide with the release of Ubuntu 15.10 ‘Wily Werewolf’. The winners were recently chosen from among the submissions and several of our community members had their images chosen!
The winning entries from our community include:
A big congratulations to you all for some amazing images being chosen!
If you’re running Ubuntu 15.10, you can grab the ubuntu-wallpapers package to get these images right here!
Hot on the heels of the prior release candidate, darktable now has an RC2 out. There are many minor bugfixes from the previous RC1, such as:
The preliminary changelog from the 1.6.x series:
More information and packages can be found on the darktable github repository.
Remember, updating from the currently stable 1.6.x series is a one-way street for your edits (no downgrading from 2.0 back to 1.6.x).
All together now…
Happy Birthday to GIMP! Happy Birthday to GIMP!…
This past weekend GIMP celebrated it’s 20th anniversary! It was twenty years ago on November 21st that Peter Mattis announced the availability of the “General Image Manipulation Program” on comp.os.linux.development.apps.
Twenty years later and GIMP doesn’t look a day older than a 1.0 release! (Yes, there’s a double entendre there).
To celebrate, I’ve been spending the past couple of months getting a brand new website and infrastructure built for the project! Just in case anyone was wondering where I was or why I was so quiet. I like the way it turned out and is shaping up so go have a look if you get a moment!
There’s even an official news post about it on the new site!
To coincide with the 20th anniversary, the team also released a new stable version in the 2.8 series: 2.8.16. Head over to the downloads page to pick up a copy!!
Still working hard and fast on PhotoFlow, Andreas took some time to record a new video tutorial. He walks through some basic usage of the program, in particular opening an image, adding layers and layer masks, and saving the results. Have a look and if you have a moment give him some feedback!
Andreas is working on PhotoFlow at a very fast pace, so expect some more news about his progress very soon!
