I don't know what format this is, but the example file is extremely simple.
000000 47 4d 50 2d 32 30 30 00 e1 01 00 00 80 02 00 00 000010 00 00 00 00 20 00 00 00 20 00 00 00 00 00 18 00 000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff * 0007a0 33 86 41 34 86 43 36 86 44 36 86 44 36 87 45 37 ... 0e16d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff * 0e17a0
So looks like 0x20 bytes of the header and the rest is uncompressed image data. Header's got 8 byte magic file format string, something that looks like little-endian 4 bytes height (0x1e1=481 - a bit weird, I'd expect 480 but let's roll with it), similarly encoded width (0x280 = 640), and some unknown values. I guess those are picture data start (0x20), bits per pixel (0x18=24, 8-bit RGB), and maybe there are fields for palette start (0x20 again) and size (0 because there is no palette in this file). Let's check if data size looks OK - 0x20 + 0x1E1 * 0x280 * 3 = 0xE17A0. Yeah, perfect fit, this has got to be a straight uncompressed RGB image.
I've thrown together a simple Python converter to PPM file format:
import sys import struct file = sys.argv[1] with open(file, 'rb') as iff: magic, height, width, unk1, unk2, unk3, unk4 = struct.unpack("<8s6I", iff.read(32)) if magic != b'GMP-200\0': raise "Unknown magic" if unk1 != 0 or unk2 != 0x20 or unk3 != 0x20 or unk4 != 0x180000: print("WARNING: unknown header fields have unexpected values") with open(file + ".ppm", 'wb') as off: off.write(f"P6\n{width} {height}\n255\n".encode("ascii")) lines = [iff.read(width*3) for _ in range(height)] lines.reverse() # stored bottom-up in GMP-200, PPM needs up-bottom for line in lines: off.write(line)
Turns out the image was laid out from bottom up, like it is usually done with BMP files and Windows' DIB data (so I guess this file format is used with some oldie Windows application that uses Windows GDI to draw stuff). Hence data reversal in the converter.