GIMP 2.9.6 & ZeMarmot

Note: this is a copy of a post initially posted on Patreon and Tipeee.

Splash of GIMP 2.9.6 by Aryeom
Splash of GIMP 2.9.6 by Aryeom

Last month, we released the third development version of GIMP, version 2.9.6, as preparation of the next stable version, GIMP 2.10.

Same as for previous versions, ZeMarmot project was one of the major contributors with 274 commits (out of 1885 total for this release) by Jehan, 4 by Aryeom (some icons, a new paint dynamics “Pressure Size” very useful for flat coloring, and the splash image for this development version), and even for the first time, 3 commits by Lionel, a board member of LILA association. Hence about 15% of GIMP 2.9.6 was brought to you by ZeMarmot! 🙂

To get some more insight, you can have a look at the official announcement. And if you want to get the full and accurate list of Jehan’s contributions in particular, it is available on the source repository.

Brought to you in 2.9.6 by ZeMarmot

  • made libgimp as thread-safe, which basically means simplify plug-in developer work to have plug-ins using  several cores (now all desktop computers are multi-core);
  • display angles when drawing lines;
  • code review for WebP image support, as well as some improvements and fixes (and even a patch upstream on libwebp library);
  • capability to switch exclusive visibility of layers inside layer groups only with shift-click (feature requested and tested/used by Aryeom for a few months before adding it to GIMP);
  • contributing to the Darktable and RawTherapee  developers efforts for our new “raw” plug-in allowing importing  RAW files through these third-party software and into GIMP (GIMP project advocates for cooperation with other Free Software);
  • contribution to allow GIMP to follow GEGL multi-thread limit (once again to have a better usage of modern computer processors but now in GIMP core in particular);
  • various improvements of PDF support, in particular multi-page PDF export from layers (this is the part where Lionel from LILA made his first steps as a developer with Jehan’s help!);
  • code review and fixes for improved support of PCX images import and export;
  • capacity of plug-ins to be installed in their own subdirectory,  which should in the long run allow to get rid of the “DLL hell”, in  particular on Windows system, a very common issue where some plug-ins  embed libraries breaking other plug-ins;
  • change various defaults values to get to up-to-date standards (bigger default font size, fullHD as the new default image dimension, 300 PPI default resolution instead of 72…);
  • intelligent adaptation of physical dimension precision based on printing resolution to allow better precision in various parts of the  software (measure tool, status bar, etc.);
  • capacity to choose the icon size, allowing to adapt GIMP on smaller or bigger screen and in particular high density screens, etc.;
  • auto-detection of native resolution of your screen to choose  better default icon size (this default choice can still be changed, cf.  previous point; but at least you should get better defaults);
  • vector icons by default for the various size support;
  • welcome new code contributors by adding a vim coding style file and integrating contributed emacs and kate coding style files;
  • Flatpak package for GIMP;
  • and much more! Bug fixes and minor features by the dozens!

Flatpak for creators on Linux?

For the creators who use GIMP on a GNU/Linux operating system, you may have heard of Flatpak,  the generic application package system. Since we also exclusively use  Linux, it felt important that GIMP be available in a timely manner (with  distribution package systems, it is not unheard of to have to wait  months after actual release to get some new version!). We take the opportunity of the release of 2.9.6 to test a first public Flatpak package. Since  we don’t have a stable server, we made it available to our Patreon  and Tipeee contributors only for the time being, then will try and make it available for everyone very  soon!

For information, Windows already has a GIMP  2.9.6 installer available; and a MacOS package should hopefully soon get  uploaded (it will depends on this package maintainer who has some family priorities right now). These are not maintained by us. » See the download page! « 🙂

Thanks and “en route to GIMP 2.10”!

I hope you appreciate our contributions to GIMP! Know that these are all thanks to our contributors, be them Patreon or Tipeee, in previous crowdfundings or the ones who make direct donations.

It is not easy everyday because we seriously lack funding, and we have had some blues more than once. ;-(
Yet the many of you who never failed us and continue to support us give us some courage.
Thanks to you!

We will continue in order to bring you an awesome stable GIMP 2.10. 🙂

Have fun with GIMP!

GIMP Motion: part 2 — complex animations

This is the second video to present GIMP Motion, our plug-in to create animations of professional quality in GIMP. As previously written, the code is pretty much work-in-progress, has its share of bugs and issues, and I am regularly reviewing some of the concepts as we experiment them on ZeMarmot. You are still welcome to play with the code, available on GIMP official source code repository under the same Free Software license (GPL v3 and over). Hopefully it will be at some point, not too far away, released with GIMP itself when I will deem it stable and good enough. The more funding (see in the end of the article for our crowdfunding links) we get, the faster it will happen.

Whereas the previous video was introducing “simple animations”, which are mostly animations where each layer is used as a different finale frame, this second video shows you how the plug-in handles animations where every frame can be composited from any number of layers. For instance a single layer for the background used throughout the whole animation, and separate layers for a character, other layers for a second character, and layers for other effects or objects (for instance the snow tracks in the example in the end of the video).

It also shows how we can “play” with the camera, for instance with a full cut larger than the scene where you “pan” while following the characters. In the end, we should be able to animate any effect (GEGL operations) as well. This could be to blur the background or foreground, adding light effects (lens flares for instance), or just artistic effects, even motion graphics…
All this is still very much work-in-progress.

One of the most difficult part is to find how to get the smoother experience. Rendering dozens of frames, each of these composited from several high resolution images and complex mathematical effects, takes time; yet one does not want to freeze the GUI, and the animation preview needs to be as smooth as possible as well. These are topics I worked on and experimented a lot too because these are some of the most painful aspect of working with Blender where we constantly had to render pieces of animation to see the real thing (the preview is terribly slow and we never found the right settings even with a good graphics card, 32GB of memory, a good processor, and SSD hard drives).
One of the results of my work in GIMP core should be to make libgimp finally thread-safe (my patch is still holding for review, yet it works very well for us already as you can see if you check out our branch). So it should be a very good step for all plug-ins, not only for animation only.
This allowed me to work more easily with multi-threading in my plug-in and I am pretty happy of the result so far (though I still plan a lot more work).

Another big workfield is to have a GUI as easy to use, yet powerful, as possible. We have so many issues with other software where the powerful options are just so complicated to use that we end up using them badly. That’s obviously a very difficult part (which is why it is so bad in so many software; I was not saying that’s because they are badly done: the solution is just never as easy as one can think of at first) and hopefully we will get something not too bad in the end. Aryeom is constantly reminding me and complaining of the bugs and GUI or experience issues in my software, so I have no other choices than do my best. 😉

 

You’ll note also that we work on very short animations. We actually only draw a single cut at a time in a given XCF file.  From GIMP Motion, we will then export images and will work on cut/scene transitions and other forms of compositing in another software (usually Blender VSE, but we hear a lot more good of Kdenlive lately, so we may give it a shot again; actually these 2 introduction videos were made in Kdenlive as a test). Since 2 cuts are a totally different viewpoint (per definition), there is not much interest on drawing them in the same file anyway. The other reasons is that GIMP is not made to work with thousands of high-definition layers. Even though GEGL allows GIMP to work on images bigger than memory size in theory, this may not be the best idea in practice, in particular if you want fast renders (some people tried and were not too happy, so I tested for debugging sake: that’s definitely not day-to-day workable). As long as GIMP core is made to work on images, it could be argued that it is acceptable. Maybe if animations were to make it to core one day, we could start thinking about how to be smarter on memory usage.
On the other hand, cuts are usually just a few seconds long which makes a single cut data pretty reasonable in memory. Also note that working and drawing animation films one cut at a time is a pretty standard workflow and makes complete sense (this is of course a whole different deal with live-action or 3D animation; I am really discussing the pure drawn animation style here), so this is actually not that huge of a deal for the time being.

To conclude, maybe you are wondering a bit about the term “cel animation”. Someday I guess I should explain more what was cel animation, also often called simply “traditional animation” and how our workflow is inspired by it. For now, just check Wikipedia, and you’ll see already how animation cels really fit well the concept of “layers” in GIMP. 🙂

Have a fun viewing!

ZeMarmot team

Reminder: my Free Software coding can be supported in
USD on Patreon or in EUR on Tipeee. The more we get
funding, the faster we will be able to have animation
capabilities in GIMP, along with a lot of other nice
features I work on in the same time. :-)

