yashsingh1/xdaforums huggingface dataset:
[Windows Mobile Software Development] Chainfire:
Well I'd still be using rescaled images if I were you :)
[Windows Mobile Software Development] pcarvalho:
actually you wouldn't :)

one of the first thing i tested was how manila works with images...

i rescaled them to QVGA using existing tools and put them in while it was still in VGA mod...they were all VGA in size so...scalable...you can even QQVGA them and in some you wont even notice the diference...but file size is so insignificante that i dont even bother :)

i'm all for optimization ;)

keep up the good work
[Windows Mobile Software Development] Chainfire:
You're missing the point I think. Yes, you are perfectly able to use QVGA resolution images on VGA devices and vice versa, but on QVGA using QVGA images is much faster. Using them compressed is again faster.
[Windows Mobile Software Development] pcarvalho:
i know it is :)
[Windows Mobile Software Development] eidolen:
Hi Chain,

I hope it's ok to post here as it seems relevant to the topic for the most part. I did some more reading and think I understand the texturing concept now. Thanks for the push in the right direction. I read up on DDS as there seems to be little to no information on the proprietary formats our devices use but it sounds like the same thing for the most part.

The flexibility to scale and compress low detail graphics to help enhance speed adds a whole new level to consider when making a theme. I did find that the loss of detail on some of the larger images was a bit too much coming from a theme makers perspective. I was still surprised on how well the images turned out considering how much smaller the file was. Some of the loss might be due to my source material though. I used the stock HTC Black theme as my base.

Anyway, I was still unable to get the CFC tool to process 3f00cd2f_manila.

stdout: 3f00cd2f_manila :: wrong format

The strange part is that if you use any image smaller than the stock 512x256 and run it through the Comnpressonator and back to manila with CFC then it works just fine. I wonder is there is some special flag in the header that CFC doesn't like.

There is definitely something going on with the file size as well as you mentioned. A 256x128 image works just fine. Even a 256x256 image works if you scale the image properly so that the device reverses the squeeze, but a full 512x256 image produces a blank white rectangle. I don't think it's a big deal anyway as there is no need for a huge file like that just for a graphic you see for less than a second.

The question I had for you was if there was a way to have more control over the compression process to try and find a happy medium between speed and detail. For example, would it be advantageous to scale an image by half but not use any png compression? Would there be any benefit to working with DDS files directly? I use The Gimp and have downloaded the DDS and normalmap plugins but not sure if there is a way to take advantage of them. I'm definitely interested in taking advantage of the ability to enhance the performance, but don't want to sacrifice the quality of certain elements.

Many Thanks,

Eidolen
[Windows Mobile Software Development] Chainfire:
Where did you get "DDS" from? I'm not familiar with the term and have no idea how it relates to TF3D.

Well you should note the difference between two things (I think you may be mis-using one of them):

Scaling by half

You should really only do this when you are making a QVGA theme. While of course it saves size for a VGA theme as well, you will lose quality. However, when using QVGA you won't be able to see the difference as the resolution is also half. I wouldn't advise the scaling for VGA - that would kind of defeat the 'pixelperfect' part of the thread, wouldn't it :D

CFC compression

The extra compression CFC can add is completely

lossless

, it reduces the size of many images up to 4 times. However, currently only the QVGA TF3D is able to handle CFC compressed images. The VGA and WVGA TF3D's cannot read these files.

Yeah yeah, I still need to make a fix for those TF3D's to be able to handle CFC compressed files ;)

Hmm I checked it out in the HTC-CA SVN and I do have a 3f00cd2f_manila file marked as 'patched-images-cf', which would imply I modified this file by hand :D Please attach your 3f00cd2f_manila file to your reply so I can look at it.

Well you have to take count the original resolution of the file your editing (don't know if you did). You can make the resolution lower, but not higher than the original.... it might work in some cases, but in general it won't.

It is advantageous to speed to scale an image by half, however, PNG is not relevant to this process. We only use the PNG's so you can easily edit the images in your favourite editor. When you have converted things back to QTC files, PNG is completely out of the picture. Furthermore, PNG compression is completely lossless, it only reduces file size, not the actual image.

All in all I think I'm not quite grasping some of the things you ask...
[Windows Mobile Software Development] D-MAN666:
2 eidolen

a) manila compression (QTC) is fixed, lossy and you can't set quality

b) PNG is a lossless format, but it's related only to source material

c) big images - the QTC header is still a mistery, and there's a strange dependancy: headers from bigger images work for smaller images, i.e. we can find more or less "universal" header from biggest file available, but we can't produce images bigger than it.
[Windows Mobile Software Development] Chainfire:
Did you read some of my comments on the first page about those headers? Manila itself does something with them, but I'm not quite sure what. The information in the headers is NOT sent to the graphics card (I've checked this - only the 'payload' is sent).

Strangely enough some modifications to the headers

do

make a difference in decoding for The Compressonator. Perhaps some may point to some form of preprocessing that should be done on the

raw

data, but again that does not make sense since Manila Editor can decode them without that data (and so could my own rip-off), even if only 99% perfect. It's a mystery to me so far.

One thing about the bigger images. According to my dissembling and fooling around, Manila uses the width and height values from the headers and images internally, this is why you cannot change them without eventually causing issues. This is also why CFC compression keeps the original width and height of the images and hides the actual width and height in the payload data instead. EDIT: Also note that Manila will not read a bigger amount of data from the file than the width and height imply the payload data should be, (edit#2) but it does work if you have smaller file, without complaining.

EDIT: Note that I'm not sure if you could change the width and height in the headers if you also change the coordinates in Manila using the (encoded) XML and values/coordinate files.
[Windows Mobile Software Development] D-MAN666:
Yes, yes, i didn't argue that headers is NOT sent to the 3d chip, but w/o knowing how headers work, we can't make manila use files with custom resolution. :)

Nah, width and height are taken from the header and payload does NOT contain them - it's just an array of chunks.
[Windows Mobile Software Development] Chainfire:
Thats not what I meant... what I meant is that the headers data doesn't make much sense to have influence.. It doesn't

seem

to be referenced anywhere, yet it is. All out weirdness :) Guess I'll have to poke IDA some more to figure those out.

I was talking about CFC compression there, not QTC, and the

reason

CFC hides them in the payload and doesn't change the header...
[Windows Mobile Software Development] D-MAN666:
Ah, yes, right then. Maybe it has something to do with memory allocation? I.e. maybe that's why headers from bigger images fit smaller ones?

Sorry, i was a bit mixed up. Got it now :)
[Windows Mobile Software Development] Chainfire:
Hmm that's something I hadn't thought of before. Could well be, worth checking out!
[Windows Mobile Software Development] D-MAN666:
Got a small idea. Can you write a small app that will go through directory and dump size / header in some file like

[width] [height] [header]

128 256 00 ff 18 56 xx xx ...

2 10 00 f5 1d xx xx xx ...

I can look at that data, i'm kinda good in finding dependencies, you know :)
[Windows Mobile Software Development] Chainfire:
I could do that I think yeah... dunno if I'll do it right now, though.

I was just checking some headers values by hand though... checked 5 of them so far... and you know what, memory allocation fits!

"Unknown2" in the QTC headers (see first page) fits with width * height, if you take width and height to be the required multiple of 4.
[Windows Mobile Software Development] D-MAN666:
They are, indeed, coz chunk size 4x4. :) Nice start!
[Windows Mobile Software Development] Chainfire:
Obviously :D I'm writing a small tool now to verify that finding. brb (damnit, and I was just modding my Touch Pro manila to use CFC... gotta wait I guess :D)
[Windows Mobile Software Development] Chainfire:
Updated posts from first page:
[Windows Mobile Software Development] D-MAN666:
All you will improve this way is some disk space economy, but in terms of performace it will be a hitdown, coz textures will have to be upscaled via (bicubic, i believe) interpolation instead of pix-to-pix output. Other than that, manila-enabled devices have *very* powerful 3d chip, so you should never bother about texture size (in terms of performance).
[Windows Mobile Software Development] D-MAN666:
Oh gosh, they're just non-transparent, so payload is halved (no transparency info)! I thought you know that already :D

Nope, width/height in header are correct. (just to clarify)
[Windows Mobile Software Development] Chainfire:
Doh, yes, obviously :D

Dunno where my head is at, but if you say it like that, I feel like a fool for not just 'getting' that. I've mostly been busy just getting the files to work with "The Compressonator" and such, and not too busy with the actual payload format. I did work on that for a bit, but my own decoder (based on yours) had the same flaw that some pixels didn't always decode perfect so I gave up the actual payload format. Either way: DOH, and thanks for the heads up.

