AVS Forum banner

661 - 680 of 745 Posts

·
Registered
Joined
·
611 Posts
Hey guys, I have a question. Javs is going to do some pixel peeping between Envy and Lumagen (in a month or so). What exactly does that mean? Is this only pertinent to still frames or does it carry over to everyday video in motion? I’m new to this A/B pixel peeping stuff. Thanks.
 

·
Registered
Joined
·
29,704 Posts
Hey guys, I have a question. Javs is going to do some pixel peeping between Envy and Lumagen (in a month or so). What exactly does that mean? Is this only pertinent to still frames or does it carry over to everyday video in motion? I’m new to this A/B pixel peeping stuff. Thanks.
It depends. I expect Envy to look better on still frames, but video may well be a different story.
 

·
Registered
Joined
·
611 Posts
It depends. I expect Envy to look better on still frames, but video may well be a different story.
That's interesting Mike. I actually thought that Lumagen would be better on stills. As I said, this is my first A/B pixel peeping showdown. I know that Envy was beta tested with a lot of action scences, as I was part of that testing experince. This is going to be very revealing. I know you are using Lumagen in your HT. Would you be able to compare Envy to Lumagen? As an unbiased salesman, I would love that input.
 

·
Registered
Joined
·
8,818 Posts
Hey guys, I have a question. Javs is going to do some pixel peeping between Envy and Lumagen (in a month or so). What exactly does that mean? Is this only pertinent to still frames or does it carry over to everyday video in motion? I’m new to this A/B pixel peeping stuff. Thanks.
You are not new to it, you have been reading the Tone Mapping thread for a long time now, its exactly that kind of stuff.

And Similar to stuff I have done in the past like this:


And this:


And this:


And this...

 

·
Registered
Joined
·
29,704 Posts
That's interesting Mike. I actually thought that Lumagen would be better on stills. As I said, this is my first A/B pixel peeping showdown. I know that Envy was beta tested with a lot of action scences, as I was part of that testing experince. This is going to be very revealing. I know you are using Lumagen in your HT. Would you be able to compare Envy to Lumagen? As an unbiased salesman, I would love that input.
No, will not be able to compare. The Envy just took too long to come out and I was not willing to wait that long. Both are going to perform very well. Envy will be easier to set up, but Lumagen will be cheaper. Performance wise, I expect them to be really close. So close that the lead may go back and forth, depending on which one had the last firmware update. Envy does need to get all of their promised features up and running. Now a year from now, who knows. :)
 

·
Registered
Joined
·
611 Posts
You are not new to it, you have been reading the Tone Mapping thread for a long time now, its exactly that kind of stuff.

And Similar to stuff I have done in the past like this:


And this:


And this:


And this...

Thanks Javs for thinking I'm not new to it all. I just diminish my own understanding next to yours. You are the man! Maybe I'll feel better after observing and learning from your pixel peeping! I will pay close attention.

edit: if Lumagen and Envy show that much difference at the pixel level, I will be totally surprised. Should be more of an algo thing. One looking more natural and un-processsed than the other. A native source compare will be revealing, as to which is the least adulterating.
 

·
Registered
Joined
·
1,120 Posts
That's interesting Mike. I actually thought that Lumagen would be better on stills. As I said, this is my first A/B pixel peeping showdown. I know that Envy was beta tested with a lot of action scences, as I was part of that testing experince. This is going to be very revealing. I know you are using Lumagen in your HT. Would you be able to compare Envy to Lumagen? As an unbiased salesman, I would love that input.
Unbiased salesman ? Isn’t that an oxymoron


Sent from my iPhone using Tapatalk
 

·
Registered
Joined
·
29,704 Posts
Unbiased salesman ? Isn’t that an oxymoron


Sent from my iPhone using Tapatalk
A salesman strictly wearing his salesman hat would recommend Sony projectors over JVC any day of the week, due to higher profit margin. Also it is not like anyone that sells Lumagen can't sell Envy. You can be a dealer for both. Just like most dealers are dealers for both JVC and Sony.
 

·
Premium Member
Joined
·
2,956 Posts
Unbiased salesman ? Isn’t that an oxymoron


