Discussion:
How to stitch scanned papers?
(too old to reply)
Carlos E.R.
2024-03-23 02:26:21 UTC
Permalink
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.
--
Cheers, Carlos.
Farley Flud
2024-03-23 10:23:36 UTC
Permalink
Post by Carlos E.R.
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.
If you can get it to compile then you might try this:

https://xmerge.sourceforge.net/


Also, you could try pnmstitch from NetPBM:

https://netpbm.sourceforge.net/doc/pnmstitch.html


I can't say how well either of these would work, but if
you do try then please report the results here. I am
curious.
Paul
2024-03-23 13:22:28 UTC
Permalink
Post by Carlos E.R.
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]

Loading Image...

Paul
Carlos E.R.
2024-03-24 04:01:43 UTC
Permalink
Post by Paul
Post by Carlos E.R.
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
Yes, I found that one. I tried, till I got to a point that did not match
the instructions and got stuck.

I am actually doing the job with gimp, and it is working. Takes time,
though.

I also tried an android tool, BimoStitch. It got two images stitched
automatically, but refused to add the third, said it found no coincidences.
Post by Paul
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
Ah, but that's Windows.
--
Cheers, Carlos.
Paul
2024-03-24 04:55:57 UTC
Permalink
Post by Carlos E.R.
Post by 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.
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.

Paul
Carlos E.R.
2024-03-24 15:01:42 UTC
Permalink
Post by Paul
Post by Carlos E.R.
Post by 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.
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°)
--
Cheers, Carlos.
Paul
2024-03-24 17:53:26 UTC
Permalink
Post by Paul
Post by Carlos E.R.
Post by 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.
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.
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.

Paul
Carlos E.R.
2024-03-24 22:29:30 UTC
Permalink
Post by Paul
Post by Paul
Post by Carlos E.R.
Post by 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.
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.
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.
Post by Paul
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.
Post by Paul
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.
--
Cheers, Carlos.
Paul
2024-03-25 02:50:47 UTC
Permalink
Post by Paul
Post by Paul
Post by Carlos E.R.
Post by 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.
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.
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.
Post by Paul
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.
Post by Paul
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 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.

Loading Image...

( https://en.wikipedia.org/wiki/Contact_image_sensor )

Perhaps the nylon slider is a bit loose.

Paul
Carlos E.R.
2024-03-25 10:43:09 UTC
Permalink
...
Post by Paul
Post by Carlos E.R.
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°)
...
Post by Paul
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.
The apparent problem in mine is that the distance between the individual
pixels in the sensor is not constant.
--
Cheers, Carlos.
Paul
2024-03-25 14:45:38 UTC
Permalink
Post by Paul
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
Carlos E.R.
2024-03-25 15:51:32 UTC
Permalink
Post by Paul
Post by Paul
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.
But then the error would not be progressive, would be in chunks.
Post by Paul
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.
Same here,

It is an Epson Perfection 1650.
Post by Paul
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.
Mine is thick, too.
Post by Paul
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
--
Cheers, Carlos.
Paul
2024-03-26 00:29:26 UTC
Permalink
Post by Carlos E.R.
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 rest of the electronics,
24V would be a poor choice and need SMPS circuits
on the controller board. Sometimes a designer does
this on purpose, when the logic board "has some
known noise sensitive circuits onboard".

https://www.photrio.com/forum/threads/scan-lines-with-epson-perfection-1650.166330/

There appears what might be two H-bridge drivers on the controller board.
The stepper has a gear train that includes two plastic gears, plus a
rubber belt, a single steel transport rod, but for the scanning assembly,
I still cannot figure out how it works or what it's made of. I have a picture
of someone cleaning around the sensor, but the rod I'm looking at there,
is likely the CCFL illumination source.

Like any modern scanner, it has one scanner chip, an ancient-looking
ROM and a RAM chip. The scanner chip is an all-in-one, as that is
what the evolution of the electronics produced. Sometimes the scanner
chips "cross brands" and are used more than once. There might
have been quite a few single chip National Semiconductor, a company
that disappeared at one point.

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.

Paul
Carlos E.R.
2024-03-26 11:50:25 UTC
Permalink
Post by Paul
Post by Carlos E.R.
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.

...
Post by Paul
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.
--
Cheers, Carlos.
Paul
2024-03-26 13:27:03 UTC
Permalink
Post by Carlos E.R.
Post by Paul
Post by Carlos E.R.
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.
Post by Paul
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" :-)

Paul
Carlos E.R.
2024-03-26 21:51:02 UTC
Permalink
Post by Paul
Post by Carlos E.R.
Post by Paul
Post by Carlos E.R.
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.
Post by Paul
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.
I have not seen an intensity control in xsane. And I have never used it
in Windows.
Post by Paul
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.
Ah, that could explain why the colour of the same paper section is off
between two scans.
Post by Paul
And it's not really all that good of a scanner, but the
marketing people "spared no effort" :-)
Well, I did not know :-)
--
Cheers, Carlos.
Carlos E.R.
2024-03-28 02:14:21 UTC
Permalink
...
Post by Carlos E.R.
Post by Paul
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.
--
Cheers, Carlos.
Paul
2024-03-28 05:34:26 UTC
Permalink
Post by Carlos E.R.
...
Post by Paul
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.
It's not clear why your scanner even has an intensity control.
Most scanners seem to run at a fixed level.

Paul
Jasen Betts
2024-03-27 08:46:05 UTC
Permalink
Post 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.
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
--
Jasen.
🇺🇦 Слава Україні
Java Jive
2024-03-27 12:50:34 UTC
Permalink
Post by Jasen Betts
Post 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.
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.
Post by Jasen Betts
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 :-)
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
Paul
2024-03-27 15:50:52 UTC
Permalink
Post 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.

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]

Loading Image...

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.

Loading Image...

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
Java Jive
2024-03-27 17:19:58 UTC
Permalink
Post by Paul
Post 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 Paul
The noise from these defects, makes it harder for automated
tools to assign control points and pick transformations.
Agreed.
Post by Paul
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.
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 Paul
Hugin 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 Paul
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.
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 Paul
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.
Yes, I've found ICE to be pretty good, but by no means perfect.
Post by Paul
My 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 Paul
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.
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 Paul
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.
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
Carlos E.R.
2024-03-28 11:33:00 UTC
Permalink
...
Post by Java Jive
Post by Paul
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.
Oh, it is very simple: I can't justify the expense. I have the original
paper map, and the person that wanted the copy will not complain: what
he had was a black an white photocopy. What I gave him was better than that.

Perfection is not required, but the defects took me by surprise.

In case I need a better result, I will do a photocopy at some paying
place that does A3 size at least. Or, if do it myself, take a photo with
a camera.
Post by Java Jive
 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 Paul
The noise from these defects, makes it harder for automated
tools to assign control points and pick transformations.
Agreed.
...

I will try, redoing the scans at half the resolution (300 dpi) and
keeping the orientation somehow, if possible.
--
Cheers, Carlos.
Carlos E.R.
2024-03-28 11:40:29 UTC
Permalink
Post by Paul
Post 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.
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.
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.
Post by Paul
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.
Post by Paul
*******
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
Post by Paul
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
Post by Paul
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
--
Cheers, Carlos.
Paul
2024-03-28 16:22:05 UTC
Permalink
Post by Carlos E.R.
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.
+++...............
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.
................++-
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.
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.
Post by Paul
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.
Post by Paul
*******
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
Post by Paul
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.

Paul
Carlos E.R.
2024-03-28 19:00:31 UTC
Permalink
...
Post by Paul
Post by Carlos E.R.
Post by Paul
    [Picture]
    https://i.postimg.cc/J0VBXmvf/correct-uses-the-overlap.gif
504 Gateway Time-out
Post by Paul
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.
Aha.
Post by Paul
To zoom in and out in GIMP, while other dialogs are open,
use <ctrl> MouseWheel .
AH! That's easy, somehow I forgot.
Post by Paul
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.
I don't know, it has not happened to me in recent memory.
--
Cheers, Carlos.
Carlos E.R.
2024-03-28 11:02:11 UTC
Permalink
Post by Java Jive
Post 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.
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
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>
Post by Java Jive
 - 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
Post by Java Jive
 - 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
Post by Java Jive
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 :-)
--
Cheers, Carlos.
Java Jive
2024-03-28 13:15:58 UTC
Permalink
Post by Carlos E.R.
Post by Java Jive
Post 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.
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
Not the case.
************************************
*                           *      *
*                           *      *
*                           *      *
*                           *      *
*       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.
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.
Post by Carlos E.R.
Post by Java Jive
  - 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
Post by Java Jive
  - 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.
Post by Carlos E.R.
Post by Java Jive
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'.
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
Carlos E.R.
2024-03-28 13:34:34 UTC
Permalink
Post by Java Jive
Post by Carlos E.R.
Post by Java Jive
Post 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.
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
Not the case.
************************************
*                           *      *
*                           *      *
*                           *      *
*                           *      *
*       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.
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 ...
No, with Gimp.

