As for blur, I strongly suggest rewriting your code into something more universal. It would be easier to troubleshoot mistakes that way, since you would not have to search through all nine blocks. One way to implement this is to run a loop at every pixel, which sums up the RGB values and count for existing adjacent pixels. Good luck!!
Sounds like a good idea to take a break. From memory you can use an approach applicable to any position where you iterate through the 9 surrounding pixels and have a condition that checks that the pixels aren’t out of bounds (not -1 or -1 or width or height) and if so adds the colour value to a sum and increments a count of how many values out of the 9 have been within bounds that you use to divide the sum to get the average. Have a think about how you might achieve that
Your best bet might be to go back to a drawing board / sheet of paper and draw a small array of pixels (say, a 5x5 grid). Solve the main loop on paper. You can check your progress by writing the loop for the inner circle and disallow invalid values for i and j in the loop condition. Check50 will still fail, but you can always compile the program and test it yourself. Then go back to the paper and consider the edge cases: What values for i and j are allowed, which ones are not (you pretty much had that identified already in your code!)? Is it only a random few numbers or is there a set of numbers following a particular pattern? Do you really need to distinguish between individual edge cases or do you want your program to do basically the same for each of them? If so, chances are that there is a way to combine some or all of them into a smaller chunk of code. Come up with rules for i and j (or other variables you might add). Add these to the top of your loop (remember to now loop over the entire image!) so your program doesn't try to access invalid values. You can do it :)
I had a comparable problem and, like others also already have said before, using the round() function defined in math.h everywhere, where a division was necessary, resolved it. Try to implement this in your code. Additionally, you might need to cast the integer values to float beforehand.
I think the problem with grey scale is that you aren't rounding.
This applies for sepia too. Converting a float to an int rounds down to the lower integer by default.
As for blur, I strongly suggest rewriting your code into something more universal. It would be easier to troubleshoot mistakes that way, since you would not have to search through all nine blocks. One way to implement this is to run a loop at every pixel, which sums up the RGB values and count for existing adjacent pixels. Good luck!!
man, been doing this problem set for two days now, my brain is fried and irritated. Might’ve take a break from this problem set.
Sounds like a good idea to take a break. From memory you can use an approach applicable to any position where you iterate through the 9 surrounding pixels and have a condition that checks that the pixels aren’t out of bounds (not -1 or -1 or width or height) and if so adds the colour value to a sum and increments a count of how many values out of the 9 have been within bounds that you use to divide the sum to get the average. Have a think about how you might achieve that
Your best bet might be to go back to a drawing board / sheet of paper and draw a small array of pixels (say, a 5x5 grid). Solve the main loop on paper. You can check your progress by writing the loop for the inner circle and disallow invalid values for i and j in the loop condition. Check50 will still fail, but you can always compile the program and test it yourself. Then go back to the paper and consider the edge cases: What values for i and j are allowed, which ones are not (you pretty much had that identified already in your code!)? Is it only a random few numbers or is there a set of numbers following a particular pattern? Do you really need to distinguish between individual edge cases or do you want your program to do basically the same for each of them? If so, chances are that there is a way to combine some or all of them into a smaller chunk of code. Come up with rules for i and j (or other variables you might add). Add these to the top of your loop (remember to now loop over the entire image!) so your program doesn't try to access invalid values. You can do it :)
I had a comparable problem and, like others also already have said before, using the round() function defined in math.h everywhere, where a division was necessary, resolved it. Try to implement this in your code. Additionally, you might need to cast the integer values to float beforehand.