I'll get busy on the header displayer now, perhaps you can dream up what Unknown1 and Unknown3 from the header do :)

EDIT: It's even worse when you realise I did notice ATC_RGB is 4 bpp ... ugh!
[Windows Mobile Software Development] D-MAN666:
Sure, i will check them. BTW, you can just post an output, i don't need the app.

Also, do that Unknown1 and Unknown3 matter for manila?
[Windows Mobile Software Development] Chainfire:
Well I updated the 2nd post. If you don't mind, read through it again to see if I missed something obvious.

I'm not sure if Unknown1 and 3 matter to Manila. I'm sure I've played with it a few months ago but to be honest I don't remember. I'll post the output as soon as it's done (20 mins or so, I guess).
[Windows Mobile Software Development] eidolen:
Damn you guys are fast. I started my reply and then had to go fix my nephew's computer. After posting then reading all the replies, (60% over my head) I realized my file didn't get uploaded.

Trying again,

Eidolen
[Windows Mobile Software Development] Chainfire:
Well that does explain a lot. I think your command is good, it's prolly just a 0x15 file in your case, and I have no idea how to convert that one to ATC (yet... perhaps I shall look at that now I'm mucking with this again anyways)
[Windows Mobile Software Development] Chainfire:
Yap, that file is an ATC_RGB file. I know I patched a few of them by hand when I made the QVGA port... don't remember exactly how, though. I'll look into it.
[Windows Mobile Software Development] D-MAN666:
Solution 1. Doesn't ATC support ATC_RGB encoding?

Solution 2. Convert em into ATC_RGB_EXPLICIT_ALPHA by modifying header + each chunk (write 0xff ff ff ff ff ff ff ff at the start of each chunk, i.e. alpha = 1 everywhere)
[Windows Mobile Software Development] eidolen:
Well at least I can feel I haven't lost all of my sanity. *Yet* Thanks for looking into it. As I said before, it's really not a huge deal being one file out of a few hundred, but it did annoy me enough to tinker with it.
[Windows Mobile Software Development] Chainfire:
I just wanted to point out about this that textures > 128x128 DO slow down the graphics chip abnormally much (non-linear). Keeping all textures 128x128 or smaller does improve performance :)

Solution 2 is possible but first I'll try Solution 1 (which was what I was going for) as the file format should support ATC_RGB... just gotta take 30 mins and figure out what the ATC header then looks like :P
[Windows Mobile Software Development] D-MAN666:
O RLY? Didn't know that, thanks. Will check :)

btw, just compared 2 CTES files:

shift RGB RGBA

0x0C 01 02

0x1C 92 93 (may be a part of DWORD)
[Windows Mobile Software Development] Chainfire:
Your data... one with hex values, other with dec values in byte, word and dword. Please open with a fixed-size font, obviously :)
[Windows Mobile Software Development] D-MAN666:
Whoa... that will take some time. :)
[Windows Mobile Software Development] eidolen:
Well I wish there was something I could do to help but I'll leave it to the experts. I did make a little pic of in sizes vs out for anyone that happens across this thread. Results are the same with both Manila Editor and CFC.

Eidolen

Edit: I took down the pic and will put it in my post on the subject for laymen like mysef. Anyone reading the development thread would probably patch the payload anyway instead of my work-around and I don't want to cause any confusion. Sorry if I did.

E
[Windows Mobile Software Development] D-MAN666:
Have you tried to patch PayloadSize for 512x256 pic as per our today's finding?
[Windows Mobile Software Development] Chainfire:
And now there's CFC for (W)VGA as well!
[Windows Mobile Software Development] D-MAN666:
Hmm, looks like these values are kinda timestamp or signature or smth else content-unrelated - smth that manila should not care for coz they do not depend on dimensions or payload size. Moreover, files w/ diff dimensions and/or payload can have the same Unknown1/Unknown3 values. Also, these values are not connected with each other.

Have you actually checked setting them to 0 or some or fixed values taken from any file?
[Windows Mobile Software Development] Chainfire:
Nope. I have tried modifying the values (though keep in mind this was about 3 months ago now) but probably screwed up Unknown2 in the process which was why I ran into strangeness.
[Windows Mobile Software Development] D-MAN666:
We should give it a try then ;)
[Windows Mobile Software Development] pcarvalho:
a master indeed :)
[Windows Mobile Software Development] Chainfire:
I just tested it.... took all original Manila files, blanked out Unknown1 and Unknown3 with 0's and restarted Manila. Works fine. Guess the payload variable was all we damaged in our playing around :)
[Windows Mobile Software Development] D-MAN666:
Yahoo! Congratulations, my friend! QTC format fell to our feet :D