With Hugins, as I said in another post, I could not complete the
procedure because the instructions to click here and there do not match
my menus and I could not find the equivalent.
Post by Java Jive
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 ...
Not older than 40 or 50 years.

It is photo copy made using chemical paper, while the original (not
available to me) was drawn on semitransparent drawing paper.
Post by Java Jive
 - 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.
The edge bezel was not the problem in my first photo, because that
portion is near the paper edge.
Post by Java Jive
Post by Carlos E.R.
Post by Java Jive
  - 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
Post by Java Jive
  - 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.
D & E were not rotated, while A, B & C were rotated 90. The photos I
posted are of A-B work, so the vertical axis on the photos are actually
the horizontal axis of the scanner.
Post by Java Jive
Post by Carlos E.R.
Post by Java Jive
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'.
Yep.

Nobody is expected to do measurements with a rule on that map.
--
Cheers, Carlos.
Java Jive
2024-03-23 13:47:19 UTC
Permalink
Post by Carlos E.R.
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!
Yup, so effectively the focal length is infinity, but you can't enter
that into the program, so give it the longest focal length that it will
accept, I've used 1000 in the past, as described in this thread which
started out being about hand or cursive writing recognition software,
but morphed into being about stitching large scanned documents together:

https://alt.windows7.general.narkive.com/3nAPl2Rs/hand-writing-recognition-software

... particularly ...

https://alt.windows7.general.narkive.com/3nAPl2Rs/hand-writing-recognition-software#post65
Post by Carlos E.R.
Is there something that works?
For Hugin, see the link above, but see also below ...
Post by Carlos E.R.
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 principle at least, you can use most image editing software to do it
by hand, but it can be desperately time-consuming and tedious to do it
this way. As you suggest, a successful stitch with automatic software
can save hours.

While I have managed to get Hugin (Linux) to work, as described in the
above thread, I've had more consistent results with Image Composition
Editor (ICE) (Windows), for which a link was given in the above linked
thread, but the program has since been withdrawn and there is no longer
a download link on the Microsoft site. However, the program is still
available via the web-archive:

https://web.archive.org/web/20191208054508/https://www.microsoft.com/en-us/research/product/computational-photography-applications/image-composite-editor/

More generally, here are some tips learned by often exasperated and
wearisome experience:

1) Make sure that there is sufficient overlap between the scanned
sections, probably about 2-2.5 cms (1 inch) all round. Anything smaller
tends to fail with misaligned results.

2) Try and keep the edges of the scanned sections as parallel as you
can. While a small amount of error will be accommodated by good
stitching software, larger errors will tend to cause significant problems.

3) Set the scanner just to scan without attempting to optimise the
contrast or clean up the results. You'll have to do the latter manually
in external software once the final correctly stitched image has been
created.

4) Note that different programs mean different things by
'grayscale/greyscale', so if, for example, you you scan something as
'greyscale' using your scanner's software, but then decide to edit one
section, perhaps to remove a blemish, before doing the stitch, you may
find that the edited section has been saved in a different format to the
others, and the stitching software complains, as described here:

https://groups.google.com/g/uk.comp.os.linux/c/8laKirJfq18

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.
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
Java Jive
2024-03-23 14:03:23 UTC
Permalink
Post by Java Jive
In case you need inspiration to continue, here are some of my most
But some of my least successful links, sorry about that. Here are the
Post by Java Jive
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);
<www.macfh.co.uk/Temp/Snowman Tree.png>
<www.macfh.co.uk/Temp/Snowman%20Tree.png>
Post by Java Jive
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
<www.macfh.co.uk/Temp/197709 Ben Cruachan - Panorama From The Summit
(full).png>
<www.macfh.co.uk/Temp/197709%20Ben%20Cruachan%20-%20Panorama%20From%20The%20Summit%20(full).png>
Post by Java Jive
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
<www.macfh.co.uk/Temp/20121127_145528 Panorama Over Loch Alsh From Kyle
Viewpoint.png>
<www.macfh.co.uk/Temp/20121127_145528%20Panorama%20Over%20Loch%20Alsh%20From%20Kyle%20Viewpoint.png>
Post by Java Jive
A sunset from near my home, taken with a mobile phone, a Samsung Galaxy
<www.macfh.co.uk/Temp/20171027_180507 Sunset Panorama Over Achnairn &
Loch Shin.jpg>
<www.macfh.co.uk/Temp/20171027_180507%20Sunset%20Panorama%20Over%20Achnairn%20&%20Loch%20Shin.jpg>
Post by Java Jive
So it can be done, but it can take a great deal of patient trial & error
to get the software to work well.
--
Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk
Loading...