YET ANOTHER SHARPENING TOOL?!

Absolutely not! The primary goal of WonderSharper is to empower both the photographic professionals and the casual user with a simple tool to enable them to perform halo-free (given an halo-free source image, of course!), edge-preserving, multi-scale sharpening and detail mapping while maintaining a really simple and usable interface.
WonderSharper absolutely loves your edges and contours, it will accurately preserves them, no matter what: the amount of “percepted detail” at various individual scales can be changed and modulated via its simple interface, but that’s just the beginning.
In fact, the real power comes from the possibility to export the so-called detail maps: aimed to the photographic professionals, with those maps at hand you’ll acquire detail manipulation capabilities to be used outside of the WonderSharper UI: this will enable you to perform various, custom and complex transformations on the original image by using your existing tools, strongly encouraging the development of new detail manipulation techniques.

Due to the vastness and complexity of the subject it would be rather unfair to try to condense everything into one single post and, instead, we are now going to have a look at WonderSharper’s halo-free capabilities with the help of some screenshots: multi-scale sharpening and detail mapping are the subjects of one or more forthcoming articles, written and edited with the cooperation of Alberto, introducing these very interesting features with real-world applications, so to have a more photographic perspective on it.

HALO-FREE SHARPENING

In order to better explain why WonderSharper is different and what halo-free means, let’s have a look at some sample results computed by using photos available on the web.
The first batch of four details comes from the President Obama’s official portrait (courtesy of Pete Souza, thanks to stevegarfield), the second batch of details, instead, comes from Canon’s demonstrative sample photos of the EOS 5D Mark II camera (Copyright 2008 Canon Inc.) while the third one is a photo that’s part of a wedding photo shooting service performed with a Canon EOS 30D (courtesy of Alberto Bua, available on Flickr).
Note that the enlarged detail images of the first two batches have been intentionally zoomed in (400%) so to have a clear view of the differences at pixel level, while the last batch, instead, depicts the situation on a bigger area.

Barack Obama Official Portrait

In this first batch of samples, at the first row, you can clearly note various aberrations, halos and color noises in both the “Sharpen” and “Unsharp Mask” filters applied by GIMP: color aberrations (green/cyan) on the flag’s red lines are easily spotted and the dark background also presents colored noise; these aberrations aren’t present in the WonderSharper result.

Source Image	Gimp’s Sharpen	Gimp’s Unsharp Mask	WonderSharper

Note how these local micro-contrasts variations, between the source image and the WonderSharper output slighty affect the whole chromaticity and color perception: although not depicted here, WonderSharper gives you some degree of control over the output image enabling you to control the saturation levels in the CiELab color space so that the lightness remains untouched.

Canon EOS 5D Mark II Sample photo

Source Image	Gimp’s Sharpen	Gimp’s Unsharp Mask	WonderSharper

Canon EOS 30D Sample photo

Source Image	Adobe Photoshop’s Unsharp Mask	WonderSharper

Note: the source materials used herein are properties of their respective owners, if you hold the copyright and want your photo removed please let me know.

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:

Hoorah. Hoorah.

Basically, it’s a brutally stupid, slogan-centric three-points-nothing-more way to express the act of developing software: “1. Develop, 2. Test, 3. Distribute“.

That’s the real program:

1. You pay, you get the iPhone, note this is not part of the program;
2. You pay, they let’s you develop (to do this you must have a Mac/Intel, not part of the program);
3. You pay, they let’s you test on the device at point 1;
4. You pay, they let’s you distribute it;
5. You distribute, you could possibly earn something, they earn (30%) from this too, damn, again!

Let me analyze it a bit:

1. Apple wanna grow, make big money and get some important user-base;
2. Users come if the platform has something interesting to offer;
3. A good platform-enrichment thing could be some software;
4. Software possibly needs to be developed (sometimes it also has to be 2. deployed and tested on the real device, and ultimately i heard someone also tried to 3. sell it);
5. Software developers, thus, are needed (they’ll invest money, time, patience and experience, just to develop);
6. Apple needs developers;
7. I. Already. Heard. That.
8. Developers decide to support the platform and write/port software for it (best case);
9. Developers willing to support the platform, implicitly favoring Apple and it’s platform, are asked to pay for doing this;

Fortunately, there are great ways to overcome the need to make a living out of bread and onions: make an i-Developer a favor and make sure to get him to know about this, this, also this, this one too, and.. this.

Oh. And this.

