This will probably be the last Journal entry for me. In less than 6 hours I will have handed in the project binder and all the documentation. All the code has been documented with the how to's of setting up and using the programs. The website is being updated and completed as I type. All that is left is to print and burn this site... to CD that is. It's been quite a semester. Good luck to all of you my friends and fellow students. Enjoy what you do, and keep it real.
Wow, who knew being the last to present could be so brutal? First off, the all of the previous presentations went over by a few minutes which added up to my presentation starting about a half-hour or so late. No big deal except for it was already 9:00pm when I started - which was when I was actually supposed to be finished giving my presentation. But the show must go on. Then there was the luck of the draw that since I was the last to present, my set up didn't go as smoothly as I would have liked. I knew it was gonna be one of those "days" when he computer rebooted after I set up everything. But I did manage to get through it in one piece after that. It's over and now I wait for the defense. Oh by the way, Great Job EveryOne. All the presentations were EXCELLENT!!!
So a very big Thank You goes out to Damian and Kevin. They helped me with my web cam processing. They were kind enough to give me some of their VB Code as a starting point. From there I was able to figure out all of the array calculations to implement my crude algorithm. Right now I have a problem with the RTLMoveMemory( ) function and consequently am restricted to using the PSet( ) function. While this is slow, it is something to show for tomorrow.
Today I had probably my last meeting with Dr. Pankratz and Dr. McVey before the presentation defense. We talked some more about the MIP-mapping and timing problems. Dr. Pankratz said to focus more on what actually was working right now and to forget about the MIP-mapping. He also pointed me in the direction of some of his own code that deals with timing down to the thousandths of a second. He called it microtime, and I used it to time the algorithms. Surprisingly enough, if the picture is small enough, even microtime can't dectect and compute a time for the algorithms. After discussing how my file processing program was working, Dr. Pankratz made a push for the real-time processing from a web cam. So now I have till the 26th to get something to work with the web cam to show for my presentation. We'll see what happens.
As it stands, the program will allow a user to open a 24-bit .bmp file and scale it using my crude method and the smooth bresenham method. When the smooth bresenham method is selected, a dialog box pops up to allow the user to set the new dimensions (in pixels) for the picture. There are also menu options to revert back to the original .bmp image and to return to the last state the picture was previously in - essentially an "undo" that takes you one step back in time. Finally the user is also able to save the file (as it is currently viewed on the screen) in the 24-bit .bmp format -> it can even be opened then by windows (outside of the program) so it is saved correctly!. Right now i am fixing the scaling to handle a shrink rather than an expansion as well as a timing method. I am currently a little fuzzy on how to approach the timing issue. The mip-mapping scheme as mentioned in the project description is proving to be a very difficult task as I am unable to find the file format of a MIP-map nor any sample C++ code which will open one for me. Most leads end in a web site that talks about mip-mapping in a game using openGL, not what I am looking for.
After a meeting with Dr. McVey, we fixed my runtime - abort error. Turns out I was accessing a two dimensional array with the array coordinates flip-flopped. One of those easily over looked, memory blowing errors. Now my crude method of scaling an image will work nicely. Now I must change the smooth bresenham procedure to work with the 2-D color arrays.
A short talk with Dr. McVey lead to another big change throughout my program. Dr. McVey noticed that I obtained the colors of pixels through multiple GetPixel()'s and SetPixel()'s. And being that this was getting the values from a memory device context, it took a little bit of time. Her solution was to store all of my values in a 2-D dynamic array. That way access to the values was quick and pretty easy too. Then when the calculations were finished, I could then set them in the memory device context only once. So now I am currently in the process of making this change in my program.
After working through Jake Mueller's code, I became familiar with his code and his bitmap class (BMPImage). I implemented some of his BMPImage class procedures to load a .bmp file. I also added my own procedure to Mueller's BMPImage class code to give it greater functionality by allowing me to get the specific colors (in COLORREF format) from individual pixels. Right now the program compiles and links with no errors, but execution ends with an abort error.
Had another meeting with Dr. Pankratz and Dr. McVey. I brought up the problem I was having when I averaged two COLORREF variables. I just wasn't getting the colors I wanted. Pankratz suggested that shifting and masking to get the individual RGB values from the COLORREF would work better. He thought it might have had something to do with the bits overflowing (carrying) from one region of the COLORREF variable to the other. Basically the blue color values were overflowing into the green values and so on. McVey had found some macros GetGValue, GetRValue, GetBValue, that could be used to extract out the RGB values from the COLORREF. I was also pointed in the direction of Jake Mueller's senior project as a starting point for code that could load and save bitmaps - something that already dealt with the bitmap header information.
Dr. Pankratz and Dr. McVey met with me to go over the Smooth Bresenham Algorithm. After a few runs through the algorithm on McVey's dry erase board, it started to make more sense. I was starting to see what the algorithm was actually doing. it was dividing the pixels in the source to fit into the new dimension of the target by doing some "tricky" math - most of which did not include divison. Looking back at the notes I took from the meeting, I began to code the Smooth Bresenham Algorithm into my existing (C++) program. Getting the algorithm working wasn't too bad, but some of the results weren't what I expected. It seemed that everytime I would averege the colors of two pixels, I would get a totally different color than either of the two pixels used. I bet this stems from the fact that I am leaving the color values from the pixels in COLORREF format. The fix to this will probably involve breaking down the COLORREF values into the separate colors: Reds, Greens and Blues. A side note from my meeting: after working through the smooth bresenham algorithm on the board, Dr. Pankratz suggested that the actual Bresenham Line Drawing Algorithm probably wasn't as good of a starting point as it looked. It was from this algorithm that the Smooth Bresenham Image Scaling Algorithm was derived, using some of the same mathematical ideas. So I have completely dropped the Bresenham Line Drawing Algorithm and turned my focus to that of Smooth Bresenham and images themselves (no more console mode).
For now I have decided to step away from Visual Basic 6.0 as my coding language and have moved into Visual C++ 6.0 with MFC. I looked to Dr. McVey's sample programs (G:\mcvebm\cs350\Programs\BitmapImage_many) that deal with loading bitmaps. I used a MemDC (Memory Device Context) to store the bitmap in memory. I do this by dynamically createing a bitmap in memory [of any size needed] and "select" it using the MemDC. I am then able to Get and Set pixel colors. This was the starting point for which I first coded my own crude scaling algorithm.
I finished coding the Bresenham Algorithm for line drawing in console mode. Now I will try to convert the line drawing algorithm to a scaling algorithm (still in console mode). I will depict images in colsole mode through groupings of characters to represent pixels. Right now the algorithm deals with static arrays, but I will be converting it into dynamic arrays shortly.
Finally held my first meeting with the professors. I met with Dr. Pankratz and Dr. McVey about the Bresenham Line Algorithm. We worked through it with an example on McVey's board. The algorithm is starting to make more sense. After the meeting, I coded the Bresenham Algorithm into console mode using C++. I also started work on a little program in Visual Basic 6.0 that would display an image and then scale it to two times the original dimensions using my own algorithm. As it currently runs, it is very slow as I get pixel colors and set pixel colors from screen to screen. And we all know that output is one of the major components of slowing down an algorithm. I will have to look into other possibilities of storing pixel colors in Visual Basic. From my Event Programming course, I know this can be done in MFC, so I am also looking at moving into Visual C++ 6.0 with MFC for image handling and manipulating.
I began initial research on my project. I have a journal, Dr. Doob's Journal (May 2002), to use as a starting point. I have created and posted the webpages on my project. Be sure to check back here for periodic updates.
Today I had my first meeting with Dr. Pankratz in which I received my capstone project: Image Scaling. We had a little discussion on the project topic, a possible approach and possible implementations (specifically citing some programming languages which I might use). After my meeting with Dr. Pankratz, I also met with Dr. McVey and Dr. Blahnik separately to discuss further the project topic and to get their opinions on programming languages to use.