Crossroad 0.7 released and future…

Crossroad 0.7

Last month, I released Crossroad 0.7. Do you remember Crossroad? My tool to cross-compile for Windows from a Linux platform, which I told about a year ago. Well there is not much to say: small release with bug fixes, minor improvements, update of the third-party pre-built Windows package repository (thanks OpenSUSE!), and so on.
Also there used to be a bug in pip, so any crossroad installed through pip was broken (I had a quick look at the time, and I think it was because it would break the install prefix). Fortunately this bug is apparently fixed so getting crossroad through pip is again the recommended installation:

pip3 install crossroad

The example from last year is still mostly valid so have a look if you want to see better what crossroad can do.

Future: Android, ARM, MIPS…

Though I historically started this project to build GIMP for Windows (when debugging for this platform), I had wanted to go further for some time now. Android cross-compilation, or even bare-metal builds come to mind.

10 days ago, I have started to work on the support for more cross-compilers. It’s not available in 0.7, but it should be in 0.8! I have successfully cross-built glib, babl, GEGL (and half a dozen other dependencies for these) for Android quite easily, in barely a few dozen of minutes (for Android ARM, x86, MIPS, etc.). Crossroad really makes cross-compilation just as easy as native compilation. 🙂

I will make a blog post with examples on cross-compiling Glib and GEGL for Android when Crossroad 0.8 will be out (not now since I may change a few things before the release). But really… if you already know how to use crossroad for building for Windows, then it’s exactly the same for Android (except there is no pre-built package installer; does anyone know if such a repository exist somewhere?). Just give a go to the git version if you can’t wait.

Going to mobile? Wait… is that… GIMP for tablets?

As always, I never develop just for the sake of it: I code because I want this for a longer term project. And I have grown interested in small devices, even though I resisted for a long time (I still barely use my phone other than for calling, and I don’t even call much). I don’t think small devices will just replace full-grown desktops and laptops any time soon (oppositely to what some would tell you), but they are definitely funny devices. So let’s have some fun in building Android (or other small devices) programs! 🙂

Now I know that a lot of people have asked for a GIMP on Android. Let me tell you I’m not sure it will happen just now. Not that it can’t. I don’t see why we could not build it on this platform (I will probably do a cross-build at some point, just for the sake of trying) but I believe it would be utter-crap as-is. GIMP has not been thought for small devices at all (I even have sometimes GUI size issues on my laptop display!) and therefore we should either heavily modify its GUI with conditional code for small touch devices,  or simply create a brand new GUI, which is probably a much better idea anyway, with such different usage paradigms. Maybe we could create a new Free Software adapted for smaller devices? If other devs are interested to make one as a continuation of the GIMP project, this could be interesting.
This said, having the main GIMP also more touch-aware would be a very good thing (for screen-tablet users), so who knows how things will evolve…

My first GEGL-powered Android “App”

Now I really wanted to have a go at this so I developed my first application to apply GEGL filters on images. This was also my first Android application, period, so I discovered a lot more than just using native libraries on Android.

I know, there are thousands of these “image effects” applications. Sorry! 😛
Really I just wanted a small and easy stuff based on GEGL, and that popped in my mind. For now, it’s called with the stupid name “Robogoat”, and you are free to look at the code under GPLv3. Current version only applies a Sepia effect (“gegl:sepia” operation) to test that the cross-compiled libgegl works well inside Android (it does!). When it will be ready, we should be able to select any effect from a wide range of GEGL operations. 🙂

Robogoat screenshot: applying a gegl:sepia effect in Android
Robogoat screenshot: applying a gegl:sepia effect in Android

If anyone wants to have fun with it, build it and even provide patches, you are more than welcome!


As a conclusion, I would like to remind that I am trying to make a living by developing Free Software, and for the time being, it doesn’t work that well. All my coding is supported through ZeMarmot project, which funds us for making an animation film while contributing to Free Software, in particular GIMP, but others too. For instance, while working on this Android stuff in the previous week, I improved Crossroad, contributed patches and a bug report to meson (and I may have discovered a bug in json-glib but I must check to be sure, before filling a new bug report) and to gradle, and also I have a few commits pending for babl (for Android support)…

