Discussion
baseline feature set for a Very Good Image Format, No Notes
- support as many different pixel formats for the same type of data as possible
- different bit packings, different channel orders a plus
- bonus points if channel order freely configurable
- extra bonus points if channels sorted alphabetically so default channel order is a, b, g, r
- as many compression formats as possible
- bonus points if switching mid-image is allowed
1/n
- users use all kinds of coordinate systems, therefore your image format should not make that decision for them
- both top-down and bottom-up image layouts, at minimum, are a must
- bonus points for supporting +x = left because this is especially valuable
- image dimensions should not be arbitrarily constrained. width and height fields should be 32-bits minimum
- bonus points if signed, you never know
- but make sure you need to load huge imgs all at once, tiles are stupid
2/n
- there are many ways to do framing; the best way to do so is to use reserved marker bytes/codes so that every layer of parsing maintains awareness of all surrounding layers at all times
- unless every layer creates a copy of the data stream with its framing removed, which is of course an even better way to do things
- leave as many extension hooks as possible
- but do not use any generic metadata format like key/value pairs, use something custom for every extension
3/n
- endianness is an emotionally loaded topic; avoid the drama by not making a choice and supporting both little and big endian
- bonus points for putting the endianness flag not in the outermost header, but somewhere 1 or 2 layers deep
- extra bonus points when figuring this out also requires parsing text in an unknown encoding
- alternatively, always mix both endians
4/n
- considering text encodings, again, don't make choices for users; just let everyone encode text however they want
- bonus points if the encoding is not stored anywhere
- be sure to always include color space information, including a full ICC profile and configurable gamma, but sRGB is optional, nobody needs that
- the default for 16-bit and HDR data should, of course, be a gamma encoding
- if you use subsampled Y'CbCr, nobody cares where the pixel centers are; let apps figure it out
5/n
@rygorous sir you are describing a beautiful albatross.