PR summary

The current implementation is not slow, but uses a lot of memory per image.

Incompare_images, we have:

• one actual and one expected image as uint8 (2×image)
• both converted to int16 (though original is thrown away) (4×)

which adds up to 4× the image allocated in this function.

Then it callscalculate_rms, which has:

• a difference between them as int16 (2×)
• the difference cast to 64-bit float (8×)
• the square of the difference as 64-bit float (though possibly the original difference was thrown away) (8×)

which at its peak has 16× the image allocated in parallel.

If the RMS is over the desired tolerance, thensave_diff_image is called, which:

• loads the actual and expected imagesagain as uint8 (2× image)
• converts both to 64-bit float (throwing away the original) (16×)
• calculates the difference (8×)
• calculates the absolute value (8×)
• multiples that by 10 (in-place, so no allocation)
• clips to 0-255 (8×)
• casts to uint8 (1×)

which at peak uses 32× the image.

So at their peak,compare_images→calculate_rms will have 20× the image allocated, and thencompare_images→save_diff_image will have 36× the image allocated. This is generally not a problem, but on resource-constrained places like WASM, it can sometimes run out of memory just incalculate_rms.

This implementation in C++ always allocates the diff image, even when not needed, but doesn't have all the temporaries, so it's a maximum of 3× the image size (plus a few scalar temporaries).

PR checklist

• [n/a] "closes #0000" is in the body of the PR description tolink the related issue
• new and changed code istested
• [n/a]Plotting related features are demonstrated in anexample
• [n/a]New Features andAPI Changes are noted with adirective and release note
• [n/a] Documentation complies withgeneral anddocstring guidelines