Automatic stitch scans of engineering drawings hopeless?

[jim cullen]

Hello
I'm trying to stitch 24 scans into a 2x3 foot drawing using stitch-scanned-images which is a python script on sf gethub.(Running hugin 2018.0.0 macosx)

First row alone works well.

First 2 of second row fine.

Third scan row 2 has a couple of features with very much in common with second scan row 2 and it gets rejected from stitching.

Is it even possible to automate the stitching of scans in this case? There are good reasons the drawings seem so repetitive.

Any direction in this most appreciated.

Jc

[Bruno Postle]

Any automated tool like this is going to fail some of the time, especially if your images have repetitive features.

I'm not familiar with stitch-scanned-images, but I would expect that in addition to producing a stitched image, it would also provide a PTO project that you can open in Hugin to fix any errors.

--
Bruno

[Gunter Königsmann]

g...@github.com:mpetroff/stitch-scanned-images.git

has worked for me in similar cases.


Kind regards,

   Gunter.

[jim cullen]

Hello
Thanks for your suggestion. After slightly modifying the sticth-scan... Python script I have an output.pto I can open in hugin and add control points. I assume need remove points on repeated features as well, optimize and stich.

Is that basically correct,
and can I delete control points en masse from .pto with vim
and where might I look for basic info such as this preferably in scan/mosaic (only a guess that) context?

I realize this is my problem not yours - thanks again.

Regards
Jc

[Bruno Postle]

On 15 February 2019 22:40:45 GMT, jim cullen wrote:
>Thanks for your suggestion. After slightly modifying the
>sticth-scan... Python script I have an output.pto I can open in hugin
>and add control points. I assume need remove points on repeated
>features as well, optimize and stich.

Yes, hopefully the PTO file has the optimisation parameters correctly set up for a mosaic project rather than a traditional panorama - there is a tutorial on the Hugin website that explains how aligning scanned images works.

>and can I delete control points en masse from .pto with vim
>and where might I look for basic info such as this preferably in
>scan/mosaic (only a guess that) context?

Each control point in the PTO file is a line that starts with 'c', you can delete them without corrupting the file. The file format is documented here: http://hugin.sourceforge.net/docs/nona/nona.txt

--
Bruno

[jim cullen]

Hello -
After vast amounts of work I think I have it pretty much working. 

Basic Approach:
I take the 24 scans comprising an A1 drawing and load them all.
From the assistant I align them all - it makes a mess due to repeated features in the drawing.

I enable scans one at a time in the quick preview and from there for each one I add I optimize after modifying control points as needed.
Eventually everything works pretty well.  I make extensive use of the move/drag and layout tabs, and of course of the control points tab
in the main window.  I have expert turned on.

I use Equirectangular and Mosaic.  I crop to max so I can cut it down later in gimp.  I use center fit and level.

Eventually I stitch and look at the real result.

If any of this is improper practice PLEASE TELL ME.  I have about a week on this monster at this point hence quite ignorant.

Problems:
The size of the thing came out enormous (the physical size of the eventual pdf) so had to scale that back.
I still have some places where lines don't match up and I don't know why.
I have some verticals that bow on the ends which I don't understand either.  I have placed vert and horiz line control points on features to
try and mitigate this.

I you are reading this trying to figure out how to make scans work on engineering drawings you are well advised to take the time to
learn how to use the above tools pretty well.  They are very capable and about as convenient as one could get for interface - for example
in the control points editor you can easily see where you need to check a given scan to see if all the control points make sense.  From
there you can also delete all those that don't make sense which is your only hope in getting stitch to work properly if you have repeated
components in the drawing that confuse the align function. 

I think running align again will break everything on you and I'm quite unclear on whether re-optimize is the same as going to the
quick preview window and running optimize.  I think optimize only runs on the active scans in that place, or rather that is what I have it
set to and I believe that's proper.

Many thanks to all who wrote this thing and much thanks to Bruno for aiming me in the right direction.

Regards,
jc

[Marius Loots]

Hello Jim and all the others,

Wednesday, February 20, 2019, 12:59:18 AM, you wrote:
> After vast amounts of work I think I have it pretty much working. 
> Basic Approach:

Your approach aligns (haha!) well with my workflow in stitching photos
of microscopic slides. Although the origin is different, images from a
good microscope is in effect equivalent to flat scans.

I have the same experience with repeated features. Depending on the
number of images, I would sometimes do an optimise of all images. If
this is totally out of whack, I resort to optimising one at a time.
If there are repeated features incorrectly matched, you immediately
get a feel for this, and just don't apply the results. Compare the
newly added images to all the previously aligned ones, and delete as
needed.

I have managed to stitched - laboriously - more than a hundred images
at times.

I do find that the hugin2012 interface is easier to work with in the
initial phases. It just seems easier.

Size is a problem, nothing really can be done about this. I have at
times resized the initial images when all else fails. And over time I
have found that I reach a limit on my computing capacity, and was able
to go back to older archives when I got a new computer.


Groetnis,
Marius

Add Some Chaos To Your Life And Put The World In Order
http://www.raka.co.za/
mlo...@medic.up.ac.za


--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full
details.

[Frederic Da Vitoria]

Hello, 

Le mar. 19 févr. 2019 à 23:59, jim cullen <talldr...@gmail.com> a écrit :

The size of the thing came out enormous (the physical size of the eventual pdf) so had to scale that back.

You can change the size of the final image inside Hugin, of course. 

 

I still have some places where lines don't match up and I don't know why.
I have some verticals that bow on the ends which I don't understand either.  I have placed vert and horiz line control points on features to
try and mitigate this.

I believe horizontal control points should only be used when assembling an actual landscape panorama, to mark the horizon itself. I never assembled flatbed or microscope images, but I did some mosaic mode stitches. My remark could be wrong... 

Also, you could try "extending" the image, for example by taping something behind what you are scanning. Since the issue is around the border, then move the border out and crop it later. The image you would tape behind should offer opportunities for good control points.

--

Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

[David W. Jones]

Fascinating. I'm guessing that whatever application/system produced the
A1 drawings in the first place - or the data files - aren't available
anymore?

On 2/19/19 12:59 PM, jim cullen wrote:
>
> Hello -
> After vast amounts of work I think I have it pretty much working.
>
> Basic Approach:
> I take the 24 scans comprising an A1 drawing and load them all.
> From the assistant I align them all - it makes a mess due to repeated
> features in the drawing.
>
> I enable scans one at a time in the quick preview and from there for

> each one//I add I optimize after modifying control points as needed.

> <http://hugin.sourceforge.net/docs/nona/nona.txt>


--
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com

[bugbear]

Frederic Da Vitoria wrote:
> I believe horizontal control points should only be used when assembling an actual landscape panorama, to mark the horizon itself. I never assembled flatbed or microscope images, but I did some mosaic mode stitches. My remark could be wrong...

I use horizontal and vertical control points routinely when sitiching mosaic scans, most commonly on the straight edges
of rectangles (e.g. maps).

Hugin is then able to use pitch and yaw, roll to correct any perspective distortion of the stitch, as well as using X,Y,Z
to perform the tesselation of the sub-images.

Optimising something with this many variables MUST (IME) be done incrementally.

BugBear

[Frederic Da Vitoria]

2019-02-20 9:55 UTC+01:00, bugbear <pwo...@papermule.com>:

> Frederic Da Vitoria wrote:
>> I believe horizontal control points should only be used when assembling an
>> actual landscape panorama, to mark the horizon itself. I never assembled
>> flatbed or microscope images, but I did some mosaic mode stitches. My
>> remark could be wrong...
>
> I use horizontal and vertical control points routinely when sitiching mosaic
> scans, most commonly on the straight edges
> of rectangles (e.g. maps).
>
> Hugin is then able to use pitch and yaw, roll to correct any perspective
> distortion of the stitch, as well as using X,Y,Z
> to perform the tesselation of the sub-images.

OK, good to know. Thanks. I'll try this next time I do this type of stitch.

[bugbear]

