1

Vision meets Robotics: The KITTI Dataset
Andreas Geiger, Philip Lenz, Christoph Stiller and Raquel Urtasun

Velodyne HDL-64E Laserscanner

Abstract—We present a novel dataset captured from a VW
station wagon for use in mobile robotics and autonomous driving
research. In total, we recorded 6 hours of traffic scenarios at
10-100 Hz using a variety of sensor modalities such as highresolution color and grayscale stereo cameras, a Velodyne 3D
laser scanner and a high-precision GPS/IMU inertial navigation
system. The scenarios are diverse, capturing real-world traffic
situations and range from freeways over rural areas to innercity scenes with many static and dynamic objects. Our data iscalibrated, synchronized and timestamped, and we provide therectified and raw image sequences. Our dataset also contains
object labels in the form of 3D tracklets and we provide online
benchmarks for stereo, optical flow, object detection and othertasks. This paper describes our recording platform, the data
format and the utilities that we provide.

Point Gray Flea 2
Video Cameras

z
x
y
x
z y

z

y
x OXTSOXTSRTRT 3003GPS
GPS / IMU

Index Terms—dataset, autonomous driving, mobile robotics,
field robotics, computer vision, cameras, laser, GPS, benchmarks,
stereo, optical flow, SLAM, object detection, tracking, KITTI

I. I NTRODUCTION
The KITTI dataset has been recorded from a moving platform (Fig. 1) while driving in and around Karlsruhe, Germany(Fig. 2). It includes camera images, laser scans, high-precision
GPS measurements and IMU accelerations from a combined
GPS/IMU system. The main purpose of this dataset is topush forward the development of computer vision and robotic
algorithms targeted to autonomous driving [1]–[7]. While ourintroductory paper [8] mainly focuses on the benchmarks,
their creation and use for evaluating state-of-the-art computer
vision methods, here we complement this information by
providing technical details on the raw data itself. We give
precise instructions on how to access the data and commenton sensor limitations and common pitfalls. The dataset canbe downloaded from http://www.cvlibs.net/datasets/kitti. Fora review on related work, we refer the reader to [8].

Fig. 1. Recording Platform. Our VW Passat station wagon is equippedwith four video cameras (two color and two grayscale cameras), a rotating
3D laser scanner and a combined GPS/IMU inertial navigation system.
•

1 × OXTS RT3003 inertial and GPS navigation system,
6 axis, 100 Hz, L1/L2 RTK, resolution: 0.02m / 0.1◦

Note that the color cameras lack in terms of resolution due
to the Bayer pattern interpolation process and are less sensitive
to light. This is the reason why we use two stereo camera
rigs, one for grayscale and one for color. The baseline ofboth stereo camera rigs is approximately 54 cm. The trunkof our vehicle houses a PC with two six-core Intel XEON
X5650 processors and a shock-absorbed RAID 5 hard disk
storage with a capacity of 4 Terabytes. Our computer runs
Ubuntu Linux (64 bit) and a real-time database [9] to store
the incoming data streams.

II. S ENSOR S ETUP
Our sensor setup is illustrated in Fig. 3:• 2 × PointGray Flea2 grayscale cameras (FL2-14S3M-C),
1.4 Megapixels, 1/2” Sony ICX267 CCD, global shutter• 2 × PointGray Flea2 color cameras (FL2-14S3C-C), 1.4
Megapixels, 1/2” Sony ICX267 CCD, global shutter◦• 4 × Edmund Optics lenses, 4mm, opening angle ∼ 90 ,vertical opening angle of region of interest (ROI) ∼ 35◦• 1 × Velodyne HDL-64E rotating 3D laser scanner, 10 Hz,
64 beams, 0.09 degree angular resolution, 2 cm distanceaccuracy, collecting ∼ 1.3 million points/second, field ofview: 360◦ horizontal, 26.8◦ vertical, range: 120 m
A. Geiger, P. Lenz and C. Stiller are with the Department of Measurement
and Control Systems, Karlsruhe Institute of Technology, Germany. Email:{geiger,lenz,stiller}@kit.edu
R. Urtasun is with the Toyota Technological Institute at Chicago, USA.
Email: rurtasun@ttic.edu

