Shoutbox

quote:

---

Originally posted by TheBlasphemer
Chunks are 4 bytes in length
Dont believe me and cookie? get a hex-editor!

---

It's not that I don't believe you, it's that I see contradicting things, which I want explained. The part I quoted you came from the libpng 1.2.5 manual. I'm assuming that's not wrong.

For your personal reference, http://www.libpng.org/pub/png/libpng-1.2.5-manual.html
Head: Unknown-chunk handling.

Thanks alot B, I've just figured it all out how it works, and I think I can really use it very well.
All I should do is change dwKeepTypes to the name of my chunk, that way I can strip everything except my chunk out. To then transform it into an algorythm that will write the chunk, shouldn't be too hard anymore.

I owe you one

quote:

---

Originally posted by TheBlasphemer
Does that make sense?

---

It does indeed, but that is exactly what you are doing, only, you're not checking to see if it is 'your chunk', you're checking to see if it's any of the mandatory chunks. I've been messing a bit and I've isolated the tEXt chunk together with the header and the 'dwLen' bytes. Up next is isolating only the content of the tEXt chunk and if I can do that I can do it with any chunk. After that I'll have a look at writing chunks.
It's all beginning to make perfect sense now, not all that hard =)

I'm going to have another read about the PNG format, though. For one, I'm interrested in what the capitalisation of the chunk types really means, where abouts you can add chunks and how unknown chunks are handled (will be handled by msn.. hmm.. hope they're not discarted.)
Might try adding a custom chunk, setting it as a DP and having a look at what the other side receives.

Thanks for the assistance TheBlasphemer and CookieRevised.

Edit:
I'd prefer to keep it the way you're handling it, since it allows for easily adding other custom chunks, in case I decide I want to pass some diffrent data in the DP as well; other than my GIF.

Hey lhunath,
                   you got any progress on this plugin/program thing yet?? or you still gathering information?

Oh right, I should update that

I've figured out how to do the animated display picture sending, I'm building a way to send it through right now, after that, there'll still be alot of work on making it show up properly.. So I'm afraid it won't be released for testing any time soon =P But we'll see how the progress goes, won't we.

i might be completely wrong here, but lemme try to explain

compare PNG's to EXE files. EXE files have a beginning, and an end. So adding data behind the end of the EXE file doesn't affect the file. I tried this with PNG, and it worked (i think).
So your file should look like:
<beginPNG><PNGdata><endPNG><yourdata...>
Ever tried this? because adding comments and working with chunks looks aweful to me =/

<offtopic>nice little dirty smilies you got there</offtopic>

What is wrong in doing it the correct way? (second time I'm asking this )... It looks complicated, but it realy isn't. It is as hard as your method, Millenium_edition:

To extract the data from the end of the PNG, you must know where the end is. So you need to read some data out of the PNG first to know where the end is, then extract the added stuff at the end...

In the the correct way of doing this, you need also to read some data from the PNG, but instead of skipping everything right to the end, you only skip the normal chuncks of the png, then extract your chunck in the same way as if you extracted something at the end of a file.

Creating the "special" PNG works also the same: instead of writing at the end of the file, you read some data out of the PNG, copy all the normal chuncks, and then if that is done, write your own chunks, and end the PNG...

The benefit is that it is a valid PNG. And even a bigger benefit of this all is that you can edit and change the PNG in a normal graphic editor (which must be PNG compatible of course) without loosing your "special" added chunck. (that's why I suggested a "private/ancillary/safe-to-copy" chunck)...

It indeed seems harder todo then it realy is, but that is with everything where the explaination is much more extensive then actually doing it...


EDIT: Oh btw, Millenium_edition, Welcome again at msgplus nice to see you here again

well i was a bit late because now you've come up with the chunks. and now you studied it.
but as far as i've read, can't you add a animdpsize="123456" to the <msnobj> tag, so you got the length, all you have to do is get the rest of the file, instead of decoding all those damn chunks...


oh and i was just passing by... thanks anyway

quote:

---

Originally posted by Millenium_edition
well i was a bit late because now you've come up with the chunks. and now you studied it.
but as far as i've read, can't you add a animdpsize="123456" to the <msnobj> tag, so you got the length, all you have to do is get the rest of the file, instead of decoding all those damn chunks...

---

That would involve interacting with the protocol. But what will that do for people without the "plugin"? It could work though. But it would be nice, IMO, if you don't need to interact with the protocol at all (which isn't so easy with plugins anyway I assume). Call me a standard and compatibily(damn word)-freak

BTW, you don't need to decode those other chuncks. That's the beauty of it, just read the type of chunck, if it isn't yours, skip it. And for writing, if it isn't yours, just copy it. No decoding involved...

---

EDIT: Oh, lhunath. I've got another small tip for you
Instead of storing the GIF in the chunck like it is. add 1 byte in front of it to identify the method you used to store the GIF. Thus it will act like kind of a version number.

I mean instead of this:
   ----start of chunck data----
   [Animated GIF (x bytes long)]
   ----end of chunck data----
Do this:
   ----start of chunck data----
   [Identifier byte (1 byte long)]
   [Animated GIF (x bytes long)]
   ----end of chunck data----

In that way, you can identify your method you used to store the GIF. This is very handy, because if you ever update the method of storing (say, you found a way to store it in a more compact way), you only have to make a new identifier (and thus acting like a version number) for your new method. In that way, the old method can still be read by your plugin because it can identify the method used for storing the GIF. If you don't use such a identifier, your plugin wont be compatible with older versions as it has no way of identifying and thus knowing what to do with the data... And that goes for the otherway around also: If someone is still using your "old" plugin, he can be notified that the PNG/GIF is written in a newer version and thus can't be read, because the "old" plugin doesn't reconize the "new" identifier and thus doesn't know the new method of extracting the GIF....

If you know what I mean (again, a big explaination for something extremely simple and it will be benefitial for the futur)

quote:

---

Originally posted by CookieRevised
Instead of storing the GIF in the chunck like it is. add 1 byte in front of it to identify the method you used to store the GIF. Thus it will act like kind of a version number.

---

That's actually a very good idea.

The current development status is this : I've made a program that extracts any data from any chunk. At the moment I'm making one that writes a custom chunk right after the IDAT chunk.

I've been thinking with TheBlasphemer about how we'll send the png to the other contact, since he told me that MSN Messenger decodes the PNG into RAW image data, then re-encodes that data into PNG format, that way, my custom chunk will be removed..