01-03-2012, 02:23 AM
(This post was last modified: 01-03-2012, 05:10 AM by AceInfinity.)
I'll do some tests right now actually, and see what I can come up with.
Update: Hmm, everything surprisingly actually works fine with the IEND bytes removed. I tested on my own forum uploading the image, and there's no delay in load time, however even on my localhost with apache installed, it seems to load fine. Tested downloading the file on both my localhost, and my website with curl back to my hard disk, and the IEND bytes don't seem to affect any of that either, after the download the IEND still remains out of the picture, but yet my file still acts completely normal... Also tried the right click and save option, but same result. I have yet to see why IEND is an important part of the file, it seems odd to me that I can't replicate any error with it's absence in the byte structure.
More investigation is probably needed with this, otherwise the smallest PNG file possible might be even less than 68 bytes...
Edit:
![[Image: ib6QXxCzRKgU9.png]](http://i.minus.com/ib6QXxCzRKgU9.png)
![[Image: i6L7gOEfighQF.png]](http://i.minus.com/i6L7gOEfighQF.png)
I know it marks the end of the PNG stream of data and it always appears last as the last 12 bytes in the file, but there's no identification for why it's such an important/critical chunk from what i've read up on PNG files up 'till now. Very strange that they don't document any of that.
I have my application check for these bytes at the beginning of the file because it's the first stream of bytes that define the PNG file format:
Then you have the IHDR and IDAT along with all the other arbitrary junk data in there, and the ICC profiles I still have to learn about (*also junk data however that could be removed), but that last part (IEND) based on my tests, doesn't do anything as far as my eyes have seen
The CRC in my files without it seems to be stable. Each bit of the IEND chunk points towards the fact that the Ancillary bit is 0, along with the Private, Reserved, and Safe-to-copy bits as well, being that they are all uppercase.
Edit: I finally see the importance of IEND now! And it is for data streaming... I will no longer look into removing this sector from the PNG file itself for optimization. I tried uploading my file with the IEND bytes removed, from an image upload site, and it wouldn't read my file. Strange how it worked with direct upload though, and I was seemingly able to view the image also...
I am sure this only happens when the bytes have to be read for streaming in a selection of interpreters however as photoshop and windows live gallery had no problem identifying the file's data (with or) without it. And I was able to view the image on a webserver if it was uploaded directly, and not through some script on a webpage. I would have to look into this further, but I finally came across an event that proved IEND valuable.
Update: Hmm, everything surprisingly actually works fine with the IEND bytes removed. I tested on my own forum uploading the image, and there's no delay in load time, however even on my localhost with apache installed, it seems to load fine. Tested downloading the file on both my localhost, and my website with curl back to my hard disk, and the IEND bytes don't seem to affect any of that either, after the download the IEND still remains out of the picture, but yet my file still acts completely normal... Also tried the right click and save option, but same result. I have yet to see why IEND is an important part of the file, it seems odd to me that I can't replicate any error with it's absence in the byte structure.
More investigation is probably needed with this, otherwise the smallest PNG file possible might be even less than 68 bytes...
Edit:
I know it marks the end of the PNG stream of data and it always appears last as the last 12 bytes in the file, but there's no identification for why it's such an important/critical chunk from what i've read up on PNG files up 'till now. Very strange that they don't document any of that.
I have my application check for these bytes at the beginning of the file because it's the first stream of bytes that define the PNG file format:
Code:
0x137 0x80 0x78 0x71 0x13 0x10 0x26 0x10Then you have the IHDR and IDAT along with all the other arbitrary junk data in there, and the ICC profiles I still have to learn about (*also junk data however that could be removed), but that last part (IEND) based on my tests, doesn't do anything as far as my eyes have seen
The CRC in my files without it seems to be stable. Each bit of the IEND chunk points towards the fact that the Ancillary bit is 0, along with the Private, Reserved, and Safe-to-copy bits as well, being that they are all uppercase.
Edit: I finally see the importance of IEND now! And it is for data streaming... I will no longer look into removing this sector from the PNG file itself for optimization. I tried uploading my file with the IEND bytes removed, from an image upload site, and it wouldn't read my file. Strange how it worked with direct upload though, and I was seemingly able to view the image also...
I am sure this only happens when the bytes have to be read for streaming in a selection of interpreters however as photoshop and windows live gallery had no problem identifying the file's data (with or) without it. And I was able to view the image on a webserver if it was uploaded directly, and not through some script on a webpage. I would have to look into this further, but I finally came across an event that proved IEND valuable.