III. DATASET
The raw data described in this paper can be accessed fromhttp://www.cvlibs.net/datasets/kitti and contains ∼ 25% of ouroverall recordings. The reason for this is that primarily datawith 3D tracklet annotations has been put online, though wewill make more data available upon request. Furthermore, wehave removed all sequences which are part of our benchmark
test sets. The raw data set is divided into the categories ’Road’,’City’, ’Residential’, ’Campus’ and ’Person’. Example frames
are illustrated in Fig. 5. For each sequence, we provide the raw
data, object annotations in form of 3D bounding box tracklets
and a calibration file, as illustrated in Fig. 4. Our recordings
have taken place on the 26th, 28th, 29th, 30th of September
and on the 3rd of October 2011 during daytime. The total sizeof the provided data is 180 GB.

2

All heights wrt. road surface
All camera heights: 1.65 m
Cam 1 (gray)Cam 3 (color)

Wheel axis
(height: 0.30m)

0.54 m1.60 m0.06 mCam-to-CamRect& CamRect-to-ImageCam 0 (gray)Cam 2 (color) z

1.68 m0.80 m0.06 mVelodyne laserscanner(height: 1.73 m)

x
x
y

z
y

Velo-to-Cam

0.27 m0.05 m

IMU-to-Velo

GPS/IMU x(height: 0.93 m)

0.81 m0.32 mzy0.48 m2.71 mFig. 3. Sensor Setup. This figure illustrates the dimensions and mounting
positions of the sensors (red) with respect to the vehicle body. Heights above
ground are marked in green and measured with respect to the road surface.
Transformations between sensors are shown in blue.
date/

Fig. 2. Recording Zone. This figure shows the GPS traces of our recordingsin the metropolitan area of Karlsruhe, Germany. Colors encode the GPS signal
quality: Red tracks have been recorded with highest precision using RTK
corrections, blue denotes the absence of correction signals. The black runs
have been excluded from our data set as no GPS signal has been available.

A. Data Description
All sensor readings of a sequence are zipped into a single
file named date_drive.zip, where date and drive areplaceholders for the recording date and the sequence number.
The directory structure is shown in Fig. 4. Besides the raw
recordings (’raw data’), we also provide post-processed data(’synced data’), i.e., rectified and synchronized video streams,on the dataset website.
Timestamps are stored in timestamps.txt and perframe sensor readings are provided in the corresponding datasub-folders. Each line in timestamps.txt is composedof the date and time in hours, minutes and seconds. As the
Velodyne laser scanner has a ’rolling shutter’, three timestamp
files are provided for this sensor, one for the start position(timestamps_start.txt) of a spin, one for the end
position (timestamps_end.txt) of a spin, and one for thetime, where the laser scanner is facing forward and triggering
the cameras (timestamps.txt). The data format in which
each sensor stream is stored is as follows:a) Images: Both, color and grayscale images are storedwith loss-less compression using 8-bit PNG files. The engine
hood and the sky region have been cropped. To simplify
working with the data, we also provide rectified images. The
size of the images after rectification depends on the calibration
parameters and is ∼ 0.5 Mpx on average. The original images
before rectification are available as well.
b) OXTS (GPS/IMU): For each frame, we store 30 different GPS/IMU values in a text file: The geographic coordinates
including altitude, global orientation, velocities, accelerations,angular rates, accuracies and satellite information. Accelera-

date_drive/
date_drive.zip
image_0x/ x={0,..,3}
data/
frame_number.png
timestamps.txt
oxts/
data/
frame_number.txt
dataformat.txt
timestamps.txt
velodyne_points/
data/
frame_number.bintimestamps.txt
timestamps_start.txt
timestamps_end.txt
date_drive_tracklets.zip
tracklet_labels.xml
date_calib.zip
calib_cam_to_cam.txt
calib_imu_to_velo.txt
calib_velo_to_cam.txt

