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!
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. :-)
Mid-July, we finally published publicly the code of GIMP Motion, our software for animations in GIMP. It is available on GIMP official source code repository under the same Free Software license (GPL v3 and over).
We don’t have a public GIMP release containing this plugin yet. Hopefully it should happen soon, but the code is still much too experimental and incomplete. We are using it daily internally and you are welcome to do so as well, but the released version will be much better. 🙂
So it means that for the time being, if you want to play with it, you will have to build it yourself from source, or wait for someone to make a build (we may provide one at some point).
The video above describes some of the base features for simple animations, such as storyboards/animatics and most common needs for animated images (GIF, Webp…). What we call “simple animations” is when you mostly have several images which you want to succeed at one another. No complex composition with background and character layers for instance. New features will still happen, for instance for panning/tilting/zooming on bigger panels (very common on storyboards as well), and adding various effects (a keyframed blur for instance would be a common movie effect).
We will soon publish a second part video where we will describe the more advanced features for complex animation (the ones with layered background/foreground/characters). Because we just scratched the surface of what we will be able to do with this plugin. 🙂
Today I released version 0.3 of TinySegmenter, a Japanese Tokenizer in pure Python (released in New BSD license), with a single minor fix for proper install on systems not-using UTF-8 (apparently that still exists! :P). Thanks to Mišo Belica for the patch. Apparently some of his Japanese users are using it for Sumy, his software to extract summary from texts.
About TinySegmenter and Japanese tokenization
It’s not much of a release, but it is a good occasion to tell about TinySegmenter. This is a “Tokenizer” for Japanese. What is a tokenizer? Basically it breaks sentences into words. For people who don’t know Japanese, it doesn’t use spaces or any other symbol to separate words. Theybasicallywritelikethis. Yet there are ways to break these sentences into words, usually based on statistical analysis (like most things in Natural Language Processing and Artificial Intelligence in general). For anyone who wants to know a bit more, this message from Kytea developer (another tokenizer, which is great) explains the 2 main methods with some links of software using them (among them Tinysegmenter) and especially keywords (allowing you to search more).
The reason why you want to “tokenize” Japanese or Chinese is that it is often a first step for further natural language analysis (for instance for automatic translation, grammar analysis, pronounciation hence speech synthesis, etc.).
Now the required example, “my name is Jehan” in Japanese is: 私の名前はJehanです。TinySegmenter breaks it like this:
I am not planning on hacking much TinySegmenter anymore. I never was planning to; at the time I took over maintainership, I just wanted to use it for a project (which never went through) and the original developers were not answering. So I just properly packaged it, did minor changes (for instance better support of European words using Latin1 and extended Latin Unicode characters), added some tests, and that’s it. I don’t even use it anymore. Yet if more people are interested and want to use it, feel free to send me patches. I could also give commit rights, and even co-maintainership after a few patches. I just wanted to get these words out. 🙂
I also discover today the existence of a TinySegmenter3 on pypi, with less downloads than TinySegmenter (the older one I maintained, yes I know that’s a bit confusing, why would they keep the same name and just add a 3?) but worth looking at since they apparently improved performance a good deal (I haven’t checked but that’s what it says). Maybe I should look at their code and merge their commits at some points after talking to them?
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. 🙂
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)…
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.
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!
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:
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
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. 🙂
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).
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.
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.
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).
How are going your last days of 2016 so far? It’s been a strange year? Well let’s not diverge, and focus on ZeMarmot, then, shall we? First be aware that our dear Director, Aryeom Han, is getting a lot better. She was also really happy to get a few “get well” messages and say thanks. Her hand is still aching sometimes, in particular on straining or long activities, but on the whole, she says she can draw fine now.
Reminding the project
I will discuss below what was done in the last months, but first — because it is customary to do so at end of year — I remind that ZeMarmot is a project relying on the funding by willing individuals and companies, with 2 sides: art and software.
I am a GIMP developer, the second biggest contributor in term of number of commits in the last 4 years and I also develop a plugin for digital 2D animation with GIMP, which Aryeom is using on ZeMarmot. I want to get my plugin to a releasable state by GIMP 2.10.
Aryeom is using the software to fully animate, draw and paint a movie, based on an original story which I wrote a few years ago, about a marmot who travels the world for reasons you will know when the film will be released. 🙂 Oh and the movie will be Creative Commons by-SA of course!
Up to now, our initial crowdfunding (~ 14 000 €) has allowed to pay several months of salary to Aryeom. I have chosen to not earn anything for the time being (not because I don’t like being paid but because we cannot afford it with current funding). Some of it is remaining but is kept to pay the musicians.
Now we are mostly relying on the monthly crowdfunding through the Patreon (USD funding) and Tipeee (EUR funding) platforms. But all combined, that’s about 180 € a month, which amounts to barely more than a day of salary (and with non-wage labour costs, that’s not all of it for Aryeom). 1 day per month to make a movie, that’s far from enough, right?
My dream? I wish we could some day consider ourselves a real studio, with many paid artists, producing cool Libre Art movies going to the cinema (yes in my crazy dream, Creative Commons by-sa films are on the big screen!), and developers paid to improve Free Software so that our media-making ecosystem gets even better and for everybody to use!
But right now, that’s no more than an experiment mostly done voluntarily.
Do you like my dream? Do you want to help us make it real? You can by helping the project financially! It can be the symbolic coin as the bigger donation, any push is actually helping us to make things happen!
Not sure yet? Feel free to read more below and to pitch in at any time later on!
Note that not only the money but also the number of supporters is of great help since it shows supports to bigger funders; and for us that’s good for morale too! A good monthly crowdfunding can also help us find producers without having to abandon any of the social and idealistic aspects of the project (note that we have already been contacted by a production who were interested by the film after the crowdfunding but we refuse to compromise too much on the ideal).
We illustrated Aryeom’s work by 2 videos presenting extracts of her work-in-progress. In this first video, she shows different steps in animating a few cuts of the main character:
In this second video, we examine some cuts of another character, the Golden Eagle, main predator of the marmot:
There are a lot which can be said on these few minutes shown about the work of “animator”. Many pages of books on the art of animating life could be filled from such examples! We will probably detail these steps in longer blog posts but I will still explain the basics here.
Animating = giving life
Aryeom says it in the first video and you can see it in several examples in both videos. When your character moves from A to B, you are not just “moving” it. You have to give the impression that the character is acting on oneself, that it is alive, inhabited, in other words: animated.
This is no surprise one of the most famous book on animation is called “The illusion of life” (by Frank Thomas and Ollie Johnston), also the bedside book of Aryeom. Going this way has a lot of ramifications on the animator job.
Believable, not realistic
Before we continue, I have to make sure I am understood. Even though realistic animation is also a thing (Disney comes to mind), making a good animation is otherwise not necessarily about making it “realistic”, but instead about making it “believable”.
It is very common to exaggerate some movements for various reasons (often because it is funnier, but also sometimes because exaggerating it may sometimes look even more believable than the realistic version!), or the opposite (bypassing anatomically-correct movements). There are no bad reasons, only choices to achieve what you want.
Now that this thing is clear, let’s continue.
You can’t just “move an arm”
The very classical example beginners will be given is often: “lift your right arm up”. That’s it? Did you only move your arm and the rest of the body stayed unchanged? Of course not. To stay in balance, your body shifted to the left as a counterweight; the right shoulder lifted whereas the left shoulder lowered; and so on.
A lot of things will change in your body with this simple action. Even your feet and legs may move to compensate the shift of the center of gravity. As a consequence, you don’t “move your arm”, you “move your whole body” (in a configuration where your arm is up).
This is one of the first reason why to just move a single part in a body, you cannot reuse previous drawings and change just this part. No, you will properly redraw the whole body because if you are to fake life, you may as well do it well.
Note: when you say “animation” to computer people, their brain usually immediately wires to “interpolation“, which is the mathematics to compute (among other things) intermediate positions. Because of what I said above, in reality, this mathematical technique is barely used in traditional (even when digital) animation. It is used a lot more in vector and 3D animation, but its role should definitely be minimized compared to the animator work even on these fields. In vector/3D, I would say that interpolation only replaced the inbetweener role (some kind of “assistant” who draw non-keyframe images) from the traditional animation world.
Timing, silence and acceleration
You often hear it from actors, poets, writers, singers, anyone who gives some kind of life: the silence is as important as the noise for their art. Well I would also add the acceleration and the symmetrical deceleration.
You can see this well on this first example of the video 1 (at 0’41). Aryeom was unhappy with her running marmot which was nearly of linear speed. Marmot arrived too fast on the flower. Well he slowed down, but barely. Her finale version, Marmot would arrive much faster with a much more visible slowdown, making the movement more “believable” (we get to the bases!).
The eagle flight in video 2 (at 1’09) is another good example of a difficult timing as Aryeom went through 2 stages before finding the right movements. With the wrong timing, her flying eagle feels heavy, like it has difficulty to lift itself into the air (what she called her “sick” eagle in the video); then she got the opposite with an eagle she felt more sparrow-like, too light and easy-lifted. She was quite happy with the last version (obtained after 8 attempts) though, and in particular of this very last bit in the cut, when the eagle gets in glider mode. Can you spot it? This is the kind of difference which just lasts for a few hundredth of seconds, barely noticed, yet on which an animator can spend a significant amount of time.
Living still images (aka “line boil”)
A common and interesting effects you find in a lot of animation is about a shaking still image. You can see it in the second video (at 0’33), first cut presenting the proud eagle still on his mountain. Sometimes you want to show a non-moving situation, but just sticking to a still image feels too weird because in real life, there is no perfect stillness. Even if you make all efforts to stay still for a few seconds, you will imperceptibly move, right? So how do you reproduce this? The attempt to stay perfectly still while this being impossible? Well commonly animators will just redraw the same image several times because as much as you can’t stay still, you can’t draw perfectly identical images twice either (you can get very close by trying hard though) and you loop them.
You usually don’t do this for everything. Typically, elements of the background, you accept them to be still much more easily. But this is common for your living character or sometimes to pull main elements which you want to tick out of the background.
Now, loops are very usual in animation. But the higher quality you aim for, the less you have loops. Same as stillness does not exist in life, you never repeat exactly the same movement twice. So even though loops seems to be the first thing many animators will teach (the famous “walking cycles”), you don’t actually use these in your most beautiful animations. When your main character walks, you will likely re-animate every step.
Of course, it is up to you to decide where to stops. Maybe for this flock of birds in the background, far away, just looping (and even copy-pasting the birds to multiply them!) may be enough. Though this is all a matter of taste, time, and money ready to spent on animator-time obviously.
This part has not really started yet, even though it has already been planned (from the storyboard step). But since Aryeom started (first video at 1’06), let’s give some more infos.
Panning and tilting
In animation, where the movement is by essence 2D as well, these refers to respectively a horizontal and vertical camera movement. Why do I need to say “in 2D animation”? Because in more traditional cinema, these will rather correspond to a tracking shot done on rails, whereas panning and tilting refer to angle movements of a static camera. Different definitions for different references. Note that even though 3D animation could be using one or the others, they mostly kept the animation vocabulary.
This gives you a good hint on how characters and background are separately managed. If you have a character walking, you will usually create a single image of the background, much bigger than the screen size, and your camera will move on it, along with the character layers. With fully digital animation, this usually means working on image files of much higher sizes than the expected display size; in traditional physically-drawn animations, it means using very large papers (or often even sticking papers together). As an example, at a Ghibli exhibition, they would display the background for a flying cut of “Kiki’s delivery service” and it would take a full wall in a very large room.
Animation is a lot of drawing
I will conclude the section on animation by saying: that’s a bloody lot of drawing!
As you can see, Aryeom spends time redrawing the same cuts so many times to get the perfect movement that sometimes she becomes crazy and thinks that she is just drawing the wrong animal. The story about the pigeon is a true story and I am the one who told her to add it to the video because that was so funny. Some day, she comes to me and show me her cut she has been working on for days. Then she asks me: “doesn’t it look like a pigeon?”
Hadn’t I stopped her, she was ready to start over.
This is an art where you even draw again when you want to show stillness, and you forbid yourself from using too much shortcuts like using loops. So what do you want: you probably have to be a little crazy from the start, no? 😉
There are actually several “schools”, and some of them would go for simplicity, shortcut and reusage. Japan is well known for the studio Ghibli which goes the hard way as we do, but this is quite a contradiction in the country industry. The whole rest of Japan’s animation industry is based on animating as little as possible. Haven’t they proved so many times that it is possible to show a single still image for 30 seconds, add sounds and voices, then call it an animation?
Sometimes it is just a choice or a focus. Some animation films focus on design rather than believable movements, or scenario rather than wonderful images. For instance, I don’t think you can say that The Simpsons has a wonderful graphics appeal and realistic animation (they even regularly makes meta-jokes inside episodes about the quality of their animation!), but they have the most fantastic scripts, and that’s what makes their success.
So in the end, there is no right choice. Every one should just go the way they wish for a given project.
And this is the way we are going for ZeMarmot!
Just a very short note on music. We have started working with the musicians, remotely and on a physical meeting on December 1st. We have a few extracts of “first ideas” but they won’t do justice to the quality of the work.
I think this will have to wait for much later.
I went so long about animation that I hope I have not lost half of the readers already! If you are still reading, I’ll say what I worked on these last months.
I am trying to do my share on GIMP, to improve it globally, speed up the release of 2.10 and because I love GIMP. So I count 259 commit authorship in 2016 (60 in the last 3 months) + 48 as committers only (i.e. I am not the author, but the main reviewer of a patch which I pushed into our codebase). I commented on 352 bug reports in 2016, making it a habit to review patches when possible.
I have a lot of projects for GIMP, some of the grander being for instance a plugin management system (to install, uninstall and update them easily from within GIMP, and a backend side for plugin developpers to propose extensions), but also a lot of ideas about the evolution of the GUI (this should be discussed topic-per-topic on later blog posts).
Also I have been starting to experiment with Flatpak so that GIMP can provide an official release for GIMP. For years, our official stance has always been to provide a Windows installer, a OSX package, and GNU/Linux… yeah grab the source and compile or use the outdated version from your package manager! I think this situation can be considerably improved with Flatpak and similar technologies which were born these years.
Animation in GIMP
As explained already, I took the path of writing it as a plugin rather than a core feature. Anyway GIMP is only missing a single feature which would make it nearly as powerful: bi-directional notification (basically currently plugins don’t get notified when pixels are updated, layers are renamed, moved or deleted, images closed…). That’s actually something I’d like to work on (I already have a stash somewhere with WIP code for this).
The animation plugin currently has 2 views:
This actually corresponds to the very basic animation logic of 1 layer = 1 frame, which is very common by people making animated GIF (or MNG/WebP now), except with a nice UI to set each image duration (instead of tagging the layer names, a very nasty user experience, feature hidden and found only on some forums or old tutorials), do basic compositing and even comments on vignettes if-need-be. All this with a nice preview in real-time!
This is the more powerful view where you can compose a frame from several images, often at least a background and a character. In the above example, the cut is made from 3 elements composed together: the background, the eagle and the marmot.
You may usually know more of the “timeline” style of view, which is basically the same thing except that frames are displayed as horizontal tracks. I tried this too, but quickly shifted to this much more traditional view in the animation world, which is usually called an x-sheet (eXposure sheet). I found it much more practical, allowing commenting more easily too, easy scroll, and especially more organized. There is a lot you don’t see in this screenshot, but this view is really targetting a professional and organized workflow. In particular with layers properly named, you can create animation loops and line tests of dozens of images, with various timings, in a few clicks.
I am also working on keyframing for effects (using animated GEGL operations) and camera movements.
Well there is a lot done but definitely a lot more I am planning to do there, which takes time. I will post more detailed blog posts and will push the code on a branch very soon (probably before Libre Graphics Meeting this year).
That’s all, folks!
And so that’s it for this end-of year report from ZeMarmot team! I hope you appreciate the project. And if so and can spare the dime (or haven’t done so yet), I remind the project accepts any amount on the links given above. Some people just give 1 Euro, others 15 Euro per month. In the end, you are all giving life to ZeMarmot!
mrxvt is a cool light-weight terminal emulator, not tied to a specific desktop environment and with minimal dependency. This was also one of my very first bigger contributions to Free Software. Well I had patches here and there before, but that’s one project where I stuck around longer and where I was quickly given commit rights. So it is dear to my heart. It was also my first big feature attempt since I started a branch to add UTF-8 support (actually any-encoding support), which is the normal way of things now but at the time, many software and distributions were still not working with UTF-8 as a default. Then I left for years-long wandering our planet on a motorcycle (as people who know me are aware) and because of this, drastically slowed down FLOSS contributions until a few years ago. Back as a contributor, mrxvt is not my main project anymore (you know which these are: GIMP and ZeMarmot!). I moved on.
Now I have to admit the awful truth: I don’t use mrxvt much anymore. My main reason is actually because I need dearly UTF-8 and even though I’d love to finish whatever I started on this topic years ago, I don’t have the opportunity to do this anymore. Whatever terminal I use now* is good for me.
Yet mrxvt is still used, and we have regularly people asking about its development. So this is just a small call, if not too late:
if anyone is interested into taking over mrxvt, you are welcome to do so!
I have recently moved the code from subversion (on Sourceforge) to git on gitlab. So consider this new repository as the new official upstream of mrxvt. But be it know that my goal here is not to take back active development. I just can’t make the time to it. I can only assure that I would maintain it with GI (historical maintainer who also has commit right on the new repo as well) and would review and merge any patch which makes sense. If any developer who previously had commit rights on our subversion repository asks me for, I can give you commit rights there too.
Last but not least: if anyone wants to take over, we will gladly give ownership. But please send a few patches first. We had a few people who wanted to become the upstream without even showing a piece of code. Well we want to give the baby, but making sure first we give it to someone who cares. So just make a few patches that we can review, and we’ll happily give over mrxvt.
* Full disclosure: my current terminal of choice is Guake. Well it has unfortunately its share of bugs, but I really love the “making it appear and disappear in a click”. Considering that the terminal emulator is undoubtly the software I use the most daily, making it a special one, with its own windowing (not lost in alt-tab hell) is a very good trick to me.
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.
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.
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).
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:
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!
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).
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.
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.
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
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.
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.
So today, I will explain crossroad by giving a concrete example:
Cross-compiling GIMP on GNU/Linux for Windows system
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.
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.
$ 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
$ 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!
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:
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:
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: *** [sdl_display_la-sdl-display.lo] Error 1 make: 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.
Only a single dependency (json-c), then classical configure, make, make install:
$ crossroad install libjson-c2 libjson-c-devel && crossroad configure && make && make install
And now for the main course! Once again, I spare you some of the search of dependencies. Here for mandatory deps:
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:
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).