Rendered at 16:33:22 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
bschwindHN 6 hours ago [-]
Over a winter break a few years ago I wrote a PNG decoder in Rust, it was kinda fun! Here's the code if anyone's interested, it's not particularly great though.
I clicked "Show metadata chunks" and I don't understand the Critical vs Ancillary distinction. The Gamma, Color Space Information, Physical Dimensions, and Background Color sections all have a lowercase letter for their header. Aren't those critical to displaying the image properly? Meanwhile the Trailer IEND has an uppercase letter, indicating the zero-length outro byte is somehow more essential than all the color info?
Same question for safe/unsafe to copy. "Do programs that modify the PNG data need to understand this chunk?" Somehow, they need to understand the Last Modification Date before modifying the image, but no, they don't need to understand the Physical Dimensions(?)
meindnoch 13 hours ago [-]
>Gamma, Color Space Information, Physical Dimensions, and Background Color
Gamma is assumed to be sRGB gamma by default. Default color space is likewise sRGB. The Background Color is supposed to be used as the background color, against which the image is alpha-composited by viewers. Most modern viewers ignore it, because the whole point of the alpha channel is that it an be shown over any color.
>Meanwhile the Trailer IEND has an uppercase letter, indicating the zero-length outro byte is somehow more essential than all the color info
The IEND chunk was made mandatory, to make the format self-delimiting. i.e. a PNG file truncated at a chunk boundary would look just like a complete file. (although, one could argue that you could find out it's truncated when the uncompressed data comes back smaller than widthheightbytes_per_pixel)
Pinus 7 hours ago [-]
I suppose one could argue that if you are ignoring things like gamma and couour space and falling back on defaults, you are not showing the image correctly. My impression is that PNG takes a more relaxed approach, and considers anything that is in the right ballpark to be correct. For example, before hi-DPI screens ("retina display" and others) most image viewers would just map one image pixel to one display pixel, completely ignoring any "physical size" values, and this was generally considered correct.
ranger_danger 16 hours ago [-]
I think it would be a neat idea (if it doesn't exist already) to have a site with a collection of similar pages like this for many different formats.
WaitWaitWha 14 hours ago [-]
Similar to the other comment "Bit-mapped Graphics" by Steve Rimmer [0] is an excellent reference.
https://github.com/bschwind/png-decoder
Same question for safe/unsafe to copy. "Do programs that modify the PNG data need to understand this chunk?" Somehow, they need to understand the Last Modification Date before modifying the image, but no, they don't need to understand the Physical Dimensions(?)
Gamma is assumed to be sRGB gamma by default. Default color space is likewise sRGB. The Background Color is supposed to be used as the background color, against which the image is alpha-composited by viewers. Most modern viewers ignore it, because the whole point of the alpha channel is that it an be shown over any color.
>Meanwhile the Trailer IEND has an uppercase letter, indicating the zero-length outro byte is somehow more essential than all the color info
The IEND chunk was made mandatory, to make the format self-delimiting. i.e. a PNG file truncated at a chunk boundary would look just like a complete file. (although, one could argue that you could find out it's truncated when the uncompressed data comes back smaller than widthheightbytes_per_pixel)
[0] https://archive.org/details/bitmappedgraphic0000rimm
https://archive.org/details/mac_Graphics_File_Formats_Second...