Print

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

[Manni]

This report is quite technical so is primarily intended for Hendrik or Haasn, but of course anyone is welcome to try to reproduce the issue and report their findings. However, please don't just play the provided clips, you have to also change your tonemapping settings (different settings for each clip) to be able to reproduce the issue, as content and settings are inter-related.

PART I: JRVR issue with HDR to HDR tonemapping

Problem: When tonemapping HDR to HDR, JRVR causes a brightness jump if, in a single scene/shot, the peak brightness in the content starts below the HDR tonemapping target, then raises above it during the shot, in other words if tonemapping kicks in during a single shot. This is most likely to happen in pans involving the sun, as peak brightness will rise significantly when the sun gets into the shot (or gets brighter).

Details:
This happens only with HDR to HDR tonemapping. It doesn't happen with HDR to SDR tonemapping.
This happens with HDR10 or DV (when tonemapping to HDR)
Obviously, this won't happen if the peak brightness in the content is below the display peak brightness / HDR tonemapping target (no tonemapping, so no brightness jump)
It also won't happen if the peak brightness in the content is above the display peak brightness at the beginning of the shot (tonemapping already active, so no brightness jump)

How to reproduce:
This can happen with all content (bright or not so bright) as long as the conditions listed above are met. I'll provide two examples.

Example 1: The Meg (2018) 4K UHD Bluray, 4,000nits, DV P7 MEL (DV supported by MC)
HDR Tonemapping target to reproduce the issue: 1,360nits
When in the film: Chapter 1, 00:04:53 (with the above target)
Link to download test clip (DV P7 MEL): https://mega.nz/file/YmVDGboJ#NdCROCltLwLN4aN18rDEmDrpJFUApPDjNejdfvaauZ4
When in the clip: 00:00:23 (with the above target)
I attach screenshots just before and after the issue takes place (I need two for each as the OSD covers the problematic area). You can see in the OSD that just before the issue the peak brightness is 1,307nits, so there is no tonemapping taking place at 00:04:52 (00:00:22 in the clip). The brightness jump takes place at 00:04:53 (00:00:23 in the clip), when the tonemapping kicks in because the peak in the content raises above the peak of the display/HDR tonemapping target. If you change the target slightly above or slightly below, the issue will take place a bit earlier or a bit later. If you change the target below 1,300nits, there will be no brightness jump because the tonemapping will be on from the beginning of the shot (1,307nits). If you change the target to 1,800nits or above, there won't be any issue because there won't be any tonemapping during the whole shot as the peak for the whole shot is around 1,750nits.

