PS3 RCOMAGE Mod 1.9 - Proper & Automated GIM to PNG conversion, Dump & Compile Files.

[LuanTeles]

Which format preserves more details?

I noticed that my custom notification icons are pixelated.

So a decompiled the rco again with my custom icons and transformed them back to png and i noticed they are pixelated a lot.

 

[sandungas]

Which format preserves more details?

I noticed that my custom notification icons are pixelated.

So a decompiled the rco again with my custom icons and transformed them back to png and i noticed they are pixelated a lot.

GIM images made with the option rgba8888 are lossless, you can try this to check it:

1) convert original.png to converted.gim with option -rgba8888
2) convert converted.gim to converted.png
3) compare the MD5 hashes of original.png and converted.png.... should be identical

*You can repeat this process as many times you want and the resulting .png at the end is identical to the original

 

[LuanTeles]

GIM images made with the option rgba8888 are lossless, you can try this to check it:

1) convert original.png to converted.gim with option -rgba8888
2) convert converted.gim to converted.png
3) compare the MD5 hashes of original.png and converted.png.... should be identical

*You can repeat this process as many times you want and the resulting .png at the end is identical to the original

Thanks, they are identical indeed

But it broke some things in the xmb due to its size hahaha, but i will keep only one notification at -rgba8888 that is the one that pop-up more frequently, it should work

 

[sandungas]

Thanks, they are identical indeed

But it broke some things in the xmb due to its size hahaha, but i will keep only one notification at -ps3rgba8888 that is the one that pop-up more frequently, it should work

The numbers at the end of the option name are the "bits per channel" btw

rgba8888 means... Red = 8 bits, Green = 8 bits, Blue = 8 bits, Alpha = 8 bits
8 bits are 1 byte
And 32 bits are 4 bytes
So rgba8888 uses 4 bytes to store the color

The other alternatives gives smaller image quality (and smaller file size), but sometimes some of them are going to give a pretty similar image quality

You can try -ps3index32, this is like -ps3rgba8888 but using an indexed color palette
And -ps3rgba4444 ... this is half the size than -ps3rgba8888 (and half the number of colors too)
Im not sure if can be used in the PS3 XMB without problems though

 

[RandomDude]

The numbers at the end of the option name are the "bits per channel" btw

rgba8888 means... Red = 8 bits, Green = 8 bits, Blue = 8 bits, Alpha = 8 bits
8 bits are 1 byte
And 32 bits are 4 bytes
So rgba8888 uses 4 bytes to store the color

The other alternatives gives smaller image quality (and smaller file size), but sometimes some of them are going to give a pretty similar image quality

You can try -ps3index32, this is like -ps3rgba8888 but using an indexed color palette
And -ps3rgba4444 ... this is half the size than -ps3rgba8888 (and half the number of colors too)
Im not sure if can be used in the PS3 XMB without problems though

afaik, sometimes using different file formats can cause glitches or white textures?

I don't remember as much, but recompiling rco's with different gim settings always lead me to some sort of glitch or white textures. Does ps3rgba8888 really work with all png files without causing a system crash?

 

[RandomDude]

If it's true tho, I'll start the tool from scratch to make provisions for manual conversions and make it open source since I've lost the source files after a reformat lmao.

 

[sandungas]

afaik, sometimes using different file formats can cause glitches or white textures?

I don't remember as much, but recompiling rco's with different gim settings always lead me to some sort of glitch or white textures. Does ps3rgba8888 really work with all png files without causing a system crash?

Yes the icons displayed with a fully opaque and squared white texture uses to be because invalid GIM settings... also sometimes happens because some kind of max size restriction (either max size of the whole rco, or the images inside it, or something like that, we are not sure)

But sometimes there are icons that acepts different GIM settings... we was messing around with the images inside impose_plugin.rco and depending of his sizes they allows to use different GIM settings

As far i know we have not found the rule of why it works this way... so there is no way to know it before trying
For someone that wants to play safe (and have success at first try) is better to use the same GIM settings than the originals... but for LuanTeles that is having lot of problems of size worths a try to use alternative GIM settings

 

[RandomDude]

Yes the icons displayed with a fully opaque and squared white texture uses to be because invalid GIM settings... also sometimes happens because some kind of max size restriction (either max size of the whole rco, or the images inside it, or something like that, we are not sure)

But sometimes there are icons that acepts different GIM settings... we was messing around with the images inside impose_plugin.rco and depending of his sizes they allows to use different GIM settings

