From: Pablo d'Angelo <pablo.dangelo@we...>  20070324 17:05:12

Hi Daniel, > On Thu, 22 Mar 2007 16:46:30 0700, dmg wrote: > >> With respect to the rearchitecturing of panotools (GSoC) I have been >> thinking about the "computational" stack of panotools. >> >> As I have stated in the past, I strongly believe that the optimization >> and the projection should be divided into 2 independent modules. >> >> This 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 >> mathmap. 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? What do you mean by f() exactly? A function that transforms coordinates (a,b) > (c,d), or a complete image processing function. >> 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. I didn't fully understand what you mean with that. Is it: 1. make the coordinate transformation stack more flexible by allowing more dynamic construction of it? 2. you propose to move to a new image processing framework, that is based on a lazy evaluation principle, where the operations are only performed for all pixels that contribute to the output pixels? This means, that by "pulling" at an output pixel, the whole image processing stack is triggered for that pixel, and no intermediate images are required (only if possible by the operations used in the stack, obviously). I think step 1 is very important. It does not make sense to do multiple geometric transforms (which always include quality loss due to interpolation) after each other. Step 2 has already been implemented by a number of other applications, which should be evaluated in detail before starting yet another one. This especially includes VIPS, which could be easily extended with the operations supported by panotools and hugin. http://www.vips.ecs.soton.ac.uk/index.php?title=VIPS Please take a look at that before starting something new from the scratch. I hope we will get a student to work on porting the panotools operations to VIPS, since this is similar to what you are describing here. >> 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. This sounds very much like using VIPS, or a similar architecture, such as GEGL. >> This system will be very powerful and useful beyond panoramas. This is why something similar has been written already :) ciao Pablo 