Database Info

[THEME TOOL IDEA] Copy 9-patch from original files

While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....

erasmux said:
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
Click to expand...
Click to collapse
Huh. I've been wondering if this was possible. I haven't tried this yet but if it works, nicely done! I think that this would be a huge improvement and addition to the themeporter programs that are out there. There is a high demand for this in that area and in the area of HDPI>MDPI/MDPI>HDPI conversion. I'm certainly bookmarking this!

Awesome, just checked out ur source, so simple but effective
Anyway wanted to ask if ur ok with me incorporating it into theme-porter ? Link
Wht im thinking is perhaps when "Hdpi to mdpi" is on, it would resize the .9.pngs by 66%, after which it would transfer the .9 data using this program so (9-patch) code is preserved.
Let me know. Thnx
FYI : Just gave it a whirl, works perfectly.

Daneshm90 said:
Awesome, just checked out ur source, so simple but effective
Anyway wanted to ask if ur ok with me incorporating it into theme-porter ? Link
Wht im thinking is perhaps when "Hdpi to mdpi" is on, it would resize the .9.pngs by 66%, after which it would transfer the .9 data using this program so (9-patch) code is preserved.
Let me know. Thnx
FYI : Just gave it a whirl, works perfectly.
Click to expand...
Click to collapse
Maybe my original post wasn't blunt enough, my code is just "proof of concept" because I am bit lazy in this department (themeing tools) - I'd rather spend my time compiling kernels (go figure ).
So my main goal for this post is for developers of apk managing tools and etc. to pick up the ball and go forward with this
And to be even clearer:
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
(am also adding this to the main post)
Regarding your actual resizing idea, you might want to resize it with the 9-patch "codes" (in the 1-pixel border) because you want the codes from your original HDMI files just resized. This should work, just be careful with resizing algorithms which average pixels and such. If I understand correctly the edge pixels should be either white or black (defining stretchable and context areas). Need to play around with this until it works well.
Let me know if I can be of any further assistance.

erasmux said:
Maybe my original post wasn't blunt enough, my code is just "proof of concept" because I am bit lazy in this department (themeing tools) - I'd rather spend my time compiling kernels (go figure ).
So my main goal for this post is for developers of apk managing tools and etc. to pick up the ball and go forward with this
And to be even clearer:
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
(am also adding this to the main post)
Regarding your actual resizing idea, you might want to resize it with the 9-patch "codes" (in the 1-pixel border) because you want the codes from your original HDMI files just resized. This should work, just be careful with resizing algorithms which average pixels and such. If I understand correctly the edge pixels should be either white or black (defining stretchable and context areas). Need to play around with this until it works well.
Let me know if I can be of any further assistance.
Click to expand...
Click to collapse
Hmm k i'll spend more time with it, perhaps the resizing program im using causes mishaps. Currently when i resize it completely messes stuff up even though the resolution corresponds to a mdpi device.
I'll do the good ol' trial/error n let u know. Thanks for the (proof of concept)
Edit :
Ok so upon using ur code for transferring images of diff sizes u can obviously tell whts up
So one improvement im thinking off, is if the images differ in size, it could draw the border and eliminate anything outside it. Ugh gotta brush up on my java though :S

bump
10 del al char har

bump
I tested it out and it works great! Thanks!

I really hope someone takes this idea and runs with it! If I knew how to code, I would certainly look into this. Maybe I can get one of the Vibrant Devs to look at this....

erasmux said:
While working on a ROM (for the hero), I have recently tried to do some theming by small changes (i.e. color changes) to the drawables in the framework-res.apk.
It appears the both for me, and the fellow that is helping me (floomat), these 9-patch files are giving a headache. We prefer editing them in some normal app (i.e. photoshop) but this seems to mess up the 9-patch "code".
I have written a very small program to apply the changes to a 9-patch image without disturbing the 9-patch itself. Note that this program is mainly meant as a "proof of concept" and hopefully one of the apk managing tools will pick up the ball and integrate it. In the meantime it might be useful even as it is (with some scripting around it most likely). Or it might be just a way to prove I am fool and there is simpler way to get around this I am not familiar with
"Program" and source: http://www.sendspace.com/file/sw4atc
(its really too small and simple to be called a program)
Usage:
Code:
java copy9patch original.9.png changed.png
Will copy the changes made to the changed.png over to the original.9.png but keep the 9-patch data of the original.9.png.
Its code (also included) and the way it works is very simple: It takes the size of the original image (i.e. 19x27), without the 1 pixel border with the 9-patch codes - so in our example it will be 17x25. Now it just copied the center 17x25 pixels from the changed.png over the original's center pixels. It has some very basic boundary conditions if the image sizes do not match but this could probably be handled better, possibly just by issuing an error in these cases.
If you want to use my code, change it, do whatever you like with it please do so and I'll be glad to checkout your result!
NOTE: I feel a bit uncomfortable posting this in the "G1 development" section but I see both apktool and apk manager are here....
Click to expand...
Click to collapse
Can U just tell how to use this code for bulk images?????

