Some years ago, using WinBatch (scripting language(like Python)) to 'screen-scrape' and gather resolution, margin size, and other info before displaying, the viewer (XnView) then prompted you that this image "needs attention".
The prompter showed a GRID marker for every test. Dimensions, Resolution, etc, etc.
Note: most of these JPGs came from office-scanners, most everything was 'letter-sized'.
The operator had to view the re-sized image, then 'mark-'off' the GRID to continue.
Every modified image was saved (before/after).
"Upside-down" "leaning" and other un-seen problems are flagged in the GRID for later repair & verification.
The experienced operator could 'verify' a scan in seconds. Often, the image was simply junk, upside-down, blurred, whatever, the 'lock' could be checked in the GRID, meaning, the image is re-queued for later editing.
The WinBatch program used a simple SQLite 'tracking' database in this record-keeping application.
The WorkFlow programs used this database to move the documents thru the system, and finally, archive them in permanent optical-disk-juke-boxes !
Obviously, this is a large-scale application common to Government record-keeping. The emphasis was to speed the input-process for high-volume work, and minimize operator training.
The scripting does little more, than what XnView can do with proper training.
With all the effort$$ described above, we failed to automate "CROP" and "ROTATE" !