Example 2: Moana 2 (2025) 4K UHD Bluray, 1,000nits, DV P7 FEL (DV currently not supported by MC)
HDR Tonemapping target to reproduce the issue: 400nits
When in the film: Chapter 1, 00:02:08 (with the above target)
Link to download a test clip (DV P5): https://mega.nz/file/Mv1QQKRQ#2PbKBq28YDXuyGNZPlk4JZO2IvcFLLUIbECK4tYhyGc
When in the clip: 00:00:10 (with the above target)
I also attach screenshots just before and after the issue takes place. You can see in the OSD that just before the issue the peak brightness is 358nits, so there is no tonemapping taking place at 00:02:07 (00:00:09 in the test clip). The brightness jump takes place at 00:02:10 (00:00:10 in the clip), when the tonemapping kicks in because the peak in the content raises above the peak of the display/HDR tonemapping target. If you change the target slightly above or slightly below, the issue will take place a bit earlier or a bit later. If you change the target below 200nits, there will be no brightness jump because the tonemapping will be on from the beginning of the shot (240nits). If you change the target to 600nits or above, there won't be any issue because there won't be any tonemapping during the whole shot as the peak for the whole shot is around 520nits.
(Moana's screenshots in next post due to 5 screenshots per post limit)

Hopefully this will allow you to reproduce and fix.

PART II: Possible DV issue
My understanding is that when I reported the brightness instability issue with FEL titles (for example in the opening sequence of Saving Private Ryan), you simply disabled DV when there is a FEL in order to avoid this. It seems to still be the case, as when playing a P7 mkv of Moana (DV FEL) there is no DV in MC, while when playing a P7 mkv of The Meg (DV MEL), DV is active in MC.

There are two points related to this.

1) The first one -- which isn't directly related to the issue described in Part I -- is that while disabling DV entirely when there is a FEL prevents the brightness instability from happening when the title needs the FEL to avoid this instability (for example Saving Brightness Ryan), it also disabled DV for FEL titles that don't show this brightness instability, which isn't desirable.
The optimal way to resolve this brightness instability issue with FEL titles would be to convert P7 to P8.1. This can be done on-the-fly by the player (that's what the new Dune 8K and Zidoo 8K players do for example). The advantage is that it allows to resolve the protential brightness instability (again, not directly related to the issue described in Part I), while keeping the dynamic metadata and the RPU for FEL titles as well as MEL titles. It there any chance you could implement this optimal way to deal with FEL titles (P7>P8.1 conversion instead of disabling DV entirely)?

2) The second one is related to Part I (and indirectly to the above). While DV is currently disabled in MC for Moana 2 when playing the 4K UHD Bluray (DV P7), it is enabled when playing both the Moana 2 test clip (DV profile 5) and The Meg test clip (DV P7 MEL). So why is the DV dynamic metadata not used when playing these clips? Shouldn't it help in precisely these situations, when DV should be providing dynamic metadata for each scene, hence should allow MC to know that the brightness is going to rise during the shot, so should be tonemapping right away in order to avoid this brightness jump? Please note that while the screenshots below show HDR10 (not sure why, I was playing the test clips I think), they do show DV for both the Moana 2 clip and The Meg clips, and the issue also happens when MC reports DV.

So please could you 1) Resolve the issue described in part 1 and 2) Implement the better way to handle FEL titles (with P7>P8.1 conversion instead of disabling DV entirely) and check that the DV dynamic metadata isn't ignored in these test clips. If it isn't, I'm not sure why it doesn't help to deal with such a situation.

I understand that the issue described in Part 1 might be difficult to solve without dynamic metadata, but I'm not sure why it's still there with the DV dynamic metadata, unless there is an issue with DV support in MC.

FYI, when playing both titles in DV (on the Oppo 203), with the relevant peak brightness target in the DV EDID to reproduce the issue (for example 400nits for Moana 2), there is no brightness jump, which suggests that the dynamic metadata is present or that DV deals better with the situation.

Thanks!

[Manni]

Moana 2 screenshots

[Hendrik]

We don't currently use per-scene brightness data from the DV metadata because its dependent on a LAV Filters upgrade that I haven't gotten around to finishing, since its held up by a feature I wanted to include. Once that is available at least for DV titles that should help.
Using the DV Enhancement Layer (EL) is something I would like to do, but its rather complex and is more of a long-term dream.

On titles without metadata, big swings in brightness in a given scene are a bit of a lost cause. You can make it react slower/more gradually, but then you'll face other issues around scene changes, or you can make it react faster and then you see a more obvious shift - either way it has to shift somewhere if it doesn't know whats coming.

[Manni]

We don't currently use per-scene brightness data from the DV metadata because its dependent on a LAV Filters upgrade that I haven't gotten around to finishing, since its held up by a feature I wanted to include. Once that is available at least for DV titles that should help.
Using the DV Enhancement Layer (EL) is something I would like to do, but its rather complex and is more of a long-term dream.

On titles without metadata, big swings in brightness in a given scene are a bit of a lost cause. You can make it react slower/more gradually, but then you'll face other issues around scene changes, or you can make it react faster and then you see a more obvious shift - either way it has to shift somewhere if it doesn't know whats coming.

Thanks for the quick reply.

I understand that it would be more difficult to resolve without the DV dynamic metadata, so I hope that LAV will soon allow you to use the DV dynamic metadata, which should help deal with this with DV titles.

