RU2352977C2 - System for control of chamber resource in portable device - Google Patents

Abstract

FIELD: physics, control.

SUBSTANCE: system is suggested for control of chamber resource in resource-limited portable device. Method is suggested for actuation of chamber system to provide the possibility of the fact that application controls chamber resource in portable device. Method consists in the fact that chamber system is activated, at that chamber system is able to work so that it controls chamber resource, application program interface (API) is provided to receive commands from application, command from application is received via program interface of application (API), at that command identifies function of chamber to be performed, and chamber function identified by means of command is identified.

EFFECT: system simplification and expansion of functional resources.

20 cl, 5 dwg

Description

Priority for this application is claimed by provisional application for US patent No. 60 / 465,533, filed April 25, 2003, and patent application US No. 10 / 453,091, filed June 2, 2003. The contents of these documents are incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates generally to image acquisition and processing in portable devices, and more particularly, to a system for managing a camera resource in a portable device having an integrated controller.

State of the art

Advances in technology have led to smaller and more powerful personal computing devices. For example, there are currently a variety of portable cordless phones, PDAs, and paging devices that are small, lightweight, and can be easily carried by users. Typically, these devices include an embedded controller with limited storage resources. For example, the amount of storage available and processing capabilities may be limited by the small size of this device.

There is an increasing need for personal computing devices in order to work with large volumes of data and execute programs that are more complex. For example, users request applications that provide comprehensive image processing. In this area, users would like to have portable devices that include camera resources that can be controlled to capture still images and video clips for processing and / or transmission.

In order to capture images on portable devices, it is necessary to manage the camera resources of these devices. For example, one type of portable device may include a low-resolution camera resource, which is a design for producing still images, and another type of portable device may include a larger, higher resolution camera resource with zoom capabilities, Designed for movie capture. Thus, each type of portable device can have a different camera resource from which to capture the content of images. Therefore, application developers must overcome compatibility issues when developing applications for use on a wide variety of portable devices that can have different camera configurations and resources.

One technology used to overcome compatibility issues requires that the application be specifically designed to run on a portable device that has a specific camera resource. For example, if an application developer is developing an application that runs on a portable device to receive video images, developers must tailor the application so that it is exactly compatible with the camera resource available on that particular device.

Unfortunately, it is quite expensive and inefficient to create applications for use on a wide variety of portable devices that adapt to the specific camera resources found on this device. For example, an application developer would need to modify the application for use on various portable devices based on the available camera resource, thereby requiring the development of multiple versions of the same application. Also, the application developer would have to constantly update their applications as new camera resources become available.

Another technology proposed for managing camera resources on portable devices involves the use of multimedia platforms, mainly available for use on desktop computers, servers, or other relatively large computing devices. However, these types of platforms would be extremely ineffective if used in a portable device that has limited resources, because these systems basically require a large number of software interfaces that must be created between the application and the software modules loaded on this device. Thus, in addition to being very complex, these systems require intensive storage devices and processing facilities, which is not compatible with the limited processing performance available on typical portable devices.

Therefore, what is required is a system that allows applications to efficiently and easily access and manage camera resources on a variety of portable devices to capture, encode, manipulate and display still images and video images.

The system must be compact and designed to work using the limited resources available on a typical portable device. For example, a system should not require extensive software interfaces between software modules that are large, inefficient, and not practical for use on a small device with a limited resource. The system should work to ensure that all types of camera resources are manageable, and provide a scalable architecture that manages new camera resources as they become available.

Disclosure of invention

In one or more embodiments, a camera system including methods and devices is provided for managing camera resources on portable devices. For example, one portable device may be a cordless telephone with an integrated controller and limited storage resources, which includes a camera device. In one or more embodiments, the camera system comprises a small and efficient program that runs on a portable device to enable applications running on this device to control the camera resource using a simple interface. Thus, the camera system is particularly well suited for use in portable devices having integrated controllers with limited storage resources.

In one embodiment, the camera system provides a simple, efficient, and effective way to access and manage camera resources on a portable device, and allows static and dynamic applications to: (1) capture a frame or video image, (2) set camera settings and configuration parameters , (3) process a fixed image and video frames, (4) add additional information, such as location information, for the image and video frame, (5) encode fixed images video frames, (6) display fixed images and video frames, and (7) receive camera events asynchronously.

In one or more embodiments, the camera system comprises a small software module, which is illustrated by examples through an executing application. This application then uses the simple application programming interface (API) provided by the software module to perform all camera operations. Events from the camera are routed to the application through a registered callback function. The software module consumes minimal memory and provides efficient implementation through direct access to the software driver at the device level to perform all camera operations.

In one embodiment, a method is provided for controlling a camera system to enable an application to manage camera resources in a portable device. This method consists in activating the camera system, while the camera system can operate in such a way as to control the camera resource, ensure that the application program interface (API) receives commands from the application, and the command is received from the application via the application program interface (API ), the command identifies the camera function to be performed, and the camera function identified by the command is performed.

In another embodiment, an apparatus for controlling a camera system is provided to enable an application to manage camera resources in a portable device. The device comprises means for activating the camera system, in which the camera system can operate so as to control the camera resource. The device also comprises means for ensuring that the application programming interface (API) receives commands from the application. The device also comprises means for receiving a command from the application via the application program interface (API), the command identifying a camera function to be performed. The device also comprises means for performing a camera function identified by a command.

In another embodiment, a computer-readable medium is provided that comprises instructions that, when executed by a processor in a portable device, operate to provide a camera system that allows an application to control the camera resource on the portable device. The computer-readable medium contains commands for activating the camera system, while the camera system can operate to control its resource, commands to ensure that the application program interface (API) accepts application program interface (API) commands from the application, commands for receiving commands of the application program interface (API) from the application through the application program interface (API), wherein the application program interface (API) command identifies the camera function to be executed , commands for performing a camera function identified by an application program interface (API) command.

In another embodiment, an apparatus for operating a camera system is provided to enable an application to manage a camera resource in a portable device. The device comprises a logic circuit for activating the camera system, wherein the camera system can operate to control the camera resource, and further comprises a logic circuit to ensure that the application program interface (API) receives commands from the application. The device also contains a logic circuit for receiving a command from an application through the application programming interface, the command identifying a camera function to be performed, and further comprises a logic circuit for performing a camera function identified by a command.

Other aspects, advantages and features of the present invention will become apparent after a review of the following brief description of the drawings, a detailed description of the invention and the claims.

Brief Description of the Drawings

The aforementioned aspects and corresponding advantages of the embodiments described herein will be more readily understood by reference to the following detailed description in conjunction with the accompanying drawings, in which:

Figure 1 represents a data network that includes a portable wireless device with an integrated controller suitable for executing one embodiment of a camera system;

FIG. 2 is a block diagram illustrating one embodiment of the portable device shown in FIG. 1, which includes one embodiment of an ICamera system that is operable to allow an application to manage a camera resource on a device;

Figure 3 is a detailed block diagram of one embodiment of the ICamera system shown in Figure 2;

FIG. 4 represents one embodiment of a state machine provided by one embodiment of an ICamera system to enable an application to manage a camera resource on a portable device; and

5 represents one embodiment of a method for operating an ICamera system to enable an application to manage a camera resource in a portable device.

The implementation of the invention

The following detailed description describes a camera system including methods and apparatus for managing a camera resource in a portable device. In one or more embodiments, the portable device has an integrated controller and limited resources (i.e., limited storage capacity), and the camera system works to allow applications to control the camera resource using a single interface.

In one or more embodiments, the camera system interacts with a run environment of a program implemented on a device that is used to simplify the operation of the device by providing generalized calls to specific resources of the device. One such program execution environment is a software platform Binary protection program run for wireless (BREW ^TM), developed by QUALCOMM, Inc., of San Diego, California. In the following description, it will be assumed that the camera system is implemented on a portable device running a program run environment, such as the BREW software platform. However, one or more embodiments of the camera system are suitable for use with other types of runtime environments for managing camera resources on a portable device.

