On 2024-03-27 18:19, Java Jive wrote:
> On 27/03/2024 15:50, Paul wrote:
>>
>> On 3/27/2024 8:50 AM, Java Jive wrote:
>>>
>>> On 27/03/2024 08:46, Jasen Betts wrote:
>>>>
>>>> On 2024-03-24, Carlos E.R. <robin_listas@es.invalid> wrote:

....

>> The scanner has a non-standard defect.
>>
>> The scanner also has a standard defect. Two defects at once.
>
> Yes, but it's still a given, which could only be changed if Carlos was
> prepared to find another scanner and redo the work, but his posing a
> question here suggests that either that option is not possible, or would
> be even more difficult or even more work for reasons that we don't know.

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.

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

....

I will try, redoing the scans at half the resolution (300 dpi) and
keeping the orientation somehow, if possible.

--
Cheers, Carlos.

On 2024-03-27 16: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.
>
> 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.

>
> Microsoft ICE (from the Microsoft Research division) does a
> damn good job, considering scanner input is garbage to begin
> with. The output for my project was "imaginative but incorrect".
> And so it goes.
>
> Like OCR, close but no cigar.
>
> My scanner was perfectly functional, when I tried a stitching
> project, and the output, was no more useful than what Carlos
> is getting.
>
> When you shoot panoramas with a panorama camera on a tripod,
> a number of the defects are gone (compared to using a scanner
> on paper stock), and you only have a couple transforms to apply
> to get a reasonably correct output. That's why people bother
> to shoot panoramas that way, because they got output that worked.
>
> Scanners and paper stock, are "a bridge too far". Too much
> garbage input, too much garbage output. But it's at least
> interesting, to see how much algorithmic attempts have progressed.

There is an app in Android (BimoStitch) that automatically stitched
sections A and B, but refused to do section C. The app is fully
automatic, so nothing to do.

>
> *******
>
> It doesn't seem to handle all of the line overlap cases well,
> but otherwise the stitching ICE does, is pretty good. But,
> you really do need the images to overlap. It would take me
> all day, to step along that seam and make it look this good.
>
> [Picture]
>
> https://i.postimg.cc/J0VBXmvf/correct-uses-the-overlap.gif

504 Gateway Time-out

>
> The cleanup work I'd have to do in GIMP in that one, would
> be limited to trying to fix the hop in the line near the top.
>
> In this case, only the very edges of the two images correlate, and
> the tool completely blows it. Zero overlap. It has removed a
> strip of material that should not have been removed. There was
> no indication on the screen, that the confidence interval was low.
> It's up to me to zoom in and inspect.
>
> https://i.postimg.cc/QM3PfW5C/no-overlap-it-fails.gif

504 Gateway Time-out

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

On 28/03/2024 11:02, Carlos E.R. wrote:
>
> On 2024-03-27 13:50, Java Jive wrote:
>>
>> On 27/03/2024 08:46, Jasen Betts wrote:
>>>
>>> On 2024-03-24, Carlos E.R. <robin_listas@es.invalid> wrote:
>>>>
>>>> I found something else when stitching manually with gimp. It is a land
>>>> plot plan, scanned with a generous overlap, but the two images do not
>>>> match. I make one line overlap fully, but the next one doesn't. The
>>>> scanner pixel distance left or right end (of the moving sensor) is not
>>>> the same. I imagined motor inexactitudes, but this is surprising.
>>
>> This can happen if the scan sections are done at different
>> orientations to each other, which is why in my first reply to you I
>> advised you to make sure that the edges of the scanned sections were
>> as parallel as possible:
>
> Not the case.
>
> Map:
>
> ************************************
> *                           *      *
> *                           *      *
> *                           *      *
> *                           *      *
> *       A                   *      *
> *                           *      *
> *                           *      *
> *                           *      *
> *                           *   D  *
> *****************************      *
> *                           *      *
> *                           *      *
> *                           *      *
> *        B                  *      *
> *                           *      *
> *                           ********
> *                           *      *
> *                           *      *
> *                           *      *
> *****************************   E  *
> *                           *      *
> *                           *      *
> *         C                 *      *
> *                           *      *
> *                           *      *
> *                           *      *
> ************************************
>
>
> A, B, and C were rotated 90°, so all at the same rotation.
>
> Edge A to B, with overlap, did not match when zooming.
> See photos:
>
> left end: <https://paste.opensuse.org/pastes/ecbec3d8650e>
> right end <https://paste.opensuse.org/pastes/b09e2b4b1b3c>

