The RIM Blackberry API makes it really simple to display bitmap images on the screen. Once you’ve added your image as a resource file the code is as simple as the following two lines:

	BitmapField bmp = new BitmapField(Bitmap.getBitmapResource("image.png"));
	add(bmp);

However, if you need to display a resized version of the image you’ll soon notice that the Bitmap class doesn’t have any methods for performing such an action. Don’t worry though, the EncodedImage class does, and also provides a method to return the required Bitmap object. Below is the code to scale an image to half its original size and then add it to the current screen:

	EncodedImage ei = EncodedImage.getEncodedImageResource("image.png");
	ei.setScale(2); // divide size by this number
	BitmapField bmp = new BitmapField(ei.getBitmap());
	add(bmp);

The Underhanded C Contest 2008 is underway. This year the contest is to write code that appears to redact (black out) rectangular regions of an image, but actually allows the redacted content to be recoverable to a certain degree. They call this “Leaky Reaction”. Sample code is provided that can be used in the solution, which includes a number of helpful functions such as reading and writing PPM image files, and getting pixel values from the loaded data.

I thought a good place to start would be with some code that actually does redact the data in a non-recoverable way. Making use of their sample code I quickly came up with the following function:

void redact(int left, int bottom, int right, int top, image * out)
{
	pixel p;
	int x,y;

	p.rgb[0] = 0;
	p.rgb[1] = 0;
	p.rgb[2] = 0;

	for( x=left; x<right; x++ ) {
		for( y=bottom; y<top; y++ ) {
			put_pixel( *out, x, y, p );
		}
	}
}

The image below shows an image before and after applying the above redact function to it:

For this contest we don’t want to redact the image though, we just want to appear to have redacted it. A simple approach we could take would be to divide the existing pixel an arbitrary value
so that the area appears black (if we divide by a large enough number), but in actual fact it is only almost black, and can be returned to the original value by multiplying the new pixel value with the number we previously divided by.

Below is a redact function that divides the pixel value by 50:

void redact(int left, int bottom, int right, int top, image * out)
{
	pixel p;
	int x,y;

	for( x=left; x<right; x++ )
		for( y=bottom; y<top; y++ ) {
			pixel p = get_pixel( *out, x, y );
			p.rgb[0] /= 50;
			p.rgb[1] /= 50;
			p.rgb[2] /= 50;
			put_pixel( *out, x, y, p );
		}
}

And to reverse the redaction:

void unredact(image * out)
{
	pixel p;
	int x,y;

	for( x=0; x<out->width; x++ ) {
		for( y=0; y<out->height; y++ ) {
			p = get_pixel( *out, x, y);
			if(p.rgb[0] * 50 <= 256
			&& p.rgb[1] * 50 <= 256
			&& p.rgb[2] * 50 <= 256)
			{
				p.rgb[0] *= 50;
				p.rgb[1] *= 50;
				p.rgb[2] *= 50;
				put_pixel(*out, x, y, p);
			}
		}
	}
}

The image below shows the original image, the image after calling the redact function, and then that image after calling unredact. The final image isn’t identical to the first because we loose some information with the integer division, but it is close enough for us to be able to recognise the details. If we used a value smaller than 50 we would have lost less information, but the redacted image wouldn’t appear so black.

While the approach discussed above clearly allows us to reproduce the “redacted” data it is highly unlikely to be a contest winner! Anyone casually glancing at the code can see that we aren’t really redacting the image at all, and working out the code to undo the redaction would be relatively trivial.

In the next part I’ll discuss some more “leaky redaction” techniques I have tried. In the mean time here is the complete source code listing for the leaky redaction application, which makes use of sample code:

// very simple leaky redaction code for the Underhanded C Contest 2008
// www.coderholic.com
#include <stdio.h>
#include <stdlib.h>
#include "ppm.c"

int main( void )   /* usage:  redact < in.ppm > out.ppm */
{
	image in, out;

	if( get_ppm_from_file( &in, stdin ) && copy_ppm( in, &out ) ) {
		redact(110, 70, 201, 100, &out);

		put_ppm_to_file( out, stdout );
		dealloc_ppm( in );
		dealloc_ppm( out );
	}
	return 0;
}

// perform leaky redaction on an image
void redact(int left, int bottom, int right, int top, image * out)
{
	pixel p;
	int x,y;

	for( x=left; x<right; x++ )
		for( y=bottom; y<top; y++ ) {
			pixel p = get_pixel( *out, x, y );
			p.rgb[0] /= 50;
			p.rgb[1] /= 50;
			p.rgb[2] /= 50;
			put_pixel( *out, x, y, p );
		}
}

// undo our leaky redaction
void unredact(image * out)
{
	pixel p;
	int x,y;

	for( x=0; x<out->width; x++ ) {
		for( y=0; y<out->height; y++ ) {
			p = get_pixel( *out, x, y);
			if(p.rgb[0] * 50 <= 256
			&& p.rgb[1] * 50 <= 256
			&& p.rgb[2] * 50 <= 256)
			{
				p.rgb[0] *= 50;
				p.rgb[1] *= 50;
				p.rgb[2] *= 50;
				put_pixel(*out, x, y, p);
			}
		}
	}
}

Did you know that Firefox has a 4096 character limit for XML nodes? I didn’t until today, and it took me quite a while to track it down! Here is the scenario: You make an AJAX request for some data, you then navigate the DOM of the returned XML data and extract the data you’re after. Something like:

function ajaxResponseHander(xml)
{
    var dataNode = xml.firstChild;
    var data = dataNode.firstChild.nodeValue;
    // now do something with the extracted data...
}

This works fine in IE, Safari, and Opera. It’ll even work fine in Firefox. That is until your data exceeds 4k. At that point you’ll only get the first 4096 characters. This is because Firefox splits any node that exceeds 4k into multiple nodes. Say, for example, you have a node with 6316 characters then you will end up having a node with the following properties:

dataNode.childNodes.length == 2;
dataNode.childNodes[0].length == 4096;
dataNode.childNodes[1].length == 2220;

Fortunately Firefox provides the textContent attribute, so we can just use:

var data = dataNode.textContent; // data.length == 6316

Although because IE doesn’t support the textContent attribute, we’re better off writing a function:

function getNodeText(xmlNode)
{
    if(!xmlNode) return '';
    if(typeof(xmlNode.textContent) != "undefined") return xmlNode.textContent;
    return xmlNode.firstChild.nodeValue;
}

I hope I’ve saved someone some pain!

I recently came across a problem in some C# code: Somebody had created a variable with the same name as an existing namespace. I wanted to refer to the namespace but I couldn’t because of the variable. An example is below:

class Test
{
    public Function()
    {
        string System = "this is a string called System";
        // the line below will cause an error, because System
        // refers to the variable above, not the "System" namespace
        System.GC.Collect();
    }
}

Obviously giving a variable the same name as an existing namespace isn’t a very good idea, and should probably be avoided at all costs. However, I was intrigued to see if it was possible to get around this issue without having to rename the variable. C# does provide a solution:

using Sys = System;

class Test
{
    public Function()
    {
        string System = "this is a string called System";
        Sys.GC.Collect();
    }
}

The line

using Sys = System;

creates an alias for the System namespace, which you can then use.

I’ve never run into this problem before because generally speaking people are sensible enough not to give their variables the same names as namespaces. I suspect this issue isn’t only a C# one though, and I’d be interested to see if there are any similar work arounds in other languages. If you know of any please leave a comment!