FIG. 1 represents a data network 100 that includes a portable wireless device 102 with an integrated controller suitable for executing one embodiment of a camera system, hereinafter referred to as the “ICamera” system and shown at 104. The ICamera system 104 is operating to ensure that applications that run on device 102 control a camera resource 124 located on device 102. In one embodiment, the ICamera system 104 interacts with a run environment 116 a program running on a device. For example, in one embodiment, the program run environment 116 is a BREW software platform.

In one or more embodiments, the ICamera system 104 is suitable for use with a wide variety of portable devices. For example, other suitable handheld devices include, but are not limited to, handheld computers (PDAs), email devices, pagers, tablets, mobile phones, or virtually any other type of handheld device that includes a camera resource.

Wireless device 102 may operate to communicate with network server 106 via data network 108 using wireless communication channels 110. In one embodiment, device 102 comprises a cordless telephone that can transmit and receive voice and / or other information over network 108. Device 102 also works to receive applications over network 108. For example, applications 112 and 114 can be downloaded to device 102 from network server 106. These applications run on device 102 and use device camera 124 to provide additional features and / or functionality to a device user. For example, applications can receive and process still images or video information from the camera 124 of the device. It is also possible to download applications to the device 102 from any other network object connected to the network 108.

In one embodiment, device 102 is also directly connected to a local system, such as local workstation 118, through a forward link 120. The device 102 may operate to download applications from the local workstation 118 using the forward link 120. For example, application 122 is downloaded to device 102 from workstation 118 using communication line 120. The ICamera system 104 can be loaded from the server 106 to the device 102 and runs on the device 102 to enable applications to control the camera 124. In another embodiment, the ICamera system 104 can be downloaded to the device 102 from the workstation 118 via 120 communication or can be installed on the device 102 during manufacture.

In one embodiment, the ICamera system 104 is offered as instructions stored on a computer-readable medium, such as a floppy disk, and downloaded to the system 118 for transmission to the device 102. In another embodiment, the ICamera system 104 can be stored on a computer-readable medium, such as a memory card (not shown), and inserted directly into the device 102, so that the ICamera system 104 can run on the device 102. Thus, the device 102 can receive the ICamera system 104 in wireless a single transmission, a wired transmission, or by removing it directly from a storage device.

FIG. 2 is a block diagram illustrating one embodiment of a device 102 that includes one embodiment of an ICamera system 104 that operates to enable the application to efficiently manage camera resources. The device 102 comprises processing logic 202 that connects to the internal data bus 204 to a store-type memory 210. Also connected to the internal data bus 204 is a memory 206 for storing commands, an application memory 216, a dynamic memory area 210, a user interface 212, a camera logic 216, an audio device logic 218, and an input / output (I / O) interface 214.

During operation of device 102, processing logic 202 executes program instructions stored in instruction memory 206 to activate program run environment 116. The program run environment 116 may be a BREW environment or another suitable program run environment. To facilitate the execution of instructions, processing logic 202 uses a store-type memory 216 to store program data or instructions on a temporary basis. For example, processing logic 202 may store constants, variables, program addresses, pointers, instructions, or other information on a temporary basis in the dynamic memory region 210. The dynamic memory region contains virtually any type of memory suitable for storing and retrieving information through processing logic 202.

In one or more embodiments, the processing logic 202 comprises a central processing unit (CPU), a gate array, software, or logic circuitry comprising any combination of hardware and software. Thus, the processing logic 202 basically comprises a logic for executing machine-readable instructions.

The memory 206 for storing instructions comprises a random access memory (RAM), read-only memory (ROM), a group-overwritten storage (FLASH), an electronic-programmable read-only memory (EEPROM), or any other suitable type of memory, or a combination. In one embodiment, instruction memory 106 is located inside device 102, and in another embodiment, instruction memory 206 includes a removable memory card or memory device that can be selectively attached to device 102, and thereby connected to the internal bus 204. Thus, the storage device 206 for storing instructions can contain virtually any type of memory that is capable of storing instructions that can be executed on ops logic 202.

The user interface 212 receives user input, for example, from a keyboard, pointing device, touch keyboard, or other input mechanisms to enable the user to interact with device 102.