In what follows, I am presuming that was your attempt with Hugins, if
that's wrong then so is everything in this section of my reply ...

It looks to me like you have a very old map on degraded paper. There
can be a number of extra problems with such documents in particular due
to their lack of structural integrity, some of which can be important
wrt scanning ...

- It can be difficult to keep them flat on the scanner glass,
particularly if the scanner lid has had to be removed to do a large
document, and particularly as many, probably most, scanners have the
glass recessed into a bezel, instead of the glass surface being level
with that of the surrounding bezel, which would make things a hell of a
lot easier. I use a pile of old books, a Haynes manual is about the
right size, instead of the lid, with sufficient clean paper between the
books and the back of the documents to prevent the printed cover of the
bottom book showing through the document to be scanned. This can be
very fiddly and tedious, but can be made to work [*].

The glass being recessed into a bezel also means that when you place on
the glass a document to be scanned in sections because it is larger than
the glass, strips near the edge are curved upwards away from the glass
to the level of the surrounding bezel, and this alters their scale
(tends to bunch together, only along the axis across the join, what is
printed on the document) and possibly their focus (they may be
increasingly blurred towards the edge of the scan). With old documents,
they may not have the structural integrity to withstand this, and may
stretch or even tear at the edges. My way of dealing with this is to
remove those distorted strips by cropping them off either at scan time
or subsequently. Of course, the disadvantage of doing this is that by
using only the central area of each scan you have to increase the number
of scanned sections to cover a given document, remembering that you
still need around 2-2.5 cms of overlap between neighbouring sections
AFTER CROPPING for Hugin or other stitching software to be able to
automate the stitch, so, given the width of the strips to be cropped are
probably about the same as the desired overlap, you need double the
overlap between sections.

* For the Snowman Tree, I was getting so exasperated with the
fiddliness of aligning the blank paper and the books, that I devised a
better solution. I happen to have a dead other of the same model of
scanner, which originally I'd bought cheaply to cannibalise to repair,
successfully, my own ADF feeder. I adapted the lid off that by removing
the ADF and the hinges, so now I place this spare lid manually then pile
the books on top of that, much less fiddle.

>>   - If the sections are even only slightly rotated with respect to
>> each other, distances between visible points across the scans will
>> differ, at least a little.
>
> not the case
>
>>   - Particularly, if the scan sections were done at right-angles to
>> each other, although the resolution across and down the length of the
>> scanner may nominally be the same, in fact they can vary
>> significantly, particularly, as Paul has pointed out, as the toothed
>> belt in the driving mechanism wears.  My oldest scanner, an HP 5490C
>> Model C9850A that did the Snowman Tree, suffers from this.
>
> not the case

Looking at your layout diagram above, it does appear to me that the
sections at the RH edge D & E are done at 90 degrees to the others? If
so, I would expect, especially with an old scanner, that there might be
problems stitching these two section to the rest of the document.

>>> In The GIMP use the "perspective" tool  that's what I use when I need
>>> to make
>>> several things line up.   it can fix a stretch or a skew or a keystone
>>> distortion.
>>>
>>> https://docs.gimp.org/en/gimp-tool-perspective.html
>>
>> Yes, you can do this in many decent image editing programs, but it can
>> be very tedious to get everything just right.
>>
>> Another method is to alter the resolution slightly, you count the
>> number of pixels between visibly the same points near opposite edges
>> of the two scans (a rubber-banding tool is useful for this) and
>> decrease the resolution of the wider of the two proportionately.
>> Again, fiddly and tedious to get exactly right, and you have to know
>> how to perform simple proportionality or scaling arithmetic, which, to
>> me surprisingly, a large number of people seem unable to do.
>>
>> But, hey, Carlos & Paul seems to be enjoying their discussion about
>> the intricacies of scanner design  -  which, given that the scanner in
>> its current state is a given and can't be changed, doesn't seem likely
>> to solve Carlos' actual problem  -  so why should we butt in with
>> practical, helpful advice :-)
>
> :-))
>
> The error is visible at big zoom. The result with the naked eye is good
> enough :-)

