DuetLapse3

stuartofmt

This post is just to illustrate the sort of flexibility and control that DuetLapse3 V4.0 provides.

Usually, when I print, I like to use a combination of layer changes and time to capture images. This makes the position of the printhead somewhat ambiguous at the end of the print job.
I also lower the print bed at the end of the print job.
For timelapse, I want the print head out of the way for the last image capture and I do not want any of the lowering etc.

Here is what I want it to look like:
Benchy.mp4

The following skeletal gcode illustrates one way of achieving this:

; This is the Start G-code
;  Call macro that puts DuetLapse3 into standby and sets the desired parameters
;  Among which seconds=20 and detect=layer and extratime=4
;
;M98 P"/macros/timelapse_layer_20sec.g"
;
;<snip> Pre-print gcode
;
M117 DuetLapse3.start  ; starts both layer and seconds capture just as the real print starts
G4 S10
;
; End of start G-code
;
;<snip>  The actual print gcode
;
; This is the End-gcode
;
G91           ; Use relative mode
G0 Z1         ;E Move the bed away a little note use of E after comment for correct layer count
G90           ;Back to absolute mode
G0 X0 Y0      ;Get the print head out of the way
              ;I don't do this in pause.g
;
;  This next bit is a bit sneaky - change DuetLapse to detect=pause will capture a final image when the pause is sent
;  Because we previously used G0 X0 Y0 the print head will not be in the way when the extratime images are generated
;
M117 DuetLapse3.change.detect=pause
G4 S10
;
M25          ; Don't use M226 here. DuetLapse3 sends unpause when its ready
G4 S10       ; Give pause unpause etc time to catch up
;
M117 DuetLapse3.completed  ; Stop the DuetLapse3 timelapse here
G4 S10					   ; None of the movements that may follow will be captured in the timelapse
;
; <snip>
;
M98 P"/macros/timelapse_defaults.g"  ; Reset to my normal defaults for DuetLapse3
;
M0            ; stops the print job and calls stop.g which in my case has a move to the bottom that I don't want to see
; End of End-gcode

stuartofmt

Just released V4.1.0

The main change is increase control in the DuetLapse3 UI. For many users, this will mean that the use of startDuetLapse3 can be infrequent and instead just have DuetLapse3 running all the time.

Version 4.1.0

[1] Added support for M117 DuetLapse.change.movehead=x,y
[2] Added Delete, Zip, Video in UI for completed jobs in currently running instance
[3] Suppressed long message when a client (browser) disconnects during UI update

LuniLAB

Is there any noob friendly guide to get it running...?

stuartofmt

@lunilab
I have not been active for a couple of weeks and just saw your post. What problems are you having?
The documentation is fairly comprehensive - if it needs improvement / fixing then I can help.

T3P3Tony

@stuartofmt would you be able to look into submitting DuetLapse to the plugin repository as well?
https://plugins.duet3d.com/

stuartofmt

@t3p3tony said in DuetLapse3:

@stuartofmt would you be able to look into submitting DuetLapse to the plugin repository as well?
https://plugins.duet3d.com/

I will. I have not looked at the plugin requirements. DuetLapse is written in Python, so not sure if that is an impediment.

T3P3Tony

@stuartofmt a DSF plugin can be written in python so that should be fine

stuartofmt

@t3p3tony
Ok! So the UI presented by the plugin would be the same as the current browser ui (more-or-less)? In other words the intent of the plugin would be eliminate the use of a browser UI ?
I'm trying to tease out the desired functionality. Might a simple iframe be just as effective ? Just probing here ...

T3P3Tony

@stuartofmt Thanks for the questions, its forced me to articulate my ideas better!

I visualised it as the "front end" UI elements are displayed as a plugin within DWC, similar to how other plugins are displayed. This would allow the setup of the time-lapse parameters in a GUI. As a bonus it would also display either a static image (last capture?) or a video feed of the camera (that could be something for a future version though)

The back end elements would run as a DSF "plugin" to manage the captures. It could gather any information it needs from the object model/intercept gcode using the DSF API. It could use the DSF API to manage the printer during the capture (either directly by sending the gcode movement and dwell commands, or by calling the a macro).

What do you think about the idea?

stuartofmt

@t3p3tony
I'm wondering whether the main intent might be to use the plugin framework as a convenient means of installation?

Given that DWC is browser based and the DuetLapse UI is also browser based (albeit ugly) - is there added utility having a UI within a UI compared to just having DuetLapse in a separate browser tab?. I'm not asking this to be difficult - just to better understand the ask.

