Where to cut a long screenshot, and why the obvious answer is wrong
Splitting an image into pieces is arithmetic that a beginner can write: take the height, divide by the number of parts, cut there. It works perfectly and produces a bad result, because the one thing the arithmetic cannot know is that row 4,000 happens to run straight through the middle of a line of text. Half a sentence at the bottom of one image and half at the top of the next is the signature of a split done this way, and it is the reason people go back to doing it by hand in an image editor.
The fix is to stop treating a cut as a position and start treating it as a preference. The even division says where the cut would ideally go; the picture gets a say in where it actually goes. Allow each cut to move by around a line and a half, and there is almost always somewhere better within reach, because text is not continuous. It comes in lines with gaps between them, in bubbles with padding around them, in sections with rules between them. A capture that looks dense is mostly empty rows.
Finding them needs a measure of how busy a row is, and the cheapest useful one is counting transitions: walk the row and count how often the colour changes by more than a hair. A row crossing text changes at every character edge and scores in the hundreds. A row in the gap between paragraphs scores zero. This is not edge detection, and deliberately so: it runs on a phone over tens of thousands of rows, and one comparison per pixel with no arithmetic is what keeps it instant.
Two rules keep the nudging honest. A cut only moves somewhere strictly quieter than where it already is, so a photograph or a gradient, which has no quiet rows anywhere, keeps its even division instead of being pushed around by noise. And among equally quiet rows the nearest wins, because a run of thirty blank rows would otherwise always snap to its first one and drag the cut further than it needed to go.
The last decision is about memory, and it is the one that separates a demo from a tool. Scoring every row means reading every pixel, and a 1,000 by 20,000 capture is 80 MB of RGBA, which is enough to end the tab on a phone, and a phone is exactly the device the capture came from. But a cut can only move as far as its radius, so all but a few hundred of those rows were never candidates. Reading one narrow band around each cut costs a fraction of a megabyte and answers precisely the same question. The general lesson is worth keeping: when an algorithm looks too expensive, check whether it is being asked about data whose answer could never have mattered.