Re: [hugin-ptx] Idea for horizontal/vertical lines

[Yuval Levy]

On December 7, 2010 03:20:47 pm Lukáš Jirkovský wrote:
> Today I've found an interesting idea

excellent idea! put in output space (fast preview) what is related to output 
space (lines) instead of cramming it into input space (cp tab).

I would say: file a feature request in the tracker, tag it as gsoc (could be 
an interesting gsoc project, or at least part thereof).

Yuv


signature.asc
Description: This is a digitally signed message part.

[hugin-ptx] Re: Idea for horizontal/vertical lines

[Bart van Andel]

Excellent idea! The way adding lines works has bothered ever since I
started using it, it just didn't bother me enough to file a request I
guess (or it didn't cross my mind).

But now we're at it: we'd need 3 tools actually. Besides horizontal
lines (lines at the equator) and vertical lines (lines perpendicular
to the equator) there is a third type of line, referred to as "add new
line" in the control point interface. This is a general type of line,
IIRC this just means a straight line in any direction (maybe someone
has a better definition?). I've used it in a couple occasions, maybe
only with rectilinear output, I don't remember. Anyway, it should
definitely not be forgotten, if this feature request is accepted and
implemented.

By the way, I believe we had someone working on line detection in the
past (GSOC project)? Has this resulted in anything but a dead branch?
I remember uploading some test images but I don't think I ever read
anything about results...

--
Bart

On 7 dec, 21:20, Lukáš Jirkovský  wrote:
> Today I've found an interesting idea for RawTherapee project [0] and I
> think hugin could make use of a similar tool to the tool proposed on
> Rawtherapees forum.
>
> Long story short. Currently there is only one way how to specify
> horizontal or vertical lines. For defining either of them you need to
> manually specify control points. This is not very user friendly and it
> can take a lot of time. The idea is to allow drawing the lines in fast
> preview window. There would be two new tools in Fast Preview window -
> draw vertical line and draw horizontal line. User then would just draw
> the line over the image and hugin would automatically add control
> points defining line here.
>
> [0]http://rawtherapee.com/forum/viewtopic.php?p=17063#17063

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] BUG [679337] Feedback welcome

[Gerry Patterson]

Hello,

Bellow is a comment I made regarding this bug which is sent out the
hugin-bug-hunters team.  I am posting it here as well as other might have
more insight.


The bug is:Camera response not assigned to the correct
image?

= report:==

Hugin apparently gives the wrong camera response to images, depending on the
first image in the panorama.

Steps to reproduce:
1. Open Hugin
2. Add any two images
3. Assign a different camera to the second image
4. Change the camera response in the first image (for example, enter 5 in
the bottommost box)
5. Look at the two images in the normal preview
5. Save pto file and generate with nona the two "remapped" files

Expected result: the preview of the first image and its remapped image has a
strange color

Outcome: in the normal slow preview the first image is unchanged and the
second one has a very strange color. The same is true for the remapped
images. The GL preview (with Photometrics applied) shows the correct colors
for the second image.

Fix: move up the second image (in the Images tab). Both bugs (in the output
and in the preview) are fixed.

= my comment:==

I have looked into the code on this. I am not familiar with what is supposed
happen but I have a guess:

When one takes a panorama with a single camera with a single response curve,
the output image will use this response curve as well.

When one takes a panorama with multiple cameras, each with their own
response curve, one of the response curves is chosen to be the one which all
others are referenced to. These are the "output" EMoR parameters, as they
are described in the code. Right now, these are hard coded to be whatever
set of parameters are used for the first image. Both nona and the slow
preview enforce this. This is why, when you change the EMoR parameters for
the first image (or any image who's EMoR parameters are linked to the first
image) all other images change since they are either using these new EMoR
parameters (same lens) or their response curve is referenced to the first
image.

However, in the case of the fast preview, while it generates the LUT for the
output response curve, it is always for a output EMoR parameter set of
0,0,0,0,0. I think this is a bug and I have a patch which makes it behave
the same as the rest of the system.

However, I am thinking it would make sense to expose the choice of which
response curve to use as the output one instead of always picking the one
associated with the first image in the list. Similar to how anchor for
exposure and anchor for position are used in the images tab.

Feedback is welcome here

- Gerry

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Stitching perfectly flat pictures (maps) together

[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

--
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] [OSX] Hugin-2010.4.0-beta2 MacOSX bundle available for download

[Harry van der Wolf]

2010/12/7 David Haberthür 

> Hoi Harry
>  I couldn't find blaring errors. I'd clean up some white-space (sometimes
> you're having lots of newlines, sometimes not) and would harmonize the
> writing of Mac OS X (which is written as MacOSX or MacOsx).
>

Regarding the white space: I will have a look at it. The "Mac OS X" is
already there from the first version Ippei wrote. I have always overlooked
it in the several versions afterwards. I always write MacOSX (also in the
subject of this mail). I'll change it before the new release. Thanks for
mentioning it.

Harry

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] [OSX] Hugin-2010.4.0-beta2 MacOSX bundle available for download

[David Haberthür]

Hoi Harry

On 04.12.2010, at 14:25, Harry van der Wolf wrote:

> Hi mac users,
> 
> Yesterday Yuval released beta2 of Hugin-2010.4.0. (see [0] for announcement 
> and changelog).
Thanks Yuv for the release!

> In the bundle you will find the beta2. 
> I also updated the the "Read me first (mac)" document. Feedback on 
> improvements, correct english and/or typos are welcome.
Thanks Harry for your hard and timely work to keep us Mac users up to date. 
Much appreciated. I couldn't find blaring errors. I'd clean up some white-space 
(sometimes you're having lots of newlines, sometimes not) and would harmonize 
the writing of Mac OS X (which is written as MacOSX or MacOsx).
Have a nice evening
Habi

PS: I'm giving beta2 a short test-run on OS X now, a test on Win 7 64 (computer 
at work with 16 GB RAM) was successful on the weekend

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Images tab not fit in window

[Yuval Levy]

Hi,

On December 7, 2010 02:38:04 am cqhl wrote:
> I try the 2010.4 beta2 source on UHU-Linux 2.1. The problem, the
> selected image very small and on button labels. The new control pont
> detector "Hugins Cfind + Celeste" drop box name very wide.  With
> the "create control points" button use very wide regio.I use 1280x800
> or 1024x768 pixel size desktop.

I try to understand your report but am not sure.  Can you please make a print-
screen and post it?  Ideally attached to a bug report on launchpad, but just 
attached to an email to this mailing list is also OK.

 
> I confused with launchpad. I try migrate to launchpad from
> sourceforge.
> 
> I see this webpage, > Claim an Imported SourceForge Account > Log on
> to the Hugin bug tracker
> 
> How to log on? I have normal sourceforge account. I think this is not
> an openid.
> http://wiki.panotools.org/Hugin_Trackers#Launchpad_Account

You need to first open an account with Launchpad and then you can claim the 
imported SourceForge account.  Log on to Launchpad is not OpenID, and even if 
it was you'd still need to create an account at some point.

Yuv


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Spanish translation

[Uwe Koch Kronberg]

Hi Yuv. I did not merge it. I just verified with msgfmt that the file
had no errors. I did not compare it with Ernesto's file either, but as
of yesterday he wrote in order to do it. In the meanwhile, I see no
problem publishing both of them, one as es_la.po (Ernesto's) and the
other as es.po (mine).

Uwe

El 07/12/10 17:55, Yuval Levy escribió:
> On December 6, 2010 09:19:00 pm Uwe Koch Kronberg wrote:
>> Hi all, I'm attaching a new file.
>> msgfmt did its job!
> what did you merge it with? how is it related to es_la.co from Ernesto? do we 
> publish both, or just es.po?
>
> Yuv

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Spanish translation

[Yuval Levy]

On December 6, 2010 09:19:00 pm Uwe Koch Kronberg wrote:
> Hi all, I'm attaching a new file.
> msgfmt did its job!

what did you merge it with? how is it related to es_la.co from Ernesto? do we 
publish both, or just es.po?

Yuv


signature.asc
Description: This is a digitally signed message part.

[hugin-ptx] Idea for horizontal/vertical lines

[Lukáš Jirkovský]

Today I've found an interesting idea for RawTherapee project [0] and I
think hugin could make use of a similar tool to the tool proposed on
Rawtherapees forum.

Long story short. Currently there is only one way how to specify
horizontal or vertical lines. For defining either of them you need to
manually specify control points. This is not very user friendly and it
can take a lot of time. The idea is to allow drawing the lines in fast
preview window. There would be two new tools in Fast Preview window –
draw vertical line and draw horizontal line. User then would just draw
the line over the image and hugin would automatically add control
points defining line here.

[0] http://rawtherapee.com/forum/viewtopic.php?p=17063#17063

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Stitching perfectly flat pictures (maps) together

[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





On Dec 7, 2010, at 3:59 AM, voschix wrote:

> 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
> 
> -- 
> 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 hugin-ptx@googlegroups.com
> To unsubscribe from this group, send email to 
> hugin-ptx+unsubscr...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/hugin-ptx

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Stitching perfectly flat pictures (maps) together

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

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] mosaic mode maths - an equation, please!

[kfj]

Hi all!

I'm trying to help in a parallel thread

http://groups.google.com/group/hugin-ptx/browse_thread/thread/873b58166bd2ff33/74891be947b6e4b6#74891be947b6e4b6

There is a guy who needs to know how varying the Z parameter
translates into a scaling factor. I thought this was straightforward,
but found it is not: I thought the Z parameter translates into a
linear distance along the optical axis measured from the center of the
panosphere, since the X and Y parameters translate into linear shifts
parallel to the image plane. This would be easy. But I can set Z
beyond 1.0, even up to 100 and further, and the image 'comes closer'
but I never quite get there. So it must be some asymptotic nonlinear
function, and I can't be bothered poking around in the code to find
the formula. Maybe someone can just tell me what it is or point me to
the appropriate place?

with regards
Kay

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Stitching perfectly flat pictures (maps) together

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

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Stitching perfectly flat pictures (maps) together

[kfj]

On 7 Dez., 13:16, Bernard Lang  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

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] ANN: Panotools Tracker (and Hugin and Enblend too)

