On 4/3/16, Martin Vignali <martin.vign...@gmail.com> wrote: > 2016-04-03 19:31 GMT+02:00 wm4 <nfx...@googlemail.com>: > >> On Sun, 3 Apr 2016 19:19:25 +0200 >> Paul B Mahol <one...@gmail.com> wrote: >> >> > On 4/3/16, Martin Vignali <martin.vign...@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 > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
