System and method for providing zooming video capture

[0002] This application is related to U.S. patent application Ser. No. 09/211,666, entitled “Polymorphic Event Handling for Zooming Graphical User Interface,” filed Dec. 14, 1998; U.S. patent application Ser. No. 09/211,280, entitled “Interchangeable Pick Handler for Zooming Graphical User Interface,” filed Dec. 14, 1998; U.S. patent application Ser. No. 09/211,669, now U.S. Pat. No. 6,249,290, issued on Jun. 19, 2001 entitled “Object Oriented Zooming Graphical User Interface,” filed Dec. 14, 1998; U.S. patent application Ser. No. 09/223,934, entitled “Click-Through Pick Method For Group Objects In A Zooming Graphical Interface,” filed Dec. 31, 1998; U.S. patent application Ser. No. 09/240,416, entitled “Zooming Information Space Grid For Graphical User Interface,” filed Jan. 29, 1999; U.S. patent application Ser. No. 09/240,905, entitled “Singleton/Universe Based Zooming Space For Graphical User Interface,” filed Jan. 29, 1999; U.S. patent application Ser. No. 09/245,205, entitled “Apparatus and Method For Cropping An Image In A Zooming Graphical User Interface,” filed Feb. 5, 1999 and U.S. patent application Ser. No. 09/239,652 entitled “System And Method For Providing Zooming Video,” filed Jan. 29, 1999. All of the referenced patent applications are assigned to Sony Corporation of America, the assignee herein, and are incorporated herein by reference.

[0003] The present invention relates generally to the field of image display methods and apparatus and more particularly to the application of image zooming technologies to video display.

[0004] With the substantial increase in processing power for personal computers realized in the recent past, it has become possible for such computers to generate and display very complex graphical images, including video images. However, due to various processor and memory limitations, the display of the video image at the computer is typically restricted to a small portion of the available display area—e.g., an area of 320×240 pixels. It would often be desirable from a user's perspective to be able to view the received video image at a larger size. While a limited re-sizing capability is known in the present art, it does not provide a smooth transition from one size to another, and does not permit a concurrent panning and re-sizing of the image.

[0005] A method is provided for transforming a video signal provided to a computer into an object in a zooming universe established in such computer, which zooming object may be enlarged and panned by manipulation by a user via a computer input device. In particular, a video signal is captured in a known video capture system operating with such a computer. At the same time a zooming engine is enabled on the computer and a zooming universe is enabled therefrom. Frames of the video signal being played on the computer video capture system are copied to a video object in the zooming universe and displayed there. By manipulation of the parameters of the bounding box enclosing the zooming video object, through use of a computer input device, the user is able to scale and pan the video image in the zooming universe display up (or down) to a desired viewing size and perspective.

[0006] However, because the interlaced video signal does not display well using a direct video surface, it is necessary to copy the received video frames to a video overlay surface, where the interlace problems are largely eliminated. But an image on such an overlay surface cannot be scaled smaller than the original size of the video image from the video frame grabber. Therefore, to effect a smooth scaling throughout a zooming range, and with the recognition that, at and below the relatively small image size as provided by the video frame grabber, the problems with displaying an interlaced frame on a direct video surface are relatively inconsequential, the invention operates to swap the displayed image between the video overlay surface and the direct video surface at the point where the scaled image size reaches the original size of the video image. In an alternative embodiment, to provide a smooth transition in that surface swap, the video signal is cached for the surface to be swapped to during a short interval preceding the swap.

[0007] A better understanding of the present invention, and additional objects, features and advantages of the invention, will be apparent to those skilled in the art upon reference to the following detailed description in conjunction with the accompanying drawings, in which:

[0008] FIG. 1 is a schematic diagram illustrating a conventional computer system.

[0009] FIG. 2 is a block diagram illustrating a computer system having an embodiment of a zooming engine in accordance with the present invention.

[0010] FIG. 3 is a block diagram illustrating an embodiment of a zooming engine in accordance with the present invention.

