Talk:GimConv: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
mNo edit summary
(→‎GIS: there is something wrong in the examples)
Line 298: Line 298:
  }
  }
  }
  }
{{Boxwarning1|content='''The 4x4 size of the custom image used for the examples is illegal ?'''}}
The sizes follows some rule (that i ignore) related with proportions, when trying to convert an image with illegal size gimconv.exe doesnt advises you about the problem (except in one of the conversions i dont remember)... so it allows you to create a GIM with illegal size
In my image of 4x4 pixels, when converted to GIM, at absolute offset 0x50 it stores the value 0x0001... this value seems to be the '''HeightAlign''' that appears on the GIS
But at the time of doing the GIM to GIS conversion this value is "fixed" automatically (see example above with HeightAlign 8), and also has been added 16 pixels at bottom with color 0x00000000
When doing a GIS to GIM with the example above it creates a GIM image that stores double the pixels than the original (it stores that 0x00000000 too)
And when doing a GIM to PNG or GIM to BMP the resulting image has 4x4 pixels (the 0x00000000 pixels get lost)


=GIM format=
=GIM format=
*http://www.pujia8.com/articles/34/
*http://www.pujia8.com/articles/34/
*https://tieba.baidu.com/p/1733245285
*https://tieba.baidu.com/p/1733245285

Revision as of 01:37, 14 April 2018

GimConv.cfg modifications made for rcomage

Rcomage uses a GimConv.cfg (configuration file) edited by Zinga Burga to improve compatibility with rcoedit/rcomage and the GIM formats used in PSP

See: a comparison GimConv.cfg official vs rcomage, and this talk

Help screen

The help screen is just informative, is posted here just to complete the list of changes accuratelly, and because is related with some of the other changes made to the file

  • Removed at help screen:
Code Sample
  • Added at help screen:
Code Sample

Help screen Talk

  • The removed -F (to use pixel_order = faster) is because all PSP GIM format uses it, so it was modifyed as one of the default settings (more info below)
  • The removed -R and the added -X are related with the order of how RGBA channels are stored in the GIM, it seems -X was useful for PSP (and -R was not useful for PSP). This options are a bit pointless anyway, you should not swap RGBA channels this way by using this options directly
  • The removed -viewer is because was intended to start an official gimviewer.exe that has never been published or leaked (the program doesnt exists, so the option -viewer is pointless)
  • The added -bpp<n> are the RGBA based GIM formats used on PSP, this list includes some custom formats that was not used officially by sony (but works on PSP)
  • The added -ps3 loads a custom option that was intended for PS3 GIM files, but is wrong (more info about this problem below)

Default settings

The default settings used in the GimConv.cfg used by rcomage are problematic for PS3... up to an exent because as mentioned in frontpage at the time you write a command line for GimConv.exe you can write a long line with lot of settings (that are going to override any default setting you consider is problematic or critical for what you want to achieve)

The real problem is when you write a short command line for GimConv.exe (without overriding any default settings), by doing this you are using all the default settings... and this breaks GIM files for PS3

  • Changed default settings:
Code Sample
  • Removed default settings:
Code Sample

