Joined
·
2,275 Posts
I was NOT the one that instigated the comparison!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!This is the MadVR thread and we are working towards making MadvR more accurate, not in comparison to Lumagen
That remark, what is the purpose of it?I was NOT the one that instigated the comparison!
------"Tit for Tat " attitudes are only harmful all around..
I can add an option for that.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 think I got them from Stacey Spears, but I'm not 100% sure, to be honest.Out of interest, do you remember where you found these patterns?
Euwh !! So that rules out desat y, I guess?It looks like it is the other way around, red become kind of pink
Ok, thanks. I might offer more options to fine tune desat i 2 in the next build.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.
That's what the "lum method" option already (optionally) offers.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.
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?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.
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.For the "lum method", only "sep" give me logical transitions
Hehe, I had done the same here...Rename the "hdr10000nitsColored.ytp" file to "hdr10000nitsColored transfer=hdr.ytp" and it will work with build 115 😉
So you're saying you have no oversaturation problem, once you calibrate with a 3DLUT, is that correct?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.
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.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?
Yep, I read that other thread comparing the two products and was blown away how jacked up that was.
True.If they graded that film even on a Dolby pulsar at 4000 nits it would be clipping everything above that point, clipping = hue shifting.
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.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....
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.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.
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.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...
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?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!
How can you claim that, without having tested that yourself?envy has always had a lot more saturation than the lumagen
It's possible, of course. But it's only one possible explanation, there are others (see above).Seems to me like the simplest explanation is the lumagen was too hastily setup with not enough time to get it right.
That is not true. And this is the 2nd time you're saying this, and the 2nd time I'm correcting you.Madhsi stated that he is basically giving up on a fix for oversat/hue issues at this point…
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.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.
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 think I got them from Stacey Spears, but I'm not 100% sure, to be honest.
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.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.
Sure, they're linked here, that clears up any question of whether they can be used.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.
Some of this is old, so tread with a little caution.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!
Awesome, thanks!Sure, they're linked here, that clears up any question of whether they can be used.
p3v2020.zip
drive.google.com
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.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.
Thanks!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".
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.What timestamp that particular green spear shot in batman v superman?
There are two scenesWhat timestamp that particular green spear shot in batman v superman?
Got it!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.
I re-tested with passthrough to LG, madVR 1000 DPL desat 1, and madVR 1000 DPL don't desat.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?
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...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.
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()
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
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).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?
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."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)."
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.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?
Thanks very much!!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...![]()
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?But you should let your product speak for itself.
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.Don't look at this as "taking a beating" as you said above.
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.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.
Split screen is only intended for tone mapping to SDR/Gamma. I haven't tested it for any other purpose.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?
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.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.
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.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...![]()
@150 nits with "sep" & highlight desat 1.000Neo-XP, Fer15, everyone, you can use the link above to get the colour ramp pattern I've been using.