Themers working with HTC Sense ROMs currently face a major problem. They are unable to modify most images used by Sense 3.5 and beyond because of HTC’s method of storing images inside proprietary m10 files. Unfortunately, the images are not stored as JPG or PNG. Instead, they are encoded with an unknown algorithm.

Previously, M10Tools by XDA Recognized Developers Flemmard and Diamondback would be used to decode these images. However, with the release of Sense 3.5, this no longer was an option, as HTC added new image formats that are not compatible with the software package.

After trying unsuccessfully to decode the new image formats, Recognized Developer and Forum Moderator Diamondback has decided to seek help from other developers in the community to find a solution to the M10 image format woes. Luckily, there is progress being made to find a solution. For starters, Diamondback has compiled a list of what we know so far:

We don’t have any hard facts for these image types but looking at the “old” image types, we can guess a few things:

• The images are in a format the GPU can render directly (Like s3tc, ATC, QTC, etc) (At least this used to be the case, might have changed)
• Images are most likely compressed. The ratio between assumed size (based on meta data) and the actual data size indicates some heavy compression. The data itself obviously looks compressed too.
• There are no headers or any other help. It is just raw data.
• We don’t know exactly how the decoded images actually look like, so we can’t say what the images display. However, due to latest archievements we “might” know this for images from Sense 3.5 and 3.6 if needed.
• The handling software side is all in a few libs and NOT in smali / java, so we can’t look for stuff there, however we have the libs, so if someone is pro with assembler he might find out something

So which image types are the ones in question? As compiled by Diamondback:

Here is a list of image type we already know ( remember, we don’t know where the numbers come from, might be some enum in native code or so)

• Type 4: Raw RGB
• Type 6: Raw RGBA (still used rather often)
• Type 8: ATC RGB (doesn’t seem to be used at all anymore)
• Type 9: ATC RGBA Explicit (doesn’t seem to be used at all anymore)

As you can see we got types WITH and WITHOUT alpha encoding.
Here is the list of UNKNOWN formats:

• Type 13 (used way less than type 14, so maybe no alpha?)
• Type 14 (this is the most used type, so I assume this one supports alpha encoding)

When thinking about what the data might be, don’t throw away crazy ideas like “The data is S3TC /ATC /whatever but compressed again by some ‘normal’ compression algorithm”. Maybe they just replaced type 8 and 9 with an additional compression on top of these types.

Diamondback is searching for help from everyone who is experienced with file formats, image compression, OpenGL or reverse engineering. Since these efforts have been ongoing for several months, any input is appreciated.  Those who wish to join the project should head over to the development thread and lend a hand.