Post by PaulPost by Carlos E.R.I found something else when stitching manually with gimp. It is a land
plot plan, scanned with a generous overlap, but the two images do not
match. I make one line overlap fully, but the next one doesn't. The
scanner pixel distance left or right end (of the moving sensor) is not
the same. I imagined motor inexactitudes, but this is surprising.
- If the sections are even only slightly rotated with respect to each other, distances between visible points across the scans will differ, at least a little.
- Particularly, if the scan sections were done at right-angles to each other, although the resolution across and down the length of the scanner may nominally be the same, in fact they can vary significantly, particularly, as Paul has pointed out, as the toothed belt in the driving mechanism wears. My oldest scanner, an HP 5490C Model C9850A that did the Snowman Tree, suffers from this.
In The GIMP use the "perspective" tool that's what I use when I need to make
several things line up. it can fix a stretch or a skew or a keystone
distortion.
https://docs.gimp.org/en/gimp-tool-perspective.html
Yes, you can do this in many decent image editing programs, but it can be very tedious to get everything just right.
Another method is to alter the resolution slightly, you count the number of pixels between visibly the same points near opposite edges of the two scans (a rubber-banding tool is useful for this) and decrease the resolution of the wider of the two proportionately. Again, fiddly and tedious to get exactly right, and you have to know how to perform simple proportionality or scaling arithmetic, which, to me surprisingly, a large number of people seem unable to do.
But, hey, Carlos & Paul seems to be enjoying their discussion about the intricacies of scanner design - which, given that the scanner in its current state is a given and can't be changed, doesn't seem likely to solve Carlos' actual problem - so why should we butt in with practical, helpful advice :-)
The scanner has a non-standard defect.
The scanner also has a standard defect. Two defects at once.
Yes, but it's still a given, which could only be changed if Carlos was
prepared to find another scanner and redo the work, but his posing a
question here suggests that either that option is not possible, or would
be even more difficult or even more work for reasons that we don't know.
Therefore, we must assume that he must make the best use he can of the
scans that he actually has, just as, when stitching the panorama from
the summit of Ben Cruachan mentioned in my original reply to him, I
couldn't revisit the area to retake the photos that I had taken in 1977,
I had to use what I had available from the time.
Post by PaulThe noise from these defects, makes it harder for automated
tools to assign control points and pick transformations.
Agreed.
Post by PaulThere are better tools than GIMP, but you and Jason carry
on with your discussion. I had something like 30 images
in a 5x6 matrix to join. You're not going to do that with GIMP.
Well, you can, it's just a lot of work - I'd done several documents
getting on for that size before someone suggested using photographic
stitching software more commonly used for making photo panoramas, which
previously hadn't occurred to me. However, certainly I agree that it's
a lot easier if you can get stitching software to work, then 5 x 6
becomes nothing really, I've done many family trees and maps of that
sort of size; as previously mentioned, my largest stitch was 4 x 18.
Post by PaulHugin is not the answer, because it demands the assignment
of a multitude of control points, which hardly saves a human
any effort whatsoever.
It depends. Hugin is able to find control points automatically, but it
depends on having sufficient overlap, the scan sections being well
aligned and not significantly rotated with respect to each other, etc,
again as mentioned in my original first reply.
Post by PaulThat would be hundreds of control points,
for my five by six matrix. I would be sick to death of
control points, before I was half done.
Yes, but if that is the only option, say because of the original scans
being poorly aligned and it not being possible to rescan them, then
that's what you have to do. That's what I had to do to get the Ben
Cruachan panorama, the final successful result was an evening's work,
and there had been at least one failed previous attempt.
If you *can* redo the scans, being more careful to maintain as exactly
as possible the orientation of the sections and getting sufficient
overlap, that may actually be quicker than struggling to get a manual
stitch.
Post by PaulMicrosoft ICE (from the Microsoft Research division) does a
damn good job, considering scanner input is garbage to begin
with. The output for my project was "imaginative but incorrect".
And so it goes.
Like OCR, close but no cigar.
Yes, I've found ICE to be pretty good, but by no means perfect.
Post by PaulMy scanner was perfectly functional, when I tried a stitching
project, and the output, was no more useful than what Carlos
is getting.
Then probably you were doing something wrong. Of course I can't say
what without greater knowledge of exactly what you were trying to do,
but the most common problems are that the sections didn't have enough
overlap, or were rotated wrt each other. Ruling light parallel pencil
marks on the back of the document can help with both of those problems.
Post by PaulWhen you shoot panoramas with a panorama camera on a tripod,
a number of the defects are gone (compared to using a scanner
on paper stock), and you only have a couple transforms to apply
to get a reasonably correct output. That's why people bother
to shoot panoramas that way, because they got output that worked.
My Ben Cruachan one was shot entirely by hand without a tripod. Yes,
I'm sure that it would have been easier to get a better result if I'd
used a tripod and the same exposure for all the shots, but I didn't have
the tripod with me and didn't realise the problems that I'd have later
with exposure.
Post by PaulScanners and paper stock, are "a bridge too far". Too much
garbage input, too much garbage output. But it's at least
interesting, to see how much algorithmic attempts have progressed.
*******
It doesn't seem to handle all of the line overlap cases well,
but otherwise the stitching ICE does, is pretty good. But,
you really do need the images to overlap. It would take me
all day, to step along that seam and make it look this good.
[Picture]
https://i.postimg.cc/J0VBXmvf/correct-uses-the-overlap.gif
The cleanup work I'd have to do in GIMP in that one, would
be limited to trying to fix the hop in the line near the top.
In this case, only the very edges of the two images correlate, and
the tool completely blows it. Zero overlap. It has removed a
strip of material that should not have been removed. There was
no indication on the screen, that the confidence interval was low.
It's up to me to zoom in and inspect.
https://i.postimg.cc/QM3PfW5C/no-overlap-it-fails.gif
The moral of the story is pretty obvious, but in my case,
the materials are, what they are. They're sections out of
a map book, where nobody cared to make them useful for
stitching into a larger map. Some of the materials overlap by
significant amounts, in other cases, you get no overlap at all,
and the legend overlaid on the picture, impedes the project.
Yes to all the above, but where there is no overlap, then really you
have to use GIMP or an equivalent image editing program, it's
unrealistic to expect a program designed to use overlap for alignment to
work without any overlap whatsoever.
--
Fake news kills!
I may be contacted via the contact address given on my website:
www.macfh.co.uk
