[woofer]

This is the MadVR thread and we are working towards making MadvR more accurate, not in comparison to Lumagen

I was NOT the one that instigated the comparison!

 

[James Freeman]

I was NOT the one that instigated the comparison!

That remark, what is the purpose of it?
Please consider actually following your own suggestion, below.

"Tit for Tat " attitudes are only harmful all around..

------

Now...
Anyone has a calibrated HDR TV and SDR monitor/project that can do some side-by-side testing?

 

[madshi]

As I see it, a bad side effect of using dumb is that some "pure" hues will get even more saturated than with "desat i" alone (without desat 2).

Then the only way is too use "desat 2" to counterbalance that.

@madshi is it possible to mix "desat i" and dumb in a way that it does not get more saturated than "desat i" alone? dumb would be used only to desaturate, but will never add saturation to "desat i".

Then maybe "desat 2" would not be useful anymore.

I can add an option for that.

Out of interest, do you remember where you found these patterns?

I think I got them from Stacey Spears, but I'm not 100% sure, to be honest.

It looks like it is the other way around, red become kind of pink

Euwh !! So that rules out desat y, I guess?

EDIT: Seems like y' is causing artifacts in other stuff, in that case desat i 1+2 with no dumb gets my vote as best option to use.

Ok, thanks. I might offer more options to fine tune desat i 2 in the next build.

Our eyes have different sensitivity to different colors. For example green more than red and blue. So perhaps it would make sense to apply a different algorithm/curve to each of the RGB values in a pixel. Or if that is too inefficient, add some extra bias based if there is a dominant color in a pixel.

That's what the "lum method" option already (optionally) offers.

On my LG CX OLED with passthrough, the spear is almost completely green, with just a slight bit of detectable yellow in the details if you look closely. In fact, it is far more green overall than madVR set to 500-1000 nits even with just desat 1, which comparatively desaturates a lot more of the highlights and makes the middle of the spear much more white.

If it's completely green with the LG, then it's probably also lacking in detail, making it look more like a green blob / flat surface?

For the "lum method", only "sep" give me logical transitions

To be fair, this specific test pattern is very "special": It actually has colors which are valid in its YCbCr encoding, but they're not valid after YCbCr to RGB conversion. Practically, there are e.g. blue pixels in there with 10,000 nits. But in RGB, only white pixels can reach 10,000 nits. A movie can never have blue pixels with 10,000 nits, because mastering is done in RGB and not in YCbCr. I intentionally designed this test pattern to use "invalid" colors, to put extra stress on the tone mapping algorithm. But practically that means that the artifacts you get with this test pattern might not matter too much, if it's very far on the right side, especially with blue.

Rename the "hdr10000nitsColored.ytp" file to "hdr10000nitsColored transfer=hdr.ytp" and it will work with build 115 😉

Hehe, I had done the same here...

Personally, I feel like Manni (but only 50 nits). Have a JVC N5 (RS1000) with 3D-Lut and no problem. If I take the 3D-Lut out of the chain, then I can e.g. Passengers and Greatest Showman recognize the skin color problem well. Despite manual calibration with professional tools.

So you're saying you have no oversaturation problem, once you calibrate with a 3DLUT, is that correct?

My idea: Would it be helpful to measure striking scenes in the still image with JVC N5 (RS1000) Frame Adaption (Pana Player) / JVC and Pana Player SDR Tone Mapping / JVC madVR.
Then set the screenshots of Calman with the Saturation Sweeps here.
There you could see the differences in Delta Hue, Luminance and Color and possibly see conclusions?

The problem is that if you try to capture what the JVC DTM does, you're involving a camera, and that alone can screw everything up completely.

Comparing "external" DTM algorithms (those not sitting inside of the display itself) would be possible this way. But then, tone mapping often has to condense both luminance and saturation down to some extent. So if one DTM reduces luminance more than saturation, and the other reduces saturation more than luminance, who did it "right"? There's no clear answer to that. The only thing you could really objectively look at is hue, but even then, any hue error depends on which color model you use. E.g. some color models take hue perception into account when desaturating colors, while others don't. So it's a very difficult thing to scientifically measure and judge.

Yep, I read that other thread comparing the two products and was blown away how jacked up that was.