pratyush.creed said:
Can U just tell how to use this code for bulk images?????
Click to expand...
Click to collapse
Hmm, haven't used this for a very long time and don't really remember whats going on here.
Still attached is the version which I have on my HD, and it does support bulk images if all the images are in a folder.
If I remember correctly (mostly going by the help that is displayed by running the program without argument):
Code:
fixResPngs drawable-mdpi drawable-mdpi.org
Will go over all drawable-mdpi/*.png files (possibly also sub dirs?! I really have no idea, sorry), and "fix" each such file. If I am not mistaken it needs a "reference" file only for 9 patch files which are identified by their ".9.png" suffix (regular pngs I think are just rewritten without any change which I found improves compatibility). In case of a 9 patch file, the original file with exactly the same name should be found under the directory given in the second argument. For example: If drawable-mdpi/aaa.9.png is processed the 9-patch data will be copied from drawable-mdpi.org/aaa.9.png.
Obviously it also still works on single files. It does *not* work on lists of files or lists of directories.
If anyone is interested in the code, I am sure I have it somewhere (I hope)....

erasmux said:
Hmm, haven't used this for a very long time and don't really remember whats going on here.
Still attached is the version which I have on my HD, and it does support bulk images if all the images are in a folder.
If I remember correctly (mostly going by the help that is displayed by running the program without argument):
Code:
fixResPngs drawable-mdpi drawable-mdpi.org
Will go over all drawable-mdpi/*.png files (possibly also sub dirs?! I really have no idea, sorry), and "fix" each such file. If I am not mistaken it needs a "reference" file only for 9 patch files which are identified by their ".9.png" suffix (regular pngs I think are just rewritten without any change which I found improves compatibility). In case of a 9 patch file, the original file with exactly the same name should be found under the directory given in the second argument. For example: If drawable-mdpi/aaa.9.png is processed the 9-patch data will be copied from drawable-mdpi.org/aaa.9.png.
Obviously it also still works on single files. It does *not* work on lists of files or lists of directories.
If anyone is interested in the code, I am sure I have it somewhere (I hope)....
Click to expand...
Click to collapse
Gr8 work...u made themin a kid's job
Sent from my GT-S5670 using XDA Premium App

???
does the original still work cause im on windows 7 64 bit and i was able to copy the changes to original but not it makes no changes at all, so the original file doesnt get the changes...
please help!!

Android - merge two MP4 files

Does anybody know about way to merge two MP4 video files directly in the phone? i've tried cat in Terminal emulator, it joined the files, but than the playbackl stops after the first file contained in the result, quite logically.
Anybody has some other way?
I know that mencoder can join two clips, but I can't find android binary for it.

Hello,
Have you found how it can be done?
Regards,
Ruslan

i thinkg you will remove head from 2nd-file before merge

Wouldn't it require the removal of the MP4 headers though?

I tryied it:
1. Create new file.mp4
2. Copy first.mp4 into file.mp4 (A read full bytes from file and write it)
3. Repeat point 2 fot second.mp4
Yes, it is stupid.. But this file will be played by Windows Media Player(I tested it).
So, How can I undestand what kind of bytes is header of second.mp4?
Does mp4 contains special separator?

I am afraid, that it simply stops playing the final product at "the right time", marked by header in the beginning of the file (=first clip). I think that to merge them without reencoding, we would have to "clip" the second header & redo the first one, to match the total length.

May be do you know some Android plugins(I mean .jar files e.g. ) witch can merge mp4 files or 3gp..?

I know, that mencoder can join two MP4 files quite easily. But I can't find any version working on Android.

If anyone found out a solution please share it here

no, nobody did I believe. To merge two MP4s you need to modify at least the header, probably even more. What we need is ffmpeg, which can be run in the terminal.

[Q] Animated GIF Support Within libwebcore.so

Hey everyone,
I've done a lot of reading lately on how can animated gif support be enabled for devices with ARM6 (like the HTC Hero). Basically what i have to do is recompile the package \lib\libwebcore.so and re-flash in on my device.
What i have in mind: within the "ImageSourceAndroid.cpp" file from "WebCore / platform / graphics / android" i have to force the should_use_animated_gif() call to return "true" everytime it is called.
*btw, you can find the above *.cpp file here
**btw, i believe someone has done this before, see here
Now, the part with changing the code is easy stuff.. however, i'm not quite sure that i'll be able to recompile the library so easily. So my questions are:
1. Can anyone point me in the right direction? How do i rebuild this library into something that i can flash on my device?
2. Can anyone tell me if what i want to do will indeed enable the gif support
Thanks!

Also, related to the above, is there any way that i can deploy *just* the libwebcore.so library?

cool beans! good work!

here's what google dev says:
[...] you want to work around this with your own Android build, you’ll need to modify C++ code, rebuild, and reflash your phone. You’ll need to make two fixes to the released sources. 1) edit the function should_use_animated_gif() in external/webkit/WebCore/platform/graphics/android/ImageSourceAndroid.cpp (around line 217). Return true to animate gifs 2) Change setRGBA() in /WebCore/platform/image-decoders/ImageDecoder.h (around line 173) to call*dest = SkPackARGB32(a, r, g, b) *dest = SkPackARGB32(a, r, g, b) instead of instead of*dest = (a << 24 | r << 16 | g << 8 | b) With these changes, gifs will animated correctly on large memory devices like Droid and Nexus One There’s no code path for animating gifs in arbitrary applications like Gallery, except by rewriting it to host a WebView modded as described above[...]
the post above has been taken from here
I'll just post more info on this topic as i go along with it. If someone has additional hints or something, please feel free to comment.

[Q] Desktop simple viewer

In order to develop an app remote desktop WP7, I started to with a desktop simple viewer and it works
but the problem that not show all actions that I do in Server side, that's video in YouTube can show you my problem
"watch?v=3q-FumfYsPQ&feature=youtu.be" (add it after /)
I use socket connection and I decode and encode my data (images).
this my code in WP7 client side
void Conncet(string IP_Address) {
client_socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
SocketAsyncEventArgs socketEventArg = new SocketAsyncEventArgs()
{
RemoteEndPoint = new IPEndPoint(IPAddress.Parse(IP_Address), 4532)
};
socketEventArg.Completed += OnConncetCompleted;
client_socket.ConnectAsync(socketEventArg);
}
void StartReceiving()
{
byte[] response = new byte[131072];
SocketAsyncEventArgs socketEventArg = new SocketAsyncEventArgs();
socketEventArg.Completed += OnReceiveCompleted;
socketEventArg.SetBuffer(response, 0, response.Length);
client_socket.ReceiveAsync(socketEventArg);
}
private void ViewReceivedImage(byte[] buffer)
{ try { MemoryStream ms = new MemoryStream(buffer);
BitmapImage bi = new BitmapImage();
bi.SetSource(ms); MyImage.Source = bi;
ms.Close();
}
catch (Exception) { }
finally { StartReceiving();
} }
this my code in Server side (PC) sending images
void StartSending() { while (!stop)
try
{
Image oldimage = scr.Get_Resized_Image(wToCompare, hToCompare, scr.GetDesktopBitmapBytes());
//Thread.Sleep(1);
Image newimage = scr.Get_Resized_Image(wToCompare, hToCompare, scr.GetDesktopBitmapBytes());
byte[] buffer = scr.GetDesktop_ResizedBytes(wToSend, hToSend);
float difference = scr.difference(newimage, oldimage);
if (difference >= 1)
{
SenderSocket.Send(buffer);
}
}
catch (Exception) { }
}
My question is how can I make the send and receive fast to show the PC screen in WP7 in +/- real time.

The short answer is, you can't. Even if you compress the screen images first, which I note you're not doing, the amount of data is just too great. An uncompressed 800x480x32-bit image (such as WP7's screen can display) is 1.5MB. That's each frame. You can halve that by using 16-bit color, of course; now it's .75MB per frame. If you want even 20 frames per second - which is slower than TV or almost any video camera, but is moderately smooth for most things - that's 15 MB/sec, which is 120Mbps (about twice the speed of most WiFi, faster even than most wired networks).
With some simple image compression combined with clever data differencing (sending only the parts of the image that change), you could probably reduce that data load by at least a factor of 10. That's still too high for most Internet connections (even if your phone can download 12 Mbps, your PC probably can't upload it) but it might be usable over WiFi (802.11n probably, 802.11a or g maybe). You'd have to make your code quite a bit more complicated, of course. Additionally, the phone's processor would have to work a lot harder, since it would be decompressing the data and applying it to the changed part of the frame, instead of just dumping netowrk packets into an image buffer.
The real solution, of course, is to use one of the several programs and protocols that already exist and have the intended purpose of doing exactly what you're trying to do. The most common on Windows is called Terminal Services or Remote Desktop (Remote Desktop Protocol). Nearly all versions of Windows come with the client, and the better editions come with the server. On WP7, there are already some client apps available; the one I use is called "RemoteDesktop" (no space). Note that, in addition to having a well-optimized algorithm for screen updates (but it's *still* not going to be smooth for things like movies or games), Remote Desktop Protocol lets you control the PC directly as well.

Thanks
I look that's apps in marketplace and it looks very difficult to me, but I develop simple viewer and next time I will develop the code that can remote the PC.
the idea about send only that pixels that changed between the old image and the new image is really good, but how I ca send only that pixel and they're position in the image, that's a question.
And about compression, how I can do that with images?

Well, just compressing the full screen to .PNG or .JPG and sending it would shrink things considerably. There are .NET libraries available (there might even be one in the core library) for image compression. Alternatively, there are some excellent C/C++ libraries available, if you can code native interop. I know the phone has built-in capability to handle JPG, not sure about PNG though.
However, once the data is compressed it's hard to extract a part of it and send just that part. What I suggest you do instead is identify the portion of the image that changed. For example, if all the changed pixels fall within one rectangle, use that. Send the coordinates of the rectangle (its origin and either the opposite corner or the length/width), followed by the updated data. On the phone, listen for the rectangle to update, then write the updated data into those coordinates on the display.
Note that you may want to send multiple rectangles - for example, if the top left nd bottom right pixels change, but nothing else does, a single rectangle that encompasses both of them would have to be the entire image. Instead, send two tiny rectangles - one for each corner - and you can massively reduce the data needed. However, the process of quickly detecting a good way to break up an image into the parts that are and are not moving is tricky. You're essentially trying to create a video compression algorithm here, and although I know a little of the theory, it's totally not my area and I don't know much more than what I've told you so far.

Thanks again
I found something similare to know the pixel that chaged
Image Comparison using C#
http://www.c-sharpcorner.com/uploadfile/prathore/image-comparison-using-C-Sharp/
I will try to study it and get information how to set the coordinates, but the problem that stay is how I send it to the right position in image in client side

juste_3al_faza said:
I look that's apps in marketplace and it looks very difficult to me
Click to expand...
Click to collapse
I don't understand that. What is "difficult"? Enable RDP access on desktop? Or add your desktop ip address to the WP7 app? Take a look to the RemoteDesktop app by Topperware: it's fast, professionally designed and easy to use but of course not a free (however $4.99 is not much!)
As for me, it looks like you are trying to "invent a bicycle" but without basic knowledge how the remote access protocols should work. It's not that easy like just a transfer bitmap images via sockets...

I mind I don't need to use it, I want to develop a simple apps because its my project and I will get a note and pass my last year in school

juste_3al_faza said:
I mind I don't need to use it, I want to develop a simple apps because its my project and I will get a note and pass my last year in school
Click to expand...
Click to collapse
Now I understand OK, I can recommend you to dig in MJPEG. There are few Silverlight classes available on the web (you may google em); they may simplify your job. The picture quality isn't good or sharp enough but should be good for the student project.

you talk about compression images to mpeg????????????
have you an idea when I zoom In image in WP7, most image be clear to see, how I can do it?
Edit (After see the article about MJPEG silverlight)
It use the HTTP connexion and I use socket, It can work together?
If yes how I can combine with it (plz a sample code can help )

No, I'm talking about M(otion)JPEG over HTTP, easiest possible video streaming implementation. For the solution, you need to implement your own M-JPEG HTTP server application, and on WP7 you may use (it's already exists, google for MJPEG MediaStreamSource) MediaElement. And I don't understand your second question.

I already edit my previous post
and about the 2nd question, I mean when to pinch in WP7 screen, is the image will be clear or not.

I don't have time to write an example for you; however it's your project or homework , I just give you a direction.
As for seconds question (as far as I understand): it's depends from the image dimensions and JPEG compression level. If you resize 1920x1080 image to 800x480 with 50% quality, resulting image will looks not so good.
P.S. Check this project: http://mjpeg.codeplex.com/ To estimate output quality on Wp7, you may use any MJPEG desktop streaming solution (vlc, for example).

Thanks a lot
I finished my app and it work good, see the video
http://www.youtube.com/watch?v=cCwsuj7Hcno

Cool. Looks like you get about a frame per second, which won't work for showing a video but is fine for a Powerpoint or something, and a decent proof of concept.
I'm not sure I'd recommend demoing using a video showing a commercial movie with a clearly visible "Uploaded by..." comment, at least in the USA schools tend to frown on open displays of media piracy. Otherwise, well done.

Ok next time I will use PowerPoint to use my app show

[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

Solution
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/

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!