Fast Semi Causal Nonparametric Markov Random Field Texture Synthesis on a Gaussian Pyramid

My Home Page

Original Version

Fast Version

Fast Version on a Gaussian Pyramid with K Nearest Search

This algorithm is a cut down version of the algorithm published in IEEE Transactions on Image Processing 1998. In this version, it has been rewritten for a single cpu machine. To maintain speed of synthesis, the update function pUpdateFn() has been set to return the maximum value. If this was modified to return a portion of the maximum value, then the synthesis would take longer, but there would be a gain in quality. If you do decide to modify the code, be careful, as I have not put in any safeguard checks. Best to fully understand the whole code, before modifying it.

This gaussian version implements the previous fast version on a Gaussian pyramid of the input image (instead of a decimated quadtree as in the fast version). As can be seen in the results, there is not a great improvement. But just a reduction in speed of synthesis, as about 1/3 more pixels need to be synthesised. However there does appear to be also a reduction in the speckle noise that was apparent in the images synthesised by the fast version.

Recently there has been quite an influx of nonparametric sampling techniques for texture synthesis (,here is a brief list). This is because it has been the nonparametric models that have had the greatest success at synthesising arbitrary textures. This technique uses a multiscale approach, which has the advantage that only a small neighbourhood is required.

However the basis of the algorithm first appeared in:

Source Code

Download Source Code Last updated 21-11-02 Copyright (C) 2002, by Rupert Paget, all rights reserved.

The source code requires ImageMagick to be preinstalled. To compile the code, run gmake in the parent directory. There are two makefiles, one in parent directory, and in the src directory. If the code does not compile, both makefiles will need to be edited. I have written one for a sun (default) and one for an sgi machine, but I give no guarantees that they will work.

The program is executed with the following command

nonparaMRF_gaussian [-l levels] [-n neighOrder] [-s] [-t treeMax] [-c] [-x cols] [-y rows] [-m maskfile] [-h] texturefile


levels =
number of gray levels the image will be compacted to. Reducing the number from 255, will probably not improve the synthesis, and will most likely increase the run time.
neighOrder =
number to signify neighbourhood size. See neighbourhoods for schematics of the neighbourhoods used in the texture synthesis algorithm.
s =
if set, the neighbourhood becomes a square neighbourhood.
treeMax =
maximum quadtree height. The algorithm will not allow the quadtree height to be set to a value that will allow either the input image or output image to be reduced to less than a 2x2 pixel image.
c =
if set, the output image is defined to be toroidal (ie cyclic) where each border matches with its opposite border.
cols =
number of columns in the output image. If undefined, number columns in the output image will equal number columns in the input image.
rows =
number of rows in the output image. If undefined, number rows in the output image will equal number rows in the input image.
maskfile =
is a mask image that must be the same size as the input texture image. Only where the mask image is non zero is the input image used.
h =
if set, will mean that just usage and default values will be displayed. This will also occur if no input values are given.
texturefile =
is the input texture image that is to be synthesised.

Default values are : levels = 256, neighOrder = 1, square = false, treeMax = 6, cyclic = false

Schematic of the neighbourhoods used in the texture synthesis algorithmSchematic of the neighbourhoods used in the texture synthesis algorithm

Synthesis run times for various input parameters

These times were compiled on a distributed system of mainly SunBlades 100: 500 MHz, 256 MBytes RAM. The input textures were 128x128 pixel images, and the output synthesised textures were 256x256 pixel images. The run times are basically dependent on output image size and the type of input texture. This is due to the nearest neighbour search algorithm used in the code. If the input texture is fairly uniform in colour, then the search algorithm will be more of an exhaustive search, and therefore more dependent on input image size. Time stamps are in "Days Hours:Minutes:Seconds".

Neighbourhood# of TestsMin Run TimeMax Run TimeMean Run TimeStdev Run Time
1 1650 0:04:100 0:13:100 0:04:530 0:01:12
1 -c 1650 0:04:100 0:13:440 0:04:470 0:01:04
1 -s 1650 0:04:150 0:15:590 0:05:220 0:02:02
1 -s -c1650 0:04:160 0:13:320 0:05:100 0:01:30
2 1650 0:04:200 0:13:550 0:05:180 0:01:32
2 -c 1650 0:04:190 0:13:470 0:05:140 0:01:24
2 -s 1650 0:04:290 0:40:360 0:08:070 0:05:14
2 -s -c1650 0:04:290 0:37:200 0:08:230 0:05:46
3 1650 0:04:220 0:16:240 0:05:320 0:01:45
3 -c 1650 0:04:210 0:14:550 0:05:450 0:01:56
3 -s 1650 0:04:500 2:39:090 0:21:170 0:24:48
3 -s -c1650 0:00:040 2:52:350 0:20:370 0:23:52
4 1650 0:04:240 0:17:590 0:06:010 0:02:12
4 -c 1650 0:04:240 0:17:550 0:06:040 0:02:24
4 -s 1650 0:05:000 7:34:320 0:49:320 1:05:53
4 -s -c1650 0:05:030 6:52:570 0:51:450 1:10:05


Additional Information

For More Information

Email Rupert Paget at:

Valid HTML 4.01!

This site was proofread by
English Editing Experts.