Hello, PNG
It&#x27;s a tiny issue, but what I like least about the PNG format is the checksum at the end of each block.<p>From what I gather, the checksum is there for two reasons: 1) a check on archival integrity, based on experience with its usefulness in ZIP files, and 2) a way to check for download errors early, before reaching the end-of-file, which was more important in the slow and noisy modem era of the 1990s.<p>However, it&#x27;s still possible for a change in chunk type to go undetected, for example, if &quot;zTXt&quot; were transformed to &quot;xTXt&quot; - a one bit change.<p>(I think it&#x27;s also possible to construct a chunk such that if the length changed to just the right value then it could be interpreted as two chunks (with a smaller length) or be merged with later chunks. This requires getting the CRCs to align just right, and even harder to have just a single bit change.)<p>My belief is that removing the per-block CRC32 and putting the checksum in the IEND at the very end of the PNG data stream, and using a stronger checksum - even MD5 - would be more effective at archival integrity.<p>This of course can&#x27;t happen now. Still, I regard it as a small bit of 1990s cruft.<p>When I developed my own format, for non-image data, I started with PNG as a guideline, then found that dealing with the checksum, even just to always generate a valid value, was a nuisance, with seemingly no good reason to justify its overhead.<p>I decided to drop the checksum, with a hand-waving argument that people should use other tools to detect and even repair file corruption, depending on their specific requirements.<p>This more generic and widespread family of formats is called &quot;FourCC&quot; for &quot;four-character code&quot; (<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;FourCC" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;FourCC</a>).