Default settings Talk

  • pixel_order
    • Originally (in the GimConv.cfg released by sony, intended for PS3) it was set to normal (this matches with the GIM format most used in PS3, and doesnt matches with the second most used GIM format in PS3 that needs to be default). For rcomage was changed to faster because all the GIM formats in PSP uses it
    • As you can see there is not a way to choose a default value for pixel_order that fits with the requirements of all known GIM formats, because one way or the other we are breaking some GIM files (either PSP or some for PS3), the solution to bypass this problem is to override this setting in every "option" you want to use (more info below)
    • In short... this change causes an small harm to PS3 GIM formats, but considering there is not really a single solution to fix this problem... is ok like this
  • limit_image_width and limit_image_height
    • Originally (in the GimConv.cfg released by sony, intended for PS3) both was set to 4096 pixels. For rcomage was changed to 512 because the size of the PSP screen is way smaller than PS3 (actually PSP screen is way smaller than 512 but it seems the values of this size restrictions are adjusted to an strict rule of proportions of width x height)
    • This problem affects all images bigger than 512 pixels converted by GimConv.exe GIM2PNG, GIM2GIM, PNG2GIM (and any other supported input image format to GIM). If the image is bigger than 512 it will be scaled down and the output image will have 512 pixels in one of its proportions (either width or height)
    • This settings allows to use the value off (to disable the image size restrictions ?) but when using it returns a WARNING : too large image size <width>x<height> (even with tiny images), it looks like it has a problem when geting the size so is not a good idea to disable this size restriction, instead is better to use the value 4096 that works fine and is what sony was using originally for PS3
    • As explained before... this problem can be bypassed by overriding this setting, either from command line or editing the file GimConv.cfg to create a custom option with the size values specific for PS3
    • Some GIM examples from PS3 with images bigger than 512 pixels in explore_plugin_full.rco:
      • tex_playing.gim (30x900 pixels) http://imgur.com/2rjGdbe
      • tex_playing_shadow.gim (30x900 pixels)
      • tex_opt_obi.gim (660x6 pixels)
    • Some GIM examples from PS3 with images bigger than 512 pixels in custom_render_plugin.rco :
      • tex_ps3logo.gim (1200x128 pixels)
      • tex_scelogo.gim (1024x64 pixels)
  • output_sequence
    • Originally (in the GimConv.cfg released by sony, intended for PS3) it was set to on. For rcomage was changed to off. I dont really know why, in my tests this setting doesnt changes anything (setting it to either on/off results in the same output files), actually i have it enabled just incase eventually i find is doing something extra (and because originally was enabled by sony), but by now nothing, nada
  • format_endian
    • Originally (in the GimConv.cfg released by sony, intended for PS3) this was added by sony as a "override default settings patch" applyed over GimConv.cfg (a section named PS3 OSD default settings) with the value format_endian = big. For rcomage it was removed (so by default it loads format_endian = little instead, that appears some lines before in GimConv.cfg)
    • This is ovbiouslly a problem for PS3, but again there is not a single way to preconfigure this setting to fill the requirements of all GIM formats. PSP needs "little", and PS3 "big", this needs to be overrided inside the "options" specific for each GIM format... or with a long command line specifying this overrides
  • pixel_order
    • Originally (in the GimConv.cfg released by sony, intended for PS3) this was added by sony as a "override default settings patch" applyed over GimConv.cfg (a section named PS3 OSD default settings) with the value pixel_order = normal. For rcomage it was removed (so by default it loads pixel_order = faster instead, that appears some lines before in GimConv.cfg)
    • PSP needs to use "faster" always, and PS3 needs "normal" and "default" (because in PS3 there are 2 different GIM formats), so again, this needs to be overrided inside the "options" specific for each GIM format... or with a long command line specifying this overrides
  • pixel_channel
    • Originally (in the GimConv.cfg released by sony, intended for PS3) this was added by sony as a "override default settings patch" applyed over GimConv.cfg (a section named PS3 OSD default settings) with the value pixel_channel = default. For rcomage it was removed (so by default it loads pixel_channel = default that appears some lines before in GimConv.cfg). In other words, sony overrided pixel_channel with the same value. This setting is pointless, is not doing anything
    • So the removal made for rcomage is not causing any change
  • image_format
    • Originally (in the GimConv.cfg released by sony, intended for PS3) this was added by sony as a "override default settings patch" applyed over GimConv.cfg (a section named PS3 OSD default settings) with the value image_format = rgba8888. For rcomage it was removed (so by default it loads image_format = default instead, that appears some lines before in GimConv.cfg)
    • This is a must to override, is one of the most critical settings, there are several values that are supported by PSP and PS3 (index4, index8, rgba5551, rgba4444, rgba5650, rgba8888, dxt5... and maybe more)
    • So the removal made for rcomage is not causing any harm, is needed to override this setting anyway

Options

  • Added options:
Code Sample
  • Removed options:
Code Sample

Options Talk

  • -ps3
    • Biggest problem when using this option is you are going to load all the default settings, and there are some default settings that results in a GIM file incompatible with PS3
    • The second problem related with this is wrong in concept, because inside PS3 RCO files are used (at least) 2 different GIM formats (that needs to be build by using different GIM settings), to make this problem even worse in most of the RCO files from PS3 firmware are included GIM files build with different GIM formats... so aplying a single collection of settings for all the GIM files inside a single RCO doesnt works ! (you can be sure some are going to be broken... becaue there are 2 GIM formats you are going to have broken a group of them... or the other)
    • Is not compatible with how rcomage automatizes the PNG-to-GIM conversions (for the same reason explained in the line above), with the actual code of rcomage is imposible to automatize the PNG-to-GIM conversions
    • "format_style = ps3". For some reason sony implemented this "tag" at the time of coding GimConv.exe but is not used in PS3 GIM files !, actually the GIM files for PS3 uses the tag "psp"
  • -bpp4, -bpp8, -bpp16, -bpp16a, -bpp16p, -bpp32
    • Are the GIM formats used in PSP, keep in mind this definitions are not including some critical settings that are hardcoded in GimView.cfg as defaults (such the endianess)
    • All this options are optionals anyway, so is not causing any harm to PS3 compatibility, if you dont need them simply dont use them
  • The other removed options
    • Doesnt have much importance, could cause problems depending in what you have for default settings in the lines at top of GimView.cfg you should not use this options directly or individually

