The headers are read in this order from the file:
fread(&bf, sizeof(BITMAPFILEHEADER), 1, inptr);
// read infile's BITMAPINFOHEADER
fread(&bi, sizeof(BITMAPINFOHEADER), 1, inptr);
Which is the correct order. You're writing them in this order:
// write outfile's BITMAPINFOHEADER
Not related to problem: Move your integer conversion and test for n being in range up, before opening a file, but after test for argc. No need to do any work if you won't resize.
Also not related: If you're working with integers only, floor and ceil make little sense. Don't exactly hurt either.
A mistake, but not the one mentioned: The new height should ...
There are several issues in the code that need to be addressed. They're affecting both horizontal and vertical scaling when n != 1.
Many of the problems are centered around bi.width and bi.height. The code multiplies both by n, but then uses the new values where the original values are needed, such as controlling the reads and repositioning in the input ...
There are a couple of issues here. First, the for loop nesting is in the wrong sequence. The outermost loop should be based on the height of the image, but that's the innermost loop. In addition, there appears to be an extra loop based on n.
Next, the logic is to process a line from the input file, then reprocess it until it's been processed n times. ...
So close, but I think you might be looking in the wrong place.
Have you verified that your header values are all correct in the output file?????????
Those values control how the image data is displayed.
If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)
[EDIT - now that Nic has found the ...
Well, that's an unusual way to try and do that. You're writing to the headers in the file! Seems like the hard way to update the headers.
Don't you think it would be easy to read the headers into a struct in memory, modify the appropriate values in memory, and then write the header structs out to the output file?
Here's an efficiency tip. Making changes ...
You've clearly looked at the images generated, but have you looked at the raw image data using the xxd tool? It's a lot more revealing because you can see patterns in the raw data!
There are a couple major issues. First, padding is based on biWidth of the particular file. In the code above, both the input and output file's padding values are based on the ...
There are a number of problems that need to be fixed.
The code doesn't skip the padding at the end of each line in the input file, so it gets treated as image data.
It always goes back to the beginning of the first line (sort of, see previous error). After the first line is processed, it needs to stay where it is, not go back.
Finally, the last fseek ...
I think I found the answer. The main problem was that I was setting the ppixelIndex variable out of the for loop and I was incrementing it way too much. So when the first iteration for the first row finishes, I wasn't resetting it so during the second iteration I was trying to reach the memory that wasn't allocated. I've also modified my code a little bit, ...
The most basic version is copying/dropping pixels.
This could be like
diff = input_height/2
repeat input_height times
diff += output_height
read input line
skip input padding
while diff >= input_height
diff -= input_height
write horizontally resized line
write output padding
which covers up- and downsize. Upsize ...
It all has to do with padding and repositioning with fseek.
If the code isn't repositiioning correctly, the code won't be aligned with the beginning of a line of pixels. When that happens the padding gets used as if it were part of a pixel. Think about this. A red pixel looks like 00ff00. Now, say that the code is copying two pixels, but the file pointer ...
First, I'm assuming that n is the scaling factor.
Look carefully at what the code is doing. It starts by creating array[n], an array of RGBTRIPLEs that can hold n pixels. Then, it stores n copies of a pixel in the array. Next, it writes out the n copies of the pixels to the output file. Finally, it writes out padding and skips the input file padding.