# xmerge 0.1.1

xmerge is an open source program for merging and correcting rotated, skewed or generally linearly distorted images.

- LICENSE TYPE:
- GPL (GNU General Public License)
- USER RATING:
- DEVELOPED BY:
**Johan Borg**- HOMEPAGE:
- xmerge.sourceforge.net
- CATEGORY:
- ROOT \ Multimedia \ Graphics

xmerge is an open source program for merging and correcting rotated, skewed or generally linearly distorted images, featuring a X GUI.

When the user has provided a set of rules for how the image(s) should look (which points should overlap, horizontal and vertical references, etc) xmerge uses an SQP solver for calculating how the images should be placed for this rules to be fulfilled, while minimizing more severe types of distortion of the images. The sqp solver used is HQP, by R. Franke.

The original implementation is intended for things related to optimal control problems, and quite bloated for simpler applications where only the good sqp solver is used. As a result, the developer decided to strip it down a bit. Also, the use of SQP for solving this problem is probably quite a bit of overkill, it is quite possible that some heuristic can be used to transform the problem into a simpler type of optimization.

When the "optimal" mapping of the images has been determined, the user is supposed to select edges, internal to the mapped images, which are used for calculating the weighting of the individual images when two images overlap (areas of the image, but outside of these edges are not used at all). The working image used at this stage is an un-interpolated version of the final image, as the interpolation takes considerable time, and even without interpolation generating the image is quite slow.

The preview and final images are generated using interpolation by Elliptically Weighted Averages, which seem to give superior results compared to most other methods, while being considerably slower. A truncated Gaussian function is used for filtering, but use of sin(x)/x may give superior results if a large enough window is used. This option might be implemented in future versions.

The mapping of the images used are on the form

X=x*(a+b*y)+c*y+d, Y=y*(e+f*x)+g*x+h

which in retrospect may be a suboptimal choice, as the inverse coordinate

mapping is really messy. Furthermore, other mappings should give better

results when applied to specific uses, like merging photographs.

There are some plans for implementing more mappings at a later time.

A problem inverse mappings for photographs is that a surface in 3D only has

6 degrees of freedom, while parts of the current version assumes 8 degrees.

One rather attractive option may be to implement 2 degrees of 2nd order

distortion, which could compensate for imperfect optical components

A more generic approach, where mappings can have arbitrary freedom

and different mappings may be combined (Ex: correcting for optical errors

before inverse Z mapping, and then mapping the result on a sphere)

would be really nice, but far much more work.

options implying non interactive operation: (in order of execution)

-s solve loaded problem

-W write current mapping data

-w write final image

·

·

· libm

· X libraries

·

Just type make, and hope it compiles on your system.

Everything is contained in the xmerge binary, which can be copied to some convenient place in the system path, if desired.

When the user has provided a set of rules for how the image(s) should look (which points should overlap, horizontal and vertical references, etc) xmerge uses an SQP solver for calculating how the images should be placed for this rules to be fulfilled, while minimizing more severe types of distortion of the images. The sqp solver used is HQP, by R. Franke.

The original implementation is intended for things related to optimal control problems, and quite bloated for simpler applications where only the good sqp solver is used. As a result, the developer decided to strip it down a bit. Also, the use of SQP for solving this problem is probably quite a bit of overkill, it is quite possible that some heuristic can be used to transform the problem into a simpler type of optimization.

When the "optimal" mapping of the images has been determined, the user is supposed to select edges, internal to the mapped images, which are used for calculating the weighting of the individual images when two images overlap (areas of the image, but outside of these edges are not used at all). The working image used at this stage is an un-interpolated version of the final image, as the interpolation takes considerable time, and even without interpolation generating the image is quite slow.

The preview and final images are generated using interpolation by Elliptically Weighted Averages, which seem to give superior results compared to most other methods, while being considerably slower. A truncated Gaussian function is used for filtering, but use of sin(x)/x may give superior results if a large enough window is used. This option might be implemented in future versions.

The mapping of the images used are on the form

X=x*(a+b*y)+c*y+d, Y=y*(e+f*x)+g*x+h

which in retrospect may be a suboptimal choice, as the inverse coordinate

mapping is really messy. Furthermore, other mappings should give better

results when applied to specific uses, like merging photographs.

There are some plans for implementing more mappings at a later time.

A problem inverse mappings for photographs is that a surface in 3D only has

6 degrees of freedom, while parts of the current version assumes 8 degrees.

One rather attractive option may be to implement 2 degrees of 2nd order

distortion, which could compensate for imperfect optical components

A more generic approach, where mappings can have arbitrary freedom

and different mappings may be combined (Ex: correcting for optical errors

before inverse Z mapping, and then mapping the result on a sphere)

would be really nice, but far much more work.

**Command line options ("xmerge -h"):***-h this message*

-o set output file for final image, if written (default test.ppm)

-O set output file for mapping data, if written

-l load saved mapping data, mutually exclusive to specifying ppm files

-m magnification applied when solution is calculated (default 1.0)

-M magnification applied if mapping data are loaded

-b background color (default: 255,0,0 (red))

-r reference-color for gain calculation (gui: b) (default 255,255,255)

-R color gain applied if mapping data are loaded (default 0,0,0)

-B black level used when final image is created (default: 0,0,0) (color gain or reference level must be adjusted accordingly)-o set output file for final image, if written (default test.ppm)

-O set output file for mapping data, if written

-l load saved mapping data, mutually exclusive to specifying ppm files

-m magnification applied when solution is calculated (default 1.0)

-M magnification applied if mapping data are loaded

-b background color (default: 255,0,0 (red))

-r reference-color for gain calculation (gui: b) (default 255,255,255)

-R color gain applied if mapping data are loaded (default 0,0,0)

-B black level used when final image is created (default: 0,0,0) (color gain or reference level must be adjusted accordingly)

options implying non interactive operation: (in order of execution)

-s solve loaded problem

-W write current mapping data

-w write final image

**Requirements:**·

**gcc**·

**libc**· libm

· X libraries

·

**xv**(optional)**INSTALLATION:**Just type make, and hope it compiles on your system.

Everything is contained in the xmerge binary, which can be copied to some convenient place in the system path, if desired.

Last updated on April 11th, 2008

#### Add your review!

SUBMIT