[0011] FIG. 4 is a schematic diagram illustrating various zooming display objects, including a zooming video object, in a zooming space in accordance with the interface of the present invention;

[0012] FIGS. 5A, 5B and 5C provide an illustration of a video image as might be displayed without any scaling, and zoomed in and out according to the method of the invention;

[0013] FIGS. 6A and 6B are flow charts illustrating processes of the method of the invention.

[0014] Through the use of a computer peripheral known as a video frame grabber, it is possible to capture and view full motion video in a window of the computer. The input video signal to the frame grabber can be provided by a VCR, a camcorder, or other known sources of such video signals. The current art, however, does not provide effective means for manipulation of the video frames from the video frame grabber, such as zooming or panning of the image displayed.

[0015] A zooming video capture interface according to the method of the invention is able to display video frames captured by the frame grabber at multiple levels of magnification. The zooming video capture interface constructs graphic representations of the video objects, which representations the user is able to magnify, reduce and pan. Magnification, also know as “zooming in,” displays an object or group of objects in greater size and/or detail. Reduction, also know as “zooming out”, displays an object or group of objects in smaller size and/or less detail.

[0016] In a preferred embodiment, the instructions implementing the zooming video capture interface of the invention are coded in JAVA®. Of course, other embodiments may be implemented using any platform independent language, such as PERL™, or any platform dependent language, such as C++ or Fortran.

[0017] Prior to discussing in detail the zooming video capture methodology of the invention, it is desirable to briefly discuss the computer environment in which the invention operates, as well as the zooming engine which provides the fundamental infrastructure for the operation of that methodology.

[0018] Computer Architecture

[0019] FIG. 1 illustrates an exemplary computer system 100 which is adaptable for implementing the zooming video interface system according to the invention. The computer system 100 includes a main housing 120 connected to a monitor 130 and interactive input devices, in this example a keyboard 150 and mouse 160, which include switches 155 and 165 having positive on and positive off positions for generating signals to the system 100. The main housing 120 includes various items (not shown in FIG. 1) that are typically used in a computer system 100. By way of example, these elements may be a processor, ROM and RAM memory, cache memory, a hard disk storage device, a floppy disk drive, a storage tape drive, graphics and audio cards, a network interface card, a video frame grabber card and a power supply, all interconnected using a conventional architecture.

[0020] A computer system 100 configured as such provides visual output through a monitor 130 and audio output through speakers (not shown), and receives input through a keyboard 150, mouse 160, and possibly a microphone (not shown). The user can interface with the computer system 100 in conventional fashion, such as by positioning the screen cursor on a desired object using an interactive input device, such as mouse 160, and clicking (depressing a button of) the interactive input device, such action providing input to the system and identifying/selecting the desired object for further activity. For example, the user may use the mouse 160 to move a cursor about a graphical display and position the cursor in relation to a particular image on the graphical display shown on the monitor 130. The user may then provide input to the system using the mouse 160 by a double click of a mouse switch 165 while the cursor so positioned, such action typically providing information to the system in respect to desired action related to the image. The display and functionality may be referred to as a graphical user interface.

[0021] Although the illustrated computer system 100 is of the desktop type, it is noted that the present invention is equally applicable to other computer system types, such as the lap-top type and palm type. Additionally, although the preferred embodiment implements a mouse for moving a cursor and providing input, it is noted that various technologies for accepting input and displaying output will evolve, and that such evolving technologies are contemplated by the present invention. For example, instead of mouse and keyboard commands, audio commands may ultimately be used to update the display. These and other alternatives will be recognized by the ordinarily skilled artisan.

