Talk:Graphic Image Map (GIM): Difference between revisions
Line 97: | Line 97: | ||
Originator "GimConv 1.20h" | Originator "GimConv 1.20h" | ||
} | } | ||
Also, the length of the value marked in reb is confirmed to be 4 bytes, it can be seen how the bytes are swapped when using the setting '''format_endian''' = little/big |
Revision as of 09:05, 19 April 2018
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 reb is confirmed to be 4 bytes, it can be seen how the bytes are swapped when using the setting format_endian = little/big