Survey - What do you want in a Time Lapse Camera script

zapta

@arhi, I run this macro on layer change. It triggers a relay connected to E1 output. IIRC, there is also a resistor or two involved in the circuit, per the requirements of the Panasonic camera. I can look for the full circuit if it matters.

https://github.com/zapta/misc/blob/master/hevo/duet/macros/camera_click

Danal

@zapta said in Survey - What do you want in a Time Lapse Camera script:

I take time lapse videos with a Panasonic camera that is triggered on layer change. Not sure how it fits the survey.
My preference is not use use a RPI with my printer to avoid having to set yet another computer.
Hope it helps.

Thank you for your comments and information on your technique. At the same time, it sounds like you won't be using the upcoming scripts.

Danal

@arhi said in Survey - What do you want in a Time Lapse Camera script:

Later on, compile the snapshots into the timelapse.

What are you using to compile the snapshots? I'm currently using:

ffmpeg -r 10 -i /tmp/DuetLapse/IMG%08d.jpeg -vcodec libx264 -crf 25 -s 800x600 -pix_fmt yuv420p -y -v 8 ~/DuetLapse.mp4

arhi

@Danal said in Survey - What do you want in a Time Lapse Camera script:

What are you using to compile the snapshots? I'm currently using:

I use similar ffmpeg only libx265 and lower resolution and lower bitrate 'cause I use that mp4 only as preview. Sometimes I don't even make that preview.

I keep all the original high res images and manipulate them in the adobe premiere. Or to be more correct, I did, but I stopped paying full adobe subscription recently so now I don't have premiere any more and am figuring out if I can do it with open source tools like openshot. But work has bin crazy lately, so it's on standby. I don't have too much time for printing and I'm currently not making any recording at all as DSLR I use for 3d print recording is in service (I left it there for cleaning before this $#%^^#%* we are experiencing now) so till this is over no more timelapses for me (as I don't want to use my 5d4 for that, I use 350d and 1dx mark2 normally for that)

Danal

Thanks! Sucks that the cam is stuck, I know many people with equipment in similar situations.

Stay Safe,

Danal

arhi

@Danal well I can probbly get both cameras back in day or two if I really needed them but so much other stuff happening...

On any way, I think gphoto2 support is super important as it will support ton of dslr/milc cameras attached to usb, you can take a snapshot, get the image etc etc .. it is also important to have a "pin" trigger too. I use gphoto2 with 350D but 1ds mark2 is old and does not support all gphoto2 features so I'm using external pin to trigger that one.

Check the https://github.com/FormerLurker/Octolapse/wiki/Configuring-an-External-Camera if you did not already.

Now with RRF, the scripts I already seen seem great. Easy to push a script in the slicer directly and with push/pull features of RRF you can generate a pause, move head away from camera, trigger output to catch image, wait for external trigger that image is taken to continue, get head back to where it was, continue print. And if you don't want to have feedback but you just know how much time you need for a photo to be taken, breaking the 1$ IC remote for camera apart and connecting to the mentioned pin is all you need to get your external camera to work

Danal

Yeah, external seems to some degree like it doesn't need a Pi based script at all. Gcode from layer change in the slicer + Duet macros + a pin, that all works very well already. I don't see the value add. Especially not in the pure "pin" use case.

Gphoto2... maybe... I'll have to think about that one some more.

What is the advantage over a pin? During the print? I understand (or I think I do) retrieving the photos and making a video after the print finishes... but when you get right down to it, that is NOT a "Duet" script. It could run on any platform that can reach the camera, and has absolutely no value add to interface to a Duet, beyond starting when the print ends.

What are your thoughts? What would a Pi script really do that does not already happen with a pin? Or gphoto2?

arhi

@Danal said in Survey - What do you want in a Time Lapse Camera script:

Yeah, external seems to some degree like it doesn't need a Pi based script at all. Gcode from layer change in the slicer + Duet macros + a pin, that all works very well already. I don't see the value add.

The "external pin" have 2 downsides

You need to know how to set it up, you either want to use the trigger port on your camera to run a wire and use some fet triggered from the pin or you break the remote control and hit it with the same setup... that require spare cable or spare remote, soldering, fet and some parts around it... In this "can I buy ready made so I just click it in" world that's too much tinkering
All your images stay on the camera.

Gphoto2 on SBC and camera connected via usb is plug & play.

A couple of people have mentioned that's what they do, in the comments of the survey. So what are your thoughts. What would the Pi script really do?

For me, the biggest benefit is moving files from the camera to the SBC. Since all the camera's I use for this purpose have ony CF slot and CF cards are rather expensive in high capacity + they don't like being plugged in/out too often (the reader pin's get bent, the connectors die), so if you are going with RAW images you need to physically get the CF card to your reader every one/two prints, and if you are running some long print you can easily get CF card full before the print ends. With gphoto2 I just scp the files to my desktop and go from there, the CF card is basically empty all the time.

Now, what might be interesting to have, that's impossible withoug SBC is overlay. It would be super cool to record a full status (maybe that full json output of the M409 with full depth) with every image so that later it can be postprocessed into the timelaps video (temp graph, Z position, dunno what else might be interesting..). I kinda assume most of us make timelapse videos to detect / inspect issues. Having additional info is super helpful there.

Furthermore, sending these images to https://www.thespaghettidetective.com/ would also be super cool.

I now use IP camera's for monitoring prints, telegram plugin and thespaghettidetective, and these external ones for timelapse.

Danal

@arhi said in Survey - What do you want in a Time Lapse Camera script:

Gphoto2 on SBC and camera connected via usb is plug & play.

need to physically get the CF card to your reader every one/two prints, and if you are running some long print you can easily get CF card full before the print ends.

Got it. Will think about those aspects. THANKS!

arhi

@Danal would be good to get in touch with the guy owning octolapse. From what I hear he's approachable and decent :). I know you can find him on octoprint forum ( https://community.octoprint.org/ ) but could probbly be contacted trough github too. He should have info on how many user use it and how they use it, what type of cameras etc. It's a huge community so that info might be relevant for you too. I personally don't know anyone who uses DSLR to take snapshots (I now, in this thread, hear about one) so we are maybe irrelevant minority, or there's maybe actually ton of ppl doing it...

Danal

https://github.com/DanalEstes/DuetLapse

Is ready for "alpha" testing for those ~~brave fools~~ er, uh, kind souls who want to take a look. Run it with no arguments and it will begin to help you figure out how to run it. I have done some very basic testing, but have not yet even run it through a print.

It needs https://github.com/DanalEstes/DuetWebAPI in the same directory (or, technically, in your python include path). It shouldn't need anything else.