[0022] The block diagram of FIG. 2 illustrates an embodiment of a computer 200 (the portion of the system 100 typically found in the main housing 120) that includes a CPU 202, ROM 204, memory 206, data storage device 208, video card 210, audio card 212, keyboard/mouse controller 214, video frame grabber card 216 and network interface 218, each coupled to a bus 224 in conventional fashion. The CPU 202 is a conventional processor, such as the PENTIUM® type provided by Intel Corporation of Santa Clara, Calif. The CPU 202 executes instructions, such as those provided in ROM 204 and/or memory 206. ROM 204 is a read only memory, which retains its stored information even while it is disconnected from a power supply. The ROM 204 may, for example, store instructions for a boot up sequence. Memory 206 is preferably volatile memory for storing instructions and information used during ordinary operation, such as those provided in the computer operating system. The data storage device 208 provides long term data storage, and is preferably a magnetic or magneto-optic hard disk device. The video card 210 and audio card 212 respectively provide the interface between the computer 200 and the monitor and speakers. The keyboard mouse controller 214 interfaces the computer 200 and the keyboard and mouse that are used to provide input to the computer 200. Video Frame Grabber card 216 operates to capture full motion video from a video source such as a VCR or cancorder, for display in a window of Display 130. The network interface 218 is a conventional network interface card that interfaces a local network line and the computer 200. The network interface card may be a conventional ethernet card, or may be a multipurpose interface for communication over a ethernet, ISDN and/or other networks. Access to the Internet can be provided through the network interface 218.

[0023] It is noted that a computer 200 may include different items than those noted in the described embodiment. For example, I/O ports for interfacing with printers and plotters, a floppy disk drive, a CD ROM drive, and various other features may be included, and various elements may be excluded. Also, although Internet access is described in connection with a network interface card, a modem connected to a conventional phone line can be used to access the Internet, such as through an internet service provider. The ordinarily skilled artisan will recognize the various alternatives for the computer 200.

[0024] Still referring to FIG. 2, the memory 206 also will include an operating system 220 and a zooming engine 222. The operating system 220 is a program that is typically loaded from the long term data storage device 208 (e.g., hard disk) to the main memory 206 during a boot up sequence. The operating system 220 manages the other programs in the computer, which are referred to as applications, and includes particular instructions and operations that can be used by the applications, either directly or through an application program interface. The operating system 220 also handles exchanges to and from devices connected to the computer (e.g., printers, disk drives, etc.), manages memory use, and allocates computing resources in multitasking environments.

[0025] The zooming engine 222, which will be described with more particularity below, includes instructions for updating the display 130 according to user and system input. For example, the zooming engine 222 manages the various zooming objects that may be provided in a zooming space, determines the available display space, determines which zooming objects are visible in the available view space, and responds to various events to update the display, such as mouse and keyboard events which arise in response to the user's navigation of the zooming space. Preferably, the zooming engine 222 is provided as software, although all or part of the zooming engine 222 may be provided as hardware, firmware, or a combination of software, hardware and firmware.

[0026] In the preferred embodiment, the system 100 utilizes a known computer operating system, such as UNIX®, WINDOWS95® or WINDOWS98®, found resident in area 220 of memory 206. When implemented as a set of instructions for a computer processor, the zooming engine used by the invention is preferably written in the JAVA® programming language, and the instructions, including the JAVA® virtual machine, can be found resident in area 220 in the memory 206 of the system 100. The JAVA® virtual machine, an abstract specification for a computing device, operates as an interface between the JAVA® application and the specific computer platform (e.g. Intel, Apple) on which the application is to be run. As is known in the art, JAVA® is a platform independent, object oriented programming language, the details of which are fully described by Sun Micro Systems, Inc. at its Internet website. The Sun Micro Systems website on the World Wide Web (WWW) can be located using its Uniform Resource Locator (URL), wwwjava.sun.com, and descriptive documentation concerning JAVA®, the JAVA® Development Kit and related products may be obtained at this website.

[0027] Alternatively, the system may include hardware and software operable to permit communication with the World Wide Web or with a local network. In that case, the software would include a JAVA® enabled browser, such as Netscape Navigator™. This enables the system 100 to run the instruction set received through the network interface 218 from a website where the platform independent language instruction set resides.

