Bug: Careful how you open
A common problem when near windows is opening a binary file in text mode. Avoid end-of-line translations and open in binary.
// FILE *inptr = fopen(infile, "r");
FILE *inptr = fopen(infile, "rb");
Check read success
If the fread() fails, error out. Also recommend to size to the object and not the type. Easier ...
I strongly recommend to declare temp as RGBTRIPLE[hight + 2][width + 2], and initialize the border pixels to 0, 0, 0. This would eliminate the need to test for pixels that are within the image boundaries.
Initializing row and column inside the for loop makes it more clear how the are used, and that they go lockstep with k and l respectively. Consider
That's a pretty cool application and it's nice to see the output!
There are a few things I'd like to cover :
Let's say you were to print the output of findNumberOfPixels everytime you ran it, you'd see that it always outputs the same number. Why? Because distance never changes and your function doesn't rely on anything else. What this means is that instead ...
Just my few cents...
There is no reason to treat distance == 1 differently:
public static int findNumberOfPixels(int distance)
int numberOfPixels = 0;
int increment = 4;
for (int i = 1; i <= distance; i++)
numberOfPixels += increment;
increment += 4;
Make sure you add #include for everything you use directly
Your code happens to compile without errors because some other header file #includes the necessary header files for you to be able to use functions like std::acos() (from <cmath>), std::abs() (from <cstdlib>), std::min() (from <algorithm>), std::unique_ptr (from <memory>), and ...
The real performance issue here is fairly simple: good performance is obtained by not repeating steps. The big step that you are doing repeatedly is to figure out where the pixel goes in the output space.
If we consider @Dannano's
img[WIDTH * y + x] = 456;
We wind up doing that currently for every point. Multiplication is hard (at least classically, and ...