Tlalli - Revision history

Erik Krause: glossaryfied

2007-12-15T17:06:47Z

glossaryfied

Erik Krause: categorized

2007-03-28T12:28:19Z

categorized

WikiSysop: added link, but what category? [Software:Library]?

2007-03-28T11:54:25Z

added link, but what category? [Software:Library]?

Erik Krause: typos

2007-03-23T22:39:09Z

typos

Dmgerman at 22:24, 23 March 2007

2007-03-23T22:24:09Z

Dmgerman at 22:23, 23 March 2007

2007-03-23T22:23:41Z

New page

Tlalli is a recent fork of Panotools that wants to focus in the remapping part
of panorama generation as opposed to the registration.

I beleive that panotools should be divided (at least from an architectural point of view)
into 2 main parts: optimization and the projection (there is a third module, which involved
projection computions, that needs to be used by both modules).

The separation of projection from optiization is probably best exemplified by Flexify, which takes an
equirectangular (I haven't use it yet, so this is my understanding)
and produces an output image after it has applied a
transformation. FLexify does not need to know anything about
registration and optimization.

What I am proposing here is a "programmable flexify", or a super
math-map. This is the direction where I want to take Tlalli.

Let me elaborate:

The current transformation model, for an equirectangular as input, is
a computation for each pixel in the output image. That is, given an
image I, a list of optional parameters, compute its projection I':

I' = f(I, [p])

What if we have two fs, and compose them?

For instance, the output of one projection is used for another
projection:

I'' = g(f(I,[p]), [p'])

This only makes sense if the output of f is compatible with the input
of g. For example, compute the Cassini of an equirectangular (rolling
it by 90 degrees), and then compute the Mercator of the Cassini; the
result is a transverse mercator. We have implemented transverse
mercator as a composition of rolling the equirectangular +
mercator. Think of the possibilities.

In the current computational model this is done in steps: Generate I'
then apply g on I'. There are two disadvantages to this model:

* Error increases
* I/O operations are proportional to the number of functions.

What I envision is a system that will allow me to add my own functions
to the computational stack, in the same way that layers work in
Photoshop. So the composition happens at the pixel level, not the
image level.

For example, if you like to have your logo in the nadir, the you can
create a function "Logo" that you insert into the computational stack.
This function can take as a parameter a string. Then when the panorama
is projected/computed, the logo is inserted right on the spot.

If the architecture is open enough, this can lead to "plugin
functions" that do things we can't even imagine today. We will only
require the developer to create a function with certain properties,
and register it.

This system will be very powerful and useful beyond panoramas.

@@ Line 1: / Line 1: @@
-Tlalli is a recent fork of [[Panotools]] that wants to focus in the [[remapping]] part
+Tlalli is {{Glossary|a recent fork of [[Panotools]] that wants to focus in the [[remapping]] part
-of panorama generation as opposed to the [[registration]].
+of panorama generation as opposed to the [[registration]]|1}}.
 The homepage of this project is http://www.tlalli.org

← Older revision		Revision as of 12:28, 28 March 2007
Line 61:		Line 61:

	This system will be very powerful and useful beyond panoramas.		This system will be very powerful and useful beyond panoramas.
		+
		+	[[Category:Software:Platform:Linux]]
		+	[[Category:Software:Platform:Mac OS X]]
		+	[[Category:Software:Platform:Windows]]

@@ Line 1: / Line 1: @@
-Tlalli is a recent fork of Panotools that wants to focus in the remapping part
+Tlalli is a recent fork of [[Panotools]] that wants to focus in the [[remapping]] part
-of panorama generation as opposed to the registration.
+of panorama generation as opposed to the [[registration]].
 I believe that panotools should be divided (at least from an architectural point of view)
@@ Line 6: / Line 8: @@
 projection computations, that needs to be used by both modules).
-The separation of projection from optimization  is probably best exemplified by Flexify, which takes an
+The separation of projection from optimization  is probably best exemplified by [[Flexify]], which takes an
 equirectangular (I haven't use it yet, so this is my understanding)
 and produces an output image after it has applied a
-transformation. FLexify does not need to know anything about
+transformation. Flexify does not need to know anything about
 registration and optimization.

@@ Line 2: / Line 2: @@
 of panorama generation as opposed to the registration.
- I beleive that panotools should be divided (at least from an architectural point of view)
+I believe that panotools should be divided (at least from an architectural point of view)
 into 2 main parts: optimization and the projection (there is a third module, which involved
 projection computions, that needs to be used by both modules).
@@ Line 12: / Line 12: @@
 registration and optimization.
- What I am proposing here is a "programmable flexify", or a super
+What I am proposing here is a "programmable flexify", or a super math-map. This is the direction where I want to take Tlalli.
 math-map. This is the direction where I want to take Tlalli.