Full SBS: when the extra width earns its keep
Full side-by-side stores each eye at the source resolution — 1920×1080 each in a 3840×1080 frame. It sounds strictly better than half SBS. In practice it is a niche format, and here is when it is worth the trouble.
What changes
| Half SBS | Full SBS | |
|---|---|---|
| Frame | 1920×1080 | 3840×1080 |
| Per eye | 960×1080 | 1920×1080 |
| File size at the same quality | baseline | ≈ 3-4× larger |
| Decoder load on a headset | light | heavy; some players drop frames |
| Player support | default everywhere | manual selection, sometimes a custom resolution |
When full SBS is the right call
- You are archiving, and you want one file that survives a future re-encode.
- You project onto a large screen from a PC with a wired connection, where the decoder is not the bottleneck.
- You are comparing a depth estimate against ground truth at full resolution, i.e. doing technical work rather than watching something.
When it is not
Watching on a Quest, Pico, Vision Pro or XREAL glasses. Those panels resolve far less than 1920 per eye in motion with a real lens in front of them, and the extra width mostly buys you a bigger file and a player that stutters. Half SBS is the format those devices were built around.
What DepthSnap produces
Half SBS, with each eye capped at 960 px wide, tagged as side-by-side so the player switches automatically. The depth estimate itself is computed at 392-518 px per pass, so a 1920-per-eye output would be interpolation dressed up as detail — we would rather not.
If you still need full SBS, convert here and upscale 2× horizontally afterwards; the eyes are already separated, so nothing drifts.