Hello all,

First I guess a small presentation is in order as a new member to this list: my name is Jehan. I am working with an animator, in the optic of creating an animation. And we are using Gimp for this (see http://girinstud.io/ for our newly set-up website).

As a consequence, I have been working on GIMP code lately, hoping to fix issues that my animator or I would encounter, and to add new features. For this, I have set up a public repository at git://git.tuxfamily.org/gitroot/gimpgirin/gimp.git (branch named "girin").
I have also just created my 2 first GIMP tickets, one is a bug fix (Bug 685557), the other a small feature (Bug 685559).

As the HACKING file in the repo says "The best way to submit patches is to publish your git repository and ask developers to git-fetch from you.", I just wanted to be sure the procedure is the right one. Should I rather make a new branch per fix/feature? Should I just give you the commit hashes (as I did in these tickets) and you can pick just these commits into the main repo? Do you actually prefer me to generate a patch and attach it on the list or in a ticket? Something else?
Thanks for all!

Jehan

Hi,

On Sat, Oct 6, 2012 at 12:24 AM, Michael Natterer wrote:

On Fri, 2012-10-05 at 22:37 +0900, Jehan Pagès wrote:

Hello all,

First I guess a small presentation is in order as a new member to this list: my name is Jehan. I am working with an animator, in the optic of creating an animation. And we are using Gimp for this (see http://girinstud.io/ for our newly set-up website).

As a consequence, I have been working on GIMP code lately, hoping to fix issues that my animator or I would encounter, and to add new features. For this, I have set up a public repository at git://git.tuxfamily.org/gitroot/gimpgirin/gimp.git (branch named "girin").
I have also just created my 2 first GIMP tickets, one is a bug fix (Bug 685557), the other a small feature (Bug 685559).

Thanks and welcome to the party :)

As the HACKING file in the repo says "The best way to submit patches is to publish your git repository and ask developers to git-fetch from you.",

Heh, does it really say that? I can imagine which of our git crazy hackers added this section. If you plan to keep a lot of patches around there, this is probably a good idea, for one or two it's total overkill :) we will see.

Eh! Anyway it is done now. And I will definitely have other patches. I am already working on some interesting features (which I hope you will find interesting to).

I just wanted to be sure the procedure is the right one. Should I rather make a new branch per fix/feature? Should I just give you the commit hashes (as I did in these tickets) and you can pick just these commits into the main repo? Do you actually prefer me to generate a patch and attach it on the list or in a ticket? Something else?

All is fine so far, we will look at your patches. Thanks for contributing!

Cool. Thanks.

Jehan

--mitch

Hi,

On Sun, Oct 7, 2012 at 2:13 PM, drawoc wrote:

Alexandre: I think you need to check out the branch girin in specific. If you cd into an existing gimp checkout you can do something like this:
git remote add gimpgirin git://git.tuxfamily.org/gitroot/gimpgirin/gimp.git git fetch --all
git checkout girin

Indeed. Sorry the main reason is that I use my locale "master" branch to track the upstream Gimp master, and my locale "girin" to track mine. As I like to have the same locale and remote name for simplicity, I ended up pushing only a "girin" branch on my fork. Anyway all good now. :-)

Jehan: I think we normally rebase branches around here instead of merging, just so you know.
Btw, since you're using the gimp for animation, you might want to take a look at Gimp-GAP.

I saw many references on the web about GAP, so I had a look a few weeks ago, read and looked a few tutorial and videos, and installed it. First the last code I could find (on the GIMP plugin registry) was for Gimp 2.6 3 years ago, along with a Windows binary (we use Linux distributions). I could compile it nonetheless but the fact it is obviously unmaintained is not reassuring. And not surprisingly, when running it, GIMP regularly complains through pop-ups that the plugin uses some deprecated function, etc.

Second it looked overcomplicated for cases when you want to do boring stuff on a huge scale with a few images (= do a hundred time the same thing which is boring and a waste of your time so you automatize). Like you have a text, you want it to circle around 1000 times, and change color while doing so; or have a ball jumping around for 10 minutes, etc. That's not what we do. And in particular, I don't like the way it does it. Like it creates hundreds of nearly similar xcf files, duplicates layers, and such. That would be very hard to maintain and work with in a huge project. Probably nice for making one-time GIF files, then forget about them. Not that good if each scene of a few seconds implies dozens of xcf files with several dozens of nearly identical (but sligthly different) layers.

I may have missed something. But all the tutorial and small tests I ran was ending the same way.
In other words, I was really not impressed by GAP.

Another issue is that it tries to be an all-in-one solution, whereas it doesn't do each thing that good. It tries to deal with drawing of course, but also importing from videos, the sound, sequence editing, video outputting, etc.

In our current workflow, for extracting images from video data, we use directly ffmpeg. For the sound, we will be most likely using Audacity and Ardour on a RT kernel. And for video editing, our current tests led us to the Blender video editor (kdenlive has limitations which made it impossible to work with it with more than 2 video channels, and I have not tested much Cinerella yet).

Once again, if I am wrong and GAP is the ultimate animation tool, please tell me. :-)

In the meantime, I am actually improving the default animation plugins available in GIMP upstream repo. I am making so these simple tools will be all what is necessary to work nicely with GIMP xcf, only for the drawing part inside a more complete workflow with other tools. I have done some very nice stuff (partially already in my branch), but I am not fully done. I plan to make a new bug ticket to propose my improvements when in a good release test. I will probably make a small demo along to explain these and post on the list.

Anyway, it's always good to have more contributers.

:-)

See you soon.

Jehan

-- drawoc

On Sat, Oct 6, 2012 at 8:25 PM, Alexandre Prokoudine wrote:

On Fri, Oct 5, 2012 at 5:37 PM, Jehan Pagès wrote:

As a consequence, I have been working on GIMP code lately, hoping to fix issues that my animator or I would encounter, and to add new features. For this, I have set up a public repository at git://git.tuxfamily.org/gitroot/gimpgirin/gimp.git (branch named "girin").

"warning: remote HEAD refers to nonexistent ref, unable to checkout."

Alexandre Prokoudine http://libregraphicsworld.org
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Hi,

On Mon, Oct 8, 2012 at 1:39 AM, Alexandre Prokoudine wrote:

On Sun, Oct 7, 2012 at 4:15 PM, Jehan Pagès wrote:

it. First the last code I could find (on the GIMP plugin registry) was for Gimp 2.6 3 years ago, along with a Windows binary (we use Linux distributions). I could compile it nonetheless but the fact it is obviously unmaintained is not reassuring.

It's not a fact, it's an assumption and an incorrect one at that :)

http://git.gnome.org/browse/gimp-gap

Thanks. I could not find a repo before. I'll have a look there.

In our current workflow, for extracting images from video data, we use directly ffmpeg. For the sound, we will be most likely using Audacity and Ardour on a RT kernel.

I would recommend Ardour 3 and xjadeo for syncing audio and video.

Thanks for the advice. I'll have a look at this. Any other advice on any part of a full movie creation workflow is good to take, so don't hesitate (true for everyone on the list)! :-) I am just starting to compare, research and test all these awesome programs.

Unless, of course, by the time you get to that stage Paul merges video tracks patch to Ardour.

Ok I miss the references so I guess I need an explanation because I am either too new to the GIMP list to know a Paul, or that's someone from Ardour's dev team, or from somewhere else. And what is the video tracks patch you are talking about? Is Ardour becoming a Video Editor as well?

Thanks.

Jehan

Alexandre Prokoudine
http://libregraphicsworld.org
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list