Difference between revisions of "BFLIM (File Format)"

From MK8
Jump to navigation Jump to search
 
(41 intermediate revisions by 5 users not shown)
Line 1: Line 1:
The BFLIM file format is used to store layout images.
+
The '''BFLIM''' file format ('''B'''inary ca'''F'''e '''L'''ayout '''IM'''age) is used to store layout images.
 +
 
 +
== Header ==
 +
The header is at the end of the file (to align the image data without the need for additional padding). It is always 0x14 bytes.
  
==Parsing information==
 
===Header===
 
The header is, for whatever reason, at the end of the file. It is always 0x14 bytes.
 
 
{| class="wikitable"
 
{| class="wikitable"
! Offset
+
! Offset !! Size !! Type !! Description
! Size
 
! Description
 
 
|-
 
|-
|0x00
+
| 0x00 || 4 || Char[4] || '''File magic'''. Always ''FLIM'' in ASCII.
|4
 
|"'''FLIM'''" File Identifier, ASCII string.
 
 
|-
 
|-
|0x04
+
| 0x04 || 2 || UInt16 || {{BOM}} Not handled on consoles, so the file data must be stored in the endianness of the target console (e.g. big endian for the Wii U).
|2
 
|'''Byte order mark''' (BOM): 0xFE,0xFF for big endian and 0xFF,0xFE for little endian.
 
 
|-
 
|-
|0x06
+
| 0x06 || 2 || UInt16 || '''Header size''', always 0x14.
|2
 
|'''Header size''', always 0x14.
 
 
|-
 
|-
|0x08
+
| 0x08 || 4 || UInt32 || '''Version''' of this file.
|4
 
|'''Unknown''', usually 0x03030000 or 0x02020000.
 
 
|-
 
|-
|0x0C
+
| 0x0C || 4 || UInt32 || '''File size''' in bytes.
|4
 
|'''Filesize'''
 
 
|-
 
|-
|0x10
+
| 0x10 || 2 || UInt16 || '''Number of data blocks''', always 0x01.
|2
 
|'''Unknown''', always 0x01.
 
 
|-
 
|-
|0x12
+
| 0x12 || 2 || UInt16 || Padding. Seems to reflect upper 2 bytes of filesize (apparently uninitialized memory garbage from file generator).
|1
 
|'''Multiplier?''', always upper 2 bytes of filesize.
 
 
|-
 
|-
|0x13
+
| 0x14 || colspan="3" {{Unknown|End of '''FLIM''' header}}
|1
 
|'''Unknown''', always 0.
 
 
|}
 
|}
  
