FormerLurker / Octolapse

Stabilized timelapses for Octoprint
GNU Affero General Public License v3.0
634 stars 99 forks source link

No smooth timelapse, image somehow shift sometimes #407

Closed Pierro55 closed 4 years ago

Pierro55 commented 4 years ago

If this is a feature request describe it here

FEATURE_REQUEST_DESCRIPTION_GOES_HERE

Version of Octolapse

Octolapse Version: 0.3.4

Version of OctoPrint

OctoPrint Version: 1.3.12

When you ran into the problem, did you have diagnostic logging enabled?

Diagnostic Logging was Enabled: NO

What were you doing when the problem occurred

  1. Slice STL-file in cura with the same settings as within Ocotlapse
  2. Upload to local
  3. Start print with Octolapse enabled and a Canon EOS 500D selected as snapshot camera.

What should have happened?

Octolapse should produce a smooth timelapse

What happened instead?

The produced timelapse contains somehow shifted images. It looks like the camera is out of focus but all settings are set to manual so this shouldn't be the problem. The XYZ movement is set to absolute and the extrusion movement to relativ via the start-gcode. (https://gist.github.com/Pierro55/c5daf8a74b36e9aa7ce25dbb870bba1b) I've followed the instrcutions for setting up a DSLR-camera:(https://github.com/FormerLurker/Octolapse/wiki/Configuring-an-External-Camera). I've also tried to bump up the snapshot delay up to 3000ms with no effect. These are the camera settings i use: Shutter speed: 1/60 Aperture size: F11 ISO value: 6400 Manual Focus Tamron 18-200mm lens

I've tested the same setup with a Logitech C270 webcam and got a smooth timelapse so this has to be a problem with the DSLR camera itself or the script i guess.

Other things i've tried with no effect: -Used a Anycubic I3 Mega instead of a Ender 3 -Tried Simplify 3D instead of Cura (with changed settings in Octolapse)

Operating System running OctoPrint and Octolapse

OS Name: Octopi Os Version: 0.17.0

Printer model & used firmware incl. version

Printer Model: Ender 3 Printer Firmware Version: Stock Firmware

Browser and version of browser, operating system running browser

Browser: Chrome 78.0.3904.97 Browser OS: Win 10

Link to the gcode file you were printing when the problem occurred

Link to Gcode File: GCODE_FILE_LINK_GOES_HERE

Link to settings.json

Link to settings.json with all passwords removed: https://gist.github.com/Pierro55/4710acaa4bfde9f8fac6336cb8fb6bb0

Link to plugin_octolapse.log

Link to plugin_octolapse.log: LINK_GOES_HERE

Link to octoprint.log

Link to octoprint.log: LINK_GOES_HERE

Link to contents of Javascript console in the browser

Link to javascript console output: LINK_GOES_HERE

Screenshots and/or videos of the problem:

Screenshot/Video Links: calicat_20191116213812

Please consider becoming a patron

If you like this project, please support my work by becoming a patron, and consider adding a 'star' to the repository. It takes a lot of time and effort to maintain the project and respond to issues. The cost of test prints, software, cameras, printer parts, etc. can quickly add up, so every bit helps.

You can find various videos and tutorials by subscribing to my Youtube channel. You can also follow me on Twitter.

FormerLurker commented 4 years ago

Looks like your camera mount is shaking, or the table upon which where your printer is sitting is shaking. This is not easy to fix, because i imagine you are using a tripod on the floor. Your best bet would be to create a small mount attached to your printer frame, or to reduce shaking by putting your printer on something heavy, like a granite slab. Let me know if i am misunderstanding the situation, and good luck!

FormerLurker commented 4 years ago

Hey, I just had a thought. Check your camera and make sure image stabilization is disabled. That can cause issues similar to what you are showing in your video for timelapses. Let me know if any of my suggestions help at all!

Pierro55 commented 4 years ago

I've tried to stabilize the tripod by lowering the camera mounting point a lot and by spreading the pods under a greater angle . Photo 17-11-2019, 21 03 40 Then i did a quick test and it was getting worse: Test Next i mounted the webcam onto the setup from the picture above and got no shaking at all: Webcam

The weight of the webcam is much less compared to the camera but if the tripod would be influenced by shaking, the webcam would also be influenced.

I just read your new comment and will check that too!

Pierro55 commented 4 years ago

I've turned off the image stabilization but sadly with no effect :/ FAILED_Octo_tower_101050_2019111

Btw, i am using a raspberry pi 4.

FormerLurker commented 4 years ago

It really looks like the printer is properly stabilized, but that the camera images are not. Does your lens maybe have some enabled features that could be disabled? What happens if you create a manual timelapse with your camera (no octolapse)? If you try this and still see some chop like in your videos, this would suggest it has something to do with your camera settings or lens. Im not sure how octolapse or avconc (ffmpeg) could produce what im seeing in your video, but I could always be wrong :)

Pierro55 commented 4 years ago

Good idea! I've tried that and the timelapse from the camera itself looks just fine. ezgif com-optimize

One thing is that while taking a timelapse I have to set the camera to video mode in which the shutter is open all the time. This is not the case while taking a timelapse with Ocotlopase where the shutter is released on every image. Maybe the shutter itself induces the camera shaking? The camera has the option 'mirror lockup' where the mirror moves up before exposure so that the vibration from the 'mirror slap' dies away before taking the picture. The problem with this setting is that the shutter has to be triggert two times which does not work with the script in Octolapse. Is there maybe a work around to trigger the shutter two times with a bit delay in between or to use the timelapse method the camera uses with the shutter open all the time?

The lens I am using only has image stabilization and auto focus which I disabled.

FormerLurker commented 4 years ago

I don't think the mirror could cause the massive and irregular jumps you are seeing in your videos. At most I would expect it to be a bit blurry in some/most frames.

The thing that sticks out to me in your videos is that the 'shaky' frames appear to all be offset by the same amount. That is really odd, and I don't think vibration would cause that.

Can you try making a manual timelapse again, but this time don't use 'video' mode? I'd like to see a video with the same settings as you are using with gphoto2.

Also, you could try the '--capture-image' or '--trigger-capture' parameter instead of '--capture-image-and-download'. See 'this guide' on using deferred image download, which will first take photos and save them to the camera's SD card, then will download all of the images before rendering the timelapse. Not sure if that will help, but it's something you could try and will reduce the capture time.

Also, if you use the deferred download script, the images will all still be on your camera after the print completes. You could manually render a timelapse from those images and compare the result with the rendering from Octolapse. That would be a good test of ffmpeg to see if it's somehow involved.

Pierro55 commented 4 years ago

Thanks for the information!

I kinda solved this problem today in a different way. I tried a mirrorless camera (Canon EOS M3) with the same settings and it finally worked! ezgif com-video-to-gif

Maybe it was the slapping mirror or something else with the camera itself.