So if you want to support me, you can fund my FLOSS development in US dollar (on Patreon) or in euro (on Tipeee). Thanks! 😀


P.S.: by the way, thanks to Free Electrons (a company for embedded Linux development, which contributes back quite a lot to the kernel; I like this, so here is for my minor help by citing them, even though I was not required to!) for having offered me a training in Android system development, a year ago. This is not the reason I first got interested into hand-held devices (rather the opposite, I went there because I had the interest), nor has it been that much help to what I did above, but that sure showed me how easy it indeed was and gave me a preview of the world of embedded Linux.

Wilber week 2017: our report

Wilber Week 2017: the hacking place
ZeMarmot reached Bacelona airport!
ZeMarmot reached Barcelona airport!

Last week, the core GIMP team has been meeting for Wilber Week, a week-long meeting to work on GIMP 2.10 release and discuss the future of GIMP.  The meeting place was an Art Residency in the countryside, ~50km from Barcelona, Spain, with pretty much nothing but an internet access and a fire place for heating. Of course, both Aryeom and I were part of this hacking week. I personally think this has been a very exciting and productive time. Here is our personal report (it does not include the full result for everyone, only the part we have been a part of).

Software Hacking, by Jehan

GIMP on Flatpak

I’ve wanted to work on an official Flatpak build for at least 6 months, did some early tests already back in September, but could finally make the full time only this week. The build is feature-complete (this was not the case of the original nightly builds of GIMP, used as tests by Flatpak’s main developer, back when it was still called xdg-app; also these incomplete builds seem to have not been available anymore for a few months now), or nearly (since some features are still missing in Flatpak).

I’ll talk more on this later in a dedicated post, detailing what is there or not, and why, with feedback on the Flatpak project.
Bottom line: GIMP will have an official Flatpak, at least starting GIMP 2.10!

Heavy coding and arting going on at #WilberWeek
“Heavy coding and arting going on at #WilberWeek” (photo by Mitch, GIMP maintainer)

Working on the help system, Windows build, and more…

I’ve also worked in parallel on some other topics. For instance I’ve made a new Windows build of GIMP to test a few bugs (with my cross-build tool, crossroad, which I hadn’t used for a few months!), fixed a few bugs here and there, and also spent a good amount of time working on improving language detection for the help system (in particular some broken cases when you don’t have exactly the same interface language as the help you downloaded, since we don’t have documentations for as many languages as we have GUI translations). This part is mostly not merged in our code yet because unfinished. But it should be soon.
All in all, that was 26 commits in GIMP (and 1 minor commit in babl) last week, and a lot more things started.

Art hacking, by Aryeom

Aryeom, ZeMarmot director, contributed a lot of smiles (as always), art and design. Since Mitch forgot our usual “Wilber Flag”, she quickly scribbled one on a big sheet of paper (see in video).

Apart from playing with Wilber stamps, created by Antenne Springborn, Aryeom also spent many hours discussing t-shirt and patch designs with Simon Budig. Here is one of her nice attempts for a very classy outlined-Wilber design:

Outlined-Wilber design by Aryeom
Outlined-Wilber design by Aryeom

Funny story: she chose as a base a font called montserrat, without realizing that the region we were in at the time was called Montserrat as well. Total coincidence!

She has also been working on some missing icons in GIMP, for instance the Import/Export preferences icon.

And with time permitting, she scribbled various drawings on paper, because digital painting doesn’t mean you should forget analog techniques, right?

Social hacking: interviews and merchandise

Developer interviews

I have been wanting to bring a little more life to our communication ever since we got a new website for GIMP. We already produce more regular news. I wish we had even more. I also think we should even extend to community news. So if you’ve got cool events around the world involving GIMP, do not hesitate to tell us about them. We may be able to make it a gimp.org news when time permits.

Something else I wanted is showing the people behind GIMP: developers and contributors, but even the artists, designers and other creators making usage of GIMP as a tool in their daily creative process. I have talked about these interviews for a few months now, and Wilber Week was my first attempt to make them a reality. I interviewed Mitch, GIMP maintainer, Pippin, GEGL maintainer, Schumaml, GIMP administrator, Simon, a very early GIMP developer and Rishi, GNOME Photos maintainer and GEGL contributor.
All these interviews soon to be featured on gimp.org!

And that’s only a start! I am planning on interviewing even more contributors (developers and non-developers) and also artists. 🙂

Merchandising

We regularly have requests about t-shirts or other merchandising featuring Wilber/GIMP. So we sat down and discussed on what should be exactly GIMP’s official position on this topic. As you know, I, personally, am all for Libre Art, so this was my stance. And I am happy that we are currently willing to be quite liberal.

Yet we have a lot of values and that was our main concern: how nice is your design? Is your merchandising using good material? Is it produced with ecologically-conscious techniques? Do you give back to the community?… So many questions and this is why Simon Budig will work on a ruleset of what will be acceptable GIMP merchandising that we will “endorse”. Endorsement from the GIMP project will mean that we will feature your selling page link on gimp.org and also that you will be allowed to feature on your own page some “endorsed by GIMP” text or logo. I’ve been quite inspired by this system which Nina Paley uses for Sita Sings the Blues movie.

Well that’s the current status, but don’t take it as an official position and wait for an official news or page on gimp.org (as a general rule, nothing I write is in any way an official GIMP statement unless confirmed on the main website by text validated by peers).

Release hacking!

The one you’ve all been waiting for, so I kept it for the end, or close: what about GIMP 2.10 release? We finally decided that it is time to get 2.10 going. We still have a few things that we absolutely need to fix before the release, but the main decision is that we should stop being blocked by unfinished cool features.

We have got many very awesome features which are “nearly there”, but mostly untouched for years. Usually it means that it globally works but is either extremely slow (like the Seamless Clone or n-point deformation tools), or that it is much too instable (up to the crash), often also with unfinished GUI…
Well we will have to do a pass through our feature list and will simply disable whatever is deemed non-releasable. The code will still be here for anyone to fix, but we just can’t release half-finished unstable features. Sorry.
The good news is that it suddenly divides our blocker list by 10 or so! And that should make GIMP 2.10 coming along pretty soon.

