[Windows Mobile Software Development] Chainfire:
Absolutely. I doubt it's noticable, though, performance wise. We're not even 100% sure right now how the payload size is being used, only that it is. It'll require more testing to find that out. The padding, however, makes sure a file takes up exactly x storage cells, where x is a whole number. While with modern flash storage this shouldn't really make a difference, it seems that it does make a difference with the cooking process itself. Not completely sure why, but I have some theories, half of which are undoubtedly not correct.

Besides, it's the memory allocation itself that takes the performance hit. As long as you are not really low on memory, 2x too large doesn't really make that big a difference (and even if low on memory, it would hardly be noticable).

EDIT: I might have missed a point of you there. For downscaling to QVGA the header info of width/height may be interesting to preserve thus still being handy to have donor headers available... The rest, well, whatever about those, as we can pretty safely judge now :P It may be necessary in some cases due to the 'faked' scaling the QVGA port does and internal coordinates of Manila to know the originally intended width and height of an image. Having donor headers available allows you to batch process a directory of items easily without having to consort to formulas and what not which may or may not be correct for what you are doing. Ok this is worded really weird (its 7 am, leave me alone!), but perhaps you'll understand what I mean.

Team work ftw, and thanks! Wouldn't have figured out my part without your findings, for sure though!

Well sharing source makes you learn. In some cases it's good, in other cases bad. Don't let one experience 'ruin' you, so to speak. Either you made a bad call once, or somebody took advantage of your good nature - is that worth giving up your good nature for? Screw them :) I'm not one who shares source code much, but I do often publish details about what I've done, how I did it, and answer detailed questions about it.

The stab in the first post was more meant as a good-natured joke, btw. (yeah yeah my sense of humor sucks, news at 11). The LUT's themselves mean **** to me, what really interests me is how you got them in the first place. They are not perfect (which is pretty much why I did what I did and which ultimately led to this thread), but as long as you don't share how you got them and nobody else figures it out, how are we (or any reader, enthousiast, etc) going to improve them or figure out the magic? It's not like you got anything to lose by sharing how you thought those LUTs up, there's no money to be made here! (these algorithms are patented in either case, according to my "research", though I have not been able to dig up the actual patent, and the luscious details that might have come with that).

I know in my original PM to you I asked for your source, this was purely so it would be as little effort as possible to you. If I recall correctly you mentioned somewhere you used some language X (dont remember which) which would actually take me quite some work to rewrite into what I use myself. I didn't want to bother you with the details of the implementation as that would require more work from your part than just sending me a file you had sitting on your drive somewhere, and I was sure I could figure it out with your en/decoding source. It would've been less work than decoding your app to find them, but not by a large margin, I think.

So don't take it like I resent you never sent me the code :)

As for it being a mystery, you can't deny that your LUTs work remarkably well... They are not perfect no, but they give 'pretty good' results, which lead me to believe what you did is essentially right, just missing something.