I suspect this works better because the input videos (Youtube videos) have already been compressed and decompressed.
With raw video input, I think the assumption "most pixels change little (or not at all) between consecutive frames, creating a sparse difference matrix ideal for this approach." would break down. For a very clean signal (low-noise sensor, brightly lit scene), maybe it'd work, but most real-world signals will have noise > 1 LSB, so I'd expect the lower bits to be changing at least half the time.
Sending the video through a compression and decompression cycle first will tend to remove that noise, creating an artificially static video where that assumption holds up.
From what I can tell, it also isn't lossless: https://github.com/ross39/new_bloom_filter_repo/blob/main/vi...
This looks like it is not storing the diff for any pixel that had the mean of its r,g,b values change by less than 10, which means that if a pixel goes from pure blue (#00ff00) to pure red (#ff0000) in consecutive frames, it would decode as pure blue in both frames.
It'd be better to convert to HSL, and compute the distance from there.
HSL-distance preserves color similarity with higher fidelity than converting both pixels to greyscale as done in the shared link
That doesn’t address the issue at all. The issue is that discarding small changes in any color space is fundamentally lossy, so the algorithm isn’t lossless.
Well yes.. I agree.
But my comment was addressing parent's point that pure blue and pure red are currently considered close together since they share the same greyscale values.
You mean something like L*ab, right, not HSL? HSL is a pretty terrible approximation to human vision.
Just like you wouldn't use PNG for photography, I don't think you'd use a lossless video codec for real-world footage.
Lossless video would make much more sense for digital content like screen recordings, where the assumption that few pixels change between consecutive frames makes much more sense.
Lossless formats (specifically DPX & EXR sequences, usually with ZIP compression) are used frequently for real world footage in post-production workflows! Granted, most consumers don't run into this stuff. Photographers don't use PNG because it doesn't offer anything for them that camera raw or EXR files don't already cover.
As far as video types go maybe it would work well for animation since that tends to compress well for the same reason a screen recording does.
Sure you do. E.g. ffv1 and huffyuv are used for archiving video losslessly.
HEVC/H.265 and VP9 can both also operate in lossless mode. In my testing they achieve compression ratios that ffv1 and huffyuv cannot come close to touching (not all that surprising given how old ffv1 and huffyuv are).
Ffv1 is much easier to work with compared to HEVC and VP9 though, probably thanks to it's deep integration with ffmpeg. By comparison, working with HEVC was hell on earth!
I spent like a week figuring out how to stuff JPEG sequences into HEVC files without losing colorspace and color profile information. Even JPEGs alone were horrible to work with, my understanding is they encode image data in the YUV444P colorspace, but every program works with them in the RGB colorspace. The conversion between YUV444P <-> RGB is lossy and every program does the conversion slightly differently. So if I ever accidentally triggered this conversion at any point, my archival was no longer bit-perfect.
And then to check your results, you obviously can't convert back to JPEGs, I think I ended up encoding to TIFF after having failed with JXL.
Code here if anybody else wants to try replicating it (good luck, you'll need it): https://gist.github.com/null-dev/ebd2f8b23c3e5066a48976c7308...
Converting lossy JPEGs to lossless HEVC might seem wasteful, but the space saved by intra-frame compression dwarfs the space saved by lossy encoding.
Losssy compression is standard on high end cinema cameras.
In most cases the compression ratio will be low enough that the video will be perceptually lossless.
Normal people never use raw, so that might not big a big issue. Phones and cameras store files in MP4 or AV1 or whatever anyway.
Unless you know to turn it on and deal with the files sizes and processing people may not realize concept of raw/unprocessed exists anymore.
I’d never thought about that before.
> I'd expect the lower bits to be changing at least half the time.
I didn't read the code, but the readme focuses on whether less than 32.4% of bits are 1. So even if a lot of the pixels are changing at the lower bits between each frame, so long as enough of the upper bits aren't changing, it should still in principle work?
The lazy approach is to download an 8K video and downsample it to something like 720p.
Or just buy a camera and run around capturing some raw 8K footage of everyday scenes.