Method and system for automatically configuring a hand-held camera using wireless communication to improve image quality

[0001] The present invention relates to configuring camera settings, and more particularly to a method and system for automatically configuring a hand-held camera using wireless communication to improve image quality.

[0002] It is well known that cameras have various settings that must be properly configured to enable the camera to take a picture having correct focus and exposure. Most cameras have a manual mode and one or more automatic modes for configuring the settings. In the manual mode, the user physically adjusts the settings based on experience and judgment, while in automatic mode, the camera automatically adjust its settings.

[0003] While automatic mode was designed to eliminate an amateur's stumbling block to more successful picture-taking, the settings are configured based on a set of relatively simple heuristics that often prove to be wrong. For example, in digital cameras, white balance may be automatically set based on a principle called “grey world” where all color pixels on the CCD are added such that the total color averages to grey. While this principle may work in many environments, it may not work in others, such as in a dark, yellow-lit room that one would encounter in a bar or museum, for instance.

[0004] Similarly, automatic focus in cameras is for the most part based two types of heuristics called “hill climbing” and “range finding”. In hill climbing, the lens is moved back and forth until the highest contrast point is detected in the center of the image, while in range finding, SONAR and infrared is used to provide a rough estimate of distance. While most automatic camera setting techniques work reasonably well, such as auto focus, camera's would take the highest quality photos possible if the need to “guess” at the conditions surrounding the subject to be photographed could be eliminated.

[0005] Accordingly, an improved method and system for configuring camera settings is needed. The present invention addresses such a need.

[0006] The present invention provides a method and system for automatically configuring a hand-held camera to improve quality of an image taken with the camera of a particular subject at a photo opportunity site. According to the method and system disclosed herein, values for a set of camera setting parameters that are optimized to enhance image quality of a picture taken at that location are determined. Next, wireless communication with the camera is established, and the set of setting parameter values are pushed to camera via the wireless communication to automatically configure the camera to take a picture of the subject.

[0007] According to the present invention, when a user subsequently captures the image using the settings values, image quality will be improved because the camera has been automatically configured for the conditions of the subject, such as the distance from the camera to the subject and lighting, which are factors known ahead of time. Therefore, the camera does not have to rely on potentially unreliable heuristics to set camera settings.

[0020] The present invention provides a method and system for automatically configuring settings in a hand-held camera using wireless commutation to improve image quality. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiment shown but is to be accorded the widest scope consistent with the principles and features described herein.

[0021] FIG. 1 is a block diagram illustrating a system for automatically configuring a hand-held camera in accordance with the present. In a preferred embodiment, the system 10 includes a server 12, a database 14, a primary site 16 having one or more photo opportunity sites 18, where each photo opportunity site 18 is in communication with the server 12 and is equipped with a wireless transceiver 20, and at least one a hand-held portable camera 22 that is also equipped with a wireless transceiver 24. An example of a primary site 16 is a tourist destination, such as a national park or museum that includes several scenic locations and/or attractions for visitors to take pictures of with their cameras 22. As used herein, any such scenic local and/or attraction that is visited by many people and is a popular photography spot may be called a photo opportunity site (hereinafter referred to as “photo op”) 18.

[0022] According to the present invention, the primary site 16 or a third party content provider familiar with the conditions surrounding each photo op site 18, determines a set of predefined camera setting parameter values 26 for each photo op site 18 that are optimized to enhance image quality of a picture taken at that location, and stores theses parameter values in the database 14, preferably sorted by photo op site 18. As conditions change at each photo op site 18, the setting parameter values may be added or updated as required. Examples of a change in conditions for an indoor object include changes in environment, such as in lighting and positioning, for instance. For an outdoor object, environmental changes would also include changes in weather, time of day, and seasonal changes. When a camera makes contact with a photo op transceiver 20, the server 12 retrieves the setting parameter values stored in the database 14 and relays the setting parameter values to the appropriate photo op site 18.

[0023] At each photo op site 18, the transceiver 20 is located in proximity to where a user would capture an image of the subject with the camera 22. For example, the transceiver 20 could be located within a plaque commemorating the subject, or located within a kiosk device at the photo op site 18. When a user brings the camera 22 within range of the transceiver 20 at a photo op site 18, the transceiver 20 transmits the camera setting parameter values 26 to the camera 22 corresponding to the photo op site 18 to dynamically configure the camera's capture settings. When a user subsequently captures the image using those settings, image quality will be improved because the camera 22 has been automatically configured for the conditions of the subject, such as distance from the camera 22 to the subject and the lighting, which are known ahead of time. Therefore, the camera 22 does not have to rely on potentially unreliable heuristics to set camera settings.

[0024] To further illustrate the present invention, consider the following examples of the configuration system of the present invention deployed at various locations. As the first example, assume that primary site 16 is the Louvre Museum, France. Assume further that one of the photo op sites 18 is the Mona Lisa, and that visitors are allowed to take pictures, but without using a flash. As a user approaches with a compatible camera 22, the photo op transmitter 20 would transmit camera setting parameters to the camera 22. For example, the strobe or flash setting would be set to “off”, a wide aperture and fast shutter speed would be chosen to reduce blurring since it is known the camera 22 will be hand-held, and gain control would be increased to compensate for a potentially under exposed image. Because the aperture is wide, the depth of field will be small, so focus is critical. However, according to the present invention, the distance from where the user stands to the picture of the Mona Lisa is already known, so the photo op site 18 would set the camera's focal distance to 1.8 meters, for instance.

[0025] As the second example, assume the photo op site 18 positioned at a look out point over the grand canyon, and that it is a sunny day. The photo op site 18 would send parameters similar to the following to the camera 22: “hyper focal distance, fastest shutter, strobe off, CCD gain off, and aperture smallest” to help minimize the amount of time the camera is in AutoS1 (searching for A*) state.

[0026] As a further example, assume the photo op site 18 is positioned within Disneyland in at the entrance to “Splash Mountain.” The photo op site 18 would send parameters similar to the following to the camera 22: “high shutter speed, small aperture, focus distance 32 feet”. The photo op site 18 could even instruct the camera to go to S2 (shutter position 2) automatically to synchronize when a water sled goes sliding down the water fall.

[0027] Thus, according to the present invention, the camera 22 is provided with the optimal set of camera settings that will produce the highest quality image possible, given the camera's capabilities, and the conditions surrounding the subject. Thus, the user does not have to rely on unreliable built-in camera 22 heuristics to determine how to configure the camera 22 for a particular subject. Instead, since the conditions at the photo op site 18 are known, the optimal camera setting parameters may be pre-stored in the database 14.

[0028] In a preferred embodiment of the present invention, each photo op site 18 may be connected to the server 12 via any type of communications network, such as a local area network (LAN), an intranet, or the Internet. And the transceivers 20 located at each photo op site 18 and the camera transceiver 24 are compatible with a wireless data transmission standard, such as Bluetooth (IEEE 802.15) or IRDA, although other wireless data transmission protocols may also be used. It should also be noted that the server 12 and/or the database 14 may be located within, or remote from, the primary site 16; and that in the case where there is only one photo op site 18, the photo op site 18 may also be considered the primary site 16.

[0029] According to a second aspect a present invention, the database 14 also contains additional content corresponding to each photo op, such as images, text and sound relating to the subject. The user may then display these images and text on the LCD of the camera 22 to learn more about the subject. Thus, not only will the camera 22 be automatically configured to capture the best quality image possible, but the additional information transmitted to the camera 22 will also allow the user's camera 22 to become a tour aid device. While some museums provide patrons with tape recorders for playing back prerecorded content, the tape recorders are specialized devices of the museum designed to perform a single function. The present invention, by contrast, allows dynamic, real-time configuration of a consumer device that is owned by the user instead of the photo op site 18, such that the camera becomes a dual functioning device when in the presence of the photo op transceiver.

[0030] According to a third aspect of the present invention, each photo op site 18 may be provided with weather instruments that relay the local weather conditions to the server 12. The server 12 may then use the current conditions to query the database 14 to retrieve the best parameters for the current conditions. For example, assume that the primary site 16 is a national park, such as Yosemite, and that multiple photo op transceivers 20 are placed in various locations through out the vast park. Since weather conditions may be different at one end of the park to the other (e.g. partly sunny vs. raining), the server 12 would send different sets of parameter values to each photo op site 18 based on the real-time weather reports received from each of the photo op sites 18.

[0031] FIG. 2 is a flow chart illustrating in more detail the photo op transceiver process for automatically configuring capture settings of a hand-held camera 22 in accordance with the present invention. The process begins by establishing wireless communication between the photo opportunity site and the camera 22 once the camera 22 comes within range of the photo op transceiver 20 in step 30. After establishing communication, the photo op transceiver 20 queries the camera 22 for current settings and capabilities in step 32.

[0032] Table I below is a list showing N example camera setting parameters and corresponding value ranges that the camera 22 may return to the photo op transceiver 20:

[0033]

	TABLE I
	CAMERA PARAMETER
	SETTING	VALUE RANGE
	1.	Aperture	f2–f8
	2.	Shutter Speed	1/1000 to 5 seconds
	3.	Focal Distance	|
	4.	Zoom Position	|
	|	|	|
	N.

It should be noted that the example camera setting parameters could be included in either a tradition film camera 22, or a digital camera 22. However, if the camera setting parameters are for a digital camera 22, other types of camera setting parameters would be included, such as CCD gain, and white balance. Since different digital cameras 22 have the capability of capturing various types of images such still images, burst images, timelapse images, panoramas, and movie clips, another setting parameter would be included to specify the applicable image type.

[0034] The photo op transceiver must query the camera 22 for camera setting capabilities because different cameras 22 made by different manufacturers may have different capabilities and capture setting parameters. In addition, a 35 mm SLR will have different capture setting parameters and value ranges than a digital camera 22. However, if only a limited number of types of cameras 22 are compatible with the configuration service and their capabilities are known, then the step of querying the camera 22 for capabilities may be omitted.

[0035] In response to determining the current capabilities and capture setting parameters of the camera 22, the photo op transceiver 20 pushes N setting parameter values 26 to the camera 22 corresponding to N camera setting parameters to automatically configure the camera 22 for capturing a photo of the subject in step 34. Since all the information about the conditions surrounding the subject being photographed is known ahead of time, the camera setting parameters may be optimized for the camera's capability to enable the camera 22 to take the highest quality picture of the subject possible under those conditions.

[0036] In addition to pushing camera settings parameter values to the camera 22, the photo op transceiver 20 may also push optional additional content to the camera 22 regarding the subject being photographed in step 36.

[0037] FIG. 3 is a block diagram illustrating examples of additional content that may be pushed to the camera 22 by the photo op transceiver 20. The additional content 38 may include one or more category tags 40, an image file 42, a text file 44, and an audio file 46. In a preferred embodiment, the category tags 40 are used by the camera 22 to automatically categorize the photograph of the subject that will subsequently be taken. For example, if the photo op site 18 is located at the Grand Canyon, a category tag of “Grand Canyon” may be sent to the camera 22 and associated with the image. The additional image file 42 could include an image of the Grand Canyon taken from a different location or under different weather conditions. The text file 44 could include history information, such as on the formation of the Grand Canyon, and the audio file 44 could include sound clips of nature in the Grand Canyon, or a narrative about rock formations, for example. The audio file 46 could optionally be associated with the image the user captures in a manner similar to associating the category tags 40 with the image.

