I have just got going using mathmap so please forgive any
elementary errors.
I am interested is creating cartographical projections from
equirectangular panoramas (created in hugin) and I know that some
(eg lambert azimuthal) exist in mathmap already.
My problems is that I wish to implement projections such as:
z = ((d+1)/(d + cos theta))sin theta
where d is a parameter, theta is the "latitude" of the
equirectangular image and z the polar radius of the output image.
My problem is this:
1. Mathmap seems to need the _inverse_ function (i.e. theta in terms
of z) (is this correct, and if so, what is the reasoning behind
it?).
2. I know how to invert the above function for d = 0 (gnomonic), 1
(stereographic) and infinity (orthographic) but not for other
values of d. Does anyone know an explicit formula for the inverse
for all d?
So my problem would be solved either if there is a way of expressing
the formula _directly_ in mathmap or if someone knows a formula for
the inverse.
Thanks,
Peter.
Yes, you need the inverse function. Pages in Wikipedia and in Wolfram
Mathworld usually give the two functions, direct and reverse.
e.g. http://mathworld.wolfram.com/GnomonicProjection.html
> 2. I know how to invert the above function for d = 0 (gnomonic), 1
> (stereographic) and infinity (orthographic) but not for other
> values of d. Does anyone know an explicit formula for the inverse
> for all d?
theta = asin ( z/sqrt((d+1)²+z²)) + asin ( z d /sqrt((d+1)²+z²))
Cheers,
Seb
> 1. Mathmap seems to need the _inverse_ function (i.e. theta in terms
> of z) (is this correct, and if so, what is the reasoning behind
> it?).
The reasoning is two-fold. On the one hand, doing the "inverse"
mapping is much simpler to implement. We iterate through all the
pixels in the image, execute the filter and get a color value for that
pixel in the image. Doing the mapping from source image to final
image would involve inverting the filter, probably numerically through
some iterative process. Otherwise we'd end up with lots of holes in
the final image. Consider, for example, enlarging the image by two
with the function
xy -> xy * 2
We could apply this function to all the pixel coordinates in the
source image and put the pixels on the resulting coordinates in the
final image. Lots of pixels would be outside the image frame, but the
main problem would be that we'd only have pixel values for every
fourth pixel. For example: Pixel (0,0) maps to (0,0). (1,0) maps to
(2,0), and so on. No pixels maps to (1,1), (1,0), (0,1), though. At
that point you'd have to figure out which original pixels MIGHT map to
those and see if they in fact do. This is not that difficult for
slow-moving continuous functions, but becomes a big issue for
discontinuous functions and for continuous functions with high
frequency components (because they look like discontinuous functions
if your sampling frequency is low).
The other reason for not doing "inverse" mapping is that you are then
tied to mapping coordinates, whereas MathMap can do much more than
coordinate transformations, like working with colors.
Mark
--
Mark Probst
http://www.complang.tuwien.ac.at/schani/
http://www.flickr.com/photos/schani/
http://schani.wordpress.com/