[FFmpeg-devel] libavcodec/exr : Add support for UINT32
Paul B Mahol
onemda at gmail.com
Sun Apr 3 21:03:38 CEST 2016
On 4/3/16, Martin Vignali <martin.vignali at gmail.com> wrote:
> 2016-04-03 19:31 GMT+02:00 wm4 <nfxjfg at googlemail.com>:
>
>> On Sun, 3 Apr 2016 19:19:25 +0200
>> Paul B Mahol <onemda at gmail.com> wrote:
>>
>> > On 4/3/16, Martin Vignali <martin.vignali at gmail.com> wrote:
>> > > Hello,
>> > >
>> > > In attach a patch to add support for UINT32 pixel type.
>> > >
>> > > Sample of UINT 32 file (scanline only in that case) can be found here
>> > > :
>> > > https://we.tl/sFB0NYlQVW
>> > >
>> > > For colorprocessing, UINT32, are converted to float, and follow a
>> similar
>> > > way for color process than float.
>> > >
>> > > I not enable in this patch PXR24 in UINT32, who need modification
>> inside
>> > > pxr24_uncompress.
>> > >
>> > > Comments welcome
>> >
>> > So UINT_32 is processed as it was FLOAT, that is strange.
>>
>> And then the float data is converted back to integer for output? That's
>> very funny.
>>
>>
> New patch attach, without the UINT32_MAX define and clean empty line
>
> For color processing :
> The actual exr decoder of ffmpeg, make color conversion inside the decoding
> process in float (trc_func, seems to expect to have a float, and one_gamma
> is also a float)
> After the color conversion, data are converted to uint16.
>
> uint32 is convert to float (but map in the range 0., 1.0). Some software
> decode UINT32 Exr as float without conversion (so the picture is most of
> the time white and more). But i doesn't think this way is very convenient
> (specially if the rest of the process is not in float)
>
> Seems you're both not agree. What solution you recommend ?
Put } and else in same line.
> Martin
> Jokyo Images
>
More information about the ffmpeg-devel
mailing list