[0028] Zooming Engine

[0029] The block diagram of FIG. 3 illustrates an embodiment of a zooming engine 222 architecture for facilitating zooming video interface functionalities such as those contemplated by the method of the invention. Preferably, the zooming engine 222 operates with an operating system 220, as described above, and includes various instructions which are executed by a CPU for providing the zooming graphical user interface functionality.

[0030] Additionally, although the zooming engine 222 may operate in any environment which facilitates the execution of instructions, including platform dependent ones, the preferred zooming engine 222 embodiment is generally platform independent, running on a virtual machine 302. The preferred zooming engine embodiment is implemented in the Java programming language and the virtual machine (VM) 302 is a Java VM. Interfaces 304 and 306 between the zooming engine 222 and operating system 220 may also be provided, such as those for rendering graphics 304 and video 306 using the operating system 220. These interfaces 304, 306 may comprise conventional facilities for interfacing with the operating system 220 such as dynamic link library (DLL) files, and/or the Microsoft DirectDraw and DirectShow SDK for the WINDOWS environment.

[0031] The zooming engine 222 includes a universe module 308 which is the highest level module corresponding to a given zooming space. The universe module 308 contains a view module 310, an object manager module 312, and an event manager module 314. These modules 308-314 include instructions which, when executed, perform the various functions described in connection with them. Although the modules 308-314 (as well as the additional sub-modules directly or indirectly associated with them) will likely be provided as software, their functionality may also be produced by using hardware or firmware. Preferably, the modules 308-314 are implemented using Java singleton class definitions which allow for only one instance of a class to be created per universe.

[0032] The illustrated universe module 308 and all of its sub-modules pertain to a single zooming space. Multiple instances of zooming spaces may be provided, as the multiverse 328 may contain numerous zooming spaces which would each comprise its own universe module 308 and appropriate sub-modules. Such a multiverse facility is described further in the above referenced application Ser. No. 09/240,905, entitled “Singleton/Universe Based Zooming Space for Graphical User Interfaces.”

[0033] The object manager module 312 controls all of the objects in the zooming space, which zooming objects are defined by the zooming object module 316, including its subclasses, such as circle module 318, rectangle module 320, text module 322, and video player module 324 . The branches, such as those shown between the zooming object module 316 and the subclasses 318-324, indicate a one-to-many relationship. For example, there may be more than one circle module 318, with each module 318 inheriting the characteristics of the superclass zooming object module 316.

[0034] The zooming engine 222 may interface with various operating systems 220. Where this is the case, the graphics module 323 interfaces the zooming engine 222 to the appropriate OS rendering interface 304. Similarly, there may be various different video player modules 324, which in turn may be ported to various operating system interfaces.

[0035] The event manager module 314 produces event objects 326 responsive to system events (arrow 330) such as mouse and keyboard events initiated by the user. The event objects 326 are then passed, along with event handling information, to the view module 310 (arrow 332) and/or the zooming object module 316 (arrow 334) so that the display can be appropriately updated.

[0036] The view module 310 contains at least one set of zooming objects selected from those in the zooming space, through request and receipt arrow (336) of information about the zooming objects from the object manager 312. Typically, the view module 310 contains those zooming objects which reside in the main zooming view. They may be associated to the same index used by the object manager 312. This allows the various objects in a view to be separately organized in the view module 310, so that separate calls to the zooming object module 316 are not required. For example, the view module 310 can issue commands (arrow 338) which are propagated through the object module 316 and any relevant subclass modules to affect rendering of many zooming objects contained in the main zooming view.

[0037] Individual or groups of zooming objects may be separately targeted for update responsive to event information passed directly to the zooming object module 316 by the event manager 314, and rendering commands would be more directly issued by the objects, such as is depicted by arrows 340-344. An example of such an update could be responsive to user selection and manipulation of a single object.

[0038] Zooming Space

[0039] FIG. 4 is a schematic diagram illustrating various geometric objects representing information contained in a zooming space 402, including zooming objects 406, 408, 410, 412 and 414. The outer boundaries of the figure, 402, represent the zooming space. While the edges of the zooming space 402 are shown for ease of illustration, they may not necessarily be part of the zooming space. Included in the zooming space 402 is an available view space 404. Typically, the available view space 404 is dictated by the display device 130 and its configuration. Thus, the available view space 404 may be the maximum display area for the display device 130. Additionally, in an environment where the zooming engine 222 works in conjunction with an operating system 220, the available view space may be related to features provided by the operating system 220. For example, the usable display area for an open window in a WINDOWS operating system 220 may be the available view space 404. Thus, the available view space 404 can change by using conventional controls for maximizing the window, or altering the locations of the sides of the window.

[0040] Objects available for zooming in zooming space 402 include a circle 406, triangle 408, star 410, a square 412 and a video image 414, such objects being graphical objects having particular sizes, shapes and colors. Video objects may comprise standard video formats including MPEG, AVI, Streaming Video, etc. The above listed zooming objects and object formats are for illustrative purposes and are by no means exhaustive. The ordinarily skilled artisan will recognize the various alternatives objects and object formats that can be readily substituted for those listed.

[0041] The zooming space 402 includes all of the zooming objects 406-414 that may be viewed by the user during navigation of the zooming space 402. However, all of the zooming objects 406-414 might not be visible at a given time, since the available view space 404 may not be large enough to encompass the entire zooming space 402. For example, here the available view space 404 covers the triangle 408, the circle 406 and the video object 414, but other objects may come into or out of view based on the scale of objects in view and the panned location.

[0042] In the zooming space, users are able to interact directly with graphical objects by selecting an object with a mouse. This action produces an event in the zooming engine, initiating an intersection test on each visible object in the universe. Primitive objects, such as lines, rectangles or ellipses, perform a simple mathematical test to check if the point under the mouse cursor intersects the object's geometry. If an object, as defined by its bounding box, is intersected by the point under the mouse cursor, the user is able to perform additional operations on the intersected object. Since the zooming object class has no geometry of its own, a variety of shaped bounding boxes can be chosen to determine whether an intersection between the bounding box and a point under the mouse cursor has occurred, although the preferred bounding box is a rectangle.

[0043] The user can navigate the zooming space 402 in three dimensions. Generally, movement in the X and Y directions, corresponding to the planar surface of the display device available view space an be referred to as panning, while navigation in the Z direction can be referred to as “zooming”. Navigation in the Z direction (into or out of the display screen) causes the perspective of the available view space 404 to appear to zoom into or away from the zooming objects in the zooming space 402.

[0044] Navigation into the display screen (the +z direction) causes the zooming objects to appear to become closer to the viewer, and thus larger. This may be referred to as “zooming in.” This also causes the perceived separation of the zooming objects to increase, which may cause a zooming object to leave the available view space 404. To “zoom in”, the user marks information desired for viewing in greater detail with a cursor and operates the input device in a manner to cause the desired information to be magnified.

[0045] Navigation out of the display screen (the −z direction) causes the zooming objects to appear to become further away from the user, and thus smaller. This may be referred to as “zooming out.” Of course, as the user zooms out, the perceived separation of the zooming objects decreases as well, and additional zooming objects may come into the available zooming space 404. To “zoom out”, the user marks information desired for viewing in lesser detail with a cursor and the desired information is reduced in size, thereby displaying a larger portion of the chosen information. All zooming operations can be responsive to conventional interactive input commands. For example, depressing the left mouse key can cause a zoom in, and depressing the same button with the keyboard shift key depressed can cause a zoom out.

