A few steps of camera operations
1. Initialization
- Before an application can use the Camera API it is necessary to create an instance and initialize it.
However, the first action is to check that a camera exists on the device. This is done by accessing the following Camera API
TInt numCameras = CCamera::CamerasAvailable()
This is a static method that returns the number of cameras available on the device.
This extra check to find the camera is recommended to ensure that the device has a camera and that the application can continue properly.
Next, once the presence of a camera has been confirmed, an instance of the Camera API can be created with the following code:
iCamera = Ccamera::NewL( iCameraObserver, 0 );
This will initialize Camera #0 and register an object to handle the callbacks from the API.
The iCameraObserver is the instance of the object which is implementing the mixin interface MCameraObserver
Once an instance of the camera has been created, it must be reserved for use in the application by making the following function call:
iCamera->Reserve()
This must be done before issuing any commands to the camera.
The reserve method is an asynchronous call and when finished it calls the ReserveComplete() callback method.
If another application has the camera reserved, an error code will be returned to the callback.
If the reserve was successful, there is one final action to be taken before the application can start to use the camera;
the camera must be turned on by making a call to the following method:
iCamera->PowerOn()
This is another asynchronous method, and when it has finished, it calls the PowerOnComplete() callback method.
Similarly, if there was a problem turning on the power, an error code would be returned in the callback.
2. View finding
- Once the camera has been reserved and all settings have been configured, the viewfinder can be started through one the following methods:
iCamera->StartViewFinderBitmapsL( aSize );
iCamera->StartViewFinderBitmapsL( aSize, aClipRect );
The aSize parameter specifies the size of the viewfinder requested, while the second method allows the application to specify a clip rectangle which clips the viewfinder image.
For the size of the viewfinder, the Camera API will find the closest size supported by the current hardware, and use that for the viewfinder bitmaps.
The aSize parameter will be overwritten by the Camera API method and on return it will contain the actual size to be used.
On the other hand, if the user specified a clip rectangle, the viewfinder image is clipped before it is returned to the application.
The actual size of the viewfinder returned will be the intersection of the aSize and aClipRect parameters.
This does not scale the bitmap , and if required, then the application must do that.
This feature needs to be supported by the camera hardware and is specified in the bitmask field TCamerainfo.iOptionsSupported member variable.
Once the viewfinder has been started, the Camera API will continually call the ViewFinderFrameReady() callback with a bitmap.
The application is responsible for displaying the bitmap.
Also the application should draw this bitmap synchronously, since the Camera API will reuse this bitmap as soon as the callback returns.
This will continue until the application stops the viewfinder with the following method:
iCamera->StopViewFinder()
3. Image capture
- To capture a still image, the Camera API must first be prepared by specifying the format and the size.
The format used is one of the specified TFormat values (found in the ECam.h header file).
An application can check which formats are currently supported by obtaining the TCameraInfo structure and checking the bitmask field CameraInfo.iImageFormatsSupported.
Before specifying the image size, the capture sizes available need to be determined, since these will depend on the sizes supported by the camera hardware.
This is also done using the TCameraInfo.iNumImageSizesSupported field which specifies how many image capture sizes the current hardware supports.
Once the number of sizes has been retrieved, the index of the required size must be found by enumerating through all the supported capture sizes.
Once the requested index has been found, the following method must be called to finish preparing the Camera API:
iCamera->PrepareImageCaptureL( EFormatFbsBitmapColor16M, requestedIndex )
This method only needs to be called once per application, all subsequent image captures will yield results in this specified format and size.
This helps minimize the latency for each image capture.
After the Camera API has been prepared, an image can be captured by using the following method:
iCamera->CaptureImage()
This is an asynchronous method, and when the Camera API has finished capturing an image, it will call the ImageReady() callback.
This callback has three parameters: a bitmap, a raw data pointer, and an error code.
Only one of the first two parameters will contain valid data depending on which format the image was captured in.
The application then owns the memory containing the image and it is the application¡¯s responsibility to convert, save, and free the memory for this image
4. Resource release
- When an application has finished using the camera, it is important to release the resource so that other applications can use it.
This is done through the following method:
iCamera->Release()
1. Initialization
- Before an application can use the Camera API it is necessary to create an instance and initialize it.
However, the first action is to check that a camera exists on the device. This is done by accessing the following Camera API
TInt numCameras = CCamera::CamerasAvailable()
This is a static method that returns the number of cameras available on the device.
This extra check to find the camera is recommended to ensure that the device has a camera and that the application can continue properly.
Next, once the presence of a camera has been confirmed, an instance of the Camera API can be created with the following code:
iCamera = Ccamera::NewL( iCameraObserver, 0 );
This will initialize Camera #0 and register an object to handle the callbacks from the API.
The iCameraObserver is the instance of the object which is implementing the mixin interface MCameraObserver
Once an instance of the camera has been created, it must be reserved for use in the application by making the following function call:
iCamera->Reserve()
This must be done before issuing any commands to the camera.
The reserve method is an asynchronous call and when finished it calls the ReserveComplete() callback method.
If another application has the camera reserved, an error code will be returned to the callback.
If the reserve was successful, there is one final action to be taken before the application can start to use the camera;
the camera must be turned on by making a call to the following method:
iCamera->PowerOn()
This is another asynchronous method, and when it has finished, it calls the PowerOnComplete() callback method.
Similarly, if there was a problem turning on the power, an error code would be returned in the callback.
2. View finding
- Once the camera has been reserved and all settings have been configured, the viewfinder can be started through one the following methods:
iCamera->StartViewFinderBitmapsL( aSize );
iCamera->StartViewFinderBitmapsL( aSize, aClipRect );
The aSize parameter specifies the size of the viewfinder requested, while the second method allows the application to specify a clip rectangle which clips the viewfinder image.
For the size of the viewfinder, the Camera API will find the closest size supported by the current hardware, and use that for the viewfinder bitmaps.
The aSize parameter will be overwritten by the Camera API method and on return it will contain the actual size to be used.
On the other hand, if the user specified a clip rectangle, the viewfinder image is clipped before it is returned to the application.
The actual size of the viewfinder returned will be the intersection of the aSize and aClipRect parameters.
This does not scale the bitmap , and if required, then the application must do that.
This feature needs to be supported by the camera hardware and is specified in the bitmask field TCamerainfo.iOptionsSupported member variable.
Once the viewfinder has been started, the Camera API will continually call the ViewFinderFrameReady() callback with a bitmap.
The application is responsible for displaying the bitmap.
Also the application should draw this bitmap synchronously, since the Camera API will reuse this bitmap as soon as the callback returns.
This will continue until the application stops the viewfinder with the following method:
iCamera->StopViewFinder()
3. Image capture
- To capture a still image, the Camera API must first be prepared by specifying the format and the size.
The format used is one of the specified TFormat values (found in the ECam.h header file).
An application can check which formats are currently supported by obtaining the TCameraInfo structure and checking the bitmask field CameraInfo.iImageFormatsSupported.
Before specifying the image size, the capture sizes available need to be determined, since these will depend on the sizes supported by the camera hardware.
This is also done using the TCameraInfo.iNumImageSizesSupported field which specifies how many image capture sizes the current hardware supports.
Once the number of sizes has been retrieved, the index of the required size must be found by enumerating through all the supported capture sizes.
Once the requested index has been found, the following method must be called to finish preparing the Camera API:
iCamera->PrepareImageCaptureL( EFormatFbsBitmapColor16M, requestedIndex )
This method only needs to be called once per application, all subsequent image captures will yield results in this specified format and size.
This helps minimize the latency for each image capture.
After the Camera API has been prepared, an image can be captured by using the following method:
iCamera->CaptureImage()
This is an asynchronous method, and when the Camera API has finished capturing an image, it will call the ImageReady() callback.
This callback has three parameters: a bitmap, a raw data pointer, and an error code.
Only one of the first two parameters will contain valid data depending on which format the image was captured in.
The application then owns the memory containing the image and it is the application¡¯s responsibility to convert, save, and free the memory for this image
4. Resource release
- When an application has finished using the camera, it is important to release the resource so that other applications can use it.
This is done through the following method:
iCamera->Release()