| moogie 2008-04-01, 7:56 am |
| >in fact you are trying to save something quite similar to 32-bit
>floating point numbers... The numbers you want to represent, without
>considering the floating point, are about 2*10^9, that are something
>less than 2^31, so for an 'uncompressed coding' you will need 31bits +
>3 sign bits = 34bits.
I do not understand why we would need 34 bits...
I have calculated the bits needed to represent the range of 8 digits +
decimal point and sign to be 31.... there are 1799999991 unique
values. Numbers containing digits (but ignoring decimal point) from
00000001 to 99999999 consist of 99999999 unique values and numbers
containing digits (but ignoring decimal point) -00000001 to -9999999
will also have 99999999 unique values. Add the 00000000 value gives
(99999999*2+1), there are 9 different positions to put the decimal
point... (e.g. 0.0000001 or 0000.0001 or 10000000. ) which means we
need to multiply by 9 to give the total number of unique values:
(99999999*2+1)*9
by the same logic above i can fit 6 digits + sign and decimal point in
24 bits (999999*2+1)*7 which is a much preferred outcome. I will
attempt to see whether the error when using only 6 digit floating
point will be acceptable.
I am attempting a video codec which will be based on least square line
fitting to generate functions that will approximate the RGB values of
a pixel through a series of sequential frames. I am attempting to
"compress" each function's term's multiplier by reducing the 32 bit
floating point number to a 24bit or 16 bit floating point number.
I am not entirely sure how one would go about reducing the accuracy of
a 32 bit floating point number to say a 24bit floating point number.
|