The audio circuit 218 comprises a logic circuit for outputting audio information to the speaker (s) of the device, remote speaker (s) or an audio system, or other type of sound source. For example, a pair of remote speakers may receive audio output from logic 218 to transmit audio information to a device user.

The camera logic 216 comprises hardware and / or software logic that serves as a means of connecting to the camera resource 124 installed on the device. For example, a device may include a charge-coupled device (CCD) camera or any other type of camera resource. The camera logic 216 serves as a means of connecting to a camera resource to ensure that still images and video images will be obtained from the camera resource. Thus, the camera logic 216 and the audiological circuit 218 may include hardware and / or software in any combination to enable the device 102 to capture and receive visual and audio information.

An I / O interface 214 operates to transmit and receive information between device 102 and external devices, systems, and / or networks. For example, in one embodiment, the input / output (I / O) interface 214 comprises a radio transmitter circuit (not shown) that operates to transmit and receive information over a wireless data network using, for example, communication line 110. For example, the transceiver comprises a circuit that modulates information received from the processing logic 2-2, and converts the modulated information into high frequency signals suitable for wireless transmission. Similarly, the transceiver also comprises a circuit for converting the received high frequency transmission signals to signals suitable for demodulation and subsequent processing by the processing logic 202.

In another embodiment, the input / output interface 214 comprises a transceiver that operates to transmit and receive information on a fixed-mount transmission line, such as a telephone line, to communicate with a remote system via a public data network such as the Internet.

In yet another embodiment, the input / output interface 214 comprises a circuit that operates to communicate with local devices, such as local workstation 116, using transmission line 120. The I / O interface 214 may also include a circuit (such as a logic circuit with a serial or parallel port) to communicate with a printer or other local computer or device, such as a floppy disk or memory card. Thus, the input / output interface 214 may comprise any type of hardware, software, or logic circuitry containing any combination of hardware and software to enable the device 102 to communicate with other local or remotely located devices or systems .

During operation of device 102, execution of program instructions by processing logic 202 causes ICamera system 104 to activate. For example, ICamera commands can be stored in computer-readable media, such as a memory for storing commands, and executing these commands activates the ICamera system. The ICamera system 104 interacts with the program run environment 116 to enable the application to efficiently manage the camera resource 124 located on the device. For example, application 220 is downloaded to device 102 via wireless network 108 and stored in memory 208. In one embodiment, application 220 is activated and interacts with ICamera system 104 to control the operation of camera resource 124 by controlling camera logic 216. For example, application 220 may act to extract still images or video frames from a camera resource, or set selected parameters that control how the camera resource works. To complete this, application 220 interacts with the only software interface provided by ICamera 104 to perform all operations associated with the camera resource.

FIG. 3 shows a detailed functional diagram of one embodiment of an ICamera system 104 running on the device 102. The device 102 includes its own hardware 302 that contain a camera resource, such as a camera 124. The device 102 also includes its own multimedia software 304, which contains software modules for audio and video. These modules may include specific encoding modules, such as MPEG4 and JPEG encoding modules. These modules represent low-level software modules that are used to directly communicate with native hardware 302. For example, modules 304 are connected to camera resource 302. Although one embodiment is shown, it is also possible to have fewer or more multimedia software modules 304, and these modules can be connected to all types of proprietary hardware 302. Thus, other configurations of proprietary hardware 302 and proprietary software 304 are possible within the scope. legal protection of the present invention.

During operation, device 102 executes program instructions to activate a program run environment 116, which in one embodiment is a Brew environment. During operation of the device 102, application 220 is then activated. For example, a device user downloads an application 220 from a data network (i.e., using an interface 214), and activates an application 220 through an I / F user 212. Application 220 was designed to manage the device’s camera resource, and was created using the structural components of ICamera, as described here.

Application 220 illustrates an example of ICamera system 104, which provides the possibility that application 220 uses the simple application programming interface 306 (API) provided by ICamera system 104 to perform all operations related to the camera resource. The media data structure 308 can optionally be created by the ICamera system 104 for storing and retrieving video information.

