Imaging

GIMP 2.9.6 Released

Comments Off on GIMP 2.9.6 Released

After more than a year of hard work we are excited to release GIMP 2.9.6
featuring many improvements, some new features, translation updates for 23
languages, and 204 bug fixes.

As usual, for a complete list of changes please see
NEWS. Here we’d like to focus
on the most important changes.

Performance

GIMP now has support for experimental multi-threading in GEGL and will try to
use as many cores as are available on your computer.

We know GIMP can explode when using more than one core, but we keep it that way
so that we get as many bug reports as possible for this officially unstable
development version. This is because we really, really want to ship GIMP 2.10
with usable parallel processing.

On the other hand, you can always set the amount of cores to 1 if you couldn’t
be bothered to report bugs. For that, please tweak the amount of threads on the
System Resources page of the Preferences dialog.

Setting amount of threads in GIMP 2.9.6

GUI, Usability, and Configurability

Benoit Touchette improved mask creation workflow for users who use a ton of
masks in their projects. Now GIMP remembers the last type of mask
initialization, and you can use key modifiers + mouse click on layer previews
to create, apply, or remove masks. There’s a new button in the Layers
dockable dialog for that as well.

Easily create new mask with GIMP 2.9.6

To make that feature possible, Michael Natterer introduced saving of last
dialogs’ settings across sessions and made these defaults configurable via the
new Interface / Dialog Defaults page in the Preferences dialog.

Configurable Dialog Defaults in GIMP 2.9.6

Additionally, the Preferences dialog got a vertical scrollbar where
applicable to keep its height more sensible, and settings on individual pages
of the dialog can be reset separately now.

The Quit dialog got a few updates: automatically exiting when all the images
in the list have been saved, and a Save As button for every opened image
(clicking an image in the list will raise it easy checks).

Configurable Fill With option in GIMP 2.9.6

Yet another new feature is an option (on the screenshot above) to choose fill
color or pattern for empty spaces after resizing the canvas.

Better Hi-DPI Support

While most changes for better Hi-DPI displays support are planned for v3.0, when
GIMP is expected to be based on either GTK+3 or GTK+4, we were able to remove at
least some of the friction by introducing icon sizes at different resolutions
and a switch for icon sizes on the Icon Theme page of the Preferences dialog.

Configurable icon size in GIMP 2.9.6

On-canvas Interaction Changes

Michael Natterer did a huge under-the-hood work that is likely to affect user
interaction with GIMP bigly. Simply put, he moved a lot of on-canvas code
from tools like Rectangle Select, Measure and Path into reusable code.

The effect of that is multifold:

  • New tools can reuse on-canvas elements of other tools (adding shape drawing
    tools should be easier now, although we are not planning that for 2.10,
    unless someone sends a clean patch).
  • GEGL-based filters can be interacted with directly on the canvas
    (Spiral and Supernova so far as test case).

So far one still needs to write C code to make a GEGL-based filter use
on-canvas interaction. We expect to spend some time figuring out a way to
simplify this, possibly using the GUM language (see below).

Layers, Linear and Perceptual Workflows

Since we want to make workflows in linear color spaces more prominent in GIMP,
it was time to update the blend modes code. You can now switch between two
sets of layer modes: legacy (perceptual) and default (linear). The user
interface for switching was a quick design, we’d like to come up with something
better, so we are interested in your input.

Moreover, we made both compositing of layers and blending color space
configurable, should you have the need to use that for advanced image manipulation.

We also added a new Colors -> Linear Invert command to provide
radiometrically correct color inversion. And the histogram dialog now features
a toggle between gamma and linear modes—again, it’s a design we’d like to improve.

Thanks to Øyvind Kolås and his
Patreon supporters, GIMP now also has a
simple ‘blendfun’ framework that greatly simplifies implementing new color
modes. Ell made use of that by adding Linear Burn, Vivid Light, Linear Light,
Pin Light, Hard Mix, Exclusion, Merge, Split, and Luminance (RGB) blending modes
(most of them now also supported in the PSD plug-in).

Another prominent change is the introduction of the Pass Through mode for layer
groups. When this mode is used instead of any other one, GIMP mixes layers
inside that group directly to the layers below, skipping creation of the group
projection. The feature was implemented by Ell. The screenshot below features a
user-submitted PSD file that has TEXTURES layer group in the Pass Through mode,
as opened in GIMP 2.9.4 (left) and GIMP 2.9.6 (right).

Pass Through mode vs no Pass Through mode

Newly added color tags simplify managing large projects with a lot of layers
and layer groups. The screenshot below is a real-life PSD file opened in GIMP 2.9.6.

New User Interface Themes

To make more use of that feature, we need someone to step up and implement
multiple layers selection. For an initial research, see
this wiki page.

For full access to all the new features, we updated the Layer Attributes
dialog to provide the single UI for setting layer’s name, blending mode,
opacity, and offset, toggling visibility, link status, various locks,
color tags.

Updated Layer Attributes dialog

CIE LCH and CIE LAB

Under the influence of Elle Stone (and with her code contributions), CIE LCH
and CIE LAB color spaces are finding more use in GIMP now.

Color dialogs now have an LCH color selector that, in due time, will most
likely replace outdated HSV selector for reasons outlined by Elle in
this article.
The LCH selector also supports gamut checking.

A new Hue-Chroma filter in the Colors menu works much like Hue-Saturation,
but operates in CIE LCH color space. Moreover, the Fuzzy Select and the
Bucket Fill tool now can select colors by CIE L, C, and H.

Finally, both the Color Picker and the Sample Points dialog now display
pixel values in CIE LAB and CIE LCH.

Sample points in LCH and LAB, GIMP 2.9.6

Tools

New Handle Transform tool contributed by Johannes Matschke in 2015 has
been finally cleaned up by Michael Natterer and available by default. It’s
a little tricky to get used to, but we hear reports that once you get the
hang of it, you love it.

Thanks to Ell, the Warp Transform tool is now a lot faster, partially thanks
to a switch that toggles high-quality preview that isn’t always necessary.

All transformation tools don’t display grid by default anymore, and during
an interactive transformation the original layer gets hidden now. The latter
greatly simplifies transforming upper layer in relation to a lower layer.
Before that, the original layer used to block the view.

Free Select tool now waits for Enter being pressed to confirm selection, which
enables you to tweak positions of polygonal selection.

Painting

An important new feature that is somewhat easy to overlook is being able to
paint on transparent layers with modes other than normal.

Thanks to shark0r, the Smudge tool now has a Flow control that allows mixing
in both constant and gradient color while smudging. There’s another new option
to never decrease alpha of existing pixels while smudging in the tools options
now as well. For more on this, please read
this forum thread.

Canvas rotation has been improved: it got snappier in certain cases, and
rulers, scrollbars, as well as the Navigation dialog follow the rotation now.

Alexia introduced some improvements to the brush engine. For bitmap brushes,
GIMP now caches hardness and disables dynamic change of hardness to improve
painting performance. Bitmap brushes also don’t get clipped anymore, when
hardness is less than 100. Plus there’s a specialized convolution algorithm
for the hardness blur to make it faster now.

Processing Raw Images

Since 2.9.4, GIMP is capable of opening raw (digital camera) images via
darktable, and the plan was to open it up to more
plug-in developers, because nothing sparks a thoughtful, civil conversation
like a raw processor of choice.

This is now possible: 2.9.6 ships with a RawTherapee plug-in (v5.2 or newer
should be installed) and a new file-raw-placeholder plug-in that registers
itself for loading all raw formats, but does nothing except returning an error
message pointing to darktable and RawTherapee, if neither is installed.

Moreover, you can now choose preferred raw plug-in, when multiple options are
available on your computer. For this, open the Preferences dialog and go to
the Image Import page, then click on the plug-in you prefer and click OK to
confirm your choice. You will need to restart GIMP.

Better PSD Support

The PSD plug-in now supports a wider range of blending modes for layers,
at both importing and exporting: Linear Burn, Linear Light, Vivid Light,
Pin Light, and Hard Mix blending modes. It also finally supports exporting
layer groups and reads/writes the Pass Through mode in those. Additionally,
GIMP now imports and exports color tags from/to PSD files.

WebP support

We already shipped GIMP 2.9.2 with initial support for opening and exporting
WebP files, however the plug-in was missing a number of essential features.
Last year, we replaced it with a pre-existing plug-in initially written by
Nathan Osman back in 2011 and maintained
through the years. We now ship it by default as part of GIMP.

WebP exporting in GIMP 2.9.6

The new plug-in received additional contributions from Benoit Touchette and
Pascal Massimino and supports both ICC profiles, metadata loading/exporting,
and animation.

Metadata Viewing and Editing

Thanks to Benoit Touchette, GIMP now ships a new metadata viewer that
uses Exiv2 to display Exif, XMP, IPTC, and DICOM metadata (the latter
is displayed on the XMP tab).

Metadata viewer in GIMP 2.9.6

Moreover, Benoit implemented a much anticipated metadata editor that
supports adding/editing writing XMP, IPTC, DICOM, and GPS/Exif metadata,
as well as loading/exporting metadata from/to XMP files.

Metadata editor in GIMP 2.9.6

Filters

Thanks to contributions from Thomas Manni and Ell, GIMP now has 9 more
GEGL-based filters, including much anticipated Wavelet Decompose, as well
as an Extract Component plug-in that simplifies fetching e.g. CMYK’s K
channel or LAB’s L* channel from an image.

Another new feature that we expect to develop further is GUM—a simple
metadata language that helps automatically building more sensible UI for
GEGL filters. Here’s a quick video:

Resources and Presets

To make GIMP more useful by default, we now ship it with some basic presets
for the Crop tool: 2×3, 3×4, 16:10, 16:9, and Square.

Documents templates have been updated and now feature popular, contemporary
presets for both print and digital media.

What’s Next

We still have a bunch of bugs to fix before we can release 2.10 and we
appreciate all the huge and tiny useful patches contributors send us to that effect.

GIMP 2.9.8 is expected to ship with more bug fixes and an updated Blend
(Gradient Fill) tool that works completely on canvas, including adding and
removing color stops and assigning colors.

An Interview with Michael Schumacher, GIMP administrator

Comments Off on An Interview with Michael Schumacher, GIMP administrator

This is the second of a series of interviews of various people surrounding GIMP development and community. See also the interview of Mitch, GIMP maintainer

GIMP is made not only by hard-core developers but also through the hard work of many less technically-inclined contributors.
Michael Schumacher, aka Schumaml, is a great example of an important core contributor who has been with the project for over 10 years. Mostly known as the project administrator, nowadays he takes care of everything but programming: administrative tasks, management, PR, support…

Schumaml was recently named the maintainer of the 2.8 branch, the stable version of GIMP which only receives bugfixes, showing that it does not require a developer to manage important roles successfully.

This interview was held on Saturday, February 4, 2017, at about 12:27 AM in front of a fireplace and after a day of hacking at Wilber Week. With us were several team members, including Debarshi Ray (Rishi (R)), Øyvind Kolås (pippin (P)) and Simon Budig who also asked questions.

Schumaml, the tie-bearing GIMP office manager
Schumaml, GIMP administrator (photo by antenne used by permission (cba))

Jehan: Hello Michael. You are the GIMP administrator, at least that’s what everybody says.

Schumaml: That’s what everybody says, yes.

J: How would you describe your contribution to the GIMP project?

S: I don’t do much coding. It’s just that so many people — from my perspective — do coding on GIMP already and have a better grasp of the source code and how it is made up. So I don’t think I can contribute much in that regard. I try to do administrative stuff like handling the monetary aspect of the project such as telling GNOME that we need money for events like Wilber Week or for LGM reimbursements…
I also care about the bug reports we have. I try to have them categorized, have a proper status, make sure that they get replies, and that we don’t leave a bug report unattended for a long time.
Also, I have administrative privileges on the GIMP web server, on mailing lists, and… what else. Do I forget anything? That’s about it, yeah.

I’ve been called the tie-wearing GIMP office manager and I even got a t-shirt with a printed tie and a “TWOM” label, because I’ve actually been wearing a proper shirt (made to measure) at one GIMP meeting during the Libre Graphics Meeting 2012 in Vienna.

Schumaml, the tie-wearing GIMP office manager
Schumaml, the tie-wearing GIMP office manager (photo by houz (cba)).

J: How long have you been contributing?

S: I think I started somewhere between 2001 and 2004. The first contributions were probably getting GIMP buildable on MSYS, the minimal GNU build system on the Windows platform. Because I was annoyed that there were only GIMP builds for releases and not for every commit in between.

J: Was it like nightly builds?

S: No it was not like nightly builds. I just wanted to be able to have a current build for the MS Windows platform and also made on the MS Windows platform, so that I could build on my Windows system I was using at the time. Just to be able to follow GIMP development more closely than using a build someone made for a development release.

J: So you mostly use GIMP on Windows?

S: Back more than 10 years ago, I did use Windows exclusively. So basically, back then I had done the porting of GIMP to the Windows platform.

J: Do you use GIMP?

S: I use GIMP. Not as much as many other people but I use it to test many things of GIMP itself. I use it to edit photos I make. I don’t publish many of the images because when I’m editing them, I print them or I use them for some documentation work, so it goes to a customer. I even still use it on MS Windows, but now my main platform is Linux.

J: What kind of job do you do?

S: I’m working for a company that used to be a part of Siemens, which had been carved out by now. We are selling communication systems – in the past, you would have called these telephony systems. Nowadays this stuff is called “Communication Enabled Business Processes”, like everything which has to do with communication: calling someone or texting someone or exchanging chats or whatever. We are providing the software, the service, and the consulting.

J: Why do you contribute to GIMP?

S: It started due to pure selfishness: being able to have the most current GIMP available to me.

Since then, a lot has changed: I believe in Free Software. I believe software should be available for everyone for every purpose. GIMP is a Free Software project. Around the time I got hooked up with GIMP, I also got hooked up with Wikipedia, which follows the same approach towards knowledge. I feel like — yeah well — I’m contributing to something that helps a lot of people all over the world. I think that’s a good thing. GIMP happens to be the the first major project I contributed to, and I like it. It’s also in-line with the topics I specialized in at university: image synthesis, image manipulation. It kind of seemed like a logical extension.

Schumaml, the tie-bearing GIMP office manager
Not the Formula One driver. (Photo by Pat David (cba))

Rishi: What do you think of Michael Schumacher?

S: (laughs) The formula one driver?

R: Yeah.

S: First thing, you know about his current condition, like probably still in the coma. I hope that he will get better. He probably won’t make it to his former self but at least to a state allowing him to live in a somewhat decent way.
He got famous when I was in the so-called German “Gymnasium” (part of secondary education). It was a bit of an annoyance then – I got the same nickname – “Schumi” – as he had. I didn’t follow his career too closely, but knew about every race he won because I would be congratulated at school.

pippin: Have you ever made use of sharing the name?

S: No I haven’t. It got me an interview opportunity with a locale radio station because they were calling all people who had the name “Michael Schumacher” and they were asking them “How hard does this affect your personal life? Has it ever affected you?“. Once, I almost had an appointment canceled because someone thought I was mocking them, but that was the only incident ever.

I’ve never used it. I’ve never abused it. Nowadays, after the end of his professional racing career, it basically didn’t matter anymore.

P: Any controversial theme you wish to be asked?

S: Like the fact that I would like to kill spammers? (Maintain several mailing lists, one forum, be a recipient for “can we haz ads on gimp.org, plz?“, and you’ll know what I mean)

Simon: Not very controversial.

J: What do you want to see in GIMP?

S: Feature-wise, I’m quite OK with what GIMP is right now. I have to admit that some of the current stuff in the GIMP development version is still above my head – for example, I have no real concept yet of the difference between compositing and blending. Learning that it was 2 different things was quite useful. I hope that we can get the documentation of GIMP up-to-speed in time.

I’m more concerned about the project management. As in: how do we decide what new features go into GIMP, how they get into GIMP, and what GIMP development will look like. Particularly post-2.10. You can see it yourself: Right now, our release cycles are much too long. Even the fact that we have actual release cycles is probably bad. If you have a look at services like Twitter or similar, they are constantly releasing. They just push new features out to the people and there is a constant review “this is working, this is not working“. With our long release cycles, users get surprised by “Oh this does not work as it used to. Why have they changed it?“.

The project is still a bit old-fashioned in regard to releases. We are trailing current development models. “Development models” is the term I use because I’m not sure how to refer to this. I’m intrigued by the idea of having stable branches with continuously added new features, but I’m not quite sure if I want 2.10 to be constantly evolving. I would prefer to have 2.12. That’s details.

J: How do you see GIMP in 20 years?

S: First thing: in 20 years, I’ll be 60 (laughs). So I’m not even sure how I see myself at that point. I very much would like to still be part of the project in 20 years. I would still like to be able to see it as an image manipulation program. One of the major Free Software ones. I have no idea at all what it will look like (laughs) because there is so much that can change. Especially in the user interaction. How people interact with software might be the defining factor for how applications will look in 20 years.

J: What’s the feature you are really waiting for?

S: The feature I’m really waiting for… It’s not a feature of painting or image manipulation. It’s about organization. This thing we want to do, Plug-in or Resource Registry 2.0. Properly built and really managed. The thing we talked so much about, have so many great ideas, but always seem to lack the time to do. This is the feature I would like to see.

J: Do you contribute under influence?

S: Yeah, have a look at the 2.8.20 NEWS file. At the typos, which I totally didn’t notice. So now I prefer to not contribute under influence.

J: Indeed you are now the maintainer of the 2.8 branch, or at least the releaser. If not mistaken, you took care of 2.8.18 and 2.8.20 releases. What can you say about this?

S: I guess I should start at why I am doing more 2.8 releases. As I explained before, I’m not interested in coding that much but more engaged in user support and maintenance. Approximately one month before the release of 2.8.18, we had received a report about a security issue in the XCF loading code. It was fixed quickly, for both the development and 2.8 branches, but there was no plan to do a 2.8 release. We have instructions for this, and mitch replied “Just do it!” when I asked about it.

It still felt like flying blind. Had I done the version changes – to 2.8.18, and afterwards advancing to 2.8.19 – correctly? Was the tarball made correctly? Would it build on any other system than mine? It did, but I had still missed two action: the release tag is supposed to be signed (i.e. git tag -s) and the GNOME translations teams should be notified about planned releases with a string freeze be put in place until the release to make it easy for them to complete translations. 2.8.20 was much better prepared and even had an extra long string freeze. I had planned to do it in October 2016, but had to delay it to February 2017, during Wilber Week.

Releasing is definitely something you want to do right, and this means taking a moment of uninterrupted time to do it. My approach towards bug handling has changed a bit, too. I pay much more attention to bugs with attached patches, and try to apply and test those (we really neglected to do this) in order to get them into a stable release.

J: This was a good interview.

S: Thank you for doing it.

GIMP 2.8.22 Released

Comments Off on GIMP 2.8.22 Released

We are releasing GIMP 2.8.22 with various bug fixes.
All platforms will benefit from a change to the image window hierarchy in single window mode, which improves painting performance when certain GTK+ themes are used.
This version fixes an a…

An Interview with Michael Natterer, GIMP maintainer

Comments Off on An Interview with Michael Natterer, GIMP maintainer

GIMP is Free Software, but even before this, it is people: the ones who create it, the ones who create with it… We don’t have accurate statistics and we take pride on not gathering your data. Yet we know (through other websites that have logged partial statistics over the years) that this is a widely used piece of software, by millions of people around the world. So wouldn’t it be neat to meet some of the individuals who make this project come alive?

Some people think there’s a huge company behind GIMP. This is not the case.
GIMP has always been developed by a handful of random people scattered around the world.
Most of them are volunteers and none of them work on it full-time.
As an insider myself, I’ve wanted to launch a series of interviews with the many awesome people I’ve met since I started contributing. So who better to start with than our own benevolent dictator, GIMP maintainer, and the biggest code contributor: Michael Natterer, aka “mitch”.

This interview was held on Friday, February 3, 2017 at around 3AM in front of a fireplace and after a day of hacking at Wilber Week.
With us were several team members, including Michael Schumacher (schumaml (S)) and Øyvind Kolås (pippin (P)), who also asked questions.

Mitch, the man, the myth, the legend
Mitch. The man. The myth. The legend.
The reason your commit probably got reverted.

Jehan: Hello Mitch! In a few words, what’s the close future of GIMP?

Mitch: In 2.10, there is the GEGL port.
Then the GTK+3 port immediately after, which will go as fast as possible.
We don’t plan many features during the GTK+3 port.

J: What are your preferred features of 2.10?

M: High bit depth, on-canvas filter previews… I don’t actually remember the features of 2.8 [to compare] because I never use it.

J: You use 2.10 instead?

M: Yes.

J: Do you use GIMP often?

M: Mostly for testing what I implement, and also for making postcards I sell in my family business. That’s the only thing I use it for.

A maintainer

J: How did you start hacking GIMP?

M: There was this code that saved the user-assigned keyboard shortcuts for menu actions. The code had an escaping bug where you couldn’t have a hyphen as an accelerator. So I wrote code for escaping the string. That was my first GIMP
patch
in 1997 or 1998.

J: How did you become the maintainer?

M: I killed the previous maintainer.
He is now in my cave in boxes.

Schumaml: Have you ever met the original authors (Spencer Kimball and Peter Mattis)?

M: No. Has anyone?

S: Have they ever contacted you?

M: Yes, they sent me a few plugins which I pushed. Neon, photocopy and cartoon. It was around 10 years after they left the project, one of them comes to me and says “Hey Mitch, I coded 3 plugins, here they are”. Everything looked perfect so I just pushed them as-is, and they still exist.

