It's absent from this graph, but I'd imagine the bloom filter approach could be at least be faster than gzip. But I don't see perf metrics anywhere else...
Also, if you want fast, good compression, use zstandard not gzip.
Ultimately the data they are storing is tuples of (x,y,r,g,b), which means that it is not sufficient to ask "does (x1,y1) pass the bloom filter?" which would be embarrassingly parallel; you have tobe able to match it to an index in your list of (r,g,b) data.
The way this is done is to iterate over all (x,y) in a consistent order for encoding and decoding, and for each (x1,y1), if it passes the bloom filter, then the next (r1,g1,b1) tuple is the pixel data for that pixel.
There are probably other reasons why this is a bad idea but I'm curious to try it.