How to stitch scanned papers?
I have a map that is larger than my scanner, so I took 3 partial scans.
I want to stitch them into one single png file. Google says to use
Hugin. I can't.
How to stitch scanned papers?
I have a map that is larger than my scanner, so I took 3 partial scans. I want to stitch them into one single png file. Google says to use Hugin. I can't.
The thing insists in asking about type of lenses and panosphere mode.
Heck, it is flat paper, not a camera!
Is there something that works?
Notice that there is an overlap in the scans, one or two centimetres. The task is similar to having the papers and joining with celo tape but cutting the excess so that they do match, and tilting a degree or two. So forget Imagemagick, this has to be a GUI.
Gimp may do it, but I hope to find something specific.
How to stitch scanned papers?
I have a map that is larger than my scanner, so I took 3 partial scans.
I want to stitch them into one single png file. Google says to use
Hugin. I can't.
The thing insists in asking about type of lenses and panosphere mode.
Heck, it is flat paper, not a camera!
Is there something that works?
Notice that there is an overlap in the scans, one or two centimetres.
The task is similar to having the papers and joining with celo tape but cutting the excess so that they do match, and tilting a degree or two.
So forget Imagemagick, this has to be a GUI.
Gimp may do it, but I hope to find something specific.
In case you need inspiration to continue, here are some of my most successful stitches:
A family tree composed by a cousin on a roll of wallpaper backing or similar - which originally was used for a children's party and had a snowman painted on the back of it, which shows through, hence the name
- scanned finally in 4 x 18 A4 sections (but was scanned twice
previously with less overlap and therefore smaller numbers of scans
along its dimensions, but both of which failed to stitch properly);
stitched using ICE (108 MB):
<www.macfh.co.uk/Temp/Snowman Tree.png>
A near 360 panorama from the top of Ben Cruachan taken with a Canon FTb
film camera in the late 70s, stitched by Hugin Panorama with both
automatic & manual addition of stitching points and manual adjustment of exposure settings, because I'd failed to take the original sections all
at the same exposure (3.5 MB):
<www.macfh.co.uk/Temp/197709 Ben Cruachan - Panorama From The Summit (full).png>
A panorama over Loch Alsh taken with an early model of digital camera, a Canon S40, probably stitched with the software that came with it, but I can't remember for sure now (10.3 MB):
<www.macfh.co.uk/Temp/20121127_145528 Panorama Over Loch Alsh From Kyle Viewpoint.png>
A sunset from near my home, taken with a mobile phone, a Samsung Galaxy
Note 2 (which has since died), and stitched with ICE (0.7 MB):
<www.macfh.co.uk/Temp/20171027_180507 Sunset Panorama Over Achnairn &
Loch Shin.jpg>
So it can be done, but it can take a great deal of patient trial & error--
to get the software to work well.
On 3/22/2024 10:26 PM, Carlos E.R. wrote:
How to stitch scanned papers?
I have a map that is larger than my scanner, so I took 3 partial scans. I want to stitch them into one single png file. Google says to use Hugin. I can't.
The thing insists in asking about type of lenses and panosphere mode.
Heck, it is flat paper, not a camera!
Is there something that works?
Notice that there is an overlap in the scans, one or two centimetres. The task is similar to having the papers and joining with celo tape but cutting the excess so that they do match, and tilting a degree or two. So forget Imagemagick, this has to be a GUI.
Gimp may do it, but I hope to find something specific.
The pictures here show it being applied to two pages.
But it does accept more of course.
"Hugin tutorial - Stitching flat scanned images
This tutorial covers another non-panoramic usage of Hugin - Taking
two or more partial scanned images of a large object, such as an
LP cover, map or poster, and stitching them seamlessly into a
single final image."
https://hugin.sourceforge.io/tutorials/scans/en.shtml
It's just a giant pain in the ass and a complainer.
*******
Whereas this is just magical. Even with the poor overlap
characteristics of the source material, it did a good job.
It didn't need control points. Only the overlap interface
needed a slight increase in radius, to make the picture
wider and use more of the source material. This means
you have to check the width of the output, to see if
it missed and snipped too much off the joints. The program
is unlikely to do the job the same twice, unless you set
the overlap controls exactly the same each time.
https://web.archive.org/web/20180724063025if_/https://download.microsoft.com/download/7/3/9/73918E0B-C146-40FA-B18C-EADF03FEC4BA/ICE-2.0.3-for-64-bit-Windows.msi
Name: ICE-2.0.3-for-64-bit-Windows.msi
Size: 7,963,136 bytes (7776 KiB)
SHA256: 3A39A8FFF473500186F56E6F79985BAE87A5B6D5F10ED3F8A3F40899D7FDDB43
[Picture]
https://i.postimg.cc/G3vywKw9/Microsoft-ICE-magical.jpg
Paul
https://web.archive.org/web/20180724063025if_/https://download.microsoft.com/download/7/3/9/73918E0B-C146-40FA-B18C-EADF03FEC4BA/ICE-2.0.3-for-64-bit-Windows.msi
Ah, but that's Windows.
On 3/24/2024 12:01 AM, Carlos E.R. wrote:
https://web.archive.org/web/20180724063025if_/https://download.microsoft.com/download/7/3/9/73918E0B-C146-40FA-B18C-EADF03FEC4BA/ICE-2.0.3-for-64-bit-Windows.msi
Ah, but that's Windows.
Yes, and my attempt to load it into WINE did not work.
I was just testing it on this machine, and even in Windows,
I was getting graphical render glitches (flashing) on the
third tab of the process. Whether it's using OpenGL or
DirectX, I don't know. I noticed in Task Manager,
that the video card was "active" and presumably in windowed 3D mode.
Still, it is fun to have something "kinda work", without
having to enter a zillion control points. And it might work better
with overlap.
Part of the problem with scanning paper items, is if they're
brand new from the store, they might be relatively dimension-stable.
However, when paper dries out or ages, the X and Y direction
do not stretch or shrink the same amount, and even areas of the
same page may not experience the same changes. When you then scan
paper like that, and then stitch the scans together, that
causes "heart failure" for the stitching tool.
On 2024-03-24 05:55, Paul wrote:
On 3/24/2024 12:01 AM, Carlos E.R. wrote:
https://web.archive.org/web/20180724063025if_/https://download.microsoft.com/download/7/3/9/73918E0B-C146-40FA-B18C-EADF03FEC4BA/ICE-2.0.3-for-64-bit-Windows.msi
Ah, but that's Windows.
Yes, and my attempt to load it into WINE did not work.
I was just testing it on this machine, and even in Windows,
I was getting graphical render glitches (flashing) on the
third tab of the process. Whether it's using OpenGL or
DirectX, I don't know. I noticed in Task Manager,
that the video card was "active" and presumably in windowed 3D mode.
Still, it is fun to have something "kinda work", without
having to enter a zillion control points. And it might work better
with overlap.
Part of the problem with scanning paper items, is if they're
brand new from the store, they might be relatively dimension-stable.
However, when paper dries out or ages, the X and Y direction
do not stretch or shrink the same amount, and even areas of the
same page may not experience the same changes. When you then scan
paper like that, and then stitch the scans together, that
causes "heart failure" for the stitching tool.
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.
See photos:
https://paste.opensuse.org/pastes/ecbec3d8650e https://paste.opensuse.org/pastes/b09e2b4b1b3c
(the movement of the sensor bar is right to left, because the image is rotated 90°)
On 3/24/2024 11:01 AM, Carlos E.R. wrote:
On 2024-03-24 05:55, Paul wrote:
On 3/24/2024 12:01 AM, Carlos E.R. wrote:
https://web.archive.org/web/20180724063025if_/https://download.microsoft.com/download/7/3/9/73918E0B-C146-40FA-B18C-EADF03FEC4BA/ICE-2.0.3-for-64-bit-Windows.msi
Ah, but that's Windows.
Yes, and my attempt to load it into WINE did not work.
I was just testing it on this machine, and even in Windows,
I was getting graphical render glitches (flashing) on the
third tab of the process. Whether it's using OpenGL or
DirectX, I don't know. I noticed in Task Manager,
that the video card was "active" and presumably in windowed 3D mode.
Still, it is fun to have something "kinda work", without
having to enter a zillion control points. And it might work better
with overlap.
Part of the problem with scanning paper items, is if they're
brand new from the store, they might be relatively dimension-stable.
However, when paper dries out or ages, the X and Y direction
do not stretch or shrink the same amount, and even areas of the
same page may not experience the same changes. When you then scan
paper like that, and then stitch the scans together, that
causes "heart failure" for the stitching tool.
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.
See photos:
https://paste.opensuse.org/pastes/ecbec3d8650e
https://paste.opensuse.org/pastes/b09e2b4b1b3c
(the movement of the sensor bar is right to left, because the image is rotated 90°)
Stepper motor and rubber belt. Plus "settling time".
See if you can select a setting which causes a slower scan.
Look through the scanner cover, and see if the belt lacks tension.
When a scan happens, the movement is in one direction and
the slack in the drive train should be taken up by the
consistent direction of travel.
The bar the scan head moves on could be rusty or sticky.
There should be a sound effect, if something is wrong with
the mechanical bits. Unlike the sound when it was new.
On 2024-03-24 18:53, Paul wrote:
On 3/24/2024 11:01 AM, Carlos E.R. wrote:
On 2024-03-24 05:55, Paul wrote:
On 3/24/2024 12:01 AM, Carlos E.R. wrote:
https://web.archive.org/web/20180724063025if_/https://download.microsoft.com/download/7/3/9/73918E0B-C146-40FA-B18C-EADF03FEC4BA/ICE-2.0.3-for-64-bit-Windows.msi
Ah, but that's Windows.
Yes, and my attempt to load it into WINE did not work.
I was just testing it on this machine, and even in Windows,
I was getting graphical render glitches (flashing) on the
third tab of the process. Whether it's using OpenGL or
DirectX, I don't know. I noticed in Task Manager,
that the video card was "active" and presumably in windowed 3D mode.
Still, it is fun to have something "kinda work", without
having to enter a zillion control points. And it might work better
with overlap.
Part of the problem with scanning paper items, is if they're
brand new from the store, they might be relatively dimension-stable.
However, when paper dries out or ages, the X and Y direction
do not stretch or shrink the same amount, and even areas of the
same page may not experience the same changes. When you then scan
paper like that, and then stitch the scans together, that
causes "heart failure" for the stitching tool.
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.
See photos:
https://paste.opensuse.org/pastes/ecbec3d8650e
https://paste.opensuse.org/pastes/b09e2b4b1b3c
(the movement of the sensor bar is right to left, because the image is rotated 90°)
Stepper motor and rubber belt. Plus "settling time".
No, in this case the error is horizontal, left end of the moving sensor to right end of the same sensor.
See if you can select a setting which causes a slower scan.
Oh, it is terribly slow, takes minutes for each page (600 dpi).
I may experiment at 300 dpi and see.
Anyway, the result is good enough in this case, but I can try to find out more about the problem.
Look through the scanner cover, and see if the belt lacks tension.
When a scan happens, the movement is in one direction and
the slack in the drive train should be taken up by the
consistent direction of travel.
The bar the scan head moves on could be rusty or sticky.
There should be a sound effect, if something is wrong with
the mechanical bits. Unlike the sound when it was new.
The scanner is over a decade old. But in this error the belt is not the issue, it is the other axis. Other sections of the stitched image are affected by the belt, but not the one that I showed in the screen shots.
In the screen shots, the vertical direction in the image corresponds to the horizontal in the scanner. Thus, no belt issues.
On 3/24/2024 6:29 PM, Carlos E.R. wrote:
On 2024-03-24 18:53, Paul wrote:
On 3/24/2024 11:01 AM, Carlos E.R. wrote:
On 2024-03-24 05:55, Paul wrote:
On 3/24/2024 12:01 AM, Carlos E.R. wrote:
See photos:
https://paste.opensuse.org/pastes/ecbec3d8650e
https://paste.opensuse.org/pastes/b09e2b4b1b3c
(the movement of the sensor bar is right to left, because the image is rotated 90°)
The scanner is over a decade old. But in this error the belt is not the issue, it is the other axis. Other sections of the stitched image are affected by the belt, but not the one that I showed in the screen shots.
In the screen shots, the vertical direction in the image corresponds to the horizontal in the scanner. Thus, no belt issues.
On this particular one, the sensor is a bunch of shorter elements joined end to end,
to make the wider green bar. The transport has the steel rod up the center and
the scanning element is supported on a nylon slider.
https://upload.wikimedia.org/wikipedia/commons/8/86/Flatbed_scanner_CIS_sensor_bar.jpg
( https://en.wikipedia.org/wiki/Contact_image_sensor )
Perhaps the nylon slider is a bit loose.
On 2024-03-25 03:50, Paul wrote:
On this particular one, the sensor is a bunch of shorter elements joined end to end,
to make the wider green bar. The transport has the steel rod up the center and
the scanning element is supported on a nylon slider.
https://upload.wikimedia.org/wikipedia/commons/8/86/Flatbed_scanner_CIS_sensor_bar.jpg
( https://en.wikipedia.org/wiki/Contact_image_sensor )
Perhaps the nylon slider is a bit loose.
The apparent problem in mine is that the distance between the individual pixels in the sensor is not constant.
On 3/25/2024 6:43 AM, Carlos E.R. wrote:
On 2024-03-25 03:50, Paul wrote:
On this particular one, the sensor is a bunch of shorter elements joined end to end,
to make the wider green bar. The transport has the steel rod up the center and
the scanning element is supported on a nylon slider.
https://upload.wikimedia.org/wikipedia/commons/8/86/Flatbed_scanner_CIS_sensor_bar.jpg
( https://en.wikipedia.org/wiki/Contact_image_sensor )
Perhaps the nylon slider is a bit loose.
The apparent problem in mine is that the distance between the individual pixels in the sensor is not constant.
Making that bar out of sections, is a common technique.
An electrical clocking failure, when passing the output from
stage to stage ("clockout") could affect the result. But that's
anywhere from "highly unlikely" to "impossible". They could
run conductors down the bar, and clock out all the sections
in parallel, and if so, there would be an opportunity for
what looks like a registration error.
Smearing in the Y direction, indicates a problem with the
stepper or a problem with the belt tension. The stepper must
have a crisp, predictable behavior, such that once it steps,
you wait the "settling time". If the response was sluggish,
then the scanning bar would not have stopped moving, and
there would be some blur.
But practically speaking, for your design to have an X direction
defect like that, it can't be a conventional design. Scanners used
to be CCD (charge coupled device) for the short sections.
Then changed to CMOS for the short sections, and there is
no depth of field with CMOS (paper must be pressed to glass,
would be out of focus anywhere else). Mine is CCD, because it's
pretty old, and it does have some depth of field. When it
scans the spine of a book, it can pick up a bit of the
text, but not necessarily all of it.
If the body of the scanner was thicker, there would be room
for an alternate implementation. Mine for example, the
body is four inches high, the lid (supports reflective
and transmissive scanning), is thick too. That's an example
of a scanner body, where there is more room for mechanical
bits. If the scanner is a flatbed that is only an inch
or two thick, there aren't a lot of ways to cheaply make
those, except to make that wide green bar out of pieces.
The highest quality scans can come from a drum scanner.--
But those require defacing the materials to be scanned,
because the material must be affixed to the drum which
rotates at high speed. You would have to cut the pages
out of a book, to drum scan it. In flatbed reviews, they
might compare a unit to a drum scan (as a "quality reference"),
but really they are night and day different from a
practical perspective.
https://www.michaelstricklandimages.com/blog/2018/4/4/drum-scanning
Paul
Same here,
It is an Epson Perfection 1650.
On 3/25/2024 11:51 AM, Carlos E.R. wrote:
Same here,
It is an Epson Perfection 1650.
Someone here got a pattern in a scan, and it was
related to the 24V power supply. An interesting
question would be, why a scanner needs a 24V power
supply, but I suppose that is handy for driving
the motor.
Since scanners can be made for $50 or less, there cannot be
a lot of money in making those chips. It's the "Intel $5 CPU problem",
not a lucrative business to be in. When you pay more for a scanner,
the money goes into a better scan head, or a transport with
tighter dimensional control. The all seem to like the rubber
belts with teeth, for transportation.
On 2024-03-26 01:29, Paul wrote:
On 3/25/2024 11:51 AM, Carlos E.R. wrote:
Same here,
It is an Epson Perfection 1650.
Someone here got a pattern in a scan, and it was
related to the 24V power supply. An interesting
question would be, why a scanner needs a 24V power
supply, but I suppose that is handy for driving
the motor.
For the fluorescent tube.
Since scanners can be made for $50 or less, there cannot be
a lot of money in making those chips. It's the "Intel $5 CPU problem",
not a lucrative business to be in. When you pay more for a scanner,
the money goes into a better scan head, or a transport with
tighter dimensional control. The all seem to like the rubber
belts with teeth, for transportation.
And scanners using a camera are quite expensive.
On 3/26/2024 7:50 AM, Carlos E.R. wrote:
On 2024-03-26 01:29, Paul wrote:
On 3/25/2024 11:51 AM, Carlos E.R. wrote:
Same here,
It is an Epson Perfection 1650.
Someone here got a pattern in a scan, and it was
related to the 24V power supply. An interesting
question would be, why a scanner needs a 24V power
supply, but I suppose that is handy for driving
the motor.
For the fluorescent tube.
Since scanners can be made for $50 or less, there cannot be
a lot of money in making those chips. It's the "Intel $5 CPU problem",
not a lucrative business to be in. When you pay more for a scanner,
the money goes into a better scan head, or a transport with
tighter dimensional control. The all seem to like the rubber
belts with teeth, for transportation.
And scanners using a camera are quite expensive.
CCFL tubes run from high voltage, and it MUST be a pure sine power source.
if there's any DC on the waveform at all, it accelerates the degradation
of the CCFL electrodes. Ignition voltage is 1000VAC. The operating voltage after it starts to conduct, might be around 700VAC. This requires an inverter, to make the sine power. CCFL tube "power" is 3 watts, but
it's delivered as 1000VAC and 3mA, and a sine wave.
The sine wave can be at 25KHz (above human hearing range). Since the
inverter operates at a high frequency, you're not supposed to be able
to hear it.
To control the intensity (your 1650 has intensity level control!),
you can PWM the inverter at 200Hz. In effect it kind of runs
in burst mode. Bursts of 25KHz high voltage. By using PWM
modulation, the CCFL tube achieves a wider range of intensities.
In the old days, intensity control was set "with a knob", and
this was a simple resistive circuit. But the intensity range
was small, and only a tiny reduction in light level could be
achieved. Whereas the PWM method has a wider range than that.
It turns out the light source, isn't as simple as you might think :-)
Now mine does not modulate the intensity level, and runs at
a fixed level. My scanner also "overscans" the glass. The scan
head scans a "white patch" just before the glass begins, and
that sets the "white level" for the scan. It takes up to
20 minutes for a CCFL to reach "stable intensity", and since
many scans are taken while the CCFL is not warm, the scanner
calibrates what it finds, by scanning a white patch just before
it scans the paper right next to it.
And it's not really all that good of a scanner, but the
marketing people "spared no effort" :-)
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.
On 2024-03-24, Carlos E.R. <robin_listas@es.invalid> wrote:
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.
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
On 27/03/2024 08:46, Jasen Betts wrote:
On 2024-03-24, Carlos E.R. <robin_listas@es.invalid> wrote:
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.
This can happen if the scan sections are done at different orientations to each other, which is why in my first reply to you I advised you to make sure that the edges of the scanned sections were as parallel as possible:
- 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 :-)
On 3/27/2024 8:50 AM, Java Jive wrote:
On 27/03/2024 08:46, Jasen Betts wrote:
On 2024-03-24, Carlos E.R. <robin_listas@es.invalid> wrote:
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.
This can happen if the scan sections are done at different orientations to each other, which is why in my first reply to you I advised you to make sure that the edges of the scanned sections were as parallel as possible:
- 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.
The noise from these defects, makes it harder for automated
tools to assign control points and pick transformations.
There 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.
Hugin is not the answer, because it demands the assignment
of a multitude of control points, which hardly saves a human
any effort whatsoever.
That 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.
Microsoft 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.
My scanner was perfectly functional, when I tried a stitching
project, and the output, was no more useful than what Carlos
is getting.
When 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.
Scanners 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.
On 2024-03-26 14:27, Paul wrote:
On 3/26/2024 7:50 AM, Carlos E.R. wrote:
On 2024-03-26 01:29, Paul wrote:
On 3/25/2024 11:51 AM, Carlos E.R. wrote:
To control the intensity (your 1650 has intensity level control!),
you can PWM the inverter at 200Hz. In effect it kind of runs
in burst mode. Bursts of 25KHz high voltage. By using PWM
modulation, the CCFL tube achieves a wider range of intensities.
I have not seen an intensity control in xsane. And I have never used it
in Windows.
On 2024-03-26 22:51, Carlos E.R. wrote:
On 2024-03-26 14:27, Paul wrote:
On 3/26/2024 7:50 AM, Carlos E.R. wrote:
On 2024-03-26 01:29, Paul wrote:
On 3/25/2024 11:51 AM, Carlos E.R. wrote:
...
To control the intensity (your 1650 has intensity level control!),
you can PWM the inverter at 200Hz. In effect it kind of runs
in burst mode. Bursts of 25KHz high voltage. By using PWM
modulation, the CCFL tube achieves a wider range of intensities.
I have not seen an intensity control in xsane. And I have never used it in Windows.
I mean I have never used the scanner in Windows.
On 27/03/2024 08:46, Jasen Betts wrote:
On 2024-03-24, Carlos E.R. <robin_listas@es.invalid> wrote:
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.
This can happen if the scan sections are done at different orientations
to each other, which is why in my first reply to you I advised you to
make sure that the edges of the scanned sections were as parallel as possible:
- 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 :-)
On 27/03/2024 15:50, Paul wrote:
On 3/27/2024 8:50 AM, Java Jive wrote:
On 27/03/2024 08:46, Jasen Betts wrote:
On 2024-03-24, Carlos E.R. <robin_listas@es.invalid> wrote:
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.
The noise from these defects, makes it harder for automated
tools to assign control points and pick transformations.
Agreed.
On 3/27/2024 8:50 AM, Java Jive wrote:
On 27/03/2024 08:46, Jasen Betts wrote:
On 2024-03-24, Carlos E.R. <robin_listas@es.invalid> wrote:
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.
This can happen if the scan sections are done at different orientations to each other, which is why in my first reply to you I advised you to make sure that the edges of the scanned sections were as parallel as possible:
- 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.
The noise from these defects, makes it harder for automated
tools to assign control points and pick transformations.
There 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.
Hugin is not the answer, because it demands the assignment
of a multitude of control points, which hardly saves a human
any effort whatsoever. That 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.
Microsoft 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.
My scanner was perfectly functional, when I tried a stitching
project, and the output, was no more useful than what Carlos
is getting.
When 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.
Scanners 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.
Paul
On 2024-03-27 13:50, Java Jive wrote:
On 27/03/2024 08:46, Jasen Betts wrote:
On 2024-03-24, Carlos E.R. <robin_listas@es.invalid> wrote:
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.
This can happen if the scan sections are done at different
orientations to each other, which is why in my first reply to you I
advised you to make sure that the edges of the scanned sections were
as parallel as possible:
Not the case.
Map:
************************************ * * * * * * * * * * * * * A * * * * * * * * * * * * * D * ***************************** * * * * * * * * * * * B * * * * * * ******** * * * * * * * * * ***************************** E * * * * * * * * C * * * * * * * * * * * ************************************
A, B, and C were rotated 90°, so all at the same rotation.
Edge A to B, with overlap, did not match when zooming.
See photos:
left end: <https://paste.opensuse.org/pastes/ecbec3d8650e>
right end <https://paste.opensuse.org/pastes/b09e2b4b1b3c>
- 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.
not the case
- 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.
not the case
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 error is visible at big zoom. The result with the naked eye is good enough :-)
On 28/03/2024 11:02, Carlos E.R. wrote:
On 2024-03-27 13:50, Java Jive wrote:
On 27/03/2024 08:46, Jasen Betts wrote:
On 2024-03-24, Carlos E.R. <robin_listas@es.invalid> wrote:
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.
This can happen if the scan sections are done at different
orientations to each other, which is why in my first reply to you I
advised you to make sure that the edges of the scanned sections were
as parallel as possible:
Not the case.
Map:
************************************
* * *
* * *
* * *
* * *
* A * *
* * *
* * *
* * *
* * D *
***************************** *
* * *
* * *
* * *
* B * *
* * *
* ********
* * *
* * *
* * *
***************************** E *
* * *
* * *
* C * *
* * *
* * *
* * *
************************************
A, B, and C were rotated 90°, so all at the same rotation.
Edge A to B, with overlap, did not match when zooming.
See photos:
left end: <https://paste.opensuse.org/pastes/ecbec3d8650e>
right end <https://paste.opensuse.org/pastes/b09e2b4b1b3c>
In what follows, I am presuming that was your attempt with Hugins, if
that's wrong then so is everything in this section of my reply ...
It looks to me like you have a very old map on degraded paper. There
can be a number of extra problems with such documents in particular due
to their lack of structural integrity, some of which can be important
wrt scanning ...
- It can be difficult to keep them flat on the scanner glass, particularly if the scanner lid has had to be removed to do a large document, and particularly as many, probably most, scanners have the
glass recessed into a bezel, instead of the glass surface being level
with that of the surrounding bezel, which would make things a hell of a
lot easier. I use a pile of old books, a Haynes manual is about the
right size, instead of the lid, with sufficient clean paper between the books and the back of the documents to prevent the printed cover of the bottom book showing through the document to be scanned. This can be
very fiddly and tedious, but can be made to work [*].
The glass being recessed into a bezel also means that when you place on
the glass a document to be scanned in sections because it is larger than
the glass, strips near the edge are curved upwards away from the glass
to the level of the surrounding bezel, and this alters their scale
(tends to bunch together, only along the axis across the join, what is printed on the document) and possibly their focus (they may be
increasingly blurred towards the edge of the scan). With old documents, they may not have the structural integrity to withstand this, and may stretch or even tear at the edges. My way of dealing with this is to
remove those distorted strips by cropping them off either at scan time
or subsequently. Of course, the disadvantage of doing this is that by using only the central area of each scan you have to increase the number
of scanned sections to cover a given document, remembering that you
still need around 2-2.5 cms of overlap between neighbouring sections
AFTER CROPPING for Hugin or other stitching software to be able to
automate the stitch, so, given the width of the strips to be cropped are probably about the same as the desired overlap, you need double the
overlap between sections.
* For the Snowman Tree, I was getting so exasperated with the
fiddliness of aligning the blank paper and the books, that I devised a better solution. I happen to have a dead other of the same model of scanner, which originally I'd bought cheaply to cannibalise to repair, successfully, my own ADF feeder. I adapted the lid off that by removing the ADF and the hinges, so now I place this spare lid manually then pile
the books on top of that, much less fiddle.
- 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.
not the case
- 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.
not the case
Looking at your layout diagram above, it does appear to me that the
sections at the RH edge D & E are done at 90 degrees to the others? If
so, I would expect, especially with an old scanner, that there might be problems stitching these two section to the rest of the document.
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 error is visible at big zoom. The result with the naked eye is
good enough :-)
Fair enough, it's always your choice when the result is 'good enough'.
I managed to create the control points, I did enjoy up to that point.
On the following stage, the instructions on the menus to click did not manage the reality and I could not find where they had been migrated to. I'm surprised that hugin doesn't have a mode to stitch scanner results. Or some other software.
https://hugin.sourceforge.io/tutorials/scans/en.shtml
In the end, creating those control points takes about the same time as joining in gimp.
The procedure I followed was (written by a profesional photographer I know, who uses gimp a lot):
+++...............
Open one image in the gimp. Enlarge canvas to the full end size or larger. Load the other images as layers.
Show only first layer and an adjoining one. Make the adjoining one semi-transparent and move it around until it fits. Make it nontrasparent again.
Continue with the remaining layers.
Save as jpg, png or whatever (or as xcf if you want to preserve layers)
Done.
................++-
To change transparency:
Press "Ctrl-L" to display the Layers toolbox at the right of the GIMP window. You can also click "Windows" at the top and select "Layers" from the menu. The layer that contains the image is selected by default.
3.
Click and drag the "Opacity" slider at the top of the Layers toolbox to the left to decrease the opacity and increase the transparency.
This other method for transparency failed, because I did not find how to reverse at the end:
To do this, select the layer and then go to Layer > Transparency > Color to Alpha. Within the image editing jargon, “alpha” refers to the “alpha channel” of an image, which controls the transparency level of the pixels. In the “Color to Alpha” window, choose a color that will be considered as transparent.
Working with layers on GIMP - PSL Explore
PSL Explore
https://explore.psl.eu › tools-and-training › tutorials › w...
<https://explore.psl.eu/en/tools-and-training/tutorials/working-layers-gimp>
For movement, I penciled two black dots in the map, at each end of the overlapping section. I match one, make this the rotating centre, and then rotate till the other end matches.
Took a bit to to do the first rotation, then it was easy.
(from the image menu bar Tools → Transform Tools → Rotate, by clicking the tool icon: in the Toolbox, by using the Shift+R key combination.) There is a button that makes the centre of rotation appear in the centre of the visible image.
What I found a nuisance was that I do not know how to zoom out and in while keeping the tool for rotate or shift active.
Microsoft 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.
My scanner was perfectly functional, when I tried a stitching
project, and the output, was no more useful than what Carlos
is getting.
When 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.
Scanners 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.
There is an app in Android (BimoStitch) that automatically stitched sections A and B, but refused to do section C. The app is fully automatic, so nothing to do.
*******
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
504 Gateway Time-out
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
504 Gateway Time-out
On 3/28/2024 7:40 AM, Carlos E.R. wrote:
[Picture]
https://i.postimg.cc/J0VBXmvf/correct-uses-the-overlap.gif
504 Gateway Time-out
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
504 Gateway Time-out
Postimage is back now.
Even uploading the images was a problem earlier.
To zoom in and out in GIMP, while other dialogs are open,
use <ctrl> MouseWheel .
And GIMP can occasionally hang, which can be annoying. This
can happen if you switch between "full screen" and "windowed" a lot.
I don't know if that got fixed in some version or not.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 915 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 30:05:18 |
| Calls: | 12,169 |
| Calls today: | 1 |
| Files: | 186,521 |
| Messages: | 2,234,226 |
