[FFmpeg-devel] [PATCH] Fast half-float to float conversion

[Jimmy Christensen]

On 2009-07-01 13:04, Michael Niedermayer wrote:
> On Wed, Jul 01, 2009 at 07:12:53AM +0200, Jimmy Christensen wrote:
>> On 2009-06-30 19:04, Frank Barchard wrote:
>>> On Tue, Jun 30, 2009 at 8:07 AM, Reimar D?ffinger
>>> <Reimar.Doeffinger at gmx.de>wrote:
> [...]
>>>
>>>>
>>>>> Also a test that converts from half float to float and back again
>>>> losslessly
>>>>> would be good.
>>>>
>>>> Well, that depends a bit on what kind of data we are talking about. To be
>>>> honest,
>>>> for image data supporting NaN and INF seems rather pointless to me
>>>> (actually when
>>>> it comes to contrast/brightness adjustments I'd think most users would
>>>> prefer it
>>>> if it wasn't supported). Also FFmpeg in general is compiled to not
>>>> distinguish
>>>> between +0.0 and -0.0.
>>>
>>>
>>> nan and inf are bad... guaranteed to cause problems.  And they shouldnt
>>> come
>>> up much.
>>> denormals are somewhat interesting, in that they extend the range of valid
>>> half floats and floats.
>>> Reguardless of what we'd like half floats to be, I would pick a hardware
>>> implementation to be compatible with.
>>> CPU's tend to take the fancy approach of supporting denormals, nan and
>>> inf,
>>> while GPU's are simplier.
>>> The table approach at least allows half float to float to work any way.
>>> But
>>> on export, you would like the float to convert back to the same half
>>> float.
>>>
>>
>> For eg. OpenEXR the only interesting part is 0 - 1. And since it currently
>> needs to go into a RGB48 buffer it rounds things off anyway.
>>
>> There are also tables to do the opposite, but from a RGB48 buffer I would
>> not expect it to be exact.
>
> what seems to be missed in this thread is that RGB in ffmpeg and pretty much
> everywhere else is not linear in terms of number of photons vs. value, it
> rather depends on the gamma value amongth other things which we did neglegt
> slightly but they can be stored in AVColorTransferCharacteristic.
> in that sense 16bit floats given sensible ordering of the sign,exponent and
> mantisse bits could be considered RGB48 with a funny
> AVColorTransferCharacteristic ...
>

Is that supported by eg. swscaler?

>
>>
>> Would be interesting though to have high dynamic support in ffmpeg. Then
>> filters could be used to control the expose. Generally float channels would
>> be highly useful with filters in general.
>
> yes, floats could be usefull, but that would be 32bit because of the general
> lack of hw support for 16bit making 16bit too inconvenient for most things.
>
>

Also what I had in mind. I think even the OpenEXR documentation states 
that 16-bit floats are merely for transferring.