Shoutbox

if I reported that both files are the same I had to download the RAR first to extract them, and if the files are the same, then nothing is wrong with the RAR either

btw, yep, both animations work for me....

quote:

---

Originally posted by CookieRevised
if I reported that both files are the same I had to download the RAR first to extract them, and if the files are the same, then nothing is wrong with the RAR either

btw, yep, both animations work for me....

---

lol.. odd.. anyway, I managed to put a GIF in there and extract it again, I'm just having some huge problems in calculating the CRC to make the PNG valid.

Edit:
So I've finally done it, embedded a GIF in a PNG successfully; It's in there and it's safe and propper. I also have a way of extracting it again and writing it out as a gif file. The PNG stays completely valid. I'll update the development info in the first post now.

What I am saying, is that winrar might take out comments of PNG files to reduce filesize. This is why they are both the same image... I think.

quote:

---

Originally posted by rompom7
What I am saying, is that winrar might take out comments of PNG files to reduce filesize. This is why they are both the same image... I think.

---

WinRAR performs a lossless compression. The original files and the files after you uncompress them are exactly the same. Which is why ZIP and RAR etc, are such a good compression method, especially for things like these or binairies. Imagine it started tossing away data in there as well like JPEG and GIF and other image compression formats do, you wouldn't be able to start the program anymore after uncompression and it would crash your system....
By the way, they are both the exact same image, the diff didn't show any diffrences at all, but on my image viewer it didn't show correctly; but I solved that problem; it was something to do with another corrupted image in the same folder which made my viewer crash, not lhunath2.png.. so never mind that..

quote:

---

Originally posted by wtbw
We already know how to make DP's display at whatever size we want; there's already the code to do the splitting, already code to display a DP (ofc), and already the timing code inside msn. So it's just a matter of putting it all together.

---

Nice, if you can get me that code, I would not mind at all at giving it a go. I was just about to put this thing on hold for now until I thought of a way to send my PNG through. I've got some ideas on which I'm working, but if you can get me the code you speak of, then I'm sure I can do it alot faster.

Lhun (uber-prutser )

quote:

---

Originally posted by wtbw
And, lhunath the code is inside MSN.

---

Does the MSN Messenger API allow for setting the DP as something custom ? Or how do you plan to use that code to set the DP to a custom image ? By my knowledge it's not really possible to just call the seperate algorythms inside MSN Messenger for own personal use.. I suppose it could be done with some ASMing but that's a bit beyond my league.

quote:

---

Originally posted by TheBlasphemer
Now think a bit, what if someone had like 10 frames, which would be a picture of 960*96 on non-patched MSN's.

---

Users without the patch aren't supposed to see the other frames.. It should be done by adding the information in a seperate chunk to hide it properly, and the actual IDAT (The image shown to users without the plugin) should contain the first frame.
That way, users without the plugin will see the first frame and not notice any problems +
the plugin will use that frame to shape the size of the DP area, so that the only thing that need be done is overlay the DP area with the animating image data.

So, all we need to do is find a way to send my PNG through.
Let's line up the posibilities :

- Make a patch for msnmsgr.exe that makes it copy the PNG to the .bin files in it's display directory, instead of building a new PNG from the actual RAW image data in our original PNG.
- Find a way to add DP's to MSN Messenger ourselves, thus we would not need the MSN Messenger DP adder, and we can make sure the DP's have our animating chunk.
- Inject the PNG in the data stream, for example, using a Proxy to find and replace whenever MSN Messenger sends our DP data, then replace it with our PNG containing the animating chunk.
- Setting up a P2P system, like PowerPlus, to send the image through, the only problem would be, fetching the contact's IP. That should not be a problem though, I'm sure there's plenty of ways, as in, adding a char to the end of the nickname, then, your plugin sends users with that char an IP request, which the other user's plugin hides and replies to.
- Still pondering about other ways, let me know what you think of each of these and if you know any alternatives.

This might sound a bit stupid... but how large will encapsulating the gif inside a png be? There might be issues for people on dialup downloading massive display pictures... like I said might sound silly sorry...

quote:

---

Originally posted by illuzn
This might sound a bit stupid... but how large will encapsulating the gif inside a png be? There might be issues for people on dialup downloading massive display pictures... like I said might sound silly sorry...

---

if it isn't compressed it will be the same size as it normaly would be...
But anyways, the thing you mentioned is exactly one of the reasons why MS fixed the size to 96x96 and only used PNG (which has a compression method build-in) and static, non-animated pictures....

quote:

---

Originally posted by illuzn
This might sound a bit stupid... but how large will encapsulating the gif inside a png be? There might be issues for people on dialup downloading massive display pictures... like I said might sound silly sorry...

---

The size will be the same as the GIF's size plus, the first frame dublicate (as the PNG static image) and some extra bytes providing the PNG structure.

About that first frame.... I wouldn't duplicate it in the PNG. I would keep the PNG image as something seperate. In that way, a user can decide to put a (slithly or complete) different pic in the PNG for "normal" users. Otherwise you bound to some restrictions in making your animated GIF. Furthermore, PNG supports far more colors then GIF and it support alpha transparency (gif not). So you'll loose all that if you duplicate the first frame instead of keeping the two things seperate...

quote:

---

Originally posted by CookieRevised
About that first frame.... I wouldn't duplicate it in the PNG. I would keep the PNG image as something seperate. In that way, a user can decide to put a (slithly or complete) different pic in the PNG for "normal" users.

---

That's indeed true, it would allow for more customisation.

quote:

---

Originally posted by CookieRevised
Otherwise you bound to some restrictions in making your animated GIF. Furthermore, PNG supports far more colors then GIF and it support alpha transparency (gif not). So you'll loose all that if you duplicate the first frame instead of keeping the two things seperate...

---

These, are features PNG does support but MSN Messenger's decoder does not, therefor it's rather pointless in using them; unless we can find a way of completely eliminating the MSN Display Picture viewer and replace it with a home cooked one.

But, that's all things we needn't really worry about until we found a way of transfering the PNG, I'm sure there's more programmers out here who can comment any of my above stated posibilities, as in, indicate which are out of option and which they may know a method of applying.
It seems that we're rather stuck for the moment being, though.. ASM Hack as in the way TheBlasphemer did with his StuffPlug, sounds like the best method, but ASM Debugging / Hacking is way beyond my field of speciality.