= API review =

Proposer: '''Blaise Gassend'''

Present at review:
 *List reviewers

== Proposal ==

I would like to add a standard service call for setting the CameraInfo stored in a camera. This service would be advertized in the same namespace as the camera's output. Having this service would allow a calibration node to compute the CameraInfo, and directly submit it to any conforming camera.

I propose to add a SetCameraInfo service to the sensor_msgs package. The proposed .srv is:
{{{
# This service requests that a camera stores the given CameraInfo 
# as that camera's calibration information.
sensor_msgs/CameraInfo camera_info # The camera_info to store
---
bool success          # True if the call succeeded
string status_message # Used to give details about success
}}}

== Question / concerns / comments ==
Enter your thoughts on the API and any questions / concerns you have here.  Please sign your name.  Anything you want to address in the API review should be marked down here before the start of the meeting.

=== Blaise ===
 * How to deal with cameras that support multiple resolutions/orientations/binnings?

=== Vijay ===
 * Is the thought for this service to change the actual eeprom of the camera, or will the settings be lost when the camera node is restarted?
  * Blaise: This would change the EEPROM.

== Meeting agenda ==
To be filled out by proposer based on comments gathered during API review period

== Conclusion ==
 * This service call looks good as it is.
 * Things we may want to add to CameraInfo at some point:
   * Binning in ROI
   * Mode string to identify what geometric mode the camera is in.
   * Mode string for exposure, brightness, etc...
   * Not flipping because it would cause too much confusion.
 * Cameras might want to support flipping and binning internally.
 * The width and height in the camera info have to match the width and height in the camera_info topic, and the camera will assume that the same width by height pixels are being referred to in both cases.

## PackageReviewCategory