Serge's World

This is the first part of my series on image processing, and to start off with, I will cover a relatively easy topic - how to invert the colours of an image. The full source used in the series is available from https://github.com/sjmeunier/image-processor.

Actually inverting the colours of an image – in essence, creating a negative of the image, is remarkably easy. All it entails is getting the colour of each pixel, which is broken down into red, green and blue and then subtracting each component from 255.

The Bitmap object we are using in C# uses colour components in the range of 0-255, hence why we subtract the value from 255. There is also an Alpha component to a colour, but we ignore that and just reuse the original value.

Once we have adjusted the colour components, we set the pixel to the new colour.
Read More »

The PC-GPE, or to give it its full name, the PC Game Programmer’s Encyclopedia is ancient. I can remember treasuring my copy of it I had way back in high school, and I had thought that it had disappeared.

The PC-GPE is a comprehensive collection of articles on how to program various bits of hardware with particular emphasis on games. So things like how to program a VGA card, or joystick are covered.

Most of the hardware covered would appear archaic by today’s standards, but it was a classic in its day, and still has useful nuggets in there.

Last night, Noisette (our neurotic staffie) was sleeping with Cole when she gave a single bark – which is normally her signal that she has heard something outside and wants to go investigate. When we ignored her, she came into our room and stood there next to the bed, waiting for us to notice her, for what must have been a good couple of minutes.

Then she did something I have never heard her do before. She gave a short yelp, and wanted me to follow her. She often wants us to follow her to investigate noises, but her yelp was a first, so up I got to see what was wrong.

Well anyway, she took me back to Cole’s room, and then stood looking at the window.

Lo and behold, standing on the windowsill, on the outside, was Garfield, our cat. He had managed to jump out the window, and then could not get back in, so was trapped out in the street (Cole’s room is street-facing).

The interesting thing about this whole story, is that Noisette seemed to actually show concern for the cat. I did not see the usual aggression when she was alerting us to the problem.

And to make it even more strange, Noisette and Garfield get along like…well…cat and dog. Garfield is always trying to swipe poor Noisette with her claws, and Noisette is always trying to chase Garfield. Your typical canine-feline relationship.

But I do think, after last night, that as much as they don’t get along, they are actually, deep down, fond of each other. Like most human families – they may fight a lot, but when it matters, they watch each others back.

South Africans are a bunch of avid genealogists. So much so, that the family trees of the early settlers is very well established, and for most of the white (and coloured) families in South Africa, the kinship can be proven easily and most South Africans have common blood. Heck, even I am provably related (albeit distantly) to just about every Afrikaans person in the country.

Now this is all very good for working out genealogical links, but South Africa in general has a rather large genealogical brick wall, and that has to do with beginnings of the Cape colony.

South Africa is a relatively new nation, only first being settled by European colonists at the Cape in 1652 – just over 350 years ago. And, yes, I know there were indigenous people here before that, but they play little part in my story, since I have found no trace of them in my ancestry.

South African genealogy is very well established up to the founding of the colony, but then the records go silent.

South Africans seem to be content in finding the “stamvader” (or “stammoeder”) – which roughly translates as “founding father” – which would be the first person of a particular lineage to immigrate to South Africa. So for example, one my ancestors, who is also a “stamvader” is Jacques de Savoye, who came to the Cape in 1688 with his family.

Now it is all very well and good knowing that, but then how do you go back further? Most of the settlers came from Germany, the Netherlands, France and later England, but most of their genealogies are not very well known.

There are exceptions though, such as the du Plessis’s, whose ancestry can be traced to the French aristocracy (and from there to royalty and nobility throughout Europe), and the Laubschers, who hail from Switzerland. Quite a few more can be traced back two or three generations in their native countries, but for the vast majority, the trail stops at the moment they stepped on South African shores.

Is the problem the fact that obtaining records for these people here in South Africa is difficult, since researching these families would requite digging through genealogical records scattered across Europe, or is it just that knowing who their “stamvader” was is good enough for most South Africans?

The answer to that, I do not know…

Originally posted on my old blog, Smoky Cogs on 7 Dec 2009

Resizing a bitmap and keeping the sides proportions intact - in other words keeping the same aspect ratio, we need to specify a maximum width and maximum height.

The first thing we do is get the longest and shortest dimensions and divide the one by the other. We then have the ratio of the two sides which we will use further on in the calculations.

