Thanks for taking a look. Looks like the troublesome image is a jpeg not png, file output is:

JPEG image data, JFIF standard 1.01, aspect ratio, density 300x300, segment length 16, baseline, precision 8, 6000x19367, components 3

(Pillow sees this as an RGB file)

I tried wrapping a context around it, no change. Also tried without luck:

• Setting (one at a time): is_pure=True, try_rotate=False, try_downscale=False.
• Loading as a PNG

Given allocations are coming from tobytes it might be how we traverse the buffer (array_interface access triggers reading the file and creating the bytes result in data, but I don't understand why that wouldn't be freed. (guessing memory views wouldn't help here either, but I suppose it could).

It could be related to python-pillow/Pillow/issues/7935 but in my test I'm not copying an image (and the PILLOW_BLOCKS_MAX setting doesn't change behavior)

Can you test if the code from this comment triggers your memory leak? It sounds pretty much exactly like our use case but should have been fixed a long time ago already.

Following this discussion led me to this blog post which could be used as a base to potentially fix the issue at hand and make the code a little faster. But I don't have time right now to spend on this.

Using numpy.array or asarray still triggers the leak.

Good find on the blog post, it does seem to minimize the leak (maybe 100mb the first time and a few mb each subsequent call). So definitely better than 300mb per call, still more leaky than using opencv directly.

I'm not sure I'll have time to dig into a fix further at the moment, if I do or find more from PIL I'll send along a note/MR.

Thanks again!