Stitching perfectly flat pictures (maps) together

[Olivier Croquette]

Hi all,

I have an usual task at hand, which is to stitch together small maps
into a bigger global map. There are many differences compared to
stitching photographs :
1. the source pictures (24) show no distortion
2. the orientation is not always the same (sometimes north is up,
sometimes it's to the right or the left)
3. the resulting picture shall not be distorted or projected
4. the pictures are of different sizes
5. the overlap is really narrow 5% or less, e.g. only the borders
match together
6. I would like to have the results tiled

Due to the small overlap, I have to create the control points
manually, I am OK with that, but I was wondering if Hugin can cope
with the other requirements. I guess for the 1. and 3., it's just a
matter of finding the rights parameters, but what are they ?

The background of requirement 6. is that the resulting map or
corresponding file will be too big, the idea is to tile it again in
regular pieces after the stitching.

Do you think Hugin can help me in this task ?

Thanks for your hints

Best regards

Olivier

[Andreas Metzler]

Olivier Croquette <ocroq...@free.fr> wrote:
> Hi all,

> I have an usual task at hand, which is to stitch together small maps
> into a bigger global map.

[...]
Have you already checked out the tutorial by Bruno Postle?
http://hugin.sourceforge.net/tutorials/scans/

cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[kfj]

On 4 Dez., 16:52, Olivier Croquette <ocroque...@free.fr> wrote:
> Hi all,
>
> I have an usual task at hand, which is to stitch together small maps
> into a bigger global map.

> ...

What sort of data do you have? Are they scans, or photographs? Or
still on paper, or images created by a GIS?
I've done my bit stitching maps, and I'm quite sure you can do it with
hugin, as long as you have some control points for every overlap.

with regards
Kay

[Tduell]

On Dec 6, 12:19 am, kfj <_...@yahoo.com> wrote:

> I've done my bit stitching maps, and I'm quite sure you can do it with
> hugin, as long as you have some control points for every overlap.

It can be done, as per the scans tutorial.
I have just run an experiment to test if there is anything
fundamentally different about maps.
I scanned a 1:100000 map (600mm EW, 710mm NS) at 300dpi.
Using an A4 scanner I needed 3 rows of three, which gave good overlap
NS but not much EW.
I found that auto control point generators are pretty useless, as maps
have lots of common features (grid lines, symbols etc), so they find
too many spurious points. Select your control points manually, giving
a good spread. I used 7 points on each overlap.
I also found I got a better results by first stitching each set of row
images and saving, then stitching the rows. It should all work OK as
a single project.

Cheers,
Terry

[kfj]

On 6 Dez., 02:40, Tduell <tdu...@iinet.net.au> wrote:

> I found that auto control point generators are pretty useless, as maps
> have lots of common features (grid lines, symbols etc), so they find
> too many spurious points.

Sometimes it helps running the CPGs with higher resolution (--maxdim
for autopano-sift-c) (might take a while with a high-res scan ;-) Any
CPs that don't match are easily removed once the images are aligned by
the ones that do. In a pickle (like, when the scans are just too large
to handle) one can just make ptos to extract the strips that do
overlap, CPG them with maximum scale and remap the CPs to the original
images, but it's probably quicker then to manually set the CPs
straight away.

If there are grid lines on the maps, they are excellent for putting
line control points on them. Also, it's wise to scan so that the edges
of the map (which often has boundary lines as well) show up on the
scan - if it's a proper topographical map, the margin would also have
the data to later easily georeference the map to feed it into a GIS.
line control points should help with getting the X, Y and shear
parameters spot on right, which is a necessity if the extent of the
total area goes beyond a few pages. I did several projects stitching
sets of photographs of maps, taken freehand in rule-of-thumb mosaic
fashion. It took a fair bit of fiddling getting it all to come out
nicely, and line control points along grid lines were the factor which
made the final difference.

Having mentioned GISs, they are a certainly worth taking a look at for
the task at hand; they offer facilites for overlapping (georeferenced)
image data and may be more flexible dealing with map data than a
panorama stitcher, which would merely produce images without being
aware of the content. I'd recommend Quantum GIS - it's very powerful
and takes a while to figure out, but it's well-documented and free:

http://qgis.org/

My workflow is like this:
digitize the maps and put back together each individual map with
hugin, thereby dealing with distortions intoduced by the digitization
georefernce the maps with QGIS and hold them in QGIS for synopsis
take it from there (like, get tiles out)

with regards
Kay

[Olivier Croquette]

Thanks for the numerous answers. I didn't know Bruno's tutorial yet,
so I tried to follow it. I came a bit further, but it actually didn't
solve this unusual problem. To make it clear what it is, I have put
some sample maps online.

They come from the french cadastre. The limits between the different
areas within a town (AI and AK in the sample) are typically
geographical features (river, road...) or property borders. There is
no overlapping between the maps of the different areas, only common
borders.

The goal is too load this data in JOSM, the editor for OpenStreetMap.
I can already load the single sheets in JOSM, and I also geo-
referenced them one by one. But the georeferencing is not perfect, and
I have discrepancies of several meters at many borders.
My idea is now to stitch first the single maps in a bigger one, that I
then georeference, leading to full consistency within the big map
(e.g. the town).

Here are 2 sheets (among the 24) :
http://ocroquette.fr/a/hugin/

I don't think stitching the pictures will work, because of :

- the size : for this town, there are 24 sheets, about 3000x3000, e.g.
the final map will have at least 200 Megapixels
- transparency : original files are transparent PNG, and the
overlapping areas do not contain information that is blend-able
(typically, a piece of map of a sheet overlaps with metadata or border
lines of another sheet), so I would need support for transparency as
input and output

So trying to stitch them as a panorama is the bad approach. I am now
thinking about just using the GUI to create control points and the
PTOptimizer to optimize the georeferencing. Hugin makes it easy with
the "Edit script before optimizing" button in the Optimize panel. I
have copied the script to a file, and I ran PTOptimizer on it. While
the input format is well documented (http://wiki.panotools.org/
PTOptimizer), the output is not.

Sample lines :
o f0 r0 p0 y0 v10 a0.000000 b0.000000 c0.000000 g0.000000 t0.000000
d0.000000 e0.000000 u10 -buf
o f0 r67.3424 p0 y0 v13.6204 a0.000000 b0.000000 c0.000000 g0.000000
t0.000000 TrX0.066214 TrY-0.033346 TrZ-0.265726 d0.000000 e0.000000
u10 +buf
C i0 c0 x1704.48 y532.368 X1704.25 Y532.207 D0.561154 Dx0.459291
Dy0.322407
C i1 c0 x1704.02 y532.046 X1704.25 Y532.207 D0.561154 Dx0.459291
Dy0.322407

I will now dive into this and see how I can integrate it in my
existing OSM workflow. If anyone has some documentation about the
output of PTOptimizer, I would be glad to see it and add it to the
Wiki.

Thanks all for your help !

Best regards

Olivier

[Carl von Einem]

Salut Olivier,

are you sure you have a license to use these maps in JOSM? As an
OpenStreetMap Contributor you are only allowed to use data you are
allowed to use. See
<http://www.osmfoundation.org/wiki/License/Contributor_Terms_Summary>.

Carl

Olivier Croquette schrieb am 06.12.10 11:29:

[Olivier Croquette]

On Dec 6, 12:01 pm, Carl von Einem <c...@einem.net> wrote:
> Salut Olivier,
>
> are you sure you have a license to use these maps in JOSM? As an
> OpenStreetMap Contributor you are only allowed to use data you are
> allowed to use. See
> <http://www.osmfoundation.org/wiki/License/Contributor_Terms_Summary>.

Hi Carl,

thanks for your concern, but yes, it's perfectly legal to use them.

[Olivier Croquette]

On Dec 6, 11:29 am, Olivier Croquette <ocroque...@free.fr> wrote:
> So trying to stitch them as a panorama is the bad approach. I am now
> thinking about just using the GUI to create control points and the
> PTOptimizer to optimize the georeferencing. Hugin makes it easy with
> the "Edit script before optimizing" button in the Optimize panel. I
> have copied the script to a file, and I ran PTOptimizer on it. While
> the input format is well documented (http://wiki.panotools.org/
> PTOptimizer), the output is not.

After having looked at some samples and the code, I still have some
difficulties with the "o" lines :
o f0 r-0.764814 p0 y0 v13.6204 a0.000000 b0.000000 c0.000000 g0.000000
t0.000000 TrX0.172524 TrY-0.000729 TrZ-0.269043 d0.000000 e0.000000
u10 +buf -buf

Any idea in what unit the Tr parameters are ?
About TrZ, I guess it can be used to retrieve the scaling factor for
this picture, but how ?

Thanks for any hint !

Best regards

Olivier

[voschix]

Olivier,

as I am also starting to do some work with OSM, I got interested and
stitched your two samples. I had no problems, at least with the two
sample maps you provided. I think the quality of the result is
sufficient for OSmapping. Have look:
http://picasaweb.google.com/voschix/DesktopFoto?authkey=Gv1sRgCNXI35bH4LStLQ&feat=directlink

What I did:
- Loaded both images
- inserted manually four control points along the border
- Optimised for: roll, X, Y
- Stitched with remapped images
- Loaded both images in GIMP, cut out a piece from one map, moved them
manually, and merged them

Regards from Italy

Volker

[Bernard Lang]

Hi,

I too am interested in putting together different takes of a flat
surface carrying an image : painted wall, frescoes, or even possibly a
building front far enough that parallax does not matter too much
regarding small features. Scans would actually be the simplest case.

I know of the scans tutorial. But it seems to assume that it is the
same as photographs of flat surfaces, with the camera directed
perpendicular to the surface, and at constant distance from the
surface.

I want something different : to assemble images of a flat surface,
actually taken with a camera, but from different places and with
different orientations of the camera and different distances from the
surface. As far as I know (but I am not an expert) this uses different
algorithmics (projective geometry) to put the various images together,
than that used for stitching spherical images all taken fron a single
point. I doubt that using the standard Hugin code, as suggested in
the tutorial, would do the job, though most features of Hugin would
still be needed.

Can you comment or help me with proper pointers ?

Bernard

* Andreas Metzler <amet...@downhill.at.eu.org>, le 04-12-10, a �crit:

> --
> You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
> A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugi...@googlegroups.com
> To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/hugin-ptx

--
Apr�s la bulle Internet, la bulle financi�re ...
Et bient�t la bulle des brevets
http://www.strategie.gouv.fr/revue/IMG/pdf/article_HS7RL2.pdf
http://www.huffingtonpost.com/brian-kahin/the-patent-bubble_b_129232.html
la gestion des catastrophes comme principe de gouvernement

Bernar...@datcha.net ,_ /\o \o/ gsm +33 6 6206 1693
http://www.datcha.net/ ^^^^^^^^^^^^^^^^^ tel +33 1 3056 1693
Je n'exprime que mon opinion - I express only my opinion
CAGED BEHIND WINDOWS or FREE WITH LINUX

[kfj]

On 7 Dez., 10:20, Bernard Lang <bea...@datcha.net> wrote:
> Hi,
>
> I too am interested in putting together different takes of a flat
> surface carrying an image : painted wall, frescoes, or even possibly a
> building front far enough that parallax does not matter too much
> regarding small features. Scans would actually be the simplest case.

...

> Can you comment or help me with proper pointers ?

Are you aware of the mosaic mode tutorials

http://hugin.sourceforge.net/tutorials/Mosaic-mode/en.shtml

and

http://panospace.wordpress.com/2010/09/19/linear-panoramas-mosaic-tutorial/

with regards
Kay

[kfj]

On 6 Dez., 11:29, Olivier Croquette <ocroque...@free.fr> wrote:
> Thanks for the numerous answers. I didn't know Bruno's tutorial yet,
> so I tried to follow it. I came a bit further, but it actually didn't
> solve this unusual problem. To make it clear what it is, I have put
> some sample maps online.

Thanks for sharing. I had a look at your data. One thing straight
away: you have Z-values. You don't want them, since the scale of all
the images is the same, and Z values refer to the distance from the
mosaic plane. Just set Z to zero. The only things you need to optimize
are roll, X and Y. With this type of content, you will have to set the
control points manually, but if the drawings are precise, you won't
need to many. If the drawings were perfect, three would be perfectly
enough.

Stitching this, with the input images' projection and the panorama
projection set to rectilinear, should give you a result where the
input images aren't distorted at all, just nudged into place. You will
have to use masking, though, to remove parts of the black background
and the image boundary lines, because the stitcher may put them into
the result rather than the geographic content in other images that
happens to be in the same 'place'.

Finally, I'd like to ask you how sure you are that the errors of
'several metres' you've observed after georeferncing the data with
JOSM might not be in the source material? I suppose these are
handdrawn maps scanned in; a few metres are easily explainable by
artifacts introduced somewhere along the line - think of it:
surveying, projecting, drawing, ageing of the maps, warping of the
paper due to humidity fluctuations, scanning shear... - and finally,
human error. All introduce errors, which may well end up amounting to
a few metres. Keep in mind that the stitching process is another
source of errors. To use the data as source for OSM, I think you'd be
well advised not to stitch the maps with hugin, but to georeference
the individual sheets as best as you can, be it in JOSM or QGIS.

with regards
Kay

[Olivier Croquette]

On Dec 7, 9:59 am, voschix <vosc...@gmail.com> wrote:
> as I am also starting to do some work with OSM, I got interested and
> stitched your two samples. I had no problems, at least with the two
> sample maps you provided. I think the quality of the result is

> sufficient for OSmapping. Have look:http://picasaweb.google.com/voschix/DesktopFoto?authkey=Gv1sRgCNXI35b...

Hi Volker !

Thanks for your help. Stitching 2 pieces is indeed not a problem, as I
mentioned earlier the problem is to stitch 24 of them together with
the required quality. The 2 sample files (and resulting picture) don't
have the necessary quality to read the names of the roads. The
resolution needs to be by factors higher, plus there are 12 times more
input pictures, so the size of the final picture is not manageable by
home computers.
To solve this, Hugin would have output tiles of the big picture
instead of a single file, without loading the whole in memory. I could
imagine this requires quite some design changes.

Additionally, this step :

> - Loaded both images in GIMP, cut out a piece from one map, moved them
> manually, and merged them

is not doable on a large scale. This process has to be repeated for
lots and lots of pieces and towns.
Here I see 2 solutions :
- more options for the blending : for instance, in this case,
dst=min(src1, src2) for each color channel would do the trick
- support of transparency in both input and output (like I said,
original PNG's are not black on white, but black on transparent)

[Olivier Croquette]

On Dec 7, 11:27 am, kfj <_...@yahoo.com> wrote:
> Thanks for sharing. I had a look at your data. One thing straight
> away: you have Z-values. You don't want them, since the scale of all
> the images is the same, and Z values refer to the distance from the
> mosaic plane. Just set Z to zero.

Actually the scale strongly varies among the 24 pieces (maybe not in
the sample I provided though), so I have Z factors. One of my problems
is to convert this Z factor into a scaling factor (see the message
about the transX/Y/Z parameters).

> Stitching this, with the input images' projection and the panorama
> projection set to rectilinear, should give you a result where the
> input images aren't distorted at all, just nudged into place.

Yes, it works, but the process doesn't scale (because of the memory
and the required manual steps).

> Finally, I'd like to ask you how sure you are that the errors of
> 'several metres' you've observed after georeferncing the data with
> JOSM might not be in the source material?

The cadastre is reference for the property limits, so it's very
accurate. I could verify that myself by stitching myself a few
samples. They fit very well.

> To use the data as source for OSM, I think you'd be
> well advised not to stitch the maps with hugin, but to georeference
> the individual sheets as best as you can, be it in JOSM or QGIS.

That was actually my first approach, but since I don't have precise
sources for the georefencing, it's not accurate enough. That's the
reason why I am trying to use the internal consistency of the pieces
between each other.

[Bernard Lang]

> Are you aware of the mosaic mode tutorials

No, I was not. I have not been using Hugin for a few years. Too busy.

I looked at the tutorials at the time, but I do not recall that this
one existed. Is it a recent development ?

I guess most of the hugin machinery is common, but flat mosaic
stiching uses a different kernel algorithm than spheric stiching. It
is a different kind of geometric problem. Isn't that correct ?

Anyway, thanks a lot for the pointers. I have plenty of frescoes and
murals to stitch.

The next step is dealing with angles in the wall, or with curving wall
(cylinders). I know algorithms have been developed for that for the
purpose of scanning books without flattening the pages. Curvature can
be inferred from edges (or straight lines in the picture) and from
lighting variations, I think.

Bien cordialement

Bernard

* kfj <_k...@yahoo.com>, le 07-12-10, a �crit:

[kfj]

On 7 Dez., 13:16, Bernard Lang <bea...@datcha.net> wrote:
> > Are you aware of the mosaic mode tutorials
>
> No, I was not.  I have not been using Hugin for a few years.  Too busy.

A few years! Do have a look at arecent version, you'll be amazed by
all the new stuff.

> I looked at the tutorials at the time, but I do not recall that this
> one existed. Is it a recent development ?

Yes. mosaic mode is quite new. It actually implements dealing with
varying camera positions and is overall a very helpful addition,
particularly for the 'mural' or 'mosaic' type of job where the object
is planar. But this is how far it goes; dealing with non-planar object
surfaces isn't there yet and borders on 3D scene reconstruction -
personally I feel that this should be left to specialized tools, but
there has been some discussion on the topic here recently, see for
example

http://groups.google.com/group/hugin-ptx/browse_thread/thread/e8c80e16ada6ebfc#

with regards
Kay

[kfj]

Slowly I start seeing where this goes. If I figure rightly, OSM has
gained permission to use the french cadastre data under certain
conditions. So this is a mass data job! I thought you might just want
to do some OSMing maybe on your own home town, but this seems to be a
major project and large quantities of data, like the older Ordonance
Survey maps in Britain. Big thumbs up to the french authorities for
letting you use the data. It looks like there has been a great effort
done on the data already, with hundreds of thousands of individual
maps already vectorised. Is that so? And how did they do it? This is
the information I'm refering to (sorry, my french is a bit rusty, so
I'm not 100% certain if I interpret this correctly):

http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre

On 7 Dez., 12:03, Olivier Croquette <ocroque...@free.fr> wrote:

> Actually the scale strongly varies among the 24 pieces (maybe not in
> the sample I provided though), so I have Z factors. One of my problems
> is to convert this Z factor into a scaling factor (see the message
> about the transX/Y/Z parameters).

The data being from an official source, hey, even the cadastre, I
reckon their scales are correct. Like the images you posted are
1:2000. I think it best to bring them all to a uniform scale before
putting them into hugin - they are all supposed to end up at the same
scale anyway. The smaller the number of parameters you have to deal
with, the better - and scaling can be done very accurately with other
tools. I would like to give you a good answer about how to convert a
scale into a Z parameter, but the connection is non-obvious. It is
certainly not as straightforward as linear distances along the optical
axis. I'll try and find it out, though.

> > Stitching this, with the input images' projection and the panorama
> > projection set to rectilinear, should give you a result where the
> > input images aren't distorted at all, just nudged into place.
>
> Yes, it works, but the process doesn't scale (because of the memory
> and the required manual steps).

