Repository navigation
OpenOSV 0.5.2
Pre-releaseOpenOSV 0.5.2: the seam as one field
0.5.1 lined the car body up across the seam, but it did so by switching column by column between a 1-D shift table and a 2-D flow grid, and every switch put a kink into whatever straight line crossed the seam: the car roof and the hood crease waved. The picture also changed between playing and parking, because a frame played during playback borrowed corrections measured on itself. 0.5.2 replaces that three-part correction with one mesh warp, fixes playback at the cause, survives a recording that lost a key picture, and lets the camera's .LRF stand in as Premiere's proxy.
What's fixed
- Straight lines stay straight across the seam. The seam correction is now one smooth field over the seam band, solved at once from the measured parallax, the straight edges detected in both lenses, a shape term that falls to zero away from the seam, and the previous moment's field. There is nothing left to switch between, so there is nothing to kink. On the day drive's hood a panel gap crossing the seam runs within 0.16 px of a straight line instead of 0.55 px (largest bend 0.9 px instead of 3.7 px), detected edges bend 7-14 times less at the seam, and the car body lines up better than before (0.992 against 0.971, median of 18 moments). The 6K sample's propeller blade, which bent at the seam in 0.5.1, renders single and straight.
- Playback shows the frame you get when you stop. Each 8-frame bucket is measured once, on its first frame, and every frame of it renders the same playing or parked. On the day drive's hood, 0.5.1 played 11 of 17 frames differently from the same frames parked (a bolt on the seam sat 2.3 px off); the measured frames are now byte for byte the parked ones. The seam's carve is steered around the sun ghosts of the bucket's first frame, whichever frame carves it. A bucket still being measured shows the previous bucket's correction until its own lands.
- The seam moves less from one moment to the next. Each bucket's field leans on the bucket before it, so measurement noise is held still while a real change (a car passing) still comes through: the field changes 1.4-1.6 times less between buckets.
- A clip that dropped frames no longer fails a whole second of frames. When the camera drops frames it can drop one lens's key picture with them, and no decoder can produce the pictures up to the next key picture (a night drive: 49 frames of one lens). Premiere got an error for each, after the importer had decoded the whole group twice for nothing, and the log blamed "the stream's timing". The decoder now recognises such a run the first time it crosses it, names it in the log, and shows the last frame before the run on both lenses, levelled with that frame's own attitude, at no decode cost. Every other frame is unchanged, bit for bit.
- An
.LRFfinds its.OSVwhen the.OSVwas renamed by a copy (CAM_..._D-001.OSVbesideCAM_..._D.LRF), so it plays on the.OSV's timeline instead of its own 25 fps one. Two such copies beside one.LRFare left alone. A project that used such an.LRFon its own will see its timing change on reopen. - The importer offers Premiere a settings block for every clip. In the 0.5.0 and 0.5.1 sessions the OpenOSV Source Settings effect never received the per-clip block Premiere hands it, so changes in the clip's Source tab never reached the picture or the project. The importer now offers that block when it opens a clip that has none. Whether Premiere keeps it still has to be confirmed live: launch Premiere once with Shift held after installing, change Colour Output on a clip's Source tab, and see whether the monitor follows. The Source Settings effect is now version 1.1.0 (0.5.1 added Hide Mount but kept 1.0.0); a 0.5.0 project restores every value by its id, with Hide Mount On.
What's new
- The camera's
.LRFbecomes the.OSV's proxy. With Auto-apply on, the OpenOSV panel attaches the.LRFbeside each dropped.OSVas its Premiere proxy (once per master clip, never over a proxy that is already there), and Attach .LRF proxies does it for the clips already in a sequence. Toggle Proxies in the Program Monitor then edits on the light file; export still uses the.OSV. The UXP panel now asks for file access to find the.LRF. osvtool seam --meshscores the new field against the correction it replaces;osvtool render --purpose exact|interactive|playback|playrenders the way Premiere asks during playback, so playback and a parked frame can be compared byte for byte;osvtool decode-replay <clip> --trace <plug-in log>replays the frames a Premiere session asked for, in its order and from its threads, and compares every picture with a sequential software decode.
Good to know
- On the night drive the car body next to the mount's blind arc lines up a little worse than in 0.5.1 (0.72 against 0.77 at one moment, 0.92 against 0.95 at another): there is no overlap to measure there, and 0.5.1 copied a neighbour's correction into it. The 6K sample's stick strip is 0.004 worse for the same reason. Lamp poles beside the seam are as straight as before within a few hundredths of a pixel.
- The clip-wide correction (Parallax Grid Steady, and Auto when it chooses Steady) takes about a third longer to measure, because every sample frame is measured twice. Auto now holds the day drive steady and lets the 6K aerial sample follow the scene, the other way round from 0.5.1.
- A smeared
.LRFframe at 1/4 playback resolution in Premiere is not the decoder: the frames a session asked for replay bit for bit. What produces it after decoding is still being looked for. - The 6K sample clip's lens overlap renders differently from 0.5.1 on purpose (the field, and Auto's choice); everything outside the seam band is byte for byte the same.
How to update
Close your editor, unzip the zip for it and double-click Install.cmd. Premiere users: launch it once holding Shift so it picks up the updated Source Settings effect.
Downloads
OpenOSV-0.5.2-premiere-windows-x64.zip: Premiere ProOpenOSV-0.5.2-resolve-windows-x64.zip: DaVinci Resolve (preview)OpenOSV-0.5.2-vegas-windows-x64.zip: VEGAS Pro 17.0 (experimental)
ffmpeg-9.0.1-source.tar.gz and ffmpeg-9.0.1-vcpkg-port.zip are the source of the FFmpeg build the zips ship (LGPL-2.1).
SHA-256
0a05c9c2863f11ba17dc5c123e67eb42d164193f1a7f5b508b008a6a90fea5e9 OpenOSV-0.5.2-premiere-windows-x64.zip
86c6c753f927575d2c1b2a3c4874b3631d56dc7eea8a8dea8350364ceb87a618 OpenOSV-0.5.2-resolve-windows-x64.zip
d98b3ca37c4221eb43a2c79858e618fc089d320bc1b380699cd42d89c292fd69 OpenOSV-0.5.2-vegas-windows-x64.zip