new projection: architectual

[Daniel M German]

hi Yuv, and everybody else

I just committed a simple, but I think useful projection. I call it
architectural. Try it with an indoor pano. Top half is miller (which
is almost conformal), bottom is lambert equal area. It presumes the
space around you (in the bottom half of the pano) is less important
than the space above the horizon.

--dmg

[Yuv]

Hi everybody,

Thanks, Daniel.

This should be a good exercise for somebody who want to try my new
tutorial:
<http://panospace.wordpress.com/2008/12/30/vedutismo/>

preprequisites: a computer with about 1GB RAM and ten fingers :-)
works best on Ubuntu or other Linuxes, but should do well on OS X as
well, and on Windows there are similar tools mentioned.

Yuv

[Daniel German]

On Mon, Dec 29, 2008 at 4:50 PM, Yuv <goo...@levy.ch> wrote:
>
> Hi everybody,
>
> Daniel M German wrote:
>> I just committed a simple, but I think useful projection. I call it
>> architectural. Try it with an indoor pano. Top half is miller (which
>> is almost conformal), bottom is lambert equal area. It presumes the
>> space around you (in the bottom half of the pano) is less important
>> than the space above the horizon.
>
> Thanks, Daniel.

Thanks to Bruno and Tom who were took the time to teach me how the projection
is computed.

Now, regarding hugin. Some time ago I modified libpano to report the projections
available to hugin. The idea was that hugin does not need to hard code the
projections, but rather can query them from libpano. This meant that
you just need to recompile, install libpano and the new projections
are available.

Isn't that the case any more? The function that reports all data about
a projection is
query_feature, I think.

--dmg

[Pablo d'Angelo]

Daniel German schrieb:

>
> Now, regarding hugin. Some time ago I modified libpano to report the projections
> available to hugin. The idea was that hugin does not need to hard code the
> projections, but rather can query them from libpano. This meant that
> you just need to recompile, install libpano and the new projections
> are available.
>
> Isn't that the case any more? The function that reports all data about
> a projection is
> query_feature, I think.

In principle, that is used, however, there are some problems with the
heuristics used to do the FOV computations and the fast preview. I'd
have to do a deeper check if that could be abstracted out of hugin and
placed into libpano as well.

ciao
Pablo

[Jim Watters]

I have committed some changes to libpano13 that
added mirror, equisolid, orthographic, and stereographic as input
image formats
added or update equisolid, orthographic, stereographic as output
panorama formats
add some more defines to panorama.h to help image and pano formats
updated comments and documentation to help adding more projections and
using the new ones.

The equisolid and orthographic, and stereographic projections came from
the work Helmut Dersch was doing with the Motion Panoramas
http://webuser.hs-furtwangen.de/~dersch/ project he was working on.

I did NOT manage to convert the equations without error into a format
for libpano13.
Panotools can create stereographic, but I don't have test images of the
other formats to verify correct implementation.

I have been holding onto this code for almost a year. It seamed like
the right time to commit it. With this resent changes there will be
someone familiar with the code to spot the problem and fix. I hope. :)

Equisolid, orthographic, and stereographic are all kinds of fisheye
projection. Some fisheye lenes optics are better suited using one of
these projections.
Mirror should help creating panos from mirror balls
http://wiki.panotools.org/Spherical_mirror_panorama

--
Jim Watters

Yahoo ID: j1vvy ymsgr:sendIM?j1vvy
jwatters @ photocreations . ca
http://photocreations.ca

[Yuval Levy]

Jim Watters wrote:
> I have committed some changes to libpano13

hugin now quits with