Sent from my iPhone using Tapatalk

A salesman strictly wearing his salesman hat would recommend Sony projectors over JVC any day of the week, due to higher profit margin. Also it is not like anyone that sells Lumagen can't sell Envy. You can be a dealer for both. Just like most dealers are dealers for both JVC and Sony.
Guys,

Speaking from a prior Top Sales Rep for many-many-many years, me.
It's a fact we do obviously look at our percentage on what product we recommend.
But ................
If one is in sales for long-term we are smart enough to recommend what's the Superior product so that in the end those Customers/Clients keep recommending us to others.

When my Newly ordered Video Processor gets installed this coming week.
I think I'll take that opportunity to do a lengthy in-depth post on why I chose the one I did.
That will be on my Dedicated Thread so I can add all the videos, Reviews etc. I wish without concern over what Thread I do it on.
I have really-really given a lot of thought as to what I want to say and show regarding my selection.
I have decided that it's going to be more "Directed" at those that have not yet decided on which VP to go with.
Like as examples madVR-ENVY or Lumagen and in my case I have been following all of them as well as discussing those for years now.

I will post the Link on this Thread and the JVC RS4500 Dedicated Thread ................

Terry
 

·
ABSOLUTE ULTIMATE AV
Joined
·
5,159 Posts
Discussion Starter #672 (Edited)
That's interesting Mike. I actually thought that Lumagen would be better on stills. As I said, this is my first A/B pixel peeping showdown. I know that Envy was beta tested with a lot of action scences, as I was part of that testing experince. This is going to be very revealing. I know you are using Lumagen in your HT. Would you be able to compare Envy to Lumagen? As an unbiased salesman, I would love that input.
No, will not be able to compare. The Envy just took too long to come out and I was not willing to wait that long. Both are going to perform very well. Envy will be easier to set up, but Lumagen will be cheaper. Performance wise, I expect them to be really close. So close that the lead may go back and forth, depending on which one had the last firmware update. Envy does need to get all of their promised features up and running. Now a year from now, who knows. :)
No at the moment. The Envy when pixel peeping stills has shown to have superior HD-->4K upscaling performance as compared with the Lumagen, however the Lumagen's lastest firmware update improvements have significantly closed the gap. Although I expect that the Envy will still have the slight edge over the Lumagen with respect to upscaling when pixel peeping stills. However, at the present time the Lumagen has superior HDR DTM as compared with the Envy. There is quite a lot wrong with the Envy's DTM in particular regarding colors and accuracy etc. however @Javs is helping the madVR team to fix these issues, so this situation will be improving in the near future. But with moving video content as shown by @woofer 's blind testing absolutely everyone prefered the Lumagen as having the best overall video performance and image quality. But further comparisons and testing will be warranted as and when accordingly as improvements continue to be made. Lumagen continue to make improvement and so do madVR with respect to the Envy. The Envy's DTM will shortly be fixed. Lumagen are further improving their upscaling and there are many further enhancements and improvements in the Lumagen pipeline yet to come. So yes it will indeed be the case that the lead may go back and forth.

I just love the way the competition is driving forwards the development of these two products and making their performances better and better. It's fantastic. I love it.

But I think it's important to note that BOTH products are now delivering stellar performance so literally nobody is going to be disappointed with the performance of either. And as the improvements continue to be made the gap in performance is going to get less and less to the extent that unless you are pixel peeping direct A-B comparisons I think some folks are going to be hard pressed to tell the difference. Hence other factors such hardware input switching, gaming support, and price are going to be more of a determining factor for choosing the Lumagen, and counterwise ease of setup for the Envy.
 

·
Registered
Joined
·
611 Posts
You are not new to it, you have been reading the Tone Mapping thread for a long time now, its exactly that kind of stuff.

And Similar to stuff I have done in the past like this...
I studied your past pixel peeping (A/B) compares. Looks like you’re quite versed at this.

I have one (more) question at this point.

