new_bloom_filter_repo

I'm confused by this line here: https://github.com/ross39/new_bloom_filter_repo/blob/4798d90... It seems like this would make the compression lossy and discard, e.g., transitions from #ffffff to #fffffa, and the line above it where the mean of pixel data is taken would discard, e.g., transitions from #ff0000 to #00ff00 regardless of the threshold used. Am I misunderstanding the role of that line of code? It doesn't seem like anything that is a 0 in the resulting mask would be encoded into the bloom filter.

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.

Similar to other compression methods, it uses keyframes (which are saved frames that exist throughout the video) as the starting point, after which the next frame is a diff of that until you reach the next keyframe. It seems to generate keyframes when the compression drops below a certain level (at which point you might as well just store the compressed frame instead of the bloom bitmap). https://github.com/ross39/new_bloom_filter_repo/blob/4798d90...

Indeed, as this comparison with gzip shows: https://github.com/ross39/new_bloom_filter_repo/blob/main/co...

So, according to your graph [1] this new compression is always strictly worse than just using GZIP? [1] https://github.com/ross39/new_bloom_filter_repo/blob/main/co...