But so what of all these cool features? Will we have to wait until GIMP 3 now? Not necessarily! We decided to relax the release rules, which come from a time where all free software released major versions with new features and minor versions with bug fixes only (some kind of semantic versioning applied to end software). So now, if any cool new feature comes along or if the currently deactivated features get finished, we are willing to make minor releases with them! Yes you read it well. This makes it much more exciting for developers since it means you won’t have to wait for years to see your changes in GIMP. But it also means that our contribution process gets much more robust to the unfinished-patch-dropping issue. Of course the libgimp API (used by plugins) still stays stable. Changes does not mean breaking stability!
This was also summed-up in an official gimp.org news recently.

I am so happy about this because I have been pushing for this change in our release process for years. Actually the first time I proposed this was in Libre Graphics Meeting 2014, Leipzig (as I explained in my report back then). I call it a rolling release, where we can release very regularly new stuff, even if just a little. This time though, the topic was brought up by Mitch himself.

People hacking

The conclusion of this week is that it was very nice. As Simon Budig put it in his interview: I mostly stay for the people. I think this is the same for us, and these kind of social events are the proof of it. The GIMP project is ­ — before all — made of people, and not just any people, even nice people! Such event is a good occasion for meeting physically, from time to time, and not just with pixels and bits exchanged through the internet.
We also spent a few hours visiting Barcelona, in particular Sagrada Familia, and doing a few hikes in Montserrat.

This slideshow requires JavaScript.

Awesome panorama shot showing several members of GIMP and GEGL (photo by Aryeom)
Panorama shot featuring several members of GIMP and GEGL (photo by Aryeom)

Financial hacking: ZeMarmot

As a conclusion, we remind you that ZeMarmot would be the way for me to work full-time on GIMP software development! We could do nearly as much every week if our project had the funding which allowed us to sustain ourselves while hacking Free Software. So if you wish to see GIMP be released faster with many cool features, don’t hesitate to click our Patreon links (for USD funding) or the Tipeee one (EUR funding).

See you soon!

Don’t be a stranger to GIMP, be GIMP…

I can try and do more coding, more code reviewing, revive designing discussions… that’s cool, yet never enough. GIMP needs more people, developers, designers, community people, writers for the website or the documentation, tutorial makers… everyone is welcome in my grand scheme!

Many of my actions lately have been towards gathering more people, so when I heard about the GNOME newcomers initiative during GUADEC, I thought that could be a good fit. Thus a few days ago, I had GIMP added in the list of newcomer-friendly GNOME projects, with me as the newcomers mentor. I’ll catch this occasion to remind you all the ways you can contribute to GIMP, and not necessarily as a developer.

Coding for GIMP

GIMP is not your random small project. It is a huge project, with too much code for any sane person to know it all. It is used by dozen of thousands of people, Linux users of course, but also on Windows, OSX, BSDs… A flagship for Free Software, some would say. So clearly coding for GIMP can be scary and exciting in the same time. It won’t be the same as contributing to most smaller programs. But we are lucky: GIMP has a very sane and good quality code. Now let’s be clear: we have a lot of crappy pieces of code here and there, some untouched for years, some we hate to touch but have to sometimes. That will happen with any project this size. But overall, I really enjoy the quality of the code and it makes coding in GIMP somewhat a lot more enjoyable than in some less-cared projects I had to hack on in my life. This is also thanks to the maintainer, Mitch, who will bore you with syntax, spaces, tabs, but also by his deep knowledge of GIMP architecture. And I love this.

On the other hand, it also means that getting your patch into GIMP can be a littler more complicated than in some other projects. I saw a lot of projects which would accept patches in any state as long as it does more or less what it says it does. But nope, not in GIMP. It has to work, of course, but it also has to follow strict code quality, syntax-wise, but also architecture-wise. Also if your code touches the public API or the GUI, be ready for some lengthy discussions. But this is all worth it. Whether you are looking for improving an already awesome software, adding lines to your resume, improving your knowledge or experience on programming, learning, you will get something meaningful out of it. GIMP is not your random project and you will have reasons to be proud to be part of it.

How to choose a first bug?

Interested already? Have a look at bugs that we think are a good fit for newcomers! Now don’t feel obligated to start there. If you use GIMP and are annoyed by specific bugs or issues, this may well be a much better entrance. Personally I never contributed to fix a random bug as first patch. Every single first patch I did for Free Software was for an issue I experienced. And that’s even more rewarding!

Oh and if you happen to be a Windows or OSX developer, you will have an even bigger collection of bugs to look into. We are even more needing developer on non-Linux platforms, and that means we have a lot more bugs there, but also most likely a good half of these are probably easy to handle even for new developers.

Finally crashes and bugs which output warnings are often pretty easy since you can usually directly investigate them in a debugger (gdb for instance), which is also a good tool to learn if you never used. Bugs related to a graphical element, especially with text, are a good fit for new developers too since you can easily grep texts to search through the code.

Infrastructure

Now there are whole other areas where you could contribute. These are unloved area and less visible, which is sad. And I wish to change this. One of these is infrastructure! GIMP, as many big projects, have a website, build and continuous integration servers, wikis, mailing lists… These are time-consuming and have few contributors.

So we definitely welcome administrators. Our continuous integration regularly encounters issue. Well as we speak, the build fails, not because of GIMP, instead because minimum requirements for our dev environment are not met. At times, we have had a failing continuous integration for months. The problem is easy: we need more contributors to share the workload. Currently Sam Gleske is our only server administrator but as a volunteer, he has only limited time. We want to step up to next level with new people to co-administrate the servers!

Writers

While we got a new website recently (thanks to Patrick David especially!), more frequent news (here I feel we have to cite Alexandre Prokoudine too), we’d still welcome new hands. That could be yours!

We need documentation for GIMP 2.10 coming release, but also real good quality tutorials under Free/Libre licenses. The state of our tutorials on gimp.org were pretty sad before the new website, to say the least. Well now that’s pretty empty.

Of course translations are also a constant need too. GIMP is not doing too bad here, but if that’s what you like, we could do even better! For this, you will want to contact directly the GNOME translation team for your target language.

Designers

And finally my pet project, I repeat this often, but I think a lot of GIMP workflow would benefit from some designer view. If you are a UX designer and interested, be welcome to the team too!

So here it is. All the things which you could do with us. Don’t be scared. Don’t be a stranger. Instead of being this awesome project you use, it could be your awesome project. Make GIMP! 🙂

GIMP 2.9.4 and our vision for GIMP future

So you may have heard the news: we recently released a new development version of GIMP, version 2.9.4 (as well as a bugfix release 2.8.18, but this is not as awesome).

Small edit: I realized that my blog post has been linked on many major news website. I didn’t expect this! Therefore I just want to make clear that whatever I wrote below is my view of GIMP future. It may not be shared by other developers who have their own priorities and this post has not be written with the other devs. In other word, anything here is not written as anything official from the GIMP project itself, but from me only, a single contributor to GIMP.

GIMP 2.9.4

I am not going to rewrite all of the official news, because you may as well read it on gimp.org. Anyway I co-wrote the news with the rest of the team and provided several screenshots. So reading there is also partly same as reading here. 😉

I’ll just illustrate with this cool picture of the live preview of operations (here a gaussian blur) directly on canvas, split for comparison, implemented by Mitch, our own benevolent dictator (or are we all his dictators?). The image on canvas is by Aryeom, ZeMarmot‘s director.

GIMP 2.9.4 screenshot. Image on canvas is by Aryeom Han under Creative Commons by-sa.
GIMP 2.9.4 screenshot. Canvas image by Aryeom Han (Creative Commons by-sa).

Pretty cool feature, uh?

GIMP & ZeMarmot project

As you can read on gimp.org, ZeMarmot is a contributor to GIMP through my own contributions (which amounts to about 14% of commits for this specific release. Commits number is not always the most perfect metrics but as good as any).

Painting

So what did we bring to the table? Well there are the stuff which we like most first: painting. So I developed symmetry painting last year. Here are some symmetrical doodles drawn by Aryeom in just a few seconds, thanks to the symmetry modes:

Symmetrical doodles by Aryeom Han (Creative Commons by-sa).
Symmetrical doodles by Aryeom (Creative Commons by-sa).

I also helped on the integration of the MyPaint brushes, and in particular contributed upstream on a whole build system rework which, as a side effect improved the codebases of libmypaint and MyPaint (quote from Mypaint’s blog post):

Development of MyPaint will continue of course; in fact making this split happen has improved a lot of things in the codebases of both projects ☺ Big thanks to @Jehan for making this all work so well!

Internationalization

Also the fact that Aryeom is Korean, that we both lived in several countries in Europe, Asia and Oceania, that we speak English, French, Japanese, Korean (well my Korean is lacking!), and that I love languages and am a grammar geek made us good targets to notice anything wrong with GIMP’s support of non Western languages. So I have fixed some bugs and even crashes related to Input Methods and made the text tool finally compliant with input method engines (it used to have an ugly overlay box, not integrated at all in the input box, and without any standard formating).

Writing Korean (left) or Japanese (right) in GIMP 2.9.4's text tool.
Writing Korean (left) or Japanese (right) in GIMP 2.9.4’s text tool.

Of course, I did several other fixes related to languages since I contribute to GIMP like each language translated in itself in the list of language in the preference, or bugs with GUI with right-to-left languages, like Arabic (did I say I was a language geek? I love all these differences and particularities).
Other than this, both Aryeom and I are trying to build a more diverse community by engaging FLOSS and GIMP enthusiasts in Japan, South Korea (some tutorial videos in Korean even) or other countries in their native languages. A hard and long job but we are trying. 🙂

Code review and code maintenance

Well I code a lot of other stuff, smaller features (like the email plugin in GIMP 2.9.4, using xdg-email, implemented a few weeks ago) and bug fixes since I like GIMP hard-rock solid and as stable as possible but that’s obviously less visible. I am also trying to step up more and more for code review and maintenance of small pieces of the software, since Mitch really needs the help (apparently the whip is not enough help! Go figure!). Well this is still work in progress and I wish I could make time to bring more cool code into GIMP, but it still allowed the action search (equivalent to the space-menu of Blender), which I think is one of the coolest feature of GIMP 2.9/2.10 and making menus so old school. This was originally contributed by Srihari, then I reviewed, rewrote and fixed parts of it to fit our high standards on code quality. Well I think that’s one of the features I am the most proud as a reviewer (instead of as the original author). This is also very rewarding to work with other coders, especially when talented and with interesting ideas.

Searching an operation in GIMP with the action search.
Searching an operation in GIMP with the action search.

There are more code I reviewed and integrated, like lately the cool command line’s batch processing macro or even the whole revamping of the user interface (new themes and icons). Arguably this is less “useful”. Well it depends. I met some people who claimed it will change their life, while others would hate the new design direction (though note that old icons and theme are still available in preferences). But anyway this was an idea hanging around on mailing list for years, so I took on myself to attend to new contributors willing to help on the matter (Klaus Staedtler for the icons and Benoit Touchette for the themes). This is also an interesting adventure, I think.

New themes by Benoit Touchette and icons originally by Barbara Muraus and Jakub Steiner, heavily updated and completed by Klaus Staedtler.
New themes by Benoit Touchette and icons originally by Barbara Muraus and Jakub Steiner, heavily updated and completed by Klaus Staedtler.

In the end working on all these fronts is very cool but also exhausting. Hopefully the more time goes, the more I will be able to do! 🙂

Future of GIMP

GEGL everywhere?

I see a lot of good things happening around GIMP. And not just from me, but from all the awesome people in GIMP team and projects around. GEGL for one is a hell of a cool project and I think it could be the future of Free and Open Source image processing. I want to imagine a future where most big graphics program integrates GEGL, where Blender for instance would have GEGL as the new implementation of nodes, with image processing graphs which can be exchanged between programs, where darktable would share buffers with GIMP so that images can be edited in one program and updated in real time in the other, and so on.
Well of course the short/mid-term improvements will be non-destructive editing with live preview on high bit depth images, and that’s already awesomely cool right?

Painting again, better UI, export and much more…

