0

I'm done with resize [more]. And check50 was ok. But when i check my program for not 0.25/0.5 size, but for size 0.2/0.4 the image was fail ./resize .2 large.bmp student.bmp

image for size .2

  • .1 - OK .15 - OK
  • .2 - err .25 - OK
  • .3 - err .35 - err
  • .4 - err .45 - err
  • .5 - OK .55 - err
  • .6 - err .65 - err
  • .7 - err .75 - OK
  • .8 - err .85 - err
  • .9 - err .95 - err

I tried to change (int)(bi.biWidth * f) to (int)round(bi.biWidth * f) and/or (out_bi.biWidth * sizeof(RGBTRIPLE)) to ((int)round(out_bi.biWidth * sizeof(RGBTRIPLE))) but it does not help.

I tried to use ceil floor, but it does not help.

Anyone have idea how to fix it?

my code

EDIT:

For example 0.75 vs 0.70 enter image description here

int row = 0;
int col = 0;

row += abs(out_bi.biHeight);
while (row > 1)
col += out_bi.biWidth;
while (col > 1)
col-=bi.biWidth;
row-=abs(bi.biHeight);

I tried to change row and col before 'cycle' and change it in 'while' but it does not help. I miss something, but i don't know what.

1

f < 0 && f > 100 should be f <= 0 || f > 100. Not your current problem, though.

In my solution, which is very similar, I avoid floating point. First, I calculate round(bi.biWidth * f) and so on (no differentiation between scaling up or down), from then I only work with the old and new width and height, which are integers. Adding new size before the while loop, subtracting old size in the loop. That way, my bitmap is always consistent with the image dimensions, no further rounding errors possible.

14
  • Can you explain with some example: "Adding new size before the while loop, subtracting old size in the loop."? Can't imagine it ( Apr 27 '18 at 16:13
  • Instead of row += f;, I have row += new_height;, and instead of row--; I have row -= old_height;. Absolute heights in this case, not negative. All integer. f appears only in determining the new size, and never again.
    – Blauelf
    Apr 27 '18 at 16:20
  • If new_height == old_height * f is true, that's the same as you do, multiplying both the added and the subtracted value with old_height, but preserving the ratio. Rounding errors might make your version fail, mine is consistent. It would probably break at images with more than one billion pixels in one dimension (around 2^30). But I think that's ok for the moment.
    – Blauelf
    Apr 27 '18 at 16:28
  • Thank you for help, @Blauelf, now it's look better but i steel have a problem. Edit post. Apr 30 '18 at 15:47
  • You initialise the values to 0, then I'd test for >0 rather than >1. But what's the problem?
    – Blauelf
    Apr 30 '18 at 15:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .