List of 3D formats and technical specs of each

This information is for both Red for future updates and for third party developers who want to support 3D pictures/videos on their Apps for RH1.
This information was extracted from the open source sView software which is an image/video viewer for Android and Windows that support multiple 3D formats and a lot of 3D visualization systems and screens.
It will be nice to support existing 3D content so 3D community could be tempted to buy a Leia device without having to throw out their existing creations and content.

Stereoscopic Formats | sView

Stereoscopic pair consist of two slightly different images of the same size captured from for left and right eyes (e.g. from two camera positions). This pair can be stored in various ways in the file:

  • Mono - no stereoscopic information, only single view is provided (wich can be joined with other 2d file with the other view)
  • Dual Stream - each view is stored in independent stream or file
  • Cross-eyed, Parallel pair - two images packed horizontally, also known as Side-by-Side
  • Over/Under - two images packed vertically, also known as Top-Bottom
  • Interlaced - row interleaved (obsolete)
  • Column interlaced (used by some 3D smartphones -when you make an screenshot you get this as is the real image that appears on the 3D screen-)
  • Anaglyph - image stored for glasses with color filters (obsolete)
  • Frame-sequential - views (frames) interleaved in time (first frame Left view, second frame Right view and so on). This is also the format used in 3D blu-rays (encoded like 60fps, so codec only stores differences between the keyframe, avoiding file size increase) and used by PlayStation 3
  • 2x720p in 1080p tiled - special layout used by some TV broadcasters in Europe

Program will be able to show image properly only when stereoscopic format has been properly selected. sView is able to determine stereoscopic format using:

  • Multiple streams ( *.mpo, *.mkv, *.wmv). Two image / video streams of the same size are automatically detected as stereoscopic pair with Left view in the first stream.

  • JPEG image containing JPS marker (VRex extension). JPS marker defines stereoscopic format.

  • PNG image containing sTER chunk (Extensions to the PNG). Only parallel pair with views order can be defined by sTER indicator.

  • WMV metadata ( *.wmv). The following metadata fields will be interpreted by sView:

  • StereoscopicLayout defining one of layouts ( SideBySideRF , SideBySideLF , OverUnderLT , OverUnderRT )

  • StereoscopicHalfHeight and StereoscopicHalfWidth defining anamorphic video

  • StereoscopicHorizontalParallax defining parallax in pixels

  • MKV metadata (*.mkv, *mkv3d). Matroska specification includes dedicated fields defining stereoscopic layout ( StereoMode ). FFmpeg library converts this data in form of stream metadata with name STEREO_MODE (with values mono , right_left , left_right , bottom_top , top_bottom , row_interleaved_rl , row_interleaved_lr , block_lr , block_rl , anaglyph_cyan_red , anaglyph_green_magenta ). Note that detection code in sView is generalized and specified metadata tags will be read from any video file (not only *.mkv).

  • h264 SEI messages (per frame side data, *.mp4, *.mkv). Some codecs stores stereoscopic identification data at every frame. This technically allows to switch from mono to stereo3d within the same stream. FFmpeg provides this information in form of AVStereo3D structure - thus sView will be able to read this information for all decoders in FFmpeg supporting this feature.

  • File extension (*.pns, *.jps). Image files with extensions *.pns (PNG file) and *.jps (JPEG file) will be interpreted as stereoscopic pair in Side-by-side format with Right view first (cross-eyed).

  • File name. sView supports the following name convention for stereoscopic format identification:

    • half-ou , -hou , -abq define anamorphic Over/Under pair*
    • half-sbs , -hsbs , -lrq , -rlq define anamorphic Side-by-side pair*
    • -ba , -ab define Over/Under pair*
    • -sbs , -lr , -rl define Side-by-side pair*

Anamorphic stereo pair with Side-by-side and Over/Under layout is a special format introduced for compatibility with build-in TV players and existing hardware players without HDMI 1.4a+ support. Video stored in this format has broken pixel proportions - it identifies itself as normal 16:9 video with 1080p HD resolution (1920x1080). Both are important - old hardware players have been unable to decode videos of greater side, and 16:9 proportions allow transferring video image through HDMI without extra scaling or cropping which should be normally applied. So in general this format has been created as a temporary hack entrenched for much longer time than expected…

Normally files should contain appropriate stereoscopic metadata to be properly displayed by players without user involvement. Unfortunately, many files still created without this information requiring manual configuration by user.

Note that most of the 3D content available everywhere -even on websites- is not encoded as 3D and is stored in an standard image/video file in Full-SBS (left eye at left). So, except for *.mpo and *.jps images, almost all video and image files available have no tag or information to recognize as 3D (but can be guessed for it’s size i.e.: being 32:9 3840x1080 instead 1920x1080, and with IA being a “double image”, an almost exact copy of same image detach exactly from center)

Time ago I gave a suggestion to enable viewing this SBS images/videos untagged as 3D on our RH1 independently from the source (App, webview of an App, browser, file stored, etc); just pressing both volume keys for 2 seconds and RH1 will put on H4V mode to watch the 3D image/video/game/etc until you touch anything, in which case screen will return to regular 2d mode. Note this is a suggestion, don’t try to press both volume keys right now


This sounds like an excellent idea, in theory.
This would be similar to how other devices operate.
(Such as the 3D. Shortcut on the Moverio.).

This would also mean that you could use applications, such as Phereo, with support for native 3D, without going through the kerfuffle of making a screenshot, renaming the file, opening in Red Player, then deleting the image.

However, if you’ve ever done that, the onset of what I like to call, “Cardboard Cutout 3D”, suggests to me, that in practice, it would be quite a lot of very complex work, to code this functionality.