University of Salford, UK Centre for Virtual Environments - - PowerPoint PPT Presentation

University ¡of ¡Salford, ¡UK ¡ Centre ¡for ¡Virtual ¡Environments ¡and ¡Future ¡Media ¡ Carl ¡Moore, ¡Toby ¡Duckworth ¡and ¡David ¡Roberts ¡

Introduc)on ¡

 Our ¡3D ¡telepresence ¡system ¡uses ¡multiple ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡

camera ¡silhouettes ¡to ¡reconstruct ¡a ¡3D ¡volume ¡

 If ¡images ¡are ¡not ¡captured ¡at ¡the ¡same ¡time, ¡the ¡

person ¡may ¡be ¡in ¡different ¡positions ¡

 This ¡can ¡lead ¡to ¡missing ¡features ¡or ¡distortion ¡ ¡  Hardware ¡triggers ¡normally ¡used ¡to ¡overcome ¡this, ¡we ¡

investigate ¡software ¡triggers ¡as ¡a ¡possible ¡cheaper ¡ alternative ¡

Related ¡Work ¡

 Our ¡previous ¡work ¡(DS-­‑RT ¡2010) ¡showed ¡ ¡possibility ¡

• f ¡using ¡unsynchronised ¡frames ¡for ¡3D ¡reconstruction ¡

 This ¡used ¡simulated ¡models ¡and ¡movement ¡

 Prior ¡to ¡this ¡no ¡one ¡seemed ¡to ¡have ¡investigated ¡its ¡

necessity ¡

 Other ¡reconstruction ¡systems ¡appear ¡to ¡assume ¡

hardware ¡synchronisation ¡as ¡necessary ¡

 Matsumaya ¡et ¡al ¡2004, ¡Origami ¡(Grau ¡et ¡al ¡2004), ¡Blue-­‑C ¡(Gross ¡et ¡al ¡2003) ¡

and ¡Towles ¡et ¡al ¡2003 ¡ ¡

Introduc)on ¡

 We ¡focus ¡here ¡on ¡an ¡acquisition ¡trigger ¡

 Acquisition ¡– ¡Starts ¡the ¡exposure ¡cycle ¡for ¡a ¡frame ¡  Grab ¡– ¡Retrieval ¡of ¡an ¡already ¡acquired ¡frame ¡

 Differences ¡in ¡acquisition ¡start ¡times ¡between ¡

cameras ¡results ¡in ¡sub-­‑frame ¡differences ¡ ¡

 Controlled ¡by ¡hardware ¡acquisition ¡trigger ¡

 Using ¡images ¡grabbed ¡from ¡different ¡frame ¡sets ¡

results ¡in ¡larger ¡multi-­‑frame ¡differences ¡

 Controlled ¡by ¡software ¡buffer ¡management ¡

Introduc)on ¡

 Push ¡

 Acquisition ¡triggered, ¡continues ¡at ¡regular ¡intervals ¡  No ¡delay ¡between ¡captured ¡frames ¡

 Pull ¡

 Acquires ¡single ¡frame ¡and ¡waits ¡for ¡next ¡trigger ¡  Decreased ¡frame ¡rate ¡and ¡latency ¡due ¡to ¡waiting ¡for ¡

exposure ¡

 Pull ¡Approach ¡2 ¡

 Acquisition ¡triggered, ¡continues ¡at ¡regular ¡intervals ¡  Frame ¡returned ¡when ¡requested ¡

Approach ¡

 Project ¡a ¡millisecond ¡clock ¡onto ¡the ¡floor, ¡visible ¡by ¡

all ¡cameras ¡

 102Hz ¡display ¡gives ¡us ¡granularity ¡of ¡9.8ms ¡  Capture ¡a ¡number ¡of ¡frame ¡sets ¡using ¡software ¡trigger ¡

with ¡UDP ¡broadcast ¡

 Compare ¡digits ¡in ¡returned ¡frames ¡to ¡discover ¡level ¡of ¡

synchronisation ¡

 Exposures ¡reduced ¡(1ms) ¡to ¡allow ¡clear ¡capture ¡of ¡

digits ¡

 Gain ¡increased ¡to ¡compensate ¡for ¡low ¡light ¡

Projected ¡Clock ¡

System ¡

 We ¡used ¡6 ¡cameras ¡connected ¡to ¡3 ¡capture ¡nodes ¡  Capture ¡nodes ¡connected ¡to ¡server ¡through ¡gigabit ¡

network ¡and ¡router ¡

 102Hz ¡projector ¡for ¡clock ¡projection ¡  Application ¡to ¡broadcast ¡UDP ¡to ¡capture ¡nodes ¡  Software ¡at ¡capture ¡node ¡to ¡trigger ¡acquisition ¡and ¡

save ¡

Results ¡

 48 ¡frame ¡sets ¡captured ¡in ¡total ¡  42 ¡sets ¡showing ¡exact ¡clock ¡digits ¡ ¡

 Must ¡have ¡been ¡captured ¡within ¡10ms ¡frame ¡

 5 ¡sets ¡with ¡two ¡clock ¡frames, ¡some ¡blur ¡between ¡two ¡

 Captured ¡during ¡clock ¡update ¡ ¡

 1 ¡set ¡contains ¡two ¡clearly ¡different ¡clock ¡frames ¡ ¡

 Could ¡mean ¡acquisition ¡start ¡difference ¡of ¡1-­‑20ms ¡ ¡

Timing ¡a ¡Pull ¡System ¡

 Used ¡the ¡same ¡software ¡with ¡automated ¡trigger ¡

 Trigger ¡sent ¡after ¡previous ¡set ¡received ¡

 Exposure ¡times ¡increased ¡for ¡normal ¡capture ¡mode ¡  Added ¡compression ¡to ¡reflect ¡real ¡data ¡transfer ¡sizes ¡  Timers ¡in ¡system ¡

 When ¡request ¡sent ¡and ¡received ¡  When ¡frames ¡send ¡and ¡when ¡full ¡set ¡of ¡frames ¡received ¡

Results ¡

 Total ¡round ¡trip ¡time ¡for ¡requesting ¡and ¡receiving ¡a ¡

full ¡set ¡of ¡frames ¡was ¡62ms ¡

 45ms ¡spent ¡acquiring ¡and ¡encoding ¡  17ms ¡spent ¡sending ¡and ¡receiving ¡

 Time ¡a ¡bit ¡high, ¡early ¡implementation ¡  Expect ¡around ¡12ms ¡for ¡12-­‑camera ¡system ¡

Discussion ¡

 17ms ¡would ¡cut ¡FPS ¡by ¡nearly ¡45%, ¡12ms ¡by ¡about ¡35% ¡  Pull ¡requests ¡could ¡be ¡managed ¡to ¡reduce ¡acquisition ¡

delays ¡

 Overlapping ¡frame ¡receive ¡and ¡subsequent ¡

acquisition ¡removes ¡a ¡large ¡portion ¡of ¡delay ¡ ¡

Discussion ¡

 Provides ¡easy ¡synchronisation ¡of ¡grabbed ¡frames ¡  Exposure ¡does ¡no ¡start ¡until ¡request ¡is ¡made, ¡adds ¡

delay ¡in ¡grabbing, ¡equal ¡to ¡exposure ¡(21ms) ¡

 Simple ¡form ¡less ¡acceptable ¡for ¡real-­‑time ¡

communication ¡than ¡other ¡two ¡approaches ¡ mentioned ¡

 Better ¡request ¡management ¡could ¡mask ¡latency ¡in ¡

some ¡systems ¡

Real ¡Test ¡ ¡

 Test ¡in ¡our ¡system ¡demonstrated ¡good ¡results ¡  Fast ¡moving ¡ball ¡captured ¡in ¡juggler ¡sequence ¡using ¡

• nly ¡software ¡acquisition ¡trigger ¡

 All ¡reconstructions ¡captured ¡at ¡Salford ¡have ¡used ¡

software ¡acquisition ¡trigger ¡

Future ¡Work ¡

 10ms ¡granularity ¡of ¡timing ¡could ¡be ¡refined ¡  Same ¡approach ¡using ¡a ¡higher ¡frequency ¡display ¡

device ¡would ¡achieve ¡this ¡(LED ¡Sequencer) ¡

 Millisecond ¡and ¡possibly ¡sub-­‑millisecond ¡achievable ¡ ¡

 Compare ¡output ¡with ¡model ¡generated ¡from ¡

hardware ¡synchronised ¡cameras ¡

Conclusion ¡

 Software ¡triggering ¡of ¡image ¡acquisition ¡produces ¡

good ¡results, ¡as ¡seen ¡in ¡juggler, ¡with ¡fast ¡moving ¡

• bject ¡

 In ¡a ¡system ¡like ¡ours, ¡software ¡acquisition ¡triggers ¡

would ¡likely ¡provide ¡an ¡acceptable ¡level ¡of ¡ synchronisation ¡for ¡3D ¡telepresence ¡

Ques)ons ¡ ¡

 Thanks ¡for ¡listening ¡