C How to Read Bytes of a Image

Due 11/18

Image files

Goals

The goals of this assignment are equally follows:

1. Learn how to program with binary files
2. Do using structures

// Credit: Prof. Yung-Hsiang Lu and Prof. Cheng-Kok Koh created earlier assignments upon which this one is based. Text from that consignment has been copied with permission.

Overview

In this exercise, you lot will write lawmaking to read, write, and crop BMP image files.

HW14 will require your working code from HW13. Writing perfect, clean code on this assignment and testing it very well volition make your life a lot easier on that assignment, which will be somewhat more challenging than this one.

The BMP file format

A BMP file has the following format:

Header	54 bytes
Palette (optional)	0 bytes (for 24-bit RGB images)
Prototype Data	file size - 54 (for 24-bit RGB images)

The header has 54 bytes, which are divided into the following fields. Note that the #pragma directive ensures that the header construction is actually 54-byte long by using 1-byte alignment.

typedef struct {                uint16_t  type;                uint32_t  size;                uint16_t  reserved1;           uint16_t  reserved2;           uint32_t  first;              uint32_t  dib_header_size;     int32_t   width_px;            int32_t   height_px;           uint16_t  num_planes;          uint16_t  bits_per_pixel;      uint32_t  compression;         uint32_t  image_size_bytes;    int32_t   x_resolution_ppm;    int32_t   y_resolution_ppm;    uint32_t  num_colors;          uint32_t  important_colors;  } BMPHeader;

Note that the number of bytes each field occupies tin be obtained by dividing the number 16 or 32 by eight. For case, the field "type" occupies ii bytes. These fields are all integers. An "uint" means unsigned, and "int" means signed. For example the fields "width" and "height" are signed integers. However, for simplicity, all the BMP files we take will incorporate only positive integers. You may assume that in your lawmaking. Also, we are dealing wih uncompressed BMP format (compression field is 0).

Considering of the packing specified in the bmp.h file, you lot should be able to use fread to read in the first 54 bytes of a BMP file and store 54 bytes in a BMPHeader structure.

Among all these fields in the BMPHeader structure, you accept to pay attention to the post-obit fields:

bits	number of bits per pixel
width	number of pixel per row
height	number of rows
size	file size
imagesize	the size of image data (file size - size of header, which is 54)

Nosotros will further explain $.25, width, height, and imagesize later. Yous should use the following construction to shop a BMP file, the header for the first 54 bytes of a given BMP file, and data should point to a location that is big enough (of imagesize) to shop the paradigm information (color information of each pixel).

typedef struct {     BMPHeader header;     unsigned char* data;  } BMPImage;

Effectively, the BMPImage structure stores the entire BMP file.

Now, let'southward examine the fields bits, width, meridian, and imagesize in greater details. The bits field records the number of bits used to represent a pixel. For this do (and the adjacent exercise and assignment), we are dealing with BMP files with only 24 bits per pixel or 16 $.25 per pixel. For 24-bit representation, 8 bits (i byte) for Cerise, eight bits for Dark-green, and 8 bits for BLUE. For 16-bit representation, each color is represented using five $.25 (the near significant flake is non used). For this practice, we volition utilise only 24-bit BMP files to test your functions. However, your lawmaking should be able to handle sixteen-scrap format also. (Note that the header format is actually more complicated for 16-bit format. However, for this do and the adjacent do and consignment, we will employ the same header format for both 24-scrap and 16-bit BMP files for simplicity. And so yes, we are abusing the format!)

The width field gives you the number of pixels per row. Therefore, the full number of bytes required to stand for a row of pixel for a 24-flake representation is width * 3. However, the BMP format requires each row to be padded at the end such that each row is represented past multiples of 4 bytes of data. For instance, if at that place is only one pixel in each row, we need an boosted byte to pad a row. If there are two pixels per row, 2 boosted bytes. If there are three pixels per row, 3 additional bytes. If there are four pixels per row, we don't have likewise perform padding. We require you lot to assign value 0 to each of the padding byte.

