That's simple because infile.bmp does not exist, that is just a placeholder it means that, that the path you put in there should contain a file. The folder images has images where you could process or filter. Try doing ./filter -g images/tower.bmp images/greytower.bmp.
This basically means ./filter will run your program, -g will state that you want to use ...
You overwrite pixels you still need later, for calculating the neighbouring pixels. What looks about right visually is still wrong.
I made another array, wrote my blurred image to that, then later copied over.
For j being 0, your index would be width. But valid index is from 0 to width-1. Subtract one and it should be right.
After fixing this, I see another issue: You first swap the left half with the right, and then the right with the left, returning the image to its old state. Stop at the right point.
BTW, you can assign whole RGBTRIPLE type variables, like ...
Remove the -1 from HW.
If the number of pixels per row is even, you need to swap half as many times.
If the number of pixels per row is odd, no need to swap the middle one with itself, so swap that number divided by two, and rounded down.
Integer division does exactly that, truncates the result. No -1 involved.
You are using 'RGBTRIPLE' structs along your code which is kind of neat but it comes with some issues:
That struct only can store values from 0 to 255 with no decimal point. That means that when doing calculations that could result in numbers with decimal point, the decimal part will be truncated, no matter if it's 0.1 or 0.9.
The other issue derivated ...
instead of using BYTE before sepiaRed, sepiaBlue, sepiaGreen, originalRed, originalBlue and originalGreen, use float
Also, don't forget to round the values of sepia Red, Blue and Green using the round() function defined in math.h
Reading your code I can see that you're worried about the number of width pixels been even or not. Should you be worried? If you look at your code you can see that you're answering yourself. When reached the middle point you do this: image[i][j] = image[i][j]; which is like do nothing. You have to flip the half part of the pixels in the left with the ones in ...
This is happening because your loop is summing values from neighbors to the left and up of the current pixel that have already been blurred by previous iterations of the same loop. You need to modify a copy of image, not image itself. memcpy can help you copy the data from image into another two dimensional array. Otherwise, your function seems ...
Did you happen to notice that the incorrect results all happen to be 1 less than the correct answers? That's a big clue.
The problem lies here.
float average = total / 3;
Since total is an int and "3" is an int, this is integer division. Rounding won't change it, since the result of the division is an integer that will always be the result of ...
Your problem lies with the / operator. Because the RGB values and the denominator are all integers, integer division is being performed and the fractional remainder is dropped instead of being passed to the round function.
Try replacing 3 with 3.0 (which is explicitly a floating point value). When at least one value is a float, floating point math will be ...
May be some more issues but, a big one, is that you are not processing the edge and border pixels at all: Here: if (x - 1 < 0 || x + 1 > width - 1 || y - 1 < 0 || y + 1 > height - 1)
you jump to the next pixel without taking in consideration the ones that are not out of ...
When checking the values of adj_i and adj_j in your 'if' conditions, you are not checking against your adjacent_positions arrays, since you added the values of i an j to them here: int adj_i = i + adjacent_positions[k] and here: int adj_j = j + adjacent_positions[k]. Fixing those, by substracting 'i' and 'j' in the conditions, for example: if (adj_j -j ...
You're doing integer division it disregards the remainder, simple fix would be to just divide by 9.0 as it will become a float division, integer division is like 11 / 2 = 5.5, oh the data type is int so let's just throw away the .5 so 11 / 2 = 5. so when it reaches your round function it does nothing since it's already a whole number.
I realised that in line 4 i am assigning values to float only once. So when I loop it in the following lines, avg_of_9_blue, avg_of_9_red and avg_of_9_green just keep increasing past 255. Corrected this an place the assignment of float values into the if statement.
Afterwards, realised that i am changing all the original RBGT values when assigning new ...
You are so almost there!! I don't know why you get those results with check50 I checked it and it tells me that there are problems with reflect and blur. For reflect there is a problem with the rigth index. For blur you made a little misspell in your conditions inside the loops.
You only need two loops to go through all the pixels of the image. One for every row, and one for the horizontal switching. So think about this: How many switchings do you need to do for every row to flip an image horizontaly?
When you divided here: image[i][j].rgbtRed = (sumRed / pixCount); you'll problably get a decimal point result. The problem is that working with int variables will result in a truncated result, the decimal point will be erased, no mather if it's ,001 or ,999. you have to think a way to get around it.
Also you have to think that when taking the values from ...
Your code assumes that every pixel can be made the centre pixel in a 3x3 block of pixels. This is not true for corner pixels as well as pixels at the vertical and horizontal borders of the image.
Corner pixels are part of a 2x2 block,
Pixels at the vertical edges would require a 3x2 block of pixels
Pixels at the horizontal edge would require a 2x3 block ...
I was very intriged because looking through your code I couldn't find anything wrong. So I compared with my blur version and they were very similar except for one thing. For my average calculations I used a double variable. I test your code and it passed ok but I can't explain why. If you find out please let me know.
When doing operationns that could result in decimal point values it's not a good idea to work with 'int' values because the result's decimal point will be truncated. It's better to do the math with a type that can store decimal points and then rounded 'round()' when assigning it to a 'int' type. For reflection check for situations when you could be getting ...
I've found 3 problems in your code: 1. You're making a copy of the image but you're not using it? 2. Revise the arrays Gx-Gy something is wrong. 3. Pay attention where you declare the group of long variables rx-ry-gx-gy-etc.