FRIGN wrote: > Another thing that bugs me is the inflexiblity of the width and > height-definition. 99% of all images have at most coordinates < 9999, which > means that you waste 10 bytes of image size on 99% of all images, because > every number is zero-padded. > > This implementation allows arbitrary-size width and height values while > remaining relatively simple at the same time. > > There may be some overhead, but it is the most flexible solution, as it both > allows simple files with no zero-padding in the values and is a bit stricter > when it comes to the header format (and fails in case it's malformed instead > of just taking what's there and failing silently). > > Just imagine some person in the year 2140 who can't save his > 2000000000x3000000 image, because we didn't take care of that and fixed the > number-width. :P
Heyho FRIGN, I don't think that is a good idea. First it would be inconsistent to allow for variable sized width and height field lengths, but force the usage of 8 bit per color channel per pixel. Secondly, the format would hit the colordepth border before hitting the 999.999.999 x 999.999.999 size restriction. With only one scanline of 999.999.999 pixels you can already enumerate 23.2% of all possible values a single pixel can have (dc: 3 k 999999999 2 32 ^ / p). If someone wants to use even higher resolutions, he probably also wants more accurate colors than just 256 shades of red|green|blue|gray|opacity. And then you are back to the pixel value interpretation madness. --Markus
