Re: [FFmpeg-devel] libavcodec/exr : add support for uint32

2017-03-29 Thread Paul B Mahol
On 3/18/17, Martin Vignali  wrote:
>>
>> Just a nitpick:
>>
>> > +} else {
>> > +//UINT 32
>>
>> The comment indicates this should be "else if (pixel_type == UINT)"
>>
>> Not sure it's necessary to replace else by else if, because OpenExr
> "planar" can only have half, float or uint32 data
>
> But new patch attach.
>
> Martin
>

applied, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] libavcodec/exr : add support for uint32

2017-03-29 Thread Martin Vignali
2017-03-27 10:10 GMT+02:00 Carl Eugen Hoyos :

> 2017-03-25 13:09 GMT+01:00 Martin Vignali :
> > Ping for apply
>
> Please send your public key to Michael and ask him to add you
> as committer, you have many commits in FFmpeg.
>
> Hello,

I'm not enough familiar with git, to be a commiter.

Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] libavcodec/exr : add support for uint32

2017-03-27 Thread Carl Eugen Hoyos
2017-03-25 13:09 GMT+01:00 Martin Vignali :
> Ping for apply

Please send your public key to Michael and ask him to add you
as committer, you have many commits in FFmpeg.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] libavcodec/exr : add support for uint32

2017-03-25 Thread Martin Vignali
Ping for apply

Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] libavcodec/exr : add support for uint32

2017-03-18 Thread Martin Vignali
>
> Just a nitpick:
>
> > +} else {
> > +//UINT 32
>
> The comment indicates this should be "else if (pixel_type == UINT)"
>
> Not sure it's necessary to replace else by else if, because OpenExr
"planar" can only have half, float or uint32 data

But new patch attach.

Martin


0001-libavcodec-exr-add-support-for-uint32.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] libavcodec/exr : add support for uint32

2017-03-18 Thread Carl Eugen Hoyos
2017-03-07 23:05 GMT+01:00 Martin Vignali :
> Hello,
>
> In attach patch for decoding uint32 channels in exr files.
>
> Following previous comments, i doesn't use float/color transformation for
> this kind of pixel data
> in this new version.
>
> Comments welcome

Just a nitpick:

> +} else {
> +//UINT 32

The comment indicates this should be "else if (pixel_type == UINT)"

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] libavcodec/exr : add support for uint32

2017-03-18 Thread Paul B Mahol
On 3/18/17, Martin Vignali  wrote:
> 2017-03-07 23:05 GMT+01:00 Martin Vignali :
>
>> Hello,
>>
>> In attach patch for decoding uint32 channels in exr files.
>>
>> Following previous comments, i doesn't use float/color transformation for
>> this kind of pixel data
>> in this new version.
>>
>> Comments welcome
>>
>> Martin Vignali
>> Jokyo Images
>>
>
> ping
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] libavcodec/exr : add support for uint32

2017-03-18 Thread Martin Vignali
2017-03-07 23:05 GMT+01:00 Martin Vignali :

> Hello,
>
> In attach patch for decoding uint32 channels in exr files.
>
> Following previous comments, i doesn't use float/color transformation for
> this kind of pixel data
> in this new version.
>
> Comments welcome
>
> Martin Vignali
> Jokyo Images
>

ping
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] libavcodec/exr : add support for uint32

2017-03-07 Thread Martin Vignali
Hello,

In attach patch for decoding uint32 channels in exr files.

Following previous comments, i doesn't use float/color transformation for
this kind of pixel data
in this new version.

Comments welcome

Martin Vignali
Jokyo Images


0001-libavcodec-exr-add-support-for-uint32.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] libavcodec/exr : add support for uint32 channel decoding with pxr24

2016-11-24 Thread Andreas Cadhalpun
On 17.11.2016 21:30, Martin Vignali wrote:
> From c70a83c38cd9a9434e6434d60dadf0a1c809e074 Mon Sep 17 00:00:00 2001
> From: Martin Vignali 
> Date: Thu, 17 Nov 2016 21:24:42 +0100
> Subject: [PATCH 2/3] libavcodec/exr : add support for uint32 channel decoding
>  with pxr24
> 
> Doesn't decode the uint32 layer, but decode the half part of the file.
> ---
>  libavcodec/exr.c | 16 
>  1 file changed, 16 insertions(+)

