|
1 | 1 | # Project Tour |
2 | 2 |
|
3 | | -* notes: |
4 | | -* > Discuss about your project file structure |
5 | | -* > what each folder is responsible |
6 | | -* > then go through each file in folders and explain there purpose |
7 | | -* > if possible create a doc system ( there are autogen docs available for most of the languages ) |
8 | | -* > decide coding style , linting style and formatting style and other themes like variable naming etc. |
9 | | -* > provide an example for existing function and tests system if possible |
10 | | -* |
11 | | - |
12 | | -# MAKE SURE PROJECT MANAGERS UPDATE THIS MD |
| 3 | +## Understanding Files |
| 4 | + |
| 5 | +### bmp.h |
| 6 | + |
| 7 | +Open up bmp.h (as by double-clicking on it in the file browser) and have a look. |
| 8 | + |
| 9 | +You’ll see definitions of the headers we’ve mentioned (BITMAPINFOHEADER and BITMAPFILEHEADER). In addition, that file defines BYTE, DWORD, LONG, and WORD, data types normally found in the world of Windows programming. Notice how they’re just aliases for primitives with which you are (hopefully) already familiar. It appears that BITMAPFILEHEADER and BITMAPINFOHEADER make use of these types. |
| 10 | + |
| 11 | +Perhaps most importantly for you, this file also defines a struct called RGBTRIPLE that, quite simply, “encapsulates” three bytes: one blue, one green, and one red (the order, recall, in which we expect to find RGB triples actually on disk). |
| 12 | + |
| 13 | +Why are these structs useful? Well, recall that a file is just a sequence of bytes (or, ultimately, bits) on disk. But those bytes are generally ordered in such a way that the first few represent something, the next few represent something else, and so on. “File formats” exist because the world has standardized what bytes mean what. Now, we could just read a file from disk into RAM as one big array of bytes. And we could just remember that the byte at array[i] represents one thing, while the byte at array[j] represents another. But why not give some of those bytes names so that we can retrieve them from memory more easily? That’s precisely what the structs in bmp.h allow us to do. Rather than think of some file as one long sequence of bytes, we can instead think of it as a sequence of structs. |
| 14 | + |
| 15 | + |
| 16 | +### filter.c |
| 17 | + |
| 18 | +Now, let’s open up filter.c. This file has been written already for you, but there are a couple important points worth noting here. |
| 19 | + |
| 20 | +First, notice the definition of filters on line 10. That string tells the program what the allowable command-line arguments to the program are: b, g, r, and s. Each of them specifies a different filter that we might apply to our images: blur, grayscale, reflection, and sepia. |
| 21 | + |
| 22 | +The next several lines open up an image file, make sure it’s indeed a BMP file, and read all of the pixel information into a 2D array called image. |
| 23 | + |
| 24 | +Scroll down to the switch statement that begins on line 101. Notice that, depending on what filter we’ve chosen, a different function is called: if the user chooses filter b, the program calls the blur function; if g, then grayscale is called; if r, then reflect is called; and if s, then sepia is called. Notice, too, that each of these functions take as arguments the height of the image, the width of the image, and the 2D array of pixels. |
| 25 | + |
| 26 | +These are the functions you’ll (soon!) implement. As you might imagine, the goal is for each of these functions to edit the 2D array of pixels in such a way that the desired filter is applied to the image. |
| 27 | + |
| 28 | +The remaining lines of the program take the resulting image and write them out to a new image file. |
| 29 | + |
| 30 | + |
| 31 | +### Helpers.h |
| 32 | + |
| 33 | +Next, take a look at helpers.h. This file is quite short, and just provides the function prototypes for the functions you saw earlier. |
| 34 | + |
| 35 | +Here, take note of the fact that each function takes a 2D array called image as an argument, where image is an array of height many rows, and each row is itself another array of width many RGBTRIPLEs. So if image represents the whole picture, then image[0] represents the first row, and image[0][0] represents the pixel in the upper-left corner of the image |
| 36 | + |
| 37 | + |
| 38 | +### Helpers.c |
| 39 | + |
| 40 | +Now, open up helpers.c. Here’s where the implementation of the functions declared in helpers.h belong. But note that, right now, the implementations are missing! This part is up to you. |
| 41 | + |
| 42 | + |
| 43 | +### Compile |
| 44 | +Paste This in you Terminal(without quotes): |
| 45 | + |
| 46 | + "gcc -g -std=c11 -Wall -Wextra -Wshadow filter.c helpers.c -o filter -lm" |
| 47 | + |
| 48 | + |
| 49 | +### Run |
| 50 | +Paste This in you Terminal(without quotes) |
| 51 | +1. For grayscale: |
| 52 | + |
| 53 | + "filter -g in.bmp out.bmp" |
| 54 | + |
| 55 | +2. For blur: |
| 56 | + |
| 57 | + "filter -b in.bmp out.bmp" |
| 58 | + |
| 59 | +3. For reflect: |
| 60 | + |
| 61 | + "filter -r in.bmp out.bmp" |
| 62 | + |
| 63 | +4. For sepia: |
| 64 | + |
| 65 | + "filter -s in.bmp out.bmp" |
0 commit comments