Frederic Da Vitoria wrote:
> 2019-02-20 9:55 UTC+01:00, bugbear <pwo...@papermule.com>:
>> Frederic Da Vitoria wrote:
>>> I believe horizontal control points should only be used when assembling an
>>> actual landscape panorama, to mark the horizon itself. I never assembled
>>> flatbed or microscope images, but I did some mosaic mode stitches. My
>>> remark could be wrong...
>>
>> I use horizontal and vertical control points routinely when sitiching mosaic
>> scans, most commonly on the straight edges
>> of rectangles (e.g. maps).
>>
>> Hugin is then able to use pitch and yaw, roll to correct any perspective
>> distortion of the stitch, as well as using X,Y,Z
>> to perform the tesselation of the sub-images.
>
> OK, good to know. Thanks. I'll try this next time I do this type of stitch.

I posted a suitable sample set (and pto file) to this list
under the subject line "Mosaic mode test set"

BugBear

[Bruno Postle]

On 19 February 2019 22:59:18 GMT, jim cullen wrote:
>
>I use Equirectangular and Mosaic. I crop to max so I can cut it down later
>in gimp. I use center fit and level.

Equirectangular output projection will result in some curved lines. The only projection that preserves straight lines is rectilinear, so you should make sure that this is set for both input and output projection.

(For a mosaic of scans, it should be possible to do it with yaw and pitch for all input images set to zero - these introduce perspective distortion, which is unwanted. Similarly the a,b,c lens parameters correct barrel distortion, so these should be set to zero)

>I think running align again will break everything on you and I'm quite
>unclear on whether re-optimize is the same as going to the
>quick preview window and running optimize. I think optimize only runs on
>the active scans in that place, or rather that is what I have it
>set to and I believe that's proper.

The Align button does all sorts of clever things depending on context. For this job I would just use the optimize button which only does what you tell it to do.

--
Bruno

[jim cullen]

Hello,

That all makes some sense.

I can't seem to make it fix the roll and pitch at zero successfully during optimization. 

I'm setting the fast preview mode to  Mosaic plane - is that proper?  I ask because the python script 

stitch-scanned-images.py which one can find on github constructs a .pto that seems to use Panosphere.

I'm now setting the first cols of the optimize panel to unchecked and zero for yaw and pitch and leaving 

the roll free (checked).  The script (edit prior to optimize lets me look) seems to have sane vars viz 

Tx Ty and r for each image.  I must be blundering some place else as it keeps saying Panorama must have positive height.

I think this is from the "batch" side of things during optimization.

I only get the option to set these things if I select Custom on the geometric optimization pull down.  Is that 

the place to set the vars to participate in optimization?  

Thanks again for all the help.

jc

[Bruno Postle]

On 21 February 2019 14:10:41 CET, jim cullen wrote:
>
>I can't seem to make it fix the roll and pitch at zero successfully during
>optimization.
>
>I'm setting the fast preview mode to Mosaic plane - is that proper? I ask
>because the python script
>stitch-scanned-images.py which one can find on github constructs a .pto
>that seems to use Panosphere.

Hugin has so many options that you can do this scanned images thing in three completely different ways. I'm wary of prescribing a particular method over another, but you can't mix them. They are:

1. Using very narrow field of view, with roll, pitch, yaw optimisation.
Imagine that you have taken these images using a very long telescope, Hugin will let you stitch them like a 'normal' panorama, as long as you set the field of view to a small number (<1°).
The result won't be perfectly correct, and there will be odd curvatures, but for most purposes you can get away with this.

2. Using the d,e lens shift parameters to move the images around a rectilinear 'canvas'.
These shift parameters are intended to let you work with photos created with a shift lens, or photos where one or more sides have been cropped away (nearly all historical/Victorian/magazine photos are uncentred like this).
So you can stitch scans by pretending that they are all the same photo, each just cropped differently.

3. The 'mosaic' XYZ mode has been added to Hugin specifically for fitting images to a rectilinear plane, so this is what we recommend, but it is a powerful tool that can do lots more than stitching scans, so it is conceptually a bit harder.
The mosaic mode assumes that your camera moves to different 3D locations for reach shot, hence the XYZ positions.
It is possible to conceive of your scans as being taken by a camera from different locations, but with the Z distance (the distance from the camera to the object) never changing, and your 'camera' is always perfectly perpendicular, so pitch and yaw are always zero.

