Improved animation support
Bug 22718 imported from GNA! bug tracker
Submitted by: jehan on 2014-09-28 23:09:39
Right now, the only animation/stopmotion-related feature is onion layers, and it is not practical at all because you have to open the preferences all the time to enable/disable it or change its value.
My patch replaces this preference item with a single checkbox "Display animation features". When checked, animation-related features are shown in the main UI. Overlay layers are moved there. This is the first change. There is no checkbox anymore, when animation features are enabled and layers > 0, layers are shown.
The second feature is that it displays a bunch of buttons in this animation mode, to play the animation made up by all the images in the session. i.e.: play/pause, etc. Frame rate can also be chosen.
This is a first iteration, and clearly a lot will be proposed afterwards. First of all, the user should be able to select a first and last frame to play (right now, it plays all the existing frame). Also it should be possible to use proxy version of the image (in lower resolution) rather than the original images, especially when very high resolution images are shot (in such a case, expected frame rate may not be reachable).
And so on. I oversee a lot of other improvements. But that's a first step. :-)
I hope you'll integrate it.
Comment by: jehan on 2014-09-28 23:14:32
By the way, it is a choice that the playback does not "select" images. I was unsure whether we should select each frame one by one, or just display them and keep the current one selected, and I implemented both version.
In the end, I decided the selected image should stay selected. Video playback is only displayed without interacting with image selection.
Comment by: danpb on 2014-09-29 19:04:48
This is a nice idea in general. I've not looked at the patch in detail yet, but from a quick glance I've got a couple of thoughts
In terms of the UI additions, rather than adding to the toolbar, I think it would be preferrable to add it as a panel to the left-hand side control panel. ie make it appear as if this is just one further set of controls for the camera. One of the things I have planned is to experiment with the new GTK "header bar" widget (see https://developer.gnome.org/gtk3/stable/ch01s05.html#id-1.2.3.7.13) which lets you combine the toolbar into the title bar. If I do this there won't be sufficient space to hold the animation buttons, which makes use of the control panel pretty desirable.
You mention the problem with high res images and frame rate. I wonder if rather than displaying images in a sequence using a timer callback, we should instead make use of gstreamer to actually the images into a video file format. We could create a 'EntangleVideoDisplay' widget as an alternative to the current 'EntangleImageDisplay' widget when needing to show videos. This would be useful even outside animation scenario. eg my Nikon DSLR can record videos & entangle can download them, but we don't have the ability to display them. So using gstreamer for rendering & display could let us solve both these scenarios much easier.
Of course encoding a large set of hi-res images to a video file itself takes considerable time. We could perhaps optimize this by actually encoding the files to a video as you capture them, so the video file is always there ready to be displayed at a moments notice.
http://docs.gstreamer.com/display/GstSDK/Basic+tutorial+5%3A+GUI+toolkit+integration
Comment by: jehan on 2014-09-30 18:04:26
> I think it would be preferrable to add it as a panel to the left-hand side control panel. ie make it appear as if this is just one further > set of controls for the camera.
In this case, do we want to show these controls all the time, or same as my patch, only when the user checks some option in the preferences? Also I am a little scared of the confusion of functions: whatever in this panel right now is specific to the connected camera. But these animation functions are generic. Also they could show even with no camera connected. But if that's ok for you, well why not. We can try.
Another UI idea I thought about was to be able to pop-up a separate video preview window (which would have all necessary controls). But for this first version, I wanted an easy solution first. I think this can get implemented on a second step.
About rendering to an actual video file, this is a possibility of course. Note that I think that exporting to any video formats is a nice feature, but not a big must-have for a stop-motion software in my opinion. I know this is not what you were speaking about, but since being able to render a video file for preview would obviously lead also to being able to easily render a finale video, I just wanted to make this point. For me, the main point is to be able to preview the animation in progress as photos are taken. Anyway if images are taken as RAW, there would be a development step (Darktable), and there could be additional "effects" steps (GIMP), then video editing. There is no problem for me to use more dedicated in-between software for these steps, and I don't mean Entangle to handle all the process towards finale rendering. Anyway after this small digression, yes why not. This is worth testing at least.
Comment by: danpb on 2014-09-30 18:37:46
It occurs to me that switching to use the left hand control panel might be easier todo once I refactor that bit of code to simplify the UI.
I can see that you don't really need movie export mode in Entangle due to the post processing needs. I think the gstreamer work might still be worthwhile in the long run.
That said I'm wondering whether I might just merge the patch you have posted as it is now, and then let us work on improving things as separate followup work.
I'll do a more detailed code review & get back to you
Comment by: gasche on 2015-10-31 11:56:07
Any news of the status of this patch?
I had a look at my sister's issues with Entangle (the other option being to add a Windows dual-boot to use proprietary software instead, which we would rather avoid), and it seems many of them would be solved by the patch proposed by Jehan below.
The problem is that it is extremely hard to try this patch for non-programmers. I got it to compile through the following steps:
- the patch does not apply on 0.7.0 nor 0.6.1
- however, 0.6.0, on which the patch cleanly applies
- the reason why 0.6.0 doesn't compile is that autoconf adds -Werror whenever it detects that we are compiling from git (which seems to be the easiest way to try many old versions).
- disabling this m4/entangle-compile-warnings misfeature lets me build a version of 0.6.0 with Jehan's patch.
The result is usable, seems to have some instabilities (the first time I enabled "Display animation features" from the Settings I got a segfault; I also observed important lag with the default setting of 3 overlays, which was avoided by just setting it back to 0), and seems a very useful step towards making Entangle more usable by for stop-motion artists.
Jehan, would you be able to rebase the patch against the more recent version of entangle (0.7.0 or git master)?
Daniel Berrange, would it be possible to merge such a rebased patch and build on top of it?