Now I'm not sure if I understand where this is going. My understanding
of OSM is that the project's aim is to create a vector map of the
earth. Vectorization is done piecemeal, so I don't see why you need
very large raster maps. Hugin is well capable of dealing with large
images (I'm not sure what the actual limit is, but I suspect it's
beyond anyone's memory), but you wouldn't want to vectorize from a
gigapixel map. Why first create one and then chop it into tiles if you
can create a set of maps each of resonable size (like some 100 MBs)
and use those as backdrop for vectorisation?

> The cadastre is reference for the property limits, so it's very
> accurate. I could verify that myself by stitching myself a few
> samples. They fit very well.

Okay, granted. Just keep in mind the error sources. I don't know how
accurately you can georefernce with JOSM, since I'm a QGIS user...

> > To use the data as source for OSM, I think you'd be
> > well advised not to stitch the maps with hugin, but to georeference
> > the individual sheets as best as you can, be it in JOSM or QGIS.
>
> That was actually my first approach, but since I don't have precise
> sources for the georefencing, it's not accurate enough. That's the
> reason why I am trying to use the internal consistency of the pieces
> between each other.

The data look to me as if they had precise grid references. I'd assume
it doesn't get better than that, please correct me if I'm wrong. If
you know the projection, the grid crossing points that are marked on
the map should be perfect for georeferencing the sheets. Are you sure
you are using the proper projection for the map data? What is the
projection, by the way?

And - do have a look at QGIS: with QGIS georeferencing raster data in
about any projection is simple. All you need is the projection and a
couple of points, like the grid intersections; it's a point-and-click
operation. It is fully integrated with OSM via a plugin and it's free,
so you can just play with it a bit to see it. I'm not sure if JOSM
does the same so easily. You can even work on the raster data in their
original projection; the vector layers are reprojected on-the-fly, so
they can be in OSM's WGS 84 but will still show correctly on the
cadastre sheets, keeping the substrate as legible as possible to aid
the vectorization.

with regards
Kay

[Olivier Croquette]

On Dec 7, 4:40 pm, kfj <_...@yahoo.com> wrote:
> It looks like there has been a great effort
> done on the data already, with hundreds of thousands of individual
> maps already vectorised. Is that so? And how did they do it? This is
> the information I'm refering to (sorry, my french is a bit rusty, so
> I'm not 100% certain if I interpret this correctly):
>
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre

Yes, most of the maps are already vectorized by the cadastre
departments, making the job for OSM much easier.
The rest is still in raster. Among the raster ones, there is an
undefined number of maps (probably <5%) using a so-called "local"
coordinate system (vs. France-wide systems like Lambert). This local
CS's are a challenge, because even the relevant cadaster departments
can't define them (I called them, they are still trying to find out).

> The data being from an official source, hey, even the cadastre, I
> reckon their scales are correct. Like the images you posted are
> 1:2000.

The problem is to put this scale in relation with the pixels - I
can't. So I have to rely on the control points for the proper scaling.

> I would like to give you a good answer about how to convert a
> scale into a Z parameter, but the connection is non-obvious. It is
> certainly not as straightforward as linear distances along the optical
> axis. I'll try and find it out, though.

OK, great, thanks !

> Now I'm not sure if I understand where this is going. My understanding
> of OSM is that the project's aim is to create a vector map of the
> earth. Vectorization is done piecemeal, so I don't see why you need
> very large raster maps. Hugin is well capable of dealing with large
> images (I'm not sure what the actual limit is, but I suspect it's
> beyond anyone's memory), but you wouldn't want to vectorize from a
> gigapixel map. Why first create one and then chop it into tiles if you
> can create a set of maps each of resonable size (like some 100 MBs)
> and use those as backdrop for vectorisation?

This is what I want to do, and a reasonable piece is one town. But
putting together the 24 submaps with a precision that allows to read
the street names brings me to 200Mpix. Even if Hugin can generate this
kind of file, importing it in JOSM will be a problem.

> Okay, granted. Just keep in mind the error sources. I don't know how
> accurately you can georefernce with JOSM, since I'm a QGIS user...

Georeferencing in JOSM is pretty bad. I should give QGIS a try soon.
But globally, my idea was to stitch the pieces first, because
georeferencing a big map is easier and faster than georeferencing 24
submaps (assuming they are precise and consistent)

> The data look to me as if they had precise grid references. I'd assume
> it doesn't get better than that, please correct me if I'm wrong. If
> you know the projection, the grid crossing points that are marked on
> the map should be perfect for georeferencing the sheets. Are you sure
> you are using the proper projection for the map data? What is the
> projection, by the way?

Unknown, unfortunately :( Otherwise I would georeference the submaps.

[Jordan Miller]

FYI:

I am stitching microscope images but it would ruin it if i optimized roll, x, and y. So I only optimize x and y. This gives me PERFECT stitchings every time. w00t!

jordan

[Bruno Postle]

On Tue 07-Dec-2010 at 02:54 -0800, Olivier Croquette wrote:

>resolution needs to be by factors higher, plus there are 12 times more
>input pictures, so the size of the final picture is not manageable by
>home computers.
>To solve this, Hugin would have output tiles of the big picture
>instead of a single file, without loading the whole in memory. I could
>imagine this requires quite some design changes.

There is a 'gigatile' tool which uses the Hugin cropping feature to
render the output as multiple 4096x4096 tiles:
http://search.cpan.org/dist/Panotools-Script/bin/gigatile

It also generates a JPEG pyramid for viewing with the Google Maps
API, but you don't need this bit (and it would be nice if someone
fixed it to use OSM rather than Google Maps).

--
Bruno

[kfj]

On 7 Dez., 19:42, Jordan Miller <jrdn...@gmail.com> wrote:
> FYI:
>
> I am stitching microscope images but it would ruin it if i optimized roll, x, and y. So I only optimize x and y. This gives me PERFECT stitchings every time. w00t!

If your microscope is remotely like mine, you shouldn't have roll,
since the scanning stage usually moves in X or Y ;-)

with regards
Kay

[kfj]

On 7 Dez., 19:05, Olivier Croquette <ocroque...@free.fr> wrote:

> Yes, most of the maps are already vectorized by the cadastre
> departments, making the job for OSM much easier.
> The rest is still in raster. Among the raster ones, there is an
> undefined number of maps (probably <5%) using a so-called "local"
> coordinate system (vs. France-wide systems like Lambert). This local
> CS's are a challenge, because even the relevant cadaster departments
> can't define them (I called them, they are still trying to find out).

This is a bother. I've been through this integrating maps into my GIS,
but using QGIS, I could at least try out any likely-sounding candidate
from the thousands of projections it supports and see if one matches
with other data. So I'd make a vector layer with, say, OSM data which
already exist of the area (usually there will be a motorway or such
which is already in the system - motorway crossings are excellent
reference points, and you can even crossreference with satellite
images), and then try different projections for the raster layer until
I find one where I instantly see it fits. If all else fails, this is
still a possibility. At least it's France and the data are quite
recent, so chances are the projection isn't too exotic - but maybe
you're still lucky and the departments can figure out what projection
they've used. Chances are they have used something which doesn't
differ too much from the national standard, so you can maybe narrow it
down. My QGIS installation lists about 20 Lambert-derived projections
which have been or still are in use in France. Best of luck ;-)

