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

[Jimmy Christensen]

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:
>
>> On Tue, Jun 30, 2009 at 07:55:04AM -0700, Frank Barchard wrote:
>>> On Tue, Jun 30, 2009 at 7:08 AM, Reimar D?ffinger
>>> <Reimar.Doeffinger at gmx.de>wrote:
>>>> Personally I don't think there is any need for such optimization for
>> the
>>>> first implementation of such a rare format as OpenEXR, it can still be
>>>> added after the rest has passed review (though Michael sometimes has a
>>>> different opinion on these kinds of things), and hopefully in a way
>> that
>>>> can
>>>> be properly optimized with assembly (whether ARM NEON or SSE2 or
>>>> whatever).
>>>
>>> I agree.    A small/simple version that can be done in hardware would be
>>> good for now.
>>> Graphic chips are starting to support half float.  So at some point we'll
>>> just want to pass the images along to be rendered as is.
>>
>> It seems more like the opposite way to me: they supported half float since
>> a
>> long time, but use it less and less nowadays and may eventually remove
>> support
>> for it.
>>
>>> Conversion could be done in swscaler.
>>
>> That may well be nicer, but also more effort.
>
>
> Ultimately, I expect we'll want float channels.  But thats almost a
> rearchitecting.  Its becoming very interesting for images / textures, but
> not all that necessary for movies.

But to generate the movies you'll need images :)

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

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.