Re: [FFmpeg-devel] [PATCH] avcodec/exr: tag gamma=1.0 output as linear light

2023-08-20 Thread Tomas Härdin 
tor 2023-08-17 klockan 14:04 -0400 skrev Leo Izen:
> On 8/17/23 08:59, Tomas Härdin wrote:
> > ons 2023-08-16 klockan 01:20 -0400 skrev Leo Izen:
> > > By default the OpenEXR decoder outputs linear light pixel data by
> > > applying a gamma=1.0 transfer (i.e. a no-op). When it does so, it
> > > should tag the data as linear so color-managed filters or other
> > > tools
> > > can work with it correctly.
> > > 
> > > Signed-off-by: Leo Izen 
> > > ---
> > >   libavcodec/exr.c | 2 ++
> > >   1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> > > index fae1d08ab0..518066facf 100644
> > > --- a/libavcodec/exr.c
> > > +++ b/libavcodec/exr.c
> > > @@ -2088,6 +2088,8 @@ static int decode_frame(AVCodecContext
> > > *avctx,
> > > AVFrame *picture,
> > >   
> > >   if (s->apply_trc_type != AVCOL_TRC_UNSPECIFIED)
> > >   avctx->color_trc = s->apply_trc_type;
> > > +    else if (s->gamma > 0.f && s->gamma < 1.0001f)
> > > +    avctx->color_trc = AVCOL_TRC_LINEAR;
> > 
> > I'm going to be difficult here and point out that gamma=0.1 is
> > not
> > linear. It's probably linear *enough* most of the time, but also
> > 1.0
> > can be exactly represented by float so an equality check seems
> > appropriate.
> 
> This exact check exists elsewhere in the source file. There's a
> branch 
> where it sets up a LUT if gamma is not between those values, and has
> a 
> no-op track otherwise - so in the event you request 0.5 or
> something 
> of that form, the code that does the color conversion treats it as
> 1.0f.

Alright. I just find myself wondering how gamma could ever become some
value that is close to 1.0 but not quite equal.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: tag gamma=1.0 output as linear light

2023-08-17 Thread Leo Izen 

On 8/17/23 08:59, Tomas Härdin wrote:

ons 2023-08-16 klockan 01:20 -0400 skrev Leo Izen:

By default the OpenEXR decoder outputs linear light pixel data by
applying a gamma=1.0 transfer (i.e. a no-op). When it does so, it
should tag the data as linear so color-managed filters or other tools
can work with it correctly.

Signed-off-by: Leo Izen 
---
  libavcodec/exr.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index fae1d08ab0..518066facf 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -2088,6 +2088,8 @@ static int decode_frame(AVCodecContext *avctx,
AVFrame *picture,
  
  if (s->apply_trc_type != AVCOL_TRC_UNSPECIFIED)

  avctx->color_trc = s->apply_trc_type;
+    else if (s->gamma > 0.f && s->gamma < 1.0001f)
+    avctx->color_trc = AVCOL_TRC_LINEAR;


I'm going to be difficult here and point out that gamma=0.1 is not
linear. It's probably linear *enough* most of the time, but also 1.0
can be exactly represented by float so an equality check seems
appropriate.


This exact check exists elsewhere in the source file. There's a branch 
where it sets up a LUT if gamma is not between those values, and has a 
no-op track otherwise - so in the event you request 0.5 or something 
of that form, the code that does the color conversion treats it as 1.0f.


- Leo Izen


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: tag gamma=1.0 output as linear light

2023-08-17 Thread Tomas Härdin 
ons 2023-08-16 klockan 01:20 -0400 skrev Leo Izen:
> By default the OpenEXR decoder outputs linear light pixel data by
> applying a gamma=1.0 transfer (i.e. a no-op). When it does so, it
> should tag the data as linear so color-managed filters or other tools
> can work with it correctly.
> 
> Signed-off-by: Leo Izen 
> ---
>  libavcodec/exr.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> index fae1d08ab0..518066facf 100644
> --- a/libavcodec/exr.c
> +++ b/libavcodec/exr.c
> @@ -2088,6 +2088,8 @@ static int decode_frame(AVCodecContext *avctx,
> AVFrame *picture,
>  
>  if (s->apply_trc_type != AVCOL_TRC_UNSPECIFIED)
>  avctx->color_trc = s->apply_trc_type;
> +    else if (s->gamma > 0.f && s->gamma < 1.0001f)
> +    avctx->color_trc = AVCOL_TRC_LINEAR;

I'm going to be difficult here and point out that gamma=0.1 is not
linear. It's probably linear *enough* most of the time, but also 1.0
can be exactly represented by float so an equality check seems
appropriate

/Tomas

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: tag gamma=1.0 output as linear light

2023-08-16 Thread Paul B Mahol 
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/exr: tag gamma=1.0 output as linear light

2023-08-15 Thread Leo Izen 
By default the OpenEXR decoder outputs linear light pixel data by
applying a gamma=1.0 transfer (i.e. a no-op). When it does so, it
should tag the data as linear so color-managed filters or other tools
can work with it correctly.

Signed-off-by: Leo Izen 
---
 libavcodec/exr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index fae1d08ab0..518066facf 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -2088,6 +2088,8 @@ static int decode_frame(AVCodecContext *avctx, AVFrame 
*picture,
 
 if (s->apply_trc_type != AVCOL_TRC_UNSPECIFIED)
 avctx->color_trc = s->apply_trc_type;
+else if (s->gamma > 0.f && s->gamma < 1.0001f)
+avctx->color_trc = AVCOL_TRC_LINEAR;
 
 switch (s->compression) {
 case EXR_RAW:
-- 
2.41.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: More strictly check dc_count

2021-05-27 Thread Michael Niedermayer 
On Tue, May 25, 2021 at 10:22:02PM +0200, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes: exr/deneme
> 
> Found-by: Burak Çarıkçı 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/exr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/exr: More strictly check dc_count

2021-05-25 Thread Michael Niedermayer 
Fixes: out of array access
Fixes: exr/deneme

Found-by: Burak Çarıkçı 
Signed-off-by: Michael Niedermayer 
---
 libavcodec/exr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 9377a89169..4648ed7d62 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1059,11 +1059,11 @@ static int dwa_uncompress(EXRContext *s, const uint8_t 
*src, int compressed_size
 bytestream2_skip(, ac_size);
 }
 
-if (dc_size > 0) {
+{
 unsigned long dest_len = dc_count * 2LL;
 GetByteContext agb = gb;
 
-if (dc_count > (6LL * td->xsize * td->ysize + 63) / 64)
+if (dc_count != dc_w * dc_h * 3)
 return AVERROR_INVALIDDATA;
 
 av_fast_padded_malloc(>dc_data, >dc_size, FFALIGN(dest_len, 
64) * 2);
-- 
2.17.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: simplify piz decompression

2021-02-23 Thread Paul B Mahol 
will apply soon
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: simplify piz decompression

2021-02-20 Thread Paul B Mahol 
On Sat, Feb 20, 2021 at 11:11 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:

> Paul B Mahol:
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavcodec/exr.c | 212 +++
> >  1 file changed, 65 insertions(+), 147 deletions(-)
> >
> > diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> > index cacdff5774..625ee4680c 100644
> > --- a/libavcodec/exr.c
> > +++ b/libavcodec/exr.c
> > @@ -91,6 +91,12 @@ enum ExrTileLevelRound {
> >  EXR_TILE_ROUND_UNKNOWN,
> >  };
> >
> > +typedef struct HuffEntry {
> > +uint8_t  len;
> > +uint16_t sym;
> > +uint16_t code;
>
> The old code allowed codes with a length of <= 58. This is more than our
> VLC-API allows and even more than fits into a 16-bit code. You seem to
> believe that all codes have a length <= 16 just because HUF_ENCBITS is
> 16. But this is wrong: It just means that there are at most 1<<16
> ordinary symbols and one special symbol for runs. It also means that we
> can't even distinguish all possible symbols because VLC_TYPE is 16 bits.
>

Fixed to use 32bits code, also added messages to ask for sample if more is
needed.


> > +} HuffEntry;
> > +
> >  typedef struct EXRChannel {
> >  int xsub, ysub;
> >  enum ExrPixelType pixel_type;
> > @@ -116,6 +122,11 @@ typedef struct EXRThreadData {
> >  int ysize, xsize;
> >
> >  int channel_line_size;
> > +
> > +uint16_t run_sym;
> > +HuffEntry *he;
> > +uint64_t *freq;
> > +VLC vlc;
> >  } EXRThreadData;
> >
> >  typedef struct EXRContext {
> > @@ -319,11 +330,8 @@ static void apply_lut(const uint16_t *lut, uint16_t
> *dst, int dsize)
> >  }
> >
> >  #define HUF_ENCBITS 16  // literal (value) bit length
> > -#define HUF_DECBITS 14  // decoding bit size (>= 8)
> >
> >  #define HUF_ENCSIZE ((1 << HUF_ENCBITS) + 1)  // encoding table size
> > -#define HUF_DECSIZE (1 << HUF_DECBITS)// decoding table size
> > -#define HUF_DECMASK (HUF_DECSIZE - 1)
> >
> >  typedef struct HufDec {
> >  int len;
> > @@ -336,7 +344,7 @@ static void huf_canonical_code_table(uint64_t *hcode)
> >  uint64_t c, n[59] = { 0 };
> >  int i;
> >
> > -for (i = 0; i < HUF_ENCSIZE; ++i)
> > +for (i = 0; i < HUF_ENCSIZE; i++)
>
> Spurious change.
>
> >  n[hcode[i]] += 1;
> >
> >  c = 0;
> > @@ -399,149 +407,63 @@ static int huf_unpack_enc_table(GetByteContext
> *gb,
> >  return 0;
> >  }
> >
> > -static int huf_build_dec_table(const uint64_t *hcode, int im,
> > -   int iM, HufDec *hdecod)
> > +static int huf_build_dec_table(EXRThreadData *td, int im, int iM)
> >  {
> > -for (; im <= iM; im++) {
> > -uint64_t c = hcode[im] >> 6;
> > -int i, l = hcode[im] & 63;
> > -
> > -if (c >> l)
> > -return AVERROR_INVALIDDATA;
> > -
> > -if (l > HUF_DECBITS) {
> > -HufDec *pl = hdecod + (c >> (l - HUF_DECBITS));
> > -if (pl->len)
> > -return AVERROR_INVALIDDATA;
> > -
> > -pl->lit++;
> > -
> > -pl->p = av_realloc(pl->p, pl->lit * sizeof(int));
> > -if (!pl->p)
> > -return AVERROR(ENOMEM);
> > -
> > -pl->p[pl->lit - 1] = im;
> > -} else if (l) {
> > -HufDec *pl = hdecod + (c << (HUF_DECBITS - l));
> > -
> > -for (i = 1 << (HUF_DECBITS - l); i > 0; i--, pl++) {
> > -if (pl->len || pl->p)
> > -return AVERROR_INVALIDDATA;
> > -pl->len = l;
> > -pl->lit = im;
> > -}
> > -}
> > +int j = 0;
> > +
> > +for (int i = im; i < iM; i++) {
> > +td->he[j].sym = i;
> > +td->he[j].len = td->freq[i] & 63;
> > +td->he[j].code = td->freq[i] >> 6;> +if (td->he[j].len
> > 0)
> > +j++;
> > +else
> > +td->run_sym = i;
> >  }
> >
> > -return 0;
> > -}
> > -
> > -#define get_char(c, lc, gb)
>\
> > -{
>\
> > -c   = (c << 8) | bytestream2_get_byte(gb);
>   \
> > -lc += 8;
>   \
> > -}
> > +td->he[j].sym = td->run_sym;
> > +td->he[j].len = td->freq[iM] & 63;
> > +td->he[j].code = td->freq[iM] >> 6;
> > +j++;
> >
> > -#define get_code(po, rlc, c, lc, gb, out, oe, outb)
>\
> > -{
>\
> > -if (po == rlc) {
>   \
> > -if (lc < 8)
>\
> > -get_char(c, lc, gb);
>   \
> > -lc -= 8;
>   \
> > -
>   \
> > -cs = c >> lc;
>\
> > -
>   \
> > -if (out + cs > oe || out == outb)
>\
> > -return AVERROR_INVALIDDATA;
>\
> > -
>   \
> > -s = out[-1];
>   \
> > -
>   \
> > -while (cs-- > 0)
>   \
> > -*out++ = s;
>\
> > -} else if (out < oe) {
>   \
> > -*out++ = po;
>   \
> > -} else {
>   \

[FFmpeg-devel] [PATCH] avcodec/exr: simplify piz decompression

2021-02-20 Thread Paul B Mahol 
Note that >32 codes are no longer supported, give
proper error code if such scenario ever happens.

Signed-off-by: Paul B Mahol 
---
 libavcodec/exr.c | 251 +--
 1 file changed, 89 insertions(+), 162 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index cacdff5774..5f99d9d5ab 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -91,6 +91,12 @@ enum ExrTileLevelRound {
 EXR_TILE_ROUND_UNKNOWN,
 };
 
+typedef struct HuffEntry {
+uint8_t  len;
+uint16_t sym;
+uint32_t code;
+} HuffEntry;
+
 typedef struct EXRChannel {
 int xsub, ysub;
 enum ExrPixelType pixel_type;
@@ -116,6 +122,11 @@ typedef struct EXRThreadData {
 int ysize, xsize;
 
 int channel_line_size;
+
+int run_sym;
+HuffEntry *he;
+uint64_t *freq;
+VLC vlc;
 } EXRThreadData;
 
 typedef struct EXRContext {
@@ -319,25 +330,15 @@ static void apply_lut(const uint16_t *lut, uint16_t *dst, 
int dsize)
 }
 
 #define HUF_ENCBITS 16  // literal (value) bit length
-#define HUF_DECBITS 14  // decoding bit size (>= 8)
-
 #define HUF_ENCSIZE ((1 << HUF_ENCBITS) + 1)  // encoding table size
-#define HUF_DECSIZE (1 << HUF_DECBITS)// decoding table size
-#define HUF_DECMASK (HUF_DECSIZE - 1)
 
-typedef struct HufDec {
-int len;
-int lit;
-int *p;
-} HufDec;
-
-static void huf_canonical_code_table(uint64_t *hcode)
+static void huf_canonical_code_table(uint64_t *freq)
 {
 uint64_t c, n[59] = { 0 };
 int i;
 
-for (i = 0; i < HUF_ENCSIZE; ++i)
-n[hcode[i]] += 1;
+for (i = 0; i < HUF_ENCSIZE; i++)
+n[freq[i]] += 1;
 
 c = 0;
 for (i = 58; i > 0; --i) {
@@ -347,10 +348,10 @@ static void huf_canonical_code_table(uint64_t *hcode)
 }
 
 for (i = 0; i < HUF_ENCSIZE; ++i) {
-int l = hcode[i];
+int l = freq[i];
 
 if (l > 0)
-hcode[i] = l | (n[l]++ << 6);
+freq[i] = l | (n[l]++ << 6);
 }
 }
 
@@ -360,7 +361,7 @@ static void huf_canonical_code_table(uint64_t *hcode)
 #define LONGEST_LONG_RUN(255 + SHORTEST_LONG_RUN)
 
 static int huf_unpack_enc_table(GetByteContext *gb,
-int32_t im, int32_t iM, uint64_t *hcode)
+int32_t im, int32_t iM, uint64_t *freq)
 {
 GetBitContext gbit;
 int ret = init_get_bits8(, gb->buffer, 
bytestream2_get_bytes_left(gb));
@@ -368,7 +369,7 @@ static int huf_unpack_enc_table(GetByteContext *gb,
 return ret;
 
 for (; im <= iM; im++) {
-uint64_t l = hcode[im] = get_bits(, 6);
+uint64_t l = freq[im] = get_bits(, 6);
 
 if (l == LONG_ZEROCODE_RUN) {
 int zerun = get_bits(, 8) + SHORTEST_LONG_RUN;
@@ -377,7 +378,7 @@ static int huf_unpack_enc_table(GetByteContext *gb,
 return AVERROR_INVALIDDATA;
 
 while (zerun--)
-hcode[im++] = 0;
+freq[im++] = 0;
 
 im--;
 } else if (l >= SHORT_ZEROCODE_RUN) {
@@ -387,161 +388,91 @@ static int huf_unpack_enc_table(GetByteContext *gb,
 return AVERROR_INVALIDDATA;
 
 while (zerun--)
-hcode[im++] = 0;
+freq[im++] = 0;
 
 im--;
 }
 }
 
 bytestream2_skip(gb, (get_bits_count() + 7) / 8);
-huf_canonical_code_table(hcode);
+huf_canonical_code_table(freq);
 
 return 0;
 }
 
-static int huf_build_dec_table(const uint64_t *hcode, int im,
-   int iM, HufDec *hdecod)
+static int huf_build_dec_table(EXRContext *s,
+   EXRThreadData *td, int im, int iM)
 {
-for (; im <= iM; im++) {
-uint64_t c = hcode[im] >> 6;
-int i, l = hcode[im] & 63;
-
-if (c >> l)
-return AVERROR_INVALIDDATA;
-
-if (l > HUF_DECBITS) {
-HufDec *pl = hdecod + (c >> (l - HUF_DECBITS));
-if (pl->len)
-return AVERROR_INVALIDDATA;
-
-pl->lit++;
-
-pl->p = av_realloc(pl->p, pl->lit * sizeof(int));
-if (!pl->p)
-return AVERROR(ENOMEM);
-
-pl->p[pl->lit - 1] = im;
-} else if (l) {
-HufDec *pl = hdecod + (c << (HUF_DECBITS - l));
-
-for (i = 1 << (HUF_DECBITS - l); i > 0; i--, pl++) {
-if (pl->len || pl->p)
-return AVERROR_INVALIDDATA;
-pl->len = l;
-pl->lit = im;
-}
+int j = 0;
+
+td->run_sym = -1;
+for (int i = im; i < iM; i++) {
+td->he[j].sym = i;
+td->he[j].len = td->freq[i] & 63;
+td->he[j].code = td->freq[i] >> 6;
+if (td->he[j].len > 32) {
+avpriv_request_sample(s->avctx, "Too big code length");
+return AVERROR_PATCHWELCOME;
 }
+if (td->he[j].len > 0)
+j++;
+else
+td->run_sym = i;
 }
 
-return 0;
-}
-

Re: [FFmpeg-devel] [PATCH] avcodec/exr: simplify piz decompression

2021-02-20 Thread Andreas Rheinhardt 
Paul B Mahol:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/exr.c | 212 +++
>  1 file changed, 65 insertions(+), 147 deletions(-)
> 
> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> index cacdff5774..625ee4680c 100644
> --- a/libavcodec/exr.c
> +++ b/libavcodec/exr.c
> @@ -91,6 +91,12 @@ enum ExrTileLevelRound {
>  EXR_TILE_ROUND_UNKNOWN,
>  };
>  
> +typedef struct HuffEntry {
> +uint8_t  len;
> +uint16_t sym;
> +uint16_t code;

The old code allowed codes with a length of <= 58. This is more than our
VLC-API allows and even more than fits into a 16-bit code. You seem to
believe that all codes have a length <= 16 just because HUF_ENCBITS is
16. But this is wrong: It just means that there are at most 1<<16
ordinary symbols and one special symbol for runs. It also means that we
can't even distinguish all possible symbols because VLC_TYPE is 16 bits.

> +} HuffEntry;
> +
>  typedef struct EXRChannel {
>  int xsub, ysub;
>  enum ExrPixelType pixel_type;
> @@ -116,6 +122,11 @@ typedef struct EXRThreadData {
>  int ysize, xsize;
>  
>  int channel_line_size;
> +
> +uint16_t run_sym;
> +HuffEntry *he;
> +uint64_t *freq;
> +VLC vlc;
>  } EXRThreadData;
>  
>  typedef struct EXRContext {
> @@ -319,11 +330,8 @@ static void apply_lut(const uint16_t *lut, uint16_t 
> *dst, int dsize)
>  }
>  
>  #define HUF_ENCBITS 16  // literal (value) bit length
> -#define HUF_DECBITS 14  // decoding bit size (>= 8)
>  
>  #define HUF_ENCSIZE ((1 << HUF_ENCBITS) + 1)  // encoding table size
> -#define HUF_DECSIZE (1 << HUF_DECBITS)// decoding table size
> -#define HUF_DECMASK (HUF_DECSIZE - 1)
>  
>  typedef struct HufDec {
>  int len;
> @@ -336,7 +344,7 @@ static void huf_canonical_code_table(uint64_t *hcode)
>  uint64_t c, n[59] = { 0 };
>  int i;
>  
> -for (i = 0; i < HUF_ENCSIZE; ++i)
> +for (i = 0; i < HUF_ENCSIZE; i++)

Spurious change.

>  n[hcode[i]] += 1;
>  
>  c = 0;
> @@ -399,149 +407,63 @@ static int huf_unpack_enc_table(GetByteContext *gb,
>  return 0;
>  }
>  
> -static int huf_build_dec_table(const uint64_t *hcode, int im,
> -   int iM, HufDec *hdecod)
> +static int huf_build_dec_table(EXRThreadData *td, int im, int iM)
>  {
> -for (; im <= iM; im++) {
> -uint64_t c = hcode[im] >> 6;
> -int i, l = hcode[im] & 63;
> -
> -if (c >> l)
> -return AVERROR_INVALIDDATA;
> -
> -if (l > HUF_DECBITS) {
> -HufDec *pl = hdecod + (c >> (l - HUF_DECBITS));
> -if (pl->len)
> -return AVERROR_INVALIDDATA;
> -
> -pl->lit++;
> -
> -pl->p = av_realloc(pl->p, pl->lit * sizeof(int));
> -if (!pl->p)
> -return AVERROR(ENOMEM);
> -
> -pl->p[pl->lit - 1] = im;
> -} else if (l) {
> -HufDec *pl = hdecod + (c << (HUF_DECBITS - l));
> -
> -for (i = 1 << (HUF_DECBITS - l); i > 0; i--, pl++) {
> -if (pl->len || pl->p)
> -return AVERROR_INVALIDDATA;
> -pl->len = l;
> -pl->lit = im;
> -}
> -}
> +int j = 0;
> +
> +for (int i = im; i < iM; i++) {
> +td->he[j].sym = i;
> +td->he[j].len = td->freq[i] & 63;
> +td->he[j].code = td->freq[i] >> 6;> +if (td->he[j].len > 0)
> +j++;
> +else
> +td->run_sym = i;
>  }
>  
> -return 0;
> -}
> -
> -#define get_char(c, lc, gb)  
>  \
> -{
>  \
> -c   = (c << 8) | bytestream2_get_byte(gb);   
>  \
> -lc += 8; 
>  \
> -}
> +td->he[j].sym = td->run_sym;
> +td->he[j].len = td->freq[iM] & 63;
> +td->he[j].code = td->freq[iM] >> 6;
> +j++;
>  
> -#define get_code(po, rlc, c, lc, gb, out, oe, outb)  
>  \
> -{
>  \
> -if (po == rlc) { 
>  \
> -if (lc < 8)  
>  \
> -get_char(c, lc, gb); 
>  \
> -lc -= 8; 
>  \
> - 
>  \
> -cs = c >> lc;
>  \
> - 
>  \
> -if (out + cs > oe || out == outb)
>  \
> -return AVERROR_INVALIDDATA;  
>  \

[FFmpeg-devel] [PATCH] avcodec/exr: simplify piz decompression

2021-02-19 Thread Paul B Mahol 
Signed-off-by: Paul B Mahol 
---
 libavcodec/exr.c | 212 +++
 1 file changed, 65 insertions(+), 147 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index cacdff5774..625ee4680c 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -91,6 +91,12 @@ enum ExrTileLevelRound {
 EXR_TILE_ROUND_UNKNOWN,
 };
 
+typedef struct HuffEntry {
+uint8_t  len;
+uint16_t sym;
+uint16_t code;
+} HuffEntry;
+
 typedef struct EXRChannel {
 int xsub, ysub;
 enum ExrPixelType pixel_type;
@@ -116,6 +122,11 @@ typedef struct EXRThreadData {
 int ysize, xsize;
 
 int channel_line_size;
+
+uint16_t run_sym;
+HuffEntry *he;
+uint64_t *freq;
+VLC vlc;
 } EXRThreadData;
 
 typedef struct EXRContext {
@@ -319,11 +330,8 @@ static void apply_lut(const uint16_t *lut, uint16_t *dst, 
int dsize)
 }
 
 #define HUF_ENCBITS 16  // literal (value) bit length
-#define HUF_DECBITS 14  // decoding bit size (>= 8)
 
 #define HUF_ENCSIZE ((1 << HUF_ENCBITS) + 1)  // encoding table size
-#define HUF_DECSIZE (1 << HUF_DECBITS)// decoding table size
-#define HUF_DECMASK (HUF_DECSIZE - 1)
 
 typedef struct HufDec {
 int len;
@@ -336,7 +344,7 @@ static void huf_canonical_code_table(uint64_t *hcode)
 uint64_t c, n[59] = { 0 };
 int i;
 
-for (i = 0; i < HUF_ENCSIZE; ++i)
+for (i = 0; i < HUF_ENCSIZE; i++)
 n[hcode[i]] += 1;
 
 c = 0;
@@ -399,149 +407,63 @@ static int huf_unpack_enc_table(GetByteContext *gb,
 return 0;
 }
 
-static int huf_build_dec_table(const uint64_t *hcode, int im,
-   int iM, HufDec *hdecod)
+static int huf_build_dec_table(EXRThreadData *td, int im, int iM)
 {
-for (; im <= iM; im++) {
-uint64_t c = hcode[im] >> 6;
-int i, l = hcode[im] & 63;
-
-if (c >> l)
-return AVERROR_INVALIDDATA;
-
-if (l > HUF_DECBITS) {
-HufDec *pl = hdecod + (c >> (l - HUF_DECBITS));
-if (pl->len)
-return AVERROR_INVALIDDATA;
-
-pl->lit++;
-
-pl->p = av_realloc(pl->p, pl->lit * sizeof(int));
-if (!pl->p)
-return AVERROR(ENOMEM);
-
-pl->p[pl->lit - 1] = im;
-} else if (l) {
-HufDec *pl = hdecod + (c << (HUF_DECBITS - l));
-
-for (i = 1 << (HUF_DECBITS - l); i > 0; i--, pl++) {
-if (pl->len || pl->p)
-return AVERROR_INVALIDDATA;
-pl->len = l;
-pl->lit = im;
-}
-}
+int j = 0;
+
+for (int i = im; i < iM; i++) {
+td->he[j].sym = i;
+td->he[j].len = td->freq[i] & 63;
+td->he[j].code = td->freq[i] >> 6;
+if (td->he[j].len > 0)
+j++;
+else
+td->run_sym = i;
 }
 
-return 0;
-}
-
-#define get_char(c, lc, gb)   \
-{ \
-c   = (c << 8) | bytestream2_get_byte(gb);\
-lc += 8;  \
-}
+td->he[j].sym = td->run_sym;
+td->he[j].len = td->freq[iM] & 63;
+td->he[j].code = td->freq[iM] >> 6;
+j++;
 
-#define get_code(po, rlc, c, lc, gb, out, oe, outb)   \
-{ \
-if (po == rlc) {  \
-if (lc < 8)   \
-get_char(c, lc, gb);  \
-lc -= 8;  \
-  \
-cs = c >> lc; \
-  \
-if (out + cs > oe || out == outb) \
-return AVERROR_INVALIDDATA;   \
-  \
-s = out[-1];  \
-  \
-while (cs-- > 0)  \
-*out++ = s;   \
-} else if (out < oe) {\
-*out++ = po;  \
-} else {  \
-return AVERROR_INVALIDDATA;   \
-}

[FFmpeg-devel] [PATCH] avcodec/exr: simplify piz decompression

2021-02-19 Thread Paul B Mahol 
Signed-off-by: Paul B Mahol 
---
 libavcodec/exr.c | 209 ++-
 1 file changed, 63 insertions(+), 146 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index cacdff5774..9d86f6ea43 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -91,6 +91,12 @@ enum ExrTileLevelRound {
 EXR_TILE_ROUND_UNKNOWN,
 };
 
+typedef struct HuffEntry {
+uint8_t  len;
+uint16_t sym;
+uint16_t code;
+} HuffEntry;
+
 typedef struct EXRChannel {
 int xsub, ysub;
 enum ExrPixelType pixel_type;
@@ -116,6 +122,11 @@ typedef struct EXRThreadData {
 int ysize, xsize;
 
 int channel_line_size;
+
+uint16_t run_sym;
+HuffEntry *he;
+uint64_t *freq;
+VLC vlc;
 } EXRThreadData;
 
 typedef struct EXRContext {
@@ -319,11 +330,8 @@ static void apply_lut(const uint16_t *lut, uint16_t *dst, 
int dsize)
 }
 
 #define HUF_ENCBITS 16  // literal (value) bit length
-#define HUF_DECBITS 14  // decoding bit size (>= 8)
 
 #define HUF_ENCSIZE ((1 << HUF_ENCBITS) + 1)  // encoding table size
-#define HUF_DECSIZE (1 << HUF_DECBITS)// decoding table size
-#define HUF_DECMASK (HUF_DECSIZE - 1)
 
 typedef struct HufDec {
 int len;
@@ -399,149 +407,63 @@ static int huf_unpack_enc_table(GetByteContext *gb,
 return 0;
 }
 
-static int huf_build_dec_table(const uint64_t *hcode, int im,
-   int iM, HufDec *hdecod)
+static int huf_build_dec_table(EXRThreadData *td, int im, int iM)
 {
-for (; im <= iM; im++) {
-uint64_t c = hcode[im] >> 6;
-int i, l = hcode[im] & 63;
-
-if (c >> l)
-return AVERROR_INVALIDDATA;
-
-if (l > HUF_DECBITS) {
-HufDec *pl = hdecod + (c >> (l - HUF_DECBITS));
-if (pl->len)
-return AVERROR_INVALIDDATA;
-
-pl->lit++;
-
-pl->p = av_realloc(pl->p, pl->lit * sizeof(int));
-if (!pl->p)
-return AVERROR(ENOMEM);
-
-pl->p[pl->lit - 1] = im;
-} else if (l) {
-HufDec *pl = hdecod + (c << (HUF_DECBITS - l));
-
-for (i = 1 << (HUF_DECBITS - l); i > 0; i--, pl++) {
-if (pl->len || pl->p)
-return AVERROR_INVALIDDATA;
-pl->len = l;
-pl->lit = im;
-}
-}
+int j = 0;
+
+for (int i = im; i < iM; i++) {
+td->he[j].sym = i;
+td->he[j].len = td->freq[i] & 63;
+td->he[j].code = td->freq[i] >> 6;
+if (td->he[j].len > 0)
+j++;
+else
+td->run_sym = i;
 }
 
-return 0;
-}
-
-#define get_char(c, lc, gb)   \
-{ \
-c   = (c << 8) | bytestream2_get_byte(gb);\
-lc += 8;  \
-}
+td->he[j].sym = td->run_sym;
+td->he[j].len = td->freq[iM] & 63;
+td->he[j].code = td->freq[iM] >> 6;
+j++;
 
-#define get_code(po, rlc, c, lc, gb, out, oe, outb)   \
-{ \
-if (po == rlc) {  \
-if (lc < 8)   \
-get_char(c, lc, gb);  \
-lc -= 8;  \
-  \
-cs = c >> lc; \
-  \
-if (out + cs > oe || out == outb) \
-return AVERROR_INVALIDDATA;   \
-  \
-s = out[-1];  \
-  \
-while (cs-- > 0)  \
-*out++ = s;   \
-} else if (out < oe) {\
-*out++ = po;  \
-} else {  \
-return AVERROR_INVALIDDATA;   \
-} \
+ff_free_vlc(>vlc);
+return ff_init_vlc_sparse(>vlc, 12, j,
+  >he[0].len, sizeof(td->he[0]), 
sizeof(td->he[0].len),
+

Re: [FFmpeg-devel] [PATCH] avcodec/exr: preserve half-float NaN bits and add fate test

2020-12-07 Thread Paul B Mahol 
On Sun, Dec 6, 2020 at 4:20 AM Mark Reid  wrote:

> On Sun, Nov 22, 2020 at 8:32 PM  wrote:
>
> > From: Mark Reid 
> >
> > Hi,
> > This patch handles NaNs more like the offical implentation handles them,
> > preserving
> > the original bits.
> >
> >
> >
> https://github.com/AcademySoftwareFoundation/openexr/blob/RB-2.5/IlmBase/Half/toFloat.cpp#L111
> >
> > It also adds a fate test that is a 256x256 exr containing all possible
> > 16bit half-float values.
> >
> > Here is a link to download the fate test file, if someone could add it to
> > fate me
> >
> >
> https://www.dropbox.com/s/2q4jg8w489aunsf/rgb_scanline_zip_half_float_0x0_to_0x.exr
> >
> > ---
> >  libavcodec/exr.c| 3 +--
> >  tests/fate/image.mak| 2 ++
> >  tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x | 6 ++
> >  3 files changed, 9 insertions(+), 2 deletions(-)
> >  create mode 100644 tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x
> >
> > diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> > index d233dd43fb..6e6ce4275c 100644
> > --- a/libavcodec/exr.c
> > +++ b/libavcodec/exr.c
> > @@ -193,8 +193,7 @@ static union av_intfloat32 exr_half2float(uint16_t
> hf)
> >  // half-float NaNs will be converted to a single precision NaN
> >  // half-float Infs will be converted to a single precision Inf
> >  exp = FLOAT_MAX_BIASED_EXP;
> > -if (mantissa)
> > -mantissa = (1 << 23) - 1;// set all bits to indicate a
> NaN
> > +mantissa <<= 13; // preserve half-float NaN bits if set
> >  } else if (exp == 0x0) {
> >  // convert half-float zero/denorm to single precision value
> >  if (mantissa) {
> > diff --git a/tests/fate/image.mak b/tests/fate/image.mak
> > index 22072a62f1..c453f0f79c 100644
> > --- a/tests/fate/image.mak
> > +++ b/tests/fate/image.mak
> > @@ -317,6 +317,8 @@ fate-exr-rgb-scanline-half-zip-dw-outside: CMD =
> > framecrc -i $(TARGET_SAMPLES)/e
> >  FATE_EXR += fate-exr-rgb-tile-half-zip-dw-outside
> >  fate-exr-rgb-tile-half-zip-dw-outside: CMD = framecrc -i
> > $(TARGET_SAMPLES)/exr/rgb_tile_half_zip_dw_outside.exr -pix_fmt gbrpf32le
> >
> > +FATE_EXR += fate-exr-rgb-scanline-zip-half-0x0-0x
> > +fate-exr-rgb-scanline-zip-half-0x0-0x: CMD = framecrc -i
> > $(TARGET_SAMPLES)/exr/rgb_scanline_zip_half_float_0x0_to_0x.exr
> > -pix_fmt gbrpf32le
> >
> >  FATE_EXR-$(call DEMDEC, IMAGE2, EXR) += $(FATE_EXR)
> >
> > diff --git a/tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x
> > b/tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x
> > new file mode 100644
> > index 00..b6201116fe
> > --- /dev/null
> > +++ b/tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x
> > @@ -0,0 +1,6 @@
> > +#tb 0: 1/25
> > +#media_type 0: video
> > +#codec_id 0: rawvideo
> > +#dimensions 0: 256x256
> > +#sar 0: 1/1
> > +0,  0,  0,1,   786432, 0x1445e411
> > --
> > 2.29.2
> >
> >
> ping
>

Uploaded sample to server.
Will apply in the next 48h.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: preserve half-float NaN bits and add fate test

2020-12-05 Thread Mark Reid 
On Sun, Nov 22, 2020 at 8:32 PM  wrote:

> From: Mark Reid 
>
> Hi,
> This patch handles NaNs more like the offical implentation handles them,
> preserving
> the original bits.
>
>
> https://github.com/AcademySoftwareFoundation/openexr/blob/RB-2.5/IlmBase/Half/toFloat.cpp#L111
>
> It also adds a fate test that is a 256x256 exr containing all possible
> 16bit half-float values.
>
> Here is a link to download the fate test file, if someone could add it to
> fate me
>
> https://www.dropbox.com/s/2q4jg8w489aunsf/rgb_scanline_zip_half_float_0x0_to_0x.exr
>
> ---
>  libavcodec/exr.c| 3 +--
>  tests/fate/image.mak| 2 ++
>  tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x | 6 ++
>  3 files changed, 9 insertions(+), 2 deletions(-)
>  create mode 100644 tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x
>
> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> index d233dd43fb..6e6ce4275c 100644
> --- a/libavcodec/exr.c
> +++ b/libavcodec/exr.c
> @@ -193,8 +193,7 @@ static union av_intfloat32 exr_half2float(uint16_t hf)
>  // half-float NaNs will be converted to a single precision NaN
>  // half-float Infs will be converted to a single precision Inf
>  exp = FLOAT_MAX_BIASED_EXP;
> -if (mantissa)
> -mantissa = (1 << 23) - 1;// set all bits to indicate a NaN
> +mantissa <<= 13; // preserve half-float NaN bits if set
>  } else if (exp == 0x0) {
>  // convert half-float zero/denorm to single precision value
>  if (mantissa) {
> diff --git a/tests/fate/image.mak b/tests/fate/image.mak
> index 22072a62f1..c453f0f79c 100644
> --- a/tests/fate/image.mak
> +++ b/tests/fate/image.mak
> @@ -317,6 +317,8 @@ fate-exr-rgb-scanline-half-zip-dw-outside: CMD =
> framecrc -i $(TARGET_SAMPLES)/e
>  FATE_EXR += fate-exr-rgb-tile-half-zip-dw-outside
>  fate-exr-rgb-tile-half-zip-dw-outside: CMD = framecrc -i
> $(TARGET_SAMPLES)/exr/rgb_tile_half_zip_dw_outside.exr -pix_fmt gbrpf32le
>
> +FATE_EXR += fate-exr-rgb-scanline-zip-half-0x0-0x
> +fate-exr-rgb-scanline-zip-half-0x0-0x: CMD = framecrc -i
> $(TARGET_SAMPLES)/exr/rgb_scanline_zip_half_float_0x0_to_0x.exr
> -pix_fmt gbrpf32le
>
>  FATE_EXR-$(call DEMDEC, IMAGE2, EXR) += $(FATE_EXR)
>
> diff --git a/tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x
> b/tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x
> new file mode 100644
> index 00..b6201116fe
> --- /dev/null
> +++ b/tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x
> @@ -0,0 +1,6 @@
> +#tb 0: 1/25
> +#media_type 0: video
> +#codec_id 0: rawvideo
> +#dimensions 0: 256x256
> +#sar 0: 1/1
> +0,  0,  0,1,   786432, 0x1445e411
> --
> 2.29.2
>
>
ping
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/exr: preserve half-float NaN bits and add fate test

2020-11-22 Thread mindmark 
From: Mark Reid 

Hi,
This patch handles NaNs more like the offical implentation handles them, 
preserving
the original bits.

https://github.com/AcademySoftwareFoundation/openexr/blob/RB-2.5/IlmBase/Half/toFloat.cpp#L111

It also adds a fate test that is a 256x256 exr containing all possible 16bit 
half-float values. 

Here is a link to download the fate test file, if someone could add it to fate 
me
https://www.dropbox.com/s/2q4jg8w489aunsf/rgb_scanline_zip_half_float_0x0_to_0x.exr

---
 libavcodec/exr.c| 3 +--
 tests/fate/image.mak| 2 ++
 tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x | 6 ++
 3 files changed, 9 insertions(+), 2 deletions(-)
 create mode 100644 tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index d233dd43fb..6e6ce4275c 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -193,8 +193,7 @@ static union av_intfloat32 exr_half2float(uint16_t hf)
 // half-float NaNs will be converted to a single precision NaN
 // half-float Infs will be converted to a single precision Inf
 exp = FLOAT_MAX_BIASED_EXP;
-if (mantissa)
-mantissa = (1 << 23) - 1;// set all bits to indicate a NaN
+mantissa <<= 13; // preserve half-float NaN bits if set
 } else if (exp == 0x0) {
 // convert half-float zero/denorm to single precision value
 if (mantissa) {
diff --git a/tests/fate/image.mak b/tests/fate/image.mak
index 22072a62f1..c453f0f79c 100644
--- a/tests/fate/image.mak
+++ b/tests/fate/image.mak
@@ -317,6 +317,8 @@ fate-exr-rgb-scanline-half-zip-dw-outside: CMD = framecrc 
-i $(TARGET_SAMPLES)/e
 FATE_EXR += fate-exr-rgb-tile-half-zip-dw-outside
 fate-exr-rgb-tile-half-zip-dw-outside: CMD = framecrc -i 
$(TARGET_SAMPLES)/exr/rgb_tile_half_zip_dw_outside.exr -pix_fmt gbrpf32le
 
+FATE_EXR += fate-exr-rgb-scanline-zip-half-0x0-0x
+fate-exr-rgb-scanline-zip-half-0x0-0x: CMD = framecrc -i 
$(TARGET_SAMPLES)/exr/rgb_scanline_zip_half_float_0x0_to_0x.exr -pix_fmt 
gbrpf32le
 
 FATE_EXR-$(call DEMDEC, IMAGE2, EXR) += $(FATE_EXR)
 
diff --git a/tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x 
b/tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x
new file mode 100644
index 00..b6201116fe
--- /dev/null
+++ b/tests/ref/fate/exr-rgb-scanline-zip-half-0x0-0x
@@ -0,0 +1,6 @@
+#tb 0: 1/25
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 256x256
+#sar 0: 1/1
+0,  0,  0,1,   786432, 0x1445e411
-- 
2.29.2

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: add cineon lin2log trc

2020-03-06 Thread Carl Eugen Hoyos 
Am Fr., 6. März 2020 um 22:11 Uhr schrieb Paul B Mahol :
>
> On 3/6/20, Carl Eugen Hoyos  wrote:
> > Am Fr., 6. März 2020 um 00:25 Uhr schrieb :
> >
> >> +AVCOL_TRC_CINE_LIN2LOG = 19, ///< Default Cineon/DPX linear to log 1D
> >> curve
> >
> > Isn't it possible to use a random large number here?
>
> No, because that would be big hack on top of big pile of hacks that
> exr in ffmpeg is already.

The description sounds as if this isn't exr-only...

But any option is probably fine, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: add cineon lin2log trc

2020-03-06 Thread Paul B Mahol 
On 3/6/20, Carl Eugen Hoyos  wrote:
> Am Fr., 6. März 2020 um 00:25 Uhr schrieb :
>
>> +AVCOL_TRC_CINE_LIN2LOG = 19, ///< Default Cineon/DPX linear to log 1D
>> curve
>
> Isn't it possible to use a random large number here?


No, because that would be big hack on top of big pile of hacks that
exr in ffmpeg is already.

>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: add cineon lin2log trc

2020-03-06 Thread Carl Eugen Hoyos 
Am Fr., 6. März 2020 um 00:25 Uhr schrieb :

> +AVCOL_TRC_CINE_LIN2LOG = 19, ///< Default Cineon/DPX linear to log 1D 
> curve

Isn't it possible to use a random large number here?

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: add cineon lin2log trc

2020-03-06 Thread Gonzalo Garramuño 



El 06/03/20 a las 16:33, Mark Reid escribió:

You would perhaps be better creating a specialist filter and
implementing it using OCIO (as suggested
https://github.com/AcademySoftwareFoundation/tac/tree/master/gsoc), or
extending the current 3D LUT code to read Cinespace or other 3D LUT
formats that support a pre-shaper and handle the float->integer
conversion that way.


I currently do have a workflow that does something similar to that, but it
slower and involves more steps :)
You are probably better off using oiiotool (part of Sony's OpenImageIO) 
for doing that sort of color corrections on EXRs.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: add cineon lin2log trc

2020-03-06 Thread Mark Reid 
On Fri, Mar 6, 2020 at 5:03 AM Kevin Wheatley 
wrote:

> On Fri, Mar 6, 2020 at 10:19 AM Hendrik Leppkes 
> wrote:
> > AVColorTransferCharacteristic should follow ISO/IEC 23001-8 and its
> > following standards (ISO/IEC 23091 I believe). Not sure we have a
> > solution for specialized variants, but adding one right there would
> > collide with the next addition to the standard...
>
> Agreed, A publicly "aligned twin text" version is available as ITU-T
> H.273 https://www.itu.int/rec/T-REC-H.273-201612-I/en shows that value
> is 'reserved'.
>
>
Agreed, it felt wrong about adding it where I did, but it was the quickest
way illustrate what I was trying
to do.

I would also suggest that there are a few implementations of the
> Cineon log to lin conversion and as such I'd reject it as is.
> You will need to pass in the parameters for the various variables
> white, black etc. You will also need to add a parameter for the
> density per code value constant (0.002 by default convention).
> Not all implementations use a gain scaling, though strictly these are
> no longer "Cineon" per se, but you will end up with needing various
> camera vendor equivalents. This would result in a large proliferation
> of equations, which I don't believe are core to the FFmpeg code.
>
>
Agreed and this all could also really be done with a 1dlut video filter but
the real issue I'm working around is that the
current float->int conversion happens in the exr codec. The currently
available apply_trc options clamp at 1.0f (unless I'm mistaken).
The full linear range is need to do any logarithmic conversion.

I was also thinking ACEScc or ACEScct might be more appropriate instead of
cineon.
http://j.mp/S-2014-003
http://j.mp/S-2016-001

I also thought of just adding a float pixel format output option to exr
sounded like a lot of work and I didn't know where to begin.


> You would perhaps be better creating a specialist filter and
> implementing it using OCIO (as suggested
> https://github.com/AcademySoftwareFoundation/tac/tree/master/gsoc), or
> extending the current 3D LUT code to read Cinespace or other 3D LUT
> formats that support a pre-shaper and handle the float->integer
> conversion that way.
>

I currently do have a workflow that does something similar to that, but it
slower and involves more steps :)


>
> Kevin
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: add cineon lin2log trc

2020-03-06 Thread Kevin Wheatley 
On Fri, Mar 6, 2020 at 10:19 AM Hendrik Leppkes  wrote:
> AVColorTransferCharacteristic should follow ISO/IEC 23001-8 and its
> following standards (ISO/IEC 23091 I believe). Not sure we have a
> solution for specialized variants, but adding one right there would
> collide with the next addition to the standard...

Agreed, A publicly "aligned twin text" version is available as ITU-T
H.273 https://www.itu.int/rec/T-REC-H.273-201612-I/en shows that value
is 'reserved'.

I would also suggest that there are a few implementations of the
Cineon log to lin conversion and as such I'd reject it as is.
You will need to pass in the parameters for the various variables
white, black etc. You will also need to add a parameter for the
density per code value constant (0.002 by default convention).
Not all implementations use a gain scaling, though strictly these are
no longer "Cineon" per se, but you will end up with needing various
camera vendor equivalents. This would result in a large proliferation
of equations, which I don't believe are core to the FFmpeg code.

You would perhaps be better creating a specialist filter and
implementing it using OCIO (as suggested
https://github.com/AcademySoftwareFoundation/tac/tree/master/gsoc), or
extending the current 3D LUT code to read Cinespace or other 3D LUT
formats that support a pre-shaper and handle the float->integer
conversion that way.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: add cineon lin2log trc

2020-03-06 Thread Hendrik Leppkes 
On Fri, Mar 6, 2020 at 12:25 AM  wrote:
>
> From: Mark Reid 
>
> Hi,
> The following patch adds a cineon lin2log color transfer characteristic to 
> exr.
> The purpose of this patch is to allow preserving of the dynamic range of an
> exr file when converting to DPX or when using video filter such as 3d luts.
> I wasn't sure if adding it to the AVColorTransferCharacteristic enum was the
> correct approach as this might be a exr specific thing but I figured it was a 
> good starting point.
>
> ---
>  libavcodec/exr.c|  2 ++
>  libavutil/color_utils.c | 14 ++
>  libavutil/pixfmt.h  |  1 +
>  3 files changed, 17 insertions(+)
>
> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> index 1db30a1ae0..f2900a7921 100644
> --- a/libavcodec/exr.c
> +++ b/libavcodec/exr.c
> @@ -1938,6 +1938,8 @@ static const AVOption options[] = {
>  AV_OPT_TYPE_CONST, {.i64 = AVCOL_TRC_SMPTEST2084 },  INT_MIN, 
> INT_MAX, VD, "apply_trc_type"},
>  { "smpte428_1",   "SMPTE ST 428-1",   0,
>  AV_OPT_TYPE_CONST, {.i64 = AVCOL_TRC_SMPTEST428_1 }, INT_MIN, 
> INT_MAX, VD, "apply_trc_type"},
> +{ "lin2log",  "Default Cineon/DPX log",   0,
> +AV_OPT_TYPE_CONST, {.i64 = AVCOL_TRC_CINE_LIN2LOG }, INT_MIN, 
> INT_MAX, VD, "apply_trc_type"},
>
>  { NULL },
>  };
> diff --git a/libavutil/color_utils.c b/libavutil/color_utils.c
> index eb8bc7b5fc..e33c019d4a 100644
> --- a/libavutil/color_utils.c
> +++ b/libavutil/color_utils.c
> @@ -167,6 +167,16 @@ static double avpriv_trc_arib_std_b67(double Lc) {
>  (Lc <= 1.0 / 12.0 ? sqrt(3.0 * Lc) : a * log(12.0 * Lc - b) + c);
>  }
>
> +static double avpriv_trc_cine_lin2log(double Lc) {
> +const double blackpoint =  95.0;
> +const double whitepoint = 685.0;
> +const double gamma  =   0.6;
> +const double offset =  pow(10, (blackpoint - whitepoint) * 0.002 / 
> gamma);
> +const double gain   = 1.0 / (1.0 - offset);
> +
> +return (log10((Lc + offset) / gain) / (0.002 / gamma) + whitepoint ) / 
> 1023.0;
> +}
> +
>  avpriv_trc_function avpriv_get_trc_function_from_trc(enum 
> AVColorTransferCharacteristic trc)
>  {
>  avpriv_trc_function func = NULL;
> @@ -225,6 +235,10 @@ avpriv_trc_function 
> avpriv_get_trc_function_from_trc(enum AVColorTransferCharact
>  func = avpriv_trc_arib_std_b67;
>  break;
>
> +case AVCOL_TRC_CINE_LIN2LOG:
> +func = avpriv_trc_cine_lin2log;
> +break;
> +
>  case AVCOL_TRC_RESERVED0:
>  case AVCOL_TRC_UNSPECIFIED:
>  case AVCOL_TRC_RESERVED:
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 1c625cfc8a..1f3f9988d7 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -499,6 +499,7 @@ enum AVColorTransferCharacteristic {
>  AVCOL_TRC_SMPTE428 = 17, ///< SMPTE ST 428-1
>  AVCOL_TRC_SMPTEST428_1 = AVCOL_TRC_SMPTE428,
>  AVCOL_TRC_ARIB_STD_B67 = 18, ///< ARIB STD-B67, known as "Hybrid 
> log-gamma"
> +AVCOL_TRC_CINE_LIN2LOG = 19, ///< Default Cineon/DPX linear to log 1D 
> curve
>  AVCOL_TRC_NB ///< Not part of ABI

AVColorTransferCharacteristic should follow ISO/IEC 23001-8 and its
following standards (ISO/IEC 23091 I believe). Not sure we have a
solution for specialized variants, but adding one right there would
collide with the next addition to the standard...

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: add cineon lin2log trc

2020-03-06 Thread Paul B Mahol 
On 3/5/20, mindm...@gmail.com  wrote:
> From: Mark Reid 
>
> Hi,
> The following patch adds a cineon lin2log color transfer characteristic to
> exr.
> The purpose of this patch is to allow preserving of the dynamic range of an
> exr file when converting to DPX or when using video filter such as 3d luts.
> I wasn't sure if adding it to the AVColorTransferCharacteristic enum was the
> correct approach as this might be a exr specific thing but I figured it was
> a good starting point.
>
> ---
>  libavcodec/exr.c|  2 ++
>  libavutil/color_utils.c | 14 ++
>  libavutil/pixfmt.h  |  1 +
>  3 files changed, 17 insertions(+)
>
> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> index 1db30a1ae0..f2900a7921 100644
> --- a/libavcodec/exr.c
> +++ b/libavcodec/exr.c
> @@ -1938,6 +1938,8 @@ static const AVOption options[] = {
>  AV_OPT_TYPE_CONST, {.i64 = AVCOL_TRC_SMPTEST2084 },  INT_MIN,
> INT_MAX, VD, "apply_trc_type"},
>  { "smpte428_1",   "SMPTE ST 428-1",   0,
>  AV_OPT_TYPE_CONST, {.i64 = AVCOL_TRC_SMPTEST428_1 }, INT_MIN,
> INT_MAX, VD, "apply_trc_type"},
> +{ "lin2log",  "Default Cineon/DPX log",   0,
> +AV_OPT_TYPE_CONST, {.i64 = AVCOL_TRC_CINE_LIN2LOG }, INT_MIN,
> INT_MAX, VD, "apply_trc_type"},
>
>  { NULL },
>  };
> diff --git a/libavutil/color_utils.c b/libavutil/color_utils.c
> index eb8bc7b5fc..e33c019d4a 100644
> --- a/libavutil/color_utils.c
> +++ b/libavutil/color_utils.c
> @@ -167,6 +167,16 @@ static double avpriv_trc_arib_std_b67(double Lc) {
>  (Lc <= 1.0 / 12.0 ? sqrt(3.0 * Lc) : a * log(12.0 * Lc - b) + c);
>  }
>
> +static double avpriv_trc_cine_lin2log(double Lc) {
> +const double blackpoint =  95.0;
> +const double whitepoint = 685.0;
> +const double gamma  =   0.6;
> +const double offset =  pow(10, (blackpoint - whitepoint) * 0.002 /
> gamma);
> +const double gain   = 1.0 / (1.0 - offset);
> +
> +return (log10((Lc + offset) / gain) / (0.002 / gamma) + whitepoint ) /
> 1023.0;
> +}
> +
>  avpriv_trc_function avpriv_get_trc_function_from_trc(enum
> AVColorTransferCharacteristic trc)
>  {
>  avpriv_trc_function func = NULL;
> @@ -225,6 +235,10 @@ avpriv_trc_function
> avpriv_get_trc_function_from_trc(enum AVColorTransferCharact
>  func = avpriv_trc_arib_std_b67;
>  break;
>
> +case AVCOL_TRC_CINE_LIN2LOG:
> +func = avpriv_trc_cine_lin2log;
> +break;
> +
>  case AVCOL_TRC_RESERVED0:
>  case AVCOL_TRC_UNSPECIFIED:
>  case AVCOL_TRC_RESERVED:
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index 1c625cfc8a..1f3f9988d7 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -499,6 +499,7 @@ enum AVColorTransferCharacteristic {
>  AVCOL_TRC_SMPTE428 = 17, ///< SMPTE ST 428-1
>  AVCOL_TRC_SMPTEST428_1 = AVCOL_TRC_SMPTE428,
>  AVCOL_TRC_ARIB_STD_B67 = 18, ///< ARIB STD-B67, known as "Hybrid
> log-gamma"
> +AVCOL_TRC_CINE_LIN2LOG = 19, ///< Default Cineon/DPX linear to log 1D
> curve

I do not think this one is correct.

>  AVCOL_TRC_NB ///< Not part of ABI
>  };
>
> --
> 2.21.0
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/exr: add cineon lin2log trc

2020-03-05 Thread mindmark 
From: Mark Reid 

Hi,
The following patch adds a cineon lin2log color transfer characteristic to exr.
The purpose of this patch is to allow preserving of the dynamic range of an
exr file when converting to DPX or when using video filter such as 3d luts.
I wasn't sure if adding it to the AVColorTransferCharacteristic enum was the
correct approach as this might be a exr specific thing but I figured it was a 
good starting point.

---
 libavcodec/exr.c|  2 ++
 libavutil/color_utils.c | 14 ++
 libavutil/pixfmt.h  |  1 +
 3 files changed, 17 insertions(+)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 1db30a1ae0..f2900a7921 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1938,6 +1938,8 @@ static const AVOption options[] = {
 AV_OPT_TYPE_CONST, {.i64 = AVCOL_TRC_SMPTEST2084 },  INT_MIN, INT_MAX, 
VD, "apply_trc_type"},
 { "smpte428_1",   "SMPTE ST 428-1",   0,
 AV_OPT_TYPE_CONST, {.i64 = AVCOL_TRC_SMPTEST428_1 }, INT_MIN, INT_MAX, 
VD, "apply_trc_type"},
+{ "lin2log",  "Default Cineon/DPX log",   0,
+AV_OPT_TYPE_CONST, {.i64 = AVCOL_TRC_CINE_LIN2LOG }, INT_MIN, INT_MAX, 
VD, "apply_trc_type"},

 { NULL },
 };
diff --git a/libavutil/color_utils.c b/libavutil/color_utils.c
index eb8bc7b5fc..e33c019d4a 100644
--- a/libavutil/color_utils.c
+++ b/libavutil/color_utils.c
@@ -167,6 +167,16 @@ static double avpriv_trc_arib_std_b67(double Lc) {
 (Lc <= 1.0 / 12.0 ? sqrt(3.0 * Lc) : a * log(12.0 * Lc - b) + c);
 }

+static double avpriv_trc_cine_lin2log(double Lc) {
+const double blackpoint =  95.0;
+const double whitepoint = 685.0;
+const double gamma  =   0.6;
+const double offset =  pow(10, (blackpoint - whitepoint) * 0.002 / gamma);
+const double gain   = 1.0 / (1.0 - offset);
+
+return (log10((Lc + offset) / gain) / (0.002 / gamma) + whitepoint ) / 
1023.0;
+}
+
 avpriv_trc_function avpriv_get_trc_function_from_trc(enum 
AVColorTransferCharacteristic trc)
 {
 avpriv_trc_function func = NULL;
@@ -225,6 +235,10 @@ avpriv_trc_function avpriv_get_trc_function_from_trc(enum 
AVColorTransferCharact
 func = avpriv_trc_arib_std_b67;
 break;

+case AVCOL_TRC_CINE_LIN2LOG:
+func = avpriv_trc_cine_lin2log;
+break;
+
 case AVCOL_TRC_RESERVED0:
 case AVCOL_TRC_UNSPECIFIED:
 case AVCOL_TRC_RESERVED:
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 1c625cfc8a..1f3f9988d7 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -499,6 +499,7 @@ enum AVColorTransferCharacteristic {
 AVCOL_TRC_SMPTE428 = 17, ///< SMPTE ST 428-1
 AVCOL_TRC_SMPTEST428_1 = AVCOL_TRC_SMPTE428,
 AVCOL_TRC_ARIB_STD_B67 = 18, ///< ARIB STD-B67, known as "Hybrid log-gamma"
+AVCOL_TRC_CINE_LIN2LOG = 19, ///< Default Cineon/DPX linear to log 1D curve
 AVCOL_TRC_NB ///< Not part of ABI
 };

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: Allow duplicate use of channel indexes

2019-10-09 Thread Michael Niedermayer 
On Tue, Oct 08, 2019 at 05:13:42PM +0200, Paul B Mahol wrote:
> Why are you not gonna apply this patch?
> 
> Fix code you break!

I did not treat this patch special
it was on the mailing list waiting for a review like any other bugfix

ill apply it with my next push

Thanks for remining me

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: Allow duplicate use of channel indexes

2019-10-08 Thread Paul B Mahol 
Why are you not gonna apply this patch?

Fix code you break!

On 9/26/19, Michael Niedermayer  wrote:
> Fixes: Ticket #8203
>
> Reported-by: durandal_1707
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/exr.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> index c12469cc28..29dab36409 100644
> --- a/libavcodec/exr.c
> +++ b/libavcodec/exr.c
> @@ -1307,6 +1307,7 @@ static int decode_header(EXRContext *s, AVFrame
> *frame)
>  int magic_number, version, i, flags, sar = 0;
>  int layer_match = 0;
>  int ret;
> +int dup_channels = 0;
>
>  s->current_channel_offset = 0;
>  s->xmin   = ~0;
> @@ -1465,10 +1466,12 @@ static int decode_header(EXRContext *s, AVFrame
> *frame)
>  s->pixel_type = current_pixel_type;
>  s->channel_offsets[channel_index] =
> s->current_channel_offset;
>  } else if (channel_index >= 0) {
> -av_log(s->avctx, AV_LOG_ERROR,
> +av_log(s->avctx, AV_LOG_WARNING,
>  "Multiple channels with index %d.\n",
> channel_index);
> -ret = AVERROR_INVALIDDATA;
> -goto fail;
> +if (++dup_channels > 10) {
> +ret = AVERROR_INVALIDDATA;
> +goto fail;
> +}
>  }
>
>  s->channels = av_realloc(s->channels,
> --
> 2.23.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/exr: Allow duplicate use of channel indexes

2019-09-26 Thread Michael Niedermayer 
Fixes: Ticket #8203

Reported-by: durandal_1707
Signed-off-by: Michael Niedermayer 
---
 libavcodec/exr.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index c12469cc28..29dab36409 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1307,6 +1307,7 @@ static int decode_header(EXRContext *s, AVFrame *frame)
 int magic_number, version, i, flags, sar = 0;
 int layer_match = 0;
 int ret;
+int dup_channels = 0;
 
 s->current_channel_offset = 0;
 s->xmin   = ~0;
@@ -1465,10 +1466,12 @@ static int decode_header(EXRContext *s, AVFrame *frame)
 s->pixel_type = current_pixel_type;
 s->channel_offsets[channel_index] = 
s->current_channel_offset;
 } else if (channel_index >= 0) {
-av_log(s->avctx, AV_LOG_ERROR,
+av_log(s->avctx, AV_LOG_WARNING,
 "Multiple channels with index %d.\n", 
channel_index);
-ret = AVERROR_INVALIDDATA;
-goto fail;
+if (++dup_channels > 10) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
 }
 
 s->channels = av_realloc(s->channels,
-- 
2.23.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/exr: Check remaining bits in last get code loop

2018-02-16 Thread Michael Niedermayer 
On Wed, Feb 14, 2018 at 01:45:24PM +0100, Michael Niedermayer wrote:
> Fixes: runtime error: shift exponent -7 is negative
> Fixes: 
> 3902/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-6081926122176512
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/exr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/exr: Check remaining bits in last get code loop

2018-02-14 Thread Michael Niedermayer 
Fixes: runtime error: shift exponent -7 is negative
Fixes: 
3902/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-6081926122176512

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/exr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index f08576af22..47f59bd638 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -558,7 +558,7 @@ static int huf_decode(const uint64_t *hcode, const HufDec 
*hdecod,
 while (lc > 0) {
 const HufDec pl = hdecod[(c << (HUF_DECBITS - lc)) & HUF_DECMASK];
 
-if (pl.len) {
+if (pl.len && lc >= pl.len) {
 lc -= pl.len;
 get_code(pl.lit, rlc, c, lc, gb, out, oe, outb);
 } else {
-- 
2.16.1

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

Re: [FFmpeg-devel] [PATCH] avcodec/exr: Check buf_size more completely

2017-12-30 Thread Michael Niedermayer 
On Fri, Dec 29, 2017 at 03:00:19AM +0100, Michael Niedermayer wrote:
> Fixes: Out of heap array read
> Fixes: 4683/clusterfuzz-testcase-minimized-6152313673613312
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/exr.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

applied


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/exr: Check buf_size more completely

2017-12-28 Thread Michael Niedermayer 
Fixes: Out of heap array read
Fixes: 4683/clusterfuzz-testcase-minimized-6152313673613312

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/exr.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index b1ecde4ebd..454dc74cfb 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1051,7 +1051,7 @@ static int decode_block(AVCodecContext *avctx, void 
*tdata,
 line_offset = AV_RL64(s->gb.buffer + jobnr * 8);
 
 if (s->is_tile) {
-if (line_offset > buf_size - 20)
+if (buf_size < 20 || line_offset > buf_size - 20)
 return AVERROR_INVALIDDATA;
 
 src  = buf + line_offset + 20;
@@ -1062,7 +1062,7 @@ static int decode_block(AVCodecContext *avctx, void 
*tdata,
 tile_level_y = AV_RL32(src - 8);
 
 data_size = AV_RL32(src - 4);
-if (data_size <= 0 || data_size > buf_size)
+if (data_size <= 0 || data_size > buf_size - line_offset - 20)
 return AVERROR_INVALIDDATA;
 
 if (tile_level_x || tile_level_y) { /* tile level, is not the full res 
level */
@@ -1095,7 +1095,7 @@ static int decode_block(AVCodecContext *avctx, void 
*tdata,
 td->channel_line_size = td->xsize * s->current_channel_offset;/* 
uncompress size of one line */
 uncompressed_size = td->channel_line_size * (uint64_t)td->ysize;/* 
uncompress size of the block */
 } else {
-if (line_offset > buf_size - 8)
+if (buf_size < 8 || line_offset > buf_size - 8)
 return AVERROR_INVALIDDATA;
 
 src  = buf + line_offset + 8;
@@ -1105,7 +1105,7 @@ static int decode_block(AVCodecContext *avctx, void 
*tdata,
 return AVERROR_INVALIDDATA;
 
 data_size = AV_RL32(src - 4);
-if (data_size <= 0 || data_size > buf_size)
+if (data_size <= 0 || data_size > buf_size - line_offset - 8)
 return AVERROR_INVALIDDATA;
 
 td->ysize  = FFMIN(s->scan_lines_per_block, s->ymax - line + 
1); /* s->ydelta - line ?? */
-- 
2.15.1

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

Re: [FFmpeg-devel] [PATCH] avcodec/exr detect invalid line offset table and recreate table

2017-03-25 Thread Martin Vignali 
Hello,

The latest patch appear to have a problem :
fatal: corrupt patch at line 6

And it doesn't work for me (head variable seems to be important).

I put in attach a patch, based on the previous one, who works for me.


Martin


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

Re: [FFmpeg-devel] [PATCH] avcodec/exr detect invalid line offset table and recreate table

2017-03-21 Thread Dzung Hoang 
Sorry about the bad format for the patch. Here's another try.

--- 
libavcodec/exr.c | 18 ++ 
1 file changed, 18 insertions(+) 

diff --git a/libavcodec/exr.c b/libavcodec/exr.c 
index 034920f..265d44d 100644 
--- a/libavcodec/exr.c 
+++ b/libavcodec/exr.c 
@@ -1640,6 +1640,9 @@ static int decode_frame(AVCodecContext *avctx, void 
*data, 
int out_line_size; 
int nb_blocks;/* nb scanline or nb tile */ 

+uint64_t *table;/* scanline offset table */ 
+uint8_t *marker;/* used to recreate invalid scanline offset table */ 
+ 
bytestream2_init(>gb, avpkt->data, avpkt->size); 

if ((ret = decode_header(s, picture)) < 0) 
@@ -1731,6 +1734,21 @@ static int decode_frame(AVCodecContext *avctx, void 
*data, 
s->buf_size = avpkt->size; 
ptr = picture->data[0]; 

+// check offset table 
+if (!s->is_tile && bytestream2_peek_le64(>gb) == 0) 
+{ 
+table = (uint64_t *)s->gb.buffer; 
+marker = avpkt->data + bytestream2_tell(>gb) + nb_blocks * 8; 
+ 
+av_log(s->avctx, AV_LOG_DEBUG, "recreating invalid scanline offset 
table\n"); 
+ 
+for (y = 0; y < nb_blocks; y++) 
+{ 
+table[y] = marker - s->buf; 
+marker += ((uint32_t *)marker)[1] + 8; 
+} 
+} 
+ 
// Zero out the start if ymin is not 0 
for (y = 0; y < s->ymin; y++) { 
memset(ptr, 0, out_line_size); 
-- 
2.1.4 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/exr detect invalid line offset table and recreate table

2017-03-21 Thread Dzung Hoang 
Thanks Martin for your comments. I made the requested changes here.

--- libavcodec/exr.c | 18 ++ 1 file changed, 18 insertions(+)
diff --git a/libavcodec/exr.c b/libavcodec/exr.cindex 034920f..265d44d 
100644--- a/libavcodec/exr.c+++ b/libavcodec/exr.c@@ -1640,6 +1640,9 @@ static 
int decode_frame(AVCodecContext *avctx, void *data,     int out_line_size;     
int nb_blocks;/* nb scanline or nb tile */
+    uint64_t *table;/* scanline offset table */+    uint8_t *marker;/* used to 
recreate invalid scanline offset table */+     bytestream2_init(>gb, 
avpkt->data, avpkt->size);
     if ((ret = decode_header(s, picture)) < 0)@@ -1731,6 +1734,21 @@ static 
int decode_frame(AVCodecContext *avctx, void *data,     s->buf_size = 
avpkt->size;     ptr         = picture->data[0];
+    // check offset table+    if (!s->is_tile && bytestream2_peek_le64(>gb) 
== 0)+    {+        table = (uint64_t *)s->gb.buffer;+        marker = 
avpkt->data + bytestream2_tell(>gb) + nb_blocks * 8;++        
av_log(s->avctx, AV_LOG_DEBUG, "recreating invalid scanline offset table\n");++ 
       for (y = 0; y < nb_blocks; y++)+        {+            table[y] = marker 
- s->buf;+            marker += ((uint32_t *)marker)[1] + 8;+        }+    }+   
  // Zero out the start if ymin is not 0     for (y = 0; y < s->ymin; y++) {    
     memset(ptr, 0, out_line_size);--2.1.4



  From: Martin Vignali <martin.vign...@gmail.com>
 To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> 
 Sent: Saturday, March 18, 2017 7:14 AM
 Subject: Re: [FFmpeg-devel] [PATCH] avcodec/exr detect invalid line offset 
table and recreate table
   
Hello,

I tested your patch on mac, seems to work, and doesn't break exr fate test.

Some comments :


> ---
>  libavcodec/exr.c | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> index 034920f..dec21af 100644
> --- a/libavcodec/exr.c
> +++ b/libavcodec/exr.c
> @@ -1726,6 +1726,25 @@ static int decode_frame(AVCodecContext *avctx, void
> *data,
>    if (bytestream2_get_bytes_left(>gb) < nb_blocks * 8)
>        return AVERROR_INVALIDDATA;
>
> +    // check line offset table and recreate if first entry is 0
> +    if (bytestream2_peek_le64(>gb) == 0)
> +    {
>
You should probably test if the file is in scanline (using s->is_tile).
After taking a quick look to the official library, this table
reconstruction seems to be only for scanline picture.


> +        uint64_t *table = (uint64_t *)s->gb.buffer;
> +        uint8_t *head = avpkt->data;
> +        uint8_t *marker = head + bytestream2_tell(>gb) + nb_blocks * 8;
>

You should probably move variable declaration to the top of the function.


> +
> +        av_log(s->avctx, AV_LOG_INFO, "Recreating invalid offset
> table.\n");
> +
> +        // recreate the line offset table using the length field for each
> line
> +        // decode_block() will check for out-of-bounds offsets, so do not
> bother
> +        // to check here
> +        for (y = 0; y < nb_blocks; y++)
> +        {
> +            table[y] = marker - head;
> +            marker += ((uint32_t *)marker)[1] + 8;
> +        }
> +    }
> +
>
>
    // save pointer we are going to use in decode_block
>    s->buf      = avpkt->data;
>    s->buf_size = avpkt->size;
> --
>

You should also add a fate test for a short sample.


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


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

Re: [FFmpeg-devel] [PATCH] avcodec/exr detect invalid line offset table and recreate table

2017-03-18 Thread Martin Vignali 
Hello,

I tested your patch on mac, seems to work, and doesn't break exr fate test.

Some comments :


> ---
>  libavcodec/exr.c | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> index 034920f..dec21af 100644
> --- a/libavcodec/exr.c
> +++ b/libavcodec/exr.c
> @@ -1726,6 +1726,25 @@ static int decode_frame(AVCodecContext *avctx, void
> *data,
> if (bytestream2_get_bytes_left(>gb) < nb_blocks * 8)
> return AVERROR_INVALIDDATA;
>
> +// check line offset table and recreate if first entry is 0
> +if (bytestream2_peek_le64(>gb) == 0)
> +{
>
You should probably test if the file is in scanline (using s->is_tile).
After taking a quick look to the official library, this table
reconstruction seems to be only for scanline picture.


> +uint64_t *table = (uint64_t *)s->gb.buffer;
> +uint8_t *head = avpkt->data;
> +uint8_t *marker = head + bytestream2_tell(>gb) + nb_blocks * 8;
>

You should probably move variable declaration to the top of the function.


> +
> +av_log(s->avctx, AV_LOG_INFO, "Recreating invalid offset
> table.\n");
> +
> +// recreate the line offset table using the length field for each
> line
> +// decode_block() will check for out-of-bounds offsets, so do not
> bother
> +// to check here
> +for (y = 0; y < nb_blocks; y++)
> +{
> +table[y] = marker - head;
> +marker += ((uint32_t *)marker)[1] + 8;
> +}
> +}
> +
>
>
// save pointer we are going to use in decode_block
> s->buf  = avpkt->data;
> s->buf_size = avpkt->size;
> --
>

You should also add a fate test for a short sample.


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

Re: [FFmpeg-devel] [PATCH] avcodec/exr detect invalid line offset table and recreate table

2017-03-17 Thread Dzung Hoang 
Since there are no comments since March 14, I assume this patch is good to go. 
I tried to commit the patch and push it to the mirror on github.com, but was 
denied access.
Can a developer please apply and commit this patch?
Thanks,- Dzung Hoang


  From: Dzung Hoang <dthoang-at-yahoo@ffmpeg.org>
 To: FFmpeg Development Discussions and Patches <ffmpeg-devel@ffmpeg.org> 
 Sent: Tuesday, March 14, 2017 1:36 PM
 Subject: [FFmpeg-devel] [PATCH] avcodec/exr detect invalid line offset table 
and recreate table
   
The EXR decoder cannot handle the image files included in NVidia's HDR SDK. 
After debugging, I found that the line offset table in the image files 
contained 0's. Other EXR decoders, including the official OpenEXR decoder, can 
detect and reconstruct missing line offset tables, so I added some code to do 
so.

I filed a trac ticket for this issue here:

https://trac.ffmpeg.org/ticket/6220.

The image files are here:

http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket6220/

Dzung Hoang
Signed-off-by: Dzung Hoang <dtho...@yahoo.com>

---
 libavcodec/exr.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 034920f..dec21af 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1726,6 +1726,25 @@ static int decode_frame(AVCodecContext *avctx, void 
*data,
    if (bytestream2_get_bytes_left(>gb) < nb_blocks * 8)
        return AVERROR_INVALIDDATA;

+    // check line offset table and recreate if first entry is 0
+    if (bytestream2_peek_le64(>gb) == 0)
+    {
+        uint64_t *table = (uint64_t *)s->gb.buffer;
+        uint8_t *head = avpkt->data;
+        uint8_t *marker = head + bytestream2_tell(>gb) + nb_blocks * 8;
+
+        av_log(s->avctx, AV_LOG_INFO, "Recreating invalid offset table.\n");
+
+        // recreate the line offset table using the length field for each line
+        // decode_block() will check for out-of-bounds offsets, so do not 
bother
+        // to check here
+        for (y = 0; y < nb_blocks; y++)
+        {
+            table[y] = marker - head;
+            marker += ((uint32_t *)marker)[1] + 8;
+        }
+    }
+
    // save pointer we are going to use in decode_block
    s->buf      = avpkt->data;
    s->buf_size = avpkt->size;
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

[FFmpeg-devel] [PATCH] avcodec/exr detect invalid line offset table and recreate table

2017-03-14 Thread Dzung Hoang 
The EXR decoder cannot handle the image files included in NVidia's HDR SDK. 
After debugging, I found that the line offset table in the image files 
contained 0's. Other EXR decoders, including the official OpenEXR decoder, can 
detect and reconstruct missing line offset tables, so I added some code to do 
so.

I filed a trac ticket for this issue here:

https://trac.ffmpeg.org/ticket/6220.

The image files are here:

http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket6220/

Dzung Hoang
Signed-off-by: Dzung Hoang 

---
 libavcodec/exr.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 034920f..dec21af 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1726,6 +1726,25 @@ static int decode_frame(AVCodecContext *avctx, void 
*data,
 if (bytestream2_get_bytes_left(>gb) < nb_blocks * 8)
 return AVERROR_INVALIDDATA;

+// check line offset table and recreate if first entry is 0
+if (bytestream2_peek_le64(>gb) == 0)
+{
+uint64_t *table = (uint64_t *)s->gb.buffer;
+uint8_t *head = avpkt->data;
+uint8_t *marker = head + bytestream2_tell(>gb) + nb_blocks * 8;
+
+av_log(s->avctx, AV_LOG_INFO, "Recreating invalid offset table.\n");
+
+// recreate the line offset table using the length field for each line
+// decode_block() will check for out-of-bounds offsets, so do not 
bother
+// to check here
+for (y = 0; y < nb_blocks; y++)
+{
+table[y] = marker - head;
+marker += ((uint32_t *)marker)[1] + 8;
+}
+}
+
 // save pointer we are going to use in decode_block
 s->buf  = avpkt->data;
 s->buf_size = avpkt->size;
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/exr

2017-03-14 Thread Martin Vignali 
Hello,

Doesn't have time yet to take a look.

Can you send a clean patch :
https://ffmpeg.org/developer.html#Submitting-patches-1

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

Re: [FFmpeg-devel] [PATCH] avcodec/exr

2017-03-14 Thread Paul B Mahol 
On 3/14/17, Dzung Hoang  wrote:
> What is the next step to get this issue resolved?

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

Re: [FFmpeg-devel] [PATCH] avcodec/exr

2017-03-14 Thread Dzung Hoang 
What is the next step to get this issue resolved?
Dzung Hoang

  From: Carl Eugen Hoyos <ceffm...@gmail.com>
 To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> 
 Sent: Tuesday, March 7, 2017 2:02 AM
 Subject: Re: [FFmpeg-devel] [PATCH] avcodec/exr
   
2017-03-06 18:24 GMT+01:00 Paul B Mahol <one...@gmail.com>:
> On 3/6/17, Dzung Hoang <dthoang-at-yahoo@ffmpeg.org> wrote:
>> The EXR decoder cannot handle the image files included in NVidia's HDR SDK.
>> After debugging, I found that the line offset table in the image files
>> contained 0's. Other EXR decoders, including the official OpenEXR decoder,
>> can detect and reconstruct missing line offset tables, so I added some code
>> to do so.
>> I filed a trac ticket for this issue here:
>> https://trac.ffmpeg.org/ticket/6220.
>
> Do you have files with this issue?

http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket6220/

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/exr

2017-03-11 Thread Michael Niedermayer 
On Mon, Mar 06, 2017 at 05:00:22PM +, Dzung Hoang wrote:
> The EXR decoder cannot handle the image files included in NVidia's HDR SDK. 
> After debugging, I found that the line offset table in the image files 
> contained 0's. Other EXR decoders, including the official OpenEXR decoder, 
> can detect and reconstruct missing line offset tables, so I added some code 
> to do so.
> I filed a trac ticket for this issue here: 
> https://trac.ffmpeg.org/ticket/6220.
> 
> 
> The patch is below.
> Regards,Dzung Hoang
> 
> 
> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> 
> index 034920f..de48e76 100644
> 
> --- a/libavcodec/exr.c
> 
> +++ b/libavcodec/exr.c
> 
> @@ -1726,6 +1726,24 @@ static intdecode_frame(AVCodecContext *avctx, void 
> *data,

this patch looks corrupted
also, if one of the images is small please add a fate test

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/exr

2017-03-07 Thread Dzung Hoang 
I uploaded rle_grayscale_noffset.exr using the videolan file uploader.
The rle_grayscale_nooffset.exr image was modified from 
https://trac.ffmpeg.org/raw-attachment/ticket/5621/rle_grayscale.exr by zeroing 
out the line offset table. The modified file is viewable with Adobe Photoshop 
but results in a blank image when processed by ffmpeg.
Let me know if you need additional test images.
Regards,- Dzung Hoang


  From: Paul B Mahol <one...@gmail.com>
 To: dtho...@yahoo.com 
 Sent: Monday, March 6, 2017 11:37 AM
 Subject: Re: [FFmpeg-devel] [PATCH] avcodec/exr
   
On 3/6/17, Dzung Hoang <dthoang-at-yahoo@ffmpeg.org> wrote:
> The EXR decoder cannot handle the image files included in NVidia's HDR
> SDK.
> After debugging, I found that the line offset table in the image files
> contained 0's. Other EXR decoders, including the official OpenEXR
> decoder,
> can detect and reconstruct missing line offset tables, so I added some
> code
> to do so.
> I filed a trac ticket for this issue here:
> https://trac.ffmpeg.org/ticket/6220.
>

 Do you have files with this issue?


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

Re: [FFmpeg-devel] [PATCH] avcodec/exr

2017-03-06 Thread Paul B Mahol 
On 3/6/17, Dzung Hoang  wrote:
> The EXR decoder cannot handle the image files included in NVidia's HDR SDK.
> After debugging, I found that the line offset table in the image files
> contained 0's. Other EXR decoders, including the official OpenEXR decoder,
> can detect and reconstruct missing line offset tables, so I added some code
> to do so.
> I filed a trac ticket for this issue here:
> https://trac.ffmpeg.org/ticket/6220.
>

Do you have files with this issue?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/exr

2017-03-06 Thread Dzung Hoang 
The EXR decoder cannot handle the image files included in NVidia's HDR SDK. 
After debugging, I found that the line offset table in the image files 
contained 0's. Other EXR decoders, including the official OpenEXR decoder, can 
detect and reconstruct missing line offset tables, so I added some code to do 
so.
I filed a trac ticket for this issue here: https://trac.ffmpeg.org/ticket/6220.


The patch is below.
Regards,Dzung Hoang


diff --git a/libavcodec/exr.c b/libavcodec/exr.c

index 034920f..de48e76 100644

--- a/libavcodec/exr.c

+++ b/libavcodec/exr.c

@@ -1726,6 +1726,24 @@ static intdecode_frame(AVCodecContext *avctx, void *data,

if(bytestream2_get_bytes_left(>gb) < nb_blocks * 8)

 returnAVERROR_INVALIDDATA;


 
+    // check offset table

+    if (bytestream2_peek_le64(>gb)== 0)

+    {

+    uint64_t *table= (uint64_t *)s->gb.buffer;

+    uint8_t *head =avpkt->data;

+    uint8_t *marker= head + bytestream2_tell(>gb) + nb_blocks * 8;

+    uint64_t offset;

+

+   av_log(s->avctx, AV_LOG_DEBUG, "recreating invalid offsettable\n");

+

+    for (y = 0; y< nb_blocks; y++)

+    {

+   offset = marker - head;

+   table[y] = offset;

+   marker += ((uint32_t *)marker)[1] + 8;

+    }

+    }

+

 // save pointer we are going to usein decode_block

s->buf  = avpkt->data;

 s->buf_size = avpkt->size;


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

Re: [FFmpeg-devel] [PATCH] avcodec/exr/c Add support for applying a transfer characteristic curve to OpenEXR inputs.

2015-09-10 Thread Michael Niedermayer 
On Tue, Sep 01, 2015 at 12:46:21PM +0100, Kevin Wheatley wrote:
> This actually marks up the buffers as having the state given by the applied 
> trc,
> 
> Kevin
> 
> On Tue, Sep 1, 2015 at 12:04 PM, Kevin Wheatley
>  wrote:
> > This adds the actual usage and allows for command lines similar to this:
> >
> > ffmpeg -apply_trc bt709 -i linear.exr bt709.png
> > ffmpeg -apply_trc smpte2084 -i linear.exr smpte2084.png
> > ffmpeg -apply_trc iec61966_2_1 -i linear.exr sRGB.png
> >
> >
> > Which assuming the correct primaries in the linear OpenEXR file will
> > generate the appropriate file.
> >
> > Kevin

>  exr.c |3 +++
>  1 file changed, 3 insertions(+)
> 366da9c44d8bcbe2f00090588fefd868ced6f441  
> 0007-Mark-up-the-decoded-buffer-as-the-appropriate-transf.patch
> From 0e6bd2437146dafef0e6a89c9db378ba534211bd Mon Sep 17 00:00:00 2001
> From: Kevin Wheatley 
> Date: Tue, 1 Sep 2015 12:35:55 +0100
> Subject: [PATCH 7/7] Mark up the decoded buffer as the appropriate transfer 
> characteristic when applying one

equivalent patches from github applied (i assume they match these)

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/exr/c Add support for applying a transfer characteristic curve to OpenEXR inputs.

2015-09-01 Thread Kevin Wheatley 
This adds the actual usage and allows for command lines similar to this:

ffmpeg -apply_trc bt709 -i linear.exr bt709.png
ffmpeg -apply_trc smpte2084 -i linear.exr smpte2084.png
ffmpeg -apply_trc iec61966_2_1 -i linear.exr sRGB.png


Which assuming the correct primaries in the linear OpenEXR file will
generate the appropriate file.

Kevin
From 25aedae9dc873abcba3a6db3dff503c64cd9e066 Mon Sep 17 00:00:00 2001
From: Kevin Wheatley 
Date: Tue, 1 Sep 2015 11:02:53 +0100
Subject: [PATCH 5/5] Add support for applying a transfer characteristic curve to OpenEXR inputs.

Signed-off-by: Kevin Wheatley 
---
 libavcodec/exr.c |  123 ++
 1 files changed, 96 insertions(+), 27 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index b9de7c1..8794da5 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -37,6 +37,7 @@
 #include "libavutil/imgutils.h"
 #include "libavutil/intfloat.h"
 #include "libavutil/opt.h"
+#include "libavutil/color_utils.h"
 
 #include "avcodec.h"
 #include "bytestream.h"
@@ -110,6 +111,7 @@ typedef struct EXRContext {
 
 const char *layer;
 
+enum AVColorTransferCharacteristic apply_trc_type;
 float gamma;
 uint16_t gamma_table[65536];
 } EXRContext;
@@ -842,6 +844,7 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 int bxmin = s->xmin * 2 * s->desc->nb_components;
 int i, x, buf_size = s->buf_size;
 float one_gamma = 1.0f / s->gamma;
+avpriv_trc_function trc_func = avpriv_get_trc_function_from_trc(s->apply_trc_type);
 int ret;
 
 line_offset = AV_RL64(s->gb.buffer + jobnr * 8);
@@ -921,24 +924,43 @@ static int decode_block(AVCodecContext *avctx, void *tdata,
 ptr_x += s->xmin * s->desc->nb_components;
 if (s->pixel_type == EXR_FLOAT) {
 // 32-bit
-for (x = 0; x < xdelta; x++) {
-union av_intfloat32 t;
-t.i = bytestream_get_le32();
-if (t.f > 0.0f)  /* avoid negative values */
-t.f = powf(t.f, one_gamma);
-*ptr_x++ = exr_flt2uint(t.i);
-
-t.i = bytestream_get_le32();
-if (t.f > 0.0f)
-t.f = powf(t.f, one_gamma);
-*ptr_x++ = exr_flt2uint(t.i);
-
-t.i = bytestream_get_le32();
-if (t.f > 0.0f)
-t.f = powf(t.f, one_gamma);
-*ptr_x++ = exr_flt2uint(t.i);
-if (channel_buffer[3])
-*ptr_x++ = exr_flt2uint(bytestream_get_le32());
+if (trc_func) {
+for (x = 0; x < xdelta; x++) {
+union av_intfloat32 t;
+t.i = bytestream_get_le32();
+t.f = trc_func(t.f);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.i = bytestream_get_le32();
+t.f = trc_func(t.f);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.i = bytestream_get_le32();
+t.f = trc_func(t.f);
+*ptr_x++ = exr_flt2uint(t.i);
+if (channel_buffer[3])
+*ptr_x++ = exr_flt2uint(bytestream_get_le32());
+}
+} else {
+for (x = 0; x < xdelta; x++) {
+union av_intfloat32 t;
+t.i = bytestream_get_le32();
+if (t.f > 0.0f)  /* avoid negative values */
+t.f = powf(t.f, one_gamma);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.i = bytestream_get_le32();
+if (t.f > 0.0f)
+t.f = powf(t.f, one_gamma);
+*ptr_x++ = exr_flt2uint(t.i);
+
+t.i = bytestream_get_le32();
+if (t.f > 0.0f)
+t.f = powf(t.f, one_gamma);
+*ptr_x++ = exr_flt2uint(t.i);
+if (channel_buffer[3])
+*ptr_x++ = exr_flt2uint(bytestream_get_le32());
+}
 }
 } else {
 // 16-bit
@@ -1364,21 +1386,31 @@ static av_cold int decode_init(AVCodecContext *avctx)
 uint32_t i;
 union av_intfloat32 t;
 float one_gamma = 1.0f / s->gamma;
+avpriv_trc_function trc_func = NULL;
 
 s->avctx  = avctx;
 
-if (one_gamma > 0.f && one_gamma < 1.0001f) {
-for (i = 0; i < 65536; ++i)
-s->gamma_table[i] = exr_halflt2uint(i);
-} else {
+trc_func = avpriv_get_trc_function_from_trc(s->apply_trc_type);
+if (trc_func) {
 for (i = 0; i < 65536; ++i) {
 t = exr_half2float(i);
-/* If negative value we reuse half value */
-if (t.f <= 0.0f) {
+t.f = trc_func(t.f);
+s->gamma_table[i] = exr_flt2uint(t.i);
+}

Re: [FFmpeg-devel] [PATCH] avcodec/exr/c Add support for applying a transfer characteristic curve to OpenEXR inputs.

2015-09-01 Thread Kevin Wheatley 
This actually marks up the buffers as having the state given by the applied trc,

Kevin

On Tue, Sep 1, 2015 at 12:04 PM, Kevin Wheatley
 wrote:
> This adds the actual usage and allows for command lines similar to this:
>
> ffmpeg -apply_trc bt709 -i linear.exr bt709.png
> ffmpeg -apply_trc smpte2084 -i linear.exr smpte2084.png
> ffmpeg -apply_trc iec61966_2_1 -i linear.exr sRGB.png
>
>
> Which assuming the correct primaries in the linear OpenEXR file will
> generate the appropriate file.
>
> Kevin
From 0e6bd2437146dafef0e6a89c9db378ba534211bd Mon Sep 17 00:00:00 2001
From: Kevin Wheatley 
Date: Tue, 1 Sep 2015 12:35:55 +0100
Subject: [PATCH 7/7] Mark up the decoded buffer as the appropriate transfer characteristic when applying one

---
 libavcodec/exr.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 8794da5..92f528a 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1308,6 +1308,9 @@ static int decode_frame(AVCodecContext *avctx, void *data,
 av_log(avctx, AV_LOG_ERROR, "Missing channel list.\n");
 return AVERROR_INVALIDDATA;
 }
+
+if (s->apply_trc_type != AVCOL_TRC_UNSPECIFIED)
+avctx->color_trc = s->apply_trc_type;
 
 switch (s->compression) {
 case EXR_RAW:
-- 
1.7.1

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