3D view for digital photograph management

[0001] This application claims the right of priority under 35 U.S.C. § 119 based on Australian Patent Application No. 2003907006, filed 17 Dec. 2003, which is incorporated by reference herein in its entirety as if fully set forth herein.

[0002] The present invention relates to computer graphical user-interfaces and, in particular, to user-interfaces for digital photograph and video management applications.

[0003] The first affordable digital cameras, having a relatively high resolution in the megapixel range, became available in the mid-to-late 1990's. Since that time, a large range of software has been developed to support digital photography, this being operable on desktop or portable computers for home or office purposes.

[0004] For digital photograph collections larger than a few dozen photographs, the most important task is arguably management of the collection. Such management will involve providing quick access to any photograph within the collection and the dispatch of photographs to other programs or various tasks for viewing, editing, printing, and the like.

[0005] In terms of accessing photographs, two major metaphors are employed. The first involves file-system views, which involve arranging the photographs by the position of their file on the hard-drive of the user's computer by which the photographs are stored. The second involves meta-data based views, where the collection may be sorted based on the attributes of the photograph, like date or keywords, that the user has applied to the photograph. In many ways these two metaphors are interchangeable.

[0006] By far the most common way of managing a photograph collection is simply through the file-system. Users save their photographs from their camera or other source to a directory on a computer hard-drive. From there, the user can take advantage of file management capabilities of the operating system associated with the computer to view the files. This is typically performed by opening the files with a program for viewing or editing. The file-system also allows the files to be categorised into directories and sorted by name or date. Operating systems such as Mac™ OS X, Windows™ XP and KDE™ often tout their strengths in this type of, largely file-based, simple photograph management.

[0007] Many dedicated photograph management programs emulate this style. This type of program keeps the directory structure and shows the files in their directories but offers more sophisticated camera integration, thumbnail viewing, dispatch to photograph editing or printing programs, or meta-data editing, than provided by the operating system. Programs in this category are numerous and include ACDSee™, Canon Zoombrowser™, BetterBrowser™, IMage, PhotoMesa™, Canon ImageBrowser™, and many more.

[0008] The variety and style of visual displays that this type of program can generate are limited by the directory structure. Proper display of the user's entire collection by date is difficult because the collection may not all reside in one place. A simple flat two dimensional (2D) view also limits how much visual structure can be created and how many thumbnails can be squeezed into the screen of the computer at one time. With limited visual structure, distinguishing the content of thumbnails becomes essential to navigate the collection. This can limit the utility of collections of thousands of images. However, such a virtual “album”, as defined by the directories in which the photographs reside, are simple, and therefore easy and inexpensive to implement.

[0009] The second type of photograph management software is the meta-data sorted type. This type of program typically requires all photographs to be registered with the program. At the time of registration, the photographs are added to a database and various meta-data for the photographs is stored. To navigate the photograph collection, the user selects an attribute, for example date, and the entire collection is sorted by this attribute. Often the sorting provides some form of categorisation. Typically, with the dates example, headings may be provided at the top for years or at the top of photographs taken at the same time. The results are presented as thumbnails of the photographs, arranged in a two dimensional grid.

[0010] This second type of photograph management is normally considered the more sophisticated of the two, since file management is generally operated by searches across a database, being a file system. File based management is therefore actually a sub-set of meta-data sorted photograph databases.

[0011] Examples of programs which allow digital photograph collections to be navigated based on the meta-data associated with the photographs, rather than the file system locations of the photographs include Adobe Photoshop™ Album, Picasa™ and iPhoto™. These programs can perform searches and order the collection by a range of different criteria, such as date, name, keywords, etc. However these programs are subject to the criticism that they are centred upon the remaining flat two dimensional view which limits the visual structure.

[0012] Both the file directory and meta-data sorted approaches to photograph management suffer from the same problem, being that the current view is invariably a grid of photograph thumbnails. While this does offer the most pixels visible for each photograph when displayed on a rectangular two-dimensional display screen, it provides almost no visual structure for the information. Users must visually scrub (move their eyes over) every photograph on screen to track down what they are looking for. There is also no “orientation”, in that every grid of photograph thumbnails looks very similar to every other grid of thumbnails. As such, the user can quickly become lost if their collection is bigger than the 200-300 thumbnail representation of photographs that will comfortably fit on a typical computer display screen.

[0013] Another type of image searching is “content-based image retrieval” (CBIR). This is essentially another sophisticated form of meta-data searching, and involves processing each image to identify visual characteristics like the colour of the subject, the number of major lines in the image and the overall texture of the image. A research project described in the paper “An Interactive 3D Visualization for Content-Based Image Retrieval” M. Nakazato, T. S. Huang; Beckman Institute for Advanced Science and Technology, University of Illinois at Urbana-Champaign proposed a system called “3D MARS”. 3D MARS took a database built in this fashion and used common database 3D visualization techniques to display the images placed along three axes depending on these three visual characteristics.