This looks OK and fixes the sample, so I've applied it.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] libavcodec/exr : add support for uint32 channel decoding with pxr24

2016-11-24 Thread Martin Vignali
2016-11-17 21:30 GMT+01:00 Martin Vignali :

> Hello,
>
> In attach a patch, who fix the decoding of half (or float) layer with
> pxr24 compression, when there is also an uint32 layer.
>
> The uint32 layer is still not decodable.
>
> Found by Andreas Cadhalpun
>
> sample can be found here :
> https://we.tl/ULGDVxQXGy
>
>
> Comments welcome
>
> Martin
>

Ping
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] libavcodec/exr : add support for uint32 channel decoding with pxr24

2016-11-17 Thread Martin Vignali
Hello,

In attach a patch, who fix the decoding of half (or float) layer with pxr24
compression, when there is also an uint32 layer.

The uint32 layer is still not decodable.

Found by Andreas Cadhalpun

sample can be found here :
https://we.tl/ULGDVxQXGy


Comments welcome

Martin
From c70a83c38cd9a9434e6434d60dadf0a1c809e074 Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Thu, 17 Nov 2016 21:24:42 +0100
Subject: [PATCH 2/3] libavcodec/exr : add support for uint32 channel decoding
 with pxr24

Doesn't decode the uint32 layer, but decode the half part of the file.
---
 libavcodec/exr.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index f02337e..7852727 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -882,6 +882,22 @@ static int pxr24_uncompress(EXRContext *s, const uint8_t *src,
 bytestream_put_le16(, pixel);
 }
 break;
+case EXR_UINT:
+ptr[0] = in;
+ptr[1] = ptr[0] + s->xdelta;
+ptr[2] = ptr[1] + s->xdelta;
+ptr[3] = ptr[2] + s->xdelta;
+in = ptr[3] + s->xdelta;
+
+for (j = 0; j < s->xdelta; ++j) {
+uint32_t diff = (*(ptr[0]++) << 24) |
+(*(ptr[1]++) << 16) |
+(*(ptr[2]++) << 8 ) |
+(*(ptr[3]++));
+pixel += diff;
+bytestream_put_le32(, pixel);
+}
+break;
 default:
 return AVERROR_INVALIDDATA;
 }
-- 
1.9.3 (Apple Git-50)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2016-04-04 Thread Martin Vignali
2016-04-03 21:11 GMT+02:00 Martin Vignali :

>
>
> 2016-04-03 21:03 GMT+02:00 Paul B Mahol :
>
>> On 4/3/16, Martin Vignali  wrote:
>> > 2016-04-03 19:31 GMT+02:00 wm4 :
>> >
>> >> On Sun, 3 Apr 2016 19:19:25 +0200
>> >> Paul B Mahol  wrote:
>> >>
>> >> > On 4/3/16, Martin Vignali  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.
>>
>
> New patch in attach.
>

In attach, a new version of this patch, adding support for PXR24 uint32.

Sorry for multi post.


Martin
Jokyo Images
From 8a27aff23da67f2689e72a7dad4248445f2f5735 Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Mon, 4 Apr 2016 15:08:41 +0200
Subject: [PATCH] libavcodec/exr : add support for uint32

---
 libavcodec/exr.c | 70 ++--
 1 file changed, 63 insertions(+), 7 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index b0573d5..878a1f5 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -3,7 +3,7 @@
  * Copyright (c) 2006 Industrial Light & Magic, a division of Lucas Digital Ltd. LLC
  * Copyright (c) 2009 Jimmy Christensen
  *
- * B44/B44A, Tile added by Jokyo Images support by CNC - French National Center for Cinema
+ * B44/B44A, Tile, uint32 added by Jokyo Images support by CNC - French National Center for Cinema
  *
  * This file is part of FFmpeg.
  *
@@ -853,6 +853,22 @@ static int pxr24_uncompress(EXRContext *s, const uint8_t *src,
 bytestream_put_le16(, pixel);
 }
 break;
+case EXR_UINT:
+ptr[0] = in;
+ptr[1] = ptr[0] + s->xdelta;
+ptr[2] = ptr[1] + s->xdelta;
+ptr[3] = ptr[2] + s->xdelta;
+in = ptr[3] + s->xdelta;
+
+for (j = 0; j < s->xdelta; ++j) {
+uint32_t diff = (*(ptr[0]++) << 24) |
+(*(ptr[1]++) << 16) |
+(*(ptr[2]++) << 8 ) |
+(*(ptr[3]++));
+pixel += diff;
+bytestream_put_le32(, pixel);
+}
+break;
 default:
 return AVERROR_INVALIDDATA;
 }
@@ -1096,7 +1112,7 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 if (s->is_tile) {
 indexSrc = 0;
 channelLineSize = s->xsize * 2;
-if (s->pixel_type == EXR_FLOAT)
+if ((s->pixel_type == EXR_FLOAT)||(s->pixel_type == EXR_UINT))
 channelLineSize *= 2;
 
 /* reorganise tile data to have each channel one after the other instead of line by line */
@@ -1181,7 +1197,7 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 *ptr_x++ = exr_flt2uint(bytestream_get_le32());
 }
 }
-} else {
+} else if (s->pixel_type == EXR_HALF) {
 // 16-bit
 for (x = 0; x < s->xsize; x++) {
 *ptr_x++ = s->gamma_table[bytestream_get_le16()];
@@ -1190,6 +1206,44 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 if (channel_buffer[3])
 *ptr_x++ = exr_halflt2uint(bytestream_get_le16());
 }
+} else {
+//UINT 32
+if (trc_func) {
+for (x = 0; x < s->xsize; x++) {
+ 

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

2016-04-03 Thread Martin Vignali
2016-04-03 21:03 GMT+02:00 Paul B Mahol :

> On 4/3/16, Martin Vignali  wrote:
> > 2016-04-03 19:31 GMT+02:00 wm4 :
> >
> >> On Sun, 3 Apr 2016 19:19:25 +0200
> >> Paul B Mahol  wrote:
> >>
> >> > On 4/3/16, Martin Vignali  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.
>

New patch in attach.
From 41342f07e965f9ad22f7970fde3b2ea0d2f4a7df Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Sun, 3 Apr 2016 21:08:58 +0200
Subject: [PATCH] libavcodec/exr : add suport for uint32

---
 libavcodec/exr.c | 57 ++--
 1 file changed, 51 insertions(+), 6 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index b0573d5..1a7323a 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1096,7 +1096,7 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 if (s->is_tile) {
 indexSrc = 0;
 channelLineSize = s->xsize * 2;
-if (s->pixel_type == EXR_FLOAT)
+if ((s->pixel_type == EXR_FLOAT)||(s->pixel_type == EXR_UINT))
 channelLineSize *= 2;
 
 /* reorganise tile data to have each channel one after the other instead of line by line */
@@ -1181,7 +1181,7 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 *ptr_x++ = exr_flt2uint(bytestream_get_le32());
 }
 }
-} else {
+} else if (s->pixel_type == EXR_HALF) {
 // 16-bit
 for (x = 0; x < s->xsize; x++) {
 *ptr_x++ = s->gamma_table[bytestream_get_le16()];
@@ -1190,6 +1190,44 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 if (channel_buffer[3])
 *ptr_x++ = exr_halflt2uint(bytestream_get_le16());
 }
+} else {
+//UINT 32
+if (trc_func) {
+for (x = 0; x < s->xsize; x++) {
+union av_intfloat32 t;
+t.f = trc_func((float)bytestream_get_le32() / (float)UINT32_MAX);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.f = trc_func((float)bytestream_get_le32() / (float)UINT32_MAX);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.f = trc_func((float)bytestream_get_le32() / (float)UINT32_MAX);
+*ptr_x++ = exr_flt2uint(t.i);
+if (channel_buffer[3]) {
+t.f = trc_func((float)bytestream_get_le32() / (float)UINT32_MAX);
+*ptr_x++ = exr_flt2uint(t.i);
+}
+}
+} else {
+for (x = 0; x < s->xsize; x++) {
+union av_intfloat32 t;
+t.f = (float)bytestream_get_le32() / (float)UINT32_MAX;
+t.f = powf(t.f, one_gamma);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.f = (float)bytestream_get_le32() / (float)UINT32_MAX;
+t.f = powf(t.f, one_gamma);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.f = (float)bytestream_get_le32() / (float)UINT32_MAX;
+t.f = powf(t.f, one_gamma);
+*ptr_x++ = exr_flt2uint(t.i);
+if (channel_buffer[3]) {
+t.f = (float)bytestream_get_le32() / (float)UINT32_MAX;
+*ptr_x++ = exr_flt2uint(t.i);

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

2016-04-03 Thread Paul B Mahol
On 4/3/16, Martin Vignali  wrote:
> 2016-04-03 19:31 GMT+02:00 wm4 :
>
>> On Sun, 3 Apr 2016 19:19:25 +0200
>> Paul B Mahol  wrote:
>>
>> > On 4/3/16, Martin Vignali  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


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

2016-04-03 Thread Martin Vignali
2016-04-03 19:31 GMT+02:00 wm4 :

> On Sun, 3 Apr 2016 19:19:25 +0200
> Paul B Mahol  wrote:
>
> > On 4/3/16, Martin Vignali  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
From 62a3500ff874db4c7da69ec235dfe9901cd49c3c Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Sun, 3 Apr 2016 20:32:54 +0200
Subject: [PATCH] libavcodec/exr : add support for uint32

---
 libavcodec/exr.c | 58 ++--
 1 file changed, 52 insertions(+), 6 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index b0573d5..3e65a91 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1096,7 +1096,7 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 if (s->is_tile) {
 indexSrc = 0;
 channelLineSize = s->xsize * 2;
-if (s->pixel_type == EXR_FLOAT)
+if ((s->pixel_type == EXR_FLOAT)||(s->pixel_type == EXR_UINT))
 channelLineSize *= 2;
 
 /* reorganise tile data to have each channel one after the other instead of line by line */
@@ -1181,7 +1181,7 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 *ptr_x++ = exr_flt2uint(bytestream_get_le32());
 }
 }
-} else {
+} else if (s->pixel_type == EXR_HALF) {
 // 16-bit
 for (x = 0; x < s->xsize; x++) {
 *ptr_x++ = s->gamma_table[bytestream_get_le16()];
@@ -1190,6 +1190,44 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 if (channel_buffer[3])
 *ptr_x++ = exr_halflt2uint(bytestream_get_le16());
 }
+} else {
+//UINT 32
+if (trc_func) {
+for (x = 0; x < s->xsize; x++) {
+union av_intfloat32 t;
+t.f = trc_func((float)bytestream_get_le32() / (float)UINT32_MAX);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.f = trc_func((float)bytestream_get_le32() / (float)UINT32_MAX);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.f = trc_func((float)bytestream_get_le32() / (float)UINT32_MAX);
+*ptr_x++ = exr_flt2uint(t.i);
+if (channel_buffer[3]){
+t.f = trc_func((float)bytestream_get_le32() / (float)UINT32_MAX);
+*ptr_x++ = exr_flt2uint(t.i);
+}
+}
+} else {
+for (x = 0; x < s->xsize; x++) {
+union av_intfloat32 t;
+t.f = (float)bytestream_get_le32() / (float)UINT32_MAX;
+t.f = powf(t.f, one_gamma);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.f = (float)bytestream_get_le32() / (float)UINT32_MAX;
+t.f = powf(t.f, one_gamma);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.f = (float)bytestream_get_le32() / (float)UINT32_MAX;
+t.f = powf(t.f, one_gamma);
+*ptr_x++ = exr_flt2uint(t.i);
+if (channel_buffer[3]){
+t.f = (float)bytestream_get_le32() / (float)UINT32_MAX;
+*ptr_x++ = exr_flt2uint(t.i);
+}
+}
+}
 }
 
 // Zero out the end if xmax+1 is not w
@@ -1401,7 +1439,12 @@ static int decode_header(EXRContext *s)
 channel->xsub   = xsub;
 channel->ysub   = ysub;
 
-s->current_channel_offset 

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

2016-04-03 Thread wm4
On Sun, 3 Apr 2016 19:19:25 +0200
Paul B Mahol  wrote:

> On 4/3/16, Martin Vignali  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.

> You keep adding white spaces in your patches, than I need to manually
> remove them.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2016-04-03 Thread Paul B Mahol
On 4/3/16, Martin Vignali  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.

You keep adding white spaces in your patches, than I need to manually
remove them.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2016-04-03 Thread Derek Buitenhuis
On 4/3/2016 5:58 PM, Martin Vignali wrote:
> Hello,
> 
> In attach a patch to add support for UINT32 pixel type.

[...]

> +#ifndef UINT32_MAX
> +#define UINT32_MAX  (0x)
> +#endif

Don't do this, we already require this header be present and working.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

2016-04-03 Thread Martin Vignali
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

Martin
Jokyo Images
From eb04d989eb53f81c225fb7ea6debf04a33fbb9c6 Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Sun, 3 Apr 2016 18:55:36 +0200
Subject: [PATCH] libavcodec/exr : add support for uint32.

---
 libavcodec/exr.c | 73 ++--
 1 file changed, 61 insertions(+), 12 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index b0573d5..45eb24a 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -154,6 +154,10 @@ typedef struct EXRContext {
 
 #define HALF_FLOAT_MAX_BIASED_EXP (0x1F << 10)
 
+#ifndef UINT32_MAX
+#define UINT32_MAX  (0x)
+#endif
+
 /**
  * Convert a half float as a uint16_t into a full float.
  *
@@ -1052,13 +1056,13 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 return AVERROR_INVALIDDATA;
 }
 }
-
+
 if (data_size < uncompressed_size || s->is_tile) { /* td->tmp is use for tile reorganization */
 av_fast_padded_malloc(>tmp, >tmp_size, uncompressed_size);
 if (!td->tmp)
 return AVERROR(ENOMEM);
 }
-
+
 if (data_size < uncompressed_size) {
 av_fast_padded_malloc(>uncompressed_data,
   >uncompressed_size, uncompressed_size);
@@ -1092,11 +1096,11 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 }
 src = td->uncompressed_data;
 }
-
+
 if (s->is_tile) {
 indexSrc = 0;
 channelLineSize = s->xsize * 2;
-if (s->pixel_type == EXR_FLOAT)
+if ((s->pixel_type == EXR_FLOAT)||(s->pixel_type == EXR_UINT))
 channelLineSize *= 2;
 
 /* reorganise tile data to have each channel one after the other instead of line by line */
@@ -1126,7 +1130,7 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 
 for (i = 0;
  i < s->ysize; i++, ptr += p->linesize[0]) {
-
+
 const uint8_t *r, *g, *b, *a;
 
 r = channel_buffer[0];
@@ -1181,7 +1185,7 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 *ptr_x++ = exr_flt2uint(bytestream_get_le32());
 }
 }
-} else {
+} else if (s->pixel_type == EXR_HALF) {
 // 16-bit
 for (x = 0; x < s->xsize; x++) {
 *ptr_x++ = s->gamma_table[bytestream_get_le16()];
@@ -1190,6 +1194,44 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 if (channel_buffer[3])
 *ptr_x++ = exr_halflt2uint(bytestream_get_le16());
 }
+} else {
+//UINT 32
+if (trc_func) {
+for (x = 0; x < s->xsize; x++) {
+union av_intfloat32 t;
+t.f = trc_func((float)bytestream_get_le32() / (float)UINT32_MAX);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.f = trc_func((float)bytestream_get_le32() / (float)UINT32_MAX);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.f = trc_func((float)bytestream_get_le32() / (float)UINT32_MAX);
+*ptr_x++ = exr_flt2uint(t.i);
+if (channel_buffer[3]){
+t.f = trc_func((float)bytestream_get_le32() / (float)UINT32_MAX);
+*ptr_x++ = exr_flt2uint(t.i);
+}
+}
+} else {
+for (x = 0; x < s->xsize; x++) {
+union av_intfloat32 t;
+t.f = (float)bytestream_get_le32() / (float)UINT32_MAX;
+t.f = powf(t.f, one_gamma);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.f = (float)bytestream_get_le32() / (float)UINT32_MAX;
+t.f = powf(t.f, one_gamma);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.f = (float)bytestream_get_le32() / (float)UINT32_MAX;
+t.f = powf(t.f, one_gamma);
+*ptr_x++ = exr_flt2uint(t.i);
+if (channel_buffer[3]){
+t.f = (float)bytestream_get_le32() / (float)UINT32_MAX;
+*ptr_x++ = exr_flt2uint(t.i);
+}
+}
+}
 }
 
 // Zero out the end if xmax+1 is not w
@@ -1210,7 +1252,6 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 channel_buffer[3] += s->scan_line_size;
 }