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.

On Sat, 23 Mar 2024 03:26:21 +0100, 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.
>

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.

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

On 23/03/2024 02:26, 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!

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

> Is there something that works?

For Hugin, see the link above, but see also below ...

> 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

On 23/03/2024 13:47, Java Jive wrote:
>
> In case you need inspiration to continue, here are some of my most
> successful stitches:

But some of my least successful links, sorry about that. Here are the
corrections:

> 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>

<www.macfh.co.uk/Temp/Snowman%20Tree.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>

<www.macfh.co.uk/Temp/197709%20Ben%20Cruachan%20-%20Panorama%20From%20The%20Summit%20(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>

<www.macfh.co.uk/Temp/20121127_145528%20Panorama%20Over%20Loch%20Alsh%20From%20Kyle%20Viewpoint.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>

<www.macfh.co.uk/Temp/20171027_180507%20Sunset%20Panorama%20Over%20Achnairn%20&%20Loch%20Shin.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

On 2024-03-23 14:22, Paul wrote:
> 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

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.

>
> 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.

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.

Paul

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°)

--
Cheers, Carlos.

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.

Paul

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.

--
Cheers, Carlos.

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:
>>>>
>>>>>> 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 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.

Paul

On 2024-03-25 03:50, Paul wrote:
> 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.

The apparent problem in mine is that the distance between the individual
pixels in the sensor is not constant.

--
Cheers, Carlos.

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

On 2024-03-25 15:45, Paul wrote:
> 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.

But then the error would not be progressive, would be in chunks.

>
> 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.

>
> 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.

>
> 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.

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 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

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.

--
Cheers, Carlos.

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" :-)

Paul

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:
>>>
>>>> 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.

I have not seen an intensity control in xsane. And I have never used it
in Windows.

> 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.

>
> 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.

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

--
Jasen.
🇺🇦 Слава Україні

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 :-)

--

Fake news kills!

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

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 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:
>>>>
>>>> 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.

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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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.

> 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

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.

--
Cheers, Carlos.

On 3/27/2024 10:14 PM, Carlos E.R. wrote:
> 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.
>

It's not clear why your scanner even has an intensity control.
Most scanners seem to run at a fixed level.

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 :-)

--
Cheers, Carlos.