So how do folks do their "hand adjustments?" . . .
[I guess I should start a new topic for this.]
On Nov 3, 12:47 pm, Robert Krawitz wrote:
> I had the same problem on the Pilgrim monument. There are only four
> spots, at the center of each side, where there's a clear view without
> glass and ba
On Thu, 3 Nov 2011 09:35:04 -0700 (PDT), JohnPW wrote:
> Ah the Pilgrim monument. I haven't been there.
> Very nice panoramas. They all look very well done to me. You clearly
> have very high production standards.
Thanks!
> When I was working for the NPS I did a similar style panorama from the
>
Ah the Pilgrim monument. I haven't been there.
Very nice panoramas. They all look very well done to me. You clearly
have very high production standards.
When I was working for the NPS I did a similar style panorama from the
top of the Cape Lookout Light (not even remotely as nice as yours
though.)
On Thu, 3 Nov 2011 07:06:01 -0700 (PDT), JohnPW wrote:
> Well that's one of those easy situations.
> When you can see the horizon clearly like that, horizontal CPs
> distributed about the pano on the horizon should give you great
> results. Contrary to how one might casually think, placing them far
BTW my sig would have to be more like
Unix doesn't dictate how I work, it dictates how I don't work (but
only when I consciously try to use it.)
;-) I love that it's there, but I like having that Aqua interface
softening the ride!
--
You received this message because you are subscribed to the Goo
Well that's one of those easy situations.
When you can see the horizon clearly like that, horizontal CPs
distributed about the pano on the horizon should give you great
results. Contrary to how one might casually think, placing them far
apart (with very wide angle images) produces diminishing accur
On Wed, 2 Nov 2011 22:57:08 -0700 (PDT), JohnPW wrote:
> If I don't misunderstand your post . . .
> Yes, one wants a level horizon, but the horizon is an imaginary line
> and is only evident in certain perfect situations without obstructions
> (flat desert, seascape, etc.) In most natural situation
If I don't misunderstand your post . . .
Yes, one wants a level horizon, but the horizon is an imaginary line
and is only evident in certain perfect situations without obstructions
(flat desert, seascape, etc.) In most natural situations like
landscapes, the viewer's senses are not greatly offended
On Wed, 2 Nov 2011 20:04:03 +, Bruno Postle wrote:
> On Wed 02-Nov-2011 at 11:47 +0500, Emad ud din Bhatt wrote:
>> can we use vertical line detector by Setting equirect pitch to 90
>> degree and than call vertical line detector. Than set pano pitch
>> to -90 and call vertical line detector a
Greetings all, I'm new here.
This is all very interesting to me. My project at the moment is to
photograph the school where I work, parts of which can be seen here:
http://www.i-magz.com/thomas-more.html
In front of the school is a strip of grass, then a narrow road, then a
thick row of trees. Phot
On Wed 02-Nov-2011 at 11:47 +0500, Emad ud din Bhatt wrote:
can we use vertical line detector by Setting equirect pitch to 90
degree and than call vertical line detector. Than set pano pitch
to -90 and call vertical line detector again?
Yes (or roll), but you would have to manually change all
can we use vertical line detector by Setting equirect pitch to 90 degree
and than call vertical line detector. Than set pano pitch to -90 and call
vertical line detector again?
On Fri, Oct 28, 2011 at 7:09 PM, Battle wrote:
> I'll reiterate Thomas' comments. I do a lot of buildings. I would
I'll reiterate Thomas' comments. I do a lot of buildings. I would
like horizontal and vertical line detectors. Seems like it ought to
be a simple programming loop that would reuse existing vertical line
feature search on a 90 degree rotated basis calling them horizontal
instead of vertical. I r
I'm bringing this thread up again...
Does anyone find the possibility of a "horizon detector" interesting, for
cases where there are not vertical lines, but there is a horizon? This
would help to automatically level more panos
Jeffrey
--
You received this message because you are subscr
Still, there is certainly use for a *horizon* detector.
in many panos there is water - the ocean - and no vertical lines.
here, the only way to level the pano is to set this horizon line.
this is not an edge case - this is a really big case :) if you check some
panos on 360cities you'll see wha
2011/9/18 T. Modes
> Hi
>
> > (A view from a non-programming user):
> > Isn't it possible to make linefind a "two-step" edge detector. First
> search
> > for vertical lines, then "rotate" the algorithm itself and search for
> > horizontal lines.
> > I see that you have "vertical lines" functions
On 18 Sep., 11:16, kfj <_...@yahoo.com> wrote:
> and in equirect all horizontal
> lines come out horizontal (to be more precise, I'm talking about lines
> which in a perfect equirect or rectilinear or cylindrical projection
> would appear horizontal, not merely lines which are horizontal in the
>
On 18 Sep., 10:51, "T. Modes" wrote:
> Hi
>
> > (A view from a non-programming user):
> > Isn't it possible to make linefind a "two-step" edge detector. First search
> > for vertical lines, then "rotate" the algorithm itself and search for
> > horizontal lines.
> > I see that you have "vertical
Hi
> (A view from a non-programming user):
> Isn't it possible to make linefind a "two-step" edge detector. First search
> for vertical lines, then "rotate" the algorithm itself and search for
> horizontal lines.
> I see that you have "vertical lines" functions and structures inside
> findlines.cp
Hi Thomas,
2011/9/17 T. Modes
>
> It's an edge detector. The same as in calibrate_lens_gui.
> If it would consider only parallel lines, it would not handles
> perspective distortion (stürzende Linien in German) correctly.
>
>
(A view from a non-programming user):
Isn't it possible to make linefi
kfj wrote:
On 17 Sep., 19:10, Gnome Nomad wrote:
It reports only vertical lines.
But there is a workaround: Run linefind to find vertical lines. Then
change the roll value of all images to 90 (or -90) and run linefind
again. This will find the horizontal lines.
Then wouldn't that leave the s
On 17 Sep., 19:10, Gnome Nomad wrote:
> > It reports only vertical lines.
> > But there is a workaround: Run linefind to find vertical lines. Then
> > change the roll value of all images to 90 (or -90) and run linefind
> > again. This will find the horizontal lines.
>
> Then wouldn't that leave
T. Modes wrote:
Hi Kay,
Sorry to keep pestering you about it, but if no images are selected in
the images tab and you click to use linefind, it looks at no images -
rather than at all images, which is the default behaviour with all
other CPGs if no images are selectd. So maybe you can modify yo
Hi Kay,
> Sorry to keep pestering you about it, but if no images are selected in
> the images tab and you click to use linefind, it looks at no images -
> rather than at all images, which is the default behaviour with all
> other CPGs if no images are selectd. So maybe you can modify your hack
> y
On 13 Sep., 19:43, "T. Modes" wrote:
> Hi Kay,
>
> > So my issue is with hugins's interaction with
> > this specific CPG rather than with the CPG itself. I wonder if this
> > wouldn't be easy to fix for someone who's inside the code?
>
> added special handling for linefind to work with single im
2011/9/15 Harry van der Wolf
>
>
> 2011/9/15 Harry van der Wolf
>
>>
>>
>> 2011/9/15 T. Modes
>>
>> Hi Harry,
>>>
>>> > I have observed now that vertical linefind is an integral part of
>>> cpfind.
>>>
>>> That's wrong. Linefind is an own program and not integrated into
>>> cpfind.
>>>
>>
>> So
2011/9/15 T. Modes
> Hi Harry,
>
> > I have observed now that vertical linefind is an integral part of cpfind.
>
> That's wrong. Linefind is an own program and not integrated into
> cpfind.
>
So I thought but it seemed not from the output.
>
> > I don't like that very much as it actually distu
2011/9/15 Harry van der Wolf
>
>
> 2011/9/15 T. Modes
>
> Hi Harry,
>>
>> > I have observed now that vertical linefind is an integral part of
>> cpfind.
>>
>> That's wrong. Linefind is an own program and not integrated into
>> cpfind.
>>
>
> So I thought but it seemed not from the output.
>
>
>>
Hi Harry,
> I have observed now that vertical linefind is an integral part of cpfind.
That's wrong. Linefind is an own program and not integrated into
cpfind.
> I don't like that very much as it actually disturbs some panorama's. I think
> it should be an option, be it a default option.But is sh
Hi Thomas,
I have observed now that vertical linefind is an integral part of cpfind. I
don't like that very much as it actually disturbs some panorama's. I think
it should be an option, be it a default option.But is should be possible to
do without, something like "--noverticallinefind" (or a bett
2011/9/14 Ian Tindale
> Can I have a copy of your built OS X one too, if you can put it up online
> somewhere? Thanks.
>
>
>
Tonight I will put it on my website as usual.
Harry
--
You received this message because you are subscribed to the Google Groups
"Hugin and other free panoramic softwar
Can I have a copy of your built OS X one too, if you can put it up online
somewhere? Thanks.
On 13 September 2011 20:06, Harry van der Wolf wrote:
> Hi Thomas,
>
> Just built the 5551. Did 2 panos and linefind works fine on OSX as well.
> Will do some more tests.
>
> Harry
>
> --
> You receive
Hi Thomas,
Just built the 5551. Did 2 panos and linefind works fine on OSX as well.
Will do some more tests.
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:
On 13 Sep., 19:43, "T. Modes" wrote:
> Hi Kay,
>
> > So my issue is with hugins's interaction with
> > this specific CPG rather than with the CPG itself. I wonder if this
> > wouldn't be easy to fix for someone who's inside the code?
>
> added special handling for linefind to work with single im
Hi Kay,
> So my issue is with hugins's interaction with
> this specific CPG rather than with the CPG itself. I wonder if this
> wouldn't be easy to fix for someone who's inside the code?
added special handling for linefind to work with single image.
(It's more like a hack, it works only for cpg w
On 11 Sep., 19:41, "T. Modes" wrote:
> Hi group,
>
> the default branch contains now a vertical line detector. It tries to
> generate vertical control points for levelling of the pano.
I have another slight issue with linefind. When I use it from hugin,
sometimes I want it to look only at a singl
On 12 Sep., 18:36, "T. Modes" wrote:
> @Kay
>
> Both issues are fixed in default branch.
Thanks for the quick fix. All is well this end now and the program
seems to be doing exactly what it's supposed to do. Thumbs up!
Kay
--
You received this message because you are subscribed to the Google
@Kay
> but in the resulting pto file, result.pto, all three vertical CPs are
> assigned to image number zero:
>
> # control points
> c n0 N0 x2847.22729509834 y2096.36641460524 X2851.72865032147
> Y2405.76855173728 t1
> c n0 N0 x-2.47460425806207 y2128.94518372973 X-3.35545983791303
> Y2407.960214
On 11 Sep., 19:41, "T. Modes" wrote:
> Hi group,
>
> the default branch contains now a vertical line detector. It tries to
> generate vertical control points for levelling of the pano.
> ...
Compiles, integrates and runs here:
Betriebssystem: Linux 2.6.38-11-generic-tuxonice i686
Architektur: 32
39 matches
Mail list logo