The Truth About Lena

If you are a Computer Science student, an Electrical Engineering student, or just someone who works in Image Processing, you must have seen and worked on this picture:

Her name is Lena. But almost everyone who had seen this image knows almost nothing about her other than the fact that the image is a great test image because it contains a nice mixture of detail, flat regions, shading, and texture that do a good job of testing various image processing algorithms, and that she makes gentlemen drool- let’s face it, geeks do not get to see that kind of attractive ladies often- and ladies jealous! But really, who is Lena? And how did she become a standard in the boring field of Image Processing?!!

Her name is Lena Söderberg, a Swedish model born in March 31st, 1951. Lena posed for the November 1972 issue of the Playboy Magazine. The image used nowadays in Image Processing is actually the same image posted in the magazine- cropped, of course.

It was in June or July of 1973 when Alexander Sawchuk, who was then an assistant professor of electrical engineering at the University of Southern California Signal and Image Processing Institute (SIPI), a graduate student, and the SIPI lab manager were searching the lab for a good image to scan for a colleague’s conference paper after they got tired of the usual test images. They wanted some image of a human face that would produce an output with a good dynamic range. It was only then when someone walked in the lab with a recent issue of Playboy. In Lena’s picture, they found exactly what they needed.

The engineers tore away the top third of the centrefold so they could wrap it around the drum of their Muirhead wirephoto scanner, which they had outfitted with three analog-to-digital converters -one for each colour channel- and a Hewlett Packard 2100 minicomputer. The Muirhead had a fixed resolution of 100 lines per inch and the engineers wanted a 512 × 512 image, so they limited the scan to the top 5.12 inches of the picture, effectively cropping it at the Lena’s shoulders. This scan became one of the most used images in computer history, so much that Lena was called the First Lady of the Internet, and was a guest at the 50th annual Conference of the Society for Imaging Science and Technology in 1997. Someone even wrote her a poem:

Sonnet for Lena

O dear Lena, your beauty is so vast
It is hard sometimes to describe it fast.
I thought the entire world I would impress
If only your portrait I could compress.
Alas! First when I tried to use VQ
I found that your cheeks belong to only you.
Your silky hair contains a thousand lines
Hard to match with sums of discrete cosines.
And for your lips, sensual and tactual
Thirteen Crays found not the proper fractal.
And while these setbacks are all quite severe
I might have fixed them with hacks here or there
But when filters took sparkle from your eyes
I said, “Heck with it. I’ll just digitize!”

Now that the truth is out there, I can almost hear the voices of the radical, extremist Muslims calling for the ban of the use this image and probably killing, then dismembering and burning the corpse of our dean for using it in our Computer Vision curriculum! At some point in the near past, there were also voices calling for retiring the Lena image. That’s because publications of the kind of Playboy are degrading to women. Give me a break! This is just pathetic! We are not using the FULL image of Lena- forgive me for not posting it; extreme content- we are only using a cropped image of a nice looking girl that only shows a face and a shoulder. What is female-degrading or anti-Islamic about that? The source of the image? Newsflash, Mr. Extremist; not we, IEEE, nor any other organization that uses the image for any purpose pays a fee for the Playboy organization in exchange for the use of it, Playboy even waved away its copyrights to this specific image. In other words, it belongs to nobody, so we are not sponsoring the work of Satan!

I know that I will be personally criticized and attacked for my opinion, and I do not really care. Bottom line is, Lena’s image is perfect for testing Image Processing techniques, and until the radicals camp blesses us with another image to use that will not send us burning in hell for eternity, I will continue to use it. Even though I am sure that the proposed new image will be something like this! Not much dynamic range there, no?


NetBeans Refactoring – Part 2

Greetings my fellow programmers! Now that NetBeans 6.8 is released, I decided that this would be the best time to post part two of my NetBeans refactoring tutorial. I highly recommend reading part one before reading this post. Read it here.

The following Java class will be used to illustrate the refactoring techniques in this post:

public class FruitStand {
 int quantity;
 double pricePerUnit;
 double totalPrice = (pricePerUnit + 12.5) * quantity ;
 String[] merchandise = new String[100];

