1 / 39

Composite Rectilinear Deformation for Stretch and Squish Navigation

Composite Rectilinear Deformation for Stretch and Squish Navigation. Imager. James Slack, Tamara Munzner University of British Columbia November 1, 2006. Composite Rectilinear Deformation. Stretch and squish navigation User selects any region to grow or shrink Visual history of navigation

lesley-finley
Download Presentation

Composite Rectilinear Deformation for Stretch and Squish Navigation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Composite Rectilinear Deformation for Stretch and Squish Navigation Imager James Slack, Tamara Munzner University of British Columbia November 1, 2006

  2. Composite Rectilinear Deformation • Stretch and squish navigation • User selects any region to grow or shrink • Visual history of navigation • Simultaneous region resizing Growing a region

  3. Successive Navigations Preserve History • Stretch and squish navigation composes deformations temporally • Navigation in regions affects entire view • Effects of all previous navigations persist

  4. Is Stretch and Squish Navigation Hard? • Simple to use • Underlying infrastructure is complex to implement • Standard graphics pipeline has a single, monolithic transformation • Mathematical composition of multiple transformations • Stretch and squish cannot be implemented using this pipeline

  5. Related Work • Stretch and squish navigation • Scales only to hundreds of objects • Rubber-sheet navigation (Sarkar 1992) • Document Lens, single region deformation (Robertson 1993) • General deformable surfaces • Scales only to thousands of objects • Non-linear magnification (Keahey 1997) • Pliable surfaces (Carpendale 1995) • Scalable visualization supporting millions of objects • No stretch and squish navigation techniques • MillionVis (Fekete 2002) • Tulip (Auber 2003)

  6. Related Work • Accordion Drawing Systems • Previous stretch and squish work focused on drawing • Assumed navigation algorithms existed, and never described • TreeJuxtaposer (Munzner 2003) • SequenceJuxtaposer (Slack 2004) • PRISAD (Slack 2005)

  7. Contributions • Our contribution: an algorithm for stretch and squish navigation • Use PRISAD for drawing dataset objects • Scale to millions of dataset items • Not dataset-specific, a generic infrastructure for navigation • Visually composable • All previous actions visible • Deformations are lossless • Support for localized deformation

  8. Complexity of Drawing • PRISAD rendering reduced the drawing complexity by culling • For each frame: draw representative visible subset, not entire dataset • (Total number of drawn objects per frame) << (Total dataset items) • In tree dataset with 600,000 leaves, draw only 1000 leaves • In sequence datasets, aggregate dense regions in software 1000 leaves visible Dense, culled regions

  9. Complexity of Navigation • PRISAD drawing complexity is in terms of visible objects • Draw objects at certain visible threshold • Navigation complexity determined by work done per animation frame • Navigation actions stretch and squish many objects simultaneously • Our algorithm update complexity is relative to regions that change • Number of regions to change simultaneously is limited • Grow just a few regions at once, dozens would be confusing! • Growing a region should not require updating every object • (Updates for navigation) << (Total dataset objects)

  10. Grids and Regions • Stretch and squish a rectilinear grid, deform to navigate • PRISAD uses grid to render, layout, etc. • Normally not visible to end user • Atomic region: smallest navigation granularity • Composite region: collection of many atomic regions • User moves outer region boundaries, interior grid lines follow Composite Region Atomic Region

  11. Vertical line set Horizontal line set Grid = Pair of Line Sets • Separate horizontal and vertical line sets • Navigate simultaneously, independently in both sets • Use same navigation algorithm for both sets

  12. Moving in a Set of Lines • Navigation in a line set moves small number of lines • Suppose 1,000,000 lines in horizontal line set • Only 1000 of these lines are used by PRISAD for drawing given frame • Visible regions between pairs of lines large enough to draw • Move small number of lines marked in red to new locations • Boundaries of composite regions • Not necessarily a subset of visible region boundaries

  13. Usage Scenario: Expand 3 Regions • 3 composite regions marked by user to grow vertically • 3 vertical regions to grow = 6 line boundaries to move • No horizontal navigation in this example Grow 3 regions vertically

  14. Moving Lines • A navigation may change many grid line positions • Every grid line potentially moves in a single navigation • Updating every grid line would be too expensive • To avoid linear update cost, we introduce a hierarchy

  15. Entire horizontal line set Split Line Hierarchy Subdivision • We build a balanced binary hierarchy from each line set • Called split line hierarchy, also used for PRISAD rendering Entire horizontal line set Smaller example Central line Children of central line Deeper regions of hierarchy

  16. Split Lines • Split lines order grid lines hierarchically • Split lines are positioned between 2 split lines in the hierarchy • Central split line bounded by scene boundaries • Split lines are bounded by parents • E.g. C is bounded by B and D

  17. 0.5 Ratios 0.6 0.4 0.0 0.3 0.5 0.7 1.0 Positions Split Line Position versus Ratio • Each split line has an on-screen position • We store ratios for each split line • Ratio is relative distance of a split line between its bounds 0.0 0.3 0.5 0.7 1.0

  18. From Ratio to Position • Ratios store positions indirectly with respect to ancestor positions • Position = (left bound) + (ratio) x (right bound – left bound) • 0.7 = 0.5 + 0.4 x (1.0 – 0.5) • Positions can be computed in logarithmic time: ancestors in hierarchy • Positions computed only on demand, not for all objects • We may cache positions during one animation frame 0.5 Ratios 0.6 0.4 0.0 0.3 0.5 0.7 1.0 Positions

  19. Navigation Algorithm Complexity • Input: set K of split lines with final positions • Only identity and positions of red lines required for input • Output: set Q of split lines with final ratios • Algorithm determines which additional lines require a new ratio • Changing ratios of these lines to output values will move K split lines • All relative positions between red lines are preserved

  20. Running Example of a Navigation • Total number of split lines: 1023 • Selected split lines to move: 4 • Input to algorithm: K (indices) 63 191 255 639 position 0.3 0.4 0.6 0.9 final position 0.2 0.5 0.6 0.7 ratio

  21. Navigation Algorithm • Flow of our navigation algorithm: moveSplitLines Initialize resize Recurse Recurse partition interpolate getRatio

  22. Algorithm: moveSplitLines • Initialize split line set that user wishes to move • M = split line list: input from user, plus left and right bounds • S = split line for partition: root split line (index 511), exact middle • Q = output ratios list: { } moveSplitLines Initialize M (indices) 63 255 639 191 0 1022 0.3 0.6 0.9 position 0.0 0.4 1.0 final position 0.0 0.2 0.5 0.6 0.7 1.0 ratio

  23. Navigation Algorithm: resize moveSplitLines Initialize resize Recurse Recurse partition interpolate getRatio

  24. Navigation Algorithm: partition moveSplitLines Initialize resize Recurse Recurse partition interpolate getRatio

  25. S = 511 Algorithm: partition • Partitions set M according to location of S • S = 511, between 255 and 639 partition M (indices) 63 255 639 191 0 1023 position 0.3 0.4 0.6 0.9 0.0 1.0 final position 0.0 0.2 0.5 0.6 0.7 1.0 ratio

  26. Algorithm: partition output • Partition returns L and R: S S index 0 63 191 255 511 511 639 1023 initial position (i) 0.0 0.3 0.4 0.6 0.7 0.7 0.9 1.0 final position (f) ? 0.0 0.2 0.5 0.6 ? 0.7 1.0 ratio Left (L) Right (R)

  27. Navigation Algorithm: interpolate moveSplitLines Initialize resize Recurse Recurse partition interpolate getRatio

  28. Algorithm: interpolate • Interpolate determines the final position of S (index 511) • Since S must be between 255 and 639 with same ratio: • f[S] = f[left] + (f[right] – f[left]) * (i[S] – i[left]) / (i[right] – i[left]) = f[255] + (f[639] – f[255]) * (i[511] – i[255]) / (i[639] – i[255]) = 0.6 + (0.7 – 0.6) * (0.7 – 0.6) / (0.9 – 0.6) = 0.63 S S index 0 191 511 511 639 1023 63 255 position (i) 0.0 0.3 0.4 0.6 0.7 0.7 0.9 1.0 final position (f) 0.0 0.2 0.5 0.6 0.63 ? 0.63 ? 0.7 1.0 ratio Left Right

  29. Navigation Algorithm: getRatio moveSplitLines Initialize resize Recurse Recurse partition interpolate getRatio

  30. index 511 Q: ratio 0.63 Algorithm: getRatio • Finally, compute ratio for S with new final position for S • Ratio S = Final 0 + (Final 511 – Final 0) / (Final 1023 – Final 0) = 0.0 + (0.63 – 0.0) / (1.0 – 0.0) = 0.63 • Add S to Q S S index 0 56 73 300 511 511 754 1023 Position (I) 0.0 0.3 0.4 0.6 0.7 0.7 0.9 1.0 final position (F) 0.63 0.63 0.7 1.0 0.0 0.2 0.5 0.6 ratio 0.63 0.63 Left Right

  31. Navigation Algorithm moveSplitLines Initialize resize Recurse Recurse partition interpolate getRatio

  32. 511 639 M (indices) position 0.7 0.9 final position 0.7 0.63 ratio 0.63 0.32 Recursion • Each recursion step computes one split line ratio • Algorithm termination: when a partition contains no more lines to move • When M=2, bounds of S have computed positions and ratios Q: index 511 255 127 63 191 767 639 ratio 0.63 0.95 0.43 0.77 0.71 0.59 0.32

  33. Result: Algorithm Complexity • Logarithmic complexity: |Q|  |K| log |N| << |N| • Q: Lines needing ratio updates • K: Lines to move • N: All lines • Many positions change, but few ratios require updates • Moving 2 grid lines only requires changing ratios for 8 split lines • Subtrees not affected will conserve their internal ratios

  34. Speed: under 1 millisecond for |N| = 2,000,000 lines Generality: implemented in PRISAD infrastructure as proof of concept Tree, sequence dataset visualizations Results: Implementation

  35. Algorithm provides lightweight visual history Algorithm supports localized deformations Set final positions for local bounds to start positions Results: Design Goals Met Localizing boundaries

  36. Future Work • Implement stretch and squish navigation in other architectures • Support non-rectilinear deformations • Localizing regions may assist in reducing complexity

  37. Conclusions • First scalable algorithm for stretch and squish navigation • K log N performance to move K of N lines • Infrastructure for composite rectilinear navigations • Lightweight visual history • Move several region boundaries simultaneously • Localized deformation • Shown on trees and gene sequences

  38. Acknowledgements InfoVis group at UBC: Ciarán Llachlan Leavitt Dan Archambault Aaron Barsky Stephen Ingram Heidi Lam Peter McLachlan Melanie Tory

  39. Download Software • http://olduvai.sf.net/tj

More Related