Support Forums

What's the significance of these 12 bytes in the PNG file format?


I don't understand, from what i've read, it is a critical part of the file, however when removed, it has no barrier on whether or not you're able to open/view and/or edit the file whatsoever.

No replies to my post at all?...

(01-01-2012, 07:21 AM)AceInfinity Wrote: [ -> ]No replies to my post at all?...

That would be because no one has any freakin clue as to a likely reason for this. You're too curious.

Yeh I haven't got the slightest idea what you're on about.

lol times when I wish there were more programmers on a forum I frequently visit... What i'm doing is recursively searching through the bytes of a filetype and using List(of Object) to add each byte from the file and search for specific bytes in a newly instanced byte array, I have to convert the encodings, and search for this end statement. After removing specific chunks of bytes as arbitrary data in the file it's going to be parsed back into a byte stream as a pseudo recompiler so I can optimize the filesize on disk. Dealing with large data like this though may require extensive multi-threading operations.

In sum this is information I require to further my development on a programming project.

What those bytes above represent is the last 12 bytes of all PNG files.

No offence but that sounds really really boring. But hey what do I know, I'm sure it's useful. Good luck with your project.

(01-01-2012, 06:13 PM)Fragma Wrote: [ -> ]No offence but that sounds really really boring. But hey what do I know, I'm sure it's useful. Good luck with your project.

Boring because you don't understand or you don't like dealing with bytes? Not everything in programming is going to be flashy like graphics

So far i'm able to remove 2 types of byte chunks in the PNG file format, which gets me about 30-50 bytes less than the original filesize. Still more to go, but PNG is already a fairly minimal filetype. There's not much you can do with compressing it's data.

Edit:
pHYs: *Total Byte Capacity = 21

cHRM: *Total Byte Capacity = 44

Basically in sum along with those 12 in the last 12 bytes of the file allow me to optimize the file by a difference of 77 bytes, not 30-50. Soon i'll be able to downsize by over 1kb, but with very small graphics that can be a big difference. There's not all the byte chunks stored in smaller graphics though due to the lack of color values in each pixel, but if you're doing this with every file you have on your website it can make a difference. Omni here wants userbars to be under 3kb? 4kb? I can't remember, but here's a use for that as well.

Sorry, that went straight over my head. Only because I couldn't be fudged to read it right now. It's good that you have such knowledge, though.

I'm now at a point where i've been able to compress PNG files by a difference of 200 bytes, however there's still text data chunks and a photoshop iCCP profile that i've seen in some of my own personal PNG files that I used for debugging that I don't know what to deal with. If I could remove that photoshop data with all it's bytes and all the meta data associated with it I could potentially reduce the file by another 200 bytes on top of that depending on whether or not it exists within the byte structure.

I could also take out the transparency chunks which is only about 1 byte difference in file optimization so I felt it's not really worth it. Transparency actually doesn't make a big difference in PNG file size after my investigation... Unless you care about getting rid of an extra whopping 1 byte.

Here's what i've got so far:





Note the mid value bytes for 0xFF 0xFF 0xFF represent the background color in RGB format in hexadecimal form, hence why you now start to see some real values being the 255 max in the decimal version I found. The background image of the file I examined here was white.


These are all demos of what i've extracted from my own personal debugging and testing, variable bytes do change but the signatures for each of these arbitrary byte chunks do not, which is why they are identifiable.

Now onto moving how I can modify the critical sectors of the PNG file structure with each of the IDAT chunks. All of what I did so far however, results in no lossy compression. It's all useless data kept in the background that most people wouldn't even realize was there in the first place.

Okay, you're just talking to yourself now. :p