System for editing time-based temporal digital media including a pointing device toggling between temporal and translation-rotation modes5790769Abstract A system and method that maps temporal control functions into a six degree of freedom pointing device. The six degree of freedom pointing device controls both transport and view modes within a time-based media editing system and allows a user to toggle between modes without losing visual contact with graphical objects appearing on a video screen. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE 1
______________________________________
Dimension Positive Direction
Negative Direction
______________________________________
X Go to Last Frame
Go to First Frame
Y Stop Playback
Z Mark Keyframe Unmark Keyframe
A Keyframe Decrement
Keyframe Increment
B Frame Decrement Frame Increment
C Play Backward Play Forward
______________________________________
As table 1 illustrates, there remain yet unused dimensions of the device which are not utilized (e.g., Y positive axis, and Z dimensions). These are reserved for application specific commands. For example, within the animation domain, translation in the Z direction of cap 202 will mark or unmark a time frame. Alternatively, the Z dimension can be used to create or delete a key frame. In addition, a "double-tap" on cap 202 (negative Y direction) can be used to issue a command (separate from the single tap for stopping playback). Within the animation domain, tilting cap 202 on the top and bottom (dimension A) will advance or retard the current time unit to the next designated "keyframe" for the active (currently selected) animation objects. Similarly, a quick twisting of cap 202 to the right or left (dimension B) will advance or decrement by a single time unit (or frame). Extended or prolonged twists of cap 202 will result in multiple frame advances or decrements. Sequential frames will be accessed (e.g., 1, 2, 3, 4 . . . ) until a threshold time is reached when the frame access jumps from single frame increments to larger units (e.g., 1, 2, 4, 8, 16, . . . ). This allows for accelerated movement in the time domain. There are a number of methods for making the transition from single to multiple frame advances/retards. In a first method labelled as pure gain, the "gain" or the "force" required to twist the cap indicates the number of frames to increment or decrement. For example, small twists (low force) will transition by single frames. More moderate twists/force will transition by multiple time units (2, 3, 4, . . . ) until the maximum twist/force is reached. This approach is problematic for 6DF pointing devices in which the cap only twists by a +/-4 degree rotation. Accordingly, difficulties arise in discriminating between twists. In a second method labelled as pure temporal, the twist/force values are ignored. The system only detects whether the cap is resting or has been twisted by any amount (larger than noise). Once motion is detected, a timer is started and a single frame is incremented/decremented. If the user persists in holding the cap in the twisted state and the timer exceeds a threshold value, the system switches into multiple frame mode. Within this multiple frame mode, a series of timers is used to advance to each successive step value (e.g., 2, 3, 4 . . . ). In this system, the series of timers can be designed with uniform or non-uniform time intervals. In a further method, the system utilizes a combination of the pure gain and pure temporal methods. In this system, the cap is divided into three uneven regions that translate to the 0-4 degrees of rotation in the positive or negative B direction. Region 1 (0-25%) Advance/retard 1 frame at a time (or slow the frame advance until we are advancing 1 frame at a time. This occurs when going from Region 2 back to Region 1) Region 2 (25-97%) Advance/retard multiple frames at a time (and increase or decrease the current frame advance) until it reaches some defined medium unit (M). Region 3 (97-100%) Advance/retard multiple frames at a time, (and increment the frame advance until it reaches some secondary maximum unit (F). As the above description indicates, maintaining cap 202 in any one of regions 1, 2 or 3 will result in an eventual frame advance/retard equilibrium being reached. For region 1, the equilibrium is 1 frame at a time. For region 2, the equilibrium is M frames at a time. Finally, for region 3, the equilibrium is F frames at a time. As would be obvious to one of ordinary skill in the relevant art, the rate at which the system approaches a given equilibrium point may vary. For example, the rate at which the system approaches the equilibrium of M frames at a time in region 2 may depend upon whether cap 202 previously resided in region 1, region 3 or no region at all. Moreover, the rate of approach towards a particular equilibrium may also depend upon the particular region itself. Ultimately, the particular design choice must be consistent with the goal of providing the user with a seamless environment in which to work. As an exception to the regions defined above, there will always be a 1/4 second delay before any one of Regions 1, 2 or 3 are entered. Regardless of the magnitude of the movement of cap 202 in the B direction, if cap 202 is released within a 1/4 second, only 1 frame will be advance or retarded. This delay allows the user to move one frame at a time with a single thrust of cap 202 without worrying about the relative precision identified by the different regions. Again, this feature allows the user to efficiently use cap 202 to implement the temporal commands. Finally, the mapping of Table 1 translates the tilting of cap 202 to the right or left (dimension C) to playback at normal speed (in the forward or backward direction respectively). In a further embodiment, the playback speed is additionally controlled by the force applied to cap 202. To guarantee a reliable playback at greater than normal speeds, only a sampling of frames is played back. This results because of the time required to generate/compute the next frame. Generally, the playback feature permitted by the temporal control mapping allows for expanded video playback functionality as compared to conventional systems. Specifically, rocking the cap back and forth in the left and right directions, enables one to "rock and roll" back and forth smoothly over a particular segment of frame data without having to explicitly issue a stop playback command when changing directions. Through this rocking, a sequence of frames is played forwards and backwards repeatedly. In effect, this continuous replay allows a user to identify the effect of an editing session on a sequence of frames. If further editing of a graphical object within a frame is required, the user can use pointing device 110. If the editing process required the translation or rotation of a graphical object, then the user can quickly toggle to the view mode and edit the keyframe that proved unsatisfactory based on the previous visual feedback. Again, the benefit of the temporal control mapping of Table 1 is evident in the seamless manner in which a user can edit and review a sequence of frames without breaking visual contact with the graphical objects of interest. The functional components used to implement this seamless process is illustrated in FIG. 3. In FIG. 3, a user provides user input 302 to a 6DF pointing device 106. Based on user input 302, 6DF pointing device 106 generates both raw data and button data. The processing of raw data processing 304 is described in greater detail below. The button data is used to toggle between transport and view modes in toggle usage control 306. Depending upon the specific mode selected, an event is processed by either transport mode event processing 308 or view mode event processing 310. View mode event processing 310 is implemented in a conventional fashion and will not be described in greater detail. In addition to the description that follows, the processing steps in each of elements 304, 306 and 308 are further described in the pseudo code that appears in the Appendix. FIG. 4 illustrates a flow diagram illustrating the processing steps of raw data processing 304. This flow chart corresponds to the ReceiveSpaceMouseEvent procedure of the pseudo code. In a preferred embodiment, the system is implemented as an event-based system. However, a person of ordinary skill in the relevant art will recognize that temporal control mappings are independent of the actual method of receiving inputs from a pointing device. Accordingly, in other embodiments, the system polls the pointing device. The rest of the discussion, however, assumes that an event-based input system exists. In this event-based input system, the data received by raw data processing 304 is a series of 6-tuples corresponding to the six degrees of freedom (X,Y,Z,A,B,C). Each of the 6-tuples is stored as an event in an event-queue that exists as a buffer between the pointing device and the application program. An event consisting of all zeros (0,0,0,0,0,0) is a special event which is termed a null event. In step 404 of FIG. 4, the system determines whether the received event is a null event. If the event is a null event then the current dimension is set to invalid in step 406 and the processing completes at step 408. If the event is not a null event, then the dominant dimension is determined in step 410. Generally, for a given event, many 6DF input devices will sample the data for all 6 dimensions and report this data back to the application. An application often uses all dimensional data simultaneously to update the objects being manipulated by the user. In transport mode, the application program is interested in only one dimension since temporal controls in different dimensions of Table 1 are not implemented simultaneously. Moreover, unintended dimensional data resulting from sloppy manipulation of cap 202 by the user should be discarded. Accordingly, after receiving an event, the system selects the largest dimension and makes that the dominant dimension. If it is different than the current dimension then it places a Null event in the event queue. This technique greatly reduces "noise" and the resulting improperly executed commands. Once the dominant dimension has been identified, steps 412, 414, 418 and 420 are used to classify the current event. In particular, if step 412 determines that the dominant dimension is not equal to the current dimension (i.e., dimension of previous non-null event) then step 414 classifies the current event as a first event. Conversely, if step 412 determines that the dominant dimension is equal to the current dimension, then step 418 is invoked. Step 418 identifies whether the event following the current event in the event queue is a null event. If the next event is equal to the null event, then the current event is labelled as a last event in step 420. This labelling identifies whether the current event is last in a string of events in a single dimension. After the raw data has been processed in accordance with FIG. 4, the usage mode is selected based on the button data from 6DF pointing device 106. The processing based on the selection of the transport mode is now described. Transport mode event processing 308 is illustrated in the flow chart of FIG. 5. This flow chart corresponds to the AnimationProcessSpaceMouseEvent procedure in the pseudo code. As illustrated, step 504 first identifies whether the current event is flagged as a first event. If the current event is flagged as a first event, step 506 initializes the 6DF pointing device prior to the performance of the current event in step 508. Step 506 corresponds to the InitializeSpaceMouse procedure in the pseudo code. If the current event is not flagged as a first event, then the performance of the event in step 508 immediately follows. After the event is performed in step 508, a second determination is made regarding the status of the current event. Specifically, step 510 determines whether the current event is flagged as a last event. If the current event is flagged as a last event, step 512 performs a cleanup of the 6DF pointing device 106 prior to exiting (step 514). Step 512 corresponds to the CleanupSpaceMouse procedure of the pseudo code. FIG. 6 illustrates a more detailed description of the processing within initialization step 506. In this procedure, step 604 first sets the parameters that will be used in subsequent processing (e.g., identifying start and end frames). Next, in step 606, the time of the current event is identified. In step 608, this current time is compared to the previous start time plus the constant Single.sub.-- Multiple.sub.-- Time. The meaning of this comparison may be viewed in light of a sequence of events received from 6DF pointing device 106. An exemplary sequence of events is illustrated in FIG. 7. This sequence of events includes subsequences 710, 720 of events that are separated by at least one null event. Specifically, subsequence 710 includes the span of events from first event 711 to last event 712 inclusive. Subsequence 710 is separated from subsequence 720 by the span of events from null event 732 to null event 733 inclusive. With further reference to FIG. 7, the time associated with a first event 711, 721 in a subsequence 710, 720, respectively, is equal to the start time. If we assume that initialization step 506 is invoked upon the receipt of first event 721 then the current time identified in step 606 is equal to the time of first event 721. This current time is compared to the previous start time (i.e., time of first event 711) plus the constant Single.sub.-- Multiple.sub.-- Time. In a preferred embodiment, the constant Single.sub.-- Multiple.sub.-- Time is set to 0.5 seconds. By this comparison, step 608 determines whether event subsequence 720 is a continuation of event subsequence 710. This determination is important for the frame increment/decrement feature wherein the rate of advancement is variable. If the current time is greater than the previous start time plus the Single.sub.-- Multiple.sub.-- time, then independence between event subsequences 710 and 720 is inferred and the start time is set to the current time in step 610. However, if the current time is less than the previous start time plus the Single.sub.-- Multiple.sub.-- time then, in step 612, the start time remains as the previous start time and the FrameChanged flag is set to true. This FrameChanged flag is used within the Frame.sub.-- Increment selection within the DoSpaceMouse procedure of the pseudo code. After initialization step 506 is completed or the event is not flagged as a first event, step 508 is invoked for actual performance of the event. Step 508 corresponds to the DoSpaceMouse procedure of the pseudo-code. The DoSpaceMouse procedure includes the set of actions to be taken upon receipt of a particular event (e.g., FRAME.sub.-- INCREMENT, STOP.sub.-- PLAYBACK, etc.). After the event is performed in step 508, step 510 determines if the current event is flagged as a last event. If so, step 512 performs a cleanup in accordance with the CleanupSpaceMouse procedure of the pseudo code. While the invention has been particularly shown and described with reference to preferred embodiments thereof, it will be understood by those skilled in the relevant art that various changes in form and details may be made therein without departing from the spirit and scope of the invention.
______________________________________
Appendix (Pseudo Code)
______________________________________
ReceiveSpaceMouseEvent(evt)
if event is Null then set current.sub.-- dimension to INVALID and
return immediately
determine dominant dimension
if dominant dimension is not same as current.sub.-- dimension
then flag current event as FIRST event
Examine event queue to see if Null event is next.
If Null event is next then flag current event as LAST event
ProcessSpaceMouseEvent(dominantDimension)
ProcessSpaceMouseEvent(evt)
if controlling Animation then AnimationProcessSpaceMouseEvent(evt)
else if controlling view then ViewProcessSpaceMouseEvent(evt)
AnimationProcessSpaceMouseEvent(evt)
if evt is flagged as FIRST then call InitializeSpaceMouse( )
DoSpaceMouse(evt)
if evt is flagged as LAST then call CleanupSpaceMouse( )
InitializeSpaceMouse( )
set AnimData to current animation data
Determine start and end frame range for animation
reset playScale to 1
reset Framechanged flag to FALSE
reset keyFrameChanged flag to FALSE
get current time
if current time is greater than PreviousStartTime plus
SINGLE.sub.-- MULTIPLE.sub.-- TIME threshold interval then
set StartTime to current time
else set Framechanged flag to TRUE and do not set
StartTime (i.e., continue using previous value)
›guarantees minimum pause between single frame adjustments!
DoSpaceMouse(evt)
check for valid dimension in event (evt)
Given dominant dimension select one of following actions:
FRAME.sub.-- INCREMENT:
if FrameChanged is TRUE then
if currentTime is greater than StartTime plus
SINGLE.sub.-- MULTIPLE.sub.-- TIME then
go into multiple increment mode:
Stop any animation playback
retrieve current PlayFrame
if evt.dataValue is negative then
PlayDirection = FORWARD
else PlayDirection = BACKWARD
computePlayScale(evt.dataValue)
getNextFrame( )
AN.sub.-- playFrame(PlayFrame, CurFrame)
else
do Nothing
else ›Single frame mode!
if evt.dataValue is positive
PlayDirection = BACKWARD
AN.sub.-- dec.sub.-- frame(AnimData)
else
PlayDirection = FORWARD
AN.sub.-- inc.sub.-- frame(AnimData)
FrameChanged = TRUE
STOP.sub.-- PLAYBACK:
AN.sub.-- playback.sub.-- stop( )
ENDPOINTS:
if (absoluteValue(evt.dataValue) is less than
MOVEMENT.sub.-- THRESHOLD then return
else
if evt.dataValue is positive
set CurFrame = EndFrame
AN.sub.-- end.sub.-- frame( )
else
set CurFrame = StartFrame
AN.sub.-- start.sub.-- frame( )
KEYFRAME:
if KeyFrameChanged is set to FALSE then
if absoluteValue(evt.dataValue) is less than
MOVEMENT.sub.-- THRESHOLD return
else
if evt.dataValue is negative
PlayDirection = BACKWARD
AN.sub.-- dec.sub.-- keyframe( )
else
PlayDirection = FORWARD
AN.sub.-- inc.sub.-- keyframe( )
KeyFrameChanged = TRUE
PLAYBACK:
if evt.dataValue is negative
PlayDirection = BACKWARD
AN.sub.-- playback.sub.-- current.sub.-- rev( )
else
PlayDirection = FORWARD
AN.sub.-- playback.sub.-- current.sub.-- fwd( )
ComputePlayScale(val)
if abs(spaceMouseVal) > MOVEMENT.sub.-- THRESHOLD
numFrames = Last Frame - Start Frame
val = abs(spaceMouseVal)-MOVEMENT.sub.-- THRESHOLD;
accelFactor = Space.sub.-- Mouse.sub.-- Units * SM.sub.-- accel.sub.--
factor;
PlayScale = (int) MAX(1.0, (MIN(0.1, (val/accelFactor)) *
numFrames));
MIN(A, B)
if A is less than B then return A else return B
MAX(A, B)
if A is greater than B then return A else return B
GetNextFrame( )
if PlayDirection is FORWARD
increment the current animation frame by 1 * PlayScale
else
decrement the current animation frame by 1 * PlayScale
›Range check. If at an endpoint, loop around!
if CurFrame is greater than EndFrame set CurFrame to StartFrame
if CurFrame is less than StartFrame set CurFrame to EndFrame
CleanupSpaceMouse( )
redraw any pending graphics
if a PlayFrame exists then
AN.sub.-- playback.sub.-- stop( )
Delete PlayFrame
The following routines are commands/functions provided by the animation
application:
AN.sub.-- playback.sub.-- stop( ) - stop current animation from playing
back
AN.sub.-- playFrame(Frame) - display animation frame "Frame"
AN.sub.-- playback.sub.-- current.sub.-- rev( ) - start reverse playback
from current frame
AN.sub.-- playback.sub.-- current.sub.-- fwd( ) - start forward playback
from current
frame
AN.sub.-- dec.sub.-- frame( ) - decrement animation by 1 frame from
current frame
AN.sub.-- inc.sub.-- frame( ) - increment animation by 1 frame from
current frame
AN.sub.-- end.sub.-- frame( ) - go to last frame in animation
AN.sub.-- start.sub.-- frame( ) - go to first frame in animation
AN.sub.-- dec.sub.-- keyframe( ) - decrement animation until hit previous
keyframe
set from current frame
AN.sub.-- inc.sub.-- keyframe( ) - increment animation until hit next
keyframe set
from current frame
Notes:
SM.sub.-- accel.sub.-- factor is a user settable value between (0.001 and
1.0).
MOVEMENT.sub.-- THRESHOLD is the minimum value needed to execute
the command (i.e,. lower values are considered noise).
Space.sub.-- Mouse.sub.-- Units is a device specific constant.
PlayFrame is a data structure associated with the animation that
indicates how the animation will be viewed.
______________________________________
|
Same subclass Same class Consider this |
||||||||||
