I've thought about making an own scan tool, it's an interesting programming challenge with pattern recognition.
Yes, assuming that the issue with 'scanin' is geometry based.
There are different degrees of sophistication possible, but one could start as scanin does, by assuming a more or less properly squared input. It doesn't have to be perfectly distortion free either, as long as one can get enough of the centers of the patches for a statistically significant number of samples to average.
Strictly speaking, one doesn't even have to use perspective corrected images, just the locations of each of the 4 patch corners from which to take the non-resampled pixel values, and a zone within those coordinates to avoid along the patch edges (to avoid shadows and/or edge blur). It can also avoid the need for resampling of the source image, just sample and average the pixels within the patch inner boundaries.
A simplification would be to use full pixel row shifts (or only offsets) to align vertical edges a bit better, and a full pixel column shift to align horizontal edges a bit better. Such a trapezoidal de-skewing avoids potential resampling issues (by using only full pixel shifts), and produces somewhat more rectangular ROIs in case a target is rotated.
The most robust thing would be to make a GUI where you have a patch grid wireframe that you can manually stretch and bend in place, but then DCamProf would get lots of GUI dependencies. It would be nicer with a command that could search and find a target in a picture and automatically map without any GUI, but it's no easy task.
That's more complex (although nice), and not trivial to do for multiple OS environments. But let's see if Graeme can (and is willing to) improve the usability of scanin, by changing whatever is causing the refusal of certain target inputs.
EDIT: Maybe AlterEgo's link gives some more ideas, I haven't read it yet.
Cheers,
Bart