[Yuval Levy]

https://bugs.launchpad.net/panotools

* I have (temporarily) put the Hugin Bug Hunters team in charge of triage.  
Inception of a dedicated team can be undertaken later if necessary.
* Ownership is with Hugin Dev. This can be changed to if necessary.
* There are "only" a handful of open reports, so initial triage won't be as 
intense as for Hugin (90% done, thank you to all who have been tackling 
reports)
* Sign up for a Launchpad Account [1] (necessary to file bug reports, feature 
requests, patches, etc.) to Panotools, Enblend, Hugin
* Imported reports are "orphaned".  If you posted a report to any of those 
trackers in the past, please claim ownership.  Instructions at [2]
* Manage your notifications.  Instructions at [3]

Happy Bug Hunting!
Yuv

[0] 
[1] 
[2] 

[3] 


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Re: Stitching perfectly flat pictures (maps) together

[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 <_...@yahoo.com>, le 07-12-10, a écrit:
> 
> 
> On 7 Dez., 10:20, Bernard Lang  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
> 
> -- 
> 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 hugin-ptx@googlegroups.com
> To unsubscribe from this group, send email to 
> hugin-ptx+unsubscr...@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

  bernard.l...@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

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Stitching perfectly flat pictures (maps) together

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

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Stitching perfectly flat pictures (maps) together

[Olivier Croquette]

On Dec 7, 9:59 am, voschix  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)

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Stitching perfectly flat pictures (maps) together

[kfj]

On 6 Dez., 11:29, Olivier Croquette  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

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Stitching perfectly flat pictures (maps) together

[kfj]

On 7 Dez., 10:20, Bernard Lang  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

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: masking cropped images

[kfj]

On 6 Dez., 16:41, Felix Hagemann  wrote:

> +1. I've been bitten by include masks in the cropped area as well.

Meanwhile I've filed a bug report concerning this issue:

https://bugs.launchpad.net/hugin/+bug/685558

so it's in the pipeline and may get resolved.

> While I like the idea of merging the crop tab with the mask tab, I
> think there is a fundamental problem with the approach:
> One the one hand masking as well as adding control point should best
> done on remapped images. I think already is a wishlist items for this.
> On the other hand cropping is mainly used to cut off dark edges of
> input fisheye images, which can be sensibly done on the original
> images only.

So, cropping is really like a less capable form of masking used for
source images only, whereas masking is a more capable form of cropping
that should be used on warped images but is not ;-)

Hmmm... conceptually, both are masking operations. And I see the point
of masking the input images (I often use it to 'remove myself' from
360/180s, which works just fine on unwarped images) - as I see the
point of using it on warped images, as it would actually be more
precise and predictable. I agree with you that control point editing
might be better with warped images.

So I reckon the ideal situation would be to allow masking on both
warped and unwarped images. It would be hard to make the two
compatible, though, with the current technique: The mask is described
by a polygon, and warping would make the polygon into a shape with
curved edges, something you'd have a real hard time describing with a
simple string of number pairs (that's how masks are represented in the
pto). Reversely, unwarping a polygonal mask defined for a warped image
would do the same. Maybe the masking could move to direct manipulation
of the alpha channel - then the warping/unwarping would just happen
together with the image data - I'm not entirely certain how it's done
technically in huign, but the only feasible way I can imagine is
calculation of the alpha channel from the polygonal mask and applying
or at least attaching it before warping, so the alpha channel handling
is already there, but the alpha channel can't yet be directly
manipulated.

There is one more aspect to cropping/masking. It is quite possible to
apply an alpha channel to the image before feeding it into hugin. This
is easily done with, e.g. the gimp, and there, a full infrastructure
exists to edit the alpha channel to one's heart's content, so the
facilty to create crops and simple polygonal masking in hugin is just
a nice-to-have tool just where you want it which does just what you
need most of the time, and not the only way to achieve such effects.

For the time being, with cropping and masking both happening on the
source image, and the only added feature for cropping is making the
mask circular, I think the two could be safely merged, especially if
the option to load mask(s) with the lens ini file, or an equivalent
mechanism, was included - any more involved operation on the input
images can be done externally. Working on warped images (like, direct
interaction with data displayed in the preview) remains an alluring
possibility for the future.

with regards
Kay

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Stitching perfectly flat pictures (maps) together

[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 , le 04-12-10, a écrit:
> Olivier Croquette  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'
> 
> -- 
> 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 hugin-ptx@googlegroups.com
> To unsubscribe from this group, send email to 
> hugin-ptx+unsubscr...@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

  bernard.l...@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

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: Stitching perfectly flat pictures (maps) together

[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

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[hugin-ptx] Re: 2010.4.0-beta1 Win32 test

[namklim]

subject title changed back after thread hijacking

-- 
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 hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx