Posts: 5,793
Threads: 268
Joined: Sep 2010
Reputation:
85
01-02-2012, 03:50 AM
(This post was last modified: 01-02-2012, 03:51 AM by AceInfinity.)
If you want to see a visual representation of where i'm at here it is:
![[Image: iPD5EruEg03Wm.png]](http://i.minus.com/iPD5EruEg03Wm.png)
Those chunks removed are just the ones that existed within this (PNG) file. My application can remove other bytes of junk data which can be found in PNG files, but sometimes PNG files can't be compressed at all because no data can be removed or altered, otherwise the file corrupts.
lol 77 bytes difference for this one though.
Posts: 556
Threads: 36
Joined: Jun 2011
Reputation:
14
(01-02-2012, 03:50 AM)AceInfinity Wrote: If you want to see a visual representation of where i'm at here it is:
Those chunks removed are just the ones that existed within this (PNG) file. My application can remove other bytes of junk data which can be found in PNG files, but sometimes PNG files can't be compressed at all because no data can be removed or altered, otherwise the file corrupts.
lol 77 bytes difference for this one though.
Now I see what you're doing. And that's actually pretty cool! Think there's some ridiculously complicated, advanced way to reduce them in size by like 90%?
Posts: 5,793
Threads: 268
Joined: Sep 2010
Reputation:
85
01-02-2012, 04:24 AM
(This post was last modified: 01-02-2012, 04:25 AM by AceInfinity.)
No, lol the smallest possible PNG filesize is 64 bytes. But that's basically nothing. You're down to grayscale, a bit depth of 1, dimensions of 1x1, removed sRGB, transparency, and everything else. The only way to do that is basically to make a PNG file identicle to that of a filesize, which would result in almost complete quality loss. PNG is already a fairly minimal filesize, which is why you don't see the compression ratio of mine very large. There's only so much data you can compress and remove before you start loosing quality. You basically end up converting down to grayscale and downsizing the bit depth to further reduce the filesize, which is completely useless to everyone.
By creating a PNG with a 1x1 frame, the smallest i've been able to compress the data to, is 64 bytes. Here's the byte structure, which basically consists of the PNG header, the IDAT, and nothing else...
Code: 89 0x50 0x4E 0x47 0x0D 0x0A 0x1A 0x0A 0x00 0x00 0x00 0x0D 0x49 0x48 0x44 0x52 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x01 0x01 0x00 0x00 0x00 0x00 0x37 0x6E 0xF9 0x24 0x00 0x00 0x00 0x13 0x49 0x44 0x41 0x54 0x78 0xDA 0x62 0xF8 0xFF 0xFF 0x3F 0x03 0x00 0x00 0x00 0xFF 0xFF 0x03 0x00 0x08 0xFC 0x02 0xFE 0xD3 0xA5 0x75 0x61
Posts: 556
Threads: 36
Joined: Jun 2011
Reputation:
14
(01-02-2012, 04:24 AM)AceInfinity Wrote: No, lol the smallest possible PNG filesize is 64 bytes. But that's basically nothing. You're down to grayscale, a bit depth of 1, dimensions of 1x1, removed sRGB, transparency, and everything else. The only way to do that is basically to make a PNG file identicle to that of a filesize, which would result in almost complete quality loss. PNG is already a fairly minimal filesize, which is why you don't see the compression ratio of mine very large. There's only so much data you can compress and remove before you start loosing quality. You basically end up converting down to grayscale and downsizing the bit depth to further reduce the filesize, which is completely useless to everyone.
By creating a PNG with a 1x1 frame, the smallest i've been able to compress the data to, is 64 bytes. Here's the byte structure, which basically consists of the PNG header, the IDAT, and nothing else...
Code: 89 0x50 0x4E 0x47 0x0D 0x0A 0x1A 0x0A 0x00 0x00 0x00 0x0D 0x49 0x48 0x44 0x52 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x01 0x01 0x00 0x00 0x00 0x00 0x37 0x6E 0xF9 0x24 0x00 0x00 0x00 0x13 0x49 0x44 0x41 0x54 0x78 0xDA 0x62 0xF8 0xFF 0xFF 0x3F 0x03 0x00 0x00 0x00 0xFF 0xFF 0x03 0x00 0x08 0xFC 0x02 0xFE 0xD3 0xA5 0x75 0x61
So by reducing the PNG you did earlier, you haven't lost any quality since you were only removing junk bytes, right?
Posts: 3,538
Threads: 348
Joined: Mar 2010
Reputation:
57
If that's the case then this is a pretty interesting project. All that talk of bytes completely confused me, you should have just said what it is you were doing in a basic way lol.
Can you do this for any file format or just .PNG? What about .MOV files?
Posts: 5,793
Threads: 268
Joined: Sep 2010
Reputation:
85
01-02-2012, 02:24 PM
(This post was last modified: 01-02-2012, 02:25 PM by AceInfinity.)
(01-02-2012, 04:31 AM)King Wrote: So by reducing the PNG you did earlier, you haven't lost any quality since you were only removing junk bytes, right?
Nope, absolutely no lossy output.
(01-02-2012, 05:09 AM)Fragma Wrote: If that's the case then this is a pretty interesting project. All that talk of bytes completely confused me, you should have just said what it is you were doing in a basic way lol.
Can you do this for any file format or just .PNG? What about .MOV files?
Yeah, I guess. I could do it for any file format, but it would require more research on how the file structure is built, no single method will compress every kind of file as there's lots of diversity in the way the byte structures of files are, and some vary quite a bit.
I could do it with .MOV files, i'm sure it wouldn't be too difficult. This program that I have now actually analyzes the byte structure of the PNG file to determine whether it's a valid PNG or not. I could do the same with virtually any kind of file after some analysis.
Right now after doing this project, I have pretty extensive knowledge about how PNG files are structured though...
Posts: 3,538
Threads: 348
Joined: Mar 2010
Reputation:
57
I probably wouldn't find any use for this as far as .PNG compressing goes, but if you were to do something similar for .MOV files in the future then please let me know! It would be really helpful with my animation course.
Posts: 5,793
Threads: 268
Joined: Sep 2010
Reputation:
85
I may give it a try later and i'll let you know.
Posts: 1,778
Threads: 163
Joined: Jun 2007
Reputation:
218
01-02-2012, 07:31 PM
(This post was last modified: 01-02-2012, 07:32 PM by Omniscient.)
The last bytes are the IEND chunk. It basically explains that that PNG file has ended. Removing it might cause load problems with browsers or other programs.
Removing it might also slow down the loading of the image. Probably not wise to get rid of it.
Great thread btw.
 I am here to rescue you.
This is Support Forums not Support PMs. Do not PM me for support unless it's private and site related.
Posts: 5,793
Threads: 268
Joined: Sep 2010
Reputation:
85
(01-02-2012, 07:31 PM)Omniscient Wrote: The last bytes are the IEND chunk. It basically explains that that PNG file has ended. Removing it might cause load problems with browsers or other programs.
Removing it might also slow down the loading of the image. Probably not wise to get rid of it.
Great thread btw.
Thankyou very much  That explains some of it, because removing the IEND chunk I had found no loading problems with photoshop or the windows photo gallery program. Modifications in Photoshop were fine with the last 12 bytes removed, and it basically rebuilds that 12 byte structure at the end no problem. I'll keep it in there though, so I was wrong, I'm now believing that the smallest valid PNG file is 68 bytes I believe.
All places I looked for just explained that the IEND chunk was to show that the PNG file had ended, but not great explanations on why it was a critical sector.
|