Examples

BMP

This is an image created in photoshop with size 2x2 pixels, filled with color 0xC0FFEE (RGB), and saved as a BMP 32 bits color depth, and named 4x4_C0FFEE_32bits.bmp

The pixel color info is stored in the bytes colored (4x4 = 16 pixels in total, 4 bytes each) 

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

00000000  42 4D 78 00 00 00 00 00 00 00 36 00 00 00 28 00  BMx.......6...(.
00000010  00 00 04 00 00 00 04 00 00 00 01 00 20 00 00 00  ............ ...
00000020  00 00 00 00 00 00 12 0B 00 00 12 0B 00 00 00 00  ................
00000030  00 00 00 00 00 00 EE FF C0 00 EE FF C0 00 EE FF  ......îÿÀ.îÿÀ.îÿ
00000040  C0 00 EE FF C0 00 EE FF C0 00 EE FF C0 00 EE FF  À.îÿÀ.îÿÀ.îÿÀ.îÿ
00000050  C0 00 EE FF C0 00 EE FF C0 00 EE FF C0 00 EE FF  À.îÿÀ.îÿÀ.îÿÀ.îÿ
00000060  C0 00 EE FF C0 00 EE FF C0 00 EE FF C0 00 EE FF  À.îÿÀ.îÿÀ.îÿÀ.îÿ
00000070  C0 00 EE FF C0 00 00 00                          À.îÿÀ...

GIM PS3 DXT5

  • Second most common GIM format used in PS3
Type This
'''GimConv.exe 4x4_C0FFEE_32bits.bmp -o 4x4_C0FFEE_32bits_ps3dxt5.gim -ps3dxt5'''
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 80 00 00 00 10 00 00 00 10  .......€........
00000020  00 03 00 00 00 00 00 70 00 00 00 10 00 00 00 10  .......p........
00000030  00 04 00 00 00 00 00 60 00 00 00 60 00 00 00 10  .......`...`....
00000040  00 30 00 00 00 0A 00 00 00 04 00 04 00 08 00 04  .0..............
00000050  00 04 00 02 00 00 00 00 00 00 00 30 00 00 00 40  ...........0...@
00000060  00 00 00 50 00 00 00 00 00 01 00 01 00 03 00 01  ...P............
00000070  00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
00000080  FF 00 49 92 24 49 92 24 FD C7 FD C7 00 00 00 00  ÿ.I’$I’$ýÇýÇ....

GIM PS3 RGBA32

  • First most common GIM format used in PS3
Type This
'''GimConv.exe 4x4_C0FFEE_32bits.bmp -o 4x4_C0FFEE_32bits_ps3bpp32.gim -ps3bpp32'''
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 B0 00 00 00 10 00 00 00 10  .......°........
00000020  00 03 00 00 00 00 00 A0 00 00 00 10 00 00 00 10  ....... ........
00000030  00 04 00 00 00 00 00 90 00 00 00 90 00 00 00 10  ................
00000040  00 30 00 00 00 03 00 00 00 04 00 04 00 20 00 10  .0........... ..
00000050  00 01 00 02 00 00 00 00 00 00 00 30 00 00 00 40  ...........0...@
00000060  00 00 00 80 00 00 00 00 00 01 00 01 00 03 00 01  ...€............
00000070  00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
00000080  C0 FF EE 00 C0 FF EE 00 C0 FF EE 00 C0 FF EE 00  Àÿî.Àÿî.Àÿî.Àÿî.
00000090  C0 FF EE 00 C0 FF EE 00 C0 FF EE 00 C0 FF EE 00  Àÿî.Àÿî.Àÿî.Àÿî.
000000A0  C0 FF EE 00 C0 FF EE 00 C0 FF EE 00 C0 FF EE 00  Àÿî.Àÿî.Àÿî.Àÿî.
000000B0  C0 FF EE 00 C0 FF EE 00 C0 FF EE 00 C0 FF EE 00  Àÿî.Àÿî.Àÿî.Àÿî.

GIM PS3 RGBA32 with footer

  • First most common GIM format used in PS3 with footer !
Type This
'''GimConv.exe 4x4_C0FFEE_32bits.bmp -o 4x4_C0FFEE_32bits_ps3bpp32_footer.gim -ps3bpp32 --update_fileinfo on'''
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 01 0C 00 00 00 10 00 00 00 10  ................
00000020  00 03 00 00 00 00 00 A0 00 00 00 10 00 00 00 10  ....... ........
00000030  00 04 00 00 00 00 00 90 00 00 00 90 00 00 00 10  ................
00000040  00 30 00 00 00 03 00 00 00 04 00 04 00 20 00 10  .0........... ..
00000050  00 01 00 02 00 00 00 00 00 00 00 30 00 00 00 40  ...........0...@
00000060  00 00 00 80 00 00 00 00 00 01 00 01 00 03 00 01  ...€............
00000070  00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
00000080  C0 FF EE 00 C0 FF EE 00 C0 FF EE 00 C0 FF EE 00  Àÿî.Àÿî.Àÿî.Àÿî.
00000090  C0 FF EE 00 C0 FF EE 00 C0 FF EE 00 C0 FF EE 00  Àÿî.Àÿî.Àÿî.Àÿî.
000000A0  C0 FF EE 00 C0 FF EE 00 C0 FF EE 00 C0 FF EE 00  Àÿî.Àÿî.Àÿî.Àÿî.
000000B0  C0 FF EE 00 C0 FF EE 00 C0 FF EE 00 C0 FF EE 00  Àÿî.Àÿî.Àÿî.Àÿî.
000000C0  00 FF 00 00 00 00 00 5C 00 00 00 5C 00 00 00 10  .ÿ.....\...\....
000000D0  34 78 34 5F 43 30 46 46 45 45 5F 33 32 62 69 74  4x4_C0FFEE_32bit
000000E0  73 2E 62 6D 70 00 41 64 6D 69 6E 69 73 74 72 61  s.bmp.Administra
000000F0  74 6F 72 00 46 72 69 20 41 70 72 20 31 33 20 30  tor.Fri Apr 13 0
00000100  31 3A 35 37 3A 34 37 20 32 30 31 38 00 47 69 6D  1:57:47 2018.Gim
00000110  43 6F 6E 76 20 31 2E 32 30 68 00 00              Conv 1.20h..

If you compare this file with the previous one (same format without footer) the only differences are the bytes marked in red

  • The value at the header is the file size - 0x10, it changes because the file was increased in size (to add the footer)
  • Footer is composed by:
    • 4x4_C0FFEE_32bits.bmp (original file name)
    • Administrator (windows user account)
    • Fri Apr 13 01:57:47 2018 (timestamp)
    • GimConv 1.20h (GimConv.exe version used to create the GIM file)

GIS

  • This is the script format, it can be generated using any image format as input, but is mostly useful to identify GIM formats by making a GIM to GIS conversion
Type This
'''GimConv.exe 4x4_C0FFEE_32bits_ps3bpp32.gim -o 4x4_C0FFEE_32bits_ps3bpp32.gis -S'''
.GIS 1.00

Picture "picture-0" {
	Image "image-0" {
		Format RGBA8888
		Order PSPIMAGE
		Width 4
		Height 4
		PitchAlign 16
		HeightAlign 8
		PlaneMask 0x00000000
		LevelType MIPMAP
		LevelCount 1
		FrameType SEQUENCE
		FrameCount 1
		Pixels "pixels-0" RGBA8888 PSPIMAGE 4 4 16 8 {
			0x00EEFFC0 0x00EEFFC0 0x00EEFFC0 0x00EEFFC0
			0x00EEFFC0 0x00EEFFC0 0x00EEFFC0 0x00EEFFC0
			0x00EEFFC0 0x00EEFFC0 0x00EEFFC0 0x00EEFFC0
			0x00EEFFC0 0x00EEFFC0 0x00EEFFC0 0x00EEFFC0
			0x00000000 0x00000000 0x00000000 0x00000000
			0x00000000 0x00000000 0x00000000 0x00000000
			0x00000000 0x00000000 0x00000000 0x00000000
			0x00000000 0x00000000 0x00000000 0x00000000
		}
	}
}
Warning
Warning
The 4x4 size of the custom image used for the examples is illegal ?

The sizes follows some rule (that i ignore) related with proportions, when trying to convert an image with illegal size gimconv.exe doesnt advises you about the problem (except in one of the conversions i dont remember)... so it allows you to create a GIM with illegal size

In my image of 4x4 pixels, when converted to GIM, at absolute offset 0x50 it stores the value 0x0001... this value seems to be the HeightAlign that appears on the GIS

But at the time of doing the GIM to GIS conversion this value is "fixed" automatically (see example above with HeightAlign 8), and also has been added 16 pixels at bottom with color 0x00000000

When doing a GIS to GIM with the example above it creates a GIM image that stores double the pixels than the original (it stores that 0x00000000 too)

And when doing a GIM to PNG or GIM to BMP the resulting image has 4x4 pixels (the 0x00000000 pixels get lost)

GIM format

Retrieved from "http://www.psdevwiki.com/ps3/index.php?title=Talk:GimConv&oldid=48920"