[0038] According to a fourth aspect of the present invention, a timestamp 48 may also be included with the additional content 38 transmitted to the camera 22 that defines the total time the files may be stored in the camera 22. The timestamp 48 is discussed further below in conjunction with FIG. 4.

[0039] Referring again to FIG. 2, after the parameter values and optional content are pushed to the camera 22 in steps 34 and 36, the process continues at step 32 where the photo op transceiver queries the camera 22 for current settings. A change in the current settings will be relayed to the server 12, which will then use the current settings to retrieve a new set of capture setting parameter values 26 from the database 14 for transmission to the camera 22 via the photo op transceiver 20.

[0040] Referring now to FIG. 4, a flow chart is shown illustrating the in-camera process for automatically configuring the camera's setting parameters after communication with a photo op transceiver 20 has been established in accordance with the present invention. The process begins by receiving the N camera setting parameter values 26 and optional content regarding the subject in step 50. The camera 22 then uses the parameter values to automatically configure the corresponding camera settings in step 52. After the camera's settings are automatically set, the camera 22 locks the capture settings in step 54.

[0041] In a preferred embodiment of the present invention, the zoom setting on the camera 22 is not locked in order to allow the user to zoom in and out of the scene. As those with ordinary skill in the art will readily recognize, changing the zoom setting may require new setting parameter values, such as a change in exposure and focus. Therefore, the process of querying the camera 22 by the photo op transceiver for current settings is performed periodically so that as the user varies the zoom setting, the setting parameter values pushed to the camera 22 by the photo op transceiver 20 are updated accordingly.

[0042] After the settings parameter values are locked, the user may capture an image of the subject using the automatically configured setting parameters in step 56. In response to receiving category tags 40 from the photo op transceiver, the camera 22 associates the category tags with the captured image for automatic categorization in step 58. In a preferred embodiment, the user must request that the image be automatically categorized. Although the category tags 40 may be associated with the image using a variety of methods, in a preferred embodiment, the category tags 40 are stored within the image file itself.

[0043] In response to receiving additional content files 42–46 corresponding to the subject, the camera 22 displays the content on the camera's LCD in step 60. In a preferred embodiment, the user is prompted to place the camera 22 in play mode to play the additional content.

[0044] In a preferred embodiment, the additional content files 42–46 are deleted from the camera 22 once the timestamp 48 associated with files has expired in step 62. In a preferred embodiment, the timestamp 48 is implemented as a numerical value that the camera 22 uses as countdown timer. When the value is received, the camera 22 continually decrements the value until it becomes zero, at which point the files associated with the timestamp 48 are deleted. In an alternative embodiment, the timestamp 48 is implemented as a literal expiration time (GMT), or a usage count (e.g., the content may be viewed 5 times before deletion.

[0045] According to the present invention, the timestamp 48 is transmitted to the camera 22 along with the additional content 38 for two reasons. One reason is that the proprietor of the primary site 16 may have spent considerable time and expense producing the additional content 38 for the visitors, and by ensuring that the additional content 38 remains on the user's camera 22 for only a predetermined amount of time, some measure of copyright protection is afforded. The second reason that the timestamp 48 is provided is that automatic deletion ensures that the camera's memory is not filled with undesired material.

[0046] In another embodiment, users may be offered the opportunity to pay for the additional content 38 upon exiting the primary site 16. When payment is received, a transceiver located at the payment center would resend the selected content to the camera 22 without the timestamp 48.

[0047] Referring now to FIG. 5, a block diagram illustrating an example camera architecture for supporting wireless communication of software commands and information between the digital camera 22 and server 12 for auto configuration is shown in accordance with the present invention. System bus 80 provides connection paths between imaging device 82, Liquid Crystal Display (LCD) 83, central processing unit (CPU) 84, dynamic random-access memory (DRAM) 86, transceiver 24, and non-volatile memory 88.

[0048] CPU 84 typically includes a conventional processor device for controlling the operation of camera 22. In the preferred embodiment, CPU 84 is capable of concurrently running multiple software routines to control the various processes of camera 22 within a multi-threaded environment. DRAM 86 is a contiguous block of dynamic memory which may be selectively allocated to various storage functions. CPU 84, or optionally an LCD controller, accesses DRAM 86 and transfers processed image data to LCD screen 83 for display. Non-volatile memory 88, which may typically comprise a conventional read-only memory or flash memory, stores a set of computer-readable program instructions to control the operation of camera 22.

[0049] In a preferred embodiment, the digital camera 22 includes a modularized series of capability parameter storage locations for containing parameter values, and parameter manager 410 software responsive to receiving a software command from the server 12 to retrieve and return the capability parameter values to the server 12. For purposes of description, the software command is referred to herein as a “GetCameraCapabilities” command.

[0050] When the digital camera 22 comes within range of the photo op transceiver 20, the server 12 issues the GetCameraCapabilities command to the camera 22 through the photo op transceiver 20, shown by line 90. In the preferred embodiment of the invention, interface lines 90 and 96 represent a wireless data communication standard, such as Bluetooth, for instance. The camera's transceiver 24 receives the GetCameraCapabilities command, and responsively passes the command to CPU 84 via system bus 80. CPU 84, acting upon the GetCameraCapabilities command and using the parameter manager 410 software, accesses the capability data contained in parameter manager 410 via line 92. Parameter manager 410 then transfers the capability data via line 94 and system bus 80 to transceiver 24, which responsively transmits the capability data to photo op transceiver 20. Photo op transceiver 20 then passes the data on to the server 12. The server 12 uses the data and the I.D. of the photo op site 18 to query the database 14 for the appropriate set of camera setting parameter values for the automatic configuration of the camera 22.

[0051] The GetCameraCapabilities command may retrieve the capability parameter value sets in several ways. In one embodiment of the present invention, if the GetCameraCapabilities command is issued with the capability parameter abbreviated name field (called the PName field) set to all nulls, then the parameter manager will interpret this as requesting a complete set of all of the capability parameters. The parameter manager first returns a numerical value called ResLength, which typically will be the number of different capability parameters which the interrogated camera 22 supports. After the parameter manager returns the ResLength, it then sends the value sets for all of the capability parameters supported by the camera 22.

[0052] In a second embodiment of the present invention, if the GetCameraCapabilities command is issued with the PName field set to all nulls, then the parameter manager will interpret this as requesting a set of all of those capability parameters which are not included in a specified core camera 22 capability parameters set. The parameter manager first returns ResLength, which typically will be the number of different capability parameters not included in the specified core camera 22 capability parameters that the interrogated camera 22 supports. After the parameter manager returns the ResLength, it then sends the value sets for all of the capability parameters which are not included in the specified core camera 22 capability parameters supported by the camera 22.

[0053] If either of the foregoing embodiments of the present invention issues a GetCameraCapabilities command with the PName field set to a non-null value, the parameter manager interprets this as a request for the value set corresponding to the specific PName capability parameter. In this case, the value of ResLength returned is 1, and the single value set corresponding to the specific PName capability parameter is returned following ResLength.

[0054] The server 12 or the user of the camera 22 may therefore more efficiently and effectively obtain sets of capability parameters for the digital camera 22, in accordance with the present invention.

[0055] In the FIG. 5 embodiment, server 12 issued the GetCameraCapabilities command. In other embodiments of the present invention, the GetCameraCapabilities command may be issued in response to the user pressing one of the buttons and dials (not shown) of the digital camera 22, or by a special parameter script imported into digital camera 22 via a removable memory and executed by CPU 84. The capability parameters would then be displayed on LCD screen 83, preferably in the form of a series of menus.

[0056] Referring now to FIG. 6, one embodiment showing the software components stored in non-volatile memory 88 is shown. In the FIG. 6 embodiment, non-volatile memory 88 includes control application 400, toolbox 402, drivers 404, kernel 406 and system configuration 408. Control application 400 includes program instructions for controlling and coordinating the various functions of camera 22. Toolbox 402 contains selected function modules including parameter manager 410, menu dialog manager 414, EEPROM interface 418 and command handler 422.

[0057] Parameter manager 410 includes software routines which control and coordinate various operating parameters in camera 22, according to the present invention. Menu dialog manager 414 includes software routines which coordinate functions related to the user interface, including displaying information on LCD screen 83 and handling information input from buttons. EEPROM interface 418 coordinates communications to and from an EEPROM via system bus 80. Command handler 422 accesses and handles various system commands and advantageously provides the commands to the appropriate destination within camera 22.

[0058] Drivers 404 control various hardware devices within camera 22 (for example, motors. Kernel 406 provides basic underlying services for the camera 22 operating system. System configuration 408 performs initial start-up routines for camera 22, including the boot routine and initial system diagnostics.

[0059] Referring now to FIG. 7, a memory map showing one embodiment of dynamic random-access-memory (DRAM) 86 is shown. In the FIG. 7 embodiment, DRAM 86 includes RAM disk 532, a system area 534, and working memory 530.

[0060] RAM disk 532 is a memory area used for storing raw and compressed image data and typically is organized in a sectored format similar to that of conventional hard disk drives. In the preferred embodiment, RAM disk 532 uses a well-known and standardized file system to permit server 12, via transceiver 24, to readily recognize and access the data stored on RAM disk 532. System area 534 typically stores data regarding system errors (for example, why a system shutdown occurred) for use by CPU 84 upon a restart of digital camera 22.

[0061] Working memory 530 includes various stacks, data structures and variables used by CPU 84 while executing the software routines used within digital camera 22. Working memory 530 also includes input buffers 538 for initially storing sets of raw image data received from imaging device 82 for image conversion, and frame buffers 536 for storing data for display on the LCD screen 83.

[0062] Working memory 530 further contains current parameters 540 which preferably include current settings for a wide variety of operational and functional attributes of camera 22.

[0063] Referring now to FIG. 8, a diagram is shown illustrating one embodiment for the capability parameters contained within the parameter manager 410, which are stored in part of the non-volatile memory. In addition to comprising executable software, parameter manager 410 includes capability parameter 1 (710 (a)) through capability parameter “N” (710(d)) which each preferably includes, but is not limited to, the capability for various operational and functional attributes of camera 22. In the preferred embodiment, there are three basic formats for capability parameters. The formats are called “list of values” format, “range of values” format, and “fixed value” format. The first two of these formats are discussed in detail below in conjunction with FIGS. 9A and 9B. The third format, the fixed value format, simply returns a fixed value for a camera's parameter. For example, a capability parameter for camera 22 name returns a user-defined string.

[0064] Specific preferred examples for capability parameter 1 (710(a)) through capability parameter “N” (710(d)) are provided below in TABLE II. However, various other capability parameters not listed in TABLE II are equally possible in other embodiments.

[0065]

TABLE II
	PARAMETER
PNAME	DESCRIPTION	VALUE TYPE	VALUE RANGE
xmod	Exposure mode	Uinteger	1 = Auto
	specification	List	2 = Shutter priority
			3 = Aperture priority
			4 = Gain priority
			5 = Manual
fmod	Focus mode	UInteger	1 = Auto
	specification	List	2 = Program
			3 = Manual
smod	Strobe mode	Uinteger	0 = Off
	specification	List	1 = Auto
			2 = Fill
			3 = Slave
			4 = Sync
zpos	Zoom position	UInteger	100 = 1X (no zoom)
	specification	List	200 = 2X
			300 = 3X
shut	Shutter speed	UInteger	125 through 4000000
	specification;		measured in steps, with
			16666 being equivalent
			to 1/60 second
fdst	Focus distance	UInteger	30 through 65535
	specification;
	measured in
	centimeters,
	with 65535 being
	infinity

[0066] Referring now to FIG. 9A, a detailed view of the structure of an exemplary capability parameter 710(a) in “list of values” format is shown. In FIG. 9A, the capability parameter for “strobe mode specification” has been chosen to illustrate a capability parameter in “list of values” format. In the preferred embodiment, each “list of values” capability parameter typically contains a PName 802 comprising 32 bits containing 4 ASCII characters, which in this exemplary case is the character set “smod” 804. Additionally each “list of values” capability parameter typically contains a text string 806 containing a description of the capability parameter 808, which in the FIG. 9A example is “strobe mode specification”. The description of the capability parameter 808 will, in each case, be a text string readable by a human user of the digital camera 22.

[0067] In the specific case of a capability parameter in “list of values” format, the value set for the capability parameter contains a variable (of type unsigned integer) called count 810 and a value list 812 which includes a list of integers and corresponding string variables. In the FIG. 9A example, “0” is associated with “Off”, “1” is associated with “Auto”, “2” is associated with “Fill”, “3” is associated with “Slave”, and “4” is associated with “Sync”. In the preferred embodiment, count 810 contains a value which is the total number of integers present in value list 812. In the FIG. 9A example, count 810 contains the value “5”.

[0068] The “list of values” format also typically includes a factory default setting 814. The factory default setting 814 contains a value corresponding to a value in list 812 which describes the appropriate factory default value. In the FIG. 9A example, factory default 814 is associated with count value “1”, which corresponds to the element “Auto”.

[0069] Referring now to FIG. 9B, a detailed view of the structure of an exemplary capability parameter 710(b) in “range of values” format is shown. In FIG. 9B, the capability parameter for “focus distance specification” has been chosen to illustrate a capability parameter in “range of values” format. In the preferred embodiment, each “range of values” capability parameter typically contains a PName 802 comprising 32 bits containing 4 ASCII characters, which in this second exemplary case is the character set “fdst” 816. Again each “range of values” capability parameter typically contains a text string 806 containing a description 818 of the particular capability parameter. In the FIG. 9B example, description 818 is “focus distance”, meaning that the numerical values are focal distances in centimeters.

[0070] In the specific case of a capability parameter in “range of values” format, the value set of the capability parameter contains three variables (of type unsigned or signed integer) which are called minimum 820, maximum 822, and factory default 824. In the FIG. 9B example of the focus distance capability parameter, the minimum 820 contains the value 30, the maximum 822 contains the value 65535, and the factory default 824 contains the value 200.

[0071] It is important to note in the examples given above in FIGS. 9A and 9B that all of the human language readable content is modularized in the text string 806 and when necessary in the list 812. The only part of the value set for the capability parameters examined in FIGS. 9A and 9B which would need changing for the purpose of human language localization would be these text strings 806 and lists 812. For example, if a batch of digital cameras 22 was ordered for use in France, the modularity of the human language content would allow the digital camera's manufacturer to more easily change the capability parameter value sets so that the human language readable content would be in the French language. Alternatively, in a multiple language camera 22, multiple sets of strings can be utilized, where the current set is selected by the current language settings in the camera 22.

[0072] Referring now to FIG. 10, one implementation of the present invention is shown. Assume that the server 12 is running an application for managing a number of photo op transceivers at photo op sites 18(a) and 18(b) at a large primary site 16. Therefore, the server 12 may be connected to several digital cameras 22, e.g., camera 22 A (a) 22(a), camera 22 B 22(b), and camera 22 C 22(c). With the present invention, the application 1010 may then issue the GetCameraCapabilities command to each of the cameras 22(a), 22(b), and 22(c).

[0073] It is important to note that the three cameras 22(a, b and c) in FIG. 10 may each support different ranges or a different list of values for each capability parameter. For example, camera 22a may support only 1× and 2× zoom, whereas camera 22b may support 1X, 2×, and 3× zoom. The capability parameter value sets returned from cameras 22a and 110b will reflect the differences in these and other capabilities of the digital cameras 22. Application 1010 may then receive the capability parameters from the three cameras 22(a, b and c) and responsively send the appropriate camera setting parameters to the respective cameras 22. Thus, the present invention enables the server 12 to be compatible with many types of cameras 22, rather than requiring the primary site 16 to restrict this service to only a select type of camera 22.

[0074] Referring now to FIG. 11, the processing of the GetCameraCapabilities command within digital camera 22 in accordance with a first embodiment of the invention is shown. In initial step 1110, the parameter manager 410 receives the GetCameraCapabilities command. Then, in step 1120, if the GetCameraCapabilities command has its PName field set to four null characters, the implication is that the server 12 is requesting a complete set of the capability parameter data from the digital camera 22. In this case, the unsigned integer ResLength (representing the number of items sent as capability parameters) is sent, in step 1122, as the total number of capability parameters present in digital camera 22. Parameter manager 410 then proceeds, in step 1124, to get the first set of capability parameter data, and, in step 1126, determines if all of the sets of capability parameter data have been retrieved. If not all of the sets have been retrieved, the parameter manager 410, in step 1128, proceeds to get the next set of capability parameter data and then loops back for another decision in step 1126. In this manner the parameter manager 410 retrieves all the sets of capability parameter data. Once the complete set of capability parameter data is retrieved, camera 22 sends the data to the server 12, in step 1130, and the FIG. 11 process ends.

[0075] If, in step 1120, the PName field in the GetCameraCapabilities command was not a set of four null characters, then the parameter manager 410, in step 1138, decides if the value of the PName is for a recognized parameter. If the value of the PName is for a recognized parameter, then the parameter manager 410, in step 1140, sends the ResLength as the number 1, retrieves the capability parameter data corresponding to the value of the PName in step 1142, and sends this data, in step 1144, to the server 12. If the value of the PName is not for a recognized parameter, then the parameter manager 410, in step 1146, returns an error code.

[0076] Referring now to FIG. 12, the processing of the GetCameraCapabilities command within digital camera 22 in accordance with a second embodiment of the present invention is shown. This second embodiment presupposes that the digital camera 22 industry reaches a concurrence about what constitutes a basic core set of standard capability parameters, which will then be common to all digital cameras 22. The processing in this flowchart is analogous to that shown in FIG. 11, with the exception of what happens following step 1220 if the PName field is set to four null characters. In this case, the ResLength is set, in step 1222, to the total number of capability parameters which are not part of the basic core set, i.e., the total number of advanced capability parameters. Then, during steps 1224, 1226, 1228, and 1230, which get and send the capability parameter data, only the capability parameter data for the advanced capability parameters are retrieved and sent to server 12. This retrieving of only those capability parameter data which are not part of the basic core set advantageously saves interface time and system resources such as memory.

[0077] In the FIGS. 11 and 12 embodiments, the server 12 issues the GetCameraCapabilities command. As mentioned during the discussion of FIG. 9, in other embodiments of the present invention, the GetCameraCapabilities command may be issued by a system user activating the buttons and dials of the digital camera 22, or by a special parameter script imported into the digital camera 22 on the removable memory 88 and executed by the CPU 84.

[0078] A method and system for automatically configuring a hand-held camera 22 to improve the quality of an image taken with the camera 22 of a particular subject at a photo opportunity site has been disclosed. The present invention has been described in accordance with the embodiments shown, and one of ordinary skill in the art will readily recognize that there could be variations to the embodiments, and any variations are would be within the spirit and scope of the present invention. In addition, software written according to the present invention may be stored on a computer-readable medium, such as a removable memory, or transmitted over a network, and loaded into any of the devices described herein for execution. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.