Lens correction database

[Bruno Postle]

On Sun 13-May-2007 at 10:38 -0700, Yuval Levy wrote:
>> >you are exposing very interesting ideas. the place to discuss them is
>> ><http://lists.freedesktop.org/mailman/listinfo/create>
>>
>> It won't let me subscribe (we did both Cc the CREATE list, but it is
>> set to reject unsubscribed posts).
>
>weird. what error message do you get?

I suspect it is set to 'admin approve all subscriptions' and the
admin is away for a long weekend.

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

[Pablo d'Angelo]

Hi Bruno,


Bruno Postle wrote:

> On Fri 11-May-2007 at 00:48 +0200, Pablo d'Angelo wrote:
>> The idea is that people who want to correct their lens take some
>> test shots, and use hugin to estimate the required calibration
>> parameters. These are then sent (hugin projects and original
>> images) to a lens database coordinator, where they are checked for
>> plausibility and incorporated into the database.
>
> This is a lot of ongoing work for whoever does this checking, it's
> also a repetitive task without much reward and requires considerable
> user input too.  Another way of going about this might be do it all
> with code:
>
> hugin is the ideal tool for calibrating lenses, but there are lots
> of ways of doing this within hugin, most of them are incidental to
> the main task of stitching panoramas.
>
> It ought to be possible to be able to upload lens/camera parameters
> directly from hugin, perhaps via a simple http POST to a preset but
> configurable URI.

 >
> During the stitching process, hugin evaluates the quality of the
> optimisation by calculating error distances, why not improve this
> with some extra checks and give the user an option to upload the
> results from _all_ good optimisation passes.

I like this idea.

This could happen through uploading an anonymized pto file (image filenames
etc. removed) to some central server. Since often multiple optimisation will
be done before the final panorama is created, it might be a better idea to
upload the data when the user actually renders the panorama.

> eg. a field of view calculation is only credible if field of view
> was actually optimised and there are a large number of well-spread
> control points involved with a low error distance.
>
> Then the task of compiling the distributable database is statistical
> analysis of this collected raw data, removing outliers, averaging
> and interpolating.

The drawback of deriving these parameters from ordinary panoramas are
inaccuracies due to parallax errors, moving objects etc. I suspect many
users of hugin are satisfied with panoramas that do not lead to a good
calibration. So some effort needs to be spend on determining a good way
to reject those. Maybe some simple rules based on distribution of the points
and the might be enough, but that needs to be evaluated.

The good thing is that both the "manual" calibration approach and this
upload based approach can be combined :-) So we can start with
the calibration based one, and later add the more automatic, upload
based approach.

ciao
   Pablo

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