If they graded that film even on a Dolby pulsar at 4000 nits it would be clipping everything above that point, clipping = hue shifting.

True.

That specific frame doesn't have a lot of yellow on my C8 either (it looks more bright orange than on your photo) but a few frames after that the next explosion is much more yellow/white....

Yes, this frame picked by James Freeman doesn't have a lot of yellow in it. The other frame I usually use hat a lot more yellow in it - but only in the inner part of the explosion, not in the outer circle.

When I projected the JVC to a small size and got 5500 nits I was still entering 5500 into MadVR so would need to do again and see, since madvr would have kept correct hue after that point.

At the time I think I said it was mostly red, or not super yellow anyway, I should do it again, though I did find some photos, and interestingly they are yellowish. But also, when you near the exposure limits of the camera it can hue shift things or make them turn yellow too. LOL.

I don't recall what you told me exactly, I can't seem to find the PM/email. But I do remember that you said it did not look like what Compromise On produces. FWIW, the inner circle of the explosion in this frame has quite a bit of yellow in it, but the outer circle is completely red, and IIRC Compromise On makes both the inner and outer circles completely yellow. On the other hand, Compromise Off loses quite a bit of the yellow punch in the middle. So it's far from perfect, as well.

Just for reference.....

Madshi posted some images comparing "Another" DTM solution with madVR...

Attached is Madshi,s image as posted..

The second pic is from the projected image from my Z1/RS4500 using the "Other" DTM solution of the same scene...

Thanks for posting this. Your photo has a quite strong blue tint, though, which makes it hard to judge skin tones. A blue tint of course makes skin tones look "cooler" = less saturated. I assume your camera added this blue tint.

But this is the problem with photos from the screen: The digital image, even after tone mapping, goes through so many additional steps, from 3DLUT calibration, to projector processing, to projector panels, to screen material, to camera imperfectness. It's really hard to judge the final result based on such a photo. Which is why I prefer to do digital screenshots. There's nothing lost or distorted that way.

Anyway, I'm happy to redo the digital screenshots with your exact settings. Can you send me a list (or photo) of your exact settings, so I can duplicate them exactly? There are a lot of them (in some menus you have to press "alt" to get access to even more settings). So to make this worthwhile it would make sense for me to use the exact same settings you're using.

I am actually a little disappointed in @madshi for making this grenade style comment...

And then follow it up with this later, a lot later...

This borders on irresponsible since we would blast someone criticizing MadVR when not properly setting it up for their display.

I expect a lot more from you!

I apologize for using imperfect settings, but to my defense: I did research which settings to use in the "other thread", and picked the settings from recommendations from key people and what some users posted as their preference. Now woofer is not happy with the settings I chose, and that's fair enough, but honestly, if it's so difficult to choose proper settings, is that my fault?

Anyway, I've been quite silent on the whole comparison topic before. E.g. I've not said a word when some people (including you, IIRC) suggested that the other product would now have superior scaling, which is far from the truth. I was hoping that someone would speak up and set things right. But weeks and months later, nobody did. At some point I can't justify lying down and silently taking a beating, any longer. I should have a right to defend myself and my product, if other people post claims that I believe to be factually incorrect, shouldn't I?

envy has always had a lot more saturation than the lumagen

How can you claim that, without having tested that yourself?

You might not know this, but in many scenes (not with the LG Colors of Journey test image, though, interestingly!) Envy/madVR is a lot brighter with default settings than any other DTM. And I'm not convinced that the users comparing saturation levels have adjusted Envy/madVR settings properly to negate this brightness difference. Obviously, if you compare 2 different DTM solutions at very different brightness levels, the darker one will look more natural and less oversaturated. And I'm thinking that this might very well explain the reports about Envy/madVR being more saturated than other (good) DTMs.

Seems to me like the simplest explanation is the lumagen was too hastily setup with not enough time to get it right.

It's possible, of course. But it's only one possible explanation, there are others (see above).

Madhsi stated that he is basically giving up on a fix for oversat/hue issues at this point…

That is not true. And this is the 2nd time you're saying this, and the 2nd time I'm correcting you.

The Envy I have here (still unopened) needs to leave in the next week or two, hopefully I can have a Lumagen here around the same time. And ill see what I can do. I will certainly spend time to show things like saturation between the two units anyway as its clear it needs to be deep dived more.

That would be great, thanks. I can add desat options to the Envy firmware any time you're ready. That said, your family is much more important, obviously.

 

[bobof]

I think I got them from Stacey Spears, but I'm not 100% sure, to be honest.

Yes, that makes sense now, I was taking with @sspears about this at the same time as trying to get the Lumagen guys to have the option not to desaturate (as I originally discovered the issues there with his original P3 in 2020 simple patches, all the desat settings on Lumagen lead to desaturation, when you'd expect 0 to not desaturate, since resolved). I made them and sent them to him and he did mention he'd sent them to you (I recall he showed me how MadVR dealt with it at the time, which I thought was better). It just surprised me seeing a "blast from the past" again as they weren't very good (!) (rounded RGB 8 bit values for the P3 primaries, poor alignment to chroma subsampling giving odd edge effects, etc) - they were really just to make a point I was having trouble getting folk to understand at the time. If they're useful to you as they are then that's cool, carry on!

I did have some back and forth with Stacey at the time on some new patterns he developed for his disc that did all those patterns do and more (nit levels indicated, 709 + P3 + 2020 on screen at once, etc, more steps, etc). They were very nice and I'm looking forward to seeing the new edition of his disc when it comes out.

 

[madshi]

Yes, that makes sense now, I was taking with @sspears about this at the same time as trying to get the Lumagen guys to have the option not to desaturate (as I originally discovered the issues there with his original P3 in 2020 simple patches, all the desat settings on Lumagen lead to desaturation, when you'd expect 0 to not desaturate, since resolved). I made them and sent them to him and he did mention he'd sent them to you (I recall he showed me how MadVR dealt with it at the time, which I thought was better). It just surprised me seeing a "blast from the past" again as they weren't very good (!) (rounded RGB 8 bit values for the P3 primaries, poor alignment to chroma subsampling giving odd edge effects, etc) - they were really just to make a point I was having trouble getting folk to understand at the time. If they're useful to you as they are then that's cool, carry on!

I did have some back and forth with Stacey at the time on some new patterns he developed for his disc that did all those patterns do and more (nit levels indicated, 709 + P3 + 2020 on screen at once, etc, more steps, etc). They were very nice and I'm looking forward to seeing the new edition of his disc when it comes out.

Would you mind sharing these test patterns once more, if you can find them? They might not be perfect, but they are reasonably useful, I think. As I mentioned, I think I got them from Stacey, and unless it's 100% sure that it's your patterns and not his, I'm not feeling good about sharing them. Don't want to step on anyone's toes.

You're talking about "all the desat settings", as in there being multiple settings? Could you point me to where all those are? Maybe I missed some. Thanks!

 

[bobof]

Would you mind sharing these test patterns once more, if you can find them? They might not be perfect, but they are reasonably useful, I think. As I mentioned, I think I got them from Stacey, and unless it's 100% sure that it's your patterns and not his, I'm not feeling good about sharing them. Don't want to step on anyone's toes.

Sure, they're linked here, that clears up any question of whether they can be used.

p3v2020.zip

drive.google.com

They were made using a Python script I recall, and I think fed into ffmpeg to encode. There are horizontal and vertical versions. The first bars in each set are 2020 primaries (ie 255,0,0 for red) and the second bars are the P3 in 2020 primaries (approx, as I said they're only 8 bit approximations, assuming I got them right...!). I generated the patch values using Lightspace subspace functions. The charts are a bit rubbish (chroma alignment sometimes has edge artifacts etc) but they do serve some purpose.

There are 2 versions, one with 1000 nit and one with 10000 nit MaxCLL metadata - they are interesting to compare sometimes as they can show where metadata is used in some instances (the Lumagens did at least use this at some point in time - it seemed to set a "ceiling" of sorts - though I think that has changed recently). I think the MaxFALL metadata is bogus, I recall couldn't be bothered to work it out for the frame.

You're talking about "all the desat settings", as in there being multiple settings? Could you point me to where all those are? Maybe I missed some. Thanks!

Some of this is old, so tread with a little caution.

There's only one desat control which has a range of values (used to be numeric - originally with a 0 that wasn't off... - but is now Off, Auto, Low, Med, High). Other controls did interact with desat though. So I recall the MaxLight setting interacted (it could affect at what point desat was happening in the luminance curve), as did the the content's declared MaxCLL, and / or the overrides you can set in the menus for the maxCLL.

Or at least it did, I'm a bit rusty on how it all works recently. Last time I tried (around when Auto desat option was added) I found it very hard trying to do static analysis of the way the Lumagen works as you don't always get the same result each time when using extreme patterns. Or at least you didn't when I tried it last.

I know it's an engineering cop-out (head hung in shame), but in the interest of watching content instead of trying to sanity check other people's implementation on an unpaid basis I settled for "seems to work well when I'm watching stuff".

 

[James Freeman]

What timestamp that particular green spear shot in batman v superman?

 

[madshi]

Sure, they're linked here, that clears up any question of whether they can be used.

p3v2020.zip

drive.google.com

Awesome, thanks!

And I can say that the file I have here has the exact same file name. So it must be your's! Good to know.

Neo-XP, Fer15, everyone, you can use the link above to get the colour ramp pattern I've been using.

They were made using a Python script I recall, and I think fed into ffmpeg to encode. There are horizontal and vertical versions. The first bars in each set are 2020 primaries (ie 255,0,0 for red) and the second bars are the P3 in 2020 primaries (approx, as I said they're only 8 bit approximations, assuming I got them right...!). I generated the patch values using Lightspace subspace functions. The charts are a bit rubbish (chroma alignment sometimes has edge artifacts etc) but they do serve some purpose.

You don't happen to have that Python script, anymore? Just wondering because I think some of the guys here might be eager enough to create their own test patterns, if they had such a Python script as a good starting point. But please don't bother going on a long search for the script, let alone rewriting it. It's just in case you happen to have it available at your fingertips and are willing to share.

There are 2 versions, one with 1000 nit and one with 10000 nit MaxCLL metadata - they are interesting to compare sometimes as they can show where metadata is used in some instances (the Lumagens did at least use this at some point in time - it seemed to set a "ceiling" of sorts - though I think that has changed recently). I think the MaxFALL metadata is bogus, I recall couldn't be bothered to work it out for the frame.

Some of this is old, so tread with a little caution.

There's only one desat control which has a range of values (used to be numeric - originally with a 0 that wasn't off... - but is now Off, Auto, Low, Med, High). Other controls did interact with desat though. So I recall the MaxLight setting interacted (it could affect at what point desat was happening in the luminance curve), as did the the content's declared MaxCLL, and / or the overrides you can set in the menus for the maxCLL.

Or at least it did, I'm a bit rusty on how it all works recently. Last time I tried (around when Auto desat option was added) I found it very hard trying to do static analysis of the way the Lumagen works as you don't always get the same result each time when using extreme patterns. Or at least you didn't when I tried it last.

I know it's an engineering cop-out (head hung in shame), but in the interest of watching content instead of trying to sanity check other people's implementation on an unpaid basis I settled for "seems to work well when I'm watching stuff".

Thanks!

 

[madshi]

What timestamp that particular green spear shot in batman v superman?

Sadly, I don't recall the timestamp. I'm using a short sample, for ease of access. It's rather late in the movie somewhere.

 

[Fer15]

What timestamp that particular green spear shot in batman v superman?

There are two scenes

frames
191503

and

219917

Awesome, thanks!

And I can say that the file I have here has the exact same file name. So it must be your's! Good to know.

Neo-XP, Fer15, everyone, you can use the link above to get the colour ramp pattern I've been using.

Got it!

Thanks bobof!

 

[madshi]

Anyone here using the "other product", please feel free to PM me photos of your DTM settings, and I'm happy to redo the comparison with your settings!

 

[aron7awol]

If it's completely green with the LG, then it's probably also lacking in detail, making it look more like a green blob / flat surface?

I re-tested with passthrough to LG, madVR 1000 DPL desat 1, and madVR 1000 DPL don't desat.

Actually, the detail can be seen on the LG TM, not as pronounced as when madVR desats and turns the middle of the spear white, but somewhat surprisingly, the detail is there despite the spear being mostly green. As I'm sure you would expect, don't desat doesn't look good here, but I would say it seems the LG approach is a very light-handed desat, just enough to reveal the detail without turning the details all white. If I had to guess, it's closer to don't desat than desat 1, so I'd say maybe it's like a ~25% desat equivalent? It's definitely the most pleasing of the three on this particular scene. Do we have the non-TM image somewhere?

 

[bobof]

You don't happen to have that Python script, anymore? Just wondering because I think some of the guys here might be eager enough to create their own test patterns, if they had such a Python script as a good starting point. But please don't bother going on a long search for the script, let alone rewriting it. It's just in case you happen to have it available at your fingertips and are willing to share.

It wasn't as glamorous as it sounds, now having found my shameful stash of snippets... It was very much a case of least possible effort to get there. If the below is useful to anyone then they are welcome to it in the spirit of sharing...

The following made a tiny PNG (chart_2.png) with colours taken out of a CSV table I made from the Lightspace patch lists (Attached, renamed .txt for the file upload). I then just stretched / rotated to 1080p size (probably in paint for my sins) to P3V2020_V.png / P3V2020_H.png, made a directory with a ton of numbered copies of the same image for the frame list, and used FFMPEG to encode.

import sys
import csv
import png

patchlist = []

with open ("PriSec_2020_P32020_2.csv") as csv_file:
    reader = csv.reader(csv_file)
    for row in reader:
        for i in range(1,(14*3)+1,1):
            patchlist.append (int (row[i]))                   
print (patchlist)
print

f = open('chart_2.png', 'wb')
w = png.Writer(14,21, greyscale=False)
w.write_array(f, patchlist)
f.close()

The file copy / encode was probably something like this going from my notes at the time (I think this is windows command prompt stuff. Can't be sure):

for /l %i in (0,1,9) do copy p3v2020_h.png p3v2020_h000000%i.png
for /l %i in (10,1,99) do copy p3v2020_h.png p3v2020_h00000%i.png
for /l %i in (100,1,999) do copy p3v2020_h.png p3v2020_h0000%i.png

ffmpeg -threads 16 -r 24000/1001 -start_number 0000001 -i p3v2020_h%07d.png -vf scale=out_color_matrix=bt2020:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -c:v libx265 -preset medium -x265-params crf=12:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)":max-cll="1000,400" -an output/p3v2020_h_1000.mp4

ffmpeg -threads 16 -r 24000/1001 -start_number 0000001 -i p3v2020_h%07d.png -vf scale=out_color_matrix=bt2020:out_h_chr_pos=0:out_v_chr_pos=0,format=yuv420p10 -c:v libx265 -preset medium -x265-params crf=12:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)":max-cll="10000,400" -an output/p3v2020_h_10000.mp4

Link to the output files added here for completeness of this post. Per previous posts; this is very rough and ready as the image isn't chroma-aligned so there are some edge artifacts, and it is only using 8bit rounded values for the P3 in 2020 patches (I only had access to generate in 8 bits) so they're roughly the right colour, but not for extremely critical work.

p3v2020.zip

drive.google.com

 

[Killroy]

I apologize for using imperfect settings, but to my defense: I did research which settings to use in the "other thread", and picked the settings from recommendations from key people and what some users posted as their preference. Now woofer is not happy with the settings I chose, and that's fair enough, but honestly, if it's so difficult to choose proper settings, is that my fault?

Anyway, I've been quite silent on the whole comparison topic before. E.g. I've not said a word when some people (including you, IIRC) suggested that the other product would now have superior scaling, which is far from the truth. I was hoping that someone would speak up and set things right. But weeks and months later, nobody did. At some point I can't justify lying down and silently taking a beating, any longer. I should have a right to defend myself and my product, if other people post claims that I believe to be factually incorrect, shouldn't I?

I have always been a huge cheerleader of MadVR and its powers. Hell, I even held a Lumagen vs MadVR shootout in my theater about 11-months ago and MadVR won out by a landslide (except one scene that Lumagen always did better) and I posted about my findings (opinion). I even posted a lengthy post on my forum pretty much saying that MadVR was the outright winner and in my own words (magical).

Posts here:

(# 6839) New Lumagen Radiance Pro Series

(# 6858) New Lumagen Radiance Pro Series

Some quotes:

"As far as the side-by-side, I had a borrowed Lumagen Pro (4224 I believe) installed on my RS3000 to test against my PC with a RTX 2070 and MadVR. The difference between the two were quite different and obvious. I will say that the upscaling on MadVR is just, in my opinion, mind blowing. The Lumagen did not stand a chance. Sorry. When it came to DTM, MadVR came ahead in several areas as far better 3D looking image and much better HDR look. I wanted to make sure I was not biased in what I saw and I asked the owner of the Lumagen if he was happy with the look of the image that the Lumagen was throwing before I tested the MadVR and he said that he liked the image on my RS3000 better than his NX7 (granted I have an A-lens, he does not). So after it was done he also commented that the MadVR threw a better image but we both agreed that the initial set up on the Lumagen is a lot easier than the MadVR PC (not sure how easy the Envy will be and I hope it's better than a W10 PC)."

But that was 11-months ago and a lot has changed in firmwares for the Lumagen in both DTM and upscaling. My buddy, that let me borrow his unit for the test, kept telling me that the image had improved dramatically which each new firmware and I just refused to believe it. I finally went to his house just after @woofer posted his comparison findings in order to verify what he and my buddy were seeing. I was literally blown away by the difference they had made in such a short time. I have a few Blu-rays that I know by heart and I used these to determine what the upscaling was doing and I was actually seeing a lot more 3D effect on the Lumagen than I could ever see on my MadVR set-up. Then we did the DTM tests on pretty much the same scenes we had used 11-months before (I kept them on an external drive) and the results in my mind were totally reversed. Everything that the my MadVR HTPC had excelled in the previous tests were now looking better and clearer on the Lumagen. The next morning I ordered mine.

I borrowed his settings but changed them to better suit my a-lens set up and the fact that I use a 150" scope image compared to his 120" 16:9 screen.

@madshi, you are by far one of the best software developers for video and HTPC playback. Your many apps have been absolute masterpieces and I have told you as much. But it seems that you have spend a lot of time trying to get the Envy up and running and I am sure it is 2-3 times more time that anyone here can even imagine or calculate. And I am sure you will get MadVR to the point that it will beat out the Lumagen in a very short, or may a bit longer, time. But you should let your product speak for itself. It has always spoken more than anyone else can say. But for the short time it needs some work. This game is a huge see-saw that keeps shifting as new stuff gets added to the each side. Don't look at this as "taking a beating" as you said above. Trust me, you have been handing out "beatings" to the other side for a lot longer than you have received in the past few months.

 

[SamuriHL]

I've encountered and issue that I can't seem to resolve. At timecode 6:04 in the SM demo if I compare the 1000 nit version to the 10000 nit version, I'm seeing problems in the rocks. Hopefully my screen grabs work (I had to finally try and fix that) so you can see the issue. In the 10000 version of it, no matter what I set for desat options the rocks have an almost pinkish white tone to them and detail is lost. The 1000 screen grab has no tone mapping applied since that is what my DPL is set to. I fully accept that I may be doing something stupid here to cause this problem but I thought I'd bring it up anyway in case there's an issue here.

settings:


1000:


10000:

 

[mightyhuhn]

desat 2 with 0 % dumb;
desat i
desat y
desat y'
produce a green that is not green anymore for 1000 to 100 nits:
54 makes it better but doesn't fix it. i'm not aware of another lum setting that helps
dumb mode seems to make this worse not better.

desat 2 desat r' this has some lum modes where is doesn't fail high saturated colors like green 54 is again one of them.
desat r seems to be similar.
my temporary conclusion is desat 2 should only be used with desat r/r' to make the primary no look to wrong.
the problem is dumb mode can change all of this making the number of possibilities and human error while testing huge.

is split screen possible with pass through and i'm simple not able to set it up?

 

[madshi]

I re-tested with passthrough to LG, madVR 1000 DPL desat 1, and madVR 1000 DPL don't desat.

Actually, the detail can be seen on the LG TM, not as pronounced as when madVR desats and turns the middle of the spear white, but somewhat surprisingly, the detail is there despite the spear being mostly green. As I'm sure you would expect, don't desat doesn't look good here, but I would say it seems the LG approach is a very light-handed desat, just enough to reveal the detail without turning the details all white. If I had to guess, it's closer to don't desat than desat 1, so I'd say maybe it's like a ~25% desat equivalent? It's definitely the most pleasing of the three on this particular scene. Do we have the non-TM image somewhere?

Interesting. Though, I assume that if the inner part doesn't get white/pale, at least the amount of visible detail should be reduced to some extent, or made less visible/obvious? You can look at the non-TM image yourself simply by entering 10000 nits in madVR.

It wasn't as glamorous as it sounds, now having found my shameful stash of snippets... It was very much a case of least possible effort to get there. If the below is useful to anyone then they are welcome to it in the spirit of sharing...

Thanks very much!!

But you should let your product speak for itself.

You mean I should not say anything when people claim that my upscaling is worse than the competition, when I know for a fact that that's completely and utterly untrue?

Don't look at this as "taking a beating" as you said above.

I don't even mind taking a beating if it's justified. But at some point, although I'm a patient guy by nature, even my patience runs out when people claim things that are objectively not true.

Anyway, let's not derail this thread with upscaling topics, I'll PM you with more information.

I've encountered and issue that I can't seem to resolve. At timecode 6:04 in the SM demo if I compare the 1000 nit version to the 10000 nit version, I'm seeing problems in the rocks. Hopefully my screen grabs work (I had to finally try and fix that) so you can see the issue. In the 10000 version of it, no matter what I set for desat options the rocks have an almost pinkish white tone to them and detail is lost.

I can see some detail being lost, but I can't seem to see anything pink(ish)? I'm looking at this on my uncalibrated computer monitor, though, so maybe it's there and I can't see it on this monitor.

desat 2 with 0 % dumb;
desat i
desat y
desat y'
produce a green that is not green anymore for 1000 to 100 nits:
54 makes it better but doesn't fix it. i'm not aware of another lum setting that helps
dumb mode seems to make this worse not better.

desat 2 desat r' this has some lum modes where is doesn't fail high saturated colors like green 54 is again one of them.
desat r seems to be similar.
my temporary conclusion is desat 2 should only be used with desat r/r' to make the primary no look to wrong.
the problem is dumb mode can change all of this making the number of possibilities and human error while testing huge.

is split screen possible with pass through and i'm simple not able to set it up?

Split screen is only intended for tone mapping to SDR/Gamma. I haven't tested it for any other purpose.

But yes, the number of possible combinations is huge. And some options "win" in some scenes and some test patterns and lose in others, as usual. So it's not easy picking an overall winner. If it were easy, I would not post test builds, but just a final build with the final objectively best solution...

 

[SamuriHL]

I can see some detail being lost, but I can't seem to see anything pink(ish)? I'm looking at this on my uncalibrated computer monitor, though, so maybe it's there and I can't see it on this monitor.

It's extremely subtle. It's not like it's screaming out "HOT PINK" lol. But the color shift is there for me. It's really weird.

 

[mightyhuhn]

But yes, the number of possible combinations is huge. And some options "win" in some scenes and some test patterns and lose in others, as usual. So it's not easy picking an overall winner. If it were easy, I would not post test builds, but just a final build with the final objectively best solution...

yeah i'm trying to find the bad settings so i can post them ask other user where i made a mistake and if not it could be better to get rid of theses options but that doesn't seem to go that well.

 

[Neo-XP]

Neo-XP, Fer15, everyone, you can use the link above to get the colour ramp pattern I've been using.

@150 nits with "sep" & highlight desat 1.000

desat i / desat y / desat y' / desat r / desat r'

• "desat i" does the best job here, but it is far from perfect
• For each hue there are always at least 2-3 gradations which look exactly the same (not good)

The same with "desat 2" enabled:

desat i / desat y / desat y' / desat r / desat r'

• desat y is broken with "desat 2"
• the transitions with desat y' are still not smooth at all
• "desat 2" does not do anything to the "r" variants
• the transitions with "desat i" are a lot smoother (almost perfect), only the end of the first blue line is not as good as the other hues IMO

Still testing...