[DEV][M10] Decompiling M10 (Sense) images

The problem

Since HTC introduced Sense 3.5, themers faced a huge problem. The previously used software "M10Tools" wouldn't work with the new version of Sense.
Flemmard and me tried countless hours decoding the new image format, but without any success. The new image format is totally diferent to anything else previously seen.
I made this thread to search for help from all the awesome devs on XDA, hoping that we might find one who can help.



The history

Let me start this with some introduction to the m10 format itself.
The images I am talking about are parts of one big file - the m10 file. We usually have multiple images per m10 file, but the number doesn't really matter.
Together with the raw image data we get a set of meta information. We are not exactly sure what the values mean, but we can guess the meaning from the history of the old, decodable images.
We used to have information like width, height, payload of the image and an integer indicating what kind of image type we have. We know the actual image type for a few of these intergers, but with Sense 3.5, 3.6 and 4.0 HTC added at least two new types.



The facts

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

I will provide a download which contains several chunks of image data and the according meta data.
If you consider working on this, please do not refrain from thinking about super simple solutions, we worked so long on this that we might be totally confused.

One thing though, this might sound arrogant, but this here really is only for people who have some decent knowledge about file formats, image compression or OpenGL.



The image types

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.



The meta data

Okay, so now lets talk about the meta data we get together with the actual data:
We get 4 more or less known chunks of information per image (plus a few unknown things)

• Image type (described earlier) (Example: 6)
• Image width (Example: 98)
• Image height (Example: 78)
• A more complex value containing multiple values at once.
  Example: "98:78:0:30576"
  We used to know the meaning of three of these values. However we are not sure for the new images. Lets explain the old meaning first:
  98: Width, same value as the value above
  78: Height, same value as the value above
  0: It's always 0, we have no idea what it means, but since it's static we didn't care
  30576: this used to be the data size. This image has a resolution of 98*78 = 7644 pixels. With a data size of 30576 that means we got 4bytes per pixel.

Lets take a look at the new images now. We still get the same information, however the meaning seems to have changed a bit:

• Image type (described earlier) (Example: 14)
• Image width (Example: 997)
• Image height (Example: 235)
• A more complex value containing multiple values at once.
  Example: "1000:236:0:118000"
  This is the assumed new meaning
  1000: Width, but rounded up to a multiple of 4
  236: Height, but rounded up to a multiple of 4
  0: It's always 0, we have no idea what it means, but since it's static we didn't care
  118000: this value is now exactly half of the rounded resolution (1000 * 236 / 2 = 118000)
  This would mean only half a byte per pixel. One big problem here: the actual data size does not match this value at all!
  The data is way smaller than this value, which indicates that it got compressed a second time

Now lets talk about some very important piece of information: HTC uses the SAME image formats on BOTH a Tegra 3 and a Qualcomm Snapdragon S4.
This obviously means that both Tegra and Snapdragon need to be able to handle this. However, also keep in mind that HTC bought S3 graphics and thefore might got some advantages here.
You can find a statistic on the used formats in the download, it's an Excel sheet with two diagrams showing the usage.

Now this was a long post, I hope someone is still reading this and might have some ideas about what's going on here.
Feel free to ask any questions concerning this.

I am also available in #virtuousrom on Freenode, per PM here or via email: diamondback [at] virtuousrom [dot] com


Download:

The download contains a bunch of unknown images of types 13 and 14 together with their meta data (like explained above)
Download image pack

onlyolli said:

After some digging I estimated that the data is compressed with fastlz [0]. Also so if you decompress it, you get exactly Width*Height bytes of data. I dont know the format this data is in, but i guess its the same the uncompressed data (type 8 or 9 or so?) was. Maybe someone could check up on that.

[0] http://fastlz.org/

Click to expand...

Click to collapse

You are indeed right. We actually found the same a few hours ago What a weird conincidence... :victory:
Type 4 and 6 are changed, they are zipped now too. Which actually breaks backwards compatibility with older Sense versions...
Inside of the zipped data are ETC images, which also explains how they can use the same on S4 and Tegra 3.
The type 14 actually contains TWO images, both ETC. Since ETC doesn't support alpha one is the image and one is an alpha mask...
Funny trick HTC!