You have been had, or you have not been given (or are not giving us) the correct unpacking instructions, or (possibly) this image has gone through some processing, such as resampling or resizing, before or after it was posted here.
- The image is a regular true-color + alpha PNG, 258 x 98 pixels.
- According to its "tEXt", it has been created with "Software:Microsoft Office". It contains a 1-byte sRGB chunk, and the rest are all IDAT chunks -- plain data.
- The plain data decompresses into 101234 bytes, which is the correct number for the size of the image.
That takes care of the preliminaries. Now on to decoding the raw data; and here come the discrepancies.
- "the first pixel is actually an integer" -- the 'first pixel' value is
01 5A A5 FF
. The last byte FF
is not significant; it's the image alpha, and this is FF
for all pixels. The remaining bytes can be read as Big Endian (10,836,481) or as Little Endian (88,741).
- "the second pixel is an integer which determines the height" -- the 'second pixel' value is
08 08 83 FF
. That would be a "height" of either 526,467 or 8,587,272 pixels -- take your pick.
- "the third pixel [..] are integers representing the number of repetitions", well, the third pixel has an RGBA value of
1C 19 2E FF
. Can you indicate which byte is 'the' integer value? Picking either one gives bad results (the image is not the expected 'size', and is not recognizable as an image anyway); using the full 3 byte value of 1,841,454 or 3,021,084 seems a bit too much for a plain RLE repetition value.
After getting a link to the correct image
Okay, it works as per original specification. The first 'pixel' values are to be interpreted as a 3-byte integer, Big Endian. The first value is 25,258 -- the number of repeat/data pairs to be unpacked. The next value is 400, the new image height. Note that supplying both is actually redundant; but you should use both to verify your algorithm.
In your own attempt, you are acquiring a pointer to the 'raw data' (correct) and reading the original width (also correct). But the height should be read from the raw data, as the guidelines stated.
Write a function read_3bytes_as_int
that returns the next 'value' to be read. Use this to get (a) the 'unpacked' length, (b) the new height, and (c) each repeat count. The last one should be in a loop: read the repeat count, then read an RGB pixel and write this repeatedly to an output file. Keep a count of how many pixel/pairs you read, so you know when to stop.