[0014] One problem with the 3D MARS research project was that the visual characteristics were hard to calculate and did not always correlate with how users mentally classified their images. The displays of the database also tended to look largely unsorted and scattered because the display had little genuine structure. Consequently, the user was not presented with an easily navigable result. The research project also required immersive navigation involving a first person view that placed the viewer in the middle of the database. This meant that much of the database was occluded, behind the viewer, hidden behind other photographs or otherwise outside the field of view. The result was that the display seemed cluttered and disorganised. Since many photographs were occluded, at any given time, most photographs could not be seen.

[0015] Many projects, both commercial and research, have investigated three dimensional (3D) visualisation as a means of better presenting information in databases. The most obvious reason is that it allows results to be plotted along more than two axes—something that is difficult in the two dimensional display environment provided by a computer screen. Some projects though, have explored this type of visualisation simply to offer a different visual metaphor, to be visually distinctive in the marketplace, or take advantage of the features of modern computer graphics cards.

[0016] The basic type of 3D visualisation is the immersive virtual-reality environment, where the viewer is placed inside the 3D model. An example of this is a program simply titled 3D-Album™ manufactured by Micro Research Institute, Inc. of the USA. This program takes a collection of photographs and presents them in locations around a 3D environment that can then be navigated by the user or toured along a virtual path. This type of arrangement, whilst fun to use, is of little utilitarian benefit. Information is not sufficiently dense to allow management of dozens, let alone hundreds or thousands of images. The arrangement is also not structured and sufficiently organized to allow rapid location of one image from among a vast number.

[0017] Other types of visualization have attempted more utilitarian purposes. A research project at Massachusetts Institute of Technology called the CAES System, constructed 3D models from information in a database. The database contained objects with location data on the MIT campus. Icons representing these objects could then be placed according to their location data on a 3D model of the MIT campus. Co-located items were stacked on top of each other. The researchers on this project ultimately concluded that this form of display was not entirely successful. Placing items on a 3D map in this way did not result in sufficiently dense information. The amount of the 3D map that was required to recognise specific features outweighed the actual result data that was presented. In the CAES system, the campus map did not provide a good means of rapidly associating information with its meaning. Also, since the results were icons representing data, not data with an actual visual component, the visual presentation was a clumsy way of presenting this textual data.

[0018] Other efforts at using 3D visualisation to structure and display data include the PARC Cone Tree manufactured by Xerox Corporation, which is really only suited to presenting tree structures and is a questionable improvement on 2D techniques for the same thing. Also, U.S. Pat. No. 5,847,709 granted Dec. 8, 1998 to Card et. al., provided a 3D document workspace divided hierarchically in terms of interaction rates with focus, immediate and tertiary spaces. This arrangement was only really suited to presenting a typical desktop metaphor and had questionable scope for handling large numbers of documents.

[0019] An interesting arrangement of visual objects in 3D is found in U.S. Pat. No. 6,005,578 granted Dec. 21, 1999 to Cole where visual objects were presented in laterally connected loops, the loops then being stacked in a vertical direction. This proposal was conceived as a hyper-linked environment more than a representation of search results from a database, and provides little scope for sorting along multiple axes.

[0020] A more functional approach to display of information from a database is given in U.S. Pat. No. 5,621,906 granted Apr. 15, 1997 to O'Neill. In this approach, information along at least two axes is presented (date into the distance and time vertically). The axial constraint simplified the structure of the data displayed and also simplified the navigation which is often the worst part about immersive 3D display.

[0021] Basic 3D -charts and graphs have often succeeded in presenting data in more than two dimensions. The charting capabilities of Microsoft Excel™ and higher end visualization programs like Amira™ or 3D-Master™ have enjoyed great success in presenting largely numerical data in three dimensions. One of the strengths of these programs is that they list their data within a confined space. The boundary of this space is clearly labelled with axes and all data within the region can be quickly associated with the relevant point along each axis.

[0022] It is an object of the present invention to substantially over come, or at least ameliorate, one or more deficiencies of prior art arrangements.

[0023] In accordance with one aspect of the present invention there is disclosed a method of viewing a database including visual media files, said method comprising the steps of:

• • [0024] (a) sorting said database according to at least two fields associated with said media files;
  • [0025] (b) arranging said media files within a range along said at least two fields into groups;
  • [0026] (c) forming a three dimensional presentation of said database having two of said dimensions formed by two of said at least two fields and a third dimension incorporating a representation of each said media file in the corresponding said group.

[0027] Other aspects of the invention are disclosed.

[0028] At least one embodiment of the present invention will now be described with reference to the drawings, in which:

[0029] FIG. 1 illustrates a display screen 3D presentation for an image collection;

[0030] FIG. 2A is a schematic block diagram representation of a 3D photograph management system;

[0031] FIG. 2B is a functional representation of operation of the system of FIG. 2A;

[0032] FIG. 2C depicts a database used in the described arrangement;

[0033] FIG. 3 is a flowchart of a method for 3D photograph management;

[0034] FIG. 4 is a flowchart of the render process of FIG. 3;

[0035] FIG. 5 shows the same collection as FIG. 1 with the cursor over the group at the intersection of “June” and “2000”;

[0036] FIG. 6 shows a render frame during animated zooming into June 2000 of FIG. 5;

[0037] FIG. 7 shows a single group containing 27 photographs, being the zoomed result of the process depicted in FIG. 6;

[0038] FIG. 8 shows a render frame during the animated zooming into a single image from the group of FIG. 7;

[0039] FIG. 9 shows the image from FIG. 8 at the end of the animation;

[0040] FIG. 10 shows a detailed image of a photograph database GUI organised by month and year; and

[0041] FIG. 11 shows the GUI of FIG. 10 after selection of one of the months.

[0042] The methods of photographic data management described herein are preferably practiced using a general-purpose computer system 200, such as that shown in FIG. 2 wherein the processes to be described in FIGS. 3 to 9 may be implemented as software, such as by an application program executing within the computer system 200. In particular, the steps of method of photographic data management are effected by instructions in the software that are carried out by the computer. The instructions may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part performs the photographic data management methods and a second part manages a user interface between the first part and the user. The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer from the computer readable medium, and then executed by the computer. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the computer preferably effects an advantageous apparatus for photographic data management.

[0043] The computer system 200 comprises a computer module 201, input devices such as a keyboard 202 and mouse 203, output devices including a printer 215 and a display device 214. A Modulator-Demodulator (Modem) transceiver device 216 is used by the computer module 201 for communicating to and from a communications network 220, for example connectable via a telephone line 221 or other functional medium. The modem 216 can be used to obtain access to the Internet, and other network systems, such as a Local Area Network (LAN) or a Wide Area Network (WAN), and which can operate as a source of digital photographs. A further input device is seen as a digital camera 230 which connects to the computer module 201 via a connection 235, which is typically a Universal Serial Bus (USB) connection.

[0044] The computer module 201 typically includes at least one processor unit 205, a memory unit 206, for example formed from semiconductor random access memory (RAM) and read only memory (ROM), input/output (I/O) interfaces including a audio-video interface 207, and an I/O interface 213 for the keyboard 202 and mouse 203 and optionally a joystick (not illustrated), and an interface 208 for the modem 216. The audio-video interface 207 supplies video image signals to the display 214 and audio output signals to loud speakers 217. A 3D graphics accelerator card 250 is included as part of the interface 207 to assist in the processing and fast rendering of 3D graphical images. A storage device 209 is provided and typically includes a hard disk drive 210 and a floppy disk drive 211. A magnetic tape drive (not illustrated) may also be used. A CD-ROM drive 212 is typically provided as a non-volatile source of data. The components 205 to 213 of the computer module 201, typically communicate via an interconnected bus 204 and in a manner which results in a conventional mode of operation of the computer system 200 known to those in the relevant art. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations or like computer systems evolved therefrom.

[0045] Typically, the application program is resident on the hard disk drive 210 and read and controlled in its execution by the processor 205. Intermediate storage of the program and any data fetched from the network 220 may be accomplished using the semiconductor memory 206, possibly in concert with the hard disk drive 210. In some instances, the application program may be supplied to the user encoded on a CD-ROM or floppy disk and read via the corresponding drive 212 or 211, or alternatively may be read by the user from the network 220 via the modem device 216. Still further, the software can also be loaded into the computer system 200 from other computer readable media. The term “computer readable medium” as used herein refers to any storage or transmission medium that participates in providing instructions and/or data to the computer system 200 for execution and/or processing. Examples of storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 201. Examples of transmission media include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on websites and the like.

[0046] Where appropriate or desirable, parts of the described methods of photographic data management may be implemented in dedicated hardware such as one or more integrated circuits performing the functions or sub functions of data management Such dedicated hardware may include graphic processors, digital signal processors, or one or more microprocessors and associated memories.

[0047] FIG. 2B illustrates a functional relationship between the salient components of the system 200 for photograph database management. The digital camera 230 provides a source of digital photographs that are loaded 252 to the hard disk 210 of the computer 201 via the USB cable connection 235. During manipulation of the computer 201, for example via an operating system thereof, a photographic database is loaded 254 from the hard disk 210 to the main memory 206. Manipulation of the database may cause information to be added 258 to the database and retrieved 256 from the database. During display of the database upon the video display device 214, render instructions 260 are generated by the processor 205 and passed to the graphics card 250 for rendering and output. Such rendering may use texture information 262 that may be loaded from the hard drive 210 via the processor 205 and sent to the graphics card 250.

[0048] The presently disclosed arrangement provides a graphical user interface (GUI) for the presentation, selection and manipulation of a database of images. FIG. 1 shows typical window display according to the present disclosure as might be seen upon the display 214 for a collection of 196 JPEG images, sorted by year and month, and presented in the manner to now be described.

[0049] The application program that implements the GUI is formed by a event loop method 300, shown in FIG. 3, which continually polls for user events (in steps 320-330) and updates the screen display 214 on every loop (defined by rendering at step 335). The GUI program is capable of responding to user actions such as requesting photographs to be fetched from the camera 230, quitting the GUI program, or navigating around the view formed on the display 214 by means of clicking the mouse 203.

[0050] The GUI program maintains a database 270, seen in FIG. 2C which, consequential to program start-up at step 301 in FIG. 3, is loaded at step 305 from the hard disk drive 210 to the memory 206, this being represented by the functional process 254 of FIG. 2B. The database 270 contains at least one table 272 whose primary role is to maintain references to media files, and is henceforth called “the reference table 272”. Media in this regard includes, but is not limited to, digital photographs and digital video, as well as meta-data for these media files.

[0051] The reference table 272 of the database 270, as illustrated in FIG. 2C, typically has one media file reference per row (274-278) and sufficient other fields per row to store at least the following meta-data for the media file:

• • [0052] (i) photograph capture date,
  • [0053] (ii) the date that the photograph was added to the database,
  • [0054] (iii) the type of the media (photo, movie, other),
  • [0055] (iv) the number of times the user has accessed the media through the GUI program, and
  • [0056] (v) other EXIF or IPTC standard meta-data information.

[0057] The information in the reference table 272 establishes the window, graphics context and memory buffers required for drawing to the display 214 and to the graphics card 250, as well as appropriate drivers and dynamically linked libraries for image loading and communicating with other tools in components of the computer 301.

[0058] Media files may be passed to the GUI program in any of a number of ways. For example, a user may place the media in a directory on the hard-drive 210 which the GUI program scans periodically at step 315 looking for new files. Alternatively, by polling the user for certain events at step 320, the user can instruct the GUI program to add the media by dragging the files onto the GUI program or selecting the files in a file dialog presented by the GUI program. A further alternative, seen at step 325, is where the user instructs the GUI program to retrieve, depicted functionally at 252, the media from the digital camera 230 when such is connected to the computer 201. This process may be performed by an interface operated by the user operating the mouse 203 to select by clicking a camera icon 102, seen in the top left of FIG. 1. Photographs fetched in this way are stored, according to step 345, on the hard drive 210.

[0059] When a new media file is passed to the GUI program by step 315 or 325, step 340 subsequently operates to add a new row 280 to the reference table 272 and to insert a reference to the media file in one of the fields of the new row 280. This is illustrated functionally at 258 in FIG. 2B. Other fields of the new row 280 are populated with information derived from the media file, as noted above, which can all be extracted from the media file and added to the fields of the new row 280 at this time. If certain values are not present in the media file, those fields of the new row 280 may be initialised to default values.

[0060] If no new media is requested at step 325, step 330 follows to check whether or not the user has selected to quit the database management (GUI) program. If so, step 350 follows to perform a file clean-up and a closing of the GUI program. If not, step 355 follows to check for a click of the mouse 203 by the user. If a click is not detected, step 335 follows to render the scene. If a click is detected, step 360 follows to pick a new camera destination. The camera destination discussed in step 360 is a virtual camera position, being the virtual viewpoint within the OpenGL scene. In OpenGL, this is a conceptual combination of the GL_PROJECTION and GL_VIEWPORT matrices with the top level GL_MODELVIEW matrix. Frequently, these matrices are not manipulated directly but set using the function “gluLookAt” which allows the user to specify the “eye” coordinates and the “centre” coordinates (the target that the “eye” looks at) and a vector which specifies the “up” direction. It is also affected by the function “gluPerspective” which sets the field of view (both width and depth). It is to be noted that GLU functions, being functions whose names begin with “glu”, are not core OpenGL functions but are part of the OpenGL Utility Library. They exist to simplify some of the more tedious but commonly used mathematics and data processing aspects of OpenGL. Skilled persons who use OpenGL will have access to GLU.

[0061] In step 360, the “new camera destination” is the location to which the virtual camera will move after a zoom or other camera movement. The term “camera destination” is used because the camera's location is not set immediately. Instead, an endpoint is set, and each frame of rendering, the virtual camera is moved closer to its destination—thus a pan/zoom or other virtual camera movement is achieved. As such, if a click of the mouse 203 is detected, step 360 determines the object that the user has clicked on within the 3D scene and from this and the virtual camera's current location (fully zoomed out, partially zoomed in or fully zoomed in), determines a new endpoint for the camera's movement.

[0062] Step 335 follows from step 360.

[0063] Once the database 270 contains all appropriate and available information, the GUI program then performs the task at step 355 of displaying the contained media to the user. Step 335 is shown in greater detail in FIG. 4, and has an entry step 400 which begins a rendering of the scene. The display of the information is constructed using calls to a 3D graphics language generally associated with and supported by the 3D graphics card 250 arranged within the computer 201. The two most common languages for this task are OpenGL, which is an industry standard 2D and 3D graphics application programming interface (API) (details of which may be obtained from www.opengl.org), and DirectX™ manufactured by Microsoft Corporation. Whilst both these languages are capable of constructing the scene formed by the GUI and may be used, the description that follows will rely upon the example afforded by OpenGL terminology.

[0064] Before the scene can be created, the information to be displayed must be retrieved from the database and before the information can be retrieved, the program must have at least one field for sorting the information. The field must be one of the fields available in the reference table 272 of the database 270. Example choices for fields by which to sort the information can include month and year and date, subject and location, keywords, as well as number of times viewed. If the user has not chosen a sort field or fields, default sort fields may be set as the month and year and date. The following description will consider information sorted by month and year and date although, as will be appreciated, any of the fields available may be used for sorting purposes. Step 405 operates to select the required field from the database 270, with each selected field representing an axis of the desired display.

[0065] With the sort fields chosen, step 405 also operates to build a query which can be sent to the database 405. If the database is one founded upon Structured Query Language (SQL), being a standard language for relational database management systems, (ie. an SQL database), the query might appear as follows:

• • [0066] SELECT media_reference, month, year, date FROM program_database ORDER BY year, month, date

[0067] This query will give the four fields, being media_reference, month, year and date, for every media file added to the database, which in this example is named program_database. The result will be sorted by year first, then within each year by month, then within each month by date. In this way, the information regarding the database 270 is retrieved from the memory 206, as functionally depicted at 256 in FIG. 2B.

[0068] Step 410 attends to adjustment of the position of the virtual camera as discussed above. Since the camera's specific location is not set (only an endpoint for the camera's movement is set), at some point it is necessary to actually animate the camera along the path towards its endpoint. Step 410 therefore attends to animation of the virtual camera along the viewpoint path.

[0069] Step 415 then operates to scan through the results and determine the months and years spanned by the results. The results are then clustered into groups based on their values along each of the two primary axes (year and month). From the groups formed, step 420 then operates to determine the largest number of media files that occur within a single month.

[0070] The rendering process 355 can now begin building the scene, in the present example, in OpenGL. It is assumed that a render context has been created and that the required OpenGL functions have been enabled at step 310, together with a light source and “camera” angle already being established, which establishes a 3D viewpoint for the 3D presentation of data. Graphical objects, by which a representation of the database 270 (ie. the “scene”) is to be viewed are then created by sending OpenGL shape instructions to the graphics card 250. This is depicted functionally in FIG. 2B by the processor 205 creating those instructions and sending them at 260 to the graphics card 250. These operations are depicted in the process 355 of FIG. 4 by step 425 which checks if there is an undrawn group from the search and, if so, by step 430 which checks if there is an undrawn file in that group.

[0071] If there is an undrawn file determined in step 430, step 435 follows to create an icon or thumbnail for each media file. The thumbnail for a photograph may simply be formed by an OpenGL quad (the default, four-sided drawing primitive in OpenGL), textured using the photograph and formed at step 440. Similarly, for a video file, a thumbnail may be formed by an OpenGL quad textured with a frame of the video. Textures are created on the graphics card 250 by transferring, as seen at 262 in FIG. 2B, a bitmap for the texture from the photograph or video's file on the hard drive 210.

[0072] A “tower”, being a three-dimensional representation that contains the representations of the results from a single group, is then built for each group, according to step 445, by arranging the quads in a two-dimensional plane of rows and columns. Each quad is placed in a location defined by its third sort field, which defines a third dimension and provides meaning for the arrangement of quads within the tower. The number of columns should be chosen based on the previously calculated largest number of media files that occur within a single group. The number of columns will be the same for every group and should be chosen so that no group is too tall to fit within the GUI program's OpenGL window. To further give shape to the tower and ensure that it is not simply a two dimensional object, a square quad is drawn at the base of the tower, perpendicular to the plane of the other quads in the tower. An example of a single tower is shown in FIG. 7.

[0073] After step 445, operation of the GUI program returns to step 430 where a check is again made for another member of the group. When all members of the group have been processed, step 450 follows to create a base backing quad for the group. This is done by placing a flat coloured quad at the base of the group, perpendicular to the tower, but square with width and length equal to the width of the tower.

[0074] Step 455 places the towers (one for each group) to form an array upon a two dimensional plane. This plane is the same as the plane that the tower's base occupies. Step 455 returns to step 425 where the next group is processed 455. The collective result of these steps is to construct upon the two-dimensional plane, towers of thumbnail representations of images stored within the database 270.. The rows and columns of this array, in the present example, represent the month and year for the group, respectively. Had different search fields been used in the database query, the array rows and columns would reflect this. For example if only “number of times viewed” had been used in the query, there would only be one column with the rows of the column being the number of times the media files within the group had been viewed. The towers represented in the display of FIG. 1 are thus a collective representation of the media files each shown commencing and extending in a third dimension from the two-dimensional grid formed by the rows and columns. As a direct consequence, by being grounded to the grid, the “height” of each tower in the third dimension is indicative of the number of thumbnail images retained in that file directory of the hierarchical file structure being represented.

[0075] With the towers arrayed in the plane, step 460 follows to create text objects along the boundaries of the plane so as to label the axes, with the years and months in the present example.

[0076] Once fully arranged and built, the OpenGL scene can be rendered is step 465 by flipping the render buffers and by doing so, the result is displayed to the user upon the display 214.

[0077] In FIG. 1, a GUI display 100 shows a media collection containing 196 photographs. The collection is viewed by pairs of months and year and, within each tower formed at each month pair/year intersection where a file exists, by filename. The 2D plane shows months from January to December and years from 1998 to 2003 and as such, spans the entire collection of media. Each photograph within the month and year for each square on the 2D plane is arranged into a perpendicular 2D grid of thumbnails. Since each of these 2D grids of thumbnails contains 5 columns of photographs, the height of the grid reflects the number of photographs for that year/month combination, rounded up to the nearest multiple of 5. These values may be selected to obtain a pleasing appearance. In FIG. 5, being a further representation of the media collection of FIG. 1, a cursor pointer associated with the mouse 203 is located over the intersection of the May-June column and the 2002 row, thereby causing that row and that column to highlight. The highlighting may be achieved using different colors for columns and rows, and different colors between rows and between columns, thereby aiding visual distinction of groups for user selection.

[0078] Advantages of this view when compared to the noted prior art representations include:

• • [0079] all photographs from a given month can be located quickly;
  • [0080] the display has a shape and pattern caused by towers of different height and gaps that allows users to quickly orient themselves within the view;
  • [0081] the 3D view is also visually appealing and is considered to have a specific appeal to the type of frequent computer user likely to take many digital photographs; and
  • [0082] the speed of modern 3D graphics cards, which may be used for the graphics card 250, allows speed of rendering and display that exceeds the performance of a traditional unaccelerated 2D display arrangement.

[0083] Variations on the display style of FIG. 1 include many different means of presenting the group at the intersection of a row and column. For example a rectangular prism may be used instead of a 2D grid of thumbnails, with the height of the prism being indicative of the number of media files in that group.

[0084] Another improvement which can be made is to cache processing that occurs in the main program loop 300 of FIG. 3. For example, it is unlikely that a user would desire creating textures for hundreds of media files every loop. These textures can be created once and left on the 3D graphics card 250 until they are no longer needed. Similarly, the database 270 need only to be queried when there is a change in the database 270. As such, results can simply be taken from the last query in all other cases.

[0085] Building the display is only one part of a media management program. The ability to select and view individual images is also required. For this, the GUI program requires a means of navigation. This is achieved by the user through interaction using the mouse 203 and the associated cursor pointer within the displayed GUI.

[0086] The first type of interaction the user can achieve is simply moving the mouse 203 to position the pointer over the display in the 3D view. The OpenGL function gluUnProject can be used to take the window (pixel) coordinates of the mouse, along with the GL_MODELVIEW_MATRIX, GL_VIEWPORT, GL_PROJECTION_MATRIX and the GL_DEPTH_COMPONENT of the pixel under the mouse to give the OpenGL coordinate of the point that the mouse is over. If it is ever determined that this OpenGL coordinate lies within the bounds of a valid tower within the scene, then when building the display axes at step 460, an extra quad may be added under the column and row of the tower.

[0087] The result of the above process is a track highlight, such as that shown in the GUI display 500 of FIG. 5. In that example, the track 502 representing the months May-June and track 504 representing the year 2002 have been highlighted, resulting in a highlighting of the tower 506 at the intersection thereof. The tower 506 shows a collection of thumbnail images.

[0088] The second type of interaction is a mouse click. When a click of a button formed on the mouse 203 is detected, the group associated with the click is selected. The grid coordinate as determined above is obtained and a new 3D camera viewing position is sought which places the camera viewpoint, and thus the user viewing the display 214, very close to the grid coordinate and directly facing the 2D plane of the group at that coordinate. The camera position is not set explicitly, but instead a destination is set so that at each render update step 410, the camera viewing position moves closer to this destination. This creates a smooth zoom-like effect which has two benefits. Firstly, the “zoom” is appealing and secondly the user never loses track of where they are or how they reached their current viewpoint.

[0089] Simultaneously, a destination camera position may be set. Further a destination alpha (opacity) value is preferably set to zero (ie, fully transparent) for all other groups at all other grid coordinates. In an alternative, the destination opacity may be set to zero, or close thereto, for those groups in the immediate vicinity of the selected group. This destination alpha is updated at the same time as the camera position is updated during each render of the “zoom”. The result is that, as the GUI display zooms into the grid coordinate at which the user has clicked, some or all other grid points fade away so that there is no occlusion of the selected group by other towers and no confusing peripheral elements.