The summit field gives you the number of rows. Row 0 is the bottom of the image. The file is organized such that the bottom row follows the header, and the height row is at the end of the file. Within each row, the left most pixel has a lower index. Therefore, the start byte in data, i.e., data[0], belongs to the bottom left pixel.

The imagesize field is height * amount of data per row. Note that the corporeality of appointment per row includes padding at the finish of each row.

You can visualize the one-dimensional data every bit a three-dimensional array, which is organized equally rows of pixels, with each pixel represented by 3 bytes of colors (24-bit representation) or 2 bytes of colors (16-flake representation). However, because of padding, y'all cannot easily typecast the ane-dimensional data as a three-dimensional array. Instead, you lot can beginning typecast it as a two dimensional assortment, rows of pixels. For each row of data, you lot can typecast it every bit a two-dimensional assortment, where the beginning dimension captures pixels from left to correct, the second dimension is the color of each pixel (3 bytes or 2 bytes).

The Wikipedia article on the BMP file format has a dainty diagram and more than complete details about this format.

Handling run-time errors

In this assignment, you will need to handle run-time errors. These are not the same as bugs in your code. These are problems (or special weather) that might arise due to the inputs from the caller of a function that you write. For example, a file may be inaccessible or decadent, or malloc(…) may fail and render Nada.

For purposes of this assignment, the error-handling strategy will be two-pronged:

1. Return a special value if the operation failed. For functions that return a FILE*, you will return Zilch if the operation failed.
2. Return an error message via laissez passer-by-address. Unremarkably, the caller will pass the address of char*. If the operation is successful, the callee will do cypher with information technology. Nevertheless, if there is a failure, the callee volition return a newly heap-allocated string. Information technology is the caller's responsibleness to free information technology.

You will do this for all functions in this consignment that take a parameter called fault.

Here is a sketch of the basic blueprint we are describing:

#include <stdio.h> #include <stdlib.h> #include <stdbool.h> #include <assert.h>  bool do_something(int a, int b, char** error) {   // ...    if(success == false) {     if(*error == Zip) {       char* message = "do_something(..) failed because success == false";       *error = malloc((strlen(message) + ane) * sizeof(**error));       strcpy(*fault, bulletin);     }     render false;   }    // ...    return true; } int principal(int argc, char* argv[]) {   char* error = NULL;   bool do_something_succeeded = do_something(x, 11, &error);   if(! do_something_succeeded) {     fprintf(stderr, error);     affirm(error != Cypher);     costless(mistake);     return EXIT_FAILURE;   }   else {     affirm(error == NULL);   }   return EXIT_SUCCESS; }

EXIT_SUCCESS and EXIT_FAILURE are constants defined as 0 and 1, respectively, in stdlib.h. Although we oasis't been using these so far in ECE 264, they are actually better than simply returning 0 and 1.

Warm-upward exercises

This assignment includes a warm-up exercise to assistance yous go fix. This accounts for xx% of your score for HW13. Scoring will exist relatively light, but the usual base requirements apply.

1. Read a text file
   Create a part that reads the contents of a file and returns it as a string on the heap. The caller is responsible for freeing that retention. Utilise fopen(…), fread(…), and fclose(…).
2. Write a text file
   Create a function that writes the given content to a file at the specified path. Use fopen(…), fwrite(…), and fclose(…).
3. Write a Point to a binary file
   Write a role that writes a single Signal to a binary file at the specified path. Use fopen(…), fwrite(…), and fclose(…). For the Point grade, please copy-paste the following struct type into your file:

                 typedef struct { int x; int y; } Point;            

   This volition be a binary file. This is grooming for working with binary files for images, which piece of work the same style. In general, you will employ fwrite(…) for binary files.

4. Read a Betoken from a binary file
   Create a role that reads a Point from the binary file at the specified path into a Indicate on the stack. No malloc(…) or free(…) are necessary for this one. Use fopen(…), fread(…), and fclose(…).

The structure of the warmup.c file is described in the Requirements table below. Yous should write your ain warmup.c. Y'all may add together helper functions, if y'all wish.

Opt out.

