What numbers does a paper animator actually measure?

The four things that come back

A tool like this can measure its own work cheaply, because the work happens in the same place you are watching it. The page decodes your image, draws it onto a canvas, synthesises the torn edge, and — if you ask for a clip — drives a frame-by-frame recorder. At each of those steps it already holds a number in its hand. The only question is whether it prints that number or hides it.

This page prints it. Four readouts come back, each with a fixed sentence shape so you can tell at a glance which one you are looking at:

• Working size. The image is fitted to a working canvas of up to 1600 px on the long side, and very small images are scaled up so the tear has room to exist. The status line reads back both numbers, for example Loaded 3840×2400 → working at 1600×1000.
• Cutout share. With the cutout on, the page counts the pixels it actually flood-filled away and divides by the pixel count of the whole frame, for example Cutout removed 66.3% of the frame as background. If that figure lands under 1.5% or over 92%, the same line changes its wording and tells you which way to move the tolerance slider.
• Frame count. Duration, which runs from 1 to 10 seconds, multiplied by the frame rate you picked, which is 24, 30 or 60 fps, is the frame count for the export. Nothing is rounded behind your back.
• Export result. After a download the page reports the real file size, and for a clip also the frame count, the rate the recorder actually reached and the real time it took — for example 30 frames @ 10 fps, recorded in 3.3s.

One real run, measured on this machine

A description of a status line is worth little until someone reads the status line. So a test image was built in the page itself — 900×600, a white background, a dark rectangle and a red disc — and handed to the tool through its own render entry point, the same path a real file takes. The cutout was switched on at its default tolerance.

The tool reported back that it had loaded a 900×600 image into a 900×600 working canvas, that the cutout was available, and that it had removed 396,012 of 540,000 pixels — 73.34% of the frame. The status line under the canvas said exactly that: Cutout removed 73.3% of the frame as background.

Then the export was run, once, on the same image. The line it printed afterwards was Saved paperrip.webm (0.05 MB, 90 frames @ 30 fps, recorded in 5.0s). Three of those figures deserve a second look. The clip was 3.0 seconds at 30 fps, which is 90 frames — the arithmetic from the previous section, confirmed on the page. The rate is 30 fps, the rate the recorder reached, not a rounded-up claim. And the elapsed time is 5.0 seconds for a 3.0-second clip, because the recorder timestamps frames by the wall clock and the encoder is real work. The page prints the time it took rather than the time you asked for.

Why the rate is measured rather than chosen

A clip recorder timestamps frames by wall clock, so a clip only plays back at the right speed if frames really are emitted one frame-interval apart. On a machine that cannot render that fast, a recording made at the rate you asked for silently stretches into slow motion. So the page does not trust the rate you picked. Before recording begins it renders three warm frames with the encoder already running — software encoding is expensive and would otherwise make the estimate far too optimistic — takes the median cost of a frame, and derives the rate from that: fps = max(6, min(wantFps, floor(900 / renderMs))).

On this machine the median cost of a frame at 900×600 was 2 milliseconds, so the derived rate is the full 30 fps you would have asked for. On a slower machine the same line of arithmetic lands lower, and the export is recorded at that lower rate — fewer frames, correct duration, and both stated plainly in the status line. When the rate it reached is below the rate you asked for, the line adds the reason: a frame cost about so many milliseconds here, so the requested rate was not reachable.

There is a floor of 6 fps and a floor of 2 frames, so a very slow machine still produces a real clip rather than a single-frame stub. And an export that produces an empty file is reported as a failure, not dressed up as a save: if the encoded blob comes back under 2048 bytes, the line says an empty file was produced and nothing was saved.

What is not measured

The honest half of this list is the half that is missing. The page does not score how good the result looks. It does not know whether the cutout kept the right subject or the wrong one, whether the tear suits this particular photo, or whether the animation reads well at the size you will actually post it. Those are judgements, and a number printed under a canvas would only pretend to make them.

It also does not measure you. There is no score for your session, no accuracy rating for your image, and no comparison of your run against anyone else's. The figures are about the work the tool did, which is why they can be printed at all: they come from the render loop, not from a model's opinion of your photo.

And it does not measure anything on a server, because there is no server in the path. The image is read off your disk and rendered in the tab, so the numbers describe a run that happened entirely on your own machine — which is also the only reason they can be reported back to you instantly.

How to check any of this yourself

None of these figures asks to be taken on trust. Load a photo, and the first line under the canvas tells you both sizes. Switch the cutout on, and the same line is replaced by the share of the frame it removed. Export a clip, and the export line gives you the file size, the frame count, the rate reached and the elapsed time. The whole audit takes about a minute and needs no tools beyond the page.

That is the difference worth noticing, because the figures you meet elsewhere in this category cannot be checked at all. The page that ranks first prints 412k+ users already signed up! and never says where the count comes from. Another prints 4.2M+ FRAMES GENERATED with no source for the number and no way for a visitor to reproduce it. Those are statements about a crowd. What this page prints are statements about the file you just handed it, produced while you watched, on your own hardware — and if you think a number is wrong, you can re-run the same image and watch it come back again.

The short version

A tool that does its work in front of you can show you the work. This page prints four things under the canvas: the working size it fitted your image into, the share of the frame the cutout removed, the frame count, and after an export the file size, the rate the recorder reached and the real time it took. Measured here: 73.3% of a 900×600 frame removed by the cutout, and a 90-frame clip at 30 fps recorded in 5.0 seconds. What it does not print is a verdict on how good your animation looks — because that one is still yours to make.