Now i am tinkering to get less stringing. For this i followed this thread (https://community.octoprint.org/t/octolapse-how-to-turn-off-saving-and-rendering-to-the-pi/4341/5) and i was sort of able to reduce the time to take a snapshot by half. However, now the camera only takes a snapshot ever second layer because it is getting stuck saying ''Use target device'' after acquiring the first snapshot. Photo 30-11-2019, 18 06 43

At the next snapshot i always get the following error: snapshot_script_error: The snapshot script failed with the following error message: Error Canon EOS M Full-Press failed (0x2019: PTP Device Busy) ERROR: Could not trigger capture. Error (-110: 'I/O in progress')

The snapshot acquiring after this error works just fine and then it loops the problem described above. Also, before a successful snapshot is taken, the camera shows beforehand a preview of the tsnapshot taken beforehand. Photo 30-11-2019, 18 07 02 So after the unsuccessful snapshot the screen of the camera switches to the preview shown above and the next snapshot gives no problem. After that it goes back to the ''Use target device'' and i get the error mentioned above.

If I copy the snapshot acquiring script to ''After Snapshot Script'' in the Octolapse settings it works fine but also giving the same error and taking twice as much time. Is this a problem with the camera itself and gphoto2 or can this be fixed with a different script?

FormerLurker commented 4 years ago

So, there could be two issues causing your problem:

  1. There is not enough time between snapshots, and your camera is still writing the previous image
  2. Something odd is going on with that preview. I wonder if this is an option you can turn off somehow via gphoto 2, or via the camera settings.

If the issue is labeled 1 above, the following may help:

The camera might be busy if the interval between snapshots is too low. You might want to take a look at this guide (which I neglected to paste in the previous comment, sorry) which is an updated version of the instructions at the thread you posted.

Replace --trigger-capture with --capture-image in the snapshot acquisition script to force the camera to wait until the image has been saved. This will take longer to acquire an image than --trigger-capture, but it should prevent the device is busy error when the interval between snapshots is shorter than the image saving time.

If the problem is labeled 2 above, you can query the capabilities of your camera from GPhoto2, and maybe the preview can be disabled. I would look this up but the gphoto2 website is not coming up for me. You might be able to disable this via the camera's menu.

If all else fails, check your gphoto2 version and update to 2.5.23, or to the latest development release. It could be that this problem was fixed in a future version.

Pierro55 commented 4 years ago

I've read through your guide and the only difference was that gphoto2 --set-config capturetarget=1 was set to 2 in my script. I've changed that after testing the capabilities of my camera but that made no difference.

Turning of the image preview in the camera settings doesn't effect this either.

Replacing --trigger-capture with --capture-image in the snapshot acquisition script adds one or two seconds extra and the error shows up either way.

Updating gphoto to version 2.5.23 or the latest development release also doesn't change anything :/ I also controlled if the firmware of te camera was an old version but that was not the case.

I searched for a problem with the camera itself related to gphoto2 and found the following code which releases the half pressed status of the camera: gpohot2 --set-config eosremoterelease=3

see --> https://sourceforge.net/p/gphoto/support-requests/122/

When i paste this into the snapshot script right under the trigger-capture event it works without spiting out an error but it is not that fast in comparison using only the trigger-capture command. I guess that's just a property of this camera so I only can tweak the slicer settings to get less stringing.

Thanks for al of your help, i really appreciate it. Also big thanks for developing this awesome tool!!

FormerLurker commented 4 years ago

Try adding

gpohot2 --set-config eosremoterelease=3

To the initialization script. You shouldn't have to run that before each snapshot, and it will take extra time to run after each snapshot. Let me know of that helps!

Pierro55 commented 4 years ago

It doesn't make a different sadly :/ If I don't run the release code in the snapshot script i always get the error mentioned above and the camera does not take a picture every second layer.

However if i put the release code in the snapshot script before the --trigger-capture code, the process is around 0.5sec faster, so that's a small improvement.

Klammerson commented 4 years ago

If it is ok I would join in right here.

I've read the hole thread and wanted to let you know that I have similar issues with my Canon EOS 70D mounted on a tripod far away enough from the printer to be affected by any vibrations coming from it.

My time lapses with my C270 are turning out great.

I've configured my DSLR to only save the pictures on the SD card since I am using a seperate software for post processing. Nevertheless when stitching the images together the video shakes a lot. I get rid of this using the image stabilization feature of iMovie but still can#t figure out how to get rid of these shakes in the first place.

Your suggestion with the mirror made me think but still doesn't seem to be right.

I'd be happy to hear about any other ideas for solving this "issue"

FormerLurker commented 4 years ago

On my DSLR I have to turn off image stabilization completely, else it shakes. Stabilization works only for single images, but causes a series of images to be offset slightly.

Also, have you tried the regular DSLR script with download? Does that work properly? If so, it could be that gphoto2 is exiting before your snapshot is complete. Not all cameras work the same, and if you look at the most recent deferred and no download guides there is a section in there that explains this. It also suggests how to fix it by adding a pause to the snapshot script.

Regarding vibrations, could it be possible that your printer is shaking? Even if the camera is stable, if your printer or stand is vibrating that will affect the stabilization. This is less likely than the snapshot script issue I mentioned above.

Klammerson commented 4 years ago

thx for the fast reply. I'll try and verify if image stabilization will fix the issue. I have used the regular DSLR script before and it produced the same issues in octoprint.

my printer is very unlikely to shake since it is placed on my massive workbench. nor will it interfere with my cam since i placed the tripod away from the printer and the workbench.

i'll let you know if image stabilization helped or not.

thanks for your awesome work and effort you put into this. you are doing an awesome job.

Klammerson commented 4 years ago

so image stabilization was the issue and now everything works like a charm. thanks for your support!

FormerLurker commented 4 years ago

Awesome! Have fun!