On 06/03/2025 01:15, Michael Niedermayer wrote:
> 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.

*how*? Unlike ints, you cannot simply shift and extract bits from floats 
and treat them as floats.

> 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.

I did mention this once before, but you should look into the Daala/Opus 
way of storing rawbits into a separate chunk at the end of the 
bitstream. It avoids polluting the range context with equiprobable bits.