Of course we want to go further for painting features and workflow improvement, but also the UI which really needs some reworking here and there (which is also why I created the gimp-gui mailing list, meant to discuss all sort of topics UI and UX related). That also includes improving support for graphics tablet and alike.
I also have a lot of ideas, some may come to be implemented in a form or another, or not (the export process for instance is still untouched for now). Even when this happens, it’s ok: contributing to Free Software is not just adding any random feature, that’s also about discussing, discovering others’ workflow, comparing, sometimes even compromising or realizing that our ideas are not always perfect. This is part of the process and actually a pretty good mental builder. In any case we will work hard for a better GIMP. 🙂
Among the many other features we are really keen on are the ability to select many layers at once (this is often a pain for Aryeom, since she usually works with many dozens of layers when animating), macros, improving the API to be able to customize the GUI (and not only adding menu items) and the behavior of GIMP, get more communication between GIMP and plugins and in general reacting to hooks, and much much more.
Now there are stuff which are also cool, like better HiDPI support but since we don’t own a HiDPI screen anyway, this is harder to test.

Also I like GIMP for being generic. While other programs choose to be specialized, which is a valid choice, we can notice most graphics programs end up with the same features in the end anyway. Indeed brushes and other painting features are actually very useful to photographers as well. On the other hand, painters regularly use filters and transformation tools originally thought for photographers. Designers use everything as well. So I think the approach of a program which aims to do everything well is quite acceptable too.

Well you see, we have a lot of plans about GIMP, that seems nearly impossible but that’s exciting. And of course, there are the plugins for animation that I am working on, on a good pace. I think I will be able to present the main GIMP plugin for animation quite soon on this website. Stay tuned! 🙂

Help us by helping ZeMarmot?

As often, I will conclude by promoting our permanent monthly funding of ZeMarmot. I know this is very annoying! We want to make a difference, something cool: a Libre animation film together with Free Software code. And trying to make this into more than just a hobby. Right now we are barely there.
I regularly talk about the more “artistic” side here, not often enough about the “technical” coding side. So I decided to use the opportunity of GIMP 2.9.4 release to make this small (non exhaustive) report of stuff I had been doing these last months and what are our goals on the software side (GIMP in particular). If you like what you read here about my contributions, then you like what ZeMarmot is doing, because this is all the same project. And therefore if ever you can afford it, we would welcome financial help so that we can continue software development as well as the production of the animation film.

We are on 2 platforms allowing monthly subscription (which you can stop anytime, as soon as you don’t like us anymore!): Tipeee where you can contribute in EUR (€) and Patreon where you can contribute in USD ($). Note that our pitch is written in French on Tipeee but that’s the same project anyway. Just read the official website in English or the Patreon page.

ZeMarmot on Tipeee (EUR).
Support ZeMarmot on Tipeee (EUR) »
ZeMarmot on Patreon.
Support ZeMarmot on Patreon »

That’s it for today! I hope you enjoyed my coding report on GIMP. Enjoy your week-end everyone! 🙂

crossroad 0.6 released: cross-building GIMP as an example

Hello all!

TL;DR; if you don't care at all about how crossroad works,
and you just want to cross-build GIMP in a few commands,
see at the bottom of the article.

Over the years, I have written a tool to cross-compile software under a GNU/Linux OS for other targets: crossroad. Well to this day, the only supported targets are Windows 32/64-bit. I realized I never advertised this tool much which — even though it has been originally built to help me build and hack a specific project (GIMP) — ended up as a generic cross-compilation system for Linux.

“The crossroads” where Robert Johnson supposedly sold his soul to the Devil, by Joe Mazzola (CC by-sa 2.0)

So today, I will explain crossroad by giving a concrete example:

Cross-compiling GIMP on GNU/Linux for Windows system

The basics

The cool stuff about crossroad is that it allows to cross-build as easily as a native build. For instance f your build system were the autotools, you would run the famous triptych ./configure && make && make install, right? Well with crossroad, you only wrap the configure step but the rest is the same!
cmake is also fully supported, even though my examples below won’t show it (check out the manual for more).

All what crossroad does is preparing you a suitable environment, with the right environment variables, but also wrappers to various tools (for instance, you get the x86_64-w64-mingw32-pkg-config tool inside a crossroad environment, which is no more than a wrapper to detect packages inside the cross-built prefix only).

Enough chit-chat. Let’s install crossroad!

pip3 install crossroad

Running crossroad the first time

I will now go through a full cross-build of GIMP for Windows 64-bit, from a brand new crossroad install. It may be a little long and boring, but I want to show you a full process. So you can just run:

$ crossroad --list-targets
crossroad, version 0.6
Available targets:

Uninstalled targets:
w32 Windows 32-bit
w64 Windows 64-bit

See details about any target with `crossroad --help <TARGET>`.

Ok so at this point, you may have no cross-compilation compiler installed. Let’s see what I need for Windows 64-bit.

$ crossroad --help w64
w64: Setups a cross-compilation environment for Microsoft Windows operating systems (64-bit).

Not available. Some requirements are missing:
- x86_64-w64-mingw32-gcc [package "gcc-mingw-w64-x86-64"] (missing)
- x86_64-w64-mingw32-ld [package "binutils-mingw-w64-x86-64"] (missing)

The package name was actually based off a Mint or a Mageia, I think. If you use Fedora for instance, you will want to install mingw64-gcc and mingw64-binutils.  Just adapt to your case.

Let’s check the output of crossroad again:

$ crossroad --help w64
w64: Setups a cross-compilation environment for Microsoft Windows operating systems (64-bit).

Installed language list:
- C
Uninstalled language list:
- Ada Common package name providing the feature: gnat-mingw-w64-x86-64
- C++ Common package name providing the feature: g++-mingw-w64-x86-64
- OCaml Common package name providing the feature: mingw-ocaml
- Objective C Common package name providing the feature: gobjc++-mingw-w64-x86-64
- fortran Common package name providing the feature: gfortran-mingw-w64-x86-64

We could stop here, but I actually know some programs make use of the C++ compiler, so let’s also install `mingw64-gcc-c++`. And now we are good to go!
I create a Windows 64-bit cross-build environment, that I will call “gimp-build”:

$ crossroad w64 gimp-build
Creating project "gimp-build" for target w64...
You are now at the crossroads...
Your environment has been set to cross-compile the project 'gimp-build' on Windows 64-bit (w64).
Use `crossroad help` to list available commands and `man crossroad` to get a full documentation of crossroad capabilities.
To exit this cross-compilation environment, simply `exit` the current shell session.

Dependencies

babl

Now let’s cross-build babl! Very easy one to start with because it does not have any dependencies:

$ cd /path/to/src/of/babl/
$ crossroad configure && make && make install

Done! You’ll notice that you don’t even need to specify a prefix. crossroad is taking care of it.

GExiv2

$ cd /path/to/src/of/gexiv2
$ crossroad configure

The configure ends up with a pretty clear error:

checking for GLIB... no
configure: error: GLib is required. Please install it.

Well basically you have to install glib. And then you think: the hell is starting! Do I have to build every dependency by hand? Fortunately no! crossroad relies on the OpenSUSE cross platform builds and can automatically download many dependencies for you. The reason I don’t do it for for all dependencies (babl, GEGL, libmypaint and GExiv2 in this tutorial) is when packages are either too old or non available. Install glib with:

$ crossroad install glib2-devel

That’s all! Neat right? Well you also have to install Exiv2 (trying to run the configure again, you’d see another error. I spare you the wasted time). You can run a separate command, or could have installed them both at the same time:

$ crossroad install glib2-devel libexiv2-devel

Try again:

$ crossroad configure

In the configuration summary, you’ll see that introspection and python bindings won’t be built-in. But since they are not needed for GIMP, we don’t care.

$ make && make install

And now GExiv2 has been cross-built too!

gegl

Now for gegl:

$ cd /path/to/src/of/gegl
$ crossroad configure

Once again, you’ll get a few dependency errors. I spare you the try and fail process. Here are all the other mandatory libs to install:

$ crossroad install libjson-glib json-glib-devel libjpeg8-devel libpng-devel

And for a fuller list of optional dependencies:

$ crossroad install cairo-devel libtiff-devel librsvg-2-2 librsvg-devel pango-devel libwebp5 libwebp-devel libjasper-devel gdk-pixbuf-devel

Well there are actually more dependencies you could install or build yourself, but I don’t think they are really needed for GIMP. I’ll just leave it there. Now I build:

$ make

But then… a build error (I’ll admit: I left a dependency error on purpose!)!

In file included from /usr/include/SDL/SDL_main.h:26:0,
from /usr/include/SDL/SDL.h:30,
from /home/jehan/dev/src/gegl/operations/external/sdl-display.c:35:
/usr/include/SDL/SDL_stdinc.h:74:20: fatal error: iconv.h: No such file or directory
compilation terminated.
Makefile:1277: recipe for target 'sdl_display_la-sdl-display.lo' failed
make[4]: *** [sdl_display_la-sdl-display.lo] Error 1
make[4]: Leaving directory '/home/jehan/dev/crossbuild/w64/gegl/operations/external'[…]

Well that’s a good example to debug. Look well at the paths… /usr/include/[…], they are definitely for the native platform! So something is wrong.
Also I don’t even remember having installed SDL through crossroad anyway. Well if you were to check out the config.log, you would understand why the configure script found it:

configure:22069: checking for sdl-config
configure:22087: found /usr/bin/sdl-config
configure:22100: result: /usr/bin/sdl-config

Sometimes, some projects would use their own *-config script instead of relying on pkg-config (SDL seems to also have a pkg-config file, not sure why we’d prefer usind sdl-config, but well…). And while pkg-config allows to really separate the build and target environments, I can’t remove the current $PATH because a lot of native tools are needed in a cross-compilation. All this to say: you may encounter issues with software distributing custom *-config script. Be warned!

Anyway let’s install SDL, don’t forget to re-run configure (otherwise the native lib will still be used), then build again.

$ crossroad install libSDL-devel && crossroad configure && make && make install

Easy said, easy done.

libmypaint

Only a single dependency (json-c), then classical configure, make, make install:

$ crossroad install libjson-c2 libjson-c-devel && crossroad configure && make && make install

GIMP

And now for the main course! Once again, I spare you some of the search of dependencies. Here for mandatory deps:

$ crossroad install atk-devel gtk2-devel libbz2-1 libbz2-devel liblzma-devel liblcms2-2 liblcms2-devel

I’ll skip completely Python dependencies. This is the only major part of GIMP I’m still having issues with in my cross-builds so I will run configure with --disable-python.

As for optional dependencies:

crossroad install libgs8 libgs-devel libmng1 libmng-devel libpoppler-glib8 libpoppler-glib-devel poppler-data xpm-nox-devel headers iso-codes-devel libwmf-devel


Note 1: libwmf-devel has the same issue as SDL, thus the configure script would see it installed if you have it on your main system because of the libwmf-config in your $PATH.

Note 2: you can use crossroad search to discover package names. Even better, sometimes you know a file name that configure is looking for (after a dependency error, check out the configure.ac file or the config.log file for this info). For instance, I can’t find a libghostcript but I see that GIMP‘s configure is looking for the file ghostscript/iapi.h to detect ghostscript:

$ crossroad search --search-files iapi.h
"iapi.h" not found in any package name.
The following packages have files matching the search "iapi.h":
- headers
- libgs-devel

Then using crossroad list-files libgs-devel, I can confirm that this is the right package (crossroad info libgs-devel also confirms this is the package for Ghostscript development files).


Back to building GIMP:

$ crossroad configure --disable-python
$ make &&
make install

Note that I don’t built some options in, like the Ascii Art, the help browser, or OpenEXR because I could not find prebuilt dependencies, but it should not be hard for you to build the dependencies yourself as we did for babl/GEGL/…

Running under Windows!

And now you can for instance make a zip to put on a Windows, like this:

$ crossroad --compress=gimp-build.zip w64 gimp-build

This will just compress the whole target build, where GIMP for Windows is under bin/gimp-2.9.exe. Now this is *not* an installer or whatever finale. The target directory is full of files useful for building, yet completely useless for the finale installation. crossroad is *not* meant for making installers… to this day at least (saying that I would not be against if anyone wanted to implement something of the sort. Why not?! Send me a patch!).
Since I usually run Windows in a Virtualbox VM, rather than zipping a whole archive, I would simply share a directory and symlink the target directory like this:

$ cd /path/to/dir/shared/with/windows/vm/
$ crossroad --symlink w64 gimp

Note: in your Windows environment, you must update the PATH environment variable to add your build’s bin/ directory otherwise Windows won’t find your various built DLLs. You’ll find information on how to do so everywhere in the web.

I use crossroad as a developer, to test and sometimes patch directly GIMP for Windows, without ever getting out of my Linux OS. Well I still test under a Windows VM, which runs in Linux. But I develop and compile in my GNU/Linux shell.
Hopefully this tool can be useful to other people willing to test their program under Windows while hacking on GNU/Linux.

About having a good build system

If you followed good programming practice, and use a full-featured build system such as autotools and cmake, chances are that you can cross-build your program with barely any fix to the code. This is for instance what happened when I ported GExiv2 to autotools after we started using it in GIMP. GExiv2 maintainer would say in the blog post:

This in turn allows gexiv2 to build on Windows, something we’d not targeted at all when we began development but is obviously a hard requirement for GIMP.

Just having a good build system turn their Linux-only library into a multi-platform one. Pretty cool, no? And now libmypaint got the same fate, I autotooled it making it just so easy to cross-compile!

But if you have hand-made makefiles (like GExiv2 did), a scons build (like libmypaint did), or other build systems which don’t have a proper support for cross-building, this won’t be as easy. Think twice when you set up your software. The tool you use for builds is definitely not something to take lightly!

The one-step crossbuild script

This was all for you to see how crossroad is working. If you are only interested into building GIMP specifically, I compiled my whole tutorial below into a single build script that you are welcome to copy paste and run with crossroad like this:

crossroad install glib2-devel libexiv2-devel libjson-glib json-glib-devel \
  libjpeg8-devel libpng-devel cairo-devel libtiff-devel librsvg-2-2 \
  librsvg-devel pango-devel libwebp5 libwebp-devel libjasper-devel \
  gdk-pixbuf-devel libSDL-devel libjson-c2 libjson-c-devel atk-devel \
  gtk2-devel libbz2-1 libbz2-devel liblzma-devel liblcms2-2 \
  liblcms2-devel libgs8 libgs-devel libmng1 libmng-devel \
  libpoppler-glib8 libpoppler-glib-devel poppler-data \
  xpm-nox-devel headers iso-codes-devel libwmf-devel headers
git clone git://git.gnome.org/babl
cd babl && crossroad configure && make && make install && cd ..
git clone git://git.gnome.org/gegl
cd gegl && crossroad configure && make && make install && cd ..
git clone git://git.gnome.org/gexiv2
cd gexiv2 && crossroad configure && make && make install && cd ..
git clone https://github.com/mypaint/libmypaint.git
cd libmypaint && crossroad configure && make && make install && cd ..
git clone git://git.gnome.org/gimp
cd gimp && crossroad configure --disable-python && make && make install

If you copy these into a file, say build-gimp.sh, you can run it at once with:

$ crossroad w64 gimp-build --run build-gimp.sh -n

I hope you enjoyed this tutorial on how to build GIMP with crossroad!

Note: if you like what I do, consider sponsoring our
animation film (CC by-sa), made with GIMP: ZeMarmot!
We fund it with Patreon (USD) and Tipeee (EUR).

Improving the export process in GIMP

While I have been working for days on the animation software for ZeMarmot, I wanted to “rest” my brain a little and came back to an old project of mine, which I should have implemented months ago.

So let’s get the troll out straight away: yes, this is about the split between save and export on GIMP. Now I was not there when the decision was taken, but I think it makes sense anyway. Saving is about “your work”, your process. XCF is — in such a view — not an image format, but a project format. It contains much more than the final visual image. Same as you would not save a “.mpeg“, “.avi” or “.mov” in blender, but a “.blend“, you don’t save a “.jpeg” or “.png” either, but a “.xcf” (another analogy for developers out there: “.blend” or “.xcf” can be compared to your source files — which is definitely what they are in a multimedia project — and the image or video formats as the compiled binary).

Yet I understand that some users have a hard time understanding this since there are nearly no difference in our GUI between saving and exporting.
save-export
What’s the difference, you’d ask? And you’d be right.

In the last 2 days, I refactored the whole GimpFileDialog code, which was completely mixing every concepts with hard-to-read if {} else {} statements inside a single class. GimpFileDialog became a generic parent class, containing only logics common to all file dialogs, and I added 3 specific children: GimpOpenDialog, GimpSaveDialog and GimpExportDialog.
This will allow us to do easily much more interesting graphical interfaces specific to each process.

As a proof of concept, I tested a “Scale at export” feature, which would allow to rescale images at export time, without touching the original. Who indeed never worked on some high resolution image, then needed to export it in lower resolution (to upload on some website, send through email or whatever…)? The current GUI would force to scale the original image, export it, then not forget to cancel the scale afterwards (if you forget, save and quit — for instance by habits — you are doomed: you just completely lost data and hours of high res work!).
Here for a UI test:
Save for Export in GIMP

Now before you tell anything: I know that the above screenshot does not look so nice, with a lot of wasted space on the right. I reused an existing widget (the same used in the “Scale Image” dialog, if you know GIMP well) and have not been trying to customize for this first version. The goal was mostly to test the new refactored code and we have some more thinking and discussion before actually adding these features (there are many more things that could be rethought to improve export, at deeper levels too).
The refactoring is now merged to master; the “Scale at export” isn’t yet though (feel free to test it on its git feature branch though, it’s functional).

Of course this is only the start of greater things. One may want to crop an image, change the color space (particularly if you were working in non sRGB), or even apply any GEGL operation before export (like “sharpen” after downscaling).
This should all be possible soon. Of course we’d have to work on the ideal UI to not clutter the export dialog. I will keep readers updated for when the next steps will occur.

I believe this is partially what some people would call a “Save for Web” feature, though I personally don’t like this naming since it is far too restrictive. You may want to change your exported image for far many more reasons that just “the web”.

Now I’ll be back to ZeMarmot (and I remind everyone who wants to support me to improve GIMP they can still support our Open Animation Film)!