Archive

Posts Tagged ‘java’

Computer Vision: IM520 Class Report (fall 2011/summer 2012)

March 24, 2015 Leave a comment

This short post deals with contents, assignments and solutions of the (very cool) IM520 computer vision class by FH-Prof. DI Dr. Wilhelm Burger at the Campus Hagenberg of the University of Applied Sciences Upper Austria, which I attended from fall 2011 to summer 2012. I’ve delayed this post for quite a while now – so that newer IM520 assignments had a chance to (at least partially) change over time. The core part of this post is making the class report public that each of us was required to submit – which contains details on how I solved all assignments, including problem descriptions, solution ideas, source snippets and lots of figures.

  • My full IM520 class report can be found here (24MB).
  • Assignment instructions (1-12) can be found here.
  • Files additionally required besides the instructions to start assignments be found here (30MB).
  • Currently, I’m providing the implementation source code only on individual request.

To make it easier for you to see if the report contains your topic of interest, here’s the table of content:


Preface

1 Introduction
1.1 Assignment 1.1: Setting up the development environment
1.2 Assignment 1.2: Testing the development environment
1.3 Assignment 1.3: Building a graph
1.4 Assignment 1.4: Mark branch nodes in graph
1.5 Assignment 1.5: Graph Cleanup

2 Fitting Lines to Points
2.1 Assignment 2.1: Implementing Algebraic Lines
2.2 Assignment 2.2: Fitting Lines to Point Sets

3 Finding Edges and Corners

4 Correlation and Log-Polar Transformation
4.1 Assignment 4.1: Correlation-based matching in gray scale images
4.2 Assignment 4.2: Log-Polar Transform

5 Texture Clustering
5.1 Assignment 5.1: Law’s texture maps
5.2 Assignment 5.2: K-means feature clustering

6 Skin Detection based on Colors 33

7 Motion Detection
7.1 Assignment 7.1: Frame-Differencing Method
7.2 Assignment 7.2: Running-Average Method
7.3 Assignment 7.3: Running-Gaussian-Average Method
7.4 Comparison of the Approaches
7.5 Assignment 7.4: Selective Background Updating

8 Tracking: Greedy Exchange Algorithm

9 Human Motion Detection based on SIFT

10 3D Camera Calibration using the Zhang Approach
10.1 Assignment 10.1: Focal Length Calculation
10.2 Assignment 10.2: Rotation Matrix Orthonormality Verification
10.3 Assignment 10.3: Scene Point Projection

Listings

Bibliography

Visitor pattern to replace getting object metainformation from runtime

April 19, 2014 Leave a comment

Assume we have different types of objects with a common interface in a single list. Objects in our example are instances of Circle, Rect and Polygon, which are all GeometricForms. In order to treat different types of objects in the list differently people often use runtime based mechanisms like instanceof (reflection), which get object metainformation from the runtime:

package com.geekoverdose.visitortest;

import java.util.ArrayList;
import java.util.List;

/**
 * Demo of using the visitor pattern to avoid instanceof statements - part 1.
 */
public class MainInstanceof {

    // ==============================================================================
    // CLASSES


    public interface GeometricForm {
    }

    public class Circle implements GeometricForm {
    }

    public class Rect implements GeometricForm {
    }

    public class Polygon implements GeometricForm {
    }
    
    // ==============================================================================
    // PROGRAM

    public void main() {
        // some list of objects that need to be drawn
        List<GeometricForm> list = new ArrayList<GeometricForm>() {
            {
                add(new Circle());
                add(new Rect());
                add(new Polygon());
            }
        };
        // separate by instanceof - can be very slow
        for (GeometricForm form : list) {
            if (form instanceof Circle) {
                // circle specific code here
                System.out.println("instanceof: circle");
            } else if (form instanceof Rect) {
                // rect specific code here
                System.out.println("instanceof: rect");
            } else if (form instanceof Polygon) {
                // polygon specific code here
                System.out.println("instanceof: polygon");
            } else {
                // error handling
            }
        }
    }
        
    public static void main(String[] args) {
        new MainInstanceof().main();
    }
}

A problem with asking metainformation from the runtime is the duration – which matters when the list is very long. In my original case we had hundreds of millions of geographic objects which needed to be drawn differently depending on object type and attributes. There using instanceof was not possible as it delayed drawing too much.

A way to avoid getting metainformation from the runtime is using the visitor pattern for our purpose. An abstract visitor provides different “visit” methods for different object types, so in our case one for Circle, Rect and Polygon. These methods get called if the visitor comes in contact with an object of the corresponding type. The common interface of your objects (GeometricForm) provides a single (abstract) method to “accept” a visitor. Each object type implements that method differently: so that the corresponding method for this object type get called at the visitor. So if we now want to process different object types differently we just call “visit” at the object and plug in a visitor which provides corresponding code for the different types, which can be created just in place:

package com.geekoverdose.visitortest;

import java.util.ArrayList;
import java.util.List;

/**
 * Demo of using the visitor pattern to avoid instanceof statements - part 1
 */
public class MainVisitorPattern {

    // ==============================================================================
    // CLASSES

    public interface GeometricFormVisitor<T> {
        // type parameter T to enable return value of any type when needed
        public T visit(Circle c);
        public T visit(Rect r);
        public T visit(Polygon p);
    }

    public interface GeometricForm {
        public abstract <T> T accept(GeometricFormVisitor<T> v);
    }

    public class Circle implements GeometricForm {
        @Override
        public <T> T accept(GeometricFormVisitor<T> v) {
            // automatically calls the Circle visit method
            return v.visit(this);
        }
    }

    public class Rect implements GeometricForm {
        @Override
        public <T> T accept(GeometricFormVisitor<T> v) {
            // automatically calls the Rect visit method
            return v.visit(this);
        }
    }

    public class Polygon implements GeometricForm {
        @Override
        public <T> T accept(GeometricFormVisitor<T> v) {
            // automatically calls the Polygon visit method
            return v.visit(this);
        }
    }

    // ==============================================================================
    // PROGRAM

    public void main() {
        // some list of objects that need to be drawn
        List<GeometricForm> list = new ArrayList<GeometricForm>() {
            {
                add(new Circle());
                add(new Rect());
                add(new Polygon());
            }
        };
        
        // visitor pattern - usually faster than using instanceof
        GeometricFormVisitor<Object> visitor = new GeometricFormVisitor<Object>() {
            @Override
            public Object visit(Circle c) {
                // circle specific code here
                System.out.println("visitor: circle");
                return null;
            }

            @Override
            public Object visit(Rect r) {
                // rect specific code here
                System.out.println("visitor: rect");
                return null;
            }

            @Override
            public Object visit(Polygon p) {
                // polygon specific code here
                System.out.println("visitor: polygon");
                return null;
            }
        };
        for (GeometricForm form : list) {
            Object someInformation = form.accept(visitor);
        }
    }

    public static void main(String[] args) {
        new MainVisitorPattern().main();
    }
}

(The type parameter T is a small extension that you can leave out if you do not need it. But if you at first need object type specific processing to extract information from an object, then process this information the same way for all objects this might be what you need).

Some more details on the problem: Polymorphism “fails” here, that’s why we use the workaround based on the visitor pattern. We cannot simply create one method each per object type, feed our object to those methods and let polymorphism solve the problem. The method call gets fixed at compile time, therefore to the supertype. So even if we have a method for our supertype and all subtypes it’s of no help. Good article describing the problem in more detail: https://sites.google.com/site/steveyegge2/when-polymorphism-fails