Testing

The first run

imageHis.c:54:50: warning: format specifies type 'double' but the

argument has
type 'int' [-Wformat]
...%9.2lf%%,\n", k, hist[k], ((hist[k])/totalpixels*100));

I got the above warning from the compiler. I realized that I forgot to convert the
percentage into double type. If the program execute, all the result will be zero because
integer doesnt store fractional part. I fixed the issue by using type casting (double) for
hist[k]. This makes the whole expression become double.

The second run

Red, Count,
Percentage,
0,
44703,
0.0%,
1,
0,
0.0%,
2,
0,
0.0%,
3,
0,
0.0%,

This result above happens to every line of the programs output. The count is correct but
percentage is always zero. I traced the problem back to the arithmetic expression but
couldnt find the cause of the problem. It took me quite long to narrow down the area the
bug. Finally, I found the issue. Instead of keep the code like below
int totalPixels = imgHeight*imgWidth;
ppmread(&imgWidth, &imgHeight, &numColors, image);

I switched their positions

ppmread(&imgWidth, &imgHeight, &numColors, image);
int totalPixels = imgHeight*imgWidth;

This adjustment makes the program work correctly. However, I couldnt fully explain
why the order matters in this situation.
In this lab, I tested the program using the sample images. I ran the first test with
halfred.ppm. The below is the outputs of the program. The percentages are reasonable
because both red and black are distributed evenly. This means 50 percent is black and 50
percent is red.
Red, Count,
Percentage,
0,
44703,
49.67%,
255, 45297,
50.33%,
Green,
Count,
Percentage,
0,
90000,
100.00%,
Blue,Count,
Percentage,
0,
90000,
100.00%,
With the globe.ppm file, it is hard to identify the color distribution of each layer. For this reason,
I used Photoshop to check the accuracy of each diagram. Comparing with programs image
diagrams, they looked very similar. This indicated that the program worked properly.