On Sun, Jan 09, 2011 at 09:21:14AM -0500, Yuval Levy wrote:
- w: weight (0.0 to 100.0) - default 1.0
I still say: Don't mention an upper limit.
Weight: floating point, default 1.0. We currently don't expect
negative weights to be useful, but who knows.
You can add a remark: currently Yuval
On January 10, 2011 03:27:19 am Rogier Wolff wrote:
On Sun, Jan 09, 2011 at 09:21:14AM -0500, Yuval Levy wrote:
- w: weight (0.0 to 100.0) - default 1.0
I still say: Don't mention an upper limit.
Weight: floating point, default 1.0. We currently don't expect
negative weights to be
On 9 Jan., 10:23, T. Modes thomas.mo...@gmx.de wrote:
That's not fully correct. I agree with Bruno.
First write the spec of the *function* and *not of the fileformat*.
This is a hen-and-egg problem. How did nature solve it? By evolution.
How do you evolve in software? You write a prototype,
On January 8, 2011 12:07:10 pm Tom Sharpless wrote:
4. case to mark sets of CPs to be used for morph-to-fit.
thanks for this, Tom. I'll update the work-in-progress specs accordingly by
transforming the active flag from a one bit to a two bits parameter:
- s: source (0=unknown, 1=human,
Hey Yuv,
On Jan 2, 9:47 pm, Yuval Levy goo...@levy.ch wrote:
B. SPECIFYING THE NEW NEEDS
1. there is a case/request to activate/deactivate CPs
2. there is a case to weight CPs
3. there is a case to discern the source of CPs (human or computer generated)
I would like to add
4. case to
On January 3, 2011 06:27:29 am Rogier Wolff wrote:
On Sun, Jan 02, 2011 at 09:47:48PM -0500, Yuval Levy wrote:
#-hugin cpWeight s0 a0 w100
Hey, do you see a need for an active-weight-zero control point?
Not really, weight is relative.
Do you see a need for an inactive weight-not-zero
On 6 Jan., 23:53, Bruno Postle br...@postle.net wrote:
Sorry, I'm not familiar with this code. Hugin updates all the
control point distances after optimisation and on initially loading
a project (so it isn't necessary to run the optimiser to get this
info).
If you could name the routine
calcCtrlPointErrors
--
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
On 7 Jan., 19:06, T. Modes thomas.mo...@gmx.de wrote:
calcCtrlPointErrors
Thanks, that was what I was looking for!
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
On 6 Jan., 00:11, Bruno Postle br...@postle.net wrote:
You could use PToptimizer which writes all this statistical
information about control point errors to the project file. Though
you have to clean a Hugin project file to make it acceptable to the
panotools parser in PToptimizer.
Bruno,
On Thu 06-Jan-2011 at 10:03 -0800, kfj wrote:
Bruno, thank you for your advice. I have started out on a new project
towards the goal of eventually providing a scripting interface for
hugin
I've run into another problem with finding the CP errors here - if I
call the optimizer on the Panorama
Am 06.01.2011 19:03, schrieb kfj:
Bruno, thank you for your advice. I have started out on a new project
towards the goal of eventually providing a scripting interface for
hugin,
that would be really nice! I once tried with boost::python, but I hit
some strange roadblocks, which prevented me
On 4 Jan., 23:52, Bruno Postle br...@postle.net wrote:
Usage: cpclean [options] input.pto
CPClean uses statistical methods to remove wrong control points
Bruno, maybe you can help. You may have noticed my quick-shot Python
script to remove all but the N 'best' CPs for each image
On Wed 05-Jan-2011 at 01:05 -0800, kfj wrote:
On 4 Jan., 23:52, Bruno Postle br...@postle.net wrote:
Usage: cpclean [options] input.pto
CPClean uses statistical methods to remove wrong control points
Bruno, maybe you can help. You may have noticed my quick-shot Python
script to
On Sun, Jan 02, 2011 at 09:37:00AM -0500, Yuval Levy wrote:
More room for scripting experiments. Let me just finish with a remark
I've made over and over: if your lens is well calibrated, you really
don't need that many CPs. Either you use a set with a great number of
CPs to calibrate your
On Sun, Jan 02, 2011 at 09:47:48PM -0500, Yuval Levy wrote:
#-hugin cpWeight s0 a0 w100
Hey, do you see a need for an active-weight-zero control point?
Do you see a need for an inactive weight-not-zero control point?
If you set the weight to zero for control points that are not active,
the
On Sun 02-Jan-2011 at 21:47 -0500, Yuval Levy wrote:
If there are no objections I will updated the specs both in Hugin and in
Libpano to make developers aware of things to come.
There is no need to update the docs until the feature exists, the
implementation often determines the details
On December 29, 2010 01:26:21 pm kfj wrote:
On 29 Dez., 14:09, Rogier Wolff rew-googlegro...@bitwizard.nl wrote:
On Wed, Dec 29, 2010 at 07:42:12AM -0500, Yuval Levy wrote:
Still: I don't think CPs are the ultimate tool for the image
alignment process...
I agree. But what else do we
On 2 Jan., 15:37, Yuval Levy goo...@levy.ch wrote:
currently a CP line in the PTO file looks like:
c n0 N1 x2319.75430140533 y1306.89102657256 X635.409481924115
Y1295.02701452379 t0
what would it take to expand it to:
c n0 N1 x2319.75430140533 y1306.89102657256 X635.409481924115
Kay,
Thanks for the script, it works great! It's helped in speeding up CP
optimization greatly.
--
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:
On 2 Jan., 20:33, kevin ke...@bluelavalamp.net wrote:
Kay,
Thanks for the script, it works great! It's helped in speeding up CP
optimization greatly.
You're welcome! By now my change to pano_trafo has also made it into
the repo, so if you grab the latest code and build it, a version of
On Sun 02-Jan-2011 at 10:38 -0800, kfj wrote:
#-hugin cpWeight s0 a0 w100
AFAIK this is established practice for introducing additional
('noncritical') values into the pto without breaking compatibility
with other pto-using programs.
It is used for Hugin GUI metadata that doesn't materially
On January 2, 2011 01:38:46 pm kfj wrote:
the C parser used by hugin would probably throw a fit
you'll be surprised to know that Hugin took a hand-crafted pto file with s/a/w
parameters without any problem, and ran the optimization as if they were not
there. So from that perspective, we can
On 29 Dez., 00:29, Rogier Wolff rew-googlegro...@bitwizard.nl wrote:
Allow me to add that I really don't think that removing all the far
points is the best way to do this.
Overall you are probably right. I contributed my script for the
specific purpose of Kevin's initial request - he noticed
On Dec 28, 6:25 am, kfj _...@yahoo.com wrote:
If you're happy with Bruno's approach to rather remove a 'bad'
percentage, take that - it's a fine idea as well and it's already
mainstream ;-)
Kay
Thanks for the script! I haven't had a chance to test it out yet, but
I hope to towards the
On 29 Dez., 10:50, kfj _...@yahoo.com wrote:
To facilitate experimentation along these lines,
I'll do the following: In my Python script, I'll provide the set of
control points as a set of objects with more properties than the ones
which can be gleaned from the mere coordinates in the pto.
On December 28, 2010 06:29:17 pm Rogier Wolff wrote:
Throwing [control points] away (well ok, commenting them out) isn't
going to help the pano.
there should be a better way to enable/disable CPs selectively...
You know what I'd like to do? I'd like to assign weights to the
control points.
On Wed, Dec 29, 2010 at 07:42:12AM -0500, Yuval Levy wrote:
On December 28, 2010 06:29:17 pm Rogier Wolff wrote:
Throwing [control points] away (well ok, commenting them out) isn't
going to help the pano.
there should be a better way to enable/disable CPs selectively...
You know
On 29 Dez., 14:09, Rogier Wolff rew-googlegro...@bitwizard.nl wrote:
On Wed, Dec 29, 2010 at 07:42:12AM -0500, Yuval Levy wrote:
... and weighting would help in this and many other cases. For example in
the
past the wish has been expressed to discern between user-generated CPs and
On 27 Dez., 15:14, kevin ke...@bluelavalamp.net wrote:
Would there be a way to delete CPs so that we keep the
top 5 CPs between images?
The script is ready, but it uses a modified version of pano_trafo
(pano_trafo_extended) which you can only have if you compile it from
the source which I've
On December 28, 2010 06:25:53 am kfj wrote:
wait and see if my modifications maybe become mainstream.
I am inclined to add them to the main repository after 2010.4.0 is declared
final. We'll have to see how to integrate neatly in the file tree. I would,
of course, prefer to have the
On 28 Dez., 14:47, Yuval Levy goo...@levy.ch wrote:
On December 28, 2010 06:25:53 am kfj wrote:
wait and see if my modifications maybe become mainstream.
I am inclined to add them to the main repository after 2010.4.0 is declared
final. We'll have to see how to integrate neatly in the
On December 28, 2010 09:36:59 am kfj wrote:
I'm glad you appreciate my contribution
not only me
https://bugs.launchpad.net/hugin/+bug/685489
Yuv
signature.asc
Description: This is a digitally signed message part.
On Tue, Dec 28, 2010 at 12:08:36PM -0500, Yuval Levy wrote:
On December 28, 2010 09:36:59 am kfj wrote:
I'm glad you appreciate my contribution
not only me
https://bugs.launchpad.net/hugin/+bug/685489
Allow me to add that I really don't think that removing all the far
points is the
On 27 Dez., 15:14, kevin ke...@bluelavalamp.net wrote:
For large image panos it'd be nice to delete all CPs except for say
the top 5 between images. So image 125 overlaps with 127, 131, and
142. So after running this type of deletion we'd be left with the
best 5 between 127, the best 5
35 matches
Mail list logo
