Editing RCOXML Images

=Description=
The images inside .rco files are indexed in the embedded '''RCOXML''' code of the .rco container under the XML element '''ImageTree'''. See [[Resource Container (RCO)]] and [[RCOXML Coding]]

All the images (with a few exceptions) inside .rco files uses a sony propietary format that works as a image container, and allows for many different image formats, see [[GimConv]]

{{spoiler|RCOXML contents PS3|{{RCOXML contents PS3}}}}

=Image=
The values marked in red are optional, the presence of the '''unknown''' specific for PS3 can be deduced based on the "rco version" in the rco header, only exists in PS3 RCO's (PSP doesnt uses it). See [[Talk:Rcomage|rcomage talk page]]. The presence of the other optional value '''file_uncompressed_size''' can be deduced by reading the entry itself

The '''file_compression''' feature adds a compression layer over the file format (pointless for image formats that are nativelly compressed like GIM or JPG)

{| class="wikitable"
|-
! Offset !! Length !! Name !! Example !! Notes
|-
| 0x00 || 0x02 || '''file_format''' ||  || 0x0=PNG<br>0x1=JPEG<br>0x2=TIFF<br>0x3=GIF<br>0x4=BMP<br>0x5=GIM
|-
| 0x02 || 0x02 || '''file_compression''' ||  || 0x0=NONE<br>0x1=ZLIB<br>0x2=RLZ
|-
| 0x04 || 0x04 || '''file_size''' ||  || either compressed or uncompressed, this is the final size of the file stored inside the rco
|-
| 0x08 || 0x04 || '''file_offset''' ||  || 
|-
| 0x0C || 0x04 || {{cellcolors|#ff9999}} ''unknown'' ||  || Most PS3 RCOs have this extra value - probably something to do with planes/frames?? usually 0x1
|-
| 0x10 || 0x04 || {{cellcolors|#9999ff}} '''file_uncompressed_size''' ||  || Optional. Doesn't exist if '''file_compression''' = '''NONE''', for PSP is located 4 bytes before because the previous value doesn't exists
|}

*unknown
**RCO files version 0x93 included in some PS3 pre-retail firmwares (such DECR 082.006) doesnt have this value. But rcomage expects it to be there and when trying to extract the RCo contents it returns an error, loses the TOC track, and then does a "jump" of 4 bytes to locate the TOC track again and continue reading, The problem doesnt seems to be critical, the extraction is fine (the rebuilding not). This is an example of the error on system_plugin_bg.rco DECR 082.006
 Warning: [entry (0xf4)] Unexpected value 0x20a4 for PS3 image - expected 0x1.
 Warning: [entry (0xcc)] Entry boundaries not aligned (going forward -4 bytes)
 

{{File Formats}}
<noinclude>[[Category:Main]]</noinclude>