Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Hendrik]

When quoting a sample from the S&M disc, can you let us know which file on the disc it is, or something to help finding it?

[mattkhan]

Same track the snowy horse comes from, disc 2 4th option down on the left then the bt2020 1000 nits version

[mattkhan]

track shown in the attached menu, scene starts at ~3:09

[mattkhan]

the visibility of the effect scales with the contrast ratio option, it's more obvious as contrast ratio goes up but remains visible even at the lowest 1000:1 setting
the effect appears to completely disappear only once you get to ~400 nits tone mapping target (peak for this scene is ~600 nits)
the reported avg appears to flicker between ~3 and ~6 nits

this might suggest the problem is centred on scene detection? i.e. it shouldn't be changing the target curve during this scene but is hence the brightness flickering

[Hendrik]

Peak Detection seems like the likely culprit. Possibly the more responsive settings are a bit too aggressive, especially with it ignoring black pixels. I'm reading in the second disc now and will confirm in a bit.

[Hendrik]

I can definitely see it here. Curious that it doesn't happen on the similar scenes before and after that point.

[eve]

Build 61 should have the advanced options interface, which is essentially just a textbox on our end.
Multiple options are delimited with commas, (semi)colons or whitespace.

There is a documentation page for libplacebo here which documents these:
https://libplacebo.org/options/

You are likely going to be interested in Tone-mapping constants:
https://libplacebo.org/options/#tone-mapping-constants

These settings are applied after all ours, so it should allow overriding almost everything, with only a few tiny exceptions that are re-set based on each input frame.

Holymoly!
Thanks Hendrik!!!!

Really glad you guys have put so much time into JRVR. It's quickly replacing MadVR for me. I pushed myself into using it for the last ~ 2 weeks for my more critical viewing in the theater and I gotta say, it aint bad. It's getting *really* close.

[haasn]

So, the problem in this scene boils down to to strange encoding noise, causing the result to flicker between 0 and 1, rather than being a constant 0. Since we ignore all-black pixels when computing the frame average brightness, this results in the average brightness flickering wildly. (See pic, orange pixels here are all-black)

I suspect the solution will be to use some sort of soft roll-off rather than a hard cutoff.

[mattkhan]

fwiw that's the only time I've noticed such instability so far (not had time to test extensively though)

does that affect the avg only? or how does this interact with https://libplacebo.org/options/#hdr-peak-detection which seems to be where the scene detection parameters are? If it's constantly updating the avg/peak within a scene then isn't that going to (theoretically) lead to further instability?

[mattkhan]

One of the main posters on the madvr tonemapping thread provided a load of shots from some aces test patterns which might be useful

https://www.avsforum.com/threads/improving-madvr-hdr-to-sdr-mapping-for-projector-no-support-questions.2954506/page-849#post-62865517

It's noticeable how the two have flipped around since a few months ago, madvr is now the more saturated one while jrvr can look a little anaemic at times (colours that you might expect to pop aren't doing so in some scenes but are in others)

I will post pics at the weekend to illustrate

[mattkhan]

a few comparisons

sometimes jrvr is just a bit dark

https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=02edd15c-64a6-11ee-b5be-6595d9b17862
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=6e1afdec-64a6-11ee-b5be-6595d9b17862
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=a9fe2582-64a6-11ee-b5be-6595d9b17862

yet other times it's markedly brighter

https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=ecd76bfc-64a6-11ee-b5be-6595d9b17862
https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=9e8716f6-64a5-11ee-b5be-6595d9b17862

or red is a bit too desaturated (though red is a bit excessive in the comparison in this example for me)

https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=d2a98fcc-64a5-11ee-b5be-6595d9b17862


subjective impression atm... jrvr is a bit dark, madvr (I am using the most version before the very latest batch of more experimental changes) a bit red

[murray]

Overall madvr is certainly looking much better than JRVR.

[JimH]

In the first example, one looks like a night scene.  The other doesn't.

In the last example, take a look at the text on the vertical sign at the left.  One is nearly readable.  The other is muddy.

[mattkhan]

I redid the madvr shots using these settings to try to tone down the (imo excessive) red saturation - https://www.avsforum.com/threads/improving-madvr-hdr-to-sdr-mapping-for-projector-no-support-questions.2954506/page-831#post-62830597

I didn't realise those links would update automatically so the old version is gone, same links (if you force a reload) should now compare those settings with jrvr both set to tm to 100nits

Overall madvr is certainly looking much better than JRVR.

I can watch either quite happily tbh. I have watched some films and did not notice any misbehaviour from jrvr and it looked fine. In comparison, for me, the red saturation in madvr is a bit much at times atm. When you flip them back to back then the differences do become quite apparent and they do seem to tone map quite differently right now. I would say that jrvr is flatter (it's darker in dark scenes but lighter in some other scenes) and it seems that red is generally desaturating quite a bit more than you might expect so I think there is room for improvement there (and/or room for some accessible options to tweak the behaviour)

In the last example, take a look at the text on the vertical sign at the left.  One is nearly readable.  The other is muddy.

see attached, the traffic light makes it clear what is going on because we have a reasonable expectation of what a traffic light looks like. In JRVR, on a RGB colour picker, red and green are basically maxed out & blue is at ~170 so it seems like it has shifted well beyond orange. In madvr, it's at ~230 red/green and ~130 blue. Perhaps this is actually just a reflection of how jrvr is pushing towards clipping? i.e. the same excess of brightening that we seem in some other images. While madvr does tend to get a bit red for me, I do think it's giving a more realistic image overall.

NB: haven't looked at a non tone mapped version of this so these are purely subjective comments atm

[mattkhan]

Anyway, I gave the dynamic adaptation strength a few more thoughts and came up with something like this: https://www.desmos.com/calculator/tyv2elsdao

I thought of trying to tweak some parameters but wanted to do it in a vaguely educated way rather than guessing so is the above reflective of the current build?

if so, is

Kadaption_pre = knee_adaptation (https://libplacebo.org/options/#tone-mapping-constants)

[Hendrik]

I thought of trying to tweak some parameters but wanted to do it in a vaguely educated way rather than guessing so is the above reflective of the current build?

if so, is

Kadaption_pre = knee_adaptation (https://libplacebo.org/options/#tone-mapping-constants)

You can compare to the code if in doubt, but that is the same variable (the code has a bit of a different flow, but the math is the same)
https://github.com/haasn/libplacebo/blob/master/src/tone_mapping.c#L226

[haasn]

I wonder if the difference in saturation is solely due to this desaturation mechanism:

Code: [Select]

diff --git a/src/shaders/colorspace.c b/src/shaders/colorspace.c
index f044b543..429e4491 100644
--- a/src/shaders/colorspace.c
+++ b/src/shaders/colorspace.c
@@ -1965,7 +1965,7 @@ void pl_shader_color_map_ex(pl_shader sh, const struct pl_color_map_params *para
         }
 
         // Avoid raising saturation excessively when changing brightness
-        GLSL("ipt.yz *= min(i_orig / ipt.x, ipt.x / i_orig); \n");
+        //GLSL("ipt.yz *= min(i_orig / ipt.x, ipt.x / i_orig); \n");
     }
 
     if (need_gamut_map) {

Some random pictures: https://slow.pics/c/VBgsCfbs

Simply removing this line is probably not the correct fix but it does illustrate the downside of this logic (which was originally a solution for the exact opposite problem, excessive saturation in very dark/bright scenes).

[haasn]

The difference is even more pronounced at 100 nits target: https://slow.pics/c/iuZ7ktw6

[mattkhan]

I recall reporting that some months ago (people looking too red in certain scenes), certainly there's a line to tread between giving everyone sunburn and bleaching the red out

some sort of more complex rolloff is required I guess?

[haasn]

I recall reporting that some months ago (people looking too red in certain scenes), certainly there's a line to tread between giving everyone sunburn and bleaching the red out

some sort of more complex rolloff is required I guess?

Yeah, possibly we want to reduce the saturation along the curve of the actual gamut hull, rather than linearly. It is some sort of convex function that is non-trivial to compute. Maybe we can approximate it with some sort of polynomial?

[mattkhan]

I was fiddling with different values for those tm parameters and noticed that you can inadvertently break it when simulating dark scenes, at least in the desmos link anyway

it occurs when this becomes undefined

Code: [Select]

K_{CoefLow}=f_{smoothstep}\left(K_{Min},K_{Def},T_{knee}\right)

because Kmin = Kdef = Tknee

example in https://www.desmos.com/calculator/1roma3igms

it's common for Savg to be quite low when expressed in nits and it only takes some small highlight areas to bump up the peak which is what this simulates, I was then trying to up the avg level without producing odd discontinuities in the curve as Savg increases so reduced Kdef then was playing with Kmin (which then clamps Kdef to Kmin). At this point you fairly quickly notice the curve disappearing because of the above condition being met.

not sure if this affects the real implementation or is it just an artifact of the simulation?

[haasn]

not sure if this affects the real implementation or is it just an artifact of the simulation?

It is an artifact of the simulation, the real code handles this edge case:

Code: [Select]

static inline float pl_smoothstep(float edge0, float edge1, float x)
{
    if (edge0 == edge1)
        return x >= edge0;
    x = (x - edge0) / (edge1 - edge0);
    x = PL_CLAMP(x, 0.0f, 1.0f);
    return x * x * (3.0f - 2.0f * x);
}

Though we could also work it around by enforcing a small epsilon between Kdef and Kmin. Note that this is a degenerate case any way, since normally Kmin < Kdef < Kmax.

[mattkhan]

Code: [Select]

knee_adaptation=0.2 knee_default=0.15 spline_contrast=0.25

I'm going to try and live with this for a while as a set of options that, for a projector like a jvc, gives a bit of pop back in dark scenes without appearing to compromise brighter scenes.

MC default => https://www.desmos.com/calculator/xmq9mspdb7
"Pop" preset => https://www.desmos.com/calculator/o2yre5gyyb

click play on Savg to compare the curve across different scene avgs (for a given peak)

At first glance, it seems to do the job but need to spend more time on real content to know whether it actually works. It might be pushing it just a bit far at times, e.g. lack of detail on the boy on left

https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=ea50a89a-65c7-11ee-b5be-6595d9b17862

but in other cases it brings the highlights to life

https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=110cec8c-65c8-11ee-b5be-6595d9b17862

or toning down some of the brightness

https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=3ba1e3e4-65c8-11ee-b5be-6595d9b17862

[haasn]

Yeah, possibly we want to reduce the saturation along the curve of the actual gamut hull, rather than linearly. It is some sort of convex function that is non-trivial to compute. Maybe we can approximate it with some sort of polynomial?

I computed a third-order polynomial approximation. Using this instead of a linear desaturation recovers a bit more of the source.

https://code.videolan.org/videolan/libplacebo/-/merge_requests/609

[tixi]

Hello,

This is exactly my feeling every time I watch a film or series with JRVR DTM on my Sony XW5000 with JRiver. The image is very beautiful, dynamic but sometimes too dark and sometimes lacks "pop"..

How do we implement this modification Haasn? Because it seems to solve this problem no ?

THANKS !

[haasn]

MC default => https://www.desmos.com/calculator/xmq9mspdb7
"Pop" preset => https://www.desmos.com/calculator/o2yre5gyyb

Looking at your "Pop" preset, it almost seems like you want the lower section of the TM curve to be a linear function instead of a 2nd order polynomial?

[Hendrik]

This is exactly my feeling every time I watch a film or series with JRVR DTM on my Sony XW5000 with JRiver. The image is very beautiful, dynamic but sometimes too dark and sometimes lacks "pop"..

How do we implement this modification Haasn? Because it seems to solve this problem no ?

The changes to libplacebo discussed here will be available in JRVR in a future update, but don't have an exact ETA right now.

[mattkhan]

Looking at your "Pop" preset, it almost seems like you want the lower section of the TM curve to be a linear function instead of a 2nd order polynomial?

It wasn't a design target as such, just a side effect of a) trying to minimise loss in dark scenes, and b) avoiding unusual variations in the curve behaviour as Savg increases while working with the parameters available. The latter was definitely a problem with some values, especially when s contrast is higher.

[haasn]

I added a curve that does something like what you want w.r.t spline slope being mostly linear, but I think it has some undesirable loss of contrast and brightness in dark scenes e.g. frame 44 of the test set above (contrary to your intentions): https://code.videolan.org/videolan/libplacebo/-/merge_requests/610

Not sure I'm happy with it. It seems like we need some logic to prevent the slope from getting too low.

[mattkhan]

Something has broken in my libplacebo build setup since I last tried to built plplay so I can't currently try it out, do you have some page somewhere describing a build environment?

A desmos sim could be handy if you have a moment to do that also

[mattkhan]

fixed my libplacebo build, are those options accessible in plplay?

[haasn]

fixed my libplacebo build, are those options accessible in plplay?

Yeah, inside the "Tone mapping" section, under "Fine-tune constants"

[DocCharky]

Overall madvr is certainly looking much better than JRVR.

IMO, they are different, but TBH none is objectively wrong or overall better-looking – whatever that means, because as always with TM what we find "better-looking" might not even be what the colourist saw when grading this scene. That's one of the reasons the AVSforum madvr DTM thread is 5 years old and 850+ pages long with thousands of infinite variations of the same 10 screenshots 

[FenceMan]

IMO, they are different, but TBH none is objectively wrong or overall better-looking – whatever that means, because as always with TM what we find "better-looking" might not even be what the colourist saw when grading this scene. That's one of the reasons the AVSforum madvr DTM thread is 5 years old and 850+ pages long with thousands of infinite variations of the samey 10 screenshots 

I agree, if you read that thread recently they are basically guessing at what to do right now.  I am not saying this is right or wrong just that their TM is just as much a work in progress as anyone elses.  Also lets not forget that the TM in the Envy is months / years behind the PC version and everyone raves about it.

I watch a film almost every night using JRVR and have yet to see anything I find unacceptable.  Improvements are always welcome but everything works really well ATM.

[FoLLgoTT]

After comparing a lot between madVR, MPV and JRiver MC I found out that dark scenes suffer from desaturation in libplacebo when target-contrast is not "inf". I created an issue for that. Both MPV and JRiver MC are affected.

Beside that the tone mapping looks pretty good now. Very bright and high saturated scenes are a bit worse in regards of details comparing do madVR. But I would say >90 % of the time it looks very close and has no problems with very bright scenes/movies.

One little thing: using the internal color conversion (without 3D LUT) the orange tints are less saturated in comparison to madVR. Using relative conversion for gamut mapping mode can change that (tested with MPV). Most of the time it is not visible. I only noticed it in "Elemental" which is very special, because the main character is a flame.

[Smack]

Nice to see you here again Nils. Nils is a known as a genius in the German community regarding MadVr and HDR Tonemapping. I think he could help here a lot with testing and reporting about quality and improvements.

[Manni]

I posted this in the JRVR tonemapping thread (https://yabb.jriver.com/interact/index.php/topic,135621.msg952578.html#msg952578) but will repost a shorter version here as it might be more appropriate.

I find using the knee_adaptation parameter very useful (for example changing it to 0.8 from the 0.4 default) resolves the highlights crushing in the cloud details at the beginning of chapter 3 of Pacific Rim, though it might have downsides elsewhere, I haven't checked for this yet), so it might be a good idea to expose this parameter in the GUI.

I also find a huge brightness instability issue with high nits content. For example, chapter 3 in Mad Max Fury Road is unwatchable with a peak of 100nits (all advanced options enabled, enabling slow peak detection doesn't seem to help).

There is no stability issue with madVR as long as you select the correct settings in the latest experimental build (see details in the link above).

Any chance to get this brightness instability in JRVR resolved? Can other users confirm that they experience this too with around 100nits peak and mad max FR chapter 3?

[mattkhan]

I find using the knee_adaptation parameter very useful (for example changing it to 0.8 from the 0.4 default resolves the highlights crusing in the cloud details at the beginning of chapter 3 of Pacific Rim, though it might have downsides elewhere, I haven't checked for this yet), so it might be a good idea to expose this parameter in the GUI.

what are you using for spline contrast?

[Manni]

what are you using for spline contrast?

0, and contrast enhance is disabled too (not sure it does anything when spline is selected).

I find that spline contrast crushes highlights too much, so I leave it to zero.

[mattkhan]

0, and contrast enhance is disabled too (not sure it does anything when spline is selected).

I find that spline contrast crushes highlights too much, so I leave it to zero.

I have tended in that direction also though I would say it does basically "disable" (for want of a better term) most of the design of that curve, it's largely invariant to the scene avg nits basically - https://www.desmos.com/calculator/xlqsj2qjhk

fwiw the one I was trying is like https://www.desmos.com/calculator/o2yre5gyyb which trades increased brightness/consistency at low end for possibly a flatter response (aka possibly less detail) at the top end, this is just the following option

knee_adaptation=0.2 knee_default=0.15 spline_contrast=0.25

I only spent limited time testing it though so can't say I can recommend it, seemed preferable to me in most scenes to the built in defaults though.

[Manni]

I have tended in that direction also though I would say it does basically "disable" (for want of a better term) most of the design of that curve, it's largely invariant to the scene avg nits basically - https://www.desmos.com/calculator/xlqsj2qjhk

fwiw the one I was trying is like https://www.desmos.com/calculator/o2yre5gyyb which trades increased brightness/consistency at low end for possibly a flatter response (aka possibly less detail) at the top end, this is just the following option

knee_adaptation=0.2 knee_default=0.15 spline_contrast=0.25

I only spent limited time testing it though so can't say I can recommend it, seemed preferable to me in most scenes to the built in defaults though.

Thanks, I'll give these a try and will report back.

Can you (or anyone else) reproduce the brightness stability issues I reported around 100nits peak? They make JRVR unusable to me. Please try to watch Mad Max Fury Road chapter 3 with 100nits peak and let us know.

[FoLLgoTT]

Can you (or anyone else) reproduce the brightness stability issues I reported around 100nits peak? They make JRVR unusable to me. Please try to watch Mad Max Fury Road chapter 3 with 100nits peak and let us know.

I can confirm that there are visible brightness adjustments in your example.

[Manni]

I can confirm that there are visible brightness adjustments in your example.

Thanks for confirming!

Hopefully, this can be fixed.

[danbez]

After comparing a lot between madVR, MPV and JRiver MC I found out that dark scenes suffer from desaturation in libplacebo when target-contrast is not "inf". I created an issue for that. Both MPV and JRiver MC are affected.

Beside that the tone mapping looks pretty good now. Very bright and high saturated scenes are a bit worse in regards of details comparing do madVR. But I would say >90 % of the time it looks very close and has no problems with very bright scenes/movies.

One little thing: using the internal color conversion (without 3D LUT) the orange tints are less saturated in comparison to madVR. Using relative conversion for gamut mapping mode can change that (tested with MPV). Most of the time it is not visible. I only noticed it in "Elemental" which is very special, because the main character is a flame.

I also noticed that very dark scenes become kind of grey if target-contrast is not set to inf (especially if left at default 1000). A good example is House of the Dragon episode 3, where there are dark scenes in the forest. target-contrast set to "inf" made it look very close to MadVR.

[Manni]

I have tended in that direction also though I would say it does basically "disable" (for want of a better term) most of the design of that curve, it's largely invariant to the scene avg nits basically - https://www.desmos.com/calculator/xlqsj2qjhk

fwiw the one I was trying is like https://www.desmos.com/calculator/o2yre5gyyb which trades increased brightness/consistency at low end for possibly a flatter response (aka possibly less detail) at the top end, this is just the following option

knee_adaptation=0.2 knee_default=0.15 spline_contrast=0.25

I only spent limited time testing it though so can't say I can recommend it, seemed preferable to me in most scenes to the built in defaults though.

Thanks again for these. They don't reclaim as much picture depth/contrast/detail in the Pacific Rim example at the beginning of chapter 3, but they produce a much better picture overall tha the default settings (to flat / crushed highlights) or my 0.8 knee_adaptation (great for the Pacific Rim example but too dim in most other situations). Like you I've only done limited testing so can't recommend them, but at first sight they seem like a significant improvement over the default.

Unfortunatey, they don't help with the brightness instability issue, so I won't investigate further until that issue is solved. Looking forward to a solution!

[mattkhan]

Thanks again for these. They don't reclaim as much picture depth/contrast/detail in the Pacific Rim example at the beginning of chapter 3, but they produce a much better picture overall tha the default settings (to flat / crushed highlights) or my 0.8 knee_adaptation (great for the Pacific Rim example but too dim in most other situations). Like you I've only done limited testing so can't recommend them, but at first sight they seem like a significant improvement over the default.

Unfortunatey, they don't help with the brightness instability issue, so I won't investigate further until that issue is solved. Looking forward to a solution!

thanks for testing, comparing to latest madvr beta (which I only just upgraded to and which brings it own blackscreen problems with some discs for me) and using your settings from avs for that, madvr is retains rather more saturation these days. I haven't noticed brightness instability that I can recall though, any other scenes noticed that on? I don't have max max so can't compare that one.

[Manni]

thanks for testing, comparing to latest madvr beta (which I only just upgraded to and which brings it own blackscreen problems with some discs for me) and using your settings from avs for that, madvr is retains rather more saturation these days. I haven't noticed brightness instability that I can recall though, any other scenes noticed that on? I don't have max max so can't compare that one.

The black screen with some discs with madVR might be because you have the measurements files enabled in madVR settings (configuration / files and folders) and have old measurements files for these titles. Recent test versions don't support measurements files, which causes these black screens when some are present. Delete the measurement files if present, or to be sure check "ignore all measurement files" in madVR configuration settings.

Re brightness jumps with JRVR, try any high nits films (mastered to 4,000nits or more) with fast scene changes. Maybe Pacific Rim, The Meg... The bathroom scene in chapter 4 of MI6: Fallout can be a good test for that too. So are the conference room scenes with Morgan Freeman in Lucy. I've stopped using JRVR since I noticed this, as it's a dealbreaker for me, so I don't have other example. But when madVR has some brightness stability issues, the above are the clips I use to test and eradicate.

There are no stability issues with the settings I posted recently on AVS for madVR (it definitely needs details threshold at one and either Mars or Mercury, as well as doubling the default brightness speed adjustment settings, and conservative contrast settings (up to log low or log very low max). Indeed, there is a lot more saturation and picture depth than JRVR, and no brightness stability issue.

[Drybonz]

which brings it own blackscreen problems with some discs for me

I noticed that it does sometimes hang on a black screen when closing a movie and has to be task killed.  I'll check on the measurement files though, and see if that helps.

[Manni]

I noticed that it does sometimes hang on a black screen when closing a movie and has to be task killed.  I'll check on the measurement files though, and see if that helps.

The measurements file issue is only when playback starts, not when it stops.

[mattkhan]

The bathroom scene in chapter 4 of MI6: Fallout can be a good test for that too.

ok yes I see what you mean, there's an example at approx 28:49 when they first walk in the bathroom. If you pause at that point and wait a little while then the peak nits stabilises to approx 1000nits, if you do this a few times (i.e. 1s jump forward then wait) then you see the following avg/peak nits pattern

8.1,957.9
7.4,99.8
11.1,99.8
15.2,471.1
15.4,489.5
17.4,513.5
24.7,522.5

this dip and rebound drives the brightness change and it occurs about 3-4s after the dip in peak nits and lasts for a second or so before it pops back up so I assume this is some sort of decaying average being applied over some seconds to judge the brightness? I guess it needs some additional logic to guard against short lived outliers which aren't scene changes to fix it which seem like it should be doable.

the nearly 1k nits peak scene is the attached and you can see the peak comes from the light that is outside the room but still just visible, in the next second the door has closed so it's no longer there hence the major reduction in peak nits

I'd agree this definitely would be a good thing to fix, you can make various choices on how to tune it but those give a generally consistent appearance but flickering is in the distracting category which you can't really get away from (once you see it).