This functionality exists in k4ainternal/common.h now, maybe we can just make those functions public?

See comments in #145. For modes in particular, these values may be hardware specific. If we add an API for getting width/height values, we may want to make it dependent on a device_t object, and possibly query the values from future hardware. This adds some complication when dealing with recordings, since the playback API would presumably need to duplicate this functionality, store the mappings in the recording, or inver them from the recorded data.

@cdedmonds it turns out we already have an API for this, although its a bit convoluted:

Call k4a_device_get_calibration or k4a_playback_get_calibration with the depth mode and color resolution of your choosing, then in the resultant k4a_calibration_t access cal.depth_camera_calibration.resolution_width

It might be cleanest to provide a helper function like:

k4a_result_t k4a_device_get_resolution(k4a_device_t, k4a_color_resolution_t, int* width, int* height);

which just calls k4a_device_get_calibration and returns the resolution data.

@Brent-A I hadn't thought abot that. Makes sense to expose an API then. Do we want one for color and depth or just color?

How about a separate k4a_device_get_color_resolution and k4a_device_get_depth_resolution?

Think this issue can be closed because k4a_calibration_t provides the resolution width and height for both depth and color now.

Nice! I would rather have a dedicated function to do this and one for FPS. It would be a bit more general purpose then the calibration API.