# Tag Info

6

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.

5

When doing math operations that could result in decimal point number, although the recieving variable is a decimal point capable, the math on the right side of the asign simbol'=', when working with ints variables, will be done with the int rules, so the decimal point will be truncated. One trick to avoid this, is to add '.00' to a number of the operation ...

3

This is an interesting one! It took me a bit to realize what was happening. As you probably did, I spent a lot of time, looking for an error in the math, in the logic, in something that was in the code. Only after I stepped through the code watching every value change, was I able to find the issue. (Mostly because yesterday was the first day that I did this ...

3

Got the solution. Using the BYTE type to store the color values resulted in overflow. Solving by using int or double for redAvg, greenAvg, and blueAvg.

3

>= 0, not > 0. 0 is a valid index. Also, you might have rounding issues because you are doing integer division.

2

You read from and write to the same array, but you need the original values for computing other averages. A solution would be to use two arrays, one for reading, one for writing, and copy between them (either before or after processing).

2

You're adding one pixel twice, and missing one pixel. The code, as you've written it, is really prone to tiny bugs like that, and they're hard to find. Once you've got it working, consider how you can make it more readable, and less prone to having issues where you copy/paste and forget to change one little thing. You're handling 9 types of pixels separately,...

2

Um, your code seems pretty hardcoded. It is good to improve the ability to think by trying to implement a new algorithm. I'm really sorry, I couldn't read it because its a lot. :( Anyways here's my code. I think it might help you. What I've basically done is I started from the top row then the relevant row and the row below. For i being the row and j being ...

2

First you have to think that when taking the values from the surroundings pixels, some of them will be already changed so the result will be diferent than with the original ones. Think in how you could solve that. On the other hand, when going around each pixel you have to check for each single one that you're not reaching out of limits of the arrays i.e. ...

2

When you divide the 3 colors by 3 you'll probably get a decimal point value. If you receive it in a 'int' variable you'll get a trimmed number. (the decimal part will be removed) The way to do it is round() it.

2

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 ...

2

From one blind old fart to another, it's like the guy that lost his glasses in the basement but was looking in the back yard because the light was better. You're looking in the wrong place. ;-) The problem is subtle. (I did the same thing the first time I did this, so don't feel bad.) The code is calculating the blur values (correctly, I assume), but then ...

2

Please note I haven't validated this with testing and have only glanced at your code, but one thing that stands out to me: round((float) (sum_blue / pixel_type)) Remember operator precedence here: the division will be performed first (as it is inside parentheses). At this point both values are integers so integer division will be performed and the remainder ...

1

I recommend you use a for loop to check if there is not a pixel rounding the actual pixel. This should make mistakes disappear. It should be really 2 for loops, 1 for width and 1 for height. "i" starting them at -1 (1 pixel before/above) and finalizing at "i < 2" (1 pixel after/bellow the main pixel). And with and "if" ...

1

Just get rid of int x=0; and replace x+i-1 with int x = i - 1. Likewise for the variable y. You can put any expression or declaration in the first section of the for loop. https://en.cppreference.com/w/c/language/for If this answers your question, please click on the check mark to accept. Don't be shy to ask another question the next time you have an issue!

1

Some of your conditions need to change. There's no 'between' syntax like in maths, so (0 < j < width-1) won't work in c. You need to split this into something like (j > 0 && j < width - 1), and make similar changes to other conditions.

1

For starters, the loops never run. That's why the output looks like the original image. Look at the test conditions in the for loop: for (int i = 0; i < height && i > 0; i++) { for (int j = 0; j < width && j > 0; j++) If i is initialized as 0 and the test condition is that i>0, then the loop never starts. Other ...

1

If you look carefully at the extended results for check50 (the link at the end), you'd see that the result array is the same as the original input array. The problem lies here: image = new_image; This doesn't do what you think. Instead, each element needs to be copied, using two nested for loops and this: image[i][j]=new_image[i][j]; If this answers your ...

1

For reflect, you have to re-think this expresion: [width - (j + 1)]. For Blur, you need to reset your variables before every i/j iteration.

1

It's the same problem here: https://cs50.stackexchange.com/a/38197/27433 Also by doing the division for the averaging with 'int' types, will result in a number that will be truncated. i.e. if the result of the division is 1.99 you'll get 1, and the decimal part will be lost. You can get around it by declaring ne or both of the operators to a decimal point ...

1

What I understand at a quick glance at your code is that you transfer every value one by one into another 2D array at every iteration. To process the colors you program calculations for every possible situation of a 3x3 grid around a pixel (nine different cases). I have not looked too deeply into the specific calculations but what I have noticed is that you ...

1

You are averaging the values in the wrong place. You have to calculate the average after you have added all the values around the current pixel. Don't forget to reset the variables for the following iterations.

1

Look at the test conditions. Here's an example. else if (0<h<height-1) That form is fine in python but not in C. It needs to look like else if (0 < h && h < height - 1) Not sure this is the only problem, but it's easy enough to figure out. BTW, which lines are 136, 137 and 138??? That's where you need to focus.

1

As you're experiencing, finding a misspelling in your code, is very dificult. When you are more comfortable with your coding, I suggest you give a try to reduce the lines of code. When I was about to give up, I got lucky and find your misspell: In the code following this line: //Special case: First row middle, something with your indexes is not right. can ...

1

For reflect a question: How many swaps do you need to do to flip the image horizontaly? Think about it. For blur you got it rigth, except for a little mispell in your 'if' line. Edited because I didn't realize that you could copy an entire struct by simply: RGBTRIPLE row = {}; row = image[i][j];

1

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 ...

1

I missed a += on the rgbtGreen :S

1

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 ...

1

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.

1

Conditional loops is really the way to go on this one. If the pixel is along the left edge and time there is an image[j - 1] it would cause an index error. Think of all conditions that would cause an index error, when image[i +/- 1][j +/- 1] is along the edges. So a corner pixel would have to be divided by 4 no 9. And edges would be 6 respectively. Again ...

Only top voted, non community-wiki answers of a minimum length are eligible