The ICamera system 104 connects and communicates with native modules 304 through a program run environment 116. For example, the program run environment 116 may be a Brew platform that provides generic calls to provide access to specific device resources. However, any suitable interface technology may be used to enable communication between the ICamera system 104 and the modules 304. Thus, it is possible for the ICamera system 104 to directly control any of the modules 304 to perform selected camera functions. For example, ICamera system 104 may control the Mpeg4 module to receive video data from a camera resource and encode it in Mpeg4 format. Data received by ICamera system 104 from modules 304 can be stored in the data structure 308, thereby performing the “Record” function, or can be retrieved and displayed on the device display, thereby performing the “Play” function.

The structure of data stored on the media

The data structure 308 stored on the medium works to protect the camera data received by the ICamera system 104 from the proprietary software 304. In one embodiment, the following structure defines a structure of data stored on the medium that provides source / receiver and context-sensitive data data related to the type of data stored on the medium.

typedef struct

{

AEECLSID clsData; // media data type

void * pData; // context sensitive data

uint32 dwSize; // context sensitive data

} AEEMediaData;

where the elements are defined as follows:

clsData; // media data type

pData; // context sensitive data

dwSize; // context sensitive data

and where the following table provides a detailed description of context-sensitive data for predefined media data types, where “Read / Write” means “Play / Write” in relation to the camera resource of the device.

clsData Mode pData dwSize MMD_FILE_NAME
MMD_BUFFER: read / write
read / write file name
printer data buffer size or 0 0 MMD_SOURCE: read / write ISOURCE data size or 0

It should be noted that for playback clsData can be set to the class identifier of any class based on ISOURCE with pData installed in the corresponding interface pointer device.

In one embodiment, the ICamera system 104 provides a single interface 306 that enables the application to manage the camera resource on the device. The interface 306 includes a set of commands for the ICamera system application programming interface (API), which provide various functions related to the camera. The application program interface (API) command set provided by ICamera is as follows:

one. ICAMERA_SetParm () ; sets camera parameters 2. ICAMERA_GetParm () ; gets camera settings 3. ICAMERA_Preview () ; starts previewing (viewfinder mode) four. ICAMERA_Pause () ; pauses the current operation 5. ICAMERA_Resume () ; resumes the current operation 6. ICAMERA_RecordSnapshot () ; record frame 7. ICAMERA_RecordMovie () ; recording a movie 8. ICAMERA_Stop () ; issues a shutdown command 9. ICAMERA_EncodeSnapshot () ; encodes a picture of a frame in a specific format (e.g. JPEG format) 10. ICAMERA_SetMediaData () ; sets media data eleven. ICAMERA_RegisterNotify () ; registers the notification function 12. ISHELL_CreateInstance () ; assigns a value to an object of the ICamera system and so on.

For example, the ICAMERA_SetParm () command may be executed by an application to instruct the ICamera system 104 to set specific parameters, settings, or variables associated with a device’s camera resource. In other embodiments, applications may execute one or more other ICamera system application program interface (API) instructions (not shown above) that may be included in ICamera system 104 to control virtually any camera resource function.

In one embodiment, the ICamera system 104 is operable to enable the application to manage the camera resource to take a frame and save it by following these steps:

1. The application program assigns a value to the ICamera system / interface object using the “ISHELL_CreateInstance ()” command and registers a callback function for receiving asynchronous events.

2. The “ICAMERA_Preview ()” command starts the camera in the preview mode, which provides the possibility that image frames will be received and displayed using the application through the registered callback function.

3. The “ICAMERA_SetMediaData ()” command sets the file name / buffer where data is to be written.

4. The “ICAMERA_SetVideoEncode ()” and “ICAMERA_SetAudioEncode ()” commands defines the encoding formats that should be used to encode image data from the camera resource and audio data. For example, encoding formats may be JPEG and MPEG4 encoding. For example, a camera resource may have a connected microphone for audio recording.

5. The ICAMERA_Recordsnapshot () command records and encodes the image at the specified destination.

In another embodiment, the ICamera system 104 is operable to enable the application to manage the camera resource to set camera operating parameters, such as a camera parameter that allows for zooming, or brightness and contrast levels, by executing the following application program interface commands ( API).

1. When the "ICAMERA_Setzoom ()" command is executed, the image scale level is set.

2. When the "ICAMERA_Brightness ()" command is executed, the brightness level is set.

3. When the "ICAMERA_SetContrast ()" command is executed, the contrast level is set.

FIG. 4 represents one embodiment of a state machine 400 provided by one embodiment of an ICamera system to enable an application to manage a camera resource on a portable device. After the application assigns a value to an object of the ICamera system, state machine 400 is in READY state 403. The application can then issue commands to the ICamera system application program interface to transition to other states of the state machine 400 and thereby control the operation of the camera resource. For example, the Preview () command activates the preview state 404. The Record_snapshot () command activates a frame state 406 when a frame image is obtained from a camera resource. The Record_movie () command activates the movie state 408 when a video stream is received from a camera resource. State machine 400 also provides the possibility that additional commands control the operation of each state. For example, the Pause () and Resume () commands may be used to control the operation of the preview state 404.

Therefore, the use of the state machine 400 provided by the ICamera system makes it possible for applications to control the camera resource of the system to obtain still images and video clips. It is also possible to modify the state machine 400 so as to add, delete, change, or reinstall the states and / or operation of the application program interface (API) commands to transition to the states without deviating from the scope of legal protection of the embodiments. Thus, virtually any type of state machine can be provided by the ICamera system to enable applications to manage the device’s camera resource.

FIG. 5 represents one embodiment of a method 500 for operating an ICamera system on a device to enable an application to manage a camera resource on a device. It will be assumed that the device implements the BREW run environment of the program and includes one embodiment of the ICamera system, as described here.

In block 502, an application is created using the structural components of the ICamera system so that it can control the camera resource on the device by using the simple application programming interface (API) provided by the ICamera system. For example, application developers create applications that run on portable devices and implement various camera functions. Applications include ICamera system application program interface (API) commands for connecting to the ICamera system, and thereby control the camera operations of the device in accordance with the state machine (i.e., state machine 400 shown in FIG. 4).

At block 504, an application with ICamera system application program interface (API) commands are downloaded to a portable device for execution. For example, an application may be downloaded to a device via a wireless data network 108. An application may be executed immediately or be stored in a storage device and executed at a later time.

At block 506, the application is executed and assigns a value to an object of the ICamera system. For example, an application runs in a run environment of a program running on a device. At run time, the application assigns values to an ICamera system object so that it can control the device’s camera resources.

At block 508, the application registers a notification function if it is required for received asynchronous events from the ICamera system. For example, selected camera events may trigger notification to the application.

At block 510, a media data structure is created and initialized based on the camera resource and / or the required encoding characteristics for the medium. For example, in one embodiment, the data type of the medium is determined based on the file extension, file content, and file encoding.

In block 512, the application issues the ICamera application program interface (API) commands to the ICamera system, which, in turn, operates to manage the camera resource on the portable device. For example, an application may issue commands to perform any of the functions described in state machine 400 to control the operation of a camera resource. Thus, the application can receive frames, video images, or control camera settings, regardless of the type of camera resource available on the device. As a result, the camera system works to eliminate any potential compatibility issues between the camera resource of the device and the application.

In block 514, after the application has completed the camera functions, the ICamera system is no longer required and it turns off.

It should be noted that the method 500 represents only one embodiment and that it is possible to make changes, additions, deletions and / or reinstallation of the steps of the method without departing from the scope of legal protection of the described embodiments.

Implementation example

The following is an exemplary embodiment to illustrate how, in one embodiment, the value is attributed to an object of the ICamera system and the camera resource is controlled by an application downloaded to a portable device. This example includes references to corresponding blocks in the method 500 of FIG. 5, and it is assumed that the program run environment used by the portable device is a BREW environment. The Carr example is the global structure of the BREW applet.

static void App_CameraPreview (CApp * pme)

{

int nRet;

AEEMediaData md;

// create the data structure of the media (Figure 5 - block 510)

md.clsData = MMD_FILE_NAME;

md.pData = (void *) "album / snapshot.jpg";

md.dwSize = 0;

// Activate the ICamera system and bring it to the Ready state (Figure 5 - block 508)

nRet = ISHELL_CreateInstance (pme-> a.pIShell, AEECLSID_CAMERA, & pme-> m_pICamera);

// If successful, register App_CameraNotify () as a registered callback for ICamera system events (Figure 5 - block 508)

if (SUCCESS! = nRet)

DisplayErrorDlg (pme, IDS_ERR_CREATECAMERA);

else if (SUCCESS! = ICAMERA_RegisterNotify (pme-> m_pICamera, App_CameraNotify, pme))

DisplayErrorDlg (pme, IDS_ERR_REGISTERNOTIFY);

// Start the preview (Figure 5 - block 512)

else if (SUCCESS! = ICAMERA_Preview (pme-> m_pIMedia)) DisplayErrorDlg (pme, IDS_ERR_PLAY);

Multiple Camera Resources

In one embodiment, the ICamera system works to enable the application to manage multiple camera resources on a single device. For example, a device may include a low resolution camera for capturing still images and a high resolution camera for receiving video clips. In this embodiment, object values for the two ICamera system variants can be attributed to allow the application to manage two camera resources. For example, one ICamera system application programming interface (API) is used by an application to control a low resolution camera, and a second ICamera system application programming interface (API) is used by an application to control a high resolution camera. For example, one camera can be used for video telephony, and the second camera as a digital converter (DSC) / recording video camera.

For clarity of description, drawings representing the operation of two or more ICamera systems on a device are not provided. However, since each ICamera system operates as described here, such drawings would be redundant and unnecessary. During operation, the application ascribes the values of the object to the first and second variants of the ICamera system, thereby activating the first and second application programming interfaces (APIs) of the ICamera system. The application then executes commands associated with any application programming interface (API) to manage the corresponding camera resource. Thus, embodiments of the ICamera system can be used to enable the application to manage virtually any number of camera resources on the device.

In one or more embodiments, a camera system has been described including methods and a device that operates to enable an application to manage one or more camera resources on a portable resource-limited device having an integrated controller. Accordingly, while one or more embodiments of the methods and devices have been illustrated and described herein, it is significant that various changes can be made to the embodiments without departing from their spirit or essential characteristics. Therefore, it is intended that the embodiments provided herein are illustrative, but not limiting, of the scope of the legal protection of the invention as defined by the following claims.

Claims (20)

1. A method of actuating a camera system to enable an application to manage a camera resource capable of performing camera functions in a portable device, the method comprising:
activate the camera system, while the camera system is able to work so as to control the camera resource;
pairing the camera system with one or more proprietary modules that connect to the camera resource;
provide an application programming interface (API) for accepting commands from the application by the camera system;
receiving a command from the application by the camera system through the application program interface (API), the command identifying the camera function to be performed;
controlling through the camera system one or more native modules based on a command;
controlled by one or more proprietary modules based on a command, a camera resource, and
the camera resource identified by the command is performed by the camera resource. 2. The method according to claim 1, which also consists in generating a data structure of the medium in order to store data received from the camera resource. 3. The method according to claim 1, in which the step of performing the function of the camera is that:
provide a state machine that identifies functions associated with a camera resource; and
control a state machine based on a command to execute a camera function. 4. The method according to claim 1, in which the portable device contains a second camera resource, and the method consists in the fact that:
activate the second camera system, while the second camera system is able to work so as to control the second resource of the camera;
provide a second application programming interface (API) for accepting commands from the application;
receive the second command from the application through the second application programming interface (API), while the second command identifies the camera function that must be performed by the second camera resource; and perform a camera function identified by the second command. 5. The method according to claim 1, wherein the portable device is a wireless device. 6. A device for actuating a camera system so as to enable the application to manage a camera resource capable of performing camera functions in a portable device, the device comprising:
means for activating the camera system, while the camera system is able to work so as to control the camera resource;
moreover, the means for activating contains means for establishing a pairing of the camera system with one or more of its own modules that are connected to the camera resource;
means for providing an application programming interface (API) for receiving commands from an application by the camera system;
means for receiving a command from the application by the camera system through the application program interface (API), the command identifying a camera function to be performed;
means for controlling, through the camera system, one or more native modules based on a command;
means for controlling through one or more proprietary modules based on a command, a camera resource, and
means for the camera resource to perform the camera function identified by the command. 7. The device according to claim 6, which also contains means for generating a data structure of the medium to store data received from the camera resource. 8. The device according to claim 6, in which the means for performing the function of the camera contains:
means for providing a state machine that identifies functions associated with a camera resource; and
means for controlling a state machine based on a camera function command. 9. The device according to claim 6, in which the portable device contains a second camera resource, and this device contains:
means for activating a second camera system, wherein the second camera system is capable of operating to control a second camera resource;
means for providing a second application programming interface (API) for receiving instructions from the application;
means for receiving a second command from the application through the second application program interface (API), wherein the second command identifies a camera function to be performed by the second camera resource; and
means for performing a camera function identified by a second command. 10. The device according to claim 6, in which the portable device is a wireless device. 11. A computer-readable medium comprising instructions that, when executed by a processor in a portable device, operate to provide a camera system that enables the application to manage a camera resource capable of performing camera functions in a portable device, the computer -readable media contains:
commands to activate the camera system, while the camera system is able to work so as to control the camera resource;
moreover, the activation commands contain commands for pairing the camera system with one or more of its own modules that are connected to the camera resource;
instructions for providing an application program interface (API) for receiving by a camera system an application program interface (API) commands from an application;
commands for the camera system to receive the application program interface (API) commands from the application through the application program interface (API), wherein the application program interface (API) command identifies the camera function to be executed;
commands for controlling through the camera system one or more native modules based on the command;
commands for controlling through one or more proprietary modules based on the command, camera resource, and
commands for the camera resource to perform the camera function identified by the application program interface (API) command. 12. A computer-readable medium according to claim 11, which also contains instructions for generating a data structure of the medium for storing data received from the camera resource. 13. A computer-readable medium according to claim 11, wherein the instructions for execution comprise:
commands for providing a state machine that identifies functions associated with a camera resource; and
commands to control the state machine based on the command of the application program interface (API) to perform the camera function. 14. A computer-readable medium according to claim 11, wherein the portable device comprises a second camera resource and the computer-readable medium comprises:
instructions for activating the second camera system, wherein the second camera system is capable of operating to control the second camera resource;
instructions for providing a second application program interface (API) for receiving instructions of an application program interface (API) from the application;
instructions for receiving a second command of an application program interface (API) from an application through a second application program interface (API), wherein a second application program interface (API) command identifies a camera function to be performed by a second camera resource; and
instructions for performing a camera function identified by a second application program interface (API) command. 15. The computer-readable medium according to claim 11, in which the portable device is a wireless device. 16. A device for actuating a camera system so as to enable the application to manage a camera resource capable of performing camera functions in a portable device, the device comprising:
a logic circuit for activating the camera system, while the camera system is able to operate in such a way as to control the camera resource;
moreover, the logic circuit for activation contains a logic circuit for establishing a pairing of the camera system with one or more of its own modules that are connected to the camera resource;
logic to provide the application programming interface (API) for the camera system to receive commands from the application;
a logic diagram for receiving a command from the application by the camera system through the application program interface (API), the command identifying the camera function to be performed;
a logic circuit for controlling, by means of a camera system, one or more native modules based on a command;
a logic circuit for controlling by one or more proprietary modules, based on a command, a camera resource; and
a logic circuit for the camera resource to perform the camera function identified by the command. 17. The device according to clause 16, which also contains a logic circuit for generating a data structure of the medium for storing data received from the camera resource. 18. The device according to clause 16, in which the logic circuit for performing the function of the camera contains:
logic to provide a state machine that identifies functions associated with a camera resource; and logic for controlling a state machine based on a command to perform a camera function. 19. The device according to clause 16, in which the portable device contains a second camera resource and the device contains:
a logic circuit for activating a second camera system, wherein the second camera system is capable of operating to control a second camera resource;
logic to provide a second application programming interface (API) for accepting instructions from the application;
a logic circuit for receiving a second command from an application through a second application program interface (API), wherein the second command identifies a camera function to be performed by a second camera resource; and
logic to perform a camera function identified by a second command. 20. The device according to clause 16, in which the portable device is a wireless device.

Images