Generate depth tables with camera parameters

[xlz]

The xtable, ztable, and 11to16 LUT can now be generated with camera parameters at runtime according to analysis in #144. The tables are generated during Freenect2Device::start(), and passed to depth processors.

Users can provide custom camera parameters at runtime with new API: setIrCameraParams(), and setColorCameraParams(), and depth processors will use those instead of USB queried parameters.

File loading functions in depth processors are removed.

Hardcoded table binary files are removed.

[floe]

Excellent work, could you perhaps add a short comment explaining the functionality of xtable/ztable itself (since you've reverse-engineered it now fully)?

[xlz]

v2:

• Added comments about 8192 and 6250.0/3 magic numbers
• Added comments about the nature of x/ztable
• Consolidated X/Z/LUTables generation functions into struct IrCameraTables.

Old comments can be found here: https://github.com/xlz/libfreenect2/commit/866fdb2dbab42cd7727db3dd52a8260cd964be21

[xlz]

Rebased to master.

[xlz]

Rebased to master.

[floe]

Just tested this, works as expected. Purely from visual inspection, I can't tell any difference between the two versions; I think @wiedemeyer had done some measurements?

[xlz]

To tell a difference, extract two frames from before and after, imagesc(abs(before-after)) will visualize the difference.

To absolutely prove the correctness, another set of x/z/lut tables have to be extracted and compared with tables computed here. Or another round of calibration set with setIrCameraParams() with external intrinsic parameters.

[xlz]

You might see some patterns obtained in http://designfankhauser.ch/files/fankhauser_2014_kinect_v2.pdf fig 5.

This paper uses an older version of libfreenect2. It is possible some of the errors analyzed in the paper come from the discrepancy of the intrinsic parameters used for image warping (external) and depth decoding (hardcoded).

[xlz]

This is the absolute error between before and after this patch (pixel values are the average of 100s images, only showing pixels with standard deviation less than 4). The units of pixel values are millimeter.

Histogram of the error between before and after.

[floe]

Ah, this is very interesting - AFAICT, the error distribution means that there wasn't a systematic error before, just a different error distribution?

[xlz]

The above plots might not be meaningful. Probably most of it is just noise and not showing the bias. I didn't have the best calibration target to test with.

Here are another two plots showing the theoretical errors in the final depth values between using the hardcoded parameters, and (1) the embedded intrinsic parameters of my Kinect; (2) iai_kinect2's sample intrinsic parameters:

I guess this really depends on the particular calibration parameters. At the edge the error is as much as a few millimeters, but another problem is data at the edge has poor reflection and poor reliability so is probably discarded for reliable computation. In the middle the error should be tiny.

[floe]

We should get this tested a little more widely, so I'm merging it now.