I know you want to work with Madshi on madVR DTM saturation. I observed (first hand) your complaint about source color saturations (easily noticed with whites) being adversely affected by DTM. You had to use “compromise on HDR tone & gamut mapping accuracy” IIRC to circumvent. That was quite a revelation to me. But extremely accurate.

Are you going to disregard this anomaly during your Envy Lumagen A/B’s? Since I’m pretty sure this hasn’t been corrected, yet. Hope this doesn’t skew your tests. But look forward to your future collaborations with Madshi on this.
 

·
Registered
Joined
·
8,818 Posts
No at the moment the Envy when pixel peeping stills has shown to have superior HD-->4K upscaling, however with the lastest firmware update improvements the gap has closed significantly however I expect that the Envy will still have the slight edge over the Lumagen with respect to upscaling when pixel peeping stills. However, at the present time the Lumagen has superior HDR DTM as compared with the Envy. There is quite a lot wrong with the Envy's DTM in particular regarding colors and accuracy etc. however @Javs is helping the madVR team to fix these issues, so this situation will be improving in the near future. But with moving video content as shown by @woofer 's blind testing absolutely everyone prefered the Lumagen as having the best overall video performance and image quality. But further comparisons and testing will be warranted as and when accordingly as improvements continue to be made. Lumagen continue to make improvement and so do madVR with respect to the Envy. The Envy's DTM will shortly be fixed. Lumagen are further improving their upscaling. So yes it will indeed be the case that the lead may go back and forth.

I love the way the competition is driving forwards the development of these two products and making their performances better and better. It's fantastic. I love it.

But I think it's important to note that BOTH products are now delivering stellar performance so literally nobody is going to be disappointed with the performance of either. And as the improvements continue to be made the gap in performance is going to get less and less to the extent that unless you are pixel peeping direct A-B comparisons I think some folks are going to be hard pressed to tell the difference. Hence other factors such hardware input switching, gaming support, and price are going to be more of a determining factor for choosing the Lumagen, and counterwise ease of setup for the Envy.
Yep, Ill just add to this, and me included at times, I think we could stop calling the DTM broken on MadVR.

Technically, and yes I am including this Studio guy Jon Thompson, its subjective preference as to the differences, which is hard for us to grasp because a lot of the testing we do with projectors for eg is not subjective at all, its a black and white fact, but there is no standard for this so its very, very difficult to prove what is correct and I will explain why now... Nigel when on the phone to me you gave up a pretty big hint at this grey area which envelops even Jon Thompson (Lumagens and your star set of eyes supposedly) and I think its really interesting, you had mentioned that Jon had said the Envy was doing incorrect colour, it was way off he said, I pushed you on this and it was said that the fire in Mad Max was the wrong colour and should be yellow. As you recall this made me laugh in a sense because it just goes to show how deep this rabbit hole goes! Ill explain why for others.

Thats a very interesting movie because that fire can go up to 10,000 nits, even now, mastering monitors only reach 4000, and when they pass 4000 they clip, so yes, in the colour grade looking at a lower nit master, or even the hdr master, the mastering monitor would clip the pixels, and guess what happens when you clip pixels asking for 10,000 nits red? They turn yellow!

This is something Mathias and those involved in the tone mapping community development/testing has talked about at one point for almost literally two months, looking at dozens upon dozens of scenes, running tests, and essentially arguing about it, because frankly, pretty much all commercial tone mapping out there, not talking Lumagen - everything else; most TV's, Projectors etc are all implementing a tone mapping solution which includes potential hue shifting when pixels exceed legal limits.

This was patched a long time ago in MadVR, and frankly, some of didn't like it at the time (me) because I had gotten rather used to it, and to be honest I much prefer the Mad Max fire yellow, it wasn't just that film, there were a lot of others. So we looked into it more and came to an agreement that we would allow an option for fire specifically to shift yellow because it subjectively looked better, but did NOT allow other colours to hue shift which you dont usually see in fire and explosions such as blues, greens, violet etc... This is what the fire option is for in MadVR and the Envy right now.