As far i know we have not found the rule of why it works this way... so there is no way to know it before trying
For someone that wants to play safe (and have success at first try) is better to use the same GIM settings than the originals... but for LuanTeles that is having lot of problems of size worths a try to use alternative GIM settings

hmm it could be that the hashes had been mismatched somewhere which lead to a different conversion setting. @LuanTeles could you send me the rco file and tell me which gim file became pixelated so I can try recreate the scenario to find out if something's wrong.

 

[sandungas]

hmm it could be that the hashes had been mismatched somewhere which lead to a different conversion setting. @LuanTeles could you send me the rco file and tell me which gim file became pixelated so I can try recreate the scenario to find out if something's wrong.

Doesnt seems to be the program, note what he said:

Thanks, they are identical indeed

But it broke some things in the xmb due to its size hahaha, but i will keep only one notification at -rgba8888 that is the one that pop-up more frequently, it should work

He had a pixelation problem with an icon... so it was not using rgba888 because as i said this is lossless (no pixelation posible)
Most probably the pixelation was because originally that icon was made with the option -ps3dxt5 (or -ps3dxt3 that has a bit more pixelation)
After my suggestion he converted the icon again with rgba888 and it seems it was displayed fine (and without pixelation)... but as a colaterall damage it looks other icons was displayed in white

If i remember right is the same that was happening in some of the experiments in impose_plugin.rco

 

[RandomDude]

After my suggestion he converted the icon again with rgba888 and it seems it was displayed fine (and without pixelation)... but as a colaterall damage it looks other icons was displayed in white

So a decompiled the rco again with my custom icons and transformed them back to png and i noticed they are pixelated a lot.

Hmmm, so multiple recompilations are what's causing the pixelated look. That's kind of bad. What we could do is store these images in a separate image database folder and allow the user to edit the image files only inside the image database folder. So whenever the user hits the compile button it takes the images from the image database folder copies it to the rco dumped folder, turned into gims and recompiles from that.

This all could be automated however, a little bit more work is required. Would this be an efficient solution?

 

[LuanTeles]

Yes the icons displayed with a fully opaque and squared white texture uses to be because invalid GIM settings... also sometimes happens because some kind of max size restriction (either max size of the whole rco, or the images inside it, or something like that, we are not sure)

But sometimes there are icons that acepts different GIM settings... we was messing around with the images inside impose_plugin.rco and depending of his sizes they allows to use different GIM settings

As far i know we have not found the rule of why it works this way... so there is no way to know it before trying
For someone that wants to play safe (and have success at first try) is better to use the same GIM settings than the originals... but for LuanTeles that is having lot of problems of size worths a try to use alternative GIM settings

I don't undestand how it works too, like i converted all notification icons inside system_explore.rco to rgba8888 it works but it breaks the in-game impose screen with all icons white. ( it breakes other rcos )

So i dont undestand, sometimes if the rco becomes too big it will have the images all white (impose.rco as examble).

Other case is the sysconf_plugin.rco , i don't remember the exatcly file size but lets say mine is 1.29Mb but sometimes if i add a big image it will freeze the system settings upon click (even using valid gim settings) but the Rebug one is 1.49MB so i don't know what happens here.

In the same rco, i added a lot of custom animations the size is still 1.29 but if a lot of animations are added it will freeze too, but this is due to characters quantity, so i changed the animations names like "circle light animation" to CLA all using abbreviations and it works ( but it is a mess after to identify them), mine currently is at the limit if i added one more characters it will freeze, but the size here doesn't matter but sometimes it matter, so it's confusing

 

[LuanTeles]

Doesnt seems to be the program, note what he said:

He had a pixelation problem with an icon... so it was not using rgba888 because as i said this is lossless (no pixelation posible)
Most probably the pixelation was because originally that icon was made with the option -ps3dxt5 (or -ps3dxt3 that has a bit more pixelation)
After my suggestion he converted the icon again with rgba888 and it seems it was displayed fine (and without pixelation)... but as a colaterall damage it looks other icons was displayed in white

If i remember right is the same that was happening in some of the experiments in impose_plugin.rco

Yeap the notifications in the system plugin are -ps3dxt5 so it got pixelated,so editing the database to - rgba888 fully solved it.

But i recommend not to change it in the db as the rco becames 15kb bigger and breaks the in-game images, (i'm not 100% sure if with the default images it will have the same behaviour)

 

[RandomDude]

Yeap the notifications in the system plugin are -ps3dxt5 so it got pixelated, - rgba888 fully solved it

If that does it then you can manually go to the database folder of the rcomage and go to the system_plugin.rco database and find the gim txt file you're searching for.

Example if tex_notification_settings.gim is causing problems then you can go to the database folder, click on the database - system_plugin.rco, click on tex_notification_settings.txt and change it from -ps3dxt5 to -ps3rgba8888

 

[LuanTeles]

If it's true tho, I'll start the tool from scratch to make provisions for manual conversions and make it open source since I've lost the source files after a reformat lmao.

if you start the tool from scratch would be possible to add the sound: tag?

to see if the system accepts it

e.g to add a xmb background music ( i think it will break due to it's size, but worth a try)

 

[LuanTeles]

If that does it then you can manually go to the database folder of the rcomage and go to the system_plugin.rco database and find the gim txt file you're searching for.

Example if tex_notification_settings.gim is causing problems then you can go to the database folder, click on the database - system_plugin.rco, click on tex_notification_settings.txt and change it from -ps3dxt5 to -ps3rgba8888

Yeap that's what i did

 

[LuanTeles]

And btw...
While doing this tests with the problematic bdp_plugin.rco make a couple of tests by changing the language in your XMB settings
This is another blind shoot... but just in case

this is still a problem, i tried many things and i still figured it out, what causes this

@RandomDude any idea? decompiling and recompiling bdp_plugin.rco even without a single modification will break the volume option in the video screen

 

[RandomDude]

Try using this tool for the bdp_plugin.rco.

Decompile and recompile and then check if it works.

https://www.psx-place.com/threads/research-rcomage-psdevwiki-mod.17958/

 

[sandungas]

Hmmm, so multiple recompilations are what's causing the pixelated look.

Yes, the only format not affected by it is rgba8888

As example... if you do a PNG ---to---> DXT5 ---to---> PNG ---to---> DXT5 ---to---> PNG

Everytime is converted to DXT5 is used an algorithm to "resample" the color of all the pixels... and this always generates different pixels (is imposible to have a result exactly like the original)

Initially it should not be a problem, becaue that algorithms are intended to "soften" the image and should not be much notable, the first conversion should be the most notable visually and the others not so much

But the fact is everytime is converted you are a bit far away than the original pixel colors... is like degrading the color info :/

Other case is the sysconf_plugin.rco , i don't remember the exatcly file size but lets say mine is 1.29Mb but sometimes if i add a big image it will freeze the system settings upon click (even using valid gim settings) but the Rebug one is 1.49MB so i don't know what happens here.

Rebug uses the sysconf_plugin.sprx/rco from DEX ...is needed for several things (one of them is because it includes all the debug options from XMB settings column)
I dont remember if the sysconf_plugin.sprx from DEX is very different than CEX, but the restriction probably is in the sysconf_plugin.sprx

In other words... it seems rebug allows to use a bigger sysconf_plugin.rco because the sysconf_plugin.sprx is DEX

If that is true (im not sure) it means the restrictions are inside the .sprx associated with the .rco

 

[LuanTeles]

Try using this tool for the bdp_plugin.rco.

Decompile and recompile and then check if it works.

https://www.psx-place.com/threads/research-rcomage-psdevwiki-mod.17958/

same problem

 

[LuanTeles]

Yes, the only format not affected by it is rgba8888

As example... if you do a PNG ---to---> DXT5 ---to---> PNG ---to---> DXT5 ---to---> PNG

Everytime is converted to DXT5 is used an algorithm to "resample" the color of all the pixels... and this always generates different pixels (is imposible to have a result exactly like the original)

Initially it should not be a problem, becaue that algorithms are intended to "soften" the image and should not be much notable, the first conversion should be the most notable visually and the others not so much

But the fact is everytime is converted you are a bit far away than the original pixel colors... is like degrading the color info :/


Rebug uses the sysconf_plugin.sprx/rco from DEX ...is needed for several things (one of them is because it includes all the debug options from XMB settings column)
I dont remember if the sysconf_plugin.sprx from DEX is very different than CEX, but the restriction probably is in the sysconf_plugin.sprx

In other words... it seems rebug allows to use a bigger sysconf_plugin.rco because the sysconf_plugin.sprx is DEX

If that is true (im not sure) it means the restrictions are inside the .sprx associated with the .rco

Yeap, but the fact is i'm using the rebug one, so even mine beeing smaller i don't really knows why, because the 1.49 rebug one drops to 1.29Mb after compiling and recopiling so i think there is a text limit ( characteres) too