Skip to content

Commit 07addbd

Browse files
authored
Update README.md
1 parent e20e9a1 commit 07addbd

File tree

1 file changed

+8
-249
lines changed

1 file changed

+8
-249
lines changed

README.md

Lines changed: 8 additions & 249 deletions
Original file line numberDiff line numberDiff line change
@@ -7,258 +7,17 @@
77

88
## Our contribution:
99

10-
- Integrated sync video
10+
- Integrated synchronized video recording
1111
- Scripts for extraction, alignment and processing of video frames [in progress]
1212

13-
# Wireless Software Synchronization of Multiple Distributed Cameras
13+
## Panoramic demo
14+
15+
- We provide scripts to **stitch 2 syncronized smatphone videos** with Hujin panorama CLI tools
16+
- Usage:
17+
- Run ```./make_demo.sh {VIDEO_LEFT} {VIDEO_RIGHT}```
18+
19+
## This work is based on "Wireless Software Synchronization of Multiple Distributed Cameras"
1420

1521
Reference code for the paper
1622
[Wireless Software Synchronization of Multiple Distributed Cameras](https://arxiv.org/abs/1812.09366).
1723
_Sameer Ansari, Neal Wadhwa, Rahul Garg, Jiawen Chen_, ICCP 2019.
18-
19-
If you use this code, please cite our paper:
20-
21-
```
22-
@article{AnsariSoftwareSyncICCP2019,
23-
author = {Ansari, Sameer and Wadhwa, Neal and Garg, Rahul and Chen, Jiawen},
24-
title = {Wireless Software Synchronization of Multiple Distributed Cameras},
25-
journal = {ICCP},
26-
year = {2019},
27-
}
28-
```
29-
30-
_This is not an officially supported Google product._
31-
32-
![Five smartphones synchronously capture a balloon filled with red water being popped.](https://i.imgur.com/rCkC5jW.gif)
33-
_Five smartphones synchronously capture a balloon filled with red water being popped to within 250 μs timing accuracy._
34-
35-
## Android App to Capture Synchronized Images
36-
37-
The app has been tested on the Google Pixel 2, 3, and 4.
38-
It may work on other Android phones with minor changes.
39-
40-
Note: On Pixel 1 devices the viewfinder frame rate drops after a couple
41-
captures, which will likely cause time synchronization to be much
42-
lower in accuracy. This may be due to thermal throttling.
43-
Disabling saving to JPEG or lowering the frame rate may help.
44-
45-
### Installation instructions:
46-
47-
1. Download [Android Studio](https://developer.android.com/studio). When you
48-
install it, make sure to also install the Android SDK API 27.
49-
2. Click "Open an existing Android Studio project". Select the "CaptureSync"
50-
directory.
51-
3. There will be a pop-up with the title "Gradle Sync" complaining about a
52-
missing file called gradle-wrapper.properties. Click ok to recreate the
53-
Gradle wrapper.
54-
4. Plug in your Pixel smartphone. You will need to enable USB debugging. See
55-
https://developer.android.com/studio/debug/dev-options for further
56-
instructions.
57-
5. Go to the "Run" menu at the top and click "Run 'app'" to compile and install
58-
the app.
59-
60-
Note: By default, the app will likely start in client mode, with no UI options.
61-
62-
#### Setting up the Leader device
63-
64-
1. On the system pulldown menu of the leader device, disable WiFi.
65-
2. [Start a hotspot](https://support.google.com/android/answer/9059108).
66-
3. After this, opening the app on the leader device should show UI options, as
67-
well as which clients are connected.
68-
69-
#### Setting up the Client(s) device
70-
71-
1. Enable WiFi and connect to the leader's hotspot.
72-
2. As client devices on the network start up, they will sync up with the
73-
leader, which will show up on both the leader and client UIs.
74-
3. (Optional) Go to wifi preferences and disable "Turn on Wi-Fi automatically"
75-
and "Connect to open networks", this will keep devices from automatically
76-
disconnecting from a hotspot without internet.
77-
78-
#### Capturing images
79-
80-
1. (Optional) Press the phase align button to have each device synchronize
81-
their phase, the phase error will show in real-time.
82-
2. (Optional) Move the exposure and sensitivity slider on the leader device to
83-
manually set 2A values.
84-
3. Press the `Capture Still` button to request a synchronized image slightly in
85-
the future on all devices.
86-
87-
This will save to internal storage, as well as show up under the Pictures
88-
directory in the photo gallery.
89-
90-
Note: Fine-tuning the phase configuration JSON parameters in the `raw` resources
91-
directory will let you trade alignment-time for phase alignment accuracy.
92-
93-
Note: AWB is used for simplicity, but could also be synchronized with devices.
94-
95-
### Information about saved data
96-
97-
Synchronized images are saved to the external files directory for this app,
98-
which is:
99-
100-
```
101-
/storage/emulated/0/Android/data/com.googleresearch.capturesync/files
102-
```
103-
104-
A JPEG version of the image will also populate in the photo gallery under the
105-
`Pictures` subdirectory under `Settings -> Device Folders`.
106-
107-
Pulling data from individual phones using:
108-
109-
```
110-
adb pull /storage/emulated/0/Android/data/com.googleresearch.capturesync/files /tmp/outputdir
111-
```
112-
113-
The images are also stored as a raw YUV file (in
114-
[packed NV21 format](https://wiki.videolan.org/YUV)) and a metadata file which
115-
can be converted to PNG or JPG using the Python script in the `scripts/`
116-
directory.
117-
118-
#### Example Workflow
119-
120-
1. User sets up all devices on the same hotspot WiFi network of leader device.
121-
2. User starts app on all devices, uses exposure sliders and presses the
122-
`Phase Align` button on the leader device.
123-
3. User presses capture button on the leader device to collect captures.
124-
4. If JPEG is enabled (default) the user can verify captures by going to the
125-
`Pictures` photo directory on their phone through Google Photos or similar.
126-
5. After a capture session, the user pulls the data from each phone to the local
127-
machine using `adb pull`.
128-
6. (Optional)The python script is used to convert the raw images using:
129-
```
130-
python3 yuv2rgb.py img_<timestamp>.nv21 nv21_metadata_<timestamp>.txt
131-
out.<png|jpg>.
132-
```
133-
134-
## How Networking and Communications work
135-
136-
Note: Algorithm specifics can be found in our paper linked at the top.
137-
138-
Leader and clients use heartbeats to connect with one another and keep track of
139-
state. Simple NTP is used for clock synchronization. That, phase alignment and
140-
2A is used to make phones capture the same type of image as the same time.
141-
Capturing is done by sending a trigger time to all devices which will
142-
independently capture at that time.
143-
144-
All of this requires communication. One component of this library is to provide
145-
a method for sending messages (RPCs) between the leader device and client
146-
devices, to allow for synchronization as well as capture triggering, AWB,
147-
state etc.
148-
149-
The network uses wifi with UDP messages for communication. The leader IP is
150-
determined automatically by client devices.
151-
152-
A message is sent as an RPC byte sequence consisting of an integer method ID
153-
(defined in
154-
[`SyncConstants.java`](app/src/main/java/com/googleresearch/capturesync/softwaresync/SyncConstants.java)
155-
and the string message payload. (defined in
156-
[`SoftwareSyncBase.java`](app/src/main/java/com/googleresearch/capturesync/softwaresync/SoftwareSyncBase.java)
157-
`sendRpc()`)
158-
159-
Note: This app has the leader set up a hotspot, through this client devices can
160-
automatically determine the leader IP address from the connection, however one
161-
could manually configure IP address with a different network configuration, such
162-
as using a router that all the phones connect to.
163-
164-
165-
### Capture
166-
167-
The leader sends a `METHOD_SET_TRIGGER_TIME` RPC (Method id located in
168-
[`SoftwareSyncController.java`](app/src/main/java/com/googleresearch/capturesync/SoftwareSyncController.java)
169-
) to all the clients containing a requested capture
170-
synchronized timestamp far enough in the future to account for potential network
171-
latency between devices. In practice network latency between devices is ~100ms
172-
or less, however the latency may be more or less depending on what devices or
173-
network configuration is used.
174-
175-
Note: In this case the future is 500ms, giving plenty of time for network
176-
latency.
177-
178-
Each client and leader receives the future timestamp and `CameraController.java`
179-
checks the timestamp of each frame as it comes in and pulls the closest frame at
180-
or past the desired timestamp and saves it to disk. One advantage of this method
181-
is that if any delays happen in capturing, the synchronized capture timestamp
182-
will show that the time offset between images without requiring looking at the
183-
images.
184-
185-
Note: Zero-shutter-lag capture is possible if each device is capable of storing
186-
frames in a ring buffer. Then when a desired current/past capture timestamp is
187-
provided each device can check in the ring buffer for the closest frame
188-
timestamp and save that one.
189-
190-
### Heartbeat
191-
192-
A leader listens for a heartbeat from any client, to determine if a client
193-
exists and whether starting the synchronization with that client is necessary.
194-
When it gets a heartbeat from a client that is not synchronized, it initiates an
195-
NTP handshake with the client to determine the clock offsets between the two
196-
devices
197-
198-
A client continuously sends out `METHOD_HEARTBEAT` RPC to the leader with it's
199-
current boolean state for if it's already synchronized with the leader.
200-
201-
A leader received `METHOD_HEARTBEAT` and responds with a `METHOD_HEARTBEAT_ACK`
202-
to the client. The leader uses this to keep track of a list of clients using the
203-
`ClientInfo` object for each client, which will also include sync information.
204-
205-
The client waits for a `METHOD_OFFSET_UPDATE` from the leader which contains the
206-
time offset needed to get to a synchronized clock domain with the leader, after
207-
which it's heartbeat messages will show that it is synced to the leader.
208-
209-
Whenever a client gets desynchronized, the heartbeats will notify the leader of
210-
it and they will re-initiate synchronization. Through this mechanism automated
211-
clock synchronization and maintenance is achieved.
212-
213-
### Simple NTP Handshake
214-
215-
The
216-
[`SimpleNetworkTimeProtocol.java`](app/src/main/java/com/googleresearch/capturesync/softwaresync/SimpleNetworkTimeProtocol.java)
217-
is used to perform an NTP handshake between the leader and client. The local
218-
time domain of the devices is used, using the
219-
[`Ticker.java`](app/src/main/java/com/googleresearch/capturesync/softwaresync/Ticker.java)
220-
method for getting local nanosecond time.
221-
222-
An NTP handshake consists of the leader sending a message containing the current
223-
leader timestamp t0. The client receives and appends it's receiving local
224-
timestamp t1, as well as the timestamp it sends a return message to the leader
225-
t2. The leader receives this at timestamp t3, and using these 4 times estimates
226-
the clock offset between the two devices, accounting for network latency.
227-
228-
This result is encapsulated in
229-
[`SntpOffsetResponse.java`](app/src/main/java/com/googleresearch/capturesync/softwaresync/SntpOffsetResponse.java)
230-
which also contains the hard upper bound timing error on the offset. In practice
231-
the timing error is an order of magnitude smaller since wifi network
232-
communication is mostly symmetric with the bias accounted for by choosing the
233-
smallest sample(s).
234-
235-
More information can be found in our paper on this topic.
236-
237-
### Phase Alignment
238-
239-
The leader sends out a `METHOD_DO_PHASE_ALIGN` RPC (Method id located in
240-
`SoftwareSyncController.java`) to all the clients whenever the Align button is
241-
pressed. Each client on receipt then starts a phase alignment process (handled
242-
by `PhaseAlignController.java`) which may take a couple frames to settle.
243-
244-
Note: The leader could instead send its current phase to all devices, and the
245-
devices could align to that, reducing the total potential error. For simplicity
246-
this app uses a hard-coded goal phase.
247-
248-
### Exposure / White Balance / Focus
249-
250-
For simplicity, this app uses manual exposure, hard-coded white balance, and
251-
auto-focus. The leader uses UI sliders to set exposure and sensitivity, which
252-
automatically sends out a `METHOD_SET_2A` RPC (Method id located in
253-
[`SoftwareSyncController.java`](app/src/main/java/com/googleresearch/capturesync/SoftwareSyncController.java)
254-
) to all the clients, which update their 2A as
255-
well. Technically 2A is a misnomer here as it is only setting exposure and
256-
sensitivity, not white balance.
257-
258-
It is possible to use auto exposure/sensitivity and white balance, and have the
259-
leader lock and send the current 2A using the same RPC mechanism to other
260-
devices which can then set theirs manually to the same.
261-
262-
Note: One could try synchronizing focus values as well, though in practice we
263-
found the values were not accurate enough to provide sharp focus across devices.
264-
Hence we keep auto-focus.

0 commit comments

Comments
 (0)