System and method for using a scripting language to set digital camera device features6094221Abstract A system and method for using scripts and selectable feature parameters to configure digital camera device features. The digital camera includes memory storing scripts for providing digital camera device features, an interface enabling a user to modify feature settings, a port connectable to a host computer for modifying or adding scripts to the memory, and a script manager for interpreting the scripts and the feature settings. The digital camera further includes an imaging device for generating a digitized image, and image processors for enhancing the digitized image according to the scripts and the selected feature settings. The digital camera still further includes command handlers for configuring the imaging device and the image processors according to the scripts and the feature settings. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
______________________________________
#HINT.sub.-- 01.CSM (1)
name "Set Exposure Hint Mode"
(2)
declare u:hint (3)
GetCameraStates(1,"hint":3?,hint)
(4)
get hint (5)
1: "AUTO"
2: "PORT"
3: "LAND"
4: "SPRT"
5: "CLOS"
end (6)
SetCameraStates(false,1,"hint",hint)
(7)
SetScriptStatus(1,"hint") (8)
______________________________________
Script manager 410 enables execution and re-execution of the script for modifying and re-modifying the hint mode setting. At any time, a user can instruct script manager 410 to execute the exposure hint feature script for setting or resetting the hint feature. Statement (1) is a comment identifying the DOS name of the script. Statement (2) specifies the script description to be provided upon user request. Statement (3) defines a variable "hint" as an unsigned integer u. A variable type table is shown below in table 1.
TABLE 1
______________________________________
Variable Types
Specifier
Description
______________________________________
u 32 bits unsigned integer.
i 32 bits signed integer.
f 32 bits signed fractional part in signed 15 bits signed
integer and 16 bits fraction.
s 32 bytes characters containing a string up to 31
significant characters terminated by a null character.
n 16 bytes string contains DOS filename, format as
(8 characters).(3 characters) or (8 characters).
p 4 characters string.
b 32 bits of Boolean flags, each bit can be either true(1)
or false(0).
l identifier used to indicate a label name.
______________________________________
Statement (4) is a command for retrieving the previously set value of hint. Statement (5) is a user interaction statement which comprises a command requesting that the user accept or modify the hint mode setting. The list of values and strings separated by colons is the feature value related to the string name for that feature. The user selects a feature by name, and the selected name's value is returned in the variable. Statement (6) ends the list in statement (5). Statement (7) instructs control application 400 to reconfigure the hint mode as the user selects. Lastly, statement (8) communicates modifications to the user via the optional LCD status display. RAM disk 532 is a RAM-based data storage area for storing the compressed light-based image information and is typically organized in a sectored format similar to that of conventional hard disk drives. RAM disk 532 may use a standardized file system enabling the external host computer system (not shown) to readily access stored data. Because the information is actually stored in RAM, the data can be easily and quickly retrieved. System area 534 typically stores system error information for CPU 344 to report upon restarting computer 118 after a system error occurs. FIG. 6A is a block diagram illustrating script manager 410 which includes a function decoder 605, function handlers 610, a tokenizer 620, a command interpreter 625, internal command handlers 630, a programming statement interpreter 635, a command table 640 and a variable table 645. Function decoder 605 is a program routine for managing and decoding script messages received from control application 400. Function decoder 605 forwards the decoded script messages to function handlers 610, which are program routines for managing these messages. If the script message only includes simple instructions (i.e., instruction such as initialize, abort, search for, GetName and Reset which do not require script execution), then function handlers 610 perform the required functions and return the appropriate responses via function decoder 605 back to control application 400. If the script message includes a complex instruction, (i.e., an instruction such as GetCameraStates or SetCameraStates which requires script execution and interpretation), then function handlers 610 forward the message to tokenizer 620 for complex instruction handling. Tokenizer 620 examines the syntax of the statements in the script message to convert the statement's ASCII codes into tokens. Tokenizer 620 passes tokens corresponding to script commands to command interpreters 625 and tokens corresponding to Arithmetic Logic Unit (ALU) statements, Input/Output (I/O) statements, control statements and documentation statements to programming statement interpreter 635. Command interpreters 625 generate data structures representing the tokens. Command interpreters 625 forward the data structures for external commands (i.e., commands which are used system-wide such as GetCameraStates or SetCameraStates and which require computations or information exchange with external components) to external command handlers 420, by passing them back as a response via the function decoder 605. The control application then passes the response to the appropriate external command handler 420 for processing based on the command code. Command interpreters 625 pass data structures for internal script commands (i.e., commands which are dedicated to script manager 410 such as Wait, Write, GetTimeString or GetDateString) are passed to internal command handler 630. To indicate whether a command is an internal command or an external command, each command entry in the command table may include an external/internal flag, command interpreter 625 may include an external/internal command table, or the command values may indicate accordingly. To create a data structure from a script command, command interpreters 625 use command table 640 and variable table 645. An example command table 640 is shown in table 2.
TABLE 2
______________________________________
Command Table
Command Command Parameter Parameter
Name Code Count Type List
______________________________________
"GetCameraStates"
0 .times. 0005
2 1, 16, 0, 0, 0, 0
"GetCameraCapabilities"
0 .times. 0006
2 1, 16, 0, 0, 0, 0
"SetCameraStates"
0 .times. 0007
3 4, 1, 17, 0, 0, 0
"GetCameraStatus"
0 .times. 0008
0 0, 0, 0, 0, 0, 0
______________________________________
The first column indicates command names, the second column indicates command codes, third column indicates the number of parameters in the parameter type send lists, and the fourth column indicates parameter type send list formats. It will be appreciated that other commands and other parameter type lists may be included in command table 2. In conjunction with the parameter type list of command table 2, command interpreters 625 use a parameter type table 3 as follows:
TABLE 3
______________________________________
Parameter Type Table
Parameter
Value Description
______________________________________
cuInteger
(1) integer between 0 and 4G, 32 bit unsigned
integer, a preceding 0x or 0.times. means hex value,
otherwise decimal value.
cInteger
(2) integer between -2G and +2G, 32 bit signed
integer, a preceding 0x or 0.times. means hex value,
otherwise decimal value.
cFixed (3) fixed integer between -32767.99999 . . . and
+32767.99999 . . . , 32 bit signed fractional part in
signed 15-bit signed integer and 16-bit
fraction.
cBitFlags
(4) Boolean and bitflags; 32 bits of Boolean flags,
each bit can be either true(1) or false(0), "0b"
means Boolean, "0x" or "0.times." means hex,
otherwise decimal value.
cPName (6) parameter name.
cName (7) DOS filename; 16 byte string surrounded by
double quotes. The format is an up to 8
character filename, followed by a period, and a
up to three character extension or up to 8
character filename; example "myscript.csm."
cString
(8) a sequence of characters surrounded by double
quotes, max length. is 31, no double quotes
inside the character string.
cPList (16) parameter list.
cPVList
(17) parameter/value list.
cNameList
(18) DOS filename list.
cUList (19) unsigned integer list.
______________________________________
For example, the command "GetCameraCapabilities" parameter list "1,16" specifies that the send list must contain a cUInteger, which is defined as a 32 bit unsigned integer between 0 and 4 G, followed by a cPList which is defined as a parameter list. A cPList is simply a list of any length of pName type values. Command interpreters 625 use tables 2 and 3 to compare predefined script formats with actual scripts for performing script command error checking. Error checking is defined in greater detail with reference to FIGS. 7 and 8. Generation of a data structure by command interpreters 625 is described in detail with reference to FIGS. 7-10. An example variable (or parameter) table is illustrated in table 4 as follows:
TABLE 4
______________________________________
Variable Table
Variable Name Type Value
______________________________________
"count" 1 0
"valu" 3 1.25
______________________________________
External and internal command handlers 420 and 650 accordingly send image processor parameters to image processors 430 for setting camera 110 software-based features, or camera parameters to the camera control system 440 for setting capture-related features. Although not shown, command handlers 420/650 may send I/O parameters to I/O interface 348 for setting I/O features or other system or control parameters to other managers for setting other camera 110 features. The operations of external command handlers 420 and internal command handlers 630 are described below in greater detail with reference to FIG. 7B. Programming statement interpreter 635 uses variable table 645 to process a programming statement such as control, I/O, ALU or documentation statements. For example, a programming statement may be a definition, a mathematical expression, a logical expression, etc. If one of the script manager 410 components including the tokenizer 620, the command interpreters 625, the programming statement interpreter 635, the internal command handler 630 locates an error in the script message, then the script manager 410 component sends an error message to an error handler 615 of function handlers 610. The error handler 615 recognizes error codes in the error message, stops script execution and passes an appropriate error message responsively back via function decoder 605 to I/O interface 348. FIG. 6B is a block diagram illustrating the operations of camera 100. Imaging device 114 captures and converts an image to a digitized image, and stores the digitized image in memory 354. Image processor 430 takes the raw digitized image and adds image enhancements such as contrast adjustment, sharpening, etc. Image processor 430 stores the enhanced image again in memory 354. The operations of imaging device 114 and of image processors 430 can be controlled by active scripts and script feature settings. While executing a script, the script manager 410 retrieves and displays the script feature setting currently-stored in the script data base 536 for the selected script. The script manager 410 can interact with a user via I/O interface 348 to enable modification or the currently-stored script feature setting in order to modify the camera device feature. Script manager 410 generates data structures representing commands within the script, as described below with reference to FIGS. 7A and 8-10. Script manager 410 sends the data structures to external/internal command handlers 420/650, which accordingly send image processor parameters to image processors 430 for setting camera 110 software-based features, camera parameters to camera control software for setting capture features, or other system or control parameters to other appropriate managers. It will be appreciated that a programmer may use host computer 120 to add additional scripts to script data base 536, for adding additional functions and features to camera 110. FIG. 7A is a flowchart illustrating a method 700 for managing script 536 statements. Method 700 begins in step 702 by tokenizer 620 receiving and parsing a statement. If tokenizer 620 in step 704 determines that the program statement is not a script command, then tokenizer 620 sends the tokens to programming statement interpreters 635, which in step 706 analyze the statement. Programming statement interpreter 635 in step 708 executes the program statement conventionally. Examples of these statements include control, I/O, ALU and documentation statements. Tokenizer 620 in step 710 determines whether there is another statement in script 536. If so, then tokenizer 620 returns to step 702. Otherwise, method 700 ends. If tokenizer 620 in step 704 determines that the program statement is a script command, then tokenizer 620 sends the token to command interpreters 625 which in step 712 retrieve the command code and the parameter list from the command table 640 illustrated above in Table 2 described with reference to FIG. 6. Using the command code and the parameter list, command interpreters 625 in step 714 scan the parameters and build a data structure. The step of building a data structure from a command is described in detail with reference to FIG. 8. Command interpreters 625 in step 716 forward data structures representing external commands via a response through the function decoder 605 back to the control application 400 to external command handler 420 or data structures representing internal commands to internal command handlers 630 for command execution. Command execution is described below with reference to FIG. 7B. Command interpreters 625 in step 718 receive responsive data returned from command handlers 420 or 650. Command interpreters 625 in step 719 examine the data returned to determine if the data indicates an error. If so, then command interpreters 726 jump to step 726 to report the error. Otherwise, command interpreters 625 continue with step 720 to determine whether the current command includes a receive list. If not, then method 700 returns to step 710. If so, then command interpreters 625 in step 722 examine the expected parameter type in the receive list. If the expected parameter type is a constant, then command interpreters 625 determine whether the responsive data matches the expected parameter type. If not, then command interpreters 625 inform the error handler 615, which in step 726 reports the error and method 700 then ends. Otherwise, command interpreters 625 in step 728 advance four bytes for an integer value, sixteen bytes for a DOS name or thirty-two bytes for a character string to index to the next parameter. Command interpreters 625 in step 730 determine whether another parameter remains in the receive list. If so, then command interpreters 625 return to step 722. Otherwise, command interpreters 625 return to step 710. If command interpreters 625 in step 722 determine that the parameter type is a variable, then command interpreters 625 in step 731 determine if the variable has been defined. If not, then method 700 jumps to step 726 to report the error. Otherwise, command interpreters 625 in step 732 stuff the received data value into the variable and proceed to step 728 to index to the next parameter. If command interpreters 625 in step 728 determine that the parameter type is a number N followed by the symbol "?", then command interpreters 625 in step 734 extract the value N. Command interpreters 625 in step 736 index past N.times.4 bytes of responsive data, i.e. N parameters. The type "N?" is used to index past parameters which are known to be unnecessary for performing the current instruction. For example, the command "GetCameraStates(1, `fmod`:3?,abc)" requests the current state of camera 110 focus mode. The responsive data may be "1,`fmod`,1,25" where "25 represents the current focus mode state. Parameter "3?" causes command interpreters 625 to jump over the first three parameters "1,`fmod`,1", and on the next loop stuff the value "25" into the variable "abc." Thus, the function "N?" eliminates examination of parameters known to be unnecessary. Command interpreters 625 then proceed to step 734. FIG. 7B is a flowchart illustrating details of the method 716 for executing a command. Method 716 begins with step 740 by command interpreters 625 determining whether the command is an external command or an internal command. If the command is an external command, then command interpreters 625 in step 742 sends the data structure (which represents the command and the send list) and the response code to function decoder 605, which decodes and forwards the data structure and response code to control application 400. Control application 400 in step 744 sends the data structures to the appropriate external command handler 420. The appropriate external command handler 420 in step 746 executes the command data structure and in step 748 forwards the appropriate response data back to the control application, which in turn calls the script manager 410 with the result. The function decoder 605 sends the response data back to command interpreters 625. Method 716 then ends. If in step 740 command interpreters 625 determine that the command is an internal command, then command interpreters 625 in step 750 sends the data structure (which represents the command and the send list) to the appropriate internal command handler 630. Method 716 then jumps to step 746. FIG. 8 further illustrates step 714 of building a data structure. Step 714 begins in step 805 by command interpreters 625 creating a command data structure header. Command interpreters 625 in step 810 get the next parameter and in step 815 determine the parameter type. Command interpreters 625 in step 820 determine if the parameter matches the expected parameter type. For example, by examining table 2 and table 3, command interpreters 625 expect the command "GetCameraStates" to be followed by a send list comprising a cUInteger (1) in turn followed by a cPList (16). If the selected parameter is not a member of the expected parameter type, then command interpreters 625 forward a message to error handler 615, which in step 825 reports the error via a response through the function decoder 605 to the control application 400. The control application reports the error to the user. As illustrated by jump symbol "A," method 700 then ends If the selected parameter is a member of the expected parameter type, then command interpreters 625 in step 830 determine whether the parameter is a constant or a variable. If the parameter is a variable, then command interpreters 625 in step 833 determine if the variable is defined. If not, then method 714 jumps to step 726 (FIG. 7A) to report the error. Otherwise, command interpreters 625 in step 835 retrieve the value of the variable. If the parameter is a constant, then command interpreters 625 convert the ASCII constant to a value. In either case, command interpreters 625 in step 845 append the value to the send data structure. Command interpreters 625 in step 850 increment the data structure size in the header by 4, 8 or 16 bytes depending on the data type. Command interpreters 625 in step 855 determine if the retrieved parameter is the last parameter. If so, then method 714 ends. If not, then method 714 returns to step 810. FIG. 9 is a block diagram illustrating a command send data structure 900, which comprises a header 905 and appended parameters 930, generated by command interpreters 625. Header 905 comprises a command code 910, a command data length 915, a command data pointer 920 and a deallocation routine pointer 925. Parameters 930 may include a plurality of appended parameters 935-945. For the example command "GetCameraStates(1,`fmod`:3?,fmod)", command interpreters 625 retrieve the command code "0.times.0005" for "GetCameraStates" as command code 910, set command data length 915 to zero and place the value nil into command data pointer 920. Command interpreters 625 append an address of the subroutine which will dispose of the data structure as a deallocation routine pointer 925. Command interpreters 625 retrieve the parameter "1" and determine that it matches the expected parameter type cUInteger. Since the parameter is a constant, command interpreters 625 append the 32-bit parameter value representing "1" to the data structure as parameter #1 data 935. Command interpreters 625 modify command data pointer 920 to point to parameter #1 data 935, and increment command data length 915 by four bytes. Command interpreters 625 retrieve the parameter "fmod" and determine that it matches the expected parameter type cPList. Since the parameter type is a parameter name constant, external command interpreters 625 append the constant "fmod" to send data structure 900 as parameter #2 data 940. Command interpreters 625 increment command data length 915 by another four bytes. In this example, there are only two parameters and command data length is eight bytes. FIG. 10 is a block diagram illustrating a command retrieve data structure 1000, which comprises a header 1005 and return parameters 1030. Header 1005 comprises a command error code 1010, a command data length 1015, a command data pointer 1020 and a deallocation routine pointer 1025. Return parameters 1030 may include parameter #1 data 1035 and parameter #2 data 1040. Any number of parameters may be included. As described in FIG. 7A, command interpreters 625 receive the command receive data structure 1000 as responsive data returned from either external command handlers 420 or internal command handlers 630. Command interpreters 625 process the receive list "3?,fmod" with the data structure 1030 values. The foregoing description of the preferred embodiments of the invention is by way of example only, and other variations of the above-described embodiments and methods are provided by the present invention. Components of this invention may be implemented using a programmed general purpose digital computer, using application specific integrated circuits, or using a network of interconnected conventional components and circuits. The embodiments described herein have been presented for purposes of illustration and are not intended to be exhaustive or limiting. Many variations and modifications are possible in light of the foregoing teaching. The system is limited only by the following claims:
|
Same subclass Same class Consider this |
||||||||||