Here are some examples from Davinci Resolve. Interestingly, when I add an S curve in here on the raw untonemapped HDR image, I can indeed induce the yellow fire easily, but Mathias has argued this is not correct either in how Davinci seems to be representing brightness levels, this warrants more deep dive too, and I am open to both directions if the argument can be substantiated. These are set to no colour gamut conversions, so they are in the original BT2020 source colour gamut, if you viewed them in BT2020 mode it would be as you see in the real world tone mapped on a WCG display. To us, these will look more desaturated overall than normal understandably.

Raw HDR Image...



What happens when I manually add an S Curve to try and copy what MadVR does with the Compromise Option ON - Which is 'Dumb' tone mapping that most displays do, simple S curve in a sense on the source. 99.9% of displays out there will do this.



Here is MadVR's 'Dumb' dynamic tone mapping. Compromise ON.

Remarkably similar! I could get it perfect if I played with the S Curve in Davinci a little more.



Here is what MadVR calls scientifically hue perfect tone mapping. (Dont Desaturate option ticked.) Not a huge difference, but according to Mathias, correct hue as present when he studied the pixels.



So the part above is not technically broken, even if Jon Thompson says it is, because logically, if the disc is asking for a pixel to be more orange and its yellow on screen due to tone mapping clipping of illegal pixel values, then its not correct. MadVR is said to be delivering the 'requested' hue here (according to Mathias - but I want to deep dive even that some more). A colorist looking at a mastering monitor which clips info above the mastering level is actually looking at hue shifting colours, 100%!! Shown above.

So thats all well and good, but then Mathias actually had created another test to prove the hue shifting which is pretty irrefutable. Even though I can produce yellow above with my rudimentary S Curve inside Davinci Resolve, which may very well be the mastering software used on this film (its definitely an industry software), this pattern shows the hue shift easily, here is the pattern he made.



The problem is, its not supposed to look like that! There is no purple in that pattern at all. It should look like this:



But then that opens another door, do we want to replicate what the colorist possibly saw including hue shifting over mastering known maximums today (4000 nits) or do we stay scientific and deliver exactly what the disc is encoded at and asking for???

Which pill do you take?

The other conversation is saturation, you could argue this makes it broken, but you can always circumvent this and go back to 'dumb' tone mapping incl hue shift. As for scientific tone mapping, which the Envy is using, so far there is a lot of subjective preference here as to the saturation being overcooked, now I am going to go right out and say, I completely dislike this saturation too, and against other tone mapping solutions it definitely supposedly looks quite overcooked and over saturated, BUT I dont believe I have seen from anywhere concrete evidence that it is, and as much as I dont like it, this is actually mostly what I am going to be very scientifically looking at with Mathias quite soon. We are not just going to force it to de-saturate, first, we are actually going to discover how it compares to a purposefully mastered lower nit version of itself. If I have a 4000 nit master, and compare it to a 100 nits master of content I created myself, THEN and only then can you say with 100% certainty that something is adding or removing saturation. Such as this:


The above preliminary testing shows at least in regards to an HDR encoded rec709 master, MadVR is indeed doing 100% exactly the right thing, and by extension the Envy would be too, with the above test. However higher/wider colour gamuts need to be investigated if they follow suit or if there is a bug somewhere there with tone mapping then.

I wish to improve on this, but there is no standard, and you cannot actually prove without a doubt that one is incorrect and the other is correct unless doing the test I mentioned above, and I want to show this so others can concur, I am not just going to accept word of mouth on this subject, we should ideally all be able to replicate the findings.

Now, if we do this test, and I can prove that MadVR is actually correct all along, then damn, I will eat my hat, you know why, because I wont like it, and it would also mean that a lot of UHD blurays are indeed encoded with a lot more colour than most of us thought (everybody not running 1000+ nits commercial displays - incl OLED) So, we really need to further deep dive if this is scientific fact or not!

Correct or not though, to my eyes subjectively (and a lot of other people now) in certain scenarios more often than not, there is too much saturation with MadVR's tone mapping at times (subjectively) and honestly, I am going to pursue the saturation thing as its own drop box like you have now for contrast, shadow etc, and personally I will just run it off and get hue perfect tone mapping but with the saturation levels we get now with the 'dumb' mode.