> The problem is to put this scale in relation with the pixels - I
> can't. So I have to rely on the control points for the proper scaling.

Now I see! Of course you don't know what resolution they have been
scanned with. Isn't there a standard size for a sheet like this?

> > I would like to give you a good answer about how to convert a
> > scale into a Z parameter, but the connection is non-obvious. It is
> > certainly not as straightforward as linear distances along the optical
> > axis. I'll try and find it out, though.
>
> OK,  great, thanks !

haven't yet found out...

> This is what I want to do, and a reasonable piece is one town. But
> putting together the 24 submaps with a precision that allows to read
> the street names brings me to 200Mpix. Even if Hugin can generate this
> kind of file, importing it in JOSM will be a problem.

JOSM seems to be your problem. I tried the other day to load a measly
200 MB GeoTIFF into JOSM, and it crashed with an out-of-memory error.
My pet project in QGIS has about 12 raster layers, some of which are
500 MB apiece, and even though it sometimes takes a while to calculate
my view onto the data, it has never failed to do so, no matter if I
want to look at a 400 square km overview or at individual houses in
the satellite images.

> Georeferencing in JOSM is pretty bad. I should give QGIS a try soon.

do, by all means. Once you see what it can do, you may not even want
to put considerable effort in trying to stitch the data with hugin.