[Pablo d'Angelo]

Hi Yuval,

>> License:
>
 >
 > CODE: the code should be free. I'd recommend GPL for the data structure
 > and the web based application; and something like LGPL for that part of
 > the code that will be integrated into the applications to do the XML
 > parsing and actual correction based on the database information. No
 > restriction on using the code from within closed source applications.

I'd like to license the library that interacts with the database as GPL,
since I'd like to keep the database free and open. If a vendor wants to use
the database easily, they can then always ask for a commercial license of
the software interface and the corresponding correction routines.

> CONTENT/DATABASE: I'd ensure that the database content is owned by one
> person/entity with a condition on the entry page stating that "by
> entering data in this form, you officially transfer copyright and
> ownership of it to <FILL THE BLANK>".

Given the mess we have seen with the panotools license, a copyright transfer
would make sense. The question is which organisation or person <FILL THE
BLANK> should be. I would volunteer, but I'm not completely sure about the
legal implications.

> then I'd multi-license the database:
> - a free license for non-commercial use within open source applications.
> - a small fee for commercial use within open source tools (e.g. 20$).
> - a negotiable fee for licensed use in closed source commercial
> applications.

I think since the database is mostly build out of community work, it would
make sense to keep it free. I actually like the Creative Commons Sharealike
license for the database. The CC SA will make sure that people contribute
back to the database, should it be included in other packages. If commercial
packages start to use the database, their users will hopefully ask for
support for new lenses and cameras, with the result of a faster growing
database.

> I think it is reasonable to ask for money from commercial players,
> wether they are users making money using open source code or companies
> selling closed source software licenses.
>
> The money can be plugged back in to the community, e.g. code bounties,
> hardware, and all the other nice things that money can buy.

It would be nice to have more support for the development this way,
but I'm not sure if this model works well for such a very community based
project, where we have many authors that contribute a little pieces (one or
two calibrations).

ciao
   Pablo


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

[Simon Oosthoek-5]

On 20/05/07, Pablo d'Angelo <pablo.dangelo@...> wrote:

Hi Yuval,

> CONTENT/DATABASE: I'd ensure that the database content is owned by one
> person/entity with a condition on the entry page stating that "by
> entering data in this form, you officially transfer copyright and
> ownership of it to <FILL THE BLANK>".

Given the mess we have seen with the panotools license, a copyright transfer
would make sense. The question is which organisation or person <FILL THE
BLANK> should be. I would volunteer, but I'm not completely sure about the
legal implications.

I don't think it would be necessary to transfer the copyright (copyright on a database is not very clear I think), but it would be a good idea to spread the data around and to make sure that the data-users and data-creators know that the data is meant to be used freely and is freely distributable. Any judge would take this into account when a copyright infringement case would be brought before him that the data was intended to be free and public.

The distribution could perhaps be done by using something like the git versioning tool. It distributes the entire history to the end-user and later it can be merged with other versions of the same git tree. Any copy would be whole and self sufficient and cannot be taken hostage.

Cheers

Simon

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

[Bruno Postle]

On Thu 17-May-2007 at 15:02 +0200, Pablo d'Angelo wrote:

> > During the stitching process, hugin evaluates the quality of the
> > optimisation by calculating error distances, why not improve
> > this with some extra checks and give the user an option to
> > upload the results from _all_ good optimisation passes.

> This could happen through uploading an anonymized pto file (image
> filenames etc. removed) to some central server.

The pto files can get very large, especially when calibrating lenses
with thousands of control points.  Is it practical to upload a 30kB
pto file with a dial-up connection?  How many is it practical to
receive concurrently?

Perhaps this is too simplistic: but the lens parameters could be
submitted to a server with a single http GET just by appending them
to the URL:

http://example.com/lens?CameraModel=Nikon%20D100;CropFactor=1.5;a=0.01;b=-0.021;etc...

This could be received by a CGI or PHP script and stuffed into an
SQL database, but it would be even simpler to have no script on the  
server and pull the information out of the server logs - This system
is _very_ scalable even with modest server hardware.

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

[Pablo d'Angelo]

Hi all,

Thomas Niemann has allowed us to use the calibrations in his old, text
based database. I have written a converter for his format into the
xml format (preliminary) we are currently discussing. The conversion is
currently quite crude and places everything in a single file
(size: ~500 kB). Maybe the current xml syntax is too verbose....

I have placed an example entry, the converter and the converted PTLens
database in a separate "module" of the hugin SVN repository:

http://hugin.svn.sourceforge.net/viewvc/hugin/lensdb/trunk/

ciao
   Pablo

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

[Bernard Lang-2]

Hi,

I have several questions/suggestions

Apologies if I missed answers relevant to some.

Bernard

1 -

  I found this paper :
http://groups.csail.mit.edu/graphics/classes/6.837/F99/devernay-faugeras_95b.ps.gz
I realize that this paper is 10 years old.  Is the approach proposed
in it obsolete or less accurate. It seems easier to use. I do not know
whether there are other proposals of the kind.


2 -

What is the importance of Image shift parameters "d" and "e" : Can
they have an impact on the accuracy of other parameters ?  They have
to be computed anyway for each camera, at least according to this
tutorial : http://www.kekus.com/forum/showthread.php?t=31

3 -

A database of the kind of EXIF data provided by each type of camera
would also be quite useful.   Maybe it already exist, but I never
saw it.  And technical documentation of vendors does not usually say
anything about that.
One advantage of such a database is that it would put pressure on
camera makers to give accurate EXIF data.

However this point is implicitly covered by my next suggestion.


4 -

Why not include in the database the photos used for the calibration
process, and the .pto file ?  This could have several advantages :

   - it would be possible to repeat the computation and possibly
     improve it or check it

   - anyone could then upload his data on the database,
     whithout work for the maintainer, thus making the process more
     decentralized.

   - it would still be possible for the maintainer, or anyone else, to
     check or repeat the calibration, with any old or new tool, and
     add his own certification stamp to the results, or to a different
     result if there is disagreement.

     In essence that would mean a separate validation process, as
     already exists on various cooperative sites, like wikipedia for
     example.

   - re-checking could possibly be done mechanically on the whole
     database in the future, as better tools or practices become
     available.

   - the database would provide at the same time information about the
     EXIF formats of cameras on the market.

   - more generally, it would be a useful database of pictures to test
     whathever new parameter one may want to compare (or make
     statistics about) across the range of available cameras and
     optics.

   - the data would be available for anyone to create a competing
     database, with possibly improved organization or features, or
     improved computation techniques.  That is precisely the basis for
     the effectiveness of free software in bringing innovation.


Drawback : it would make the database much heavier for the maintainer,
but that should not be unmanageable, expecially considering that
people would not usually download the images.

It would still be possible not to include the source photos, if for
some reason there is no other way to get data published about a given
camera.

The only problem that I see is that some people might not want to have
some of their pictures freely available in a free database.  This
issue can be handled legally in a simple way : make the licence free
and copyleft for calibration and analysis purposes, but reserve the
right on the photos for any imaging purpose (unless explicitly stated
in the comment fields of the picture, or otherwise).

I can already hear the comments of some radicals, but :
  - it make perfect legal sense
  - it gives more to the public than just abandonning the idea of
    having the source pictures, so as to pretend to copyleft purity.
    So it can only be an improvement.

I would add that to give the parameters without the data (photos) to
compute them (i.e. the source pictures) is a bit like giving a free
object code without the source code : like free beer, but not like
free speech.




* Pablo d'Angelo <pablo.dangelo@...>, le 17-05-07, a écrit:

>
> Hi Bruno,
>
>
> Bruno Postle wrote:
> > On Fri 11-May-2007 at 00:48 +0200, Pablo d'Angelo wrote:
> >> The idea is that people who want to correct their lens take some
> >> test shots, and use hugin to estimate the required calibration
> >> parameters. These are then sent (hugin projects and original
> >> images) to a lens database coordinator, where they are checked for
> >> plausibility and incorporated into the database.
> >
> > This is a lot of ongoing work for whoever does this checking, it's
> > also a repetitive task without much reward and requires considerable
> > user input too.  Another way of going about this might be do it all
> > with code:
> >
> > hugin is the ideal tool for calibrating lenses, but there are lots
> > of ways of doing this within hugin, most of them are incidental to
> > the main task of stitching panoramas.
> >
> > It ought to be possible to be able to upload lens/camera parameters
> > directly from hugin, perhaps via a simple http POST to a preset but
> > configurable URI.
>  >
> > During the stitching process, hugin evaluates the quality of the
> > optimisation by calculating error distances, why not improve this
> > with some extra checks and give the user an option to upload the
> > results from _all_ good optimisation passes.
>
> I like this idea.
>
> This could happen through uploading an anonymized pto file (image filenames
> etc. removed) to some central server. Since often multiple optimisation will
> be done before the final panorama is created, it might be a better idea to
> upload the data when the user actually renders the panorama.
>
> > eg. a field of view calculation is only credible if field of view
> > was actually optimised and there are a large number of well-spread
> > control points involved with a low error distance.
> >
> > Then the task of compiling the distributable database is statistical
> > analysis of this collected raw data, removing outliers, averaging
> > and interpolating.
>
> The drawback of deriving these parameters from ordinary panoramas are
> inaccuracies due to parallax errors, moving objects etc. I suspect many
> users of hugin are satisfied with panoramas that do not lead to a good
> calibration. So some effort needs to be spend on determining a good way
> to reject those. Maybe some simple rules based on distribution of the points
> and the might be enough, but that needs to be evaluated.
>
> The good thing is that both the "manual" calibration approach and this
> upload based approach can be combined :-) So we can start with
> the calibration based one, and later add the more automatic, upload
> based approach.

--
             Le brevet logiciel menace votre entreprise
               Software patents threaten your company
    Soutenez la Majorité Économique - Support the Economic Majority
                  http://www.economic-majority.com/

Bernard.Lang@...             ,_  /\o    \o/    Tel  [phone]
http://pauillac.inria.fr/~lang/  ^^^^^^^^^^^^^^^^^  Fax  [phone]
            INRIA / B.P. 105 / 78153 Le Chesnay CEDEX / France
         Je n'exprime que mon opinion - I express only my opinion

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

[Pablo d'Angelo]

Hi Bernard,

Bernard Lang wrote:

>   I found this paper :
> http://groups.csail.mit.edu/graphics/classes/6.837/F99/devernay-faugeras_95b.ps.gz
> I realize that this paper is 10 years old.  Is the approach proposed
> in it obsolete or less accurate. It seems easier to use. I do not know
> whether there are other proposals of the kind.

I have thought about a similar approach, but I wasn't sure if it is reliable
enough. The results in the paper look good, Maybe if I have some time to
write the code, I'll try it.

> What is the importance of Image shift parameters "d" and "e" : Can
> they have an impact on the accuracy of other parameters ?  They have
> to be computed anyway for each camera, at least according to this
> tutorial : http://www.kekus.com/forum/showthread.php?t=31

Yes, they are usually dependent on the camera (play in lens mount etc.).
However, for simple distortion correction, we can get away with assuming
that they are located in the image centre. Due to differences between each
camera, it is impossible to create a accurate (<1 of a pixel or so), generic
distortion correction database anyway.

> 3 -
>
> A database of the kind of EXIF data provided by each type of camera
> would also be quite useful.   Maybe it already exist, but I never
> saw it.  And technical documentation of vendors does not usually say
> anything about that.
> One advantage of such a database is that it would put pressure on
> camera makers to give accurate EXIF data.

exiftool contains GREAT support for all different kinds of metadata stored
in images. However, this hasn't lead camera makers to be more open with
their EXIF extensions.

> 4 -
>
> Why not include in the database the photos used for the calibration
> process, and the .pto file ?

Actually, this is planned for dedicated calibrations.

> The only problem that I see is that some people might not want to have
> some of their pictures freely available in a free database.  This
> issue can be handled legally in a simple way : make the licence free
> and copyleft for calibration and analysis purposes, but reserve the
> right on the photos for any imaging purpose (unless explicitly stated
> in the comment fields of the picture, or otherwise).

Yes, for dedicated calibration images, they need to be available. However, I
don't think this is a real problem, since the calibration shots will
probably be dedicated images, without much artistic value.

ciao
   Pablo

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

[Pablo d'Angelo]

Bruno Postle schrieb:

> On Thu 17-May-2007 at 15:02 +0200, Pablo d'Angelo wrote:
>
>>> During the stitching process, hugin evaluates the quality of the
>>> optimisation by calculating error distances, why not improve
>>> this with some extra checks and give the user an option to
>>> upload the results from _all_ good optimisation passes.
>
>> This could happen through uploading an anonymized pto file (image
>> filenames etc. removed) to some central server.
>
> The pto files can get very large, especially when calibrating lenses
> with thousands of control points.  Is it practical to upload a 30kB
> pto file with a dial-up connection?  

If I had a dialup only (common for some people in germany, DSL is not
available everywhere), I wouldn't want to used for uploading such kind of
data anyway. Maybe some caching scheme might help.

 > How many is it practical to receive concurrently?

Hmm, maybe a binary format would be more efficient than the pto text files.
Except for extremely large projects, the size required for transmission
would be a smaller than 10 kB (uncompressed). But still, it could lead to
quite some burden on the receiving server, I agree.

> Perhaps this is too simplistic: but the lens parameters could be
> submitted to a server with a single http GET just by appending them
> to the URL:
>
> http://example.com/lens?CameraModel=Nikon%20D100;CropFactor=1.5;a=0.01;b=-0.021;etc...
>
> This could be received by a CGI or PHP script and stuffed into an
> SQL database, but it would be even simpler to have no script on the  
> server and pull the information out of the server logs - This system
> is _very_ scalable even with modest server hardware.

Yes, this sounds like a good idea to get a scalable system.

The only drawback is that less information is available, and most processing
to determine if a stitch is good for calibration purposes needs to be done
in hugin itself.
Having access to the pto file would provide much more flexibility, and
improvements in the algorithms to mine the calibrations could be done on the
existing database.

ciao
   Pablo

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

[Bruno Postle]

On Mon 21-May-2007 at 00:42 +0200, Pablo d'Angelo wrote:
>
>Thomas Niemann has allowed us to use the calibrations in his old, text
>based database. I have written a converter for his format into the
>xml format (preliminary) we are currently discussing. The conversion is
>currently quite crude and places everything in a single file
>(size: ~500 kB). Maybe the current xml syntax is too verbose....

XML needs to be verbose, the gzip version is 32kB so I don't think
this is a problem.

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

[dmg-4]

 Simon Oosthoek twisted the bytes to say:


 Simon> On 20/05/07, Pablo d'Angelo <pablo.dangelo@...> wrote:
    Hi Yuval,
   
    > CONTENT/DATABASE: I'd ensure that the database content is owned by one
    > person/entity with a condition on the entry page stating that "by
    > entering data in this form, you officially transfer copyright and
    > ownership of it to <FILL THE BLANK>".
   
    Given the mess we have seen with the panotools license, a copyright transfer
    would make sense. The question is which organisation or person <FILL THE
    BLANK> should be. I would volunteer, but I'm not completely sure about the
    legal implications.

 Simon> I don't think it would be necessary to transfer the copyright
 Simon> (copyright on a database is not very clear I think), but it
 Simon> would be a good idea to spread the data around and to make
 Simon> sure that the data-users and data-creators know that the data
 Simon> is meant to be used freely and is freely distributable. Any
 Simon> judge would take this into account when a copyright
 Simon> infringement case would be brought before him that the data
 Simon> was intended to be free and public.

What you are implying is to put in the public domain (no copyright ->
public domain).

IN my opinion, each individual values are not copyrightable (they are
facts, not expression), but the entire database is copyrightable (in
the countries where databases are, which in the long term is expected
to be all).


dmg



 Simon> The distribution could perhaps be done by using something like
 Simon> the git versioning tool. It distributes the entire history to
 Simon> the end-user and later it can be merged with other versions of
 Simon> the same git tree. Any copy would be whole and self sufficient
 Simon> and cannot be taken hostage.

 Simon> Cheers

 Simon> Simon

 Simon>

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

[alexandre jenny]

 
Hi,

>   I found this paper :
>
http://groups.csail.mit.edu/graphics/classes/6.837/F99/devernay-faugeras_95b
.ps.gz

This is an old but quite standard way to do it.
The paper "straight line have to be straight" is a more up to date version
of this technic.

> Why not include in the database the photos used for the
> calibration process, and the .pto file ?

I totally agree with this. The photos have to be provided to give the
possibility to
redo the optimization, with new enhancement of algorithm / calibration
process.
Without them, you are just lost.

BTW : bernard talked about an exif database for any camera type. That's
exactly it.
The real exif database would to have at least one picture of each camera /
lens combinaison
 / format ( jpeg / raw ).
Then, it would be up to you to check that your tool can decode them.

> Drawback : it would make the database much heavier for the
> maintainer, but that should not be unmanageable, expecially
> considering that people would not usually download the images.

This lens database is something here at kolor we though of 2 years ago. And
that's something
we want to participate if the license allows us to do so. Having our product
using this database will definitively help everyone because we will have a
faster growing database of result.
Always with the same preleminaries of licensing issue, we could also help
with servers for storing
this database of parameters / pictures. This is something we are used to do.

For calibration, I really insist on two facts :
* Panotool lens models had to be revamp and improved. It's not really good.
(BTW : the database could store more than one model. We can even thing that
anyone who has it's own lens model could run some test on the pictures again
to calibrate it's tool ).
* We need standard workflow. If someone is doing stitching with 5%
overlapping and another time 50%, the results will just be really
differents. Without standard process, the accuracy of the database will just
make it useless.

Alexandre
Kolor



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

[Bernard Lang-2]

* alexandre jenny <alexandrejenny@...>, le 22-05-07, a écrit:

>
>  
> Hi,
>
> >   I found this paper :
> >
> http://groups.csail.mit.edu/graphics/classes/6.837/F99/devernay-faugeras_95b
> .ps.gz
>
> This is an old but quite standard way to do it.
> The paper "straight line have to be straight" is a more up to date version
> of this technic.
>

available at
http://www-igm.univ-mlv.fr/~vnozick/ENSEIGNEMENTS/PROJET_TURORE/PROJET_TUTORE_2003_2004/IRCGN/ARTICLES/devernay01straight.pdf

bernard


--
             Le brevet logiciel menace votre entreprise
               Software patents threaten your company
    Soutenez la Majorité Économique - Support the Economic Majority
                  http://www.economic-majority.com/

Bernard.Lang@...             ,_  /\o    \o/    Tel  [phone]
http://pauillac.inria.fr/~lang/  ^^^^^^^^^^^^^^^^^  Fax  [phone]
            INRIA / B.P. 105 / 78153 Le Chesnay CEDEX / France
         Je n'exprime que mon opinion - I express only my opinion


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