ITK Release 4/Video/Time Stamp: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
 
(4 intermediate revisions by the same user not shown)
Line 89: Line 89:
** istream >> should reconstruct the object.
** istream >> should reconstruct the object.
** when sent to file formats then we will be subject to the file format representation (just as we are with images).
** when sent to file formats then we will be subject to the file format representation (just as we are with images).
* Manage conversion between Dates and microseconds by using the Unix conversion algorithms.
* '''Internal''' implementation (private)
** TimeStamp will use a timeval struct
** TimeInterval will use a double
* '''Error''' management: Needs more discussion
** Do we want an ErrorValue to be stored in the TimeStamp and / or the TimeInterval ?
** Should error be managed only through exceptions ?
** Should there be a default value ?
*** If so, should there be a way of checking for it ?
*** How to avoid the subsequent code to be saturated with "if"s.

Latest revision as of 15:19, 29 November 2010

Reference Systems

VRPN - UNC

URL

http://www.cs.unc.edu/Research/vrpn/vrpn_getting_started.html

Time Stamp Structure

<source lang="cpp"> struct timeval

 {
   __time_t tv_sec;		/* Seconds.  */
   __suseconds_t tv_usec;	/* Microseconds.  */
 };

</source>

OpenCV

  • include/opencv/cv.h: double timestamp
  • src/cv/_cvipp.h: float timestamp
  • 3rdparty/include/ffmpeg_/avformat.h: int64_t timestamp;

KWSys

  • static double GetTime();

ITK RealTimeClock

System Time

Scales

If counting from a given starting point (forward):


  • int32 : can count in microseconds, up to 4.5 years
    • 2**32 / (30 * 3600 * 24.0 * 365 ) = 4.5 years
  • double : can count in microseconds, up to 285 years (before losing any precision)
    • 2^53 / ( 1000000 * 3600 * 24.0 * 365 ) = 285
    • after that it will be counting in tens of microseconds...
  • int64 : can count in microseconds, up to 584942 years
    • 2**64 / ( 1000000 * 3600 * 24.0 * 365 ) = 584942
    • (or in nanoseconds up to 584 years)


If counting relative times:

  • int32 -> will use the sign, and can count (-2.4, +2.4) years
  • double -> and can count (-142, +142) years
  • int64 -> (-292471, +292471) years

Units

  • Should the time units be specified ?
    • Use microseconds ?

Proposal

  • Use double as internal representation
  • Use micro-seconds as unit
  • Have convenience methods to return time in other units
    • seconds, hours, days
  • Have convenience methods for computing differences between two times
  • Encapsulated type:
    • External time representation = double in microseconds
    • Internal time representation is private and is not exposed
  • Two Classes
    • TimeStamp
    • TimeInterval
    • TimeInterval = TimeStamp - TimeStamp
    • TimeStamp = TimeStamp + TimeInterval
    • Time operations will be implemented in these two classes.
    • They will have to be as efficient as double or int64 arithmetics.
  • "Get" methods only available for debugging
    • TimeStamp.GetTimeInSecondsSince1970();
  • Serialization
    • ostream << (controlled by ITK)
    • istream >> should reconstruct the object.
    • when sent to file formats then we will be subject to the file format representation (just as we are with images).
  • Manage conversion between Dates and microseconds by using the Unix conversion algorithms.
  • Internal implementation (private)
    • TimeStamp will use a timeval struct
    • TimeInterval will use a double
  • Error management: Needs more discussion
    • Do we want an ErrorValue to be stored in the TimeStamp and / or the TimeInterval ?
    • Should error be managed only through exceptions ?
    • Should there be a default value ?
      • If so, should there be a way of checking for it ?
      • How to avoid the subsequent code to be saturated with "if"s.