These days, they’ve been reimplemented in GEGL, but the new versions give different results, so the old plugins are still in the menu.

J: Why do you continue working on GIMP?

M: That’s a good question. (laughs)
I don’t know. You guys, perhaps?
It can be really annoying sometimes.
Why do you guys continue?

J: Me? It’s fun.

M: It’s fun yes but sometimes it’s not fun and you do it anyway.

GIMPers at Montserrat, España
GIMPers at Montserrat.

J: Where do you see GIMP 20 years from now?

M: It will probably end up in a pile of bits rotting in some corner. I may have been thinking the same thing twenty years ago, though, so you never know.

A hacker

J: What do you think of Free Software?

M: It’s the way to go, but you need to use the software which is available for a task, so for some tasks you have no choice but to use something that’s not exactly free.

For example: [pointing to nomis trying to make a label printer work on a GNU/Linux
distribution]
if you were using the closed-source driver for that, it would work.

*: (laughs)

J: What’s your operating system, distribution, desktop…?

M: Debian Unstable, GNOME 3.

J: You often complain about all these though.

M: Because it’s all shit.
Just because you have the least shitty [software] doesn’t mean it’s not all shit.
Like autotools. They are shit, but it’s the best shit we have.
There is no software that isn’t shit, except perhaps the most simple of software which does one task.

J: What’s your development environment or text editor of choice?

M: Terminal & emacs.

J: How do you like to hack?

M: It depends. Sometimes I need silence and sometimes a crowded room.

J: You are your own boss in a shop. But we see commits from you all the time. Are you hacking in your bookstore when you get free time and don’t have to take care of your employees or customers?

M: Sometimes, but very rarely. I’m mostly hacking in the evenings, or I commit something during the daytime that I worked on the night before until 2AM.
If I think “I better go to sleep before I push this”, then I’ll wait until the next day when I’m awake to check it once more before I do.

But I don’t have time to do 5-hour long patches during working hours.

J: You don’t sleep?

M: I don’t really sleep, no.

S: What channels do you use to communicate on behalf or in the project?

M: IRC, and IRC.

pippin: What was the first computer you programmed?

M: It was a Schneider CPC, a variation of the Amstrad. At 15 or 16?

S: How did you write your first hello world?

M: In BASIC of course. My programming languages were BASIC, Assembly, Pascal, Modula-2, C, in that weird order. 🙂 Plus some others at university nobody cares about. 🙂

J: Do you code under the influence?

M: Always! That’s the only way to code.


XKCD Ballmer Peak
Obligatory XKCD, by Randall Munroe (Creative Commons By-NC 2.5).

GIMP: present

J: So all software is shit, but in the list of shitty software, is GIMP not so bad?

M: I hope so, but of course it’s shitty.
We’re just a handful of volunteers doing what companies with hundreds of (paid) people do.

J: But sometimes we do things not so bad, right?

M: Yes, but there is nobody to make sure of it.
It’s not often that someone spends the time and effort to make a plugin perfect.
Sometimes it happens, but usually it gets dumped on us and that’s it.
Ten years later, we look at the code again and say “oh my god, this is complete garbage”.
Very rarely do people maintain their code long term and we cannot seriously expect that to happen with everyone being a volunteer here.

S: Is there something you’d like to do much more in the project, apart from coding?

M: In the project? No, coding is fun. I’m happy that I don’t have to do that much administrative work.

S: When will 2.10 be released?

M: Oh go away! The answer is “go away!”. Read my lips: “go away”. When it’s ready.

S: Do you expect it to be this year?

M: Yes of course.

J: So we have a promise!

*: (laughs)

GIMP: future

S: There was this thing that the UI should use Python and the core should use C.

M: Python for the user interface. Horrible! Why?

S: This is something we had discussed.

M: Yes but in the past people wanted to use JavaScript. The year before they wanted to use Java, the year before they wanted to use this, and the year after they want to use that. Now they’re all gone.

Everyone who ever said “I want to use this or that”, and “It’s all shit, let’s use JavaScript”, none of them are still in the project, so…

S: So you don’t see any big changes regarding GIMP in the near future?

M: In the near future definitely not because we need to get some releases out.
Unless, of course, there is a well-done patch that doesn’t need weeks of discussion and back-and-forth negotiations on how things should be done.

About using other languages: why not? There is Rust. There is maybe simpler stuff for doing user interfaces, but making such decisions for a codebase the size of GIMP is not something we can decide based on “the latest hot stuff”.

I mean, look at this javascript mess.
Is that really better? Just because it’s easier?
Easier just means that more clueless people can write code, and they are clueless enough already.
So making it easier doesn’t make it better.
Arrogant but true.

S: Anything else you want to change?

M: Yes a lot of stuff as long as I don’t have to do all the changes, because I really have enough things to do already (laughs).

You can be the maintainer of whatever subpart, please.
Please. Take away the work from me.
All contributors need to realize that if they do something really well, they will be in charge of that part.

J: That’s a very good point.

M: If you do it right, then you’ll be in charge of the part you are doing right.
It always works like that.

S: They don’t need a blessing from you, right?

M: I don’t do blessings. (laughs)

J: GTK+ comes from GIMP. What do you think of GTK+ now?

M: They lost their minds, but they are also doing really good work. I don’t really understand some of their decisions.

On the other hand, look at the mails we get. People say exactly the same about GIMP: “Have the GIMP devs lost their minds?!?”. I was involved with GTK+ for a long time and people thought that I had lost my mind, which was (and is) probably true. Bottom line is that all is fine between GTK+ and GIMP, I just reserve the right to complain for myself.