It DOES already exist way back in the development (beta version 10), I can roll back to a specific version which does it and it looks outstanding while at the same time being hue perfect colour. See here:

See here (look at all pics all the way to bottom of page many examples): Improving Madvr HDR to SDR mapping for projector

Mathias added 'saturation recovery' after that build because there were proven specific scenarios where tone mapping down to low levels <100 nits definitely resulted in fairly heavy de-saturation compared to the original master at brighter levels which is unfortunately unavoidable, so, some things were added to hopefully bring some of that saturation back, but its intention was at no point to actually boost it, but only to recover it! Hence I think that option should be forked out and called Saturation Recovery. this actually should be quite simple for Mathias to roll back IMO and fork out the further part of the algo at least that way we have a testing starting point, I wager even that will bring it immediately right back in line and neck and neck with the way the lumagen is handling it, in saying that, there was a reason back then why it further evolved from there and it was not borne out of just trying to cook the colour.

So, I, and others should stop saying its broken. Until I see actual evidence otherwise, in a comparison of sorts (100 ant 4000 nit masters custome made for eg), not heresay, its only fair to say it needs further deep investigation.

I am going to be looking in to all of this until Mathias and I, and the other community testers are satisfied before I actually submit any kinds of comparisons here between Lumagen and Envy, I think thats fair. Otherwise if I did that, then we go in and resolve some things or make DTM much improved, I would have wasted my time and I am not about to do that.

Phew! Long post :)
 

·
Registered
Joined
·
8,818 Posts
I studied your past pixel peeping (A/B) compares. Looks like you’re quite versed at this.

I have one (more) question at this point.

I know you want to work with Madshi on madVR DTM saturation. I observed (first hand) your complaint about source color saturations (easily noticed with whites) being adversely affected by DTM. You had to use “compromise on HDR tone & gamut mapping accuracy” IIRC to circumvent. That was quite a revelation to me. But extremely accurate.

Are you going to disregard this anomaly during your Envy Lumagen A/B’s? Since I’m pretty sure this hasn’t been corrected, yet. Hope this doesn’t skew your tests. But look forward to your future collaborations with Madshi on this.
Read above. :)

Absolutely yes, I am not going to waste time on a comparison for it to be null and void.

