# LiViM: real-time Eulerian video magnification in a Qt 6 desktop app > LiViM wraps three Eulerian video magnification algorithms in a Qt 6 GUI for webcams and video files, and ships prebuilt packages for Linux, Windows and macOS. It is a solo project, heavily AI-assisted by the author's own admission, and the documentation is thinner than the feature list suggests. **tschnz/Live-Video-Magnification** — Real‑time Eulerian video magnification: amplify subtle motion & color from webcam or video. Linux/Windows/macOS - Repository: https://github.com/tschnz/Live-Video-Magnification - Stars: 547 · Forks: 119 - Language: C++ - License: AGPL-3.0 - Published: 2026-09-17 · Updated: 2026-09-17 · Language: en - Canonical page: https://hysenlabs.com/projects/tschnz-live-video-magnification ## What LiViM amplifies, and who the tool is for Eulerian video magnification takes an ordinary video and multiplies tiny temporal changes in pixel values until they become visible. A wrist pulse, a vibrating machine panel, a breathing chest: all of it is present in the frames but below the threshold of the eye. LiViM is a desktop application that does this live, from a webcam or a file, and shows the result in the same window as the original. The audience is narrow and practical. Someone with a camera pointed at equipment that should not be moving, a student who wants to see the SIGGRAPH 2012 effect without reimplementing the pyramid, or anyone who needs a quick visual check before committing to a measurement rig. The README states plainly that the algorithms and pipeline date back to the author's 2015 bachelor thesis at Universität Tübingen, and that reviving the work into a program that does not crash every other click was the goal. That framing matters: this is a usable front end over published research, not a new method. It is not a measurement instrument. Nothing in the README mentions calibration, physical units or accuracy bounds, and the output is a magnified video, not a number. ## Three magnification algorithms and the pyramid behind each The processing panel exposes three modes, and they are genuinely different pipelines rather than presets. Motion (Laplace) uses a Laplacian pyramid with a temporal IIR bandpass filter. This is the classic Eulerian motion approach from Wu et al., SIGGRAPH 2012. It is the mode with the most parameters: amplification, cutoff wavelength, the frequency band, chroma attenuation and pyramid levels all apply. Motion (Phase) uses a Riesz pyramid with a Butterworth bandpass, following Wadhwa et al. from SIGGRAPH 2013 and ICCP 2014. The README describes it as less noisy than the Laplacian path. It drops chroma attenuation but keeps the rest. Color uses a Gaussian pyramid with an ideal FFT bandpass over a rolling window, aimed at effects like blood flow. It has no cutoff wavelength control, which makes sense: the spatial cutoff belongs to the motion paths. Two constraints in the parameter table are worth reading twice. The frequency band is capped at Nyquist, defined in the README as Capture FPS divided by two, so a 30 fps source cannot be magnified above 15 Hz. And Capture FPS is a separate field from playback rate. The README is explicit that for high-speed footage played back slowly you must enter the real capture rate, giving 1000 as the example, regardless of how slowly it plays. Get that wrong and the Hz band you set has no relation to the physical motion. ## Installing a prebuilt LiViM package and running a first magnification The README points to the Releases page for binaries rather than a package manager. Linux gets .deb, .rpm and .AppImage for x86_64, Windows gets an NSIS .exe and a portable .zip for x86_64, and macOS gets a .dmg for Apple Silicon. There is no Homebrew formula, no winget manifest and no Flatpak mentioned. On macOS, Gatekeeper blocks the app on first launch. The README gives two ways past it: right-click then Open, or strip the quarantine attribute from the terminal. ```bash xattr -dr com.apple.quarantine /Applications/livim.app ``` On Windows the installer triggers SmartScreen, and the README says to click More info then Run anyway. On Linux your user must be in the video group for camera access. The video view needs OpenGL 3.3 with a core profile, which is the one hard hardware gate in the documentation. Once the app is open, the workflow is: open a file or camera, choose a Display mode, then tune Processing. Original doubles as the off switch because it skips magnification entirely, which is a clean way to compare. Reset restores the current mode's defaults. F11 toggles fullscreen and Esc leaves it. For a first run, pick Motion (Phase), set Capture FPS to the true rate of your footage, and pull the dual-handle frequency slider to the band you care about. The slider shows BPM alongside Hz, so a pulse-related band is easier to dial in than it sounds. If the machine cannot keep up, the README's remedy is to lower the processing resolution, which ranges from 1/1 to 1/8, or shrink the ROI. ## What happens when the machine cannot keep up LiViM handles overload differently for files and cameras, and the difference is the most important operational detail in the README. For video files, playback runs at the rate set next to the FPS readout. If processing falls behind, playback slows down instead of dropping frames. Nothing is buffered ahead, so the app stays frame-accurate but runs in slow motion. The README's answer is to use Export when you need the full-rate result, because file exports re-decode the chosen range at full quality. For cameras, frames are simply dropped under load. There is no slow-motion fallback because the hardware sets the pace. Lowering processing resolution or shrinking the ROI are the two levers the README names. Export itself has a hard ceiling worth knowing before you plan a session. File exports re-decode the selected range, so they are bounded by disk and CPU. Camera exports first record raw frames into RAM, and the README states that recording stops automatically at 8 GB because the buffer grows quickly. A long camera capture will therefore end on its own, not on your command. Exports are also video only, with no audio track. ## Where LiViM is the wrong tool The absence of a scripting interface is the first limitation. Everything in the README describes a GUI: a drawable ROI, dual-handle sliders, display modes, a theme that follows the OS. There is no CLI, no Python binding and no library target documented, so a batch job over a hundred clips means a hundred manual sessions. If you need Eulerian magnification inside a pipeline, the reference implementations from the MIT CSAIL project are the more sensible starting point, and the Python implementations that appear in search traffic are a different codebase entirely. Second, the project is honest about its own provenance. The README's closing section says the app is heavily vibecoded and that the author is a solo developer with a full-time job. That is a candid statement about review depth, and it should shape how much you trust edge cases in a tool that touches camera drivers and video codecs. Third, the output is visual. There is no documented way to extract the magnified signal as data, no CSV, no frame dump. If your question is quantitative, LiViM answers a different question. Finally, the platform matrix has a gap: the macOS build is Apple Silicon only, and the README lists no Intel Mac package. ## How LiViM differs from the MIT CSAIL reference code The MIT CSAIL video magnification project is the obvious alternative, and the difference is not the algorithm. LiViM implements the same published techniques, and the README links the original papers directly. The difference is the delivery: CSAIL publishes MATLAB and Python code that you run from a script or notebook, with no GUI, no camera capture layer and no export dialog. That makes the trade-off concrete. CSAIL code gives you a function you can call in a loop, inspect and modify. LiViM gives you a real-time viewer with a frame-accurate timeline, V4L2, Media Foundation and AVFoundation capture, side-by-side and top-and-bottom comparison views synced to the same frame, and three export formats: MP4 with H.264, AVI with MJPG, and MKV with FFV1 for lossless output. You trade programmability for immediacy. A second alternative is any of the Python Eulerian implementations that show up in search traffic. Those are separate projects with their own accuracy and maintenance characteristics, and LiViM's README does not compare itself to them, so the comparison is not one this article can make on the project's behalf. ## Licence, build cost and what upgrading involves LiViM is AGPL-3.0. For a desktop tool you run yourself, that is unremarkable. For anyone who wants to embed the magnification pipeline in a network service, the AGPL's source-availability obligation is the reason the README notes that a separate commercial licence is available from the maintainer. That is a statement of fact from the README, not legal advice; the terms of your own use are for you and a lawyer to settle. The third-party components are dynamically linked and listed with their licences: Qt 6 under LGPLv3, OpenCV under Apache-2.0, and FFmpeg under LGPLv2.1+ with no GPL components. Dynamic linking is what keeps the Qt obligation at the level it is, so a build that statically links Qt would be a different licensing situation. Building from source is a real cost. Dependencies come through vcpkg, and the README warns that the first configure compiles them, taking roughly 30 to 90 minutes, once. You need a C++20 compiler, CMake 3.25 or newer, Ninja, nasm, and VCPKG_ROOT set in the environment. ```bash scripts/setup-linux.sh --configure cmake --build --preset gcc-release && ./build/gcc/RelWithDebInfo/livim ``` The script installs system packages through apt, dnf or pacman and bootstraps vcpkg. Windows presets assume a VS 2022 x64 Native Tools prompt, and macOS presets need cmake, ninja, nasm and pkg-config from Homebrew. The release preset is RelWithDebInfo, not a stripped release build. cmake --list-presets shows what your machine offers. Upgrade cost is low if you use the binaries: the project's first tagged release is v0.1.0, dated 2026-08-01, and the last push to main was on 2026-08-01 as well. There is no migration path to worry about yet because there is only one release. The README does not document rollback, a changelog or a compatibility policy between versions. ## Conclusion Adopt LiViM if you want to see the Eulerian effect on live camera input without writing the pipeline yourself, and you are comfortable with an AGPL-3.0 desktop binary from a solo maintainer whose README calls the code heavily vibecoded. Do not adopt it if you need a scriptable library, audio in exports, or a supported commercial product without a separate licence. Before relying on it, verify three things: that your GPU exposes OpenGL 3.3 core profile, that the magnification band you need sits below the capture FPS divided by two, and that the 8 GB camera-export buffer is enough for the clip length you intend to record. ## FAQ ### What is Eulerian video magnification? It is a family of techniques that amplify motion and color changes in a video that are too subtle to see by eye. LiViM implements the MIT CSAIL variants, including the Laplacian pyramid and Riesz pyramid motion methods and a Gaussian pyramid color method. ### How do motion amplification cameras work? LiViM is not a camera; it is software that processes frames from a webcam or a video file. The README describes three pipelines, each combining a spatial pyramid with a temporal bandpass filter, and the motion modes use a Laplacian or Riesz pyramid. ### What does +2 magnification mean? The README does not define a +2 notation. LiViM exposes an Amplification parameter per mode, described as effect strength that also amplifies noise, with no numeric scale documented in the README. ## Sources - [Issues](https://github.com/tschnz/Live-Video-Magnification/issues) - [License: AGPL-3.0](https://github.com/tschnz/Live-Video-Magnification/blob/main/LICENSE) - [README](https://github.com/tschnz/Live-Video-Magnification/blob/main/README.md) - [Releases](https://github.com/tschnz/Live-Video-Magnification/releases) - [tschnz/Live-Video-Magnification on GitHub](https://github.com/tschnz/Live-Video-Magnification) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tschnz-live-video-magnification