You have to keep one thing in mind; it's not the bit length of the hash that is relevant, but the entropy of its source. If the source has less than 32 bits of entropy, then so will the hash. If you take the hash of every character of your password individually to get a set of keys, then each key has no more than 6 bits of entropy even if you calculate a 32-bit hash from it, since those 6 bits can only possibly generate 64 of the roughly 4.2 billion possible 32-bit hashes. One possible idea here could be to split the password into sets of 6 characters (6 characters then providing 36 bits, just above 32-bits for a hash), and do as many passes as you have 6-character sets.
If all you are after is a simple protection from the average user, then a single XOR pass with a PRNG seeded by a 32-bit hash of the password is probably more than enough for what you need. Who knows, it may even be enough to just rename your image.png to image.whatever and skip encryption entirely and get away with it.
You also have to be aware of one more thing if the intent is to protect game assets. If you, for example, upload your image as a texture, then it is quite a trivial task to intercept the data itself as you pass it to, say, OpenGL. No amount of encryption will help you here, since the OpenGL API provides only unencrypted data transfer.