4

After edit: For reference, here is the pseudocode from the walkthrough: for each row       for each pixel          write to array n times       for n times          write array to outfile  &...


3

These are a number of points that you should consider: You shouldn't read the padding. Instead, you should calculate it for both the original image and the resized image, seek a number of bytes equal to the padding for the original image in case of reading and write a number of zeros equal the padding for the resized image (where each 0 is exactly a byte). ...


2

If I'm reading the code correctly, it looks like a padding issue. When you are scaling up by any number that requires padding, here's what I see happening. You read in a line of pixels, process it, and write it out, and then go back and repeat this "L" times. However, the code that adds the padding is outside the loop that does this, causing the padding to ...


2

Following your code, it appears that you're not using the array as you're supposed to. An array should store a whole scanline, whether that scanline is resized or not, and each element in it should be written n times in case the stored scanline is NOT resized or just one time if the stored scanline is already resized. Let me demonstrate with a simple ...


2

fseek(inptr, 0 - padding_ori - horiz, SEEK_CUR); Interesting way to do this. When the loop finishes, isn't horiz equal to bi.biWidth? Now, when you call fseek(), what units does it use to move? Maybe bytes? And what units do bi.biWidth and (since they're equal) horiz use? If this answers your question, please click on the check mark to accept. Let's ...


1

fseek does not require an unsigned long, the signature is int fseek(FILE *stream, long offset, int whence); The runtime error stems from this calculation -((bi.biWidth * sizeof(RGBTRIPLE))-1). sizeof returns a size_t type which is unisigned. The result of the calculation will be unsigned according to promotion rules in the "New C Standard 6.3.8.1". It is ...


1

You have problems in two areas. First, you have header values that are incorrectly calculated. Run ./resize 1 small.bmp s2.bmp and compare the two files using peek. They should be identical. You should quickly see the problem. Next, your vertical scaling has serious issues. The first for loop does a fine job with processing the file for a resize factor ...


1

Have you tried the steps described in the problem statement's "Testing" chapter? https://docs.cs50.net/2018/x/psets/4/resize/less/resize.html#testing The total file size is part of the BITMAPFILEHEADER. As far as I know, there are a few other fields containing various size information, most of them are optional in case of a simple non-compressed image (we ...


1

Looks like too many loops. Why is there an outer loop that processed the entire input file n times? Most of the pieces are there, but reprocessing the entire file more than once won't accomplish anything useful. You should be thinking about how to reprocess each line n times before moving on to the next. That code is missing. Also, where should the input ...


1

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


1

Have you looked at the raw image data using xxd? The image data for anything larger than n=1 is far too much! The code is using the output file's biHeight and biWidth to control reading the input file when it should use the original values, resulting in almost n * n times larger than the correct amount of image data. (I say almost n * n because the image ...


1

One of the problems is that you're not resizing vertically. What you're doing is: 1) read one triple and write it as many times as needed by resize factor. Repeat this until a whole scanline has been read and written. (All this is correct) 2)Then you skip the infile's padding. 3) You repeat steps 1 and 2 n amount of times. But each time you start the ...


1

You're not making use of your RGBTRIPLE array. You declare it, but then you directly write the temporary triples you read from your infile into your outfile. Instead, try to read your infile one RGBTRIPLE at a time, storing it n times in that array, and at the end of each horizontal line, writing that array n times (each time with padding) into your outfile. ...


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