 public void insertIntoDB(String[] names) {
  for (int i = 0; i < names.length; i++)
   names[i] = names[i].toUpperCase();

  // Rest of method...

 public class Apples {
  int quantity = 500;
  double pricePerUnit = 5.99;

Some of the images here are not very clear because of page size limitations. You can click on any image to see it in full size.

Extract Interface:

Extract Interface refactoring allows you to select public non-static methods and move them into a separate interface. This can make your code more readable and maintainable. Suppose you want to extract the insertIntoDB method into an interface:

Note that the class FruitStand now implements NewInterface, and that NewInterface has appeared in the package:

Extract Superclass:

Extract Superclass refactoring works exactly the same way as Extract Interface refactoring. However Extract Superclass moves the methods to a new superclass and extends the refactored class (the one from which the methods were pulled). Repeating the same process we did in Extract Interface:

Move Inner to Outer Level:

Move Inner to Outer Level refactoring converts an inner class to a separate external class declared in its own file. It also gives you the option to declare a field for the current outer class. Here, I am going move the inner class Apples to a separate external class:

You can specify a new name for the class that is being moved and optionally, you can select to declare a field for the current outer class and enter a name for that field:

Note that the inner class Apples has disappeared from class FruitStand, and that a new class Apples has appeared in the package:

Introduce Constant:

Introduce Constant refactoring allows you to change a value used in your code into an individual constant. Assume that the owner of the fruit stand decided to deduct 12.5£ from each unit she sells (her business is not paying well!). So, the value of 12.5 will be declared as an individual constant by first highlighting it then choosing Introduce Constant:

You can also choose the name and the access modifier for the newly created constant:

And voila! The constant is declared and used in the statement where 12.5 was used:

Introduce Method:

Sometimes in your code, you notice that there are certain sections that contain similar blocks of code. Introduce Method refactoring can extracts these code fragments into a separate method that can be called anywhere. This makes the code more readable and easier to maintain. Assume that the fruits in the inventory are submitted into a database, but before doing so, their names must be written in upper case letters (it is stupid, I know!). The for loop inside the insertIntoDB method does that. You find out later that you need to do this operation again somewhere else in the code. Instead of writing it again, you can simply extract it into a separate method. To do this, highlight the code you want to convert to a method and choose Introduce Method:

As in Introduce Constant, you get to choose the method name and its access modifier:

And there you go! The method is declared and called where the piece of code was previously written:

Note that your code selections must meet the following criteria:

  • Selections cannot have more than one output parameter.
  • Selections cannot contain a break or continue statements if the corresponding target is not part of the selection.
  • Selections cannot contain a return statement that is not the last statement of the selection. The selected code is not allowed to return conditionally.

Encapsulate Fields:

When developing object-oriented code, it is almost a standard to give the fields (variables) private access, and use public methods to change their values or retrieve them- mutator (setter) and accessor (getter), respectively. Encapsulate Fields refactoring allows the automation of this process; it generates getter and setter methods for the desired fields, enabling the changing of the access modifier for those fields and the accessor methods. To illustrate this, I will encapsulate the quantity and pricePerUnit fields:

You can choose which fields to encapsulate and change the visibility modifiers of the fields and accessors:

After clicking Refactor, you will note that accessors and mutators of the chosen fields were added to your code:

And that is it. Hope you enjoyed this two-part tutorial. If you have any question or comment, do not hesitate to contact me or leave a comment here. See you later with another Significant Insignificane tutorial. Cheers!


Things That Not All Programmers Know #2: Handling Mouse Wheel In JavaScript

Everyone who has been on the Web even a little knows the importance of the use of mouse wheels, scrolling pages, zooming in Google Maps, mouse wheel gestures in Opera 9 browser, and many more. It is almost impossible now to find a mouse without wheel. However, not many Web applications’ developers know how to make smart use of mouse wheel. Therefore, I decided to make this little tutorial to provide general information on how to handle mouse-wheel-generated events in JavaScript.

There are some images that are not very clear because of page size limitations. You can click on any image to see it in full size.

First, the thing you should know about mouse wheels is that they do not have an absolute system. Therefore, the only way to capture the wheel actions is via a parameter called delta, which is the mouse wheel angle changes. The delta parameter takes positive and negative values; if the wheel is scrolled up- which means the page is scrolled down- delta is positive, if the wheel is scrolled down- which mean the page is scrolled up- delta is negative. The handle function takes on that delta parameter. This function should be modified by you to handle the wheel actions:

High Level Function

The actual values of delta depend on the sensitivity of the mouse. However, for optimization, the code is adjusted so that the values of delta are either -1 or +1. Also note that delta takes different values between the Internet Explorer, Opera, and Mozilla Firefox browsers. For example, in Opera and Firefox, delta takes a different sign than that of Internet Explorer, and in Firefox, the value of delta is always a multiple of 3. Here is the event handler code:

Event Handler Function

The following part is optional. This piece of code is to prevent the default actions caused by the mouse wheel. You may want to do that because you are already handling scrolls somehow:

Handling Default Actions

The initialization code:

Initialization Code

And that is it. Now you can handle mouse wheel actions easily anyway you want using the handle function. Note that this code has been tested only with recent versions of Internet Explorer, Mozilla Firefox, Opera, and Safari browsers. I have no idea if it will work with other browsers or not.

Hope this was useful. I would really love it if you tried it and sent me your feedback. And again, if you know a good programming trick that you believe not many people know, please let me know. Wait for a new programming trick next month. Until then, happy coding!