>I'm now setting the first cols of the optimize panel to unchecked and zero
>for yaw and pitch and leaving
>the roll free (checked). The script (edit prior to optimize lets me look)
>seems to have sane vars viz
>Tx Ty and r for each image.

This is correct for method 3.

>I must be blundering some place else as it
>keeps saying Panorama must have positive height.
>I think this is from the "batch" side of things during optimization.

I've have no idea how this happens.

>I only get the option to set these things if I select Custom on the
>geometric optimization pull down. Is that
>the place to set the vars to participate in optimization?

Yes, I would set 'custom' geometric optimisation, and control everything from the Optimiser tab (for methods 2 & 3).

--
Bruno

[T. Modes]

Am Samstag, 23. Februar 2019 09:40:54 UTC+1 schrieb Bruno Postle:

>I only get the option to set these things if I select Custom on the
>geometric optimization pull down.  Is that
>the place to set the vars to participate in optimization?  

Yes, I would set 'custom' geometric optimisation, and control everything from the Optimiser tab (for methods 2 & 3).

For method 2 & 3 there is also an user defined assistant. But I don't know how good it works in this case.

[AKS-Gmail-IMAP]

I can comment on some of this. I am currently using the "method 3” to create “contact sheet” images of 35mm photograph film rolls archived in style “35-7BXW” PrintFile archival negatives preservers. These are clear plastic negatives preserves holding seven rows of six 35mm image negative strips. These scan really well on a desktop flatbed photo scanner in transparency mode, but it takes three scans to do one sheet. Therefore the scans have to be stitched together. Hugin using method 3 does the job. Furthermore, because the negatives might be at radically different exposures, Hugin’s stack handling where the stacks are multiple scans at different exposures allows exposure fusing all the images in the contact sheet to be satisfactory images.

When using this mosaic XYZ mode I always see the “Panorama Tools” "Panorama must have positive height” message when the “edit script before optimizing” check box is checked where the “Continue with these changes” is pressed at the “Edit Panorama Tools Script” form. I would be clueless trying to edit the script. I never see any negative numbers in the script. Hugin does show “-0” in the Z plane parameters when it calculates the parameters. The number is actually a small negative number when viewed in the edit box. The "Panorama must have positive height” message will show even after reseting all parameters to 0. Perhaps this is a bug. I would not know since I am pretty much cook booking my way through this part of Hugin.

By the way, Masks are essential to use in “method 3”.

Regarding engineering drawings, the type and source of which has not been described, I do not see how one could automate the task because each image requires at least one unique mask and possibly four unique masks and also because the image control points are best placed by hand. The time spent removing and correcting falsely placed automatic control points is many times more the manual effort to create the very few required control points. The situation is similar to the fallacy digitizing scanned drawings into computer aided drawings. Incidentally the time spent personally observing each image in the manual method pays off with additional knowledge about the images. That knowledge might explain causes for problems seen in the output.

The type and source of the engineering drawings is not mentioned. I’ve worked in that business for many years and I have tried on many occasions to reassemble plans using every imaginable technique from “xerox art” to Hugin. I cannot recall any time the source images did not have a different distortion in both the x and y directions. The results were always unsatisfactory to some degree, often terrible. I could see x y scale issues with any first generation roll plotter sources and small media copy machines. Images created on full sized flat bed equipment were the best but what company has one of those these days?

Output from a roll plotting or reproducing device is going to have a slight stretch distortion as the media passes over the roll. I would see this in recent plots and also back in the day when running vellums or cloth through a diazo machine. I would foresee difficulties trying to stitch plans back together without being disappointed in the results. Even recently the best results with the least amount of effort and frustration were always using what we called “xerox art”. This is cut and paste using Scotch magic tape with perhaps a bit of pencil or pen touchup followed by a run through a large format copier.

Regards, Allan

> --
> A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
> ---
> You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/7CF8818D-08E1-46CC-B919-320BA64FF7EE%40postle.net.
> For more options, visit https://groups.google.com/d/optout.

[Gunter Königsmann]

Floating-point numbers often add a small rounding error. Maybe the slightly negative number isn't a bug but such a thing...

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/3FF884DC-A3EE-4247-9997-B16A5CEF9DAA%40gmail.com.