CSC 400 Team Project: Parallel Jigsaw Puzzle Solving
Team:
The goal of this project is to create a system to assemble
jigsaw puzzles, taking advantage of opprtunities for
parallel processing to speed up the process.
Specifically, you will be provided with a number of images,
each containing several pieces of the puzzle photographed against
black velvet.
Example.
The object is to extract the pieces from the images, and figure out how they
fit together. The final output will be a single image showing the
assembled scene (or as much of it as you program can produce).
You may certainly employ non-imagelike intermediate representations
to help in the solution of the problem, but you should produce an image
that allows your solution to be evaluated visually.
Note that at best, your system will only solve the puzzle down to a
(4-way) rotation in the image plane, since I do not expect you to
be able to determine which way is up (though you are
welcome to try).
Currently, for development data, I have taken imagery for two 100-piece
puzzles. They are in ~nelson/pics/puzzles/duck_bunny and
~nelson/pics/puzzles/fish.
Each directory contains 34 images, each containing 6 (or 4 in
a few cases) puzzle pieces on black velvet.
There are two images of each set, numbered consecutively, taken at
different exposures. The odd-numbered images are brighter than
the even numbered ones.
The fish puzzle contains a lot of pieces that are of a generally
underwater-blue shade, which could make matching more difficult.
As a culmination, there will be, on a class day near the end of the semsester,
hold a demonstration challenge, where the system must attempt to solve
previously unseen puzzle (of the same general
difficulty as the development data) in reasonable time.
The team will also need to give a presentation on their effort
(on a class after the demonstration)
As usual, the team is to create a single, coherent, written report on
their approach to the project, describing in detail what
approaches were used, what did not work, any comparative studies done,
what considerations went into the design, where the processing time
was spent, how the system would be expected to scale, etc. etc.
There are a number of aspects that need to be addressed.
The first is the image-processing/vision aspect.
The puzzle pieces need to be extracted from the images.
I have tried to take images that will make this
as easy as possible.
The images are all shot with a very narrow field of view,
from directly overhead, and at the same scale and exposure.
Thus all the colors and boundaries should match within the limits
of the camera and image accuracy.
Because of the black background, simple thresholding will (almost)
allow the puzzle pixels to be separated from the background.
Most of the minor problems here can be fixed up by some
simple local filtering (e.g. a 3x3 median filter).
A connected components routine can be used to associate pixels
belonging to individual pieces.
There are a few complexities you will need to deal with.
First, the dynamic range of the camera is not all that might be hoped.
If white areas are not saturated, some dark areas look pretty black.
Just in case this causes problems, I have taken each image twice at
different exposures. Odd numbered images (01, 03, ...) are
taken at a bright exposure, and following even numbered images
(02, 04, ...) are darker exposures of the same scene.
You may make use of these (or not) as you wish.
Second, our building shakes. This means that the pictures of the
same scene may be mis-aligned by a couple of pixels.
It also means that you may sometimes encounter "interlace artifacts"
in the images themselves. To understand this, you need to know
that standard video cameras take odd and even lines 1/60 of
a second apart and merge them into one image.
If the camera moves slightly between fields, a "fingering" or
"staircasing" effect shows up along object boundaries.
This might have an effect on some matching processes you might use.
The effect can be ameliorated in various ways.
Median filtering (or other smoothing) helps to some extent.
Following this by a dilation and an erosion of the thresholded binary image
would probably produce pretty clean regions for segmentation.
If you want to get more elaborate the image could be separated
into odd and even fields, and a shift correction computed and applied.
Or you might even work with a 1/2 resolution image obtained by subsampling.
Third, you will need to rotate the pieces as well as translate them
in order to fit them together.
There is code in my libaries for rotating images, but there are
pixel-level accuracy issues at the boundaries.
Also, although the aspect ratio of the pixels is approximately 1 to 1,
I do not guarantee it is exactly 1 to 1 (i.e. that the pixels are
exactly square.) You may want to carefully measure the real aspect ratio
in the Canon cameras from which the images were taken.
(They were taken with one of the ceiling cams in the software lab)
You will have to take some pics of either an exactly square object,
or a rotated object.
Knowing this precisely might be the crucial difference in whether
you can do shape matching or not.
I have written library code for all the operations mentioned above,
including connected components, and many more,
so you probably do not need to write or find image processing code.
You just need to figure out how to link and use the ipp libraries.
There is a program "image_calc" in ~nelson/bin/PCLinux
that will let you experiment with all sorts of image processing
operations on the images, to see what gives good extraction.
You can look at the source in ~nelson/programs/src/integrated/bin
to see how to link and use the routines once you have figured out
what needs to be done.
The second aspect is the representation and matching problem.
You will need to represent the pieces in a way that permits
matching operations to be performed efficiently on the
color and/or pattern and/or shape.
It might be advantageous to identify border pieces.
It might also be advantageous to obtain a boundary description
broken at "corners" (where 4 pieces come together) for each piece.
These points seem like they would be identifiable on the pieces we
have, and a boundary segment represented in normalized form could
permit quick match checks (e.g. on length) and fast shape-matching - since
the endpoints are known, no further rotation would need to be done.
A third inportant aspect involves parallel processing and efficient
algorithms for the overall assembly.
Since the goal is to solve the puzzle as rapidly as possible,
any use of parallel resources, and any heuristics to reduce the number of
matches that need to be considered would owrk towards that goal.
Human-like strategies of working on groups of pieces of similar color
might be helpful.
Of course some such strategies might not interact well with division over
a moderate (16+) number of processors, so there are tradeoffs to be
considered.
There is also the issue of how much time is consumed in basic image
processing versus matching. Image processing, especially of multiple
images, is rather trivially parallelizable.
If most of the work is in the production of the piece representations, then
parallelizing the matching might be a moot point.
Finally there is the issue of presentation of the processing.
It would be nice to have a live display
illustrating the progress of the system as it progresses.
Some graphical output showing sections as they are constructed,
would be interesting.
How to do so effectively when many machines are working on the problem at
once is an interesting problem
Getting started
As a step towards handling the image-processing aspect of the project,
you should you should become familiar with
these
machine vision resources.
Once you have done this, you could check out the program
"image_calc" in ~nelson/programs/src/integrated/bin.
this allows you to experiment with the routines in my ipp image processing
library, which probably contains most of the image-processing
capability that you will need. The source code will show you how the
routines are used, and the make file will show you how to link the
libraries.
Back to CSC 400 main page