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

Michael Niedermayer michaelni
Wed Jul 1 13:04:13 CEST 2009


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


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


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090701/197b5457/attachment.pgp>



More information about the ffmpeg-devel mailing list