Development Planning

Status

As of April 2020:

• Basically, slowmoVideo still compiles and runs!
  • Rendering is unstable
• No active development, valgit and granjow actively coded years ago
• No recent downloads and outdated docs
• Hard to compile for non-Linux systems
• UI seems hard to understand

Topics

General improvements

• Check if newer/faster optical flow implementations are available
  • Which properly support GPUs and which is maintained
  • For example, NVIDIA Optical Flow
• Improve handling flow builders, e.g. register different flow builders in the UI
  • It still makes sense to keep the flow builders separate from the main application as they can have arbitrary dependencies. Executable, library, …?
• Provide different caching mechanisms (use a caching layer for abstraction) like in-memory, storage, compressed, …
• Make sV compile on Linux, OS X, and Windows
• Improve building
  • Split V3D part to separate project
  • Move CMakeLists to project roots
  • Provide libraries required for building flow (easiest way is probably a submodule)
• Upgrade to C++11 etc.
• Upgrade to OpenCV 4

Projects + Rendering

• Improve file structure. Options:
  • For a project foo, always create an empty directory foo containing project.sVproj
• Extract frames in the background when opening a new project
• Render in background
• Multi-threaded rendering

Docs

• Make web site repository public
• CI/CD for web site
• Update documentation

Re-usability

• Provide library usable by other projects like Kdenlive (video editing) through MLT
• Start renderer as a service which recieves frames and returns interpolated frames
• Support (or use) [.flo](http://vision.middlebury.edu/flow/code/flow-code/) for saving optical flow files
  • This would allow users to use tools like floviz

CLI

• Instead of rendering directly, generate a script which uses the renderer to render a project
• Extend the renderer executable to support rendering a video directly without having to generate a project file, e.g. by setting a constant speed an in/out points or by providing a serialised curve

UI

• Snap nodes to an exact frame to avoid recomputation (requires knowledge about output fps)
• Set curve steepness (e.g. to exactly 50 %)
• Play a preview with a dot moving on the curve to get a better understanding of what will happen
  • And/or with raw input frames
• Show help overlay by default
• Improve zooming
  • Zoom to curve
  • Zoom to selected rectangle

CI

• Packages on GitHub Packages
• Automated build with Actions

Stability

• Do not accidentially purge HOME as in #130
• Add more unit tests