-
Notifications
You must be signed in to change notification settings - Fork 420
MVE File Format
Wiki Home ▸ MVE File Format
This page describes the MVE scene format; a set of directories and files that describe the cameras, per-camera data, as well as 3D features their relation to images.
MVE associates scenes with directories in the file system. The name of the directory is treated as the name of the scene. Every view is stored inside a directory (usually with a .mve extension) in a sub-directory views/ in the scene directory. Scene structure, e.g. Structure from Motion points, is read from a file which is historically called synth_0.out in the scene directory. The user is free to create further files and directories inside the scene directory.
scene-name/scene-name/synth_0.outscene-name/views/scene-name/views/view_0000.mve/scene-name/views/view_0001.mve/- and so on.
The format of these files and directories is now described in more detail.
Every view is represented in a directory, e.g., view_0000.mve, a sub-directory in the views/ directory. Every view contains a meta.ini file with arbitrary key/value pairs. This file also contains the camera parameters. All other files are considered images or BLOBS (arbitrary binary data). Example view directory:
view_0000.mve/view_0000.mve/meta.iniview_0000.mve/original.jpgview_0000.mve/undistorted.pngview_0000.mve/depth-L2.mveiview_0000.mve/exif.blob
Allowed image formats inside a view are JPEG (for 1 or 3 channel 8-bit images), PNG (for 1, 2, 3 and 4 channel 8-bit images) and MVEI (arbitrary number of channels or type). Note that MVE never writes JPEG files except if they can be copied (e.g. when importing images) without loss of quality. JPEG images that are changed and saved will be converted to a lossless format.
The meta.ini file contains arbitrary key/value pairs which can be used to store textual information. It is a simple line-based INI file format. In particular, the view name, ID and camera parameters are recognized by the view implementation. An example meta.ini file looks like this:
[view]
id = 0
name = DSC10041
[camera]
focal_length = 0.821
pixel_aspect = 1
principal_point = 0.5 0.5
rotation = 1 0 0 0 1 0 0 0 1
translation = 0 0 0
These fields should be fairly self-explanatory. focal_length is normalized and independent of image size (i.e., the focal length in pixels divided by the larger side). The pixel_aspect is the pixel width divided by the pixel height. The principal_point is also normalized and independent of the image size.
The MVE image file format starts with the signature 89 4D 56 45 5F 49 4D 41 47 45 0A (hex).
-
89: Has the high bit set to discriminate from text files. -
4D 56 45 5F 49 4D 41 47 45: The ASCII lettersMVE_IMAGE. -
0A: A Unix newline character.
What follows is binary signed 32-bit integers for width, height and channels, and the type. The type corresponds to the mve::ImageType enum. Then the binary image data follows.
The BLOB file format starts with the signature 89 4D 56 45 5F 42 4C 4F 42 0A (hex).
-
89: Has the high bit set to discriminate from text files. -
4D 56 45 5F 42 4C 4F 42: The ASCII lettersMVE_BLOB. -
0A: A Unix newline character.
What follows is the size of the blob as a binary 64-bit unsigned integer, followed by the binary BLOB data.
The SfM format is ASCII. It contains the file signature drews 1.0 followed by a newline, followed by the number of cameras and features points. Then five lines make up a single camera. After all cameras, three lines for every point follows.
drews 1.0
<num_cameras> <num_features>
<cam 1 line 1> // Focal length, Radial distortion: f rd1 rd2
<cam 1 line 2> // Rotation matrix row 1: r11 r12 r13
<cam 1 line 3> // Rotation matrix row 2: r21 r22 r23
<cam 1 line 4> // Rotation matrix row 3: r31 r32 r33
<cam 1 line 5> // Translation vector: t1 t2 t3
...
<point 1 position> // x y z (floats)
<point 1 color> // r g b (uchars)
<point 1 visibility> // <list length (uint)> ( <img id (uint)> <sift id (uint)> <reproj. quality (float)> ) ...
...