On Fri, 18 Jul 2014 13:44:20 -0400
Charlie Murphy <cmsmurp00_AT_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 <dev_AT_frign.de>
Received on Fri Jul 18 2014 - 20:10:22 CEST