hugin: queryfeature.c:429: panoProjectionFeaturesQuery: Assertion `0'
failed.
Aborted

I look at queryfeature.c before line 429 is the
panoProjectionFeaturesQuery function and I don't see your new
projections there.

Yuv

[Yuval Levy]

around line 400, after

case PANO_FORMAT_FISHEYE_FF:

add:

case PANO_FORMAT_ORTHOGRAPHIC:
case PANO_FORMAT_EQUISOLID:

sorry, I have no SVN access to contribute this fix.

Yuv

[Yuval Levy]

and: around line 95, PanoType14 and Panotype15 should read Orthographic
and Equisolid, not Architectural...

Yuv

[Jim Watters]

Thanks.  I made the corrections.

[Yuval Levy]

Jim Watters wrote:
> Thanks. I made the corrections.

Thanks, all works fine.

In Hugin (I will committ to SVN soon) all the new projections are
available and render well. The options in the stitcher tab may require
some fine tuning (e.g. the calculation of optimal size) and the fast
preview is quirky with Panini (try dragging). With Orthographic and
Equisolid it has difficulty at the extreme (360°).

Is queryfeature.c documented?

while waiting for hugin to build I looked at it and noticed that some
projections are mentioned in "LensType" while others, particularly the
new ones, are not. And then there are those commented out, whose
numbering is not consistent with "PanoType".

Do I understand correctly that LensType is the input projection and
PanoType the output projection?

And: queryfeature.c mentions the anti-aliasing filters. How difficult
would it be to access them from hugin?

Yuv

[Daniel German]

hi Jim,

Please don't take this as a criticism.

I think committing this many additions of features in a single commit
is too risky,
and you have mentioned that they are not very well tested. In my
opinion it is better
to commit one "task" at a time, so each can be isolated and debugged
independently
of each other.

Why don't we roll back your changes and introduce one change at a time?
We could also use a branch for those features that are not totally tested
(the input projections).


--dmg

--
--dmg

---
Daniel M. German
http://turingmachine.org

[Yuv]

Jim Watters wrote:
> added mirror ... as input image formats

I just realize this. Are these the "donuts" that we see from mirrors
like http://www.0-360.com/ ?

how do we add this to hugin?

I had one of these mirrors on the shelve for the last three years. And
I have an adapter to put it in front of my camcorder...

Yuv

[Yuval Levy]

Daniel German wrote:
> In my opinion it is better to commit one "task" at a time, so each
> can be isolated and debugged independently of each other.

atomic commits are a good practice indeed and your advice is very
valuable for future commits.

> Why don't we roll back your changes and introduce one change at a time?

for this specific case I am against a rollback. I've built everything in
Ubuntu and what I have tested works well and I did not find any serious
regression / broken things. I am looking for how to test the mirror
input projection, but I am afraid it will have to wait to next week as I
am away from the mirror itself.

> We could also use a branch for those features that are not totally tested
> (the input projections).

branches are a great tool, and so are tags. IMO tags are the tool to use
to mark points in time when SVN is more robust and stable than
experimental. New features can and should be added with little testing
to trunk to encourage experimentation. A branch would have made sense
for this case during the months in which the code for Jim's recent
commit was piling up. But at some point, branches needs to get back to
trunk. The sooner the better.

my 2 cents
Yuv

[Daniel M German]

Yuval Levy twisted the bytes to say:

>> We could also use a branch for those features that are not totally tested
>> (the input projections).

Yuval> branches are a great tool, and so are tags. IMO tags are the tool to use
Yuval> to mark points in time when SVN is more robust and stable than
Yuval> experimental. New features can and should be added with little testing
Yuval> to trunk to encourage experimentation. A branch would have made sense
Yuval> for this case during the months in which the code for Jim's recent
Yuval> commit was piling up. But at some point, branches needs to get back to
Yuval> trunk. The sooner the better.

Ok, let us leave it as is.

--dmg

[paul womack]

Yuval Levy wrote:
>> We could also use a branch for those features that are not totally tested
>> (the input projections).
>
> branches are a great tool, and so are tags. IMO tags are the tool to use
> to mark points in time when SVN is more robust and stable than
> experimental. New features can and should be added with little testing
> to trunk to encourage experimentation. A branch would have made sense
> for this case during the months in which the code for Jim's recent
> commit was piling up. But at some point, branches needs to get back to
> trunk. The sooner the better.

For anyone using a source control system, I would strongly
recommend reading this:

http://www.cmcrossroads.com/bradapp/acme/branching/

It has some excellent (and source control system
agnostic) overview of various strategies.

BugBear