In a hurry, and don't need the practise? This warm-upwardly is here to help yous learn what you need to succeed on the balance of this assignment—not to add boosted work. Therefore, nosotros give you lot an option. Those who feel that they exercise non need the practice may "opt out". by modifying warmup.c and so that it does nix but print the following message exactly and then leave:

I already know this and exercise not demand to exercise.

If you do that, then your score for HW13 will exist based solely on the rest of this assignment. If you exit the warmup.c undone, if you do non plough in a warmup.c, or if the bulletin it prints does not friction match perfectly, and then you will receive 0 for the warmup portion of this consignment (20%).

Test-driven development

Apply test-driven development to practice this assignment incrementally. At least 12 stages must be explicitly marked with comments in your chief(…) in test_bmp.c. It volition expect like to this:

int primary(…) {   // Stage 00:     //     // Stage 01:     //     // Stage 02:     //     …    // Stage 11:     //     …    return 0;  }

This aspect of the assignment will exist checked, simply only to the degree that we can exercise so efficiently (i.e., perhaps very lightly). Nevertheless, y'all should follow it in earnest for your own do good.

Call up: Your code should never be broken for more than about 10-15 minutes at a time.

bmp.h and exam files

We accept provided a bmp.h file and some test image files. You must employ our bmp.h. To obtain these, run 264get hw13. You may utilise other BMP epitome files of your choice*, but not all BMP files will work with this code (e.g., grayscale, other colour depths, etc.), so your may wish to stick with the supplied files to test.

Whatever image files that yous turn in must be G-rated and non violate any copyrights (i.due east., your own images or else freely licensed). Provide credit in your bmp.c file in the grade of a comment similar:

// Credit:  blahblah.bmp, Fetty Wap, http://fettywap.com/free_photos/blahblah.bmp

Requirements

In all functions that take FILE* fp, you may presume that it is valid and open in the correct manner. Nevertheless, y'all may non assume anything nearly the corporeality of data. Besides, you may not presume that every call to fread(…) or fwrite(…) will succeed.

In all functions that accept char** error, you must handle run-time errors as described in the section above (Handling run-time errors).

1. Your submission must incorporate each of the post-obit files, as specified:

file	contents
bmp.c	functions	readbmp(FILE✶ fp, char✶✶ error) → return blazon: BMPImage✶ Read a BMP image from an already open up file. Return the image equally a BMPImage on the heap. Utilize your check_bmp_header(…) to check the integrity of the file. Handle all kinds of run-fourth dimension errors using the method described above. That means in case of an error, set *error to the accost of a descriptive message on the heap and render Null. It is the caller's responsibility to gratis the memory for the error bulletin. Practice not leak retentivity nether any circumstances. Do not attempt to open or close the file. Information technology is already open. fopen(…) and fclose(…) are not allowed in bmp.c. (Come across the tabular array of allowed functions/symbols below.)
		checkbmpheader(BMPHeader✶ bmphdr, FILE✶ fp) → return type: bool Test if the BMPHeader is consistent with itself and the already open up image file. Render true if and only if the given BMPHeader is valid. A header is valid if ① its magic number is 0x4d42, ② image data begins immediately subsequently the header information (header -> starting time == BMPHEADERSIZE), ③ the DIB header is the right size (DIB_HEADER_SIZE), ④ there is only ane epitome plane, ⑤ there is no compression (header->pinch == 0), ⑥ num_colors and important_colors are both 0, ⑦ the image has either 16 or 24 $.25 per pixel, ⑧ the size and imagesize fields are right in relation to the $.25, width, and height fields or the file size.
		writebmp(FILE✶ fp, BMPImage✶ image, char✶✶ mistake) → return blazon: bool Write an prototype to an already open file. Return true if and only if the performance succeeded. Handle run-time errors using the method described above. That means in case of an error, set *error to the accost of a descriptive message on the heap and return false. It is the caller's responsibility to free the retentivity for the error message. This should non close the file. Do not leak memory under any circumstances. Practise non attempt to open or close the file. It is already open. fopen(…) and fclose(…) are not allowed in bmp.c. (See the table of immune functions/symbols below.) Y'all may assume the file is initially empty.
		gratisbmp(BMPImage✶ image) → return blazon: void Free all retention referred to by the given BMPImage.
		cropbmp(BMPImage✶ paradigm, int ten, int y, int westward, int h, char✶✶ error) → render type: BMPImage✶ Create a new paradigm containing the cropped portion of the given image. 10 is the get-go index, from the left border of the input image. y is the start index, from the peak edge of the input image. w is the width of the new image. h is the acme of the new image. This will create a new BMPImage, including a BMPHeader that reflects the width and elevation (and related fields) for the new epitome (westward and h). Re-create in pixel data from the original image into the new epitome data. Handle run-time errors using the method described above. That means in case of an fault, gear up *error to the address of a descriptive message on the heap and return NULL. Information technology is the caller'south responsibility to free the memory for the fault message. Since crop_bmp(…) does not read or write any files, the error handling will exist somewhat simpler here.
test_bmp.c	function	master(…) → return type: int See the section in this assignment titled test-driven evolution. This should not require any command line arguments. All image filenames should exist hard-coded in your test_bmp.c. The files should be included with your submission.
warmup.c	functions	principal(int argc, char✶ argv[]) This part is optional. If included, it will not be tested, but must have a render 0 at the cease to avoid bug with our tester.)
		readfile(const char✶ path, char✶✶ fault) → render blazon: char ✶ Reads the contents of a file and returns it as a string on the heap. The caller is responsible for freeing that retentivity. Use fopen(…), fread(…), and fclose(…).
		writefile(const char✶ path, const char✶ contents, char✶✶ fault) → render blazon: void Write the given content to a file at the specified path. Use fopen(…), fwrite(…), and fclose(…).
		writebetoken(char✶ path, Point p, char✶✶ error) → return blazon: void Writes a single Point to a file at the specified path. Employ fopen(…), fwrite(…), and fclose(…). For the Point class, delight re-create-paste the following struct type into your file: typedef struct { int x; int y; } Point;
		readbetoken(const char✶ path, char✶✶ error) → return type: Point Read a Signal from the file at the specified path into a Point on the stack. No malloc(…) or costless(…) are necessary for this i. Apply fopen(…), fread(…), and fclose(…).

