I'm doing PSET4 (More) and fixing the downsizing portion.

Given a 8 x 8 pixel image. Downsizing to a 4 x 4 pixel image. n = 0.5 So I'm starting with 64 pixels. New image must have 16 pixels.

I have written several different algorithms for choosing pixels. None of mine seem to chose the same 16 pixels at the staff's version.

Where can I read more on downsizing pixel choosing algorithms? Like pseudocode?

  • I am having the same issue. Did you find a solution? Feb 7 '17 at 2:43
  • Nope. I found made an algorithm that matched their output from 8 to 4, but then I ran it on different sizes and it didn't match the others. Feb 7 '17 at 2:45

Haven't seen the staff solution's output, but one approach is to take the average of several pixels.

If you downsize an 8x8 to 4x4, there's 2x2 pixels of the original bitmap you can average to obtain one output pixel.

For not so nice rations like 0.75 (not of the form 1/n), you could either average different numbers of rows/columns (like 4 to 3 as 1-2-1), or lay another grid over the image, and weigh the different pixels by the area of the output pixel they cover.

For 0.75 you'd average the first and second input row with weights 0.75/0.25 for first output row, second output row is second and third input row with weights 0.5/0.5, third output row is third and fourth input rows with weights 0.25/0.75. Same for columns.

In my example, every input line got a weight of 0.75 in the output image, that's the resize factor, and weights for any given output row add to 1.

It's easier done if you keep the whole image in memory, but you could reduce it to holding one input line and one output line.

Resizing to enlarge is even more interesting, most basic with repeating pixels, linear interpolation, or bicubic splines, or approaches that better preserve edges.


what i did in this pset, is based on the fact the the provided image is very symetric and the factoring is always 0.5, which means you skeep, or copy (up to you), every othe pixel, in every other line. The trick of this pset is in the setteing of the pointer of the infile after you scan a line, its tricky, but once you realize that the bitmap is realy a long line of bytes, not few lines as it apears, try to think what you need to put in your fseek function.

You must log in to answer this question.

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