[0090] FIG. 6 shows an exemplary 3D render frame 600 during the zoom transition to the tower 506. It will also be seen from FIGS. 5 and 6 that a further tower 508, at the intersection of May-June 2003, is transparently depicted to aid the highlighting of the tower 506. The further tower 508 is shown opaque in FIG. 1. The “vicinity” in which opacity is altered may be varied according to the size of towers surrounding that group which is selected and the extent of possible occlusion. An immediate vicinity in the example of FIGS. 5 and 6 may therefore include those eight groups that are immediately adjacent the selected group 506.

[0091] In a further alternative, without a need to click the mouse 203, as the mouse 203 is moved over the display 500, groups and towers other than that over which the mouse cursor currently lies, may be made wholly or partly transparent, to thereby afford the user of immediate visual feedback of that group or tower immediately available for selection.

[0092] From the frame 600 of FIG. 6, in comparison with the view 500 of FIG. 5, it will be appreciated that the camera viewpoint is swinging around to a position perpendicular to the plane of the selected group and that the viewpoint is also zooming-in so that the selected group begins to fill the display screen 214. All other non-selected groups are in the process of fading away.

[0093] FIG. 7 shows a view 700 including 25 photographs comprising the thumbnails of the tower 506 from the final position of the camera viewpoint after the transition from FIG. 5 via that of FIG. 6. The view 700 is analogous to a typical “grid of thumbnails” view in other photograph or video clip management software. Whilst the view of FIG. 7 is effectively a “2D elevation” view of the 3D tower 506, the tile 702 that the group rests upon reminds the user that the view 700 remains one part of a 3D environment, adding both context and consistency at the same time.

[0094] The re-positioning of the viewpoint in the fashion described above and illustrated in FIGS. 5 to 7 may be performed by using the OpenGL function gluLookAt( ) or by setting the GL_PROJECTION and GL_MODELVIEW matrices directly.

[0095] In certain implementations, not shown in the drawings, the same types of selection, movement and other actions that are typical under this type of software (eg. OpenGL) can be performed. This includes menu items to perform a slideshow on the currently displayed images or selecting some images and sending them to an external program for editing or selecting some images and emailing them.

[0096] Once the camera has reached the viewpoint shown in FIG. 7, three new mouse actions are possible, those being:

• • [0097] (i) the user can click on an image in the group;
  • [0098] (ii) the user can click on one of the navigation buttons; or
  • [0099] (iii) the user can click on the “Whole Collection” 704 in the top right of the window 700.

[0100] If the user clicks on the “Whole Collection” 704 in the top right of FIG. 7, the reverse of all camera and alpha transitions between FIG. 5 and FIG. 7 are applied. The result is that the camera is moved back to its starting position and all grid locations become visible again.

[0101] If the user clicks on one of the navigation buttons (in FIG. 7 they are labelled “Next Month” 706 and “Previous Month” 708), the camera viewpoint destination is set to the appropriate point for the next or previous grid coordinate, as though the user had clicked on the next or previous month from the “Whole Collection” view (ie. FIG. 5). The destination group has its destination alpha set to one (fully opaque) and the currently displayed group has its destination alpha set to zero. The result is that the camera viewpoint moves either forwards to the next group or backwards to the previous group, and that the current group fades to fully transparent while the destination group becomes fully opaque.

[0102] If the user clicks on one of the photographs in FIG. 7, the thumbnail under the mouse pointer is determined by obtaining the OpenGL coordinates of the point under the mouse and determining if this point is within the bounds of one of the thumbnail representations. The OpenGL function gluUnProject can be used to take the window (pixel) coordinates of the mouse, along with the GL_MODELVIEW_MATRIX, GL_VIEWPORT, GL_PROJECTION_MATRIX and the GL_DEPTH_COMPONENT of the pixel under the mouse to give the OpenGL coordinate of the point that the mouse is over. By doing this, and by further rounding the result to the nearest thumbnail point, the coordinates of the centre of the thumbnail selected are determined. The camera viewpoint destination is then set to a location close enough to the thumbnail in order for the thumbnail to fill the screen, with the thumbnail centred in the camera viewpoint. Further the destination alpha of all thumbnails in the group (except the selected thumbnail) and the group itself are set to zero. The result is that the camera viewpoint zooms in to the thumbnail while everything else fades out of view. FIG. 8 shows a render frame 800 during this transition with the target photograph 802 getting larger in the view as the camera moves into it and the other photographs fading to blank. FIG. 9 shows the endpoint of this transition, with the zoom complete providing a view 900 including only the selected photograph 902.

[0103] From FIG. 9, any mouse click except a mouse click on the camera 904 (top left) or the “Whole Collection” 906 (top right) results in a reverse transition back to that of FIG. 7. Clicking the “Whole Collection” 906 results in a transition all the way back to FIG. 5 in one step. Clicking the camera 904, as at any point during the execution of the GUI program, fetches any new photographs from the camera 230 according to step 345.

[0104] In another implementation, not shown in FIG. 9, this closest view allows the user to perform edit and modification behaviours typical to photograph or video clip management applications. These behaviours include adding keyword metadata or adjusting image brightness and contrast or sending the media file to an external application for viewing and editing. The ability to move to the next or previous photograph in the group may also be made available.

[0105] FIGS. 10 and 11 illustrate a further alternative for photo album navigation, which build upon the structures shown in FIGS. 5 and 6. FIG. 10 shows a three-dimensional representation 1000 formed by a two-dimensional grid 1002 of months 1004 in one dimension and years 1006 in the other. The months and years represent ranges of dates respectively by which a hierarchical file database may be sorted. The representation 1000 is that of a hierarchical file directory structure of photographs arranged according to date of image capture, for example. At various ones of the grid coordinates, towers 1008 of thumbnail images 1010 are represented extending in a third dimension from the plane of the grid 1002. Movement of the mouse 203 as before results in corresponding movement of a mouse cursor across the GUI of which the representation 1000 forms a part. In this implementation, where the user wishes to review in detail the images in any one tower, a mouse click on that tower, for example the tower 1012 at Nov-2000, results in the GUI altering to the representation 1100 shown in FIG. 11. As is seen, the transition between FIGS. 10 and 11 results in a hierarchical change in representation for months and years, to days within the selected month. Further as seen, the single tower group 1012 of FIG. 10 is represented in FIG. 11 by seven towers 1101-1107 each of which possessing at least one thumbnail image captured on the corresponding day. Further, whilst the 2D plane in FIG. 10 is sorted according to two fields (month, year), the 3D plane of FIG. 11 may be considered sorted according to one field, being date.

[0106] From FIG. 11, it is noted that the representation 1100 is laid out akin to a calendar with the month (November), being shown arranged in its appropriate weeks. The weeks provide appropriate ranges of a second field by which the files of the tower group 1012 may be sorted. A pair of lines 1110 and 1111 delineate the month of November from adjacent months October and December respectively, with the days of those months that fill the grid in the representation 1100 being shaded a different color so as to clearly distinguish them from the selected month. A pair of arrow icons 1112 and 1113 are also provided and which are selectable by operation of the mouse 203 to shift or scroll the representation 1100 into the adjacent month of October or December respectively. Thus the representation of FIG. 11 affords a detailed representation of a lower level of the hierarchical file structure, different from that of FIG. 10, but nevertheless in a consistent and hierarchically interpretable manner.

[0107] The navigation of the three dimensional view described above is quite distinct from typical “virtual reality” methods or immersive forms of interaction as known in the prior art. While the camera viewpoint does move in the 3D model, all visible elements remain in view at any given time. The advantages of this include:

• • [0108] the user does not need to turn their head (ie. adjust the camera viewpoint) to see what is behind them;
  • [0109] access to a global view of everything (the “Whole Collection”) is available in one click of the mouse 203;
  • [0110] navigation operates at the same point and in a similar click style that user are familiar with from two dimensional GUIs;
  • [0111] slow, walking-style navigation around a 3D environment is not required—instead, quick zooming transitions occur with a single mouse click;
  • [0112] navigation is simpler than immersive environments because only two types of action are required: zoom in or zoom out, with navigation between groups (“Next Month” and “Previous Month”) being strictly optional and not required to access any part of the collection;
  • [0113] the tile is still visible in the intermediary hierarchy level (the dark trapezoid 710 at the base of the group in FIG. 7) reminding the user that they are at one “square” of the “Whole Collection” view.

[0114] The GUI program described above provides a method of viewing thumbnail representations of media files from a database in three dimensions, where the thumbnails are sorted along two or more fields of the database and grouped within a range along both fields, with the groups being arranged according to their values along the two sort fields. This results in an ordered presentation of the information in a fashion consistent with methods of interpretation typically employed by users. This arises from the use of sort terms and the familiarity of users in identifying a 2D intersection of terms and then assessing the information at the intersection, which may be a single photograph or a collection of photographs. The GUI program also provides a means of navigating a set of groups displayed in three dimensions.

[0115] Although the present description is centred upon media files having image (eg. thumbnail) representations, the principles disclosed herein may be readily applied to databases that utilize any one or more of a range of file types. For example, operating systems such as Windows™ afford general file searching functionality which may be limited by date, date range, file name and file type for example. The search result may then be sorted based upon a file attribute such as name, size, type or date. Consequently, multiple searching dimensions can be applied across a general database of files. These may then be used to generate a 3D view similar to those of FIGS. 1, and 5-9. Further, the present disclosure is also applicable to broader collections of data that may not be file-structured. Such include arrangements where a number of data objects are arranged in a collection that is not file-based and not a database.

[0116] The arrangements described are applicable to the computer and data processing industries and particularly in respect of management of large numbers of visual media files.

[0117] The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.