Anyhow, considering computational photography was a brand-new field to me, i’m rather satisfied with the results: the sharpen is polished and the gain in both detail and depth level are impressive, while trying to intentionally cause artifacts is somewhat difficult, in the sense one have to boost detail frequencies to rather extreme values in order to cause artifacts and chromatic aberrations: in fact, considering the way actual tools currently work, i wonder why WLS-based strategies have still to take the lead in well-known commercial applications.

Unfortunately, as you may already know, i don’t have much free time to dedicate to most of the things i’m interested in, so this post is sort of an introduction while the rest will follows: it could take a while for me to write more about it, but i’ll try to share the time between coding and blogging, in the meantime i’m posting some results with it, but please, don’t laugh at the GUI too badly, its still all of an experimental thing and it’s just.. well.. usable ;-P
Note that the videos here don’t give justice to the real results due to the compression going on with both the Xvid codec and YouTube, so look at the HD version if you can.

The following video try to demonstrate some more detail exaggeration:

The idea was to build the foundation for a fancy, compositing-based windowing system: beside the actual implementation that’s basically just wobbling the current target, i’m sure you’ll be able to come up with other effects as well, but that’s not the real point.
Setting aside the concrete animator implementation that would be better to be used as a base to derive some more abstract definitions from it, the architecture is quite open to new approaches and ideas, especially for the ultra-simple opengl-like interface i chosen for the rasterizer that let’s you prototype things quite fast:

package rasterizer
{
	import flash.display.Sprite;
	import flash.display.BitmapData;
	import rasterizer.data.*;

	/**
	 * OpenGL-like interface for a generic rasterizer.
	 * The triangle is the only supported polygon right now
	 *
	 * More desc for me..
	 */
	public interface IRasterizer
	{
		function glTexture( tex: BitmapData, forceRecreate: Boolean = false, smooth: Boolean = false ): void;
		function glSetTarget( aTarget: Sprite ): void;

		function glBegin( rasterMode: int ): void;
		function glEnd(): void;

		function glPresent( aTarget: Sprite = null ): void;
	}

	/**
	 * OpenGL-like interface for a generic 2D rasterizer.
	 * The triangle is the only supported polygon right now
	 *
	 * More desc for me..
	 */
	public interface IRasterizer2D extends IRasterizer
	{
		function glVertex( vertex: Vertex2, uv: Vertex2 ): void;
	}

	/**
	 * OpenGL-like interface for a generic 3D rasterizer.
	 * The triangle is the only supported polygon right now
	 *
	 * More desc for me..
	 */
	public interface IRasterizer3D extends IRasterizer
	{
		function glVertex( vertex: Vertex3, uv: Vertex2 ): void;
	}
}

Portions of the actual wobble animator took inspiration from the previous Magic Carpet demo and some stuff i found on the net: if you come up with some other effects let me know, i’ll be happy to link back to them!
Here you can play with a basic demo i setup to try it out or get the source code to do your own experiments:

Some time ago i was asked to publish my implementation of fixed-point math, mainly regarding embedded architectures where IEEE floating point computations have really bad performances. What i want to give you here is a pure-c++, template-based implementation of a fixed-point datatype: this thing is more of a test in order to see how much an object-oriented implementation can perform, being in contrast to a more traditional implementation. As expected, operator overloading and temporary object creation overhead are the main issues with a full-oo implementation as this one, anyway, its a damn nice way to exercise yourself in writing c++ policy-based templated code ;)

Big thank you goes to Kurt for having a great discussion with me on c++, math and for recommending me the most wonderful book on computer arithmetic as Hacker’s Delight delivers it in spades!
Back to the fp stuff: usage of this code in testing environments is advised, since it could contain rounding errors and sometimes explicit casts are needed to get it to work correctly; as i said, this was some sort of test, i abandoned the O-O idea when i ack the performances’ gap between OO vs. traditional implementation was remarkable (at least on embedded devices).
Before showing some usage guidelines, i should say that using this datatype on a desktop machine hasn’t much sense: nowadays floating-point math is faster than the integer’s one!
The class itself predefines a 24.8 and a 16.16:

typedef AquaFixed< 8, LowPrecision,  LowPrecision> fixed8_t;
typedef AquaFixed<16, HighPrecision, HighPrecision> fixed16_t;

An usage example could be a generic, datatype-unaware Matrix implementation as this one:

template<class Number>
class matrix {
private:
Number m[4][4];
public:
matrix();

// matrix indexing
inline Number&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; operator()(const int,const int);

// matrix operations
matrix<Number> operator*(const matrix<Number>);
matrix<Number> operator/(const matrix<Number>);
};

Doing it this way, you should be able to declare a Matrix as here and perform your own tests:

matrix<float_t> float_matrix;
matrix<fixed16_t> fixed_matrix;

NOTE! The AquaFixed class comes out straight from my framework, so you’ll have to define basic datatypes such as int32_t/int64_t for yourself, but that shouldn’t be a problem.

Get the code here and let me know of your tests!