Hot answers tagged

7

Your approach is correct, but you have three errors to deal with, one of which is irrelevant. First, as you guessed, your calculation for fseek is in error. In simple terms, you've placed parentheses incorrectly. Hint: padding only exists once on each line of pixels. Look carefully at how you laid out the line and you should be able to resolve it. fseek(...


4

You are subtracting from bi.biWidth on line 125. Since bi.biWidth is an unsigned long, it cannot contain negative values (-1 and so on), instead it's capacity to store positive values is doubled. So by subtracting you are just setting bi.biWidth to what it would be if it were a signed long, but since it's unsigned you just get a very, very large number. An ...


3

First the padding. Keep in mind that the input file and the output file may or may not require the same amount of padding. In item 5, you don't examine the padding in the input file, you skip over it to the beginning of the next line. In item 6, you're adding the appropriate amount of padding to the output file. It uses a loop instead of 4 if statements to ...


3

Assuming BWold is the width of the original image, this value represents the number of pixels in every row of the image, you need to consider that a pixel (or RGBTRIPLE) is three bytes. So in the same way you are using fseek to read from the file, reading the size of a RGBTRIPLE for every pixel, to move the cursor back a row of pixels you have to do it BOld ...


2

Given that padding cannot be read by fread Who says the padding can't be read by fread? Of course it can and that's the main reason you need to skip it — in order to make fread read the first pixel of the next scanline rather than the padding.


2

1) My understanding is that lines are executed in order. Why would I position 'skip padding' only after the reading and writing commands as it happens in copy.c? you could also position it after add padding but it doesnt matter point is ultimately you want to skip padding so you dont read the padding and hence write it in your new file because your old ...


2

In the first case, you want to wind back for all but the last iteration. In the second case, you would need a different condition, as you want to revert to the beginning of the line in all but the first iteration (where you already are in the right position). So if (m > 0) should work.


2

for(int i = 0; i < MEMORYBLOCK; i++) { //read & store 512bytes in memory[i] fread(&(store[i]), 1, 1, inptr); //do we need *inptr instead? } If you want to read 512 bytes into an array, then you can simply call fread once, like this: fread(store, sizeof(BYTE), MEMORYBLOCK, inptr); Also, you shouldn't need to use ...


2

Well, you seem to be almost there, so I won't review all of your code, just give you some pointers: The first and most crucial tip is that you need to pass fseek() the number of BYTES as the second argument, but you're passing it the number of PIXELS + padding here: fseek(inptr, -(bi.biWidth / n + padding_original), SEEK_CUR);. Understand what I mean? ...


1

First, I love cacahuetes. Second: I can tell you one problem right away. This part won't work with pipe streams like php files: if (fseek(file, 0 , SEEK_END) != 0) { DBG_Print("\n%i\n", __LINE__); return false; } *length = ftell(file); To get the load() function working correctly 100% of the time, one usually needs to read from the ...


1

First... you're using bi.biHeight directly here, but you're forgetting that it is a negative value. I won't say much more... think about that. bi.biSizeImage = ((bi.biWidth + padding) * bi.biHeight); Second... I don't think you really understand how fseek() works, so I'll try to explain it to you in simple terms: Workings of fread() and fseek() (...


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

While we think of an image as pixels and lines, i.e., a two dimensional array like a checkerboard, the data is stored in the file as a single linear string of data. Adding the padding all at once would either write it all in one place, probably at the end, would overwrite image data and leave a corrupted file, or would require a complicated process that ...


1

Your guess is pretty good. Look at the following line: // reset stream pointer for next scanline fseek(inptr, -((biOut.biWidth * sizeof(RGBTRIPLE)) + outPadding), SEEK_CUR); First, this line is moving the pointer on the INPUT file, but is using values for the OUTPUT file. Next, look carefully at where the pointer is when this line is executed. Is ...


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

Too many one letter variables for me to really understand your code. But reset probably should not include intpadding. And the j++ within the innermost loop also is quite odd.


1

by fseek(inptr, (sizeof(RGBTRIPLE) * or_Width) + or_padding, SEEK_SET); you move cursor back to the very beginning of the file (SEEK_SET), and then move it to the beginning of the next row (sizeof(RGBTRIPLE) * or_Width) + or_padding). instead, you AT FIRST need to fill the first row in the way you do, THEN(!!!) add new padding THEN move cursor back to ...


1

Not only with fseek. In the beginning you redefine bi.biWidth and bi.biHeight - now its new width and new height. But when you iterate over scanlines and pixels, you want to do it over infile's ones, that is old bi.biWidth and old bi.biHeight.


1

fseek(inptr, bf.bfOffBits + ((oldWidth * 3) * i) + newPadding, SEEK_SET); You want to go to the start of i line of infile. Each infile line is (oldWidth * 3 + oldPadding) bytes. Multiply it by i and you see your mistake. Spoiler: two mistakes.


1

an int is 4 bytes an unsigned char is 1 byte so buffer[3] in char is the 4th byte but in int it is the 13-16 bytes. so when using int you are not actually checking the first 4 bytes, but the first 16.


1

You change bi.biWidth and bi.biHeight to new scale using bi.biWidth = bi.biWidth * enlarge; bi.biHeight = bi.biHeight * enlarge; and then use code that relies on the values to represent the input file for (int i = 0, biHeight = abs(bi.biHeight); i < biHeight; i++) //iterate for each scanline and for (int k = 0; k < bi....


1

I'll quote some useful answers, because this question has been asked before: First Kareem Zidade on a post on facebook: You'll learn more about that in the following few weeks of the course, but PHP is an "interpreted" language, meaning PHP code goes through a program called an "interpreter", that interprets it, and produces output (e.g., the final ...


1

You could use fseek(inptr, -bi.biWidth * sizeof(RGBTRIPLE), SEEK_CUR); (no padding, as you never read some) to go back to the start of the line where you fseek at the moment, and after that loop, use fseek(inptr, bi.biWidth * sizeof(RGBTRIPLE) + padding_inp, SEEK_CUR); to jump to the next line.


1

According to MSDN biSizeImage The size, in bytes, of the image. This may be set to zero for BI_RGB bitmaps. If biCompression is BI_JPEG or BI_PNG, biSizeImage indicates the size of the JPEG or PNG image buffer, respectively. Let's say you have an image with 3x3 pixels, and you want to enlarge it by a factor of 2. So your new biWidth == 6 and biHeight == 6. ...


1

biNEW.biHeight = n * abs(bi.biHeight); The sign of the biHeight parameter tells the computer whether to paint the image from top to bottom, or from bottom to top. By applying the abs() function, it changes any negative values to positive. That's breaking your code because the input files use a negative value. If this answers your question, please click on ...


1

Fseek works by moving the file pointer, indicated by the FILE pointer in our case, forward or backward. So whenever you use functions that work with file streams, you should keep in mind where the file position pointer. So when you make changes to the output file using fputs, you are moving the file pointer. Clearly, you can see why when you try to read and ...


1

There are a number of issues that need to be fixed. Since the philosophy of this forum is to guide people to solutions and not just to fix code, I'll point you at two subtle but major issues that will help you with the rest. First, your generated bitmap files are not being recognized as bitmaps. Very simply, when you write out the BITMAPFILEHEADER and the ...


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