All i can ask you now (yeah, again, i know :)) is using CTES.dll for all-in-one conversion ;)

PS I guess specifying header file(s) in CFC s/b unnecessary now :)
[Windows Mobile Software Development] eidolen:
outstanding work for a single night you two. grats!

I'm completely in awe.
[Windows Mobile Software Development] Chainfire:
EDIT: And congratulation to you, of course!

Yeah yeah using the DLL... TBH The Compressonator plugin API is only written with C++ folks in mind, and I detest C++. IIRC, it's not usable from any language that does not follow C++'s object structure (in other words, any other language than C++ ;)). So err, pardon my french, "**** that" as long as I'm not paid by anyone to do it! (and even then ...)

The headers and such, read the top of the first post (with a cheap stab at you and a PM we once shared :P). For conversion to different resolutions it's still handy to have donor headers I think, but I will actually test this when I have the time, and update the CFC tool (I'll also have to rewrite half of the first few posts, UGH!).

Hey, we try :) And thx!

-

EDIT: BTW I'm trying to upload the correct "The Compressonator" version as well, but XDA giving me a "service unavailable" every time. Will try again tomorrow.

EDIT#2: Freaking funny how long this has been a mystery and then we think about it and solve it ... well, a couple of times a couple of minutes work and checking :D
[Windows Mobile Software Development] D-MAN666:
Okay, okay. No problem. :)

I just thought that performance may benefit from correct payload size (just like 512 bytes padding).

Yeah, that's what they call "team work". It's a honor to work alongside such a pro like you. Seriously! :D

Hey, you got me a bit wrong... Every day I'm getting requests from wannabe coders asking for my sourcecode, but i had a bad experience with sharing my src (i will not name the project, but you know it) which ended with endless "hey, maybe you'll code this part, give me your src and will port it?" instead of taking the information i recovered and implementing it into code. So, when you wrote, how could i know you're not one of them? :) And still, note, i'm not giving you any src, just still sharing the information and we do good! I.e. unlike others ("consumers"), who wanna everything in ready-made state, you can think your head, write your own code, and i respect that, so you can always count on my help & support.

Re LUTs - you can share them, but they are not correct anyway :) And accurate custom RGB->QTC conversion is a mystery for now. For some (multicoloured) images Compressonator does the job way better.
[Windows Mobile Software Development] D-MAN666:
Yep, same here. I always post my findings, and helping ethusiasts, answering questions, but when i'm asked questions - not src in the first place.

Yeah, i got that. :)

I was putting diff values into the file, screenshotting, analyzing the result. Took me quite a long time to figure them all out. But i was "lit up" by Manila reversing, slept about 4hrs/day that time, spending all other time on reversing :)
[Windows Mobile Software Development] Chainfire:
Heh, brute-forcing it. Interesting. I had hoped you had a hunch about something, as the formula you created for it isn't intuitive, at least not to me.
[Windows Mobile Software Development] D-MAN666:
Ehhh, are you talking about LUTs (fixed tables) or mixdown formula (for getting actual color values)?
[Windows Mobile Software Development] Chainfire:
I just looked, I know I wrote a decoder tool based on your stuff but can't find it right now, but arent they related? As I remember the formula is something like k * LUTw + r * LUTx + g * LUTy + b * LUTz or something. So I guess, both :)

EDIT: Note this may be completely obvious, I'm just a coder who dabbles into graphics, I don't know much about *actual* graphics :)
[Windows Mobile Software Development] D-MAN666:
Ah, that one! :) Well, it was a result of brute-force/analysys, but i can't guarantee it's 100% correct, but in pair with LUTs it produce that decent resut. :)

So, basically, i was looking at testing results, and eventually i put it out of my head :) Plain math, actually - no gfx connection in general

Now i wonder how you found out that QTC payload is same as ATC :D
[Windows Mobile Software Development] 6Fg8:
I gave that a try during the last days, here are a few details:

