Stitching photographs of a large map into a whole map
1,475 views
Skip to first unread message
Peter Cooper
Dec 18, 2016, 4:04:58 AM12/18/16
to hugin and other free panoramic software
I have what seems to me a fairly simple task to perform. I want to stitch together a series of photographs taken from a camera suspended over a large map. They are all taken vertically at the same distance and the map has been carefully moved linearly underneath the camera. I have a number of such maps to process, at as high a quality as I can manage, and cannot afford to incur the costs of professional scanning.
With just a few component photos (up to 4) Microsoft ICE has done the job adequately some of the time, but there is little control over what it does so sometimes I cannot get it to stitch properly. I can use QGIS (mapping software) but it is not optimised for this task. I use Windows 10, and have had occasional forays into Linux.
When I came across Hugin I thought that this could be exactly what I wanted, even though it is more aimed at panoramas, and would be fun to try. I have read the tutorials (including the ones on Stitching flat scanned images, and Stitching murals using mosaic mode), and searched around for others' experiences (I enjoyed especially dinosaurpalaeo, and this one in the forum).
Unfortunately, I have tried quite a number of times to stitch a few photos together and, although I have no problem creating control points, I cannot get the results I would expect. I am not very familiar with all the various photographic terms in Hugin and, as this stitching is only a very small part of my whole project (http://mapping4ops.org/), I cannot afford the time to understand all the details.
I do manual control points because of a particular problem with black and white maps in that any automatic matching finds lots of false matches - one line is like any other line and there is lots of white!
I have long experience of using computers, and can follow instructions, including strange ones like changing each lens to a new one. It is probably something I am doing, but one issue is that the version of Hugin I am using (the latest) is different from that used in the tutorials and some aspects are different. Also there are terms used in it that I cannot understand (which some may think disqualifies me from trying). However, for whatever reason, after over 10 attempts I cannot achieve what I want, and without help I am going to have to give up on Hugin.
As with much open/free software, Hugin seems a tremendous system, and I am grateful to everyone involved for the contributions they have made. It would be a shame if someone like me could not use it simply because of misunderstanding. I use lots of other FOSS systems.
My questions are:
- am I correct in thinking my task is something that is fairly easy to achieve, for someone who understands Hugin?
- is there anyone who could guide me (either in public or in private) to a workflow process that works for me?
Thanks again for great software.
Terry Duell
Dec 18, 2016, 3:57:37 PM12/18/16
to hugi...@googlegroups.com
Hello Peter,
On Sun, 18 Dec 2016 16:56:32 +1100, Peter Cooper
<peterco...@gmail.com> wrote:
[snip]
> My questions are:
>
> -
> *am I correct in thinking my task is something that is fairly easy to
> achieve, for someone who understands Hugin? *
> - *is there anyone who could guide me (either in public or in private)
> to a workflow process that works for me?*
I can try to help, and I suspect others will also offer.
What we need is some clear description of your problem. If that is
difficult, then the best approach would be to provide some of your images
so we can try a stitch and see what these problems are.
I suggest three overlapping images would be sufficient, and if they are
large images it would be advisable to make them available via Dropbox or
similar service which doesn't require the recipient to be a registered
member of the service.
In addition, could you please describe your imaging process in more detail?
For example, how much overlap between images?
How close is the camera to the map, what type of lens (rectilinear or
fisheye) and focal length?
Is the map perfectly flat or does it have small creases at fold lines?
...and, which version of hugin?
Cheers,
--
Regards,
Terry Duell
On Sun, 18 Dec 2016 16:56:32 +1100, Peter Cooper
<peterco...@gmail.com> wrote:
[snip]
> My questions are:
>
> -
> *am I correct in thinking my task is something that is fairly easy to
> achieve, for someone who understands Hugin? *
> - *is there anyone who could guide me (either in public or in private)
> to a workflow process that works for me?*
>
> Thanks again for great software.
>
Yes, and yes.
> Thanks again for great software.
>
I can try to help, and I suspect others will also offer.
What we need is some clear description of your problem. If that is
difficult, then the best approach would be to provide some of your images
so we can try a stitch and see what these problems are.
I suggest three overlapping images would be sufficient, and if they are
large images it would be advisable to make them available via Dropbox or
similar service which doesn't require the recipient to be a registered
member of the service.
In addition, could you please describe your imaging process in more detail?
For example, how much overlap between images?
How close is the camera to the map, what type of lens (rectilinear or
fisheye) and focal length?
Is the map perfectly flat or does it have small creases at fold lines?
...and, which version of hugin?
Cheers,
--
Regards,
Terry Duell
Peter Cooper
Dec 19, 2016, 12:24:26 PM12/19/16
to hugin and other free panoramic software
Thank you for your encouraging responses.This prompted me to thoroughly re-read the manual and tutorials, do further experimentation, and write lots of notes for myself. I have also carefully retaken my photographs of the map, so there is more overlap. I wanted to make sure I could get as far as I could without help.Following the "Stitching flat scanned images" tutorial to the letter (and making notes along the way about aspects I could not follow, or questions I had), and adding in some steps of my own, I have managed to produce a stitched map that I am quite pleased with.
I have put the end product into my DropBox. It is stitched from 20 separate photographs.There are issues with some roads and field boundaries not meeting up, for example in the centre of the map above the name "Fen Drayton". Is there a way I can persuade the stitcher not to take bits of photographs like this, or is there an issue with my control points?Some comments on my process, compared to the tutorial:
- the automatic creation of control points for all images was only partially successful in that the horizontal links were mostly done OK, but
- I had to remove quite a few spurious matches (eg for the same symbols or letters in different places)
- very few vertical links were made so I had to do these by selecting a few images and specifically starting the creation process for each little group
- Setting each image to have a separate lens will be more of a pain when I am trying to stitch more images - is there not an option to do this for all images?
- The average pixel difference was 3.85, and I am not sure how "good" that is
- After the geometric optimisation I did Photometric optimisation with low dynamic range (as the light had changed)
- In stitching I noticed a message "Unable to run Dijkstra optimiser", and I presume this is not essential
Any other suggestions or advice on the process would be very welcome.
By the way my camera is Canon IXUS 80 IS (8MP) , I used a "leaning over tripod" so the lens was 22 cm above the paper, and turned on the camera's macro. I am not a photographer.
Thanks again.
bugbear
Dec 19, 2016, 12:31:28 PM12/19/16
to hugi...@googlegroups.com
Peter Cooper wrote:
> Thank you for your encouraging responses.
>
> This prompted me to thoroughly re-read the manual and tutorials, do further experimentation, and write lots of notes for myself. I have also carefully retaken my photographs of the map, so there is more overlap. I wanted to make sure I could get as far as I could without help.
>
> Following the "Stitching flat scanned images" tutorial to the letter (and making notes along the way about aspects I could not follow, or questions I had), and adding in some steps of my own, I have managed to produce a stitched map that I am quite pleased with.
Could you send your project file (the .pto) to the list?
> Thank you for your encouraging responses.
>
> This prompted me to thoroughly re-read the manual and tutorials, do further experimentation, and write lots of notes for myself. I have also carefully retaken my photographs of the map, so there is more overlap. I wanted to make sure I could get as far as I could without help.
>
> Following the "Stitching flat scanned images" tutorial to the letter (and making notes along the way about aspects I could not follow, or questions I had), and adding in some steps of my own, I have managed to produce a stitched map that I am quite pleased with.
BugBear
Peter Cooper
Dec 19, 2016, 1:11:59 PM12/19/16
to hugin and other free panoramic software
I should have added that I did a little Hugin editing (adding more control points) after I generated the Tiff file in my DropBox.
On Monday, 19 December 2016 17:52:44 UTC, Peter Cooper wrote:
On Monday, 19 December 2016 17:52:44 UTC, Peter Cooper wrote:
pto file attached.Thanks
Roger Broadie
Dec 19, 2016, 7:24:09 PM12/19/16
to hugi...@googlegroups.com
Thanks, Peter, for tabling an early version of your stitch and the pto file. It's so helpful to have something concrete to work with. However, the pto file won't load without
images, and I don't think you have provided the originals. Never mind, it helps to concentrate the mind if one uses blank dummies of the correct size, and since the
optimiser works only on the control points the missing image data does not affect its operation, though of course functions like fine-tuning can't be used if the data on
which they operate is not there.
However, I find that running the optimiser (a) changes the optimiser values and (b) gives a large error - an average error at optimum resolution of 40 and a maximum
of 2049. All the values of Z, except for the anchor value of 0 for the first image have changed. They are now shown as -1, though selecting them in the Optimiser tab
shows them to be slightly variable, at around -0.96. That means that the remapped images are now all tiny, except for the anchor image, which therefore cannot
possibly be stitched to the remainder. Something has clearly gone wrong, and I suspect the main cause, though not the only one, is that some control points are
wrong.
Now X and Y define the different camera positions in a plane parallel to the plane of the original (which makes them very suitable for this sort of operation) and Z
defines the position of the camera in the direction normal to that plane and with respect to the position of the anchor image (which conveniently can be set at 0, though
it doesn't have to be). While your set-up may not be completely accurate, as a first approximation we can certainly take the values of Z to be the same for all the image.
Thus undoing the first optimisation and then setting all the Z values at 0 and rendering them all non-optimisable should give a better alignment. Actually, the error
figures go up to an average of 49, probably because the non-anchor images are now bigger and the errors between them magnified. But at least all the images are
now present in roughly the right position and of roughly the right size.
The first step is then to clean the control points (in a Windows environment right-click on any image filename in say the Optimiser tab, right-click on 'Lens' and then
select 'Clean control points') and then reoptimise. That reduces the average error to 18. Then I would suggest successively adding into the optimisation:
- roll, since you may not quite move the original map parallel to itself
- Z, since you may have slight variation in the height of the camera
- y and p, since the camera may not be pointing quite vertically downwards
- the lens characteristics, since you are using a camera that we can expect to have perhaps 2% barrel distortion.
In the lens characteristics I do not include the field of view, which seems pretty arbitrary for a photomosaic like this. And, even more important, the fov should not be
allowed to vary per image, since the effect it has in changing the scale of the individual images is already dealt with by allowing Z to vary and allowing both
parameters to be optimised has odd effects. There seems no reason why there shouldn't be only a single lens, optimised for b principally, but for the full set of
parameters a-e for the best results.
Then there are possibilities I can't investigate, like fine tuning.
Personally, I would anchor the most central image, which seems to be image 7, at X=Y=Z=0, but I'm not sure it actually helps much.
Putting all this together gives the attached pto file and screen grab of the optimiser tab. After another round of cleaning control points and then reoptimising the
average/maximum error distances at optimum resolution are 1.3/3.8.
Even so, it looks as though some extra control points might be helpful in the area that is mostly of mostly wording at the bottom of the map. And I would hope to
achieve a straighter and more rectangular frame around the map than is shown in your stitch. You may have enough control points to achieve that, but otherwise it can
be useful to define horizontal and vertical control points. I find putting them on the thin line inside the broader border works well.
I hope this helps. It may be you are mostly interested in the principle of stitching these maps, but otherwise please allow me to ask if you are aware that this map is
available on the internet, e.g. here: http://maps.nls.uk/view/101571550. That may be an easier source for the constituent images unless you have some particular
reason not to want to use it.
Roger Broadie
========================================
Message Received: Dec 19 2016, 06:12 PM
From: "Peter Cooper"
To: "hugin and other free panoramic software"
Cc:
Subject: [hugin-ptx] Re: Stitching photographs of a large map into a whole map
--
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/82557e1e-4ae9-46a8-a0bf-5087f762a156%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
images, and I don't think you have provided the originals. Never mind, it helps to concentrate the mind if one uses blank dummies of the correct size, and since the
optimiser works only on the control points the missing image data does not affect its operation, though of course functions like fine-tuning can't be used if the data on
which they operate is not there.
However, I find that running the optimiser (a) changes the optimiser values and (b) gives a large error - an average error at optimum resolution of 40 and a maximum
of 2049. All the values of Z, except for the anchor value of 0 for the first image have changed. They are now shown as -1, though selecting them in the Optimiser tab
shows them to be slightly variable, at around -0.96. That means that the remapped images are now all tiny, except for the anchor image, which therefore cannot
possibly be stitched to the remainder. Something has clearly gone wrong, and I suspect the main cause, though not the only one, is that some control points are
wrong.
Now X and Y define the different camera positions in a plane parallel to the plane of the original (which makes them very suitable for this sort of operation) and Z
defines the position of the camera in the direction normal to that plane and with respect to the position of the anchor image (which conveniently can be set at 0, though
it doesn't have to be). While your set-up may not be completely accurate, as a first approximation we can certainly take the values of Z to be the same for all the image.
Thus undoing the first optimisation and then setting all the Z values at 0 and rendering them all non-optimisable should give a better alignment. Actually, the error
figures go up to an average of 49, probably because the non-anchor images are now bigger and the errors between them magnified. But at least all the images are
now present in roughly the right position and of roughly the right size.
The first step is then to clean the control points (in a Windows environment right-click on any image filename in say the Optimiser tab, right-click on 'Lens' and then
select 'Clean control points') and then reoptimise. That reduces the average error to 18. Then I would suggest successively adding into the optimisation:
- roll, since you may not quite move the original map parallel to itself
- Z, since you may have slight variation in the height of the camera
- y and p, since the camera may not be pointing quite vertically downwards
- the lens characteristics, since you are using a camera that we can expect to have perhaps 2% barrel distortion.
In the lens characteristics I do not include the field of view, which seems pretty arbitrary for a photomosaic like this. And, even more important, the fov should not be
allowed to vary per image, since the effect it has in changing the scale of the individual images is already dealt with by allowing Z to vary and allowing both
parameters to be optimised has odd effects. There seems no reason why there shouldn't be only a single lens, optimised for b principally, but for the full set of
parameters a-e for the best results.
Then there are possibilities I can't investigate, like fine tuning.
Personally, I would anchor the most central image, which seems to be image 7, at X=Y=Z=0, but I'm not sure it actually helps much.
Putting all this together gives the attached pto file and screen grab of the optimiser tab. After another round of cleaning control points and then reoptimising the
average/maximum error distances at optimum resolution are 1.3/3.8.
Even so, it looks as though some extra control points might be helpful in the area that is mostly of mostly wording at the bottom of the map. And I would hope to
achieve a straighter and more rectangular frame around the map than is shown in your stitch. You may have enough control points to achieve that, but otherwise it can
be useful to define horizontal and vertical control points. I find putting them on the thin line inside the broader border works well.
I hope this helps. It may be you are mostly interested in the principle of stitching these maps, but otherwise please allow me to ask if you are aware that this map is
available on the internet, e.g. here: http://maps.nls.uk/view/101571550. That may be an easier source for the constituent images unless you have some particular
reason not to want to use it.
Roger Broadie
========================================
Message Received: Dec 19 2016, 06:12 PM
From: "Peter Cooper"
To: "hugin and other free panoramic software"
Cc:
Subject: [hugin-ptx] Re: Stitching photographs of a large map into a whole map
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/82557e1e-4ae9-46a8-a0bf-5087f762a156%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Peter Cooper
Dec 19, 2016, 11:05:24 PM12/19/16
to hugin and other free panoramic software
Thanks for the advice. I have had another go at my map, and attach the full project, with the stitched result, on DropBox.
Further to what I did before I have:
- made image 17 the anchor (as Holywell is the village I am most interested in)
- set all the Z values at 0 and render them all non-optimisable
- cleaned control points (but see below)
- examined the control point table for the worst distances and deleted or fine-tuned them
- added some control points for horizontal and vertical lines
- optimised first on X & Y, then in stages on roll, then Z, then y & p, then b
- I had a lot of trouble when I cleaned control points, as the process removed all control points from several pairs that should have remained (eg images 0, 5 and 10)
- I guess this is tied in with the fact that the initial create control points did not create any points for those pairs either
- I therefore resorted to adding back control points after I had cleaned them
- I removed some of the control points for horizontal and vertical lines because in the original the lines are not perfectly straight, and had high distances
- I had not appreciated the need to treat optimisation as a step by step process - now I do
- I do not understand why the final tiff has a black mark down the bottom right of the image - this does not appear in the preview in hugin
- Does "There seems no reason why there shouldn't be only a single lens, optimised for b principally, but for the full set of parameters a-e for the best results" mean that I should not have a different "lens" for each image?
Now I know I will be able to stitch, I want to go back to experimenting with getting better images in the first place. I have a "leaning tripod" setup that seems to work OK, I presume that saving in RAW format would be better than JPG, but does anyone have any other suggestions?
Thanks
bugbear
Dec 20, 2016, 5:14:04 AM12/20/16
to hugi...@googlegroups.com
Peter Cooper wrote:
> * I had not appreciated the need to treat optimisation as a step by step process - now I do
This is only true for mosaic stitches - a spherical "pano head" stitch,
where only YPR are optimised will pretty much work "in one hit".
A full YPR/XYZ stitch must be done very carefully, and in stages,
because some of the parameters have "similar" effects.
In particular, a small mosaic could be feasibly stitched (with some errors) in YPR mode.
One tip I will offer - save your pto file VERY regularly; you never know when a new
optimisation will become degenerate!
When I did my VERY large mosaic (173 image) I started by adding images one (or 2) at a
time, and optimising. As the mosaic grew, I was forced to set existing images parameters
to be "fixed" because the optimsation time became very high (60 minutes, at the end).
I would add a row of images, 1 at a time, then allow the previous row to be optimised against
the new row, then allow the whole image to be optimised, then start on the next row.
I was also setting X-Y manually for each added image (based on arithmetic interpolation "guessing")
so that my desired optimisation minimum was nearby in the search space.
(because my map was large, and some of my images had poor focus, my stitching took
around 2 weeks of intermittent work!)
BugBear
> * I had not appreciated the need to treat optimisation as a step by step process - now I do
This is only true for mosaic stitches - a spherical "pano head" stitch,
where only YPR are optimised will pretty much work "in one hit".
A full YPR/XYZ stitch must be done very carefully, and in stages,
because some of the parameters have "similar" effects.
In particular, a small mosaic could be feasibly stitched (with some errors) in YPR mode.
One tip I will offer - save your pto file VERY regularly; you never know when a new
optimisation will become degenerate!
When I did my VERY large mosaic (173 image) I started by adding images one (or 2) at a
time, and optimising. As the mosaic grew, I was forced to set existing images parameters
to be "fixed" because the optimsation time became very high (60 minutes, at the end).
I would add a row of images, 1 at a time, then allow the previous row to be optimised against
the new row, then allow the whole image to be optimised, then start on the next row.
I was also setting X-Y manually for each added image (based on arithmetic interpolation "guessing")
so that my desired optimisation minimum was nearby in the search space.
(because my map was large, and some of my images had poor focus, my stitching took
around 2 weeks of intermittent work!)
BugBear
Peter Cooper
Dec 20, 2016, 6:34:09 AM12/20/16
to hugin and other free panoramic software
Thanks again. I have had a go at another map to see how the process can work when you know what you are doing! The input and output files are again in my DropBox.
It went well and the end resulting average was less than 1 pixel. The map itself is different from the first one I did (it is adjacent, and I had fewer images) but I had a similar problem with some pairs (adjacent vertically) not being given any control points by the automatic creation process, and getting all control points removed by the cleaning control points process. I wonder if this is a feature of stitching maps or a bug?
Incidentally this map had images taken without the camera's macro being on but I do not see much difference in the end product from my first map, which had the macro on.
I cannot find out why my first stitched map had a black area at bottom right, but that does correspond to the part of the map that is in image 4 and not other images.
Roger Broadie
Dec 22, 2016, 2:26:13 PM12/22/16
to hugi...@googlegroups.com
Peter, You seem to have created a very good stitch and I don’t think I can make any suggestions that will help you improve it.
What I would mention, more for another time than because it will make any noticeable difference here, is that, if you are adding h and v control points to ensure that
you have a rectangular, correctly oriented frame for the stitch, you should also allow the values of y, p and r for the anchor image (17 in your case) to be optimised.
Otherwise the perspective of the anchor image may not match that of the stitch as a whole, although in this example the discrepancy is probably dissipated amongst
the other images.
On the image 4 problem, about which you wrote again today, I ran your b version of the project file on the images you supplied and did not meet the strange darkening
of image 4 you showed. I also replaced the control points with a complete new set. The result stitched to give a panorama equivalent to yours, but again without the
extreme darkening of image 4. Why it happened, or what can be done to avoid it, I do not know. I do wonder if possibly your stitch comes from an earlier version of the
project file.
Progressively extending the scope of the optimisation can be used to add images into the optimisation in the way Bugbear suggested, and I have been forced to do
that. But if possible I include the full set of images and add classes of parameter cumulatively. My reasons for doing so are:
1. It can be helpful to restrict what the optimiser is trying to do at one time. If too much is asked of it, it may be overwhelmed (forgive me for being a bit anthropomorphic
about this).
2. One can stop as soon as a good stitch is achieved and thus achieve the stitch with fewer parameters needing to be optimised. The more parameters you include in
the optimisation, the more control points you need (I think).
3. At each stage I try to refine and extend the set of control points. My objective at this stage is as much to achieve a robust and comprehensive set of control points as
to do the stitch itself. Once one has a good set of control points I find that one can usually reset all the optimised parameters to 0 (but leaving them optimisable) and
then optimise the whole thing in one big bang. The result should be as good as, or possibly even better than, the original optimisation/stitch.
I think the need to create control points oneself is a normal, if boring, part of stitching photos of old maps, where control-point detectors can be thrown by the splodgy
nature of the features in the images. But there is a great resource to help solve this problem, as you may well know. Once the images are approximately positioned,
by any means available, extra control points can be added by the ‘Create control points here’ feature that can be invoked in the Preview tab of the Fast Preview
panorama window. See here: http://hugin.sourceforge.net/tutorials/hugin-2015.0.0/en.shtml
You asked why I preferred to use a single lens. I am not at all clear why Hugin suggests here that each image should have its own lens. If images do not all have the
same dimensions, separate lenses need to be used. They may be required in other circumstances, too. And if the settings of the lens are changed, the purist will say
that each set of settings should have its own set of lens parameters. But here it seemed to me that your set-up was sufficiently fixed to mean that any variations that
were present from features like automatic focussing were likely to be masked by variations in other factors, such as the exact positioning of the control points. In those
circumstances it seemed to me that it was closer to reality to assume that only a single lens was involved. Then, even with the full set of parameters a to e, only 5 were
needed. I notice that you have allowed b to vary between the different lenses, one for each image. That requires 20 parameters and they vary between roughly -0.016
and -0.020. I suspect that this range is more than is needed specifically to compensate for differences between the lens distortions for the different images and has to
do with the fact that the more you give the optimiser to play with the better result you get (provided there are enough control points, of course). In other words
variations in b are used to adjust the relationships between the images.
Roger Broadie
========================================
Message Received: Dec 20 2016, 11:34 AM
From: "Peter Cooper"
To: "hugin and other free panoramic software"
Cc:
Subject: [hugin-ptx] Re: Stitching photographs of a large map into a whole map
To: "hugin and other free panoramic software"
Cc:
Subject: [hugin-ptx] Re: Stitching photographs of a large map into a whole map
--
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/96989e65-ecd6-4e8a-9d54-9134b23f38fc%40googlegroups.com.
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.
Abrimaal
Dec 22, 2016, 8:26:30 PM12/22/16
to hugin and other free panoramic software
I see that you are not the only one long time user who has problems with maps. I have never managed to stitch any map in Hugin, while I stitch and straighten many photos every day. Even when the control points are placed correctly, the projection distorts every map. Even when the projection is corrected by vertical and horizontal lines, there are many other improvements (dedicated for photos) that make the final image erroneus. My plea to anybody who understands the methods of stitching flat documents and the GUI developer is to add "Flat document mode for beginners" to the main menu. Preparing Hugin for maps really requires a lot of work that could be accessible from the menu as a preset.
Scanned paper maps are not computer graphics, they are always distorted by folded paper, scanner optical imperfection and photometric corrections performed by the scanning software. Some statistics is required, the similarity threshold optimized for high contrast and exposure correction not as sensitive as in photography. I can participate in the process by testing.
Scanned paper maps are not computer graphics, they are always distorted by folded paper, scanner optical imperfection and photometric corrections performed by the scanning software. Some statistics is required, the similarity threshold optimized for high contrast and exposure correction not as sensitive as in photography. I can participate in the process by testing.
Reply all
Reply to author
Forward
0 new messages