2. But the following externally divers functions and constants are allowed in your .c files. (You may put the corresponding #include <…> statements in the .c file or in your bmp.h, at your option.)

   header	functions/symbols	immune in…
   assert.h	assert(…)	bmp.c, test_bmp.c, warmup.c
   string.h	strcat(…), strlen(…), strcpy(…), strcmp(…), strerror(…), strncpy(…), memcpy(…)	bmp.c, test_bmp.c, warmup.c
   stdbool.h	true, false	bmp.c, test_bmp.c, warmup.c
   stdlib.h	malloc(…), free(…), Zippo, EXIT_SUCCESS, EXIT_FAILURE	bmp.c, test_bmp.c, warmup.c
   stdio.h	clearerr(…), feof(…), ferror(…), fgetpos(…), FILE, fread(…), fseek(…), ftell(…), ftello(…), fwrite(…), fflush(…, EOF, SEEK_CUR, SEEK_SET, SEEK_END	bmp.c, test_bmp.c, warmup.c
   stdio.h	fopen(…), fclose(…), printf(…), fprintf(…), stdout	test_bmp.c, warmup.c

3. Make no assumptions nigh the maximum image size.
4. No role in bmp.c except for free_bmp(…) may modify its arguments or whatsoever memory referred to direct or indirectly past its arguments.
5. You may optionally include other BMP files (G-rated and non-copyright-infringing) that your examination code uses.
6. Do not modify the bmp.h file.
7. Unlike previous assignments, yous do not need a test_bmp.txt.
8. All files must be in one directory. Do not put images in subdirectories.
9. Submissions must meet the code quality standards and the policies on homework and bookish integrity.

How much piece of work is this?

This consignment is designed to be of similar difficulty to HW12. As usual… Do not depend on this estimate. Your mileage may vary in either direction.

Q&A

1. How can I view the contents of a BMP straight?
   The all-time mode to inspect binary data is with a hex dump. From bash, you lot tin can blazon xxd myimage.bmp. Since it will probably be long, you will want to view in vim. One mode to do that is type xxd myimage.bmp | vim - from bash. Another mode is to open the file in vim and and so type :%!xxd. (Do not relieve!)

   Suppose yous have the following tiny 6x6 BMP image: . (Yes, information technology actually is only vi pixels by half-dozen pixels. Don't worry. A larger version is included in one of the diagrams below.)

   To get a hex dump right on the control line, yous could type this at bash:

                 $              xxd 6x6_24bit.bmp

   It volition be more convenient to view in vim, so we type this from bash instead. (Don't forget the "-" at the end!)

                 $              xxd 6x6_24bit.bmp | vim -

   Here is the hex dump, a you lot volition see it. Don't worry if this looks cryptic. Read on and you volition understand it completely.
   

   You can interruption this apart using the information most the BMP file format above. Hither is the same hex dump, this fourth dimension with some annotations.

   For this and other binary file formats, you can sympathize what value goes where past but looking at the specification and a hex dump of the binary file.

   To cheque your understanding of the file format, endeavour asking yourself the following questions:

   1. How big is this BMP image (in terms of pixels)?
   2. How many bytes is the file?
   3. For the BMP header:
   1. How many bytes does it take up?
   2. Where in the diagram is it?
   3. What is its file offset (i.e., number of bytes from the outset of the file)?
   4. Consider the pixel in the lower-left corner of the paradigm.
   1. What color is it?
   2. Where is the data (3 bytes) in the diagram?
   3. How many bytes is that from the beginning of the image information (pixels)?
   4. How many bytes is that from the beginning of the file?
   5. What are its (10,y) coordinates? (Hint: Meet the pocket-size representation of the image in the lower-right corner of that diagram.)
   5. Consider the pixel in the upper-right corner. … and finally the lower-left corner. Enquire yourself the same questions about each of those pixels.
   6. Find some "padding" in the diagram. How many bytes is information technology?
   7. How many bytes does a single row of pixels take up in this image (including the padding)?
   8. Will the number of padding bytes per row always exist the same within a given image?
   9. … for all BMP images?
   10. For an arbitrary prototype that is w pixels broad, at what file offset will the i ^thursday row begin?
2. Why is the file size (174) represented as "ae00 0000" in memory (instaed of 0000 00ae)?
   The BMP format is a little endian format. In short, that ways the number 0x12345678 (305419896 in decimal notation) will be stored in retentivity every bit 7856 3412.

   Remember that two hex digits are 1 byte. For example, 0x12345678 consist of iv bytes: 0x12, 0x34, 0x56, and 0x78. When we store it using trivial endian, nosotros store the least significant byte (LSB) showtime in the file (or retentivity). For that reason, little endian can too be called LSB first.

   This may seem counter-intuitive considering our own writing system in the physical world is the opposite: big endian. Thus, if you write, "I have 57 pints of ice cream in my freezer," 5 is the well-nigh significant digit of 57, and we write it first.

3. Do I need to manually reverse the bytes when I read/write a BMP file?
   No, not on our platform.

   For this assignment yous are copying bytes directly from a file to retention, and dorsum. Luckily for you, the x86 and x64 architectures, which power almost Linux and Windows computers happen to use little-endian for storing numbers in memory. You lot may accept noticed this when using the x/… control in gcc.

   In fact, the choice of fiddling- or big-endian is actually a bit arbitrary, at least for fixed-width storage in retentiveness or binary files.

4. Are the bits reversed, likewise?
   How would you know? … Think, it's all just bytes.
5. Would a cord representation of an integer (e.thou., char* due south = "abc") likewise be reversed in retentivity?
   No.

   Long version: A string is just an array of characters, and each character is really merely a number. Endian-ness merely affects how a unmarried number is stored, not bigger structures such as arrays or structures. Also, since a char is only 1 byte on our platform (actually, all platforms by virtue of a special provision in the standard, but I digress...), endian-ness would not affect fifty-fifty an individual grapheme because information technology only applies to the order of bytes inside a number requiring multiple bytes to shop in a file or memory.

   You tin can observe this directly from gdb.

6. Why are the RGB color components written in bluish-green-red order (instead of cerise-blue-green)?
   This also has to practise with BMP beingness a fiddling endian format.
7. What are uint16_t and uint32_t?
   These are special types that have a guaranteed size of two and 4 bytes, respectively.
8. Do I all the same demand to use sizeof(…) when referring to the size of uint16_t and uint32_t?
   Aye.
9. What is unsigned ?
   The unsigned keyword is a function of some type names (e.g., unsigned int, unsigned char, etc.) and indicates that the blazon cannot be negative.
10. Are there other types I should know about?
    "Should" is relative, simply yes, at that place are many other numeric types. Wikipedia has a decent list.
11. Will all of this be on the test?
    All of the concepts in this and the other assignments can be considered inside scope. That includes this Q&A.
12. What does "valid" hateful for check_bmp_header(…)?
    You lot are checking that none of the data in the header contradicts itself or the contents of the file (esp. the file size).
13. Is the gray_earth.bmp image valid?
    Yeah and no. That file follows the BMPv5 format specification. For this assignment we are post-obit the simpler BMPv3 format specification. You may desire to ignore that file.
14. Tin can nosotros use assert(…) in our check_bmp_header(…)?
    Yes and no… but mostly no. You lot may use assert(…) wherever you like, merely only for detecting errors in your lawmaking; it should never be used to cheque for errors in the inputs or anything else. In other words, it is non for run-time checking.

    Real-earth software development operations typically use compiler features to effectively remove all assert(…) statements prior to shipping a product. Thus, you should use assert(…) simply for things that need not exist checked after the production is completed and deployed to users.

15. Why do we need ftell(…)?
    Information technology might help you get the file size. (We'll leave information technology upward to you to notice how, and why that would be needed in the offset identify.)
16. Why does check_bmp_header(…) take a FILE* fp equally a parameter?
    You lot should employ that to make certain the actual file size matches the information in the BMP header. See Q15.
17. Why does fwrite(…) add a newline character (0x0a)? to the end of my file
    It doesn't. If y'all open the binary file in vim and then use :%!xxd you may see an extraneous 0x0a at the end. That's considering vim (similar many code editors) adds a newline to the end of a file, if at that place's not one there already. Some solutions:
    
    1. (BEST) Use xxd myfile.bmp | vim - from bash. (Don't forget the '-' at the end!)
    2. Ignore the 0x0a.
    3. Open up the file with vim -b myfile.bmp and then use :%!xxd to convert to the hex dump. The -b tells vim to open up it in binary manner, which (among other things) disables the newline at the end.
    4. From inside vim, open the file with :tabe ++binary myfile.bmp and and so use :%!xxd to catechumen to the hex dump. This too opens information technology in binary mode.
18. How tin read_bmp(…) return a descriptive error bulletin when check_bmp_header(…) does non?
    You may want to utilise a helper function to do the checking for both. Your helper would be a lot like check_bmp_header(…) but render an error bulletin (i.due east., via a char** error). This isn't a requirement—just a proffer. Use information technology only if you discover it helpful.
19. How are the pixels in a BMP numbered?
    For purposes of the BMP image format, the pixels first in the lower-left, and progress left-to-right then lesser-to-top. See the diagram for a more physical example.

    For purposes of near image processing APIs and discussion, nosotros mostly designate (0,0) as the upper-left.

20. What are some skillful helpers to use?
    It's upwards to you. Hither are some ideas to get you thinking:
    1. long int _get_file_size(…)
    2. _Color _get_pixel(BMPImage* image, int 10, int y)
typedef struct { unsigned char r, m, b; };
    3. int _get_image_row_size_bytes(BMPHeader* bmp_hdr)
    4. int _get_image_size_bytes(BMPHeader* bmp_hdr)
    Yous may use/copy those if you observe them helpful, but we make no guarantees equally to whether they will piece of work for you.
21. How practice I read an image?
    The structure of the BMP file format is given above under The BMP file format. In short, a BMP file consists of a header (BMPHeader struct object stored in a binary file) plus an array of unsigned char (ane byte each). Each pixel is three bytes, with one for each of red, green, and bluish. You won't need to worry most the private colors for this assignment.

    An case is shown in Q1 in this Q&A.

    The following explanation omits details about error checking.

    Your read_file(…) will outset read a BMPHeader from the file using fread(…) This is simply like the warm-upwardly. (An case shown in Prof. Quinn'due south lecture can be plant on the schedule folio.)

    Based on the information in the BMPHeader object, you lot will know how many bytes are in the image pixel data. With that, you lot will read an array of unsigned char using fread(…).

    For fread(…), this is all you demand. You won't need to practise much with the pixel information, except for crop_bmp(…). Nevertheless, y'all do demand to empathize the fields in the image header in order to test it.

    The chief focus of this assignment is on testing. The reading and writing of images is not intended to be very challenging.

    Your write_bmp(…) volition exist very similar. It will write a BMPHeader object using fwrite(…) and then use fwrite(…) to write the pixel information.

22. What should my error messages say?
    There is no standard or required text. Just brand sure the mistake message describes the trouble specifically.
23. How do the pieces of this file relate to the paradigm?

    Images are fabricated up of small dots called "pixels". Images can exist stored in a diversity of ways. For this assignment, we focus on the BMP file format—and in particular, the 24-bit color format. In this format, each pixel consists of 3 bytes: red, green, and blueish. This image data (pixels) is stored right after the header (54 bytes).

    The header is just a struct object containing many details well-nigh the image, such as the width, superlative, and file format. Later on the header, the pixels are laid out in a row in the file, starting with the lower-left pixel.

    Each row must exist a multiple of 4 bytes. To ensure that is the case, 0 to iii bytes of padding may exist added to the cease of each row.

    All of this is illustrated in the diagram (annotated xxd output) in Q1 higher up. Exist sure yous understand the diagram before y'all proceed.

24. What is the value of the padding bytes?
    The padding bytes are intentionally wasted space in the file. They are there to brand the rows of pixel information line upwards. The value won't exist used, but for consistency, they must comprise cypher.
25. Is there any example lawmaking I can refer to?
    This code from Prof. Lu'south book is like respects to this assignment. There are many differences betwixt that code and this assignment, but you may detect it useful to empathise the high level. In particular, annotation how the fault checking code is designed to forbid memory leaks, even when reading corrupt BMP files. Do not re-create that code (or whatever other code).
26. Should my program terminate from inside read_bmp(…)?
    No. It should terminate simply from the return statement at the finish of your main(…).
27. Should my main(…) take paradigm file names from the command line (eastward.thousand., via argv)?
    No. Hard lawmaking the prototype filenames in your main(…) and include the image files with your submission.
28. What if read_file(…) (or others) are called with Aught for fp?
    Yous may assume fp is non Nada.
29. What unit of measurement are ten, y, width, and pinnacle measured in?
    Pixels.

Updates

11/ix/2016	No starter warmup.c; write_file(…) will call fwrite(…) not fread(…); warmup.c can #include whatsoever of the headers allowed for anything else in this consignment
11/13/2016	Added boilerplate reminder well-nigh lawmaking quality standards and policies. It had been inadvertently omitted. Syllabus already states these apply to every assignment but we try to put a reminder in every assignment.
xi/14/2016	Do not close file in whatsoever of the functions in bmp.c. Tidied upwards requirements tabular array by shortening the wording of some descriptions and moving details to the bullets. Stock-still ncolours ⇒ num_colors and importantcolors ⇒ important_colors. Added Q21 to Q&A. Your test_bmp.c should not require any command line arguments.
11/15/2016	Added some comprehension questions to Q1. Added Q22-Q28. Antiseptic mistake handling procedure for read_bmp(…) and write_bmp(…); they must not leak memory.
11/sixteen/2016	fopen(…) and fclose(…) are allowed in test_bmp.c just non in bmp.c.
11/17/2016	fflush(…) was added to the table of allowed functions/symbols.

beckerwitle1961.blogspot.com

Source: https://engineering.purdue.edu/ece264/16au/hw/HW13

Share this post