I could talk to ctes.dll and some simple things (show version, helptext, fourcc params), but: each dll is required to callback and register with compressonator. So it would be necessary to write a host which provides the function required for that. I couldnt figure out how they actually do it, well i'm not the big OLE gal but i guess it could be done with some effort. The reason i stopped that for the moment is somewhat different.

There are some oddities with compressonator (or at least the ctes.dll), i tried to compress my favorite background pics, they showed up but i couldnt select CTES as compression format. Looks like there are some limitations what can be compressed and what is refused.
[Windows Mobile Software Development] Chainfire:
Then what exactly is k? Is that just a random letter you thought up somewhere :D

Well that was actually fairly easy. Me and 'shrike were already busy with the HTC-CA driver stuff when we walked in on djboo and his trying to get TF3D QVGA working. So we got cracking with an OpenGL layer proxy to fake VGA on QVGA as far as TF3D was concerned (simple coordinate math, /2, *2, keep track of some textures, reverse-fake input coordinates through some hooking, etc) when we noticed TF3D used a compressed format that was directly supported by the graphics card. The ID code of that format was looked up and somewhere something that popped up in that search (a C header on some russian site IIRC) referenced an obscure and pretty much unknown format used by ATI mobile chips

only

. As that implied it was a 'standard ATI' format ATI must have some tools for it, so we found the ATI texture tool ("The Compressonator"), and pretty much deducted it would be pretty much the same format and found out we were right. (After all, it wouldn't make sense for software to first manually compress some image, to then send it to the chip compressed, only for the chip to decompress and use it... why not just send an uncompressed image in that case?). At that point we compared some data from TF3D files and found out only the headers and padding differ.

All in all, it just comes down to some API hijacking/DLL proxying/value logging, finding something strange, Googling a bit, and comparing output data. No great insights, just plain looking around for info that might be relevant.
[Windows Mobile Software Development] Chainfire:
New testing...

Just a heads up I'm mucking with updating the CFC tool to 0.3 right now.

To-do CFC:

- Adjust internal structures to reflect new discoveries done

- Fix CFC compression to skip the padding done

- Fix CFC compression to adjust payload header done

- Allow conversion of RGB QTC <-> ATC done

- Make donor headers optional done

- Allow larger than original images *

- Add CFC compression for RGBA images (PNG source instead of QTC source) *

To-do libgles:

- Allow for CFC RGBA images *

* All those marked with a * together will allow me to make TF3D for non MSM devices. However, I don't think we have a fast software OpenGL driver yet as we do D3D...
[Windows Mobile Software Development] D-MAN666:
It's QTC2RGB formulla and QTC master color consists of 4 x 4 byte components: K, R, G, B (names are mostly unrelevant, if you check actal LUTs, but who cares :)).
[Windows Mobile Software Development] 6Fg8:
As i wasnt convinced that they really used LUTs, i tried a different approach with pure math. keycolor1 and keycolor2 have different number of colorbits and thus are interpreted different:

keycolor1 (address xxx8): xRRR RRGG GGGB BBBB <= 5 bits/color

keycolor2 (address xxxA): RRRR RGGG GGGB BBBB <= 5 bits for R,B, 6 bits for G

Basic treatment:

R1 = (keycolor1 and 0x7C00) >> 10

G1 = (keycolor1 and 0x03E0) >> 5

B1 = keycolor1 and 0x001F

R2 = (keycolor2 and 0xF800) >> 11

G2 = (keycolor2 and 0x07E0) >> 5

B2 = keycolor2 and 0x001F

Colors then amplified with their weights:

R1, G1, B1 *= 8

R2, B2 *= 8

G2 *= 4

after that, color mixup with the 2-bit mixvalue:

R = R2*mix/3 + R1*(3-mix) /3)

G = G2*mix/3 + G1*(3-mix) /3)

B = B2*mix/3 + B1*(3-mix) /3)
[Windows Mobile Software Development] Chainfire:
Cool, is the result any good?
[Windows Mobile Software Development] Chainfire:
CFC 0.3

CFC 0.3 released!
[Windows Mobile Software Development] D-MAN666:
wow, wow :)

i wonder about results, too
[Windows Mobile Software Development] 6Fg8:
yeah, looks pretty well.
[Windows Mobile Software Development] D-MAN666:
wow, nize :]
[Windows Mobile Software Development] Chainfire:
Guess what we need to do now is compare it with the PNG's the compressonator outputs... :)