Referring to Ryans file above:
guint8 is a GTK type, which if memory serves is typedef'd as unsigned char. So it is guaranteed to be exactly 8 bits wide, allowing it to represent the values from 0..255. Perfect for pixel values!
The image-data above is 4 bytes per pixel, so 4 unsigned chars represents each pixel (RGBA). Each byte is listed in octal, so the first pixel would consist of the values "\377,\377,\377,\0" or in decimal 255,255,255,0 which would be solid white, with no alpha/transparency.
If bashcommando wants to put those values into an array of unsigned shorts (which, incidentally are 16-bits wide) there are two options, as outlined in my original post.
1. Read every element in the original array in the struct, cast it to unsigned short and copy it to his array.
2. Alter the original file to use the types he wants to use - e.g. change the guint's to unsigned int and the guint8 to unsigned short.
But unsigned short can represent a wider range of values than unsigned char, so both of these options could present some unwanted problems/side-effects, so the question to bashcommando is how do you plan to represent each pixel in the array of unsigned shorts?
It would be wasteful to use a 16 bit type to store 8 bit values......You could perhaps store two of the 8 bit bytes in each unsigned short value, which I guess would mean casting the first byte to unsigned short and then bit-shifting it to the left by 8 bits before adding the second byte. So two unsigned shorts would contain the four bytes of data for a single pixel. But when it comes to extracting the RGBA values, you'd need to do more bit-shifting to get the values.... So you would almost certainly be best leaving it as guint8/unsigned char IMO!
(BTW: if you aren't using gtk, you could just change guint8 to unsigned char and change guint to unsigned int!)