Hi everyone

Current FFv1 code with my patchset supports 16bit floats. The implementation
is quite simple. Which is good

I have tried improving compression, the gains are incremental, but its not
large overall. For example 44% space gain on the remapping table is just
0.1% overall.

I have few float samples. Its mainly one high quality slideshow of unrelated
16bit float images. These excercise a wide range fo things including negative
color values.
I think I have only one single (non slideshow) video of float 16 samples,

It turns out the most efficient way to store floats that i found, is to remap
them to integers. Not to store tham as sign, exponent, mantisse, i tried that
for many hours.

Storing them using a remapping, has a very nice side effect though, and that is
it will be easy to add 32bit and 64bit float support (once there is some
sample data)
Because a image of 64bit floats, after its split into slices of up to 256x256
can always be mapped into 16bit integers within each slice.

What about the mapping itself, it uses a rather simple rle coder. ive spend
most of the day today tuning that and failing to really beat that.
Using context from the previous image didnt work with the slideshow material
i have nor that one video i have. I tried using sign and exponent as context,
tried previous run, relations of runs, low bits and many more, but no or
insignificant improvments of yesterdays implementation was achieved.

There was some paper, lynne pointed my too about float remapping but that seemed
about remapping scientific 1-dimensional data. And what that paper did was
bascially reverse mapping floats into decimal numbers like 1.23456*10^-2
No image or video i found has samples like that. Also the paper was messy

Considering the whole remap table is now bascially down to slightly more than
0.1% of teh whole file, its not worth to look at that more.

Beyond the remapping, the storage of float follows what we do with integers
split into slices, perform decorrelation between planes, encode pixel for
pixel and sample for sample with a preidctor, and context from the
surrounding qualitized pixel differences and range coder.


If people have more ideas that fit into FFv1 float support.
(that is, good compresssion vs complexity vs speed and an architecture that
 fits into FFv1) ...

If not, i intend to apply my current patchset, update the FFv1 specification
and move on to some other work

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Homeopathy is like voting while filling the ballot out with transparent ink.
Sometimes the outcome one wanted occurs. Rarely its worse than filling out
a ballot properly.