Vertical line detector

[T. Modes]

Hi group,

the default branch contains now a vertical line detector. It tries to
generate vertical control points for levelling of the pano. It's using
the roll value in the pto file to define what is "top" and "bottom".
By default it will add maximal 5 control points for each image. It
should also work for fisheye images (the detection happens in the
equirectangular projection). Some first test were successful and
resulted into nicely levelled panos.

It is integrated into the assistant. It can also be started as a
command line tool named linefind (see http://wiki.panotools.org/Linefind
).
For running inside hugin you need to reset the control points detector
settings to default or add manually a setting for linefind (see
http://wiki.panotools.org/Control_Point_Detector_Parameters#Linefind
for parameters)

Thomas

[Terry Duell]

Hullo Thomas,

On Mon, 12 Sep 2011 03:41:59 +1000, T. Modes <Thomas...@gmx.de> wrote:

> Hi group,
>
> the default branch contains now a vertical line detector.

[snip]

> It is integrated into the assistant. It can also be started as a
> command line tool named linefind

Builds and installs OK on Fedora 15 x86_64.
I have tried a couple of projects, and it seemed to work OK.
Only once did it assign points incorrectly, but this didn't seem to upset
the result, perhaps because there were a number of other verticals
identified in other images. On a repeat run with that same project the
spurious vertical was no longer there.
Thanks for your work on this feature.

Cheers,
--
Regards,
Terry Duell

[brian_ims]

Hi Thomas

Just tried to build for Windows using MSVC2008 but get following error:

-- Installing: C:/HUGINbase/hugin_build/INSTALL/FILES/bin/autooptimiser.exe
CMake Error at src/tools/cmake_install.cmake:65 (FILE):
file INSTALL cannot copy file
"C:/HUGINbase/hugin_build/src/tools/Release/autooptimiser.exe" to
"C:/HUGINbase/hugin_build/INSTALL/FILES/bin/autooptimiser.exe".
Call Stack (most recent call first):
src/cmake_install.cmake:35 (INCLUDE)
cmake_install.cmake:99 (INCLUDE)
Project : error PRJ0019: A tool returned an error code from "Performing
Post-Build Event..."
Build log was saved at
"file://c:\HUGINbase\hugin_build\INSTALL.dir\Release\BuildLog.htm"
INSTALL - 1 error(s), 0 warning(s)

My skills are inadequate to sort out how to overcome

Cheers

Brian
--
View this message in context: http://old.nabble.com/Vertical-line-detector-tp32443091p32446851.html
Sent from the hugin ptx mailing list archive at Nabble.com.

[kfj]

On 11 Sep., 19:41, "T. Modes" <Thomas.Mo...@gmx.de> 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 bit
Freier Speicher: -1828108 kiB

Hugin
Version: Pre-Release 2011.3.0.4826832f8d18
Ressourcen-Pfad: /usr/local/share/hugin/xrc/
Datenpfad: /usr/local/share/hugin/data/

Libraries
wxWidgets: 2.8.11.0

... but the result seems strange to me - maybe there's an error? I fed
it a pto with nine images from my stereographic fisheye. It found thre
vertical lines in three different images: (command line output, same
if run from hugin)

$ linefind -o result.pto input.pto

linefind is searching for vertical lines
Working on image IMG_1050.tif
Found 0 vertical lines
Working on image IMG_1051.tif
Found 1 vertical lines
Working on image IMG_1052.tif
Found 0 vertical lines
Working on image IMG_1053.tif
Found 1 vertical lines
Working on image IMG_1054.tif
Found 0 vertical lines
Working on image IMG_1055.tif
Found 0 vertical lines
Working on image IMG_1056.tif
Found 0 vertical lines
Working on image IMG_1057.tif
Found 1 vertical lines
Working on image IMG_1058.tif
Found 0 vertical lines

Written output to result.pto

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.96021470891 t1
c n0 N0 x2851.06479346968 y1874.90595527298 X2843.63811550857
Y2193.76486309095 t1

The use of negative coordinates also seems a bit strange.

Am I missing something?

Kay

[Kornel Benko]

Am Montag, 12. September 2011 schrieb brian_ims:

> Hi Thomas

>

> Just tried to build for Windows using MSVC2008 but get following error:

>

> -- Installing: C:/HUGINbase/hugin_build/INSTALL/FILES/bin/autooptimiser.exe

> CMake Error at src/tools/cmake_install.cmake:65 (FILE):

> file INSTALL cannot copy file

> "C:/HUGINbase/hugin_build/src/tools/Release/autooptimiser.exe" to

> "C:/HUGINbase/hugin_build/INSTALL/FILES/bin/autooptimiser.exe".

> Call Stack (most recent call first):

> src/cmake_install.cmake:35 (INCLUDE)

> cmake_install.cmake:99 (INCLUDE)

> Project : error PRJ0019: A tool returned an error code from "Performing

> Post-Build Event..."

> Build log was saved at

> "file://c:\HUGINbase\hugin_build\INSTALL.dir\Release\BuildLog.htm"

> INSTALL - 1 error(s), 0 warning(s)

>

> My skills are inadequate to sort out how to overcome

I do not have windows, but maybe:

there is no such file as "C:/HUGINbase/hugin_build/src/tools/Release/autooptimiser.exe"

or there exists already the file "C:/HUGINbase/hugin_build/INSTALL/FILES/bin/autooptimiser.exe" and you don't have permission to overwrite

> Cheers

>

> Brian

Kornel

[brian_ims]

Thanks Kornel

For some reason cannot overwrite autooptimiser.exe

Cheers

brian

--
View this message in context: http://old.nabble.com/Vertical-line-detector-tp32443091p32447923.html

[T. Modes]

@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.96021470891 t1
> c n0 N0 x2851.06479346968 y1874.90595527298 X2843.63811550857
> Y2193.76486309095 t1
>
> The use of negative coordinates also seems a bit strange.
>

Both issues are fixed in default branch.


@brian_ims
Kornel is on the right way. Maybe autooptimiser is still running.
Check taskmanager and kill autooptimiser.exe or reboot your system.

Thomas

[kfj]

On 12 Sep., 18:36, "T. Modes" <Thomas.Mo...@gmx.de> 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

[brian_ims]

T. Modes wrote:
>
> @brian_ims
> Kornel is on the right way. Maybe autooptimiser is still running.
> Check taskmanager and kill autooptimiser.exe or reboot your system.
>
>

Hi Thomas

Got it in one - built ok last night now rebuilding with latest update

Cheers
--
View this message in context: http://old.nabble.com/Vertical-line-detector-tp32443091p32454353.html

[kfj]

On 11 Sep., 19:41, "T. Modes" <Thomas.Mo...@gmx.de> 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 single image. If I activate just
one image in the images tab and run any CPG, the CPG is fed all images
instead of just the single one. With most CPGs it is of course futile
to only look at a single image, because, after all, one wants CPS
between several images - the only reason to apply a CPG to a single
image would be for side-effects, like to generate a key file. With
vertical line CPs, it's perfectly sensible to just process one image
from the set, though. 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?

Kay

[T. Modes]

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 which have linefind in
the program name)

Thomas

[kfj]

I suppose new CPGs needing this special treatment won't suddenly turn
up out of the blue in large numbers, so a hack should be perfectly
adequate ;)

It works here. Thanks!

Kay

[Harry van der Wolf]

Hi Thomas,

Just built the 5551. Did 2 panos and linefind works fine on OSX as well. Will do some more tests.

Harry

[Ian Tindale]

Can I have a copy of your built OS X one too, if you can put it up online somewhere? Thanks. 

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

--
Ian Tindale

[Harry van der Wolf]

2011/9/14 Ian Tindale <ian.t...@gmail.com>

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

[Harry van der Wolf]

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 better name).

I have quite some panoramas of landscapes containing trees. I suppose some "edge like"  algorithm is used and with trees that are vertical and quite straight, but not absolutely vertical and not completely straight I get horrible distortions.  This is very obvious in the Assistant.
It requires me to recenter, resize to fit, restraighten and to autocrop again.

So please make this a (default) option that can be switched off.

Harry

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

> 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 better name).

Linefind is integrated into the assistant workflow. I made this step
optional, you can switch it off in the preferences.

Thomas

[Harry van der Wolf]

2011/9/15 T. Modes <Thomas...@gmx.de>

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 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 better name).

Linefind is integrated into the assistant workflow. I made this step
optional, you can switch it off in the preferences.

Thomas

Where is it in Preferences? I can't find it.

Harry

[Harry van der Wolf]

2011/9/15 Harry van der Wolf <hvd...@gmail.com>

OK, I see. A new commit to the trunk. I will sync and build it.

Harry 

[Harry van der Wolf]

Works OK. thanks.

Harry

[kfj]

On 13 Sep., 19:43, "T. Modes" <Thomas.Mo...@gmx.de> wrote:

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
yet again.

As far as linefind itself goes, I have mixed results with it. I am
currently scanning some maps, and they have black border lines and a
separate black framing box, not to mention the UTM grid in thin red
lines. I ran linefeed on the whole set of 15 A4 300 dpi scans, and it
found 8 vertical lines in total, all of which were on the black frame,
and usually very short (few tens of pixels) - it found none of the red
grid lines. Is the detector really a line detector, or more one for
vertical edges, like two planes bordering on each other vertically?
And is there a possibility to also have it scan for horizontal lines?
That would be great for my scans.

Kay

[T. Modes]

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
> yet again.

Fixed again.

> As far as linefind itself goes, I have mixed results with it. I am
> currently scanning some maps, and they have black border lines and a
> separate black framing box, not to mention the UTM grid in thin red
> lines. I ran linefeed on the whole set of 15 A4 300 dpi scans, and it
> found 8 vertical lines in total, all of which were on the black frame,
> and usually very short (few tens of pixels) - it found none of the red
> grid lines. Is the detector really a line detector, or more one for
> vertical edges, like two planes bordering on each other vertically?

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.

> And is there a possibility to also have it scan for horizontal lines?
> That would be great for my scans.

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.

Thomas

[Gnome Nomad]

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 your hack
>> yet again.
>
> Fixed again.
>
>> As far as linefind itself goes, I have mixed results with it. I am
>> currently scanning some maps, and they have black border lines and a
>> separate black framing box, not to mention the UTM grid in thin red
>> lines. I ran linefeed on the whole set of 15 A4 300 dpi scans, and it
>> found 8 vertical lines in total, all of which were on the black frame,
>> and usually very short (few tens of pixels) - it found none of the red
>> grid lines. Is the detector really a line detector, or more one for
>> vertical edges, like two planes bordering on each other vertically?
>
> 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.

>
>> And is there a possibility to also have it scan for horizontal lines?
>> That would be great for my scans.
>
> 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 set of "horizontal" lines identified as
vertical lines?

--
Gnome Nomad
gnome...@gmail.com
wandering the landscape of god
http://www.cafepress.com/otherend/

[kfj]

On 17 Sep., 19:10, Gnome Nomad <gnomeno...@gmail.com> 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 set of "horizontal" lines identified as
> vertical lines?

Well, yes. But if I have to go to the length of rotating the images 90
degrees (easy in hsi), I might as well do that before I scan for
verticals and run a simple find-and-replace on the CP type field in
the pto after the horizontals are found. It's even quite feasible to
write a little python script as a go-between - see my cpg_glue script
at

http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/cpg_glue.py

which does the two linefind calls etc.

Kay

[Gnome Nomad]

That would fix it. Perhaps an option in Hugin to look for vertical lines
(run linefind with images as they are) or horizontal lines (rotate
images, then run linefind, followed by changing each found "horizontal"
line to "vertical". Be more convenient than running a script.

[Harry van der Wolf]

Hi Thomas,

2011/9/17 T. Modes <Thomas...@gmx.de>

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 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.cpp. Could it be done with some coordination changes in the algorithms to make them search for horizontal lines?

Harry

[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 and structures inside
> findlines.cpp. Could it be done with some coordination changes in the
> algorithms to make them search for horizontal lines?

That is possible. But the question is: for which application this
feature is necessary? For generating a "normal" panorama the detection
of horizontal lines would only help if there is a defined horizon or
the projection is rectilinear. For all other projection there is
maximal one horizontal line - the horizon - adding horizontal lines
will result in the case often in distortions.

I can imagine, that it helps for correcting perspective distortions,
but this is also limited to the rectilinear projection.

Thomas

[kfj]

On 18 Sep., 10:51, "T. Modes" <Thomas.Mo...@gmx.de> 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 lines" functions and structures inside
> > findlines.cpp. Could it be done with some coordination changes in the
> > algorithms to make them search for horizontal lines?
>
> That is possible. But the question is: for which application this
> feature is necessary?

Just one example: I've done panoramas of dams, and the only really
reliable lines were along the banisters. When I manually set
horizontal CPs on them, they made my pano perfectly level. The few
verticals I had were short, few and unreliable (lampposts). And while
we're at it - why not support lines which are neither horizontal nor
vertical? There is a CP type for them, and they can be very helpful -
plus, they can contain more than just two image points, which makes
them ideal for nudging bits from several images to a common line (I've
used them to good effect when stitching mosaics of scans of large
images). So if the line CPG detects a very long straight edge, it
might output a line cp with points every few hundred pixels. All of
this is supposing, of course, that the detector is taking into account
the input's projection - e.g. in my dam case it's stereographic, so
only lines through the center are straight, just where they're worst-
suited for levelling the panorama (if I remember correctly, it's best
to have two vertical line CPs near the left or right margin of an
image)

> For generating a "normal" panorama the detection
> of horizontal lines would only help if there is a defined horizon or
> the projection is rectilinear. For all other projection there is
> maximal one horizontal line - the horizon - adding horizontal lines
> will result in the case often in distortions.

This implies linefind is working on the source images, instead of
reprojected source images. This wouldn't be good news for fisheye
users. If I understand hugin's ways right, vericality/horizontality is
refering to the points when transformed to equirect (so, the
optimization is done in pano space) - 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
scene but may not project to horizontal because of perspective), no
matter where they are, so every horizontal can be helpful

Kay

[kfj]

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
> scene but may not project to horizontal because of perspective)

... oops - tahat's nonesense. You're right, Thomas, horizontal remain
horizontal only in rectilinear, or otherwise on the horizon itself.

Kay

[Harry van der Wolf]

2011/9/18 T. Modes <Thomas...@gmx.de>

You are right. I was just thinking further along the line of "what is possible". However, in case you really want to correct perspective distortions in buildings or so, the image is such that you want to do it by hand anyway (at least most of the time).

Harry

[Jeffrey Martin]

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 what i mean.

additionally, these panos are really hard for anyone to level, unless they deeply understand stitching software....

i didn't have a chance to try this vertical line detector yet but i'm very intrigued :) i'll try it soon! Thanks Thomas for helping to make it a reality :) :)

Jeffrey

[Jeffrey Martin]

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

[Battle]

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 realize I'm over simplifying things, but its
not a new invention, but an adaption of an existing one. I probably
don't have the programming skills to help, but I would like to see the
extension of the vertical line find to horizontal as 99& of what I do
is rectilinear projections of architecture.

Battle

[Emad ud din Bhatt]

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? 

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

--


Emaad
www.flickr.com/emaad

[Bruno Postle]

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 the
'vertical control points' to 'horizontal'.

This doesn't solve the fundamental problem: vertical lines are
parallel, but horizontal lines generally are not - This is why
horizontal control points have very limited use for levelling
panoramas.

The case of straightening an elevation of a building is an
exception. For this someone can write a switch for linefind that
enables detection of horizontal lines in panoramas with FoV <180°,
but it still shouldn't be the default in Hugin.

--
Bruno

[Ian Adam]

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. Photography involves a lot of tilting the camera at very steep angles!

My best effort so far was to move along the building taking photos in portrait format, 1 low and 1 high in each location. Hugin does avery good job but gets defeated by the serious curves on the verticals. It also gets very confused by the parts of the building that are invisible on one shot but visible on the next.

I would be very grateful for any comments, suggestions or criticisms.

Thank you

Ian

--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com

To unsubscribe from this group, send email to hugin-ptx+unsubscribe@googlegroups.com

[Robert Krawitz]

On Wed, 2 Nov 2011 20:04:03 +0000, 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 again?
>
> Yes (or roll), but you would have to manually change all the
> 'vertical control points' to 'horizontal'.
>
> This doesn't solve the fundamental problem: vertical lines are
> parallel, but horizontal lines generally are not - This is why
> horizontal control points have very limited use for levelling
> panoramas.

I don't understand this -- usually one wants a level horizon?

--
Robert Krawitz <r...@alum.mit.edu>

Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- http://ProgFree.org
Project lead for Gutenprint -- http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[JohnPW]

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 by a slightly
misaligned horizon and it can estimated and adjusted without
difficulty. The manmade environment, where most pictures are taken, is
positively chock full of obviously vertical and horizontal lines. When
all these cues do not align properly it is can be offensively obvious
and discordant, so you want them to be properly aligned. in a
rectilinear projection, only a vertical line always appears vertical
and straight (like the longitude lines on a globe.) The only
horizontal line that is level and straight is the horizon (which
really isn't a line at all since it's theoretical projection and is
actually a huge circle. All the truly straight, non vertical lines
actually appear slightly curved, to a greater or lesser extent. The
only horizontal lines that appear close to straight are on objects
that directly face the viewer, and only those that happen to be
coincident with the horizon, and these only over a short distance.
(Sorry if I have misunderstood and I'm stating the obvious to you.)

I suppose the proposed new Apple Inc. campus building (which will be
huge and round with a round courtyard in the middle) would offer an
opportunity to use horizontals for alignment. :-)
http://theinspirationroom.com/daily/design/2011/8/apple_city_rendering_1.jpg

On Nov 2, 9:18 pm, Robert Krawitz <r...@alum.mit.edu> wrote:
> On Wed, 2 Nov 2011 20:04:03 +0000, 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 again?
>
> > Yes (or roll), but you would have to manually change all the
> > 'vertical control points' to 'horizontal'.
>
> > This doesn't solve the fundamental problem: vertical lines are
> > parallel, but horizontal lines generally are not - This is why
> > horizontal control points have very limited use for levelling
> > panoramas.
>
> I don't understand this -- usually one wants a level horizon?
>
> --
> Robert Krawitz                                     <r...@alum.mit.edu>
>

> Tall Clubs International  --  http://www.tall.org/or 1-888-IM-TALL-2

[Robert Krawitz]

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 situations like
> landscapes, the viewer's senses are not greatly offended by a slightly
> misaligned horizon and it can estimated and adjusted without
> difficulty. The manmade environment, where most pictures are taken, is
> positively chock full of obviously vertical and horizontal lines. When
> all these cues do not align properly it is can be offensively obvious
> and discordant, so you want them to be properly aligned. in a
> rectilinear projection, only a vertical line always appears vertical
> and straight (like the longitude lines on a globe.) The only
> horizontal line that is level and straight is the horizon (which
> really isn't a line at all since it's theoretical projection and is
> actually a huge circle. All the truly straight, non vertical lines
> actually appear slightly curved, to a greater or lesser extent. The
> only horizontal lines that appear close to straight are on objects
> that directly face the viewer, and only those that happen to be
> coincident with the horizon, and these only over a short distance.
> (Sorry if I have misunderstood and I'm stating the obvious to you.)

I ask because I took a panorama from a tower in Provincetown, MA, at
the tip of Cape Cod. About 3/4 of the horizon from that spot is the
ocean, and a misalignment of 1 pixel was very apparent; I had to
correct it by editing the final output.

[JohnPW]

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 accuracy. As
they get closer to 180º apart the effect of minor errors in point
placement is amplified, just as it would be by placing them closer to
0º apart.
Was this at Long Point Light or were you up on a communications tower?

[JohnPW]

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!

[Robert Krawitz]

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
> apart (with very wide angle images) produces diminishing accuracy. As
> they get closer to 180º apart the effect of minor errors in point
> placement is amplified, just as it would be by placing them closer to
> 0º apart.

One would think it would be simple, but it wasn't. There was one
error of about 1 pixel I was never able to get rid of, and I had to
play some games in GIMP to clean it up to my satisfaction. Even 1
pixel error is very noticeable for something like the sky-sae interface.

> Was this at Long Point Light or were you up on a communications tower?

Provincetown Monument. See
http://rlk.smugmug.com/Other/Landscapes/4851912_XB4SmT/1079379016_sm6Jy
(the monument itself is
http://rlk.smugmug.com/Travel/Provincetown-MA-October-2010/14616061_32XQRG/1087222681_A2kfU).

[JohnPW]

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.)
It was my first 360º panorama and I wasn't sure it would work since I
took it from the outer catwalk, but I figured the closest objects were
far enough away that it wouldn't be a problem. It wasn't that great
(3.5Mp jpegs, no fusion or TCA correction etc., but this was a few
years ago and my colleagues (who had never seen stitched panos before)
were amazed and perplexed by how I got "such nice images" using a
little digital point and shoot (although the results would probably
not be acceptable to anyone in this forum.) I stitched them together
with well aged Apple QTVR Studio Software running on system 7 via
Rosetta on a G3 PowerMac. Although the whole western sky was blown
out, I was actually pleasantly surprised myself. I should go back and
run it through Hugin. I'm sure there would be a little noticeable
improvement.

> (the monument itself ishttp://rlk.smugmug.com/Travel/Provincetown-MA-October-2010/14616061_3...).

[Robert Krawitz]

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
> top of the Cape Lookout Light (not even remotely as nice as yours
> though.)

> It was my first 360ş panorama and I wasn't sure it would work since I

> took it from the outer catwalk, but I figured the closest objects were
> far enough away that it wouldn't be a problem. It wasn't that great
> (3.5Mp jpegs, no fusion or TCA correction etc., but this was a few
> years ago and my colleagues (who had never seen stitched panos before)
> were amazed and perplexed by how I got "such nice images" using a
> little digital point and shoot (although the results would probably
> not be acceptable to anyone in this forum.) I stitched them together
> with well aged Apple QTVR Studio Software running on system 7 via
> Rosetta on a G3 PowerMac. Although the whole western sky was blown
> out, I was actually pleasantly surprised myself. I should go back and
> run it through Hugin. I'm sure there would be a little noticeable
> improvement.

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 bars getting in the way. It's fortunate that I have an 8-16
mm lens; I don't think even a 10 or 11 mm lens would have provided
enough overlap for a good stitch and a 12 mm lens probably wouldn't
have been wide enough, period. I did have to fix some things up by
hand where the parallax error was too great (the parking lot at the
bottom had some problems that I had to fix manually, in addition to
the horizon problem I mentioned earlier).

I actually generally do use JPEGs, and I haven't done TCA correction
or predefined lens models (which are likely to be accurate only at one
particular focal length, anyway). And all too often I do them
hand-held. But when I look at my panoramas, I generally don't see a
lot of TCA problems. As for RAW vs. JPEG, the 7D does a very good job
of in-camera processing. If the light's such that I'm going to have
serious dynamic range problems, I probably need more than the
additional one or two stops I'll get from my own RAW processing. The
P-town panorama, for example, did have dynamic range problems, but
simple exposure bracketing and fusion worked very well.

For this one:

http://rlk.smugmug.com/Other/Landscapes/4851912_XB4SmT/1488875261_xzm3Fzn

I really did have to use RAW, though (and fix up a lot of sky by hand,
also).

There is one little trick I sometimes play that I haven't seen
mentioned anywhere to reduce the aspect ratio and get more foreground
detail. With wide angle lenses, the final output is somewhat torpedo
or barrel shaped due to the projection onto a planar surface. I make
a second pass with Hugin, treating the first stage panorama as having
been shot by a cylindrical lens (like a Spinshot camera) of between 20
and 35 mm focal length and then re-projecting it as rectilinear, which
applies a pincushion effect.

Panorama stitching really is a lot of fun.

[JohnPW]

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 <r...@alum.mit.edu> 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 bars getting in the way.  It's fortunate that I have an 8-16
> mm lens; I don't think even a 10 or 11 mm lens would have provided
> enough overlap for a good stitch and a 12 mm lens probably wouldn't
> have been wide enough, period.  I did have to fix some things up by
> hand where the parallax error was too great (the parking lot at the
> bottom had some problems that I had to fix manually, in addition to
> the horizon problem I mentioned earlier).
>
> I actually generally do use JPEGs, and I haven't done TCA correction
> or predefined lens models (which are likely to be accurate only at one
> particular focal length, anyway).  And all too often I do them
> hand-held.  But when I look at my panoramas, I generally don't see a
> lot of TCA problems.  As for RAW vs. JPEG, the 7D does a very good job
> of in-camera processing.  If the light's such that I'm going to have
> serious dynamic range problems, I probably need more than the
> additional one or two stops I'll get from my own RAW processing.  The
> P-town panorama, for example, did have dynamic range problems, but
> simple exposure bracketing and fusion worked very well.

-- I have no choice but to use jpeg on my Nikon CP4500 (Tiff isn't
really a reasonable choice time wise and the camera has no RAW.)

> For this one:
>
> http://rlk.smugmug.com/Other/Landscapes/4851912_XB4SmT/1488875261_xzm...

>
> I really did have to use RAW, though (and fix up a lot of sky by hand,
> also).
>
> There is one little trick I sometimes play that I haven't seen
> mentioned anywhere to reduce the aspect ratio and get more foreground
> detail.  With wide angle lenses, the final output is somewhat torpedo
> or barrel shaped due to the projection onto a planar surface.  I make
> a second pass with Hugin, treating the first stage panorama as having
> been shot by a cylindrical lens (like a Spinshot camera) of between 20
> and 35 mm focal length and then re-projecting it as rectilinear, which
> applies a pincushion effect.

-- I'd have to see to understand (my fault not yours.) Perhaps you
should make a tutorial? :-)