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

Michael Niedermayer michaelni
Wed Jul 1 13:30:36 CEST 2009


On Wed, Jul 01, 2009 at 01:16:51PM +0200, Jimmy Christensen wrote:
> 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?

no but patch welcome ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- 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/70ed33dc/attachment.pgp>



More information about the ffmpeg-devel mailing list