For example - in DWC --> Settings --> General --> Webcam if you put in the URL for DuetLapse. You will get the Duetlapse UI by clicking the Webcam link in DWC. Is this the general sort of behavior you envisage?

Regarding the use of DSF API -- I do not know what the added benefit would be (remember - I've not looked yet). DuetLapse already interrogates the object model and sends gcode (using http). Maintaining and testing two different interfaces would need to be offset by some material advantage.

I had not thought about Duetlapse displaying the last captured image. I usually use videostream to broker images and have a link to that in my DWC. There is certainly utility in incorporating an image display function into DuetLapse - it should be straightforward enough.

T3P3Tony

@stuartofmt Yes they main point from the front end is it brings it into the structure of plugins which ease installation (and potentially discovery by users, once the plugin repository is more used). In addition alerting users to updates through the plugin system would be available once that feature is implemented.

The back end side of things could stay with the http API. In some ways that's more flexible as you could then run it on a Pi, without having a duet 3 in the mix. The biggest advantage of using what you have is of course that it already exists. In the long run using a DSF "plugin" for the backend instead will hopefully also ease installation and updating. It will potentially also allow for the plugin directly managing the gcode stream with nothing inserted form the slicer (using gcode interception to spot layer changes for example, carrying out some user defined functions, and then allowing the print to continue).

All that said, the most immediate benefit appears to be with a DWC plugin for the UI to ease installation and discovery.

stuartofmt

@t3p3tony said in DuetLapse3:

@stuartofmt Yes they main point from the front end is it brings it into the structure of plugins ......

Can you point me to a "step by step" document / example? I've searched and searched but all I seem to find is descriptions of folder structures within a zip file, or git references that are just source code. I get that bit (more or less).

What's missing for me is a clear explanation of what goes in which folder, how those components need to be structured (internally) , and the structure (and switch meaning) for the main config file. Especially: what is the mechanism for linking to the http interface.

I've made some interim changes to my code to support the idea of its own configuration file (previously all cmd line). I need to understand what other changes may be needed.

Thx in advance.

chrishamm

@stuartofmt You can find current documentation about plugins here:

for DSF: https://github.com/Duet3D/DuetSoftwareFramework/wiki/Third-Party-Plugins
for DWC: https://github.com/Duet3D/DuetWebControl/wiki/Third-Party-Plugins
There is an automated build script for DWC plugins as well, it should be described in the second link, too.

DWC is being heavily changed at the moment but as a general starting point I suggest you read through these two articles and have a look at either the endstops plugin or the motion webcam server plugins. In both repos you can find a short README section explaining how they can be built.

osterac

Hi
This is a great solution for timelapses. Thanks!
I was wondering how I can change the webcam capture resolution. I read through the documentation but some of it was a bit over my head. My camera is capable of 1440p but duetlapse3 records at 720p. I think 1080p would be a good resolution for my videos. I use this command to start duetlapse3:

sudo python3 /home/pi/ftp/files/DuetLapse/DuetLapse3.py -duet 192.168.1.8 -deletepics -seconds 20 -fps 30  -detect none -restart -camera1 web -weburl1 http://192.168.1.30/picture/2/current/ -extratime 3 -basedir /home/pi/ftp/files/DuetLapse -standby

Thanks!

PS I think a great addition would be an option to set how long the video will be and automatically adjust settings so it always comes out that length. This way you don't get timelapses of short prints that are only a few seconds long, and really long prints won't be too long and slow. Octolapse has this feature.

stuartofmt

@osterac said in DuetLapse3:

Hi
This is a great solution for timelapses. Thanks!
I was wondering how I can change the webcam capture resolution.

PS I think a great addition would be an option to set how long the video will be and automatically adjust settings so it always comes out that length. .......
Octolapse has this feature.

DuetLapse uses ffmpeg to "stitch" together the individual frames. The primary resolution is set by the software controlling the camera. In your case, this is whatever is serving up images at http://192.168.1.30/picture/2/current/. That is where you will have the control over resolution.

I do have a companion program videostream which allows the resolution to be changed for most usb cameras (and Pi cameras).

https://forum.duet3d.com/topic/23759/videostream/12

On the question of video length. In a naïve way - x seconds of fixed length video would be easy to achieve. Number of images / fixed length = fps. Whether the results would be pleasing to the eye might be a value judgement.
I'm guessing this is what Octolapse does?

osterac

@stuartofmt
I dug up some old octolapse videos and they were all at different framerates so yes, it does work that way. I looked at my webcam (motioneye) settings and it was set to 1440p. I set it to 1080p and the video was still 720p. It also had problems, it started in the middle of the print and skipped forward and backward a couple of times. It was also at 10 FPS when I requested 30 FPS. Here's the media info:

Video 
ID : 1 
Format : AVC 
Format/Info : Advanced Video Codec 
Format profile : High@L3.1 
Format settings : CABAC / 4 Ref Frames 
Format settings, CABAC : Yes 
Format settings, Reference frames : 4 frames 
Codec ID : avc1 
Codec ID/Info : Advanced Video Coding 
Duration : 25 s 300 ms 
Bit rate : 1 975 kb/s 
Width : 1 280 pixels 
Height : 720 pixels 
Display aspect ratio : 16:9 
Frame rate mode : Constant 
Frame rate : 10.000 FPS 
Color space : YUV 
Chroma subsampling : 4:2:0 
Bit depth : 8 bits 
Scan type : Progressive 
Bits/(Pixel*Frame) : 0.214 
Stream size : 5.96 MiB (100%) 
Writing library : x264 core 155 r2917 0a84d98 
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=10 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00 
Color range : Full 
Codec configuration box : avcC

I'll give videostream a try, do I install it on the webcam server or the pi running Duetlapse 3? I don't think I could install it on motioneye, because it's buildroot. You can install motioneye on top of a full linux distro though.

Here's a link to the faulty timelapse:
https://1drv.ms/v/s!ArZNmx9oeG5CzQKqBpTQqJG-LFmP?e=7BoTKS

Thanks

stuartofmt

@osterac said in DuetLapse3:

@stuartofmt
I dug up some old octolapse videos and they were all at different framerates so yes, it does work that way. I looked at my webcam (motioneye) settings and it was set to 1440p. I set it to 1080p and the video was still 720p. It also had problems, it started in the middle of the print and skipped forward and backward a couple of times. It was also at 10 FPS when I requested 30 FPS. Here's the media info:
Video 
ID : 1 
Format : AVC 
Format/Info : Advanced Video Codec 
Format profile : High@L3.1 
Format settings : CABAC / 4 Ref Frames 
Format settings, CABAC : Yes 
Format settings, Reference frames : 4 frames 
Codec ID : avc1 
Codec ID/Info : Advanced Video Coding 
Duration : 25 s 300 ms 
Bit rate : 1 975 kb/s 
Width : 1 280 pixels 
Height : 720 pixels 
Display aspect ratio : 16:9 
Frame rate mode : Constant 
Frame rate : 10.000 FPS 
Color space : YUV 
Chroma subsampling : 4:2:0 
Bit depth : 8 bits 
Scan type : Progressive 
Bits/(Pixel*Frame) : 0.214 
Stream size : 5.96 MiB (100%) 
Writing library : x264 core 155 r2917 0a84d98 
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=10 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00 
Color range : Full 
Codec configuration box : avcC 
I'll give videostream a try, do I install it on the webcam server or the pi running Duetlapse 3? I don't think I could install it on motioneye, because it's buildroot. You can install motioneye on top of a full linux distro though.

Here's a link to the faulty timelapse:
https://1drv.ms/v/s!ArZNmx9oeG5CzQKqBpTQqJG-LFmP?e=7BoTKS

Thanks

osterac

@stuartofmt
Did you mean to make a post with only a quote of me in it?

stuartofmt

@stuartofmt

Hmm - let me ponder the resolution side of things.

The frame-rate ought to follow the settings. I'm wondering if there is a problem with ffmpeg (would not be the first time). What version are you running ffmpeg -version will tell

I've bever seen a video jump around like that. The -camera1 web setting uses wget to retrieve the images. Afterwards ffmpeg creates the video by taking the frames in sequence. I'm wondering if there is some sort of strange timing issue?

As an experiment we can get the images using ffmpeg. This is my usual way, mainly because it exercises more of the code. What happens if you use this set of options?:
-weburl1 http://192.168.1.30/picture/2/current/ -camera1 other -camparam1="'ffmpeg ' + ffmpegquiet + ' -y -i ' +weburl+ ' -vframes 1 ' +fn+debug"

stuartofmt

@osterac said in DuetLapse3:

@stuartofmt
Did you mean to make a post with only a quote of me in it?

Yes See above