I set up a small community lab last year, complete with a camera scanning setup, and although inverting film scans has become quite doable, we found manually cropping dozens of rolls at a time was a pain. This led me to build a utility that detects frame edges and crops scans automatically. I recently bundled it into a web utility you can try out, accessible here. It’s a pure “classical computer vision” solution, no machine learning, no ai, and specifically designed to retain accurate crops in the presence of sprocket holes, low contrast film edges and strong lines in the image area itself.
I recommend you use chrome or a chromium based browser, and place the images of each roll in a dedicated folder as the detection uses a roll level consensus, since assuming film mask geometry and size are constant throughout a roll really helps with detection. Export is a bit slow because of the limitations of working out of a browser, and I haven’t found a way of improving that yet. Since it’s orginally a lab utility, the GUI isn’t super flashy, but it gets the job done, and there are hotkeys for everything except the fine crop area / tilt adjustments.
I hope some of you find this utility useful, and if you have any questions or feedback, I’ll be happy to answer them.
Just tried it with a few photos, so not to extensively, but the cropping seems accurate. The export speed is fine by me, since it saves time compared with manually cropping. Only thing I noticed so far is that it seems to desaturate or change the colors of the exported photos a bit, compared to the originals. Is this something that could be fixed?
I looked and there was an issue with colour profile handling: the export function stripped the profile from the output. I have fixed it, now all metadata, including colour profiles should survive the crop. How does it look on your end now?
Thank you for making this tool available to community!
If I am allowed to suggest something, though I understand this would require very considerable new effort.
So here are my 2 cents. Typical inversion workflow requires raw file to be presented (as it has all the info which make inversion happen in proper color space and fitness), so it’s raw files which typically need to be rotated and cropped before the inversion. Also sprocket holes and rebate not removed before inversion would seriously mess up the inverted colors. Would it be too hard for autocropper to process raw files and give user back the sidecar xmp file which would guide the cropping for application which do the inversion?
Slight correction first: cropping the raw file before inversion isn’t the correct workflow, one has to have an estimation of Dmin to invert accurately, and the film rebate area is the best reference for this; so the logic would be film mask detection → estimate rebate from the median value of the raw scan around the film mask → invert → crop and rotate.
It’s doable, but it would add a bunch of moving parts and require some thinking on how to do it, plus at the moment, the tool is geared to detect edges for already inverted files. In principle it’s only a sign flip in the logic, but it does add another path (raw negatives on top of already inverted images).
A minimal version of the feature you propose would be to add a “raw negative” option that operates the same logic with the sign flip and only exports the coordinates of the corners for the crop area as a JSON or XMP file. The tricky part there is to ensure compatibility with a wide range of worflows, because there are many ways of inverting scans.
This is all true what you are saying. To be honest I did implement very similar procedure locally - but in my case I was doing simple inversion right after the crop ( sampling the lightest part of rebate before crop ). I meant my app to do just on the fly conversion from hot folder for user to have an idea what is going on. Anyway, hope your users enjoy your app.
