On July 16, 2014 2:02:27 PM CEST, FRIGN <d...@frign.de> wrote:
>On Tue, 15 Jul 2014 20:40:08 +0200
>Markus Teich <markus.te...@stusta.mhn.de> wrote:
>
>> I hope this explains my issue.
>
>The definition is ambiguous and I start to get the impression the guy
>who defined this format had a naive view on what a "blank" is:
>Just a normal whitepace (0x20), as you already suspected.
>
>We now have two options: Either really define what should be put as a
>delimiter, or just don't care.
>Easiest to parse directly is using 0x00, but this is not very
>comfortable once you want to write an image-header.
>
>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.
>
>Why not do it like this:
>
>9 "imagefile"
>1 0x20
>var width
>1 0x20
>var height
>1 0x00
>
>and work with it like this:
>
>char *
>readimage(int fd, int *w, int *h)
>{
> size_t s;
> uint8_t c, *p, *data;
>
> for(s = 0; !s || c && s < SIZE_MAX; ++s){
> if(!read(fd, &c, 1))
> return NULL;
> }
>
> if (s < 9 || !(data = malloc(s)) || lseek(fd, 0, SEEK_SET) == -1
> || read(fd, buf, s) != s || strncmp("imagefile", data, 9)
> || !(p = strtok(data, " ") || !(*w = atoi(p))
> || !(p = strtok(p, " ") || !(*h = atoi(p)) ) {
> free(data);
> return NULL;
> }
>
> s = (*w) * (*h) * 4;
> free(data);
> data = malloc(data, s);
> if (!data || read(fd, data, s) != s) {
> free(data);
> return NULL;
> }
> return data;
>}
>
>This implementation allows arbitrary-size width and height values while
>remaining relatively simple at the same time.
>
>imagefile 800 600^@[data]
>
>vs
>
>imagefile 000000800 000000600^@[data]
>
>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
>
>Let me know what you think.
>
>Cheers
>
>FRIGN
Pathetic. Why would you do that to save at most 16 bytes?
Reasons against it:
0. This implementation is way cooler.
1. Storage is cheap.
2. Compression.
If anything, I would store the numbers as unsigned 64 bit LSB and change the
read/write functions for MSB architectures.