In fact, the past year has been really busy: work and daily life take so much that sometimes you have to fight with yourself to squeeze out every possible free minute to do your own things, so one whole year has gone, but this doesn’t mean i don’t have something to write about, even better, i struggled to post about it from September, and i really mean September 2007, but better late than never!

But what did i do in all this time without even posting a blank post in 300 days? Well, in fact, we are not dead for sure, i’m working really hard on the cross-platform framework of some posts ago and we hope to be able to work full-time on the game idea we had in the past and, best of all, on the iPhone!

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!

I’m currently working on an early-stage, more of a proof-of-concept thing, but i needed to know more about the code performances: googling for an ActionScript profiler just showed up ASProf, an AS2 profiler. So i decided to port to AS3 the C++ profiler i wrote for Aqua, the cross-platform framework i was working on until April: the original C++ implementation has been developed after being inspired by an article of Steve Rabin in the Game Programming Gems 1 book, that’s a nice one to have on the shelf together with some other great books of which i could post something about them later.
It is always wise to remember that if you are serious about code profiling, you’ll be better to search for some professional tools: in the C++ arena my choice would be this one, but if you plan to have lunch and dinner for the next couple of months give Eletric’s one a try, it really deserves a look.
Unfortunately for the AS3 world, i just haven’t found anything really usable for it up to now, so i just thought to release it under a zlib/png license and some hints on how it works here.

ProfilerConfig.Width = stage.stageWidth;
ProfilerConfig.ShowMinMax = true;
prof = new Profiler( 32 );
addChild( prof );

Setup some custom configuration parameters and then create a Profiler and don’t forget to add it to your local render queue: the Profiler its a Sprite and it will render the results right there, all you have to do now is to profile some code:

var i: int = 0;
var it: int = 1000000;

prof.beginProfiling();

i = it;
prof.begin( "fadd" );
while( i-- ) { fRes += 1.; }
prof.end( "fadd" );

i = it;
prof.begin( "iadd" );
while( i-- ) { iRes += 1; }
prof.end( "iadd" );

i = it;
prof.begin( "fsub" );
while( i-- ) { fRes -= 1.; }
prof.end( "fsub" );

i = it;
prof.begin( "isub" );
while( i-- ) { iRes -= 1; }
prof.end( "isub" );

prof.endProfiling();

With another couple of lines of code you’ll end up with something like this:

Cool graphing for your function-timing needs ;)
And this is it!
A thing i may point out is that you can always group code fragments belonging to your most logical schema by wrapping the same ProfileNode around the different fragments; here i’m grouping math operations by their type, just to keep the call-graph a little bit organized:

var i: int = 0;
var it: int = 1000000;

prof.beginProfiling();

i = it;
prof.begin( "float", true );
prof.begin( "fadd" );
while( i-- ) { fRes += 1.; }
prof.end( "fadd" );
prof.end( "float" );

i = it;
prof.begin( "int", true );
prof.begin( "iadd" );
while( i-- ) { iRes += 1; }
prof.end( "iadd" );
prof.end( "int" );

i = it;
prof.begin( "float", true );
prof.begin( "fsub" );
while( i-- ) { fRes -= 1.; }
prof.end( "fsub" );
prof.end( "float" );

i = it;
prof.begin( "int", true );
prof.begin( "isub" );
while( i-- ) { iRes -= 1; }
prof.end( "isub" );
prof.end( "int" );

prof.endProfiling();

That’s all there is to it, hope it will be useful!
Grab the Profiler here and take a look at the demo code used for this post.

• it seems that image-type function parameters are bound to the selected images according to their alphabetical order, instead of the natural user-defined one: for instance, create a new kernel as here, select two images and refresh; you should be now looking at the image you loaded via “Load Image 2…”: now rename “in image4 srca” to be “in image4 srcc” and refresh. Wrongly, you are now looking at the first image
• the GUI doesn’t release cpu/gpu resources while minimized in order to relieve the machine from the rendering process

Aside that, i’m looking forward to try all this cool stuff with Astro!

I had some difficulties installing the package since it was keep asking to terminate another Adobe installation, anyway i managed to install the beast and give it a try: i wanted to simulate a “glassy look-through” effect (as you are watching something outside of a glass door): it goes without saying there is the need to use some of the “region needed” magic in order to crop the black borders out, but i have no time at the moment, so here it is.
In order to use this filter you’ll have to download the kernel source and these three images:

Basically, once you launched the AIF Toolkit, you load the hydra source, then the shower as the first image, and then choose one of the two normal maps as the second image, press F5 and try play with the parameters.