Nawwar Kabbani's blog

A couple of hours ago, while “slashdotting” as usual, I read what I found a fascinating example of a debate between two groups of people about whether a particular behavior of some image scaling algorithms used by most popular image viewing and editing tools (GIMP, Photoshop, Firefox, …) is a bug or not. The story of this image scaling “bug” was slashdotted. In fact, the main article gives you a nice example of the phenomenon, but if you read the comments on slashdot you might understand the problem easier, because the main article is too verbose and somewhat complicated.

My example!

Before I explain the issue, I’ll give my own example that I just created with a script I wrote and a couple of my own images!
The picture on the side (—>) is mine! It contains a hidden message. I’m not sure how the picture would look on other monitors, but on my laptop monitor, which is LCD, I can’t see the message normally unless I look at the screen from a very extreme angle from up or down since it’s LCD. On a CRT monitors, looking from different angles doesn’t change anything. I expect to hear that some people can read the message easily from the first look. Anyway, the example become interesting if you try to scale the image down 50%. This can be done easily with Firefox by pressing Ctrl+(-) (Control and minus) 4 times, or by holding control and scrolling up with the mouse. You can also try to open the image with your favorite image viewing or editing program and scale it down by 50%. I’d like to know your results using different programs.

So what happens?

Briefly, the issue comes from the fact that the human eye, combined with a specific monitor, doesn’t have a “linear” sensitivity for different scales of gray (or colors, generally speaking). Or, from another perspective, the way colors (or luminosity level) represented in digital computers is linear /or/ doesn’t match the non-linearity of the eye+monitor.
For example, black is usually represented as number 0, while white is 255. If we have an image with pixels alternating between black(0) and white(255), and we want to scale the image down to half size, most scaling algorithm (linear, cubic, except for nearest neighbor) will give you an image with pixel values of 127, a scale of gray that is supposed to be mid-point between black and white. However, if you look at the original image with your eye, it would appear lighter than the 127-grey image. In fact, it would look more like 186-gray level (depending on monitor).

How I created the image?

Briefly speaking, the example images you’ve seen, the one here and the ones in the original article, had an average value of pixels of 127, but each two adjacent pixels had a difference in value proportional with the pixel values of the original picture. Therefore what was a white color in the original picture, was presented as black(0) and white(255) pixels, which the eye will perceive as light-gray(186). Whereas what was black in the original picture, was represented by two grey(127) pixels, which the eye will perceive as (darker) gray(127).

Isn’t that a bug?

Yes and no!
If you think this is a problem that will reduce the value of the image editing program your using, then it’s a bug. If you think it doesn’t change anything for you, then it’s not a bug, at least not for you. A question whether something is a bug or not is not always obvious, in fact it’s a hard to decide more often than what most people think. Prof. Cem Kaner, in his Black Box Testing course / Bug Advocacy, has nice examples about the differences between bugs and features, and why it’s such subtle question to answer.
To me, this issue is not a bug. Real life pictures are different from the ones you’ve seen in this article and the original article. The examples you’ve seen are very specially crafted and produced by computers to expose the issue. In real pictures, the vast majority of adjacent pixels have very close values. So it won’t make any different if gamma correction was considered, That is, whether the average of (150 and 154) is 152 or 152.3, both cases will look exactly identical on the screen. Even when it happens that two adjacent pixels have a big difference in value, it’s still not a significant error in my humble opinion. There are a lot of sources of image errors and distortions much more severe that make this little error look really negligible, for example does the monitor have a correct gamma factor in the first place? And what about JPEG compression errors, etc.

The Workshop on Teaching Software Testing (WTST) came to an end on Sunday after amazing 3 days of hot talks and open discussions. It was my great pleasure to attend the workshop for the second time, but this time as a presenter, not just an attendee as last year.
The workshop is hosted every year by my professor Cem Kaner, Scott Barber, and Rebecca Fiedler. Notable testers from the industry and the academia attend each year. This year’s notable attendee were Daniel Hoffman [U. Victoria], Morven Gentelman [Dalhousie U.], Doug Hoffman [Software Quality Methods], Jon D. Hagar [Lockheed Martin], Michael Bolton [DevelopSense], Peter Clarke [Florida Int. U.], Tao Xie [NCSU], Jim Kiper [Miami U.], Javier Tuya [U. de Oviedo], and Mike Smith [U. Calgary].
WTST is not a conventional workshop. A presentation might take over an hour, or as short as 5 minutes. Discussions then might take anything from 1 minute up to several hours. There were cases in the past where one presentation provoked discussions for the whole day and even night. That’s why it’s tough! Nobody can get away easily with a mediocre presentation and arguments.
This year I presented an experience report about teaching software testing 2 course at Florida Tech. This course is concerned with teaching glass/white-box testing techniques, Test-Driven Development/Design (TDD), Agile methodologies, and related topics. More details about the course and our experience in it are published in my WTST paper.
The presentation I gave seemed to provoke a lot of thinking. I got several compliments from people such as Dan, Morven, Doug, and Scott, about my talk; particularly about the example I gave to explain the impact of knowing the code on how we test. I feel very honored that some of them told me they’d use my example in their classes.
Overall, I learned a lot from the workshop. I enjoyed every talk, and all the discussions. I hope to repeat the experience again

In one of my class assignments recenly, I needed to download historical stock prices from Yahoo and import them to a MySQL database in order to run my own back-testing algorithms. So I created a simple bash script for this purpose, and I thought I could share it with the World Wide Web! :p I’m pretty sure many people will find it useful. All you have to do is:

1. Create a bash script with your preferred text editor, let’s name it “import.sh“, with the following code:

#!/bin/bash
#This script will download Financial data of stocks entered on the standard input.
#The downloaded CSV files will then be imported into MySQL database using mysqlimport tool

#Enter your database parameters here
DB='DB_NAME'
HOST='DB HOSTNAME'
USER='USERNAME'
PASS='DB PASSWORD'
TAB_PREFIX='yahoodata_'

DB_PARAMS="-u ${USER} -h ${HOST} -p${PASS} ${DB}"
CREATE="DROP TABLE IF EXISTS ${TAB_PREFIX}_SYMBOL_; CREATE TABLE ${TAB_PREFIX}_SYMBOL_ (day DATE PRIMARY KEY, open DECIMAL(8,3), high DECIMAL(8,3), low DECIMAL(8,3), close DECIMAL(8,3), volume BIGINT, adj_close DECIMAL(8,3))"
URL='http://ichart.finance.yahoo.com/table.csv?s=_SYMBOL_&d=0&e=25&f=2010&g=d&a=2&b=13&c=1986&ignore=.csv'

while read SYMBOL; do
  wget -O "${TAB_PREFIX}${SYMBOL}.csv" -q "${URL/_SYMBOL_/$SYMBOL}"
  mysql -e "${CREATE//_SYMBOL_/$SYMBOL}" ${DB_PARAMS}
  mysqlimport --columns=day,open,high,low,close,volume,adj_close -L --ignore --fields-terminated-by=, --ignore-lines=1 ${DB_PARAMS} "${TAB_PREFIX}${SYMBOL}.csv"
done

2. Edit the first 4 lines according to your MySQL connection settings. You can also choose a table prefix for your data table in line 5. Then save the file.

3. Give your script execution permissions:

~$ chmod u+x import.sh

4. If you want to specify the stocks to download manually, just go ahead, run the program, and start typing stocks symbols in the command line. Hit Ctrl+D when done.

~$ ./import
MSFT
GOOG

5. If you have a list of symbols that you want the program to download and import automatically into the database, you can forward the file to the standard input of the script. Let’s say SP500.txt contains a list of the S&P 500  company symbols, each on a line, then run:

~$ ./import < SP500.txt

Et Voilà! Now you should have a table with historical data created for each stock in the S&P500 index.

You might wonder how to obtain a list of S&P 500  stock symbols. With a quick googling I couldn’t a text file that matches the requirements of this program (that is, just the symbols, one on a line). I’m pretty sure someone out there has the required file. However, there are gazillions of web pages that give you the list in other formats. But you need extract them with the desired format.

For convenience, Here’s my S&P500 list of symbols file.

Here is my lecture in Dr. Scott Tilley‘s class “Introduction to software engineering”. He wanted me to give a simple introduction to what it means testing SOA security – the topic of my thesis. It wasn’t easy making such a deep topic easy for sophomore students. However, contrary to what I had thought,  I saw a lot of activity and interest from the students. And  I  got very positive feedback from the professor and some students   The presentation may look very concise, but there were a lot of talking behind it! I ended up the class with a small demonstration of using soapUI to test a weather service.

soa-security-testing

This is my first lecture in Software Testing II class (glass-box testing). It’s a quick introduction to JUnit 4. Hopefully some people might find it useful.  JUnit 4 Tutorial (pdf)

Hey! This is my first blog post! Will delete it soon