Fig. 4. Structure of the provided Zip-Files and their location within a
global file structure that stores all KITTI sequences. Here, ’date’ and ’drive’
are placeholders, and ’image 0x’ refers to the 4 video camera streams.

tions and angular rates are both specified using two coordinate
systems, one which is attached to the vehicle body (x, y, z) and
one that is mapped to the tangent plane of the earth surface
at that location (f, l, u). From time to time we encounteredshort (∼ 1 second) communication outages with the OXTS
device for which we interpolated all values linearly and set
the last 3 entries to ’-1’ to indicate the missing information.
More details are provided in dataformat.txt. Conversion
utilities are provided in the development kit.
c) Velodyne: For efficiency, the Velodyne scans are
stored as floating point binaries that are easy to parse using
the C++ or MATLAB code provided. Each point is stored withits (x, y, z) coordinate and an additional reflectance value (r).
While the number of points per scan is not constant, on averageeach file/frame has a size of ∼ 1.9 MB which corresponds
to ∼ 120, 000 3D points and reflectance values. Note that the
Velodyne laser scanner rotates continuously around its verticalaxis (counter-clockwise), which can be taken into accountusing the timestamp files.
B. Annotations
For each dynamic object within the reference camera’s fieldof view, we provide annotations in the form of 3D bounding
box tracklets, represented in Velodyne coordinates. We define
the classes ’Car’, ’Van’, ’Truck’, ’Pedestrian’, ’Person (sitting)’, ’Cyclist’, ’Tram’ and ’Misc’ (e.g., Trailers, Segways).
The tracklets are stored in date_drive_tracklets.xml.

3
ObjectCoordinates

y

rz
x

y
dt

wi

z

Velodyne
Coordinates

gt

len

w)

x

