Digital Picture Frame Final Report Embedded Systems Spring 2005 Samuel Toepke and Nenad UzunovicIntroduction: Digital images have replaced film in the common household, and for good reason. Film is expensive, must be bought, must be inserted into the camera, taken out, and developed. Film is expensive, and the development process is time consuming. ‘Hard’ pictures degrade over time, cannot be manipulated, are costly, take up physical space (photo albums), and can be sent only as fast as the mail can go. Digital images and cameras have vastly improved upon the old process of image capture/management. For a relatively low cost, a digital camera can be bought with a memory stick, and then all the user has to do is point and click. The user will empty the images onto a computer when he/she feels like; then have an empty memory card ready to go. The images can be archived on disk, sent around the world instantly and can be manipulated using any one of the many programs for graphics. To get digital pictures in a frame, the user will most likely print them out; then manually insert them into the frame. We are suggesting a digital picture frame that allows the user to download the picture onto the picture frame module; then have the module display the picture onto a VGA display.Hardware: 1) Personal computer that is capable of manipulating JPEGS, and equipped with a serial port. 2) XESS XSB-300E SPARTAN 2E FPGA. This is a FPGA which is sold by XESS. More information can be found here. 3) VGA monitor. 4) All necessary cables/connectors that are needed to put the pieces of hardware together. We assume that the end user has already used a proprietary digital camera to place the images onto the computer.The Flow of the project: The original idea was to implement a jpeg decoder purely in hardware. Since it was a proud work of a couple of doctorate students, we decided to move on software. After a month of trying to simplify the robust code of Independent JPEG group and run their library on the board itself, we got a permission of Prof. Edwards to use the DJPEG software and continue Software: We are using several pieces of software to get the image to its final destination on the monitor. Our test picture is a picture of Olympus, Sam’s cat. 1) DJPEG: We are using a class library called djpeg that is distributed by the Independent JPEG group. Information about them, and code, and be found here. The program takes as input a JPEG, we are using an image that is 640X480, and outputs the image in a PPM format. A PPM is a ‘portable pixel map’, and has information stored in red/green/blue values, more information here. 2) PPM2BIN: We then take the PPM file, strip the padding, and process each pixel. There are 3 bytes of color information, one byte a piece for red/green/blue. We take the first three bits of red, first three bits of green and first two bits of blue, and put them into a new color. This color will now be representative of the pixel. 3) TEST232: A program that Marcio Buss showed us how to use. It simply opens up the serial port and sends a file across the port byte by byte. 4) COMPRESS: It was taking a long time to draw the picture as we were sending a byte for each pixel across the serial cable. 307200 bytes were being sent across at 9600 baud. We decided to use a compression technique that is based on run length encoding. Since many of the adjacent pixels in a JPEG are of the same color, we decided we could create a compression program that would look ahead, and see how many pixels there are in a line that are of the same color. We will then send two bytes, the first byte with the color and the second byte with the number of pixels that are of that color. This look ahead only works for up to 256 pixels, as that is all the information that can be held in eight bits. But that is plenty anyway because (excluding test pictures with only a couple of colors) on the average repetition of the pixels with same color is less than 50. 5) MAIN.C/ISR.C: On the receiving end. These programs are set up to grab each byte as they come across the serial port. The programs take the first byte, set the color, take the second byte, and loop the number of pixels of that color. This makes picture display much faster. The technique used here is a large FIFO buffer with two pointers chasing each other. First one is the pointer to the fresh data and the second one is the pointer to the data that is being read and processed on the screen. The size of the buffer determines the flexibility of the process, increases the speed and minimizes the probability of error 6) HARDWARE SIMULATION: memoryctrl.vhd, opb_xsb200.vhd, pad_io.vhd, vga_timing.vhd, vga.vhd. These files are taken from last year’s Lab 5 and are used to control the video display.Command Log: #make download #djpeg < olympus.jpg > olympus.ppm #./ppm2bin olympus.pnm olympus.bin #./compress olympus.bin olympus.nas #./test232 < olympus.nas A user can also browse to the c_source_files and use the command: #sh ./LoadPicture.sh to run a shell script that will automatically put everything on the board and take care of all the picture manipulation. All the user has to do is rename the image ‘picturetoload.jpg’ and place it in the jpg folder. The above commands will put an image onto the VGA monitor.Continuing Implementation: Quality: The picture is noticeably fuzzy and blocky. This is because of the sampling that is being done in ppm2bin. There are ways to smooth the picture out, namely using a dithering algorithm. Dithering uses the concept of blurring, or juxtaposing, adjacent pixels to make it appear as though there is a third color. The benefits of dithering can be seen in these two pictures: The dithering algorithm can be implemented in code, but for our purposes, and under our time constraints, we decided to focus more on the speed of getting the image across. With the speed in place, it will be easier for someone to work on the quality of the picture.Conclusions: Who did what: Nenad and Sam worked on all parts of the implementation together. Each of us pushed ahead with all testing, development and troubleshooting. Lessons learned: • The FPGA has limited memory resources. We spent much time trying to strip down the DJPEG code to no functioning avail. • The serial port is terribly slow; we even kicked around transferring through USB or parallel, but did not have the time to begin
View Full Document
Unlocking...