Feat.Req: Execute custom command when grabbing frame

Bug #1069185 reported by Arthus Belliqueux on 2012-10-20
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linux Stopmotion

Bug Description

Feature Request : Add an option in LSM preferences to execute a command when grabbing a frame ( i.e : A command that executes each time the spacebar/ capture button is hit )

This would enable users to have a custom command runnin on each frame grab like :

- grab high quality pictures from a SLRD cameras with utilities like gphoto2.
- play a sound when grabbing a frame.
- interact with elements that need step by step evolution ( servomotor to achieve a camera motion, light stroboscop, dimming, have a background projected video playing frame by frame as you take shots...)

An option exists that allow users to define a command that is executed when activating/disabling the preview, but doesn't repeat on each image grab.

It would enpower users to integrate LSM into a custom workflow.

EDIT: Modified description not to be so specific on the usage of the feature.

tags: added: feature
removed: featqure


Webcam and DSLR camera wouldn't capture the same frame since they can't be in the same place and position. How do you imagine to fix this problem?

Arthus Belliqueux (ab-reg) wrote :

Hi there,

First, I wan't to say I'm very glad someone stood up to take this project in charge again and apologise if the feature requests don't really belong in the bug tracking system.

As for your question, I must emphasize that the webcam would in that setup only serves as a visual guide that helps you to achieve a motion. In that case, a different camera angle doesn't matter as the preview you're looking for is of the motion and not of the final composition of your image. Numbers of professional studios work in this way, as processing very large images is heavier on cpu than SD. I agree that for some scenes, it will come off as a problem though.

In that case, what I do is putting my webcam in the sight of the DSLR..I'm not sure I'm making myself clear here, so see the pic in attachment :)

Sorry if I have trouble putting words on my thoughts as english is not my native language !

Thanks Arthus. It's very clear now.
So far we discussed only about DSLR camera with live view planning to implemento a double shot (one from the low res preview and one HD shot), so to put in place a proxy workflow.
I understand your need comes from a DSLR camera vith no live view.

Arthus Belliqueux (ab-reg) wrote :

Indeed, I did forgot to mention that important point ! I can think of a few more usages to the original feature I was requesting.
You could use it to play a sound when grabbing a frame, as I saw in another feat. request.
You could interact with a servomotor (via arduino for example) in order to achieve a camera motion.
You could interact with other IRL elements that need step by step evolution ( light strobo, dimming, have a background projected video playing frame by frame as you take shots...)
As I see it, it would be a powerful added value to the software in a Gnu/Linux tubes philosophy way ! It also seems quite trivial to implement as there is already the polling that works in a similar way ( executes on button activation).

I did go through the sources a bit to try a dirty hack, but I don't know much about C programming, otherwise I would have gladely done it myself.

Arthus Belliqueux (ab-reg) wrote :

(Can't find a way to edit my previous post)

By "the polling ", I meant the prepoll command you are able to define in the preferences at the moment.

There is already a primitive live preview DSLR grabber intended for LinuxStopmotion, hosted at Sourceforge: http://sourceforge.net/p/linuxstopmotion/fe09/

Source code only, for now.

Proper DLSR support, with both medium-resolution continuous preview and high-res capture is on my TODO. :-) It requires some invasive rewriting of LinuxStopmotion, though.

Ok, I get it: What about DSLRs with no live view or preview feature at all? You would like to use two cameras; one for continuous preview, and one for capture. I'll keep that in mind. :-)

Arthus Belliqueux (ab-reg) wrote :

Hi there !

I've already stumbled accross this experimental feature, but I d'like to remind here that DSLR grabbing is one of many use this feature would allow. I see it mainly as a way for LSM to integrate into a custom workflow.

description: updated
Changed in lsm:
importance: Undecided → Wishlist
Tim Band (tim-band) wrote :

It's hard to know how to do this nicely and cover all the bases. You want the "on capture" command to be able to capture an image. So, $(IMAGEFILE) should be different to the one passed into "start daemon" and "pre-poll", so that it isn't interfering with that operation. But then if the "on capture" doesn't actually capture an image (if it plays a sound, for example), you will never capture anything.

Options: (1) Ignore the problem. Assume we get a capture.
(2) Add a check box to say "this command captures an image"
(3) Allow the command to copy the latest preview image by passing in $(PREVIEWFILE) as well as $(IMAGEFILE), so in the absence of a capture command, cp $(PREVIEWFILE) $(IMAGEFILE) could be used. This seems a confusing option.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments