3

In the headers, you forget to put the new biWidth and biHeight in the BitmapInfoHeader of the new file. You do compute the new values, but you don't write them into the headers. And to quote Cliff B: If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)


2

There are two major issue. First, the code is using biWidth and biHeight for the output file to control reading from the input file. Second, there's no actual code to handle vertical scaling. Perhaps a review of the walkthroughs is in order? If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)


2

Your output file is too large, larger than the header claims. Use input height, not output height for the outermost for loop. Not sure this can explain the problem you describe, especially those numbers make me wonder. A common mistake would be confusing input and output padding, but all related cases I've seen so far produced some viewable output.


2

As you know arrays start with index 0. it means name of outfile should be char *outfile = argv[3]; , not argv[4].


2

I would wager that you looked at the images but not at the raw data in the files. Since the header is correct, it tells any bmp viewer to display the amount of data that should be in the image, but if there's any additional data, it won't be displayed. If you had looked at the raw data, you would see that for a scaling factor greater than 1, there's extra ...


1

It's actually a structure, or a struct that is defined in the bmp.h file: /** * RGBTRIPLE * * This structure describes a color consisting of relative intensities of * red, green, and blue. * * Adapted from http://msdn.microsoft.com/en-us/library/aa922590.aspx. */ typedef struct { BYTE rgbtBlue; BYTE rgbtGreen; BYTE rgbtRed; } ...


1

Let's see the very first switch being the first pixel on the left and the last pixel on the right. In your code: image [i][j] = image [i][(width -1) - j]; you copied the last pixel in the first position. Now you have the same pixel in the first and last position and no access to the one that was first. So How can you switch the two pixels without losing any ...


1

:( resizes small.bmp correctly when n is 2 expected 0x6, not 0x3 in header field biWidth This tells you there's the wrong value in new_bi.biWidth when you write it to the output file. If you look closely, after copying bi to new_bi, you never change that particular field. You should have checked the headers using peek before running check50 (in the problem ...


1

I assume you declared RGBTRIPLE scanline[newwidth];, so that all the pixels actually fit in. Allocating on heap like RGBTRIPLE *scanline = malloc(newwidth * sizeof(RGBTRIPLE)); would work too, but require a free(scanline); later while providing no benefit, so I prefer the array. You assign to scanline[k], those are the same n output pixels for each input ...


1

Your problem is where RGBTRIPLE array[orgBiWidth]; is declared. It's declared within the loop, so when the current iteration is over, this memory is marked unused, and part of it will be reused before entering the next iteration, where the next array is declared in the same position (so it seems to persist between iterations). To fix this, simply move this ...


1

You've declared a new header struct, but you never gave it any values // write outfile's BITMAPFILEHEADER BITMAPFILEHEADER outfile_bf; fwrite(&outfile_bf, sizeof(outfile_bf), 1, outptr); Earlier you read the header from the file into a variable called bf. Perhaps you meant to set out_file bf = bf? Otherwise, you are writing garbage.


1

Hmmm..... After the code creates the output file headers, do you think it would be useful to load/copy the values from the input file headers into the output file headers? // write outfile's BITMAPFILEHEADER BITMAPFILEHEADER outfile_bf; fwrite(&outfile_bf, sizeof(outfile_bf), 1, outptr); // write outfile's BITMAPINFOHEADER BITMAPINFOHEADER ...


1

Have you looked at the actual hex data of the file instead of the image? When looking at the image, the header data (assuming it's correct) will only allow the display of the specified amount of data in the image. Any extra data at the end of the image will not be displayed. When I looked at the actual file data, I saw that there are n times more rows of ...


1

Would be nice if you could describe the problem next time. Like does the programme crash? Is there a header mismatch (use cs50's peek as described in the "Testing" chapter)? Is the file size wrong? Does xxd show you wrong bytes? Does the file look weird in some way (with screenshot)? If you had run peek on your output, you could have seen that you write an ...


1

The calculation of the headings is clearly incorrect, as shown in its image, one of the difficulties of this set is that it needs extensive documentation and a deep understanding of how a BMP works. That is why we should look for information about the structure of a Windows BMP, especially the following two structures: BITMAPFILEHEADER and BITMAPINFOHEADER. ...


1

The code will work when the scaling factor is 1, but not otherwise. The problem is straightforward. The code calculates the new biHeight and biWidth values, but it doesn't plug them back into the new headers. Remember too that the code needs to have both the old and the new values for these vars in order to process the image. If this answers your ...


1

The problems revolve around how the pointer is moved at the end of each line in the input file and how padding is added to the output file. There are two issues. First, the output file padding. It works for n=1 because the padding sizes are identical. The problem here is that the code is writing the input padding to the output file. Next, when handling ...


1

Have you actually looked at the raw hex data contained in the program's output files? Notice anything interesting? Where is the bmp signature that's supposed to be in the first 2 bytes? Next question: Which header is supposed to be printed out first, bi or bf? ;-)


1

You have just learned an important lesson. Seg faults can be muted by debug environments. When this happens, you need to isolate the offending statement using printf statements to see how far execution goes. By strategically placing unique printf statements, you can compile and run the program and see which is the last printf statement to execute and which ...


1

Several issues here. First, look at the code that expands the line horizontally: for (j = 0; j < biSmall.biWidth; j++) { // read RGB triple from infile fread(&triple, sizeof(RGBTRIPLE), 1, inptr); arr[j] = triple; for (q = 0; q < n; q++) { // write RGB ...


1

For each input line, you currently read bi.biWidth * scale_factor pixels from input. Obviously, the input line does not have that many (unless the factor is 1). One approach is to read the pixels to some array once, and use that one for writing multiple times. Another approach is to use fseek for jumping back the number of pixels just read (you could use ...


1

First, there are errors in calculating header data. That should be easy to fix. The design logic for vertical scaling is totally flawed. Understand that images are not stored in two dimensions. The data is stored in the image file linearly. Each row follows the previous row. There is no direct way to read the data vertically. In order to scale vertically,...


1

Actually, you don't get the correct image size. The output image data is several times larger than it should be. The intent of the code posted above is to read in a pixel (an RGBTRIPLE), copy it to a pixel array n times, and repeat to the end of the line. Once a line of pixels has been read in, then output the scaled-up line to the output file. ...


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

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


1

if (i < n - 1) will trigger for the first input line only, second input row starts with i being of value n. A possible fix would be if (i % n < n - 1), you might know the operator from pset2 Caesar and Vigenère.


1

From one line of input data, you need to write coef lines of output data. Either remember the line using an array and write it multiple times, or jump back (using fseek) and re-read the input line.


1

So, I see that it calculates the padding for the input file. Where is the padding calculation for the output file? They are not necessarily the same, especially if the scaling factor != 1. Also, biSizeImage and bfSize are going to have some issues because of that and because they can't simply be multiplied by the scaling factor that was entered. Finally, ...


1

You have to check your command line arguments. You take the third argument as the resize factor and as the infile name.


1

1st problem: You have skip over padding (when reading from the input file) within the third for loop, the same loop you are using to horizontally multiply the pixels. We don't skip over padding for each pixel when we read the input file, because the input file only has the padding at the end of each row (hint). 2nd problem I see: you are never using fseek()...


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