There are a couple of ways to do this, one is to just get the executable programs off someone who's already compiled orbits, the other is to get the source and make it compile on your desktop computer or if you want to have more fun, compile it on a wearcomp (bonus points to the first ECE1766 student to get orbits running on a wearcomp --- it runs a little slow on a wearcomp, but it will be a fun and educational exercise). If you have trouble, try to team up with someone who has some experience with the "C" (and ++) programming language. It is preferable to use these because they run on more platforms (e.g. more platforms than the original FORTRAN, Matlab, FMEX, CMEX, PV-Wave, etc., implementations of orbits). It's also good to learn some "C" and this is a great way to get going on C and personal imaging. (Bonus points to anyone who makes suggestions on improvement of this mess of programs.) Assuming you're going the compile route (as opposed to getting executables), first obtain http://wearcam.org/orbits so that you have roughly the following: GrowArray.h++ derivatives.c mat_util.c Makefile derivatives.h mat_util.h Orbits.doc display_service.c mat_util.o PNMImageOffsetable.c++ display_service.h math2d.h PNMImageOffsetable.h++ dst_to_src_pchirp2.c motion.c README.HTML dst_to_src_pchirp2.h motion.h README.TEX est_pseudo.c par.c README.TXT est_pseudo.h par.h alpha filt2d.c pchirp2ia.c basic.h filt2d.h pchirp2ia.h boundingbox.c hp700 pchirp2nocrop.c++ boundingbox.h img.h pintegrate.c++ cement.c++ img_resample.c pintegrate.m click_image.tcl img_resample.h pinverse.c corners2d.c index.htm pinverse.h corners2d.h index.html ppm.c corners2r.c interp.c ppm.h corners2r.h iris readme.txt corr2p_main.c main.c If you're not familiar with Makefiles, you can just compile from the command line as follows: Compile each module with either: (i) gcc -c FILE.c *OR* (ii) gcc -c -I/usr/openwin/include FILE.c or the like for programs with X dependency (the above is for SUN worktation; vary as needed depending on X location). You need to generate objects (compile corresponding c files): mat_util.o display_service.o est_pseudo.o ppm.o pchirp2ia.o derivatives.o motion.o filt2d.o par.o main.o corners2r.o dst_to_src_pchirp2.o img_resample.o interp.o Then link with: gcc mat_util.o display_service.o est_pseudo.o ppm.o pchirp2ia.o \ derivatives.o motion.o filt2d.o par.o main.o corners2r.o \ dst_to_src_pchirp2.o img_resample.o interp.o -o estpchirp2m \ -lX11 -lm OR, gcc mat_util.o display_service.o est_pseudo.o ppm.o pchirp2ia.o derivatives.o mo tion.o filt2d.o par.o main.o corners2r.o dst_to_src_pchirp2.o img_resample.o int erp.o -o estpchirp2m -L/local/X11/lib -lX11 -lm -lsocket -lnsl setenv LD_LIBRARY_PATH /local/X11/lib printenv or some such, depending on where your libraries are, etc. the final executable is called "estpchirp2m" (so-called for historical reasons; the "m" denotes multilevel; this is the same as the estpchirp2m of Matlab/fmex and Matlab/cmex) ----------------------Other notes... ----------------------------------- in filt2d.c strings.h chaged to string.h mat_util.c:583: warning: comparison is always 0 due to limited range of data typ (leaving this warning, may want to check later) ---------------------------------------------------------------------- If you're running this on linux or SUN, you can use the ldd command to see what shared objects are needed, e.g.: ldd estpchirp2m libX11.so.4 => /usr/openwin/lib/libX11.so.4 libm.so.1 => /usr/lib/libm.so.1 libc.so.1 => /usr/lib/libc.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libw.so.1 => /usr/lib/libw.so.1 libintl.so.1 => /usr/lib/libintl.so.1 if your computer has these files in different places, or the like, you might want to re-link For example, if one of the shared objects is missing, ldd will notify you: ldd estpchirp2m libX11.so.5.0 => (file not found) libm.so.1 => /usr/lib/libm.so.1 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libintl.so.1 => /usr/lib/libintl.so.1 libmp.so.1 => /usr/lib/libmp.so.1 libw.so.1 => /usr/lib/libw.so.1 In this case, compile or re-compile, or fix the missing shared object. Problems like this can often be very easy to fix without even needing to compile the source code, for example, the above problem can be fixed by: setenv LD_LIBRARY_PATH /local/X11/lib I suggest you use the display option because you'll learn a lot by just watching it run. the -display option opens an X window and gives you a diagnostic/tutorial "peek inside" the process of videoorbits showing you how it works. Example: ./estpchirp2m pic290.pgm pic294.pgm -display -steps 4 3 3 3 3 Note that I have chosen 4 resolution levels with 3 steps at each level. Experiment with various numbers, e.g. try -steps 5 3 3 3 3 3 to see what happens with 5 levels. Try -steps 4 9 9 9 9 or -steps 4 1 1 1 1 to see the difference in how long it takes to run with only 1 rep at each level. Now try it with less levels, like -steps 3 2 2 2 For your image set, see if you can get it to run quickly by being creative with the hierarchy. For example, reps at the top of the pyramid run faster, while those at the bottom run slower, so try something like -steps 4 8 4 2 1 so that you taper off the number of reps as you get down to more computationally costly levels. Have fun with VideoOrbits, and make a writeup of what you do and what you find while you're doing it (a lot easier than trying to remember what numbers you tried later on). GENERAL BACKGROUND ON VideoOrbits VideoOrbits 1.0 allows you to ``stitch together'' multiple pictures of the same scene or object, taken from a fixed center of projection or of a flat surface. These assumptions may also be violated to some extent with successful results see some of the examples in http://wearcam.org/orbits/gallery.html VideoOrbits 1.0 can reassemble overlapping pictures of the same scene into one large "image composite", given the assumption that they lie in the same orbit of the projective group of coordinate transformations (e.g. static scene, constant lighting, and zero parallax, which happens if either the camera is at a fixed point in space but still free to pan, tilt, rotate about its optical axis, or zoom, or if the subject matter is flat). Given enough overlap in the input images, and a reasonable approximation to images being in the same orbit, the software can function without user intervention. One can regard the process as embodying a ``painting'' metaphor, where the camera ``paints'' out images onto an empty ``image canvas''. If the camera ``paints'' back on itself (e.g. path loops around in a self-intersecting way so that it covers an area already ``painted''), some cumulative error may become visible, because release 1.0 does not re-adjust to distribute the error over various possible frame pairs (this will be fixed in release 1.1). The four main programs you need to use to assemble such image sets are estpchirp2m, pintegrate, pchirp2nocrop, and cement (Computer Enhanced Multiple Exposure Numerical Technique). The programs use the ``isatty'' feature of the C programming language to provide documentation which is accessed by running them with no command line arguments (e.g. from a TTY) to get a help screen. The sections for each program give usage hints where appropriate. Future versions will support the ``pipe'' construct (e.g. some programs may be used without command line arguments but will still do the right thing in this case rather than just printing a help message). The first program you need to run is estpchirp2m, which estimates coordinate transformation parameters between pairs of images. These ``chirp'' parameters are sets of eight real-valued quantities which indicate a projective (i.e., affine plus chirp) coordinate transformation on an image. You should store each picture in a separate file, and use filenames that are numbered sequentially, for example, v000.ppm, v001.ppm, ... v116.ppm (e.g. for an image sequence with 117 pictures in it). After you run estpchirp2m on all successive pairs of input images in the sequence, the result will be a set of sets of eight numbers, in ASCII text, one set of numbers per row of text (the numbers separated by white space). The number of lines in the output ASCII text file will be one less than the total number of frames in the input image sequence. For example, if you have a 117-frame sequence (e.g. image files numbered v000.ppm to v116.ppm), there will be 116 lines of ASCII text in the output file from estpchirp2m. The first row of the text file (e.g. the first set of numbers) indicates the coordinate transformation between frame 0 and frame 1; the second row, the coordinate transformation between frame 1 and frame 2, A typical filename for these parameters is ``parameters_pairwise.txt''. These pairwise relative parameter estimates are then to be converted into ``integrated'' {\em absolute} coordinate transformation parameters (e.g. coordinate transformations with respect to some selected `reference frame'). This conversion is done by a program called pintegrate. This program takes as input the filename of the file containing parameters from the ASCII text file produced by estpchirp2m (e.g. ``parameters\_pairwise.txt'' and a `reference frame' (specified by the user), and calculates the coordinate transformation parameters from each frame in the image sequence to this specified `reference frame'. The output of pintegrate is another ASCII text file which lists the set of chirp parameters (again, 8 numbers per chirp parameter, each set of 8 numbers in ASCII, on a new row of text), this time one parameter per frame, designed to be used in order. That is, the first row of the output text file (first set of 8 real numbers) provides the coordinate transformation from frame 0 to the reference frame, the second from frame 1 to the reference frame\ldots The program called pchirp2nocrop takes the ppm or pgm image for each input frame, together with the chirp parameter for this frame % from pintegrate, and `dechirps' it (applies the coordinate transformation to bring it into the same coordinates as the reference frame). Generally the parameters passed to pchirp2nocrop are those which come from pintegrate (e.g. {\em absolute} parameters, not relative parameters). The output of pchirp2nocrop is another ppm or pgm file. The program called cement (CEMENT is an acronym for Computer Enhanced Multiple Exposure Numerical Technique.) assembles the dechirped images (which have been processed by pchirp2nocrop) and assembles them onto one large image `canvas'. Additional notes: The estimation program, estpchirp2m, can take optional initial parameter ``guess'' inputs. This is useful when incoming images do not have a lot of overlap (i.e., taken with a still camera rather than a video camera). Initial estimation parameters can be generated using the Abelian pre-processors (still to be ported to C), or idr.c (interactive dechirp/rechirp) may be used to experiment with manual specification of the starting ``guess''. See also The Wyckoff Principle: http://wearcam.org/wyckoff.html as well as IEEE Transactions on Image Processing Vol. 6 No. 9, p. 1281--1295 and Proceedings of the IEEE, Vol. 86, No. 11, November, 1998, 29 pages (30 including cover; cover picture of issue depicts an early embodiment of Mann's WearComp invention) Pages 2123-2151