Talk:Graphic Image Map (GIM)

Strings from GimConv EXE and DLL

image_format

RGBA8888....RGBA4444....RGBA5551....RGBA5650
INDEX32.INDEX16.INDEX8..INDEX4
DXT5EXT.DXT3EXT.DXT1EXT.DXT5....DXT3....DXT1

pixel_order

NORMAL
PSPIMAGE
FASTER
GENERIC

level_type

MIPMAP
MIPMAP2

• MIPMAP3, MIPMAP4, MIPMAP5, etc... doesnt works (not valid)

Some hints about hierarchy at the most deeper levels

IMAGE_INDEX
IMAGE_PLANE
IMAGE_LEVEL
IMAGE_FRAME

PALETTE_INDEX
PALETTE_LEVEL
PALETTE_FRAME

frame_type

SEQUENCE

???

HOLD
CYCLE
DISSOLVE
EVENT
CONSTANT
LINEAR

• frame_type with this values doesnt works

Frankensperiments

Block header size

This was made with the goal of identifying the last value at the block headers, the file is well formed but the value in red has been modifyed, originally was a 0x10 and has been changed to 0x20

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  2E 47 49 4D 31 2E 30 30 00 50 53 50 00 00 00 00  .GIM1.00.PSP....
00000010  00 02 00 00 00 00 00 E0 00 00 00 10 00 00 00 10  .......à........
00000020  00 03 00 00 00 00 00 80 00 00 00 10 00 00 00 10  .......€........
00000030  00 04 00 00 00 00 00 70 00 00 00 70 00 00 00 10  .......p...p....
00000040  00 30 00 00 00 03 00 00 00 04 00 02 00 20 00 10  .0........... ..
00000050  00 01 00 02 00 00 00 00 00 00 00 3C 00 00 00 40  ...........<...@
00000060  00 00 00 60 00 00 00 00 00 01 00 01 00 03 00 01  ...`............
00000070  55 53 45 52 44 41 54 41 41 52 45 41 00 00 00 40  USERDATAAREA...@
00000080  CA 5E 11 00 CA 5E 12 00 CA 5E 13 00 CA 5E 14 00  Ê^..Ê^..Ê^..Ê^..
00000090  CA 5E 21 00 CA 5E 22 00 CA 5E 23 00 CA 5E 24 00  Ê^!.Ê^".Ê^#.Ê^$.
000000A0  00 FF 00 00 00 00 00 50 00 00 00 50 00 00 00 20  .ÿ.....P...P... 
000000B0  4E 4F 50 41 44 44 2E 42 4D 50 00 41 64 6D 69 6E  NOPADD.BMP.Admin
000000C0  69 73 74 72 61 74 6F 72 00 54 68 75 20 41 70 72  istrator.Thu Apr
000000D0  20 31 39 20 30 39 3A 32 32 3A 35 31 20 32 30 31   19 09:22:51 201
000000E0  38 00 47 69 6D 43 6F 6E 76 20 31 2E 32 30 68 00  8.GimConv 1.20h.

At the time the area at 0xA0 is loaded (block id 0x00FF intended to store the file_info) the real header size is 0x10 but the value changed takes the next 0x10 bytes as part of the header... so it starts reading the file_info at offset 0xC0

This is how it looks when this file is converted GIM to GIS, note the strings at the bottom how has been cropped

.GIS 1.00

Picture "picture-0" {
	Image "image-0" {
		Format RGBA8888
		Order NORMAL
		Width 4
		Height 2
		PitchAlign 16
		HeightAlign 1
		PlaneMask 0x00000000
		LevelType MIPMAP
		LevelCount 1
		FrameType SEQUENCE
		FrameCount 1
		UserData "userdata-0" {
			0x52455355 0x41544144 0x41455241
		}
		Pixels "pixels-0" RGBA8888 NORMAL 4 2 16 1 {
			0x00115ECA 0x00125ECA 0x00135ECA 0x00145ECA
			0x00215ECA 0x00225ECA 0x00235ECA 0x00245ECA
		}
	}
}

FileInfo "file_info-0" {
	ProjectName "istrator"
	UserName "Thu Apr 19 09:22:51 2018"
	SavedDate "GimConv 1.20h"
	Originator "GimConv 1.20h"
}

Also, the length of the value marked in red is confirmed to be 4 bytes, it can be seen how the bytes are swapped when using the setting format_endian = little/big