A layout-break check ignores up to 81,920 changed pixels in a 1280x800 frame

Take the constants at their stated values and the check has a floor. Both captures are resized to 1280 by 800 before anything is compared ^[8], which is 1,024,000 pixels ^[1]. The aggregate threshold is 8 percent of the frame ^[11], so 81,920 pixels have to register as changed before `compare_screenshots()` reports a layout change ^[2]. A pixel only registers if its brightness differs from its counterpart by more than 25 out of 255 ^[10], roughly a tenth of the available range ^[3].

That floor is deliberate on the noise side. The dev.to writeup argues that a rotating banner or a latest-posts block can redraw between captures without pushing the whole-frame change rate past 8 percent. That holds as long as the block occupies only part of the frame ^[12]. It cuts the other way too. A region of 320 by 240 pixels is 76,800 pixels, 7.5 percent of the resized frame, so a break confined to it stays under the threshold however wrong it looks ^[4].

Both constants are claims about the pages this tool watches. They transfer to yours if your legitimately dynamic areas (ad slots, timestamps and rotating widgets are the cases named ^[5]) total under 81,920 pixels after the resize. The breaks you care about also have to move more than that ^[8]. The post leaves both areas unmeasured.

Preprocessing decides what counts as noise before either threshold sees it. Grayscale conversion drops colour so the comparison runs on luminance and layout pattern ^[8][9]. A change that alters hue while holding brightness constant therefore produces a per-pixel difference of zero, well under the 25-level tolerance ^[5]. The `ImageFilter.SMOOTH` blur is there to absorb the few-pixel jitter that font anti-aliasing produces between two captures of an unchanged page ^[9]. It absorbs a genuine shift of the same few pixels along with it ^[6].

The best part of the writeup is a failure with nothing to do with image processing. The before screenshot was originally written to `before_{safe_name}.jpg`, a filename derived from the site's display name ^[13]. Users rename sites during normal operation. After a rename the code looked for a name that no longer matched the file on disk, so the stored capture became permanently unreachable and the comparison could not run at all ^[14]. A rename is routine, so it arrives as housekeeping and never as a bug report. A before/after check spans two captures separated by an arbitrary amount of user activity, so its key has to be something the user cannot edit.

The fix keys the filename to an internally assigned UUID (`_id`), with `take_before_screenshot()` calling `site_paths.is_valid_site_id()` and using the ID-based path when that check passes ^[15]. The name-based path survives as a fallback for legacy records that predate the `_id` field ^[15]. Those records stay keyed on a string the user can still change ^[7].