Then, finding the new width and height, we set the new width to the maximum width, and the new height to the maximum height divided by the ratio of the sides. If however, the height was the largest side, we then set the new height to the maximum height, and the width to maximum width divided by the ratio of the sides.

Once we have done this, we can then create a new Bitmap from the old Bitmap, using the new width and height we have calculated and then return the Bitmap as the last thing we do.
Read More »

When trying to debug Javascript, objects can be a real pain, since trying to determine the value of the entire contents of the object is not entirely easy. You can access individual components of the object is quite straightforward, but more often than not, the structure of the whole object is much more useful than individual components.

Trying to find a way to do this, I found a blog mentioning a way to do this, and then modified the function quite a bit to suite my own purposes.

To use the function you just need to call the function dumpObject with the object and the maximum depth as the parameters. The function then outputs a string containing the formatted contents of the object.

The function basically just recurses through all the items in the supplied object until it either reaches the bottom or else reaches the maximum depth.
Read More »

Trying to properly show an equation on a webpage is not exactly the easiest thing to do, since it often relies on arcane symbols and odd formatting. Never fear, Google is to the rescue.

Google Charts allows you to embed many types of graphs and charts in a webpage using a simple call to the chart api.

That may be wonderful in itself, but there is an even better use for this API, and that is to render equations. All you need to know for that is a little Latex.

This is an undocumented feature so the documentation from Google on this is rather scarce, although it is rather easy to use. As an example, here is a formula for combinations

and the code required to create it is

<img src="http://chart.apis.google.com/chart?cht=tx&chf=bg,s,FFFFFF00&chco=000000&chl=\[\left(\!\!\!\begin{array}{c}n\\r\end{array}\!\!\!\right) = {n}C_r = \frac{n!}{r!(n-r)!}\]">

The chf parameter sets the background colour of the resulting image, and chco controls the foreground colour. The actual latex code is specified in the chl parameter, which can be any valid latex code. The possibilities for this are endless.

Thanks to Ryan Moulton who put up a blog post on this same topic where I first saw this feature mentioned.

Originally posted on my old blog, Smoky Cogs on 12 Nov 2009

Creating an application to draw graphs of mathematical equations has two components to it, namely, parsing the equation and drawing the results.

Parsing an equation is quite a complicated endeavor. However, I found on the internet a very useful C&$35; library that parses equations very well called dotMath by Steve Hebert. You can visit the website for the library at http://www.codeplex.com/dotMath. Rather than write my own library, I used this library to do all the parsing for me.

The fun part - for me anyway - is trying to draw the graph of an expression. I created a Windows Forms control that contains a picture box that fills the entire control. This picture box will contain the graph that we draw.

The actual generation of the image we are going to draw happens using a Bitmap object.

We set up the pens and brushes we need for the axis, graph, grid and background using the configuration settings that the class contains.

If the flag to draw the axes is set, we first draw the x and y axes, and then label it, using the scale we specify. The offset allows us to move the graph so that the centre of the screen does not need to be the position (0,0), which is the default. The LabelIncrement determines how many pixels apart the labels need to be. If we set the draw grid flag to true, we also draw a grid, which will make it easier to see what value the graph shows. Drawing the axes and grid works by taking the centre point and working out along each axis to the end of the screen.
Read More »

The interleaved 2 of 5 barcode uses an scheme which alternates using bars and spaces to encode data with narrow and wide bars (or spaces). The encoding is further split up into odd and even encodings.

The interleaved 2 of 5 barcode does not require a checksum digit, and can be any length.

The left and right guard bars are 1010 and 01101 respectively, and the digts are encoded alternatively with the odd and even encodings.

The standard 2 of 5 barcode format encodes all of the information in the bars, and only uses the spaces for spacing purposes, unlike all the other barcodes we have looked at so far, and is used mostly in warehouses and airline ticketing.

To calculate the checksum digit, working through the digits from right to left, you add up the odd-positioned elements and even-positioned elements separately. We then find the checksum by 10 - ((((3 * odd) + even) modulo 10) modulo 10).

Using this full string then we apply the encoding, where a narrow bar is defined by 11 and a wide bar with 111111. The left guard is 1111011110110 and the right guard is 1111011011110.

The encodings for each digit is as follows