No need to convert GIM2GIM.
What i explained about the dxt format being lossy is not an invention, wikipedia mentions it very explicitelly
https://en.wikipedia.org/wiki/S3_Texture_Compression
wikipedia said:
S3 Texture Compression (S3TC) (sometimes also called DXTn, DXTC, or BCn) is a group of related lossy texture compression algorithms
Gimconv.exe (used by rcomage) is performing that algorithm that recalculates the pixel data, but the resulting pixel data depends of the original pixel data. If the original pixel data is very simple (lets say, a little white arrow with a palete of only 5 colors) then it could happen that the pixel data is not modifyed in the GIM --> PNG ---> GIM conversion process with dxt settings
For an example everyone can try... take any image in good quality you have at hand (something with good definition or many colors, like a rainbow) and use gimconv.exe directly to convert it several times using dxt settings PNG ---> GIM ---> PNG ---> GIM ---> PNG ---> GIM ---> PNG ---> etc... (you can make a .bat to automate it) and then open the PNG images in a viewer and do a huge zoom in them to to compare how the pixels "degrades" in every dxt conversion (you are looking at the algorithm in action)
So... this presents 2 problems for your tool:
1) If you extract the dxt files as PNG and then you use them to convert them again to dxt in a later step the quality of that image decreases a bit, this doesnt matters if the user is going to replace it by a custom image... but think in it this way.. the original image in sony studios (in .tga) is the only with highest quality, but when they converted it to GIM using dxt format they degraded his quality a bit (first dxt conversion), if we extract it and convert again to GIM with the same settings (second dxt conversion) we are degrading it a bit again
2) It breaks the bruteforce procedures intended to identify the GIM settings... when i figured this procedures i hitted with 2 big problems... one was the footer i mentioned (fixed in your second version of the script), and the other was the lossy dxt conversions
Btw, the idea to solve this annoyances in the bruteforce process caused by the dxt lossy image formats by doing GIM---> GIM conversions directly (
to preserve the pixel data) was zinga burga (who made rcomage), is a trick he was using to identify GIM settings

That thread have a lot of info related to all this btw
http://endlessparadigm.com/forum/showthread.php?tid=19501&pid=437695#pid437695
ZiNgA BuRgA said:
Note that GIM «> PNG conversion can be lossy. If you're trying to guess settings, it's better to use GimConv to convert GIM to GIM with your settings (eg "gimconv in.gim -o out.gim [settings]")
sandungas said:
Nice trick, i didnt imagined it and i was using a GIM--»PNG--»GIM conversion that works pretty fine if the original GIM was made by using format --image_format rgba8888
From 245 images that are inside explore_plugin_full.rco from PS3 4.70 firmware, around 200 passed this test (exact MD5 hash after rebuilding GIM--»PNG--»GIM)
The others are the problematic ones and as yoou say it seems related with the DXT conversions that are lossy, it seems is not posible to create a DXT exactly like the original
But by making a GIM--»GIM conversion the DXT is not modifyed, this allows for a perfect match after rebuilding, nice method, better than what i was doing
Im not trying to be a party breaker, but it could happen that your scripts works fine in some specific GIM files but eventually you will find others where it cant find the GIM settings
Right now the better way to check it is by making another bat to run all actions in all the GIM files from inside all the RCO files from 4.89... thats a good stress test
*The rco comparisons (original VS rebuilt) are not handy, because rcomage generates areas of paddings with variable sizes (a bit random, not following the rules of the original), is mentioned somewhere in the other forum or the rcomage readme.txt