Home >> Media Group >> Research >> ViPER
Downloads -- Documentation -- Developers -- Discussion
LAMP     The Language and Media Processing Laboratory

ViPER-GT: The Ground Truth Authoring and Viewing Tool

Remember Ben Shneiderman's infoviz mantra:

  1. Overview First
  2. Zoom + Filter
  3. Details on Demand
  1. Core System
    1. Metadata Management
      1. The core system must allow the plug-ins to access via the ViPER API.
      2. The core system must support loading and saving any valid viper file and saving it back, so that the two files are equivalent.
      3. The system should have a history of user files, to allow quick loading of recently used files.
      4. The system should be able to handle loading multiple files at a time, for editing and comparing results, and switching between related files in a project (e.g. different camera angles).
      5. The system may support inserting other files or merging two metadata files. If the GT system doesn't support this, a seperate tool must exist for this kind of functionality (it is often necessary to divide work among multiple truth editors, and merging is a necessary step).
    2. User Interface Mediation for Modules
      1. There must be a means of reducing the user clutter and focusing the user's attention to the work at hand. This includes a method for selecting what file to work on, what frames are important, and what descriptors are relevant to the user's task. An example would be having a selection for showing only descriptors that are relevant to another descriptor, a certain frame, or contain a certain lvalue.
      2. There should be a method for supporting DnD. 694122
    3. Basic Graphical User Interface
      1. The menus and windows must follow standard guidelines (e.g. the Windows guidelines).
      2. The main window must show the current sourcefile selected in its title bar. 694123
      3. The user should have access to a list of most recently used files, to save time looking for files to open.
    4. User Preferences Management
      1. Different modules should have their own preferences, accessable in the same manner or through the same interface.
      2. The user should be able to specify their hotkey preferences. 694133
    5. Undo/Redo 694113
      1. The undo/redo should be accessable through the standard hotkeys and place in the menu.
      2. The undo manager should have a user interface to display multiple levels of undo.
      3. Any undo manager may support transactions, to allow multiple actions to be bundled into one by a script.
    6. Documentation
      1. There must exist a clear design specification of the core system, allowing plug-in writers a clear handle on how to extend the app.
      2. There users must have a manual which describes the system from the perspective of a ground truth author or designer.
    7. Ontology Support
    8. Help System
      1. There must be some form of online help, if only a link to the documentation.
      2. There should exist context-sensitive help, explaining certain features.
  2. Canvas Module
    1. A media canvas must exist, which presents a view of the current file and frame, with the metadata appropriately represented directly upon it, and directly manipulatable when possible.
    2. The canvas must be frame accurate - i.e. it will display the frame x as per the media format specification, and consistant with time, as well.
    3. The canvas should be fast, displaying the new frame after a user suggests a change in less than a second. It would be preferrable to allow real-time playback of video, as well.
    4. The canvas should use standard vector manipulation ui metaphors and gestures, unless there is a clear reason to use different ones. 694134
    5. There should be a way to select multiple objects on the canvas and manipulate them at once. 694114
    6. There should be a way for the user to customize colors or to associate colors with each instance of an object. 694120
    7. The shapes and so forth should be drawn appropriately to the scale of the zoom. 694124
    8. In order to support more clarity while editing ground truth, the canvas should allow the user to manipulate the image quality, e.g. contrast, gamma, and possibly sharpness. 694126
    9. Should have a refresh or snapback button to go to a preferred view clear of clutter or pixel effluvia. 694128
    10. Should have standard video controls to allow real-time scan of video for errors. 694130
    11. It would be nice if there was a way to create a movie of the canvas. 694106
    12. Should have a way of tracing object tracks through a video at near-real-time. 793929
  3. Timeline Module 694089
    1. The new system must have a timeline (see LifeLines or OntoLog to get an idea of what a timeline view is) that shows an overview of the metadata along the t dimension.
    2. The timeline must support direct manipulation paradigms of some sort.
    3. The timeline must provide all the functionality currently provided by the range slider and the buttons beneath it. This includes:
      1. The user can use the timeline widget to scrub through time, dragging a slider, or something, to skip around through the video. The change must be reflected in the canvas.
      2. The user must be able to use the canvas to select frames, down to frame level precision. This may involve the use of a type-in box, or some sort of enhanced fisheye scrubbing.
      3. The user should be able to use the timeline to propagate descriptor data across frames.
      4. The user must be able to use the timeline to interpolate a descriptor between frames.
    4. The display should support dynamic-query type manipulation to display only lines that are relevant to the user.
    5. The timeline should support zooming along the time access. It may support zooming along the orthogonal, but that may prove distracting.
    6. The timeline should present the lines in a coherent ordering, and allow the user to alter the ordering (either with direct manipulation or with some sort of dynamic query type functionality).
    7. The timeline should have thumbnails of important frames (to the user). 694131
  4. Table Module (See the spec)
    1. The table module presents a spreadsheet-like table view of all instances of a descriptor type or set of descriptor types.
    2. The table module must allow direct editing of all attribute values.
    3. The table must have tabs for each object descriptor type, one for all content descriptors, and one for the file descriptor. 694118
    4. It should be possible to hide selected attributes from the view. This will help to reduce clutter and increase user focus. 694116
  5. Property Sheet Module
    1. The property sheets must provide an editable overview of a single descriptor. It may show the descriptor over the course of its life, or for the currently focussed frame.
  6. Ontology/Configuration Editor Module
    1. The system needs a config editor. The current method of editing .gtc files is a significant barrier to the utility of the toolkit.
  7. Tree View of Instances 694117
    1. The new gt should include a treeview of the instances, which will allow the user to select the appropriate ones and to compare them.