Testing takePicture Versus startCapture Times on THETA Z1

THETA API Usage
, ,
1

If you would like to install the useful command line tool for THETA API developed by Oppkey used in articles like Using BASH Scripts To Easily Test THETAs and Saving HDR _filter Setting to mySetting, please go to:

SC2 Developers - Community Docs, Code Samples and Tutorial Videos

The registration and the command line tool are free. Binaries are available for Linux, Windows, Mac and Raspberry Pi. Or you can compile the code yourself!

I tested taking a series of 7 images in a row on a THETA Z1. There are two key ways to do this, with takePicture or with startCapture. This was based off of @pixel’s questions and issues in the thread Z1 issue: Service Unavailable & Alert thread.

@pixel and @codetricity showed how sending a series of commands successfully depends on understanding if the camera is ready for the next command or not.

This test is simple and slightly different. I’m merely interested in which command, takePicture or startCapture, is faster. However, I used @pixel’s exact settings. Shutter speed has 7 different settings and changes with each image. All other settings (iso=100, aperture=2.1, and colorTemperature=2500) are the same for each of the 7 images.

takePicture means you’re running the takePicture command each time you want to take a picture.

startCapture means you set the _autoBracket option and run bracketed picture taking.

Guess what? In my tests, startCapture was significantly faster.

takePicture
Test 1: 40.25 seconds
Test 2: 39.98 seconds
Test 3: 39.86 seconds

startCapture
Test 1: 27.07 seconds
Test 2: 27.10 seconds
Test 3: 26.74 seconds

Keep in mind

  • This is informal and rough.
  • I used a hand stopwatch on an iPhone.
  • Your mileage may vary.

Here’s the BASH script file for testing takePicture.

#!/usr/bin/bash
# Built to test @pixel's timing of 7 bracketed images and how long
# it takes to complete a command before moving on to a next one
 
# set exposureProgram to 1
./theta.exe exposureProgram --value=1
 
# set ISO, Aperature and Color Temperature one time
./theta.exe setOption --name=iso --value=100
 
./theta.exe setOption --name=aperture --value=2.1
 
./theta.exe setOption --name=_colorTemperature --value=2500
 
# set shutter speed
./theta.exe setShutter --speed=0.625
 
# take a picture
./theta.exe takeAndReady
 
# set shutter speed
./theta.exe setShutter --speed=0.16666666
 
# take a picture
./theta.exe takeAndReady
 
# set shutter speed
./theta.exe setShutter --speed=0.04
 
# take a picture
./theta.exe takeAndReady
 
# set shutter speed
./theta.exe setShutter --speed=0.01
 
# take a picture
./theta.exe takeAndReady
 
# set shutter speed
./theta.exe setShutter --speed=0.0025
 
# take a picture
./theta.exe takeAndReady
 
# set shutter speed
./theta.exe setShutter --speed=0.000625
 
# take a picture
./theta.exe takeAndReady
 
# set shutter speed
./theta.exe setShutter --speed=0.00015625
 
# take a picture
./theta.exe takeAndReady

Here’s the BASH script file for startCapture.

#!/usr/bin/bash
date
./theta.exe setOption --jsonFile=options/bracket_7_config.json
./theta.exe startCapture --mode=bracket

You can see it uses a json file to set the options for each bracketed image. Here’s the json file information used with startCapture.

{
    "_autoBracket": {
      "_bracketNumber": 7,
      "_bracketParameters": [
        {
          "iso": 100,
          "aperture": 2.1,
          "shutterSpeed": 0.625,
          "_colorTemperature": 2500,
          "exposureProgram": 1,
          "whiteBalance": "auto"
        },
        {
            "iso": 100,
            "aperture": 2.1,
            "shutterSpeed": 0.16666666,
            "_colorTemperature": 2500,
            "exposureProgram": 1,
            "whiteBalance": "auto"
          },      
          {
            "iso": 100,
            "aperture": 2.1,
            "shutterSpeed": 0.04,
            "_colorTemperature": 2500,
            "exposureProgram": 1,
            "whiteBalance": "auto"
          },
          {
            "iso": 100,
            "aperture": 2.1,
            "shutterSpeed": 0.01,
            "_colorTemperature": 2500,
            "exposureProgram": 1,
            "whiteBalance": "auto"
          },
          {
            "iso": 100,
            "aperture": 2.1,
            "shutterSpeed": 0.0025,
            "_colorTemperature": 2500,
            "exposureProgram": 1,
            "whiteBalance": "auto"
          },
          {
            "iso": 100,
            "aperture": 2.1,
            "shutterSpeed": 0.000625,
            "_colorTemperature": 2500,
            "exposureProgram": 1,
            "whiteBalance": "auto"
          },
          {
            "iso": 100,
            "aperture": 2.1,
            "shutterSpeed": 0.00015625,
            "_colorTemperature": 2500,
            "exposureProgram": 1,
            "whiteBalance": "auto"
          }
      ]
    }
  }
1 Like
2

Thank you for these additional test which clearly shows that startCapture is the way to go! :wink:

3

Thanks for these tests.

Although startCapture is likely better, I wanted to point out that it’s likely possible to reduce the time taken to complete the code below.

The tester is creating a new HTTP session for each command. It would like be faster if we rewrote the library to send multiple commands through a single HTTP connection and then close the HTTP connection after all the commands were completed. I used this technique to get a hundred thumbnails at a time. Instead of opening 100 HTTP sessions, I opened one session and ran all the commands through that one session.

The second area for possible optimization is checking for status as done. The tester is only checking once per second in the takeAndReady command. If we set it to check every 200ms, it would likely cut down the delay between pictures.

I like the test you did because it shows that the camera works and that it’s programmers can likely improve their apps with different programming techniques.

At the moment, we don’t have recommendations or best practices on optimization of checking status or on when to keep the HTTP sessions open. However, I think that if we keep testing the camera with tests like you have above, we will learn and be able to document more tips for the community.

If you’re curious, the http library we’re using in the theta library is this:

It’s just a small difference of using client.post instead of http.post directly. We need to close the client at the end.

image
image1083×468 43.2 KB

2 Likes