Hello Ruiling,
On Fri, 4 May 2018 15:32:58 +0800, Ruiling Song wrote:
> It basically does hdr to sdr conversion with tonemapping.
>
> Signed-off-by: Ruiling Song
> ---
> This patch tries to add a filter to do hdr to sdr conversion with tonemapping.
> The filter does all the job of tonemapping
Another thing that came to my mind:
On Fri, 4 May 2018 15:32:58 +0800, Ruiling Song wrote:
> +static int tonemap_opencl_filter_frame(AVFilterLink *inlink, AVFrame *input)
> +{
> +AVFilterContext*avctx = inlink->dst;
> +AVFilterLink *outlink = avctx->outputs[0];
> +TonemapOpen
>
> As a last note, you can find my GLSL(+Vulkan) implementations of the
> algorithm changes described above, as well as all of the related
> color-management code and various decision logic for what values to
> infer/default here:
> https://github.com/haasn/libplacebo/blob/master/src/shaders/col
On 5 May 2018 at 18:40, Daniel Oberhoff
wrote:
>
> >
> > As a last note, you can find my GLSL(+Vulkan) implementations of the
> > algorithm changes described above, as well as all of the related
> > color-management code and various decision logic for what values to
> > infer/default here:
> > ht
> Am 05.05.2018 um 20:41 schrieb Rostislav Pehlivanov :
>
> On 5 May 2018 at 18:40, Daniel Oberhoff
> wrote:
>
>>
>>>
>>> As a last note, you can find my GLSL(+Vulkan) implementations of the
>>> algorithm changes described above, as well as all of the related
>>> color-management code and va
Hello Niklas,
Thanks so much for your valuable feedback.
> -Original Message-
> From: Niklas Haas [mailto:ffm...@haasn.xyz]
> Sent: Saturday, May 5, 2018 2:00 AM
> To: Song, Ruiling
> Cc: ffmpeg-devel@ffmpeg.org; s...@jkqxz.net
> Subject: Re: [FFmpeg-devel,RFC] lavfi: add opencl tonemap
Hello Ruiling,
> Thanks for sharing your idea with me. I basically also noticed some poor
> quality tone mapping result for some hdr stream.
> I will try your suggestion to see whether I can make it in good state so I
> can include it in next version.
> In fact I have not thought detecting scene
> The way my scene change detection heuristic works like this: I trigger a
> scene change (and therefore discard the frame averaging buffer) if the
> distance between the current frame average brightness and the current
> running average exceeds a threshold value, that threshold being (by
> default
On Fri, May 11, 2018 at 10:10:42 +0200, Niklas Haas wrote:
> Thinking about this logic again, I came to realize that a different
> strategy might be to check instead for a minimum threshold brightness
> difference in a critical number of different areas of the screen. This
> way, a very bright ligh