h(

z

h(

l)

Fig. 7. Object Coordinates. This figure illustrates the coordinate systemof the annotated 3D bounding boxes with respect to the coordinate system of
the 3D Velodyne laser scanner. In z-direction, the object coordinate system islocated at the bottom of the object (contact point with the supporting surface).

Fig. 6. Development kit. Working with tracklets (top), Velodyne point clouds(bottom) and their projections onto the image plane is demonstrated in the
MATLAB development kit which is available from the KITTI website.

Each object is assigned a class and its 3D size (height, width,
length). For each frame, we provide the object’s translation
and rotation in 3D, as illustrated in Fig. 7. Note that weonly provide the yaw angle, while the other two angles
are assumed to be close to zero. Furthermore, the level ofocclusion and truncation is specified. The development kit
contains C++/MATLAB code for reading and writing tracklets
using the boost::serialization1 library.
To give further insights into the properties of our dataset,
we provide statistics for all sequences that contain annotatedobjects. The total number of objects and the object orientations
for the two predominant classes ’Car’ and ’Pedestrian’ areshown in Fig. 8. For each object class, the number of object
labels per image and the length of the captured sequences isshown in Fig. 9. The egomotion of our platform recorded by
the GPS/IMU system as well as statistics about the sequencelength and the number of objects are shown in Fig. 10 for thewhole dataset and in Fig. 11 per street category.
C. Development Kit
The raw data development kit provided on the KITTI
website2 contains MATLAB demonstration code with C++
wrappers and a readme.txt file which gives further
details. Here, we will briefly discuss the most important features. Before running the scripts, the mex wrapper
readTrackletsMex.cpp for reading tracklets into MATLAB structures and cell arrays needs to be built using thescript make.m. It wraps the file tracklets.h from the1 http://www.boost.org
2 http://www.cvlibs.net/datasets/kitti/raw data.php

cpp folder which holds the tracklet object for serialization.
This file can also be directly interfaced with when working ina C++ environment.
The script run_demoTracklets.m demonstrates how
3D bounding box tracklets can be read from the XML files
and projected onto the image plane of the cameras. The
projection of 3D Velodyne point clouds into the image plane
is demonstrated in run_demoVelodyne.m. See Fig. 6 foran illustration.
The script run_demoVehiclePath.m shows how toread and display the 3D vehicle trajectory using the GPS/IMU
data. It makes use of convertOxtsToPose(), which takes
as input GPS/IMU measurements and outputs the 6D pose of
the vehicle in Euclidean space. For this conversion we makeuse of the Mercator projection [10]xy= s×r×π lon
180

= s × r × log tan(1)π(90 + lat)
360


(2)


0 ×π
with earth radius r ≈ 6378137 meters, scale s = cos lat180,
and (lat, lon) the geographic coordinates. lat0 denotes the latitude of the first frame’s coordinates and uniquely determines
the Mercator scale.
The function loadCalibrationCamToCam() can beused to read the intrinsic and extrinsic calibration parametersof the four video sensors. The other 3D rigid body transformations can be parsed with loadCalibrationRigid().
D. Benchmarks
In addition to the raw data, our KITTI website hosts
evaluation benchmarks for several computer vision and robotictasks such as stereo, optical flow, visual odometry, SLAM, 3D
object detection and 3D object tracking. For details about thebenchmarks and evaluation metrics we refer the reader to [8].
IV. S ENSOR C ALIBRATION
We took care that all sensors are carefully synchronized
and calibrated. To avoid drift over time, we calibrated thesensors every day after our recordings. Note that even though
the sensor setup hasn’t been altered in between, numericaldifferences are possible. The coordinate systems are definedas illustrated in Fig. 1 and Fig. 3, i.e.:• Camera: x = right, y = down, z = forward• Velodyne: x = forward, y = left, z = up

4

City
Fig. 5.

Residential

Road

Campus

PersonExamples from the KITTI dataset. This figure demonstrates the diversity in our dataset. The left color camera image is shown.

GPS/IMU: x = forward, y = left, z = up
Notation: In the following, we write scalars in lower-caseletters (a), vectors in bold lower-case (a) and matrices using
bold-face capitals (A). 3D rigid-body transformations whichtake points from coordinate system a to coordinate system bwill be denoted by Tba , with T for ’transformation’.
•

A. Synchronization
In order to synchronize the sensors, we use the timestampsof the Velodyne 3D laser scanner as a reference and consider
each spin as a frame. We mounted a reed contact at the bottomof the continuously rotating scanner, triggering the cameras
when facing forward. This minimizes the differences in therange and image observations caused by dynamic objects.
Unfortunately, the GPS/IMU system cannot be synchronizedthat way. Instead, as it provides updates at 100 Hz, we
collect the information with the closest timestamp to the laser
scanner timestamp for a particular frame, resulting in a worstcase time difference of 5 ms between a GPS/IMU and acamera/Velodyne data package. Note that all timestamps areprovided such that positioning information at any time can beeasily obtained via interpolation. All timestamps have beenrecorded on our host computer using the system clock.
B. Camera Calibration
For calibrating the cameras intrinsically and extrinsically,
we use the approach proposed in [11]. Note that all camera
centers are aligned, i.e., they lie on the same x/y-plane. Thisis important as it allows us to rectify all images jointly.

The calibration parameters for each day are stored inrow-major order in calib_cam_to_cam.txt using thefollowing notation:s(i) ∈ N2 . . . . . . . . . . . . original image size (1392 × 512)(i)
• K
∈ R3×3 . . . . . . . . . calibration matrices (unrectified)(i)• d∈ R5 . . . . . . . . . . distortion coefficients (unrectified)(i)• R∈ R3×3 . . . . . . rotation from camera 0 to camera i(i)• t∈ R1×3 . . . . . translation from camera 0 to camera i(i)2• srect ∈ N . . . . . . . . . . . . . . . image size after rectification(i)
3×3• Rrect ∈ R. . . . . . . . . . . . . . . rectifying rotation matrix(i)
3×4• Prect ∈ R. . . . . . projection matrix after rectification•

Here, i ∈ {0, 1, 2, 3} is the camera index, where 0 represents
the left grayscale, 1 the right grayscale, 2 the left color and3 the right color camera. Note that the variable definitions
are compliant with the OpenCV library, which we used for
warping the images. When working with the synchronized
and rectified datasets only the variables with rect-subscript are
relevant. Note that due to the pincushion distortion effect theimages have been cropped such that the size of the rectified
images is smaller than the original size of 1392 × 512 pixels.
The projection of a 3D point x = (x, y, z, 1)T in rectified(rotated) camera coordinates to a point y = (u, v, 1)T in thei’th camera image is given as(i)y = Prect x

(3)

5

100

(i) (i)−fu bx



0
0




1

(4)

(i)

the i’th projection matrix. Here, bx denotes the baseline (inmeters) with respect to reference camera 0. Note that in orderto project a 3D point x in reference camera coordinates to apoint y on the i’th image plane, the rectifying rotation matrix(0)of the reference camera Rrect must be considered as well:

150000100000

50000

0

0
r
Ca

(0)

5000

3×3
Rcam
. . . . rotation matrix: velodyne → camera
velo ∈ R
1×3
tcam
∈
R
.
.
. translation vector: velodyne → camera
velo

Using
Tcam
velo =

 cam
Rvelo
0

tcam
velo
1

(0)

y = Prect Rrect Tcam
velo x(6)(7)

For registering the IMU/GPS with respect to the Velodyne
laser scanner, we first recorded a sequence with an ’∞’-loop
and registered the (untwisted) point clouds using the Pointto-Plane ICP algorithm. Given two trajectories this problem
corresponds to the well-known hand-eye calibration problem
which can be solved using standard tools [12]. The rotationvelo
matrix Rvelo
imu and the translation vector timu are stored incalib_imu_to_velo.txt. A 3D point x in IMU/GPS
coordinates gets projected to a point y in the i’th image as
(i)

4000
3000
2000
1000

0
-1
57
.5
-1 0
12
.5
0
-6
7.
50
-2
2.
50
22
.5
0
67
.5
11 0
2.
5
15 0
7.
50

0

Orientation [deg]Orientation [deg]Fig. 8. Object Occurrence and Orientation Statistics of our Dataset.
This figure shows the different types of objects occurring in our sequences(top) and the orientation histograms (bottom) for the two most predominantcategories ’Car’ and ’Pedestrian’.

for example in difficult lighting situations such as at night, in
tunnels, or in the presence of fog or rain. Furthermore, weplan on extending our benchmark suite by novel challenges.
In particular, we will provide pixel-accurate semantic labels
for many of the sequences.



a 3D point x in Velodyne coordinates gets projected to a point
y in the i’th camera image as
(i)

10000

5000

We have registered the Velodyne laser scanner with respect
to the reference camera coordinate system (camera 0) byinitializing the rigid body transformation using [11]. Next, we
optimized an error criterion based on the Euclidean distance of
50 manually selected correspondences and a robust measure on
the disparity error with respect to the 3 top performing stereo
methods in the KITTI stereo benchmark [8]. The optimization
was carried out using Metropolis-Hastings sampling.
The rigid body transformation from Velodyne coordinates tocamera coordinates is given in calib_velo_to_cam.txt:•

Number of Cars

C. Velodyne and IMU Calibration

Number of Pedestrians

15000

(0)

•

6000

(5)

Here, Rrect has been expanded into a 4×4 matrix by append(0)ing a fourth zero-row and column, and setting Rrect (4, 4) = 1.

ian
ian
r
Ca ded Car ated destr ded destr ated
nc Pe cclu Pe runc
clu
Oc
T
Tru
O
Occlusion/Truncation Status by Class

t
)
c
n
n
k
Va Truc stria itting yclis Tram MiseCs
Ped rson (Pe
Object Class

20000

(i)

y = Prect Rrect x

50

-1
57
.5
-1 0
12
.5
0
-6
7.
50
-2
2.
50
22
.5
0
67
.5
11 0
2.
50
15
7.
50

0
(i)
fv
0

(i)
cu
(i)
cv

Number of Labels


(i)
fu

(i)
Prect =  0
0% of Object Class Members

200000

with

(0)

velo
y = Prect Rrect Tcam
velo Timu x(8)

V. S UMMARY AND F UTURE W ORK
In this paper, we have presented a calibrated, synchronized
and rectified autonomous driving dataset capturing a wide
range of interesting scenarios. We believe that this dataset
will be highly useful in many areas of robotics and computer vision. In the future we plan on expanding the set ofavailable sequences by adding additional 3D object labels for
currently unlabeled sequences and recording new sequences,

R EFERENCES[1] G. Singh and J. Kosecka, “Acquiring semantics induced topology inurban environments,” in ICRA, 2012.
[2] R. Paul and P. Newman, “FAB-MAP 3D: Topological mapping withspatial and visual appearance,” in ICRA, 2010.
[3] C. Wojek, S. Walk, S. Roth, K. Schindler, and B. Schiele, “Monocularvisual scene understanding: Understanding multi-object traffic scenes,”
PAMI, 2012.
[4] D. Pfeiffer and U. Franke, “Efficient representation of traffic scenes bymeans of dynamic stixels,” in IV, 2010.
[5] A. Geiger, M. Lauer, and R. Urtasun, “A generative model for 3d urban
scene understanding from movable platforms,” in CVPR, 2011.
[6] A. Geiger, C. Wojek, and R. Urtasun, “Joint 3d estimation of objects
and scene layout,” in NIPS, 2011.
[7] M. A. Brubaker, A. Geiger, and R. Urtasun, “Lost! leveraging the crowd
for probabilistic visual self-localization.” in CVPR, 2013.
[8] A. Geiger, P. Lenz, and R. Urtasun, “Are we ready for autonomous
driving? The KITTI vision benchmark suite,” in CVPR, 2012.
[9] M. Goebl and G. Faerber, “A real-time-capable hard- and softwarearchitecture for joint image and knowledge processing in cognitive
automobiles,” in IV, 2007.
[10] P. Osborne, “The mercator projections,” 2008. [Online]. Available:
http://mercator.myzen.co.uk/mercator.pdf[11] A. Geiger, F. Moosmann, O. Car, and B. Schuster, “A toolbox forautomatic calibration of range and camera sensors using a single shot,”in ICRA, 2012.
[12] R. Horaud and F. Dornaika, “Hand-eye calibration,” IJRR, vol. 14, no. 3,
pp. 195–210, 1995.

20

700
600
500
400
300
200
100
0
0

4000
3000
2000
1000
0

5

10
15
Car per Image

20

0

15
5
10
20
Person (sitting) per Image

5

3500
3000
2500
2000
1500
1000
500
0
0

10
15
Van per Image

15
510Cyclist per Image

12000
Number of Images

Number of Images

Number of Images

5000

Number of Images

500
450
400
350
300
250
200
150
100
50
0
0

20

1800
1600
1400
1200
1000
800
600
400
200
0
0

6000

10000
8000
6000
4000
2000
0

10
5
15
Truck per Image

20

0

20

500
450
400
350
300
250
200
150
100
50
0
0

Number of Images

9000
8000
7000
6000
5000
4000
3000
2000
1000
0
0

Number of Images

Number of Images

Number of Images

6

15
5
10
Tram per Image10515
Pedestrian per Image

20

15
5
10
Misc per Image

20

5

20
10
15
velocity [m/s]

25

×104
3

120

2
−2
0
acceleration [m/s2]

4

20
0
800
400
1200
Frames per Sequences

0

1

road

person40

21.5

residential

60

2.5
city

80

campus100

Number of Images

14000
12000
10000
8000
6000
4000
2000
0
−4

Number of Sequences

7000
6000
5000
4000
3000
2000
1000
0
0

Number of Images

Number of Images

Fig. 9. Number of Object Labels per Class and Image. This figure shows how often an object occurs in an image. Since our labeling efforts focused oncars and pedestrians, these are the most predominant classes here.

0.5
0

1600

Street Categoryr) t
Ca VaTnruckstrianttingyclisTramMiscde si C
Person (e
P
Object Class

City

200
100

500
450
400
350
300
250
200
150
100
50
0

4

Number of Images

30

0
−2
2
acceleration [m/s2]

12000

12000
10000

8000
6000
4000
2000

Residential

250
200
150
100
50
0

4
2
3
velocity [m/s]

6000
4000
2000

r
)
Ca VaTnruckstrianttingyclistTramMiscde (si C
PersoneP
Object Class

Road

100
80
60
40
20
0

5

static observer

1r)
Ca VaTnruckstrianttingyclistTramMiscde (si C
PersonPe
Object Class

120

300

) t
r
Ca VaTnruckstriainttingyclisTramMiscde s C
Person (e
P
Object Class

1

8000

0

r
)
Ca VaTnruckstrianttingyclistTramMiscde (si C
PersonPe
Object Classstatic observer

400
350
300
250
200
150
100
50
0
−2 −1.5 −1 −0.5 0 0.5
acceleration [m/s2]

10000

0

) t
r
c
Ca VaTnruckstriainttingyclisTramMisde s C
Person (Pe
Object Class

10 15 20 25
velocity [m/s]Number of Labels2−20acceleration [m/s2]

1000
900
800
700
600
500
400
300
200
100
0
−4

5

Number of Objects

18000
16000
14000
12000
10000
8000
6000
4000
2000
0

0

350
300
250
200
150
100
50
0
0

Number of Labels

300

16

Number of Images

3

5000
4500
4000
3500
3000
2500
2000
1500
1000
500
0
−4

4
8
12
velocity [m/s]Number of Labels

0

Number of Images

400

0

16

Number of Objects

×104
3.5
3
2.5
2
1.5
1
0.5
0 ar n k n ) st m c
C VaTrucstriaittingycli Tra Misde (s C
PersonPe
Object Class

500

Number of Objects

500

Number of Images

1500
1000

0
4
8
12
velocity [m/s]

1800
1600
1400
1200
1000
800
600
400
200
0
1
−3 −2 −102acceleration [m/s2]

700
600
500
400
300
200
100
0

600

2000

Number of Images

Number of Images

2500

Number of Labels

1600
1400
1200
1000
800
600
400
200
0
0

Number of Objects

Number of Objects

Number of Labels

Number of Images

Number of Images

Fig. 10. Egomotion, Sequence Count and Length. This figure show (from-left-to-right) the egomotion (velocity and acceleration) of our recording platform
for the whole dataset. Note that we excluded sequences with a purely static observer from these statistics. The length of the available sequences is shown as
a histogram counting the number of frames per sequence. The rightmost figure shows the number of frames/images per scene category.

r)
Ca VaTnruckstrianttingyclistTramMiscde (si C
PersoneP
Object Class

Campus

5000
4500
4000
3500
3000
2500
2000
1500
1000
500
0

90
80
70
60
50
40
30
20
10
0

) t
r
Ca VaTnruckstriainttingyclisTramMiscde s C
Person (Pe
Object Class) trc
Ca VaTnruckstriainttingyclisTramMisde s C
Person (Pe
Object Class

PersonFig. 11. Velocities, Accelerations and Number of Objects per Object Class. For each scene category we show the acceleration and velocity of the mobile
platform as well as the number of labels and objects per class. Note that sequences with a purely static observer have been excluded from the velocity andacceleration histograms as they don’t represent natural driving behavior. The category ’Person’ has been recorded from a static observer.