===Data Information===
+
== Image Information ==
Comes directly after header, always 0x14 bytes. Formats not the same in games like NSMBU, be sure to use filename if possible (EG: ^l).
+
A section containing image information comes directly after header. It is always 0x14 bytes long.
 +
 
 
{| class="wikitable"
 
{| class="wikitable"
! Offset
+
! Offset !! Size !! Type !! Description
! Size
+
|-
! Description
+
| 0x14 || 4 || Char[4] || '''Section magic'''. Always ''imag'' in ASCII.
 
|-
 
|-
|0x14
+
| 0x18 || 4 || UInt32 || '''Parse information size''' (total block size), always 0x10 (this and next 0xC bytes).
|4
 
|"'''imag'''", some signature, ASCII string.
 
 
|-
 
|-
|0x18
+
| 0x1C || 2 || UInt16 || '''Width''' of the texture in pixels.
|4
 
|'''Parse information size''', always 0x10 (this and next 0xC bytes).
 
 
|-
 
|-
|0x1C
+
| 0x1E || 2 || UInt16 || '''Height''' of the texture in pixels.
|2
 
|'''Width'''
 
 
|-
 
|-
|0x1E
+
| 0x20 || 2 || UInt16 || '''File alignment''', always a power of 2.
|2
 
|'''Height'''
 
 
|-
 
|-
|0x20
+
| 0x22 || 1 || Byte || '''Format''', how the data is stored.
|2
 
|'''Alignment''' usually 0x800 (2048) or 0x1000 (4096)
 
 
|-
 
|-
|0x22
+
| 0x23 || 1 || Byte || '''Tile mode''' and '''Swizzle''', packed as bits '''SSSTTTTT'''.
|1
+
* '''TTTTT''' maps to GX2TileMode (line 795 [https://pastebin.com/DCrP1w9x here]). Typically GX2_TILE_MODE_2D_TILED_THIN1 (4).
|'''Format''', how the data is stored.
+
* '''SSS''' is the initial swizzle value. Could be anything from 0 to 7.
 
|-
 
|-
|0x23
+
| 0x24 || 4 || UInt32 || '''Raw data size''', always 0xC minus 0x28 (the header).
|1
 
|'''Swizzle''', first nibble is swizzle times two (2 is 1, 4 is 2, etc), second seems to always 4
 
 
|-
 
|-
|0x24
+
| 0x28 || colspan="3" {{Unknown|End of '''Image''' header}}
|4
 
|'''Raw data size''', always 0xC minus 0x28 (the header).
 
 
|}
 
|}
  
==Format==
+
== Format ==
 
{| class="wikitable"
 
{| class="wikitable"
! ID
+
! ID !! Name !! Type !! Bits Per Pixel (BPP)
! Name
+
|-
! Type
+
| 0x00 || L8_UNORM || Luminance || 8
! Bits per pixel
+
|-
! Notes
+
| 0x01 || A8_UNORM || Alpha || 8
 +
|-
 +
| 0x02 || LA4_UNORM || Luminance + Alpha || 8
 +
|-
 +
| 0x03 || LA8_UNORM || Luminance + Alpha || 16
 +
|-
 +
| 0x04 || HILO8 || ? || 16
 +
|-
 +
| 0x05 || RGB565_UNORM || Color || 16
 +
|-
 +
| 0x06 || RGBX8_UNORM || Color || 32
 +
|-
 +
| 0x07 || RGB5A1_UNORM || Color + Alpha || 16
 +
|-
 +
| 0x08 || RGBA4_UNORM || Color + Alpha  || 16
 +
|-
 +
| 0x09 || RGBA8_UNORM || Color + Alpha || 32
 
|-
 
|-
|0x00
+
| 0x0A || ETC1_UNORM || Color || 4
|R8_UNORM
 
|single-color
 
|8
 
|^c BFLIM files
 
 
|-
 
|-
|0x01
+
| 0x0B || ETC1A4_UNORM || Color + Alpha || 8
|R8_UNORM
 
|single-color
 
|8
 
|^d BFLIM files
 
 
|-
 
|-
|0x03
+
| 0x0C || BC1_UNORM || Color + Alpha || 4
|R8_G8_UNORM
 
|
 
|16
 
|^f BFLIM files
 
 
|-
 
|-
|0x05
+
| 0x0D || BC2_UNORM || Color + Alpha || 8
|RGB565
 
|color
 
|
 
|^h BFLIM files
 
 
|-
 
|-
|0x0C
+
| 0x0E || BC3_UNORM || Color + Alpha || 8
|BC1_UNORM / DXT1
 
|
 
|16
 
|^i BFLIM files
 
 
|-
 
|-
|0x0E
+
| 0x0F || BC4L_UNORM || Luminance || 4
|BC3_UNORM / DXT5
 
|
 
|16
 
|^k BFLIM files
 
 
|-
 
|-
|0x0F
+
| 0x10 || BC4A_UNORM || Alpha || 4
|I4? / BC4_UNORM / ATI1 (Low-End)
 
|grey
 
|
 
|^r BFLIM files
 
 
|-
 
|-
|0x10
+
| 0x11 || BC5_UNORM || Red + Green + Alpha || 8
|IA4? / BC4_UNORM / ATI (High-End)
 
|color+alpha
 
|
 
|^s BFLIM files
 
 
|-
 
|-
|0x11
+
| 0x12 || L4_UNORM || Luminance || 4
|I8? / BC5_UNORM / ATI2
 
|color
 
|
 
|^t BFLIM files
 
 
|-
 
|-
|0x12
+
| 0x13 || A4_UNORM || Alpha || 4
|IA8?
 
|color+alpha
 
|
 
|
 
 
|-
 
|-
|0x14 / 0x09
+
| 0x14 || RGBA8_SRGB || Color + Alpha || 32
|RGBA32_UNORM / RGBA8888
 
|color+alpha
 
|32
 
|^l BFLIM files
 
 
|-
 
|-
|0x15
+
| 0x15 || BC1_SRGB || Color + Alpha || 4
|BC1_UNORM / DXT1
 
|Compressed
 
|32
 
|^o BFLIM files
 
 
|-
 
|-
|0x16
+
| 0x16 || BC2_SRGB || Color + Alpha || 8
|BC2_UNORM / DXT3
 
|Compressed
 
|32
 
|^p BFLIM files
 
 
|-
 
|-
|0x17
+
| 0x17 || BC3_SRGB || Color + Alpha || 8
|BC3_UNORM / DXT5
 
|Compressed
 
|32
 
|^q BFLIM files
 
 
|-
 
|-
|
+
| 0x18 || RGB10A2_UNORM || Color + Alpha || 32
|
 
|
 
|
 
|^e BFLIM files
 
 
|-
 
|-
 +
| 0x19 || RGB565_INDIRECT_UNORM || Color? || 16
 
|}
 
|}
  
 
= Tools =
 
= Tools =
 +
The following tools can handle BFLIM files:
  
The following tools can extract (and generate) BFLIM files:
+
* [https://github.com/aboood40091/BFLIM-Tool/releases/tag/v1.0 BFLIM Tool], by [[User:Aboood40091|AboodXD]]
 +
* [https://mega.nz/#!KgRilZAR!qLGAx1yb9KduShuzxwZjd7nuN329nMjDQvrX9sy-CsE BFLIMtoGTX], by [[User:RandomTalkingBush|RandomTalkingBush]]
 +
* [[Wexos's Toolbox]], by [[Wexos]]
  
* [https://mega.nz/#!KgRilZAR!qLGAx1yb9KduShuzxwZjd7nuN329nMjDQvrX9sy-CsE BFLIMtoGTX], by [[User:RandomTalkingBush|TandomTalkingBush]]
+
[[Category:File Format]]
* [https://github.com/aboood40091/BFLIM-Extractor BFLIM Extractor], by [[User:Aboood40091|AboodXD]]
 

Latest revision as of 09:42, 3 November 2017

The BFLIM file format (Binary caFe Layout IMage) is used to store layout images.

Header

The header is at the end of the file (to align the image data without the need for additional padding). It is always 0x14 bytes.

Offset Size Type Description
0x00 4 Char[4] File magic. Always FLIM in ASCII.
0x04 2 UInt16 Byte Order Mark (BOM): 0xFEFF for big endian and 0xFFFE for little endian. Not handled on consoles, so the file data must be stored in the endianness of the target console (e.g. big endian for the Wii U).
0x06 2 UInt16 Header size, always 0x14.
0x08 4 UInt32 Version of this file.
0x0C 4 UInt32 File size in bytes.
0x10 2 UInt16 Number of data blocks, always 0x01.
0x12 2 UInt16 Padding. Seems to reflect upper 2 bytes of filesize (apparently uninitialized memory garbage from file generator).
0x14 End of FLIM header

Image Information

A section containing image information comes directly after header. It is always 0x14 bytes long.

Offset Size Type Description
0x14 4 Char[4] Section magic. Always imag in ASCII.
0x18 4 UInt32 Parse information size (total block size), always 0x10 (this and next 0xC bytes).
0x1C 2 UInt16 Width of the texture in pixels.
0x1E 2 UInt16 Height of the texture in pixels.
0x20 2 UInt16 File alignment, always a power of 2.
0x22 1 Byte Format, how the data is stored.
0x23 1 Byte Tile mode and Swizzle, packed as bits SSSTTTTT.
  • TTTTT maps to GX2TileMode (line 795 here). Typically GX2_TILE_MODE_2D_TILED_THIN1 (4).
  • SSS is the initial swizzle value. Could be anything from 0 to 7.
0x24 4 UInt32 Raw data size, always 0xC minus 0x28 (the header).
0x28 End of Image header

Format

ID Name Type Bits Per Pixel (BPP)
0x00 L8_UNORM Luminance 8
0x01 A8_UNORM Alpha 8
0x02 LA4_UNORM Luminance + Alpha 8
0x03 LA8_UNORM Luminance + Alpha 16
0x04 HILO8 ? 16
0x05 RGB565_UNORM Color 16
0x06 RGBX8_UNORM Color 32
0x07 RGB5A1_UNORM Color + Alpha 16
0x08 RGBA4_UNORM Color + Alpha 16
0x09 RGBA8_UNORM Color + Alpha 32
0x0A ETC1_UNORM Color 4
0x0B ETC1A4_UNORM Color + Alpha 8
0x0C BC1_UNORM Color + Alpha 4
0x0D BC2_UNORM Color + Alpha 8
0x0E BC3_UNORM Color + Alpha 8
0x0F BC4L_UNORM Luminance 4
0x10 BC4A_UNORM Alpha 4
0x11 BC5_UNORM Red + Green + Alpha 8
0x12 L4_UNORM Luminance 4
0x13 A4_UNORM Alpha 4
0x14 RGBA8_SRGB Color + Alpha 32
0x15 BC1_SRGB Color + Alpha 4
0x16 BC2_SRGB Color + Alpha 8
0x17 BC3_SRGB Color + Alpha 8
0x18 RGB10A2_UNORM Color + Alpha 32
0x19 RGB565_INDIRECT_UNORM Color? 16

Tools

The following tools can handle BFLIM files: