Decoders should not modify sample values, as that's the job of a library like
swscale.
Signed-off-by: James Almer
---
libavcodec/exr.c | 38 ++
libavcodec/version_major.h | 1 +
2 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/libav
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
> > > sho
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 w
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.
>
> Signe
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".
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 change
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
[...]
--
Mich
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
+++
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".
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
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/libavcode
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
> +
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 +
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 +
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/AcademySoftwareFoundatio
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 fa
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
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
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
e
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
http
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 t
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
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
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 a
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
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 AVColorTran
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
[...]
-
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
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.
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/t
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/ex
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 Nie
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
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
Des
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 @@ sta
To: FFmpeg development discussions and patches
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
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
Discussions and Patches
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 tab
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 cod
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
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
What is the next step to get this issue resolved?
Dzung Hoang
From: Carl Eugen Hoyos
To: FFmpeg development discussions and patches
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 :
> On 3/6/17, Dz
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 d
in a blank image when processed by ffmpeg.
Let me know if you need additional test images.
Regards,- Dzung Hoang
From: Paul B Mahol
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 wrote:
> The
2017-03-06 18:24 GMT+01:00 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 de
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 lin
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 cod
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
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 smpte20
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 w
50 matches
Mail list logo
