On Fri, 18 Jul 2014 13:44:20 -0400 Charlie Murphy <cmsmur...@gmail.com> wrote:
> Bytes Description > 13 ASCII string: "img13w7h7rgba" > 7 Right-justified, space-padded ASCII string containing width. > 7 Right-justified, space-padded ASCII string containing height. > (w*h) Raw RGBA. I still don't like the idea of this ASCII-string for width and height. I'd rather put it this way: Bytes Description 13 ASCII string: "img13w4h4rgba" 4 32 bit Big-Endian integer for width 4 32 bit Big-Endian integer for height (w*h) Raw RGBA. I expect texture-sizes to grow exponentially in the future. Just take modern video games, which can get really heavy and use a single texture-map for whole levels to make loading easier. These maps can be several Gigabytes and reach measures in the 10k- and 100k-areas. With 7 chars, you only get that far to address a certain size. I also want to note that it's painful to read the padding zeroes. The only reason you want to have human-readable width and height is that the format should be printable with shell-scripts. Well, it's not very hard to handle binary-data either, and usually, the "standard tools" should be written in C, where handling binary data is almost simpler than handling these difficult, padded strings. Some people even said that this readable width and height would allow users to hand-edit files. How would that work? You could change the header, but then needed a hex-editor anway. The only sane reason I can think of is for people to check what dimensions an image has. However, if I want to get image-dimensions, I usually use "file" for that. Anything else is just unnecessary cruft to fix problems which didn't exist in the first place or which even not fixes the issues. Cheers FRIGN -- FRIGN <d...@frign.de>