From SoftwarePractice.org

Contents 1 1. 2 2. 3 3. 4 4. 5 5. 6 6. 7 7.

1.

We decided to choose code 39 symbology because it was universal and simple to implement. As a group we agreed that we should attempt to finish as much of the project coding as possible, so that we would be able to explore extra more advanced avenues such as:

- The possibility of deblurring an image that may have been distorted due to lens movement, camera focus or any factor. (We managed to do this!)

- Possibly implementing the “bar code-ASCII” version of code 39 , which included in particular the entire lower case alphabet and characters such as }, { and ~. (We managed to do this too!)

- Working with images that were slanted on a 2-D and perhaps a 3-D plane. (Yet again this was done!)

- Possibly implementing the recognision of other bar code symbologies. (Ran out of time to do this...)

The advantage of choosing a simpler code, allowed our group to look into “deblurring” an image and we successfully implemented this within our set scope.

In choosing Code 39 symbology, we were also able to ultimately extend our project code to read and recognise the “full ASCII” Code 39 symbology. Which is an extension of the standard Code 39.

We were also able to recognise images that were tilted on a 2D level and also at a 3D level. That is, 2D images are tilted only in one plane at a time whereas 3D are tilted in 3 planes. This was made possible though the use of finding the lines on a tilted barcode and calibrating it with the angles found between each line (please refer to the image processing rotate function for further information).

2.

The option of having a deblur checkbox on the GUI has both advantages and limitations. The complications of deblur are thoroughly discussed in the “Image Processing Techniques” section of this wiki. If we do not know the cause of an imaged being distorted, then it is difficult to determine what process is required to restore the image into its original condition. Hence the limitation is that it will only deblur an image that has a Gaussian distributed blur (as a Gaussian random variable is used in the deblur). The advantage of this function is that those images that do have this type of blur can be deblurred and hence read.

By adding a deblur checkbox to our GUI, this creates the opportunity for the user to deblur their image if they deem necessary. However the issue with this is, deblur may distort the image even further then the original distorted image, and create an unreadable bar code. This was a risk that we took, since we believed that we wanted to extend our scope to look into deblurring images, because realistically, images may be distorted to a wide range of factors.

3.

We have discovered that images that are processed through our code will need to be at least 40KB in size. Through a process of trial and errors, we believe that the variance and noise detection parameters in our code are best suited to images of 40KB or higher. This is discussed in stage 7 of the Design Process. This is a simple limitation for our project. At the other end we have limited to size of images to [2000 2000] pixels any image greater than this will be reduced by 50% until it is smaller than this limitation. This is more a performance issue as any image larger than this will take quite a long time to process. In saying that the user is able to input a larger file, our code however, will reduce this size before the image will be read. Secondly the size of the barcode in the image is another factor, it is hard to give it quantitative values however, the barcode should be of a reasonable size, i.e. you should be able to see the bars in the barcode in the image.

4.

Similar to image size we have put another limitation on the image. The intensity of light when a barcode is photographed seems to greatly affect the outcome of image recognision.

When an exceptionally bright light or reflection is part of the image, which may be a result of a camera flash, the sun or reflection from artificial lighting, “image recognition” will find it difficult to distinguish between black and white. The light will interfere with the grey threshold, because a lot of the image, due to the intense light may fall into the “light or white” threshold, and thus it is difficult to define what a black or a bar is. This is shown below, figure 1 shows the failure to read an image that has an intense light source in it. Figure 2 shows the histogram of this image and compares it with a histogram of another image that does not have as much light. It can be seen that the bulk of the colour is concentrated in one area for the left hand picture in figure 2. Whereas, there are two separate peaks and there is a definite differentiation between black and white for the right hand picture in figure 2.

Figure 1

Figure 2

Therefore a limitation for the images is that if the bar code jpeg is created by a camera and a flash or extensive lighting is involved then the issues of defining black and white will arise. Hence, a bar code image created by a program such as “BARTENDER” or the font “free 3 of 9” would be an ideal image to process. Since no light can interfere with a data image. A future enhancement would be to detect the intensity of light in the image and account for this when setting the threshold value between a white and a black pixel.

5.

Similar to deblur, we ultimately intended to include the ability for our code to recognise a checksum digit in our bar code images. The checksum specifications were initially ignored in fear that we would not be able to implement it.

However as we slowly completed the main project code, and we discovered that the checksum was essentially a modulo 43 calculation, the checksum was then added to our code. This was again another advantage of concentrating on Code 39 symbology, because we were allowed freedom to further explore deeper into the advanced options or extras of Code 39.

6.

We are currently able to rotate an image that has been uploaded onto the GUI. However a limitation on our Image Reader is that it cannot read an image that is either sideways or upside-down, as seen from figure 3.The ratios that were set for a correct horizontal reading are not the same for the inverse. Much like the image recognisers used in everyday life, for example barcode scanners at the supermarket; we see this as an opportunity to expand the Image Recognition software to be able to recognise a Code 39 barcodes from all angles.

Figure 3

7.

Since we decided to focus solely on one barcode symbology, this also poses as a limitation for our Image reader. At this moment, our Image reader can only recognise Code 39 symbology. This could perhaps be extended to other universal codes such as Code 128, EAN 13 and 8. We have also discussed the possibility of extending our code recognition to 2D barcodes. A 2D barcode is one where data is encoded in both the horizontal and vertical dimensions. Relative to a 1D barcode whereby the data is only encoded on the horizontal. This comparison is made in figure 4.

Figure 4

To return to main page of Team B click here Bar code reading from image