Fair enough, it's always your choice when the result is 'good enough'.

--

Fake news kills!

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

On 2024-03-28 14:15, Java Jive wrote:
> On 28/03/2024 11:02, Carlos E.R. wrote:
>>
>> On 2024-03-27 13:50, Java Jive wrote:
>>>
>>> On 27/03/2024 08:46, Jasen Betts wrote:
>>>>
>>>> On 2024-03-24, Carlos E.R. <robin_listas@es.invalid> wrote:
>>>>>
>>>>> I found something else when stitching manually with gimp. It is a land
>>>>> plot plan, scanned with a generous overlap, but the two images do not
>>>>> match. I make one line overlap fully, but the next one doesn't. The
>>>>> scanner pixel distance left or right end (of the moving sensor) is not
>>>>> the same. I imagined motor inexactitudes, but this is surprising.
>>>
>>> This can happen if the scan sections are done at different
>>> orientations to each other, which is why in my first reply to you I
>>> advised you to make sure that the edges of the scanned sections were
>>> as parallel as possible:
>>
>> Not the case.
>>
>> Map:
>>
>> ************************************
>> *                           *      *
>> *                           *      *
>> *                           *      *
>> *                           *      *
>> *       A                   *      *
>> *                           *      *
>> *                           *      *
>> *                           *      *
>> *                           *   D  *
>> *****************************      *
>> *                           *      *
>> *                           *      *
>> *                           *      *
>> *        B                  *      *
>> *                           *      *
>> *                           ********
>> *                           *      *
>> *                           *      *
>> *                           *      *
>> *****************************   E  *
>> *                           *      *
>> *                           *      *
>> *         C                 *      *
>> *                           *      *
>> *                           *      *
>> *                           *      *
>> ************************************
>>
>>
>> A, B, and C were rotated 90°, so all at the same rotation.
>>
>> Edge A to B, with overlap, did not match when zooming.
>> See photos:
>>
>> left end: <https://paste.opensuse.org/pastes/ecbec3d8650e>
>> right end <https://paste.opensuse.org/pastes/b09e2b4b1b3c>
>
> In what follows, I am presuming that was your attempt with Hugins, if
> that's wrong then so is everything in this section of my reply ...

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.

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

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

>
>>>   - If the sections are even only slightly rotated with respect to
>>> each other, distances between visible points across the scans will
>>> differ, at least a little.
>>
>> not the case
>>
>>>   - Particularly, if the scan sections were done at right-angles to
>>> each other, although the resolution across and down the length of the
>>> scanner may nominally be the same, in fact they can vary
>>> significantly, particularly, as Paul has pointed out, as the toothed
>>> belt in the driving mechanism wears.  My oldest scanner, an HP 5490C
>>> Model C9850A that did the Snowman Tree, suffers from this.
>>
>> not the case
>
> Looking at your layout diagram above, it does appear to me that the
> sections at the RH edge D & E are done at 90 degrees to the others?  If
> so, I would expect, especially with an old scanner, that there might be
> problems stitching these two section to the rest of the document.

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.

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

On 3/28/2024 7:40 AM, Carlos E.R. wrote:

> I managed to create the control points, I did enjoy up to that point.
> On the following stage, the instructions on the menus to click did not manage the reality and I could not find where they had been migrated to. I'm surprised that hugin doesn't have a mode to stitch scanner results. Or some other software.
>
> https://hugin.sourceforge.io/tutorials/scans/en.shtml
>
>
> In the end, creating those control points takes about the same time as joining in gimp.
>
> The procedure I followed was (written by a profesional photographer I know, who uses gimp a lot):
>
> +++...............
> Open one image in the gimp. Enlarge canvas to the full end size or larger.
> Load the other images as layers.
> Show only first layer and an adjoining one. Make the adjoining one semi-transparent and move it around until it fits. Make it nontrasparent again.
> Continue with the remaining layers.
> Save as jpg, png or whatever (or as xcf if you want to preserve layers)
> Done.
> ................++-
>
>
> To change transparency:
>
> Press "Ctrl-L" to display the Layers toolbox at the right of the GIMP window. You can also click "Windows" at the top and select "Layers" from the menu. The layer that contains the image is selected by default.
> 3.
>
> Click and drag the "Opacity" slider at the top of the Layers toolbox to the left to decrease the opacity and increase the transparency.
>
>
>
> This other method for transparency failed, because I did not find how to reverse at the end:
>
> To do this, select the layer and then go to Layer > Transparency > Color to Alpha. Within the image editing jargon, “alpha” refers to the “alpha channel” of an image, which controls the transparency level of the pixels. In the “Color to Alpha” window, choose a color that will be considered as transparent.
>
> Working with layers on GIMP - PSL Explore
> PSL Explore
> https://explore.psl.eu › tools-and-training › tutorials › w...
>
> <https://explore.psl.eu/en/tools-and-training/tutorials/working-layers-gimp>
>
>
> For movement, I penciled two black dots in the map, at each end of the overlapping section. I match one, make this the rotating centre, and then rotate till the other end matches.   
>
> Took a bit to to do the first rotation, then it was easy.
>
> (from the image menu bar Tools → Transform Tools → Rotate, by clicking the tool icon: in the Toolbox, by using the Shift+R key combination.) There is a button that makes the centre of rotation appear in the centre of the visible image.
>
>
> What I found a nuisance was that I do not know how to zoom out and in while keeping the tool for rotate or shift active.
>
>
>
>
>>
>> Microsoft ICE (from the Microsoft Research division) does a
>> damn good job, considering scanner input is garbage to begin
>> with. The output for my project was "imaginative but incorrect".
>> And so it goes.
>>
>> Like OCR, close but no cigar.
>>
>> My scanner was perfectly functional, when I tried a stitching
>> project, and the output, was no more useful than what Carlos
>> is getting.
>>
>> When you shoot panoramas with a panorama camera on a tripod,
>> a number of the defects are gone (compared to using a scanner
>> on paper stock), and you only have a couple transforms to apply
>> to get a reasonably correct output. That's why people bother
>> to shoot panoramas that way, because they got output that worked.
>>
>> Scanners and paper stock, are "a bridge too far". Too much
>> garbage input, too much garbage output. But it's at least
>> interesting, to see how much algorithmic attempts have progressed.
>
>
> There is an app in Android (BimoStitch) that automatically stitched sections A and B, but refused to do section C. The app is fully automatic, so nothing to do.
>
>>
>> *******
>>
>> It doesn't seem to handle all of the line overlap cases well,
>> but otherwise the stitching ICE does, is pretty good. But,
>> you really do need the images to overlap. It would take me
>> all day, to step along that seam and make it look this good.
>>
>>     [Picture]
>>
>>     https://i.postimg.cc/J0VBXmvf/correct-uses-the-overlap.gif
>
> 504 Gateway Time-out
>
>>
>> The cleanup work I'd have to do in GIMP in that one, would
>> be limited to trying to fix the hop in the line near the top.
>>
>> In this case, only the very edges of the two images correlate, and
>> the tool completely blows it. Zero overlap. It has removed a
>> strip of material that should not have been removed. There was
>> no indication on the screen, that the confidence interval was low.
>> It's up to me to zoom in and inspect.
>>
>>     https://i.postimg.cc/QM3PfW5C/no-overlap-it-fails.gif
>
> 504 Gateway Time-out

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

On 2024-03-28 17:22, Paul wrote:
> On 3/28/2024 7:40 AM, Carlos E.R. wrote:

....

>>>     [Picture]
>>>
>>>     https://i.postimg.cc/J0VBXmvf/correct-uses-the-overlap.gif
>>
>> 504 Gateway Time-out
>>
>>>
>>> The cleanup work I'd have to do in GIMP in that one, would
>>> be limited to trying to fix the hop in the line near the top.
>>>
>>> In this case, only the very edges of the two images correlate, and
>>> the tool completely blows it. Zero overlap. It has removed a
>>> strip of material that should not have been removed. There was
>>> no indication on the screen, that the confidence interval was low.
>>> It's up to me to zoom in and inspect.
>>>
>>>     https://i.postimg.cc/QM3PfW5C/no-overlap-it-fails.gif
>>
>> 504 Gateway Time-out
>
> Postimage is back now.
>
> Even uploading the images was a problem earlier.

Aha.

>
> To zoom in and out in GIMP, while other dialogs are open,
> use <ctrl> MouseWheel .

AH! That's easy, somehow I forgot.

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