4 ms·
Ok, let's do some math. Let's assume image compression randomly flips the last bit of every pixel (this is a crude approximation but it should do). Let's furt
by MauranKilom 5y ago
Ok, let's do some math.
Let's assume image compression randomly flips the last bit of every pixel (this is a crude approximation but it should do).
Let's further assume your original image was 1k x 1k and was shrunk by a factor of 3, so each downscaled pixel is the average of 9 original ones.
Let's then assume that all nine pixels have to "flip" in a specific way to change the downscaled one, so a 1/2^9 chance.
The odds of this bit flip propagating past the last two bits you dropped are 1/4 (dropping bits is not very effective at combating random behavior!).
That means there is a 1/2^11 chance that adding compression to the pipeline changes any given downsampled channel-pixel in the 360px/6-bit-per-color hash input.
The SHA256 stays the same if this does not happen in any of the 360 x 360 x 3 channel-pixels. The odds of that are (1 - 1/2^11)^(360*360*3) = 3.4e-83. You could drop two more bits and the odds would still be 2.4e-21 (each dropped bit amounts to taking the square root).
In effect, your suggested scheme would simply never assign the same hash with any amount of compression happening.
Fundamentally, you still have way too many pixels that might spuriously change from tiny perturbations of the input image. Reducing resolution further is actually much more effective than dropping bits, because it both increases the averaging effect and reduces how many pixels have a chance to flip.
- nullc 5y agoIndeed, you're right.