MadVR deep dive comes before anything, the Envy will greatly help with that, having MadVR and Envy at the same time and an reference HDR Grading Monitor ( 30" Worth > $30k). Only then will I post comparisons between those and the Lumagen here. But I go into much more detail on that above.
 

·
Registered
Joined
·
57 Posts
The NVIDIA Shield definitely hallucinates texture detail that's such an apt term LOL.

It's terrible. I don't know what drugs they are on over there, it looks ok in still, but when it moves it's got crazy shimmering artefacts. I can't believe a lot of the 'internet' think it's amazing. I really had high hopes for that box but it's been pretty disappointing.
What strength did you have it on? I really like what it does on Low. So much so in fact I've stopped using my HTPC for my C9. It already had out of the box accuracy and the AI upscaling on the shield didn't make me feel like I was missing NGU Sharp.
 

·
Registered
Joined
·
8,818 Posts
What strength did you have it on? I really like what it does on Low. So much so in fact I've stopped using my HTPC for my C9. It already had out of the box accuracy and the AI upscaling on the shield didn't make me feel like I was missing NGU Sharp.
The lowest strength.

Have you used it on a projector at all?

If you like it that's fine.
 

·
ABSOLUTE ULTIMATE AV
Joined
·
5,159 Posts
Discussion Starter #678
Yep, Ill just add to this, and me included at times, I think we could stop calling the DTM broken on MadVR.

Technically, and yes I am including this Studio guy Jon Thompson, its subjective preference as to the differences, which is hard for us to grasp because a lot of the testing we do with projectors for eg is not subjective at all, its a black and white fact, but there is no standard for this so its very, very difficult to prove what is correct and I will explain why now... Nigel when on the phone to me you gave up a pretty big hint at this grey area which envelops even Jon Thompson (Lumagens and your star set of eyes supposedly) and I think its really interesting, you had mentioned that Jon had said the Envy was doing incorrect colour, it was way off he said, I pushed you on this and it was said that the fire in Mad Max was the wrong colour and should be yellow. As you recall this made me laugh in a sense because it just goes to show how deep this rabbit hole goes! Ill explain why for others.

Thats a very interesting movie because that fire can go up to 10,000 nits, even now, mastering monitors only reach 4000, and when they pass 4000 they clip, so yes, in the colour grade looking at a lower nit master, or even the hdr master, the mastering monitor would clip the pixels, and guess what happens when you clip pixels asking for 10,000 nits red? They turn yellow!

This is something Mathias and those involved in the tone mapping community development/testing has talked about at one point for almost literally two months, looking at dozens upon dozens of scenes, running tests, and essentially arguing about it, because frankly, pretty much all commercial tone mapping out there, not talking Lumagen - everything else; most TV's, Projectors etc are all implementing a tone mapping solution which includes potential hue shifting when pixels exceed legal limits.

This was patched a long time ago in MadVR, and frankly, some of didn't like it at the time (me) because I had gotten rather used to it, and to be honest I much prefer the Mad Max fire yellow, it wasn't just that film, there were a lot of others. So we looked into it more and came to an agreement that we would allow an option for fire specifically to shift yellow because it subjectively looked better, but did NOT allow other colours to hue shift which you dont usually see in fire and explosions such as blues, greens, violet etc... This is what the fire option is for in MadVR and the Envy right now.

Here are some examples from Davinci Resolve. Interestingly, when I add an S curve in here on the raw untonemapped HDR image, I can indeed induce the yellow fire easily, but Mathias has argued this is not correct either in how Davinci seems to be representing brightness levels, this warrants more deep dive too, and I am open to both directions if the argument can be substantiated. These are set to no colour gamut conversions, so they are in the original BT2020 source colour gamut, if you viewed them in BT2020 mode it would be as you see in the real world tone mapped on a WCG display. To us, these will look more desaturated overall than normal understandably.

Raw HDR Image...



What happens when I manually add an S Curve to try and copy what MadVR does with the Compromise Option ON - Which is 'Dumb' tone mapping that most displays do, simple S curve in a sense on the source. 99.9% of displays out there will do this.



Here is MadVR's 'Dumb' dynamic tone mapping. Compromise ON.

Remarkably similar! I could get it perfect if I played with the S Curve in Davinci a little more.



Here is what MadVR calls scientifically hue perfect tone mapping. (Dont Desaturate option ticked.) Not a huge difference, but according to Mathias, correct hue as present when he studied the pixels.



So the part above is not technically broken, even if Jon Thompson says it is, because logically, if the disc is asking for a pixel to be more orange and its yellow on screen due to tone mapping clipping of illegal pixel values, then its not correct. MadVR is said to be delivering the 'requested' hue here (according to Mathias - but I want to deep dive even that some more). A colorist looking at a mastering monitor which clips info above the mastering level is actually looking at hue shifting colours, 100%!! Shown above.

So thats all well and good, but then Mathias actually had created another test to prove the hue shifting which is pretty irrefutable. Even though I can produce yellow above with my rudimentary S Curve inside Davinci Resolve, which may very well be the mastering software used on this film (its definitely an industry software), this pattern shows the hue shift easily, here is the pattern he made.



The problem is, its not supposed to look like that! There is no purple in that pattern at all. It should look like this:



But then that opens another door, do we want to replicate what the colorist possibly saw including hue shifting over mastering known maximums today (4000 nits) or do we stay scientific and deliver exactly what the disc is encoded at and asking for???

Which pill do you take?

The other conversation is saturation, you could argue this makes it broken, but you can always circumvent this and go back to 'dumb' tone mapping incl hue shift. As for scientific tone mapping, which the Envy is using, so far there is a lot of subjective preference here as to the saturation being overcooked, now I am going to go right out and say, I completely dislike this saturation too, and against other tone mapping solutions it definitely supposedly looks quite overcooked and over saturated, BUT I dont believe I have seen from anywhere concrete evidence that it is, and as much as I dont like it, this is actually mostly what I am going to be very scientifically looking at with Mathias quite soon. We are not just going to force it to de-saturate, first, we are actually going to discover how it compares to a purposefully mastered lower nit version of itself. If I have a 4000 nit master, and compare it to a 100 nits master of content I created myself, THEN and only then can you say with 100% certainty that something is adding or removing saturation. Such as this:


The above preliminary testing shows at least in regards to an HDR encoded rec709 master, MadVR is indeed doing 100% exactly the right thing, and by extension the Envy would be too, with the above test. However higher/wider colour gamuts need to be investigated if they follow suit or if there is a bug somewhere there with tone mapping then.

I wish to improve on this, but there is no standard, and you cannot actually prove without a doubt that one is incorrect and the other is correct unless doing the test I mentioned above, and I want to show this so others can concur, I am not just going to accept word of mouth on this subject, we should ideally all be able to replicate the findings.

Now, if we do this test, and I can prove that MadVR is actually correct all along, then damn, I will eat my hat, you know why, because I wont like it, and it would also mean that a lot of UHD blurays are indeed encoded with a lot more colour than most of us thought (everybody not running 1000+ nits commercial displays - incl OLED) So, we really need to further deep dive if this is scientific fact or not!

Correct or not though, to my eyes subjectively (and a lot of other people now) in certain scenarios more often than not, there is too much saturation with MadVR's tone mapping at times (subjectively) and honestly, I am going to pursue the saturation thing as its own drop box like you have now for contrast, shadow etc, and personally I will just run it off and get hue perfect tone mapping but with the saturation levels we get now with the 'dumb' mode.

It DOES already exist way back in the development (beta version 10), I can roll back to a specific version which does it and it looks outstanding while at the same time being hue perfect colour. See here:

See here (look at all pics all the way to bottom of page many examples): Improving Madvr HDR to SDR mapping for projector

Mathias added 'saturation recovery' after that build because there were proven specific scenarios where tone mapping down to low levels <100 nits definitely resulted in fairly heavy de-saturation compared to the original master at brighter levels which is unfortunately unavoidable, so, some things were added to hopefully bring some of that saturation back, but its intention was at no point to actually boost it, but only to recover it! Hence I think that option should be forked out and called Saturation Recovery. this actually should be quite simple for Mathias to roll back IMO and fork out the further part of the algo at least that way we have a testing starting point, I wager even that will bring it immediately right back in line and neck and neck with the way the lumagen is handling it, in saying that, there was a reason back then why it further evolved from there and it was not borne out of just trying to cook the colour.

So, I, and others should stop saying its broken. Until I see actual evidence otherwise, in a comparison of sorts (100 ant 4000 nit masters custome made for eg), not heresay, its only fair to say it needs further deep investigation.

I am going to be looking in to all of this until Mathias and I, and the other community testers are satisfied before I actually submit any kinds of comparisons here between Lumagen and Envy, I think thats fair. Otherwise if I did that, then we go in and resolve some things or make DTM much improved, I would have wasted my time and I am not about to do that.

Phew! Long post :)
Very interesting! Looking forward to your further investigation, findings and report. Thank you for doing this! 🙂
 

·
Premium Member
Joined
·
460 Posts
Great stuff @Javs - thanks for this!
It goes exactly into the direction i´m thinking that it first needs to be defined what is the benchmark and what do we actually define as a (correct) target, before doing comparisons.
 
  • Like
Reactions: Manni01 and Javs

·
Registered
JVC RS4500 | ST130 G4 135" | MRX 720 | MC303 MC152 | 6.1.4: B&W 802D3, 805D3, 702S2 | 4x15 IB Subs
Joined
·
9,016 Posts
You might want to check that. Roku has not even started shipping the player that can do atmos. Supposed to start shipping today.
Roku launches new Ultra player with Dolby Vision & Atmos
Roku 4 / Ultra passes atmos direct bitstream to the AVR just fine. The plex client, for example, works this way just fine. I've tested it a lot. Perhaps the announcement was some sort of ability to decode atmos into Multi channel PCM.
 
661 - 680 of 745 Posts
Top