Re: [dev] Looking for simple, alpha supporting image format

From: Markus Teich <markus.teich_AT_stusta.mhn.de>
Date: Wed, 16 Jul 2014 14:54:24 +0200

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
Received on Wed Jul 16 2014 - 14:54:24 CEST