[0046] FIGS. 5A through 5C provide an illustration of a displayed image for a video being operated on according to the invention. Each of the illustrated images is a capture of a view on the same Zooming Universe. Zooming Video Image1, shown in FIG. 5A, displays what the user would see as the un-altered output of the video frame grabber. Zooming Video Image2, shown in FIG. 5B, illustrates the same video image zoomed in a bit. Illustratively, the user executes the zoom-in function by placing the mouse cursor anywhere in the viewed image and pressing the left mouse button. Note that the location that is zoomed in is the location of the mouse cursor. Zooming Video Image3, shown in FIG. 5C, illustrates the same video image zoomed out. Illustratively, the user executes the zoom-out function by placing the mouse cursor anywhere in the viewed image and pressing the shift key and the left mouse button simultaneously.

[0047] Zooming Video Capture Methodology

[0048] In a preferred embodiment of the methodology of the invention, a video signal is provided to a video capture system operating in a computer and caused to play on a video player established in the native code of the computer operating system. A zooming engine, which is preferably established in the JAVA programming language, will also have been initiated in the computer, and a zooming universe for such zooming engine is caused to be displayed at the display device for the computer (or in the active window for such display). For a preferred embodiment, the video player will be Microsoft DirectDraw, and the video frames will be copied to a memory area known as a DirectDraw surface or to an overlay surface established with reference thereto.

[0049] In the discussion following of the methodology of the invention, it is noted that the term “Zooming Video” is intended to denote a graphical object which displays video. Such a “Zooming Video” object can be continuously and uniformly scaled while the video is playing. The “Zooming Video” can also be panned continuously while playing. The term “Zooming Video Capture” is intended to denote a “Zooming Video” object which is receiving video data from an external source. [Note that in the companion cross-referenced application entitled “System And Method For Providing Zooming Video,” Ser. No. 09/239,652, filed Jan. 29, 1999, a methodology is disclosed and claimed for providing continuous scaling and panning of video objects which are derived from encoded and digitized video streams provided as a discrete digital files and stored in a storage medium accessible to the computer.]

[0050] The Zooming Video Capture methodology of the invention is represented, in a preferred embodiment, by two abstract java classes ZVideoPlayer and ZVideoDevice. Specific subclasses of each of those classes will be established for particular video capture devices and video libraries.

[0051] In a preferred embodiment of the invention, when a ZVideoDevice class is constructed, a C++ function is called which initializes the capture device and its associated video port. The ZVideoPlayer is then attached to the capture device by calling the setVideo function, passing the ZVideoDevice instance as a parameter. This invokes another C++ function which creates a DirectDraw VideoPort and attaches a DirectDrawSurface to receive the output of the video port.

[0052] The interface to the ZVideoPlayer gives users the ability to play, pause and stop the video stream. These calls, representing signals from a user-input device, invoke C++ functions which tell the DirectDrawVideoPort to start and stop the video data input.

[0053] Once the captured video data is on the DirectDrawSurface, it is copied to the Zooming Universe off-screen surface. If the ZVideoPlayer is playing an animation request of the type described in the companion cross-referenced application entitled “System And Method For Providing Zooming Video,” Ser. No. 09/239,652, filed Jan. 29, 1999, the damage/repaint methodology described in that application is applied. Each time a ZVideoPlayer is damaged, its paint method is called, causing the DirectDrawSurface containing the video data to be copied to the correct location on the Zooming Universe off-screen surface.

[0054] Because of the interlaced character of the video signal received by the computer's video port, the type of video player surface used in displaying the captured video has a great impact on the quality of the video image. In general, such interlacing results in significant distortion when displayed using the normal DirectDrawSurface, particularly at larger scalings of the image. To overcome this distortion problem, a video overlay surface can be used which will substantially improve the quality of the displayed image. However, the use of such video overlay surfaces is also problematic in certain respects. First, it is not possible to overlay other Zooming Objects on top of a video overlay surface. In addition, an image displayed on such a video overlay surface cannot be scaled below the size of the original image from the video frame grabber card, typically 320×240 pixels. This scaling limitation in respect to the overlay surface will of course preclude a continuous scaling of images to sizes less than the original image size, and such sub-size scaling may be desired by a user. In addition, certain panning operations for an image displayed on the overlay surface can reach a critical point, again related to the original image size, which would cause the zooming/panning application to crash.

[0055] With the recognition by the inventors that the interlace distortion resulting from display of the captured video image on a normal DirectDrawSurface is visually much less apparent at and below the relatively small image size output from the video frame grabber card, the invention causes the image to be displayed using a video overlay surface at scale magnitudes at and above the original image size, and further causes the displayed image to be swapped between the video overlay surface and the normal DirectDrawSurface at the point where the scaled image size reaches the original size of the video image from the video frame grabber card. In an alternative embodiment, to avoid a flicker that might otherwise be visible when switching between surfaces at the transition point, the video signal is captured to both the normal and the overlay surfaces when scaled to within approximately 10 pixels of the transition point.

[0056] As each video frame is copied to the surface on which the video frame is being stored, the copied frame is then transformed to a video object in the Zooming Universe, that video object representing a surface in the Zooming Universe on which the video frames are displayed. By manipulation of the dimensions and position of a bounding box enclosing the video object in the Zooming Universe, using conventional input devices, the scale of that object will be enlarged so as to provide the user with a panned and magnified image of the running video signal.

[0057] In FIG. 6A, the methodology of the invention is depicted in flow chart form. As can be seen from the figure, the Zooming Video Capture operation of the invention is divided, at interface 601, between functions that are carried out in the zooming engine, which is implemented in JAVA, and functions that are carried in the Native Code for the operating system of the computer. The Zooming Engine operates under the control of the JAVA Virtual Machine 600, which creates the Zooming Video Capture object 602. When the Zooming Video Capture object is told to play, a call is made to the native code telling the video port to begin data flow. Video pixel information from the DirectDraw Video Port 603 then flows to Native Video Object 604. Based on the scale of the Zooming Video Object, a decision is made, at decision block 605, as to whether the video pixel information at Native Video Object 604 should be copied to the Normal DirectDraw RGB Surface 606, or to the Video Overlay Surface 607. If the Zooming Video Object is scaled to a size greater than the minimum size for the Video Overlay Surface—that minimum size normally being the original image size from the DirectDraw Video Port, the video pixel information from the Native Video Object is copied to the Video Overlay Surface 607. If, on the other hand, the Zooming Video Object is scaled to a size equal to or less than the Video Overlay Surface minimum size, the video pixel information from the Native Video Object 604 is copied to the Normal DirectDraw RGB Surface 606.

[0058] In an alternative embodiment shown in FIG. 6B, when the Zooming Video Object is scaled to within a threshold greater or less than the Video Overlay Surface minimum size—10 pixel units for the illustrated cases, the pixel information from the Native Video Object 604 is copied to both the Normal DirectDraw RGB Surface 606 and the Video Overlay Surface 607 (block 605(a)), in order to avoid an image flicker at the point where the two surfaces are swapped. When the Zooming Video Object is scaled outside the threshold, subsequent processing follows a flow identical to that shown in FIG. 6A.

[0059] Conclusion

[0060] A methodology has been described hereinabove for transforming a video signal being played in native code of a computer operating system into a zooming universe operating on such computer, where the image of that video signal may be scaled by a user to dimensions desired by the user. The zooming engine providing the zooming universe in which the transformed video object may be scaled is preferably implemented in the JAVA programming code. To avoid visual distortion problems relating to interlacing of the input video signal, the video is played on a video overlay surface at scale magnitudes above a threshold level—normally the original image size—and on a DirectDraw video surface at scale magnitudes below that threshold level. A swap of the surface from which the video is being played is made between the video overlay surface and the DirectDraw video surface at the threshold point, with preferably a caching of image information on both surfaces as the scaling approaches the threshold point from either side.

[0061] Although the methodology of the invention, and illustrative applications of that methodology, have been describe in detail, it should be understood that various changes, alterations, and substitutions can be made therein without departing from the spirit and scope of the invention as defined by the appended claims.