S: So we will release GIMP 3 with GTK+3 or 4?

M: They just branched for GTK+ 4.x, so that’s not going to happen overnight.

P: It won’t hurt to suddenly have GIMP 4 instead of 3.

M: No it wouldn’t. If they are done in a few weeks, we’d go for GIMP 4 right away. So why not. That would be cool. (laughs) Or GIMP 5!

J: GIMP 10?

M: GIMP X!

Various rants

S: If you happen to be in a conversation with people talking about GIMP, but they don’t know that you are involved, do you come out as the GIMP principal developer?

M: Only if they start talking utter bullshit, or if things simply need clarification. It has happened, of course. A guy wanted to convert me to GIMP once and I had to tell him: yeah you don’t need to. It was in a non-hacker situation.

J: Who is Wilber?

M: Nobody knows. Wilber is a GIMP.

S: What special device would you like to see GIMP on?

M: This cool Microsoft thing (Surface Studio PC) where they have this hyped video online, and it looks super slick with touch and everything.
It’s an ad like Apple used to do in the past and now Microsoft does it, which is a bit weird.
The official Microsoft YouTube video makes you want to have one of these things.

S: What advice you would like to give to someone who would want to contribute?
What to do and what not to do?

M: Listen to advice and be persistent.

Don’t give up because somebody says “this patch isn’t quite right”, most of the time it won’t be. My first commit to GIMP was reverted immediately.

S: I think you also reverted my first.

M: Yes, that’s kind of a tradition. Everybody fucks up on their first commit and it gets reverted. That’s a good standard.

S: So do not be afraid of errors?

M: Yes exactly. Unless they jeopardize the fate of humanity or something. That’s unlikely.

*: Thanks for the interview.

M: You are welcome!

Mitch at work

Images in this post are courtesy of antenne and used by permission (cba).

GIMP 2.8.20 Packages for macOS and Microsoft Windows are available

Comments Off on GIMP 2.8.20 Packages for macOS and Microsoft Windows are available

Thanks to Kristian Rietveld’s and Jernej Simončič’s effort, we can now offer GIMP 2.8.20 packages for macOS and Microsoft Windows from our downloads page. There is a number of interesting bug fixes, and we are eager to hear about your experiences with this release.

GIMP 2.10 blockers and the road to 3.0

Comments Off on GIMP 2.10 blockers and the road to 3.0

During WilberWeek 2017 in Barcelona, the GEGL/GIMP team discussed further development plans.

What’s Blocking The 2.10 Release

Deprecation of libgimp API. Some functions in libgimp need to be deprecated, and capable replacements need to be introduced. We started this shortly before WilberWeek, a lot more work needs to be done.

Introduction of the linear workflow. Currently GIMP has a few loose ends with regards to linear pixel data workflow introduced by Michael Natterer and Øyvind Kolås. The Linear switch in the histogram dialog is more of a prototype and needs a better implementation. Both the Curve and the Levels tools have to be adjusted to work on linear data and need a simple way to switch between linear/gamma-corrected modes. And there’s more work to be done here.

Rework of the layer modes. Michael and Øyvind introduced significant changes to how layer modes are stored in XCF. We now have legacy modes (from GIMP 2.8 and earlier), gamma-corrected modes and linear modes. We have a prototype UI to switch between these sets, but we need a more solid implementation that we’d be happy to ship in 2.10. And there’s more internal work to do.

Icon and UI themes. With dark themes, insensitive menu items are brighter than sensitive menu items. The problem may lie with the GTK+ pixbuf engine. We need to investigate that further. The new symbolic icon theme has design issues and is incomplete. Our current stance is that we may likely revert to color icons and a light theme as a default one (though we will still release symbolic icons and dark themes as alternatives settable in Preferences), unless dedicated designers step up to complete themes and icons.

Color management. While most of GIMP is now color-managed, the big missing bit is complete implementation of color management for GEGL-based filters. Currently it’s slow and clutters the UI. We need to fix that.

Warp Transform tool. The tool works well enough for small images, but lags on larger ones. We need to make it faster.

The usual bugfix routine. Currently, we have ca. 60 bug reports with the 2.10 milestone. Some of them are not essential and can be safely reassigned to the next milestone, but some definitey need our attention.

GTK+3 Port May Prove to Be A Bigger Change Than Expected

We have barely touched the ‘gtk3-port’ branch since 2012, while most of GIMP’s source code is actually related to UI.

The GTK+3 port compiles and appears to work at least for some users. However we need to sit down and do a complete code audit to figure out, how much work needs to be done to finish the port. We can’t provide any completion estimations at this time.

Depending on how much time this takes, we may end up switching to GTK+4 (we do like some aspects of the GTK+ Scene Graph Kit). This will be decided upon in due time.

Relaxing The No-New-Features Policy

We pride ourselves at releasing software that is very stable, although not state-of-the-art fast. This is because for stable releases, we have a policy of not introducing new features to keep the releases as bug-free as possible. Yet this policy proved a blocker for 2.10 since we have too many incomplete features, started by contributors, promising, yet not in release-shape.

We decided that these features should be disabled in 2.10, but can be added later in the stable branch, if they reach the stable state. This way, we don’t block exciting new features arrival for years, while still being able to ship regular releases. This would make our blocker list much smaller, and we could work in smaller steps.

Therefore if the GTK+3 port proves to be too long of a journey, we will start adding new features to 2.10 or launch a 2.11.x/2.12 series. This is too early to talk about it, but we think we need to be transparent about it.

How You Can Contribute

One of the reasons development of GIMP isn’t moving as fast as we’d like to is that we are stuck with completing v2.10, and we have a mostly featureless v3.0 ahead of us. We realize that it doesn’t motivate new developers to join and work on new features, but there is no easy solution. 2.10 has to be released, and the GTK+3 port has to be done.

However we see some ways to help contributors making GIMP better without waiting for the opening of the 3.1/3.2 series. One of the most common questions we hear is how to find bugs that are easy to fix to get started with hacking on GIMP. To amend that, we are tagging such bug reports as ‘newcomers‘, following recommendations of the GNOME Newcomers Initiative. You are welcome to come on IRC to discuss patches directly with the GIMP team. Jehan is also available for questions as the mentor for newcomers, if you feel lost.

If you do not write code, we shall soon be releasing Flatpak builds of GIMP, so you can help testing and providing feedback. This is currently in works by Jehan Pagès.

We shall post a complete report on WilberWeek 2017 once the event is over.

GIMP 2.8.20 Released

Comments Off on GIMP 2.8.20 Released

We are releasing GIMP 2.8.20 with various bug fixes—the most noticeable one being changes to the weird initial user interface language selection on macOS to make it use the user’s preferred language.

Also, for users on the Microsoft Windows platforms, an annoying oscillating switching between different input devices has been fixed, this should make using a tablet more reliable.

Check out the full list of fixed issues since 2.8.18.

The source code for GIMP 2.8.20 is available from our downloads page; pre-built packages for Microsoft Windows and macOS will follow shortly.

WilberWeek 2017

Comments Off on WilberWeek 2017

On January 27 – February 5, the team is meeting in Barcelona for WilberWeek—a week of project planning and vicious hacking.

This meeting is possible thanks to continuos donations from our community.

So far the agenda includes, but is not limited to:

  • preparing the 2.10 release;
  • working on the new GIMP plugins/asset interface + architecture;
  • reviewing all current patches in bugzilla and giving them a proper status;
  • doing interviews with developers/project members;
  • performing all kinds of project administrativa;
  • discussing how post-2.10 GIMP development is going to be done;
  • updating docs.gimp.org.

Expected participants are:

  • Michael Natterer, principal developer of GIMP
  • Øyvind Kolås, principal developer of GEGL
  • Michael Schumacher, project administrator
  • Ville Pätsi, GIMP contributor
  • Simon Budig, GIMP contributor
  • Jehan Pagès, GIMP and GEGL contributor
  • Thomas Manni, GIMP and GEGL contributor
  • Mukund Sivaraman, GIMP and GEGL contributor
  • Debarshi Ray, GNOME Photos lead developer, GEGL contributor
  • Jon Nordby, GIMP, GEGL, MyPaint contributor, imgflo / Flowhub developer
  • Aryeom Han, artist, animator
  • Antenne Springborn, media artist

The event is taking place in Can Serrat art centre in El Bruc, near Barcelona.

We invite local GIMP users to drop by for a chat and mutual insights.

Community-supported development of GEGL now live

Comments Off on Community-supported development of GEGL now live

Almost every new major feature people have been asking us for, be it high bit depth support, or full CMYK support, or layer effects, would be impossible without having a robust, capable image processing core.

Øyvind Kolås picked up GEGL in mid-2000s and has been working on it in his spare time ever since. He is the author of 42% of commits in GEGL and 50% of commits in babl (pixel data conversion library).

Thanks to his work, we shall be shipping GIMP 2.10 with 16/32-bit per color channel precision, linear pixel data workflow, and filters that have an on-canvas preview.

But we always need more from both GEGL and babl:

  • better performance (always);
  • more sophisticated use of GPU;
  • support for arbitrary RGB primaries and TRC (think using wide-gamut RGB, like rec2020);
  • support for CMYK and spot colors;
  • more GIMP filters available as GEGL operations.

And the list go on.

Which is why we ask you to support Øyvind via his Patreon page, so that the development of new features requested by you, our community, could go faster.

2016 in review

Comments Off on 2016 in review

When we released GIMP 2.9.2 in late 2015 and stepped over into 2016, we already knew that we’d be doing mostly polishing. This turned out to be true to a larger extent, and most of the work we did was under-the-hood changes.

But quite a few new features slipped in. So, what are the big user-visible changes for GIMP in 2016?

Better Handling of Layers, Channels, Masks, and Paths

Michael Natterer eliminated one of the big issues with the clipboard: not having an easy way to copy/paste layers and layer groups from one project to another. Now you can just select a layer or a layer group in the ”Layers” dialog, press ”’Ctrl+C”’, switch to a different project and press ”’Ctrl+V”’.

The ”Layer Attributes” dialog, which hasn’t been very useful, now provides the single UI for setting layer’s name, changing blending mode and opacity setting offset in X/Y, toggling visibility, link status, various locks.

Newly added color tags improve layers management and can be set via ”Layers” menu, ”Layer Attributes” dialog. They are also accessible via shortcuts and available for channels and paths (we don’t expect people to use it a lot, but it was too easy to implement).

The color tags feature is currently not very useful without multiple layers selection. This is something we’ve been meaning to do for quite a while. Last year we did a basic research on that, but we don’t expect to accomplish this task in time for GIMP 2.10, unless someone contributes a very good patch. If you are interested in helping out, please talk to us.

Moreover, for people who use a lot of masks, the workflow has been streamlined. Now GIMP remembers the last type of mask initialization, and you can use key modifiers + mouse click on layer previews to create, apply, or remove masks. Additionally, there’s a new button for that as well.

Remembering Defaults Across Sessions, Improved Configurability

We had to figure out a sane way for GIMP to remember last mask initialization settings, so we devised a whole new infrastructure to remember settings of various dialogs. The user interface to adjust those settings is now live on the new ”Interface -> Dialog Defaults” page in the ”Preferences” dialog. See the Making settings persistent in GIMP post for more details.

We also made various GIMP settings resettable in the ”Preferences” dialog. And since GIMP is a huge app, where settings tend to accumulate over the years, we added a vertical scrollbar to keep the height of the dialog sensible. Additionally, we reorganized some of the settings, e.g. on the ”Color Management” page.

Color Management

We already introduced a handful of changes to the color management implementation in 2015, when the code was rewritten by Michael Natterer pretty much from scratch become a core feature rather than a plug-in. But there was more to follow.

Now everything is color-managed in GIMP: all sorts of previews, the Color Picker tool, the painting tools etc. The only missing bit is the on-canvas preview for GEGL-based filters. Color transforms are extremely slow with LittleCMS, so we shall need more time to figure this out.

On a related matter, the Color Management section of the Preferences dialog now features new options to toggle color transforms optimization, so that you could choose between performance and color fidelity.

Additionally, toggling soft-proofing is just a few clicks away in the ‘View -> Color Management’ submenu now, along with rendering intent settings.

Better Tools

While we didn’t intend to work on tools a lot, there have been several interesting updates:

  • The ”Align” tool now has vertical offset setting (contributed by Jonathan Tait).
  • The ”Move” tool shows relative coordinates when moving guides and sample points (bug #770911).
  • The ”Text” tool got improved support for languages using Input Method Engines (contributed by Jehan Pages).
  • Both the ”Bucket Fill” and the ”Fuzzy Select” tool have a new ”Diagonal neighbors” option to select diagonally neighboring pixels (contributed by Ell).
  • The ”Intelligent Scissors” tool now allows to remove the last added segment with the ”’Backspace”’ key.

Split preview for GEGL-based filters

Michael Natterer added a new on-canvas preview feature for GEGL-based filters: splitting the view to compare the image before and after applying the filter. You can drag the ‘curtain’ to adjust the view and use key modifiers to swap before/after sides and the direction of the split (horizontal/vertical).

darktable

Tobias Ellinghaus of the darktable project contributed a new plug-in to load raw files into GIMP by having them developed in darktable. This is only available on platforms supported by darktable, i.e. Linux and macOS.

Since there is more than one raw processing plug-in out there, we intend to eventually add a way to set preferred raw plug-in. You can contribute a patch for that.

WebP support

Pascal Massimino and Benoit Touchette contributed a new WebP plug-in that supports loading/exporting of WebP files, along with ICC profiles, Exif and XMP metadata. The plug-in also supports animation.

Painting

In early 2016, we finally merged the branch by Jehan Pagès that introduces symmetric painting to all painting tools (Paintbrush, MyPaint Brush, Eraser etc.). The feature is available via a dedicated dockable dialog on per-image basis. Modes: Mirror, Tiling, Mandala (Kaleidoscope). The work on this feature was directly sponsored by the part of the community that uses GIMP for digital painting.

For bitmap brushes, GIMP now caches hardness and disables dynamic change of hardness to improve painting performance. Bitmap brushes also don’t get clipped anymore, when hardness is less than 100.

User Interfaces Changes

One of the most visible changes in GIMP is the new user interface themes along with new icon themes, available since v2.9.4 released last summer. We now ship GIMP with “Dark” theme and “Symbolic” icon theme enabled by default.

GIMP ships with 5 new themes (lighter, light, gray, dark, darker) overall. For users who prefer the old UI, we still ship the old default UI theme along with old colorful icons. There’s also some ongoing work on vector-based icons for better Hi-DPI displays compatibility.

We also fixed a number of usability issues. E.g. toolbox buttons do not grab focus anymore, which used to break the use of the ”’Tab”’ key and other canvas-related shortcuts after changing tools with a pointing device click.

GEGL and babl

GEGL and babl got their fair share of development focus. We only added a handful of new operations (”Saturation”, ”Gaussian Selective Blur” etc.), because most work on GEGL was performance improvements, house cleaning etc.

One interesting change, though, is the new ”gegl_operation_progress” function to report processing progress. It’s useful for reporting processing progress to a GEGL-based editor such as GIMP. For now, we use it in ”cartoon” and ”distance-transform” operations, but expect to use it in many more ops.

For babl, most changes were about improving performance (creating fast pixel data conversion paths and caching them) and fixing bugs.

What’s Next for GIMP

There are still many bugs to fix before we can release 2.10. In the mean time, we are planning to hold a week long developers meet-up in Barcelona at end of January. One of the topics will be cleaning up libgimp to get it into the releasable state for 2.10. We shall soon announce the full agenda for the Wilberweek.

Another upcoming major change is how linear/gamma-corrected workflows are implemented in GIMP. Since early January, Michael Natterer and Øyvind Kolås have been hacking on GIMP to make layer modes work on both linear and gamma-corrected image data correctly. This involved a lot of source code reorganization, and a major part of that work is already done.

Additional changes currently live in the ‘pippin/linear-is-the-new-black’ Git branch soon to be merged, and we hear good reports about it from some of our most sceptical users already.

Some other exciting news deserve a separate announcement.

We expect to ship GIMP 2.10 with 16/32-bit per color channel support, new color management implementation, and a great many improvements overall later this year. Our next focus will be completing the GTK+3 port to make the graphic tablets support fully functional on all supported platforms again and prepare GIMP for even more long overdue changes such as non-destructive image editing.