> But globally, my idea was to stitch the pieces first, because
> georeferencing a big map is easier and faster than georeferencing 24
> submaps (assuming they are precise and consistent)

I have reservations concerning precision and consistence. As I have
pointed out, there are numerous sources of error. If the maps have
been scanned, it's quite possible that the scanning has introduced
subtle distortions (shear, slight shifts in aspect ratio). Statistics
tells us that, when combining data with errors, you can be lucky and
the errors cancel out (unlikely) or at least some of the errors sum up
to produce a larger error in the combination (likely). Every
additional processing step introduces additional errors. Putting the
scans directly into a capable GIS is still the desirable path, and
stitching with a panorama stitcher before would only be sensible if
you can't find a way of somehow properly georeferncing the data.

> > The data look to me as if they had precise grid references. I'd assume
> > it doesn't get better than that, please correct me if I'm wrong. If
> > you know the projection, the grid crossing points that are marked on
> > the map should be perfect for georeferencing the sheets. Are you sure
> > you are using the proper projection for the map data? What is the
> > projection, by the way?
>
> Unknown, unfortunately :( Otherwise I would georeference the submaps.

If you do not know the projection, you cannot derive vector data for
OSM from them. It's just not possible mathematically. You have to find
the projection, be it by getting the communes to remember what
projections were used for their maps, be it by trial and error, as I
have pointed out above, or be it by creating your own custom
projection to interpret a given data set. Concentrate your efforts on
that, for now. You gain nothing by stitching a larger map with an
unknown projection, since you can't use the data. Georeferencing is
not only finding some reference points with known coordinates, but
also includes the projection. You may make up your own projection by
defining a projection type (mercator, lambert etc), a reference point
and a scaling factor (I think that's all you need), but you definitely
need one.

with regards
Kay

[Carl von Einem]

kfj schrieb am 08.12.10 10:39:

>
> JOSM seems to be your problem. I tried the other day to load a measly
> 200 MB GeoTIFF into JOSM, and it crashed with an out-of-memory error.
> My pet project in QGIS has about 12 raster layers, some of which are
> 500 MB apiece, and even though it sometimes takes a while to calculate
> my view onto the data, it has never failed to do so, no matter if I
> want to look at a 400 square km overview or at individual houses in
> the satellite images.

I only found a German description how to start JOSM with more memory via
the command line:
<http://wiki.openstreetmap.org/wiki/DE:JOSM/Anleitung#Start_.C3.BCber_Kommandozeile>

For the Mac version there is also a description in English:
<http://wiki.openstreetmap.org/wiki/JOSM/Mac#memory>

On my OS X system this command works:
java -Xmx1G -jar
/Applications/josm-macosx/JOSM.app/Contents/Resources/Java/josm-snapshot-3376.jar

Note that on Mac OS X one has to open the JOSM.app bundle to get the
correct name of the .jar file.

Carl

[Olivier Croquette]

On Dec 7, 11:11 pm, Bruno Postle <br...@postle.net> wrote:
> There is a 'gigatile' tool which uses the Hugin cropping feature to
> render the output as multiple 4096x4096 tiles:http://search.cpan.org/dist/Panotools-Script/bin/gigatile

Nice, thanks for the link !

[kfj]

On 7 Dez., 19:05, Olivier Croquette <ocroque...@free.fr> wrote:

> > I would like to give you a good answer about how to convert a
> > scale into a Z parameter, but the connection is non-obvious. It is
> > certainly not as straightforward as linear distances along the optical
> > axis. I'll try and find it out, though.
>
> OK,  great, thanks !

I asked the group and finally received an answer today that clarified
the matter for me. Sorry I was confused, it's a linear distance along
the Z axis after all. Have a look at the link T. Modes sent to explain
the mosaic mode:

http://www.google.com/url?sa=D&q=http://wiki.panotools.org/Stiching_a_photo-mosaic&usg=AFQjCNF3n4u2D5ofRrAu1SntQoNnxp7oOg

and if you want to see my comment on it, look at

http://groups.google.com/group/hugin-ptx/browse_thread/thread/8adfa04e2a9d3cce/665c19c73496e0a4#665c19c73496e0a4

that's the thread

with regards
Kay

[dmg]

I only changed the focal length to 207 mm, and I don't see any problem
with the result:

http://turingmachine.org/~dmg/temp/rip2.jpg

--dmg

> --
> You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
> A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugi...@googlegroups.com
> To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/hugin-ptx
>
>

--
--dmg

---
Daniel M. German
http://turingmachine.org