Please could you implement P7>P8.1 conversion, so that FEL titles can also benefit from this when available in LAV? At the moment, DV is disabled with FEL titles to avoid the brightness instability I reported earlier, but this isn't desirable. P7>P8.1 conversion allows you to keep as much as possible from the DV metadata without causing brightness instability. It would be very beneficial to implement, so that FEL titles can also benefit from the LAV improvements.

None of this needs full FEL support, which I agree is harder to do, and would only help with only a few titles where the base layer is borked, so not a big deal at all. P7>P8.1 is far more important and can be done even when the player doesn't fully support FEL (i.e. the latest Dune and Zidoo 8K players).

Also, I believe that madVR is able to deal with the issue reported in Part I without DV metadata, both by "looking into the future" by a frew frames, and by using a rolling average to avoid sudden jumps. I haven't tested as I don't have a recent build of madVR installed (I only use it as a pattern generator with build 113), but I don't believe these issues happen with madVR, so it might be something to consider.

[Hendrik]

Please could you implement P7>P8.1 conversion, so that FEL titles can also benefit from this when available in LAV? At the moment, DV is disabled with FEL titles to avoid the brightness instability I reported earlier, but this isn't desirable. P7>P8.1 conversion allows you to keep as much as possible from the DV metadata without causing brightness instability. It would be very beneficial to implement, so that FEL titles can also benefit from the LAV improvements.

This isn't really a thing. 8.1 is essentially just 7 MEL. You can achieve this either by discarding the EL, which has shown to not be desirable, or actually applying it to the image.

I imagine what these players do is mark it as 8.1 and discard the EL, so that they can output the metadata to the TV (because profile 7 is far more complicated to output). But DV metadata cannot be output from a PC, at least not that anyone has ever found out or documented publicly.
So essentially what this would do is remove the logic that stops DV processing on FEL titles and just call it a day. I suppose I could make that an option and its up to you to decide if you rather deal with the odd broken title with a bad base layer reaction, or have some of the processing. That said the brightness metadata could probably be used regardless of that choice, once its available.

[Manni]

This isn't really a thing. 8.1 is essentially just 7 MEL. You can achieve this either by discarding the EL, which has shown to not be desirable, or actually applying it to the image.

I imagine what these players do is mark it as 8.1 and discard the EL, so that they can output the metadata to the TV (because profile 7 is far more complicated to output). But DV metadata cannot be output from a PC, at least not that anyone has ever found out or documented publicly.
So essentially what this would do is remove the logic that stops DV processing on FEL titles and just call it a day. I suppose I could make that an option and its up to you to decide if you rather deal with the odd broken title with a bad base layer reaction, or have some of the processing. That said the brightness metadata could probably be used regardless of that choice, once its available.

It is definitely a thing

Dune and Zidoo initially did what MC used to do with FEL titles, so they were simply discarding the FEL but were still using the RPU, even when the RPU needed the FEL to achieve the correct brightness. This what my old Dune Pro Vision 4K Solo (Realtek) still does. The only way to avoid the issues where this kind of FEL processing would lead to brightness instability was to disable DV entirely, because that player doesn't do the P7>P8.1 conversion. This is what MC does currently: if it's a FEL title, DV is disabled. This is also what I do with my Pro Vision 4K Solo (Realtek): DV is disabled because that's the only way to avoid the brightness instability with FEL title on these.

On the new 8K Dune and Zidoo (and my new Pro Vision 4K with AML chipset), instead of doing the "wrong" FEL processing that led to brightness instability for many titles (hundreds of them, including Saving Private Ryan), they now do a P7>P8.1 conversion. They are still unable to do proper FEL processing, but it's now possible to use the dynamic metadata without getting the brightness instability. No FEL, but Profile 7 is correctly converted to Profile 8 so metadata pertaining to the FEL is removed (basically spatial resampling and header entries). For example, if you play Saving Private Ryan on the new Dune 4K/8K/Zidoo 8K (AML chipset) with P7>P8.1 conversion, you don't get the brightness fluctuation that you get with the Dune Pro Vision 4K Solo (Realtek) without P7>P8.1 conversion. However, you still get dynamic metadata for tonemapping. So while the 12 bits 1080p enhancement layer isn't processing and titles with a borked HDR10 layer are not corrected (still no full FEL support), you do get the dynamic metadata and it can be used for tonemapping. That's what should be possible in MC, once LAV handles the DV dynamic metadata, and what would be much preferable to the current handling of FEL titles (DV disabled), because it would probably resolve the issues in The Meg or Moana 2 (when played in DV).

Again, this is not full FEL processing (as in the Ugoos AM6B+ or my Oppo 203), but it's as good as it gets without full DV SDK support. Whether it's the equivalent of DV MEL, I don't know. All I know is it gets rid of the brightness instability issues, yet it keeps the dynamic metadata for tonemapping and it doesn't need full FEL support (DV SDK for P7, which is only available on physical players and by mistake on the Ugoos AM6B+).

Although some argue that without full FEL support, you have many issues, I personally don't see any visible/significant ones with P7>P8.1 conversion, except in the handful of titles that have a borked HDR10 base layer (Halloween II, Le Cercle Rouge, Total Recall, etc). The issues with these titles are usually posterization and artifacts, and are not as visible as the brightness fluctuation you get when FEL is incorrectly processed (what MC was doing before disabling DV for FEL titles). Nothing can be done about these titles except full DV processing (Ugoos AM6B+ or 4K BD Players with DV support). But I have maybe 12 of them out of 1,000 DV titles, and most of these titles I purchased specifically to test these issues, i.e. they tend to be obscure/old titles poorly mastered by Studio Canal. I think people post-prod houses are aware of these issues now, so I don't think there will be many more titles with these mastering issues.

There are no downsides to implementing P7>P8.1, only benefits, so I don't think you'd need an option (there would be nothing to gain by disabling it): You get rid of all the issues with hundreds of FEL titles (brightness instability, rogue colored frames, etc, all the issues we were getting in MC before you disabled DV for FEL titles) but you can still exploit the dynamic metadata for tonemapping. It's a compromise between the two that has no obvious downsides that I know of, and it's NOT what you had previously in MC (hundreds of titles with brightness instability and artifacts).

Of course this is moot until LAV is able to handle the dynamic metadata, but once that becomes available, it would mean that 99% of all DV titles would be processed mostly correctly, and only a handful (borked HDR10 layer) would still need full FEL processing to correct the mastering issue.

I can't see any situation where I would want to disable P7>P8.1 conversion on the new Dune/Zidoo. However, I immediately disabled DV on my old Dune 4K, because the brightness fluctuation and artifacts were too visible / distracting in hundreds of titles.

[Hendrik]

Trust me, there is no real technical difference between Profile 7 MEL and Profile 8.1, the only defined differences in those profiles are disabling all flags related to an enhancement layer, which MEL doesn't use anyway (despite technically having one, its just empty).

The only advantage from such a "conversion" is that those hardware devices can output DV metadata to the TV this way, without needing to output the EL in any way. Clearly you'll observe a difference in the image from this being done and not, since now you get DV processing.

For us that would mean simply removing the check for disabling DV on FEL, since the EL is inherently always ignored. There is no further processing that would take place from any conversion.
But we also do not implement the DV tonemapping curves, and have no plans to do so at this point. Maybe those correct any issues caused by the other metadata. Or there is more unknown/undocumented DV processing taking place based on other metadata extension blocks.

Its not exactly an open format, and the downside of the PC is that we have to do 100% of the processing ourselves, while those hardware boxes can simply output the (modified) DV metadata and let the TV do it, which then uses a reference Dolby processor. Thats a far simpler task, and one where said "conversion" actually makes sense, since you use it to get the reference Dolby processor in the TV to do all the work.

So for us any change here would just mean returning to the situation from before FEL was blocked.

[Manni]

Trust me too, that's not what's happening, my TV is a Samsung S90C... It doesn't support DV natively

I use LLDV (player-led DV) with a VRROOM to spoof a DV Datablock and get the player to believe that the TV supports DV, so it's definitely the player that does all the processing and tonemapping in my case if DV is involved. It's sent as LLDV (HDR10 YCC 12bits), while if it was DV it would be sent in an RGB 8bits container. The only situation in which the player doesn't do the processing is when it sends HDR10+ (as the Samsung supports that, so does the tonemapping/processing in that case).

So I do get DV processing in both cases in the player (which then outputs HDR10 to the TV, just like MC), but one is wrong (P7 without 8.1 conversion, brightness fluctuation etc in the old Dune) and one is right (P7>P8.1 conversion in the new 4K/8K Dunes / 8K Zidoo).

What the P7>P8.1 conversion does might be that it allows the player to leverage DV processing from the DV SDK, as P8.1 is allowed for mediaplayers (while P7 isn't, except by mistake in the Ugoo AML6B+).

Returning to the situation before FEL was blocked in MC is defnitely not desirable. As far as I'm concerned, I wouldn't ever enable that option for FEL titles, there are just too many titles with very visible issues. The current handling, though not ideal from a tonemapping point of view, is by far preferable, at least until LAV supports DV dynamic metadata.

As far as I'm concerned, the only interesting thing for MC regarding DV is the dynamic metadata. If you can use it with LAV at some point, it would be a shame to only be able to do so with P7 MEL titles, and not with P7 FEL titles.

I'm going to see if I can get more information regarding P7>P8.1 conversion, and what it means exactly. If I find anything useful, I'll post it here.

In the meantime, I'm going to bump the brightness of my S90C to 2,000nits, so that the issue described in Part I is less likely to happen, and if it does it should be even less visible.

Thanks again for taking the time to answer and for engaging in the discussion. Hopefully, something good will come out of it for MC, at least for DV titles.

[Hendrik]

What the P7>P8.1 conversion does might be that it allows the player to leverage DV processing from the DV SDK, as P8.1 is allowed for mediaplayers (while P7 isn't, except by mistake in the Ugoo AML6B+).

Well same problem then, we do not and cannot use any official DV thing, so if all they do is convert it so either the TV or some other official DV component can do the work, that certainly doesn't benefit us.
All our processing is our own, there is none hidden somewhere that can magically be engaged.

But in any case, the per-scene brightness data could possibly be used even on FEL titles, hoping that the EL is not designed to substantially boost the brightness of a scene making those values wrong. Although who knows, maybe it is.

[Manni]

Well same problem then, we do not and cannot use any official DV thing, so if all they do is convert it so either the TV or some other official DV component can do the work, that certainly doesn't benefit us.
All our processing is our own, there is none hidden somewhere that can magically be engaged.

But in any case, the per-scene brightness data could possibly be used even on FEL titles, hoping that the EL is not designed to substantially boost the brightness of a scene making those values wrong. Although who knows, maybe it is.

That sentence was pure conjecture on my part, hence the "might". As I said, I will try to find out about the P7>P8.1 so we can see if anything can be beneficial for MC. If it relies on the DV SDK, then of course that won't help us.

[Manni]

FYI I just tested the two clips (Moana 2 and The Meg) using the HDR10/P7 version (as madVR can't play DV P5) and I can confirm that even with the old build 113 (the one I have installed here for madTPG purposes) there is no brightness jump in these scenes with the targets allowing to reproduce the issues. So irrespective of the DV discussion, that's a JRVR specific issue. I know that madVR looks a few frames into the future, and uses a rolling average to avoid big brightness shifts like this, so that might be why.

[Manni]

If we put the DV P7 discussion aside for now, a couple of things in case the issue reported in Part I is a bug in JRVR:

1) Again, there is no brightness jump when tonemapping to SDR with JRVR using the same targets. Why would it be different when tonemapping to HDR?
2) In the Moana clip, madVR reports a peak going as high as 1,000nits, while JRVR reports a peak going just above 520nits. Unless they are not reporting the same thing, one of the renderers has to be wrong, and given that madVR has no brightness jump issue with these clips, you might want to double check that JRVR isn't misreading the peak in these situations when tonemapping to HDR.

[aron7awol]

Greetings all.  I am trialing JRiver with intent to purchase if it can meet my needs.  @Manni has been recommending JRVR to me for a while now, and I consider the native HDR 3DLUT support a very compelling feature.

HDR to HDR tone-mapping is my primary use case, and I came across this issue very quickly in my testing.

What appears to be happening, from what I can tell, is that while in HDR to SDR tone-mapping mode, pixels are never allowed to go beyond the specified display peak because relative gamma doesn't allow such a thing, in HDR to HDR tone-mapping mode, JRVR is actually leaving pixels which are beyond the specified display peak alone, and not tone-mapping them at first, then suddenly it jumps to tone-mapping them down and it looks really bad.

In the Moana 2 example tone-mapped to 400 nits, the sun is around 1000 nits (light level) and when it first appears in the frame, it's actually sending to the display still at 1000 nits, then suddenly it tone-maps to 400 nits.

The behavior of HDR to HDR tone-mapping should be the same as HDR to SDR tone-mapping, in that pixels should not be sent to the display in PQ at light levels beyond the specified display peak.  I believe that is what is causing this issue, and that it is not a more typical brightness jump due to lack of smoothing or scene detection etc, since the HDR to SDR behavior at the same peak works nice and smoothly without harsh transition.

[aron7awol]

I wanted to confirm my findings by also testing a bright shot with HDR to HDR TMing to 1360 nits.  It happened almost immediately on the first title I checked.

Here's a clip from Alpha (2018):
https://mega.nz/file/2I4VAQ4T#Nir4MEEOVrnjpT42CwfG08knIZhFo7vkfEkzq-TnIcM

Same deal, when the sun first appears it is not TMing, then suddenly there's a huge change as TMing suddenly kicks in.

[Manni]

Thanks and welcome Aaron. That's indeed the same situation as reported in the first post (Part 1) for the Meg and Moana 2. The shot starts at 400nits peak (no tonemapping), then the sun rises gradually in intensity, and in the same shot rises above the peak (1,360nits) up to 3000nits. That's when the HDR to HDR tonemapping kicks in and suddenly compresses the picture.

On a separate matter, we can close the Part II (possible DV issue). I checked and as I suspected, the P7>P8.1 conversion only allows the media player to convert the stream from a DV format that isn't accepted in a media player (P7) to a format that is (P8.1), which allows to leverage the DV composer in the player (or in the TV) to tonemap the shot properly. As Hendrik suggested, this isn't relevant for MC as MC doesn't have access to the DV composer. So let's hope that a future LAV improvement will allow MC to exploit the dynamic metadata in both MEL and FEL titles, without re-introducing the brightness instability for the latter.

I'm not sure the DV metadata would help in this situation though, because as this brightness jump doesn't happen in HDR to SDR, I agree with Aaron that it more likely to be a bug rather than a scene detection / brightness instability issue. JRVR has seen huge improvements and performs better than madVR in this area following all the issues addressed when I reported some weaknesses. The fact that this brightness jump issue doesn't exist in madVR also makes it more probable that it's a bug in JRVR rather than something fundamental that needs improving.

For now, I have raised the peak brightness in my S90C to 2,000nits to reduce the likelyhood of seeing this happen, but it would be very nice if it could get fixed. This is much less likely to happen with projectors (with 100-200nits, tonemapping is more or less always active, plus this doesn't happen with HDR to SDR anyway) and very bright displays (with 2,000nits+, there is a lot less tonemapping needed). Everything in between, this will happen every time highlights rise significantly in intensity in the same shot, if that shot starts below the tonemapping target, so without needing any tonemapping.

By the way, don't let Aaron's low post count fool you. Although new to MC and JRVR, he is a very experienced developer, calibrator and tonemapping expert, so I hope he'll decide to keep using MC after his trial. It would be great to have him contributing here.

[aron7awol]

Presumably when doing HDR to SDR TMing, the algo clips pixels that are greater than display peak when in that in between zone where the actual frame is greater than display peak but the smoothing is resulting in a nits value that is still below display peak white, resulting in "no tone map" state even though the frame exceeds display peak.

As a side note, it appears the frame peak nits being reported on the OSD is actually luminance and not light level.  That's surprising since light level is what actually corresponds to display capabilities rather than luminance, but maybe that's a topic for another day...

[mattkhan]

I think the peak calculation is described somewhere in the vicinity of https://yabb.jriver.com/interact/index.php/topic,136378.msg949056.html#msg949056

[aron7awol]

Thanks for the link.

To test it, I played some 50% stim test patterns (which have consistent light level but inconsistent luminance) and JRVR is definitely reporting luminance for me.

.5,.5,.5 ~100 nits
.5,0,0 ~26 nits
0,.5,0 ~68 nits
0,0,.5 ~6 nits
etc

But all of those examples are ~100 nit light level, and all require a 100 nit peak white display to produce.

[aron7awol]

I compared a little more between how JRVR does HDRtoSDR vs HDRtoHDR TMing.

I see with HDRtoSDR even on scenes with low peaks it consistently shows spline TMing 203->203, and then as the peak increases above 203 but below specified display peak (say, 400, in this example) it will show something like 300->300, for example, and then if peak increases beyond display peak it will then show something like 500->400, for example.

But with HDRtoHDR it shows no TMing until suddenly when peak increases beyond display peak it will then show something like 500->400, for example.  And because of this, we get this issue with a suddenly ugly jump in the image.

HDRtoHDR should behave exactly the same as HDRtoSDR other than any color space differences and obviously final output transfer function.  But from a TMing perspective, it should be the same, and I believe that's the fix for this issue.

[Manni]

I compared a little more between how JRVR does HDRtoSDR vs HDRtoHDR TMing.

I see with HDRtoSDR even on scenes with low peaks it consistently shows spline TMing 203->203, and then as the peak increases above 203 but below specified display peak (say, 400, in this example) it will show something like 300->300, for example, and then if peak increases beyond display peak it will then show something like 500->400, for example.

But with HDRtoHDR it shows no TMing until suddenly when peak increases beyond display peak it will then show something like 500->400, for example.  And because of this, we get this issue with a suddenly ugly jump in the image.

HDRtoHDR should behave exactly the same as HDRtoSDR other than any color space differences and obviously final output transfer function.  But from a TMing perspective, it should be the same, and I believe that's the fix for this issue.

Though I agree there is likely a bug with HDR>HDR TM in JRVR as there is no issue with HDR>SDR TM, "203>203" and "300>300" with SDR content means the same as "nothing" in HDR. It simply means no tonemapping (brightness-wise). JRVR correctly doesn't touch the picture (SDR or HDR) from a TM point of view if peak in content < display peak. So I don't think this means anything.

There is no issue with HDR to HDR if the shot starts at a level that needs TM from the start, or doesn't need TM during the whole shot. For example, to keep your 400nits MDL example, if a shot ends with no TM (under 400nits), and the next shot start at 600nits, you willl suddenly see 600>400 when before that there was nothing, but JRVR will handle it propely because it's scene detection will tell it right away that tonemapping is needed from the start, and there won't be any sudden jump in brightness, even with HDR>HDR.

Again, this issue only happens when a shot/scene (as identified by JRVR) starts with no tonemapping (peak in content below display peak) and calls for significant tonemapping (brightness-wise) during the shot. Not sure why it's handled differently in HDR>SDR and HDR>HDR, but I agree it shouldn't be (from a brightness TM point of view).

Looking at the difference in handling should allow to resolve this issue, but what the OSD says in SDR is purely cosmetic and doesn't help much.

Hendrik, please could you confirm that you are looking into this? It isn't a case of handling a specific case that would cause issues elsewhere, otherwise we'd have the same issue with HDR>SDR when using the same target.