FormerLurker / Octolapse

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

DSLR: snapshot delay is in milliseconds during cofiguration #898

Open francofusco opened 1 year ago

francofusco commented 1 year ago

If this is a feature request describe it here

_REPLACE_THISFEATURE_REQUEST_DESCRIPTION_GOES_HERE

Version of Octolapse

Octolapse Version: 0.4.2

Version of OctoPrint

OctoPrint Version: 1.8.7

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

Diagnostic Logging was Enabled: YES

What were you doing when the problem occurred

I wanted to capture images with 2" exposure using an old camera that cannot be triggered from software. I was creating a script that (using some relays) activates the camera and then need to wait a bit, since the camera is doing long exposure. I want the wait time to be set using the "Snapshot Delay" value (which serves exactly this purpose, to my understanding). While doing so, I think I found an issue that can be replicated easily with the following steps - no actual camera needed:

  1. SSH into the Raspberry Pi, create a new script named debug.sh and make it executable.
  2. Paste the following:
    #!/bin/sh
    # This script simply prints on STDERR the delay passed by Octolapse to the script
    >&2 echo "DELAY: $2"
  3. Create a new camera profile, select "External Camera - Script" as type.
  4. Set /home/pi/debug.sh as script
  5. Set "Snapshot Delay" to 2000 ms
  6. Press "Test script" - an error should appear.
  7. Perform a test print and wait for a snapshot. As soon as the snapshot is taken, an error should appear. The print can be cancelled.
  8. cat ~/.octoprint/logs/plugin_octolapse.log should show the following at the end:
    2023-04-20 13:35:59,532 - octolapse.script - ERROR - Error output (stderr) for 'Sony α350 - Snapshot Camera Script':
        DELAY: 2000
    2023-04-20 13:43:00,528 - octolapse.script - ERROR - Error output (stderr) for 'Sony α350 - Snapshot Camera Script':
        DELAY: 2.0

What should have happened?

In the log, the echo to STDERR should show the same output.

What happened instead?

Operating System running OctoPrint and Octolapse

OS Name: OctoPi Os Version: 1.0.0

Link to plugin_octolapse.log

Link to plugin_octolapse.log: https://pastebin.com/rrwK212V

Link to octoprint.log

Link to octoprint.log: _REPLACE_THISLINK_GOES_HERE

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.

francofusco commented 1 year ago

TL;DR of the issue:

FormerLurker commented 1 year ago

So, the snapshot delay from the profile is not being used when clicking the test button, but rather a default delay of 2 seconds is used. I'm not sure why I did it that way exactly (the snapshot delay isn't sent at all), but probably just to fill in the parameters for the script.

As for the parameters sent to the actual call, the real delay in seconds is used. This was done intentionally since the sleep (both windows and linux prompt) takes seconds, and is documented in the description of the parameters:

SNAPSHOT_NUMBER=$1 DELAY_SECONDS=$2 DATA_DIRECTORY=$3 SNAPSHOT_DIRECTORY=$4 SNAPSHOT_FILENAME=$5 SNAPSHOT_FULL_PATH=$6

You could pretty easily multiply by 1000 to get seconds pretty easily.

I'll look into passing the snapshot delay, but I don't want a situation where someone enters a really large value for the delay and thinks their webcam isn't working. Thoughts?

francofusco commented 1 year ago

the snapshot delay from the profile is not being used when clicking the test button, but rather a default delay of 2 seconds is used

Ok, I did not figure this out due to an unfortunate coincidence: I was using a 2s delay and therefore I thought it was the same value given by the user. I think it is reasonable to use a set value in testing, especially if it would require several changes to pass the user-supplied value.

You could pretty easily multiply by 1000 to get seconds pretty easily

Indeed. What I did was to check if the delay was less than 60: if this was the case, then I would assume the delay was in seconds and multiply it by 1000. However, in my opinion it would be better to have a consistent unit everywhere. Taking into account what was said before, I think a good solution would be to change the default value sent during the execution of the test script to 2.0: still a set value, but in seconds. Also, I think it would be worth mentioning somewhere that a default value will be used during testing, and that the unit will always be seconds.

Finally, I think that my understanding of the parameter itself was wrong: I thought that the delay was to be used by the script, while after testing a bit more I believe that the delay refers to an additional sleep time that will be added after the script returns. If this is the case, maybe it would be better to just add a new parameter named, e.g., SNAPSHOT_EXPOSURE_SECONDS. Scripts could use this parameter to make sure that a DSLR exposes for the correct amount of time - if this feature is available on the camera and/or program used to capture the image.