[FFmpeg-devel] libavcodec/exr : Add support for UINT32

Martin Vignali martin.vignali at gmail.com
Sun Apr 3 20:59:22 CEST 2016


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 ?

Martin
Jokyo Images
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-libavcodec-exr-add-support-for-uint32.patch
Type: text/x-patch
Size: 4956 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160403/275eaf96/attachment.bin>


More information about the ffmpeg-devel mailing list