MadVR - ArgyllCMS - Page 153 - AVS Forum | Home Theater Discussions And Reviews
Forum Jump: 
 488Likes
Reply
 
Thread Tools
post #4561 of 4587 Old 05-12-2017, 06:47 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,994
Mentioned: 37 Post(s)
Tagged: 0 Thread(s)
Quoted: 526 Post(s)
Liked: 490
I'm confused right now. I don't think we're on the same page.

Situation A):

The user does not have a meter. He has an HDR display, but the display's tone mapping sucks, so he wants madVR to convert HDR videos to SDR, so the TV doesn't even know it's displaying HDR content. The user has the choice to either let madVR do the HDR -> SDR conversion by using pixel shader math, which works well but costs a lot of GPU performance. Alternatively the user can create a HDR -> SDR conversion 3dlut. This 3dlut receives PQ data on the input side, and outputs 2.222 gamma data on the output side. The 3dlut converts to a gamut the user selected (e.g. BT.709), using a peak display luminance value the user selected (e.g. 400 nits).

So in short: The 3dlut input is PQ BT.2020 10000 nits. The 3dlut output is Gamma 2.222 BT.709 400 nits.

Situation B):

The user does not have a meter. He has an HDR display, but the display's tone mapping sucks. However, the display has a special HDR mode which squeezes some additional brightness out of the backlight, so the user wants to put the display into HDR mode. But the user still wants the tone mapping to be done by madVR. The user has the choice to either let madVR do the tone mapping by using pixel shader math, which works well but costs a lot of GPU performance. Alternatively the user can create a HDR -> HDR conversion 3dlut. This 3dlut receives PQ data on the input side, and outputs PQ data on the output side. The 3dlut tone maps the source's BT.2020 (or DCI-P3) gamut to a gamut the user selected (e.g. BT.709), using a peak display luminance value the user selected (e.g. 400 nits).

So in short: The 3dlut input is PQ BT.2020 10000 nits. The 3dlut output is PQ BT.709 400 nits.

-------

Do you agree with me that the two 3dluts from situation A) and B) are *TOTALLY* different? Not only the header is different, but also the 3dlut data is totally different. If you agree with that, then it follows logically that the only way for the user to create 3dluts for situation A) and B) is that DisplayCAL needs to offer an option to create a 3dlut for either situation A) or B). Right?

Whether or not the header contains a flag that identifies a 3dlut as being A) or B) doesn't even matter much here. I don't see how DisplayCAL would possibly know whether to create a 3dlut for situation A) or B) if DisplayCAL doesn't have an option which lets the user choose A) or B)?

-------

All that said, DisplayCAL currently only supports A), and if you don't want to add support for B) that's ok with me. But if you do want to support option B) then I don't see how you could possibly do that without giving the user a control to choose if he wants A) or B)?

Or am I missing something obvious?

P.S: madTPG doesn't support HDR yet, planned for a future version.
madshi is offline  
Sponsored Links
Advertisement
 
post #4562 of 4587 Old 05-12-2017, 06:55 AM
Advanced Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 851
Mentioned: 37 Post(s)
Tagged: 0 Thread(s)
Quoted: 424 Post(s)
Liked: 280
Quote:
Originally Posted by madshi View Post
Do you agree with me that the two 3dluts from situation A) and B) are *TOTALLY* different? Not only the header is different, but also the 3dlut data is totally different. If you agree with that, then it follows logically that the only way for the user to create 3dluts for situation A) and B) is that DisplayCAL needs to offer an option to create a 3dlut for either situation A) or B). Right?
Yes, but that option is already there (or rather, there is nothing special necessary to support this, all the user needs to do is measure the display in HDR mode, or create a synthetic HDR destination profile), the only thing missing is the correct header so the user can actually create a 3D LUT that madVR will accept in situation B).
The only thing DisplayCAL currently can't do is switch the display into HDR mode itself automatically during measurements in case you want to create a profile from actual measurements.

Quote:
Originally Posted by madshi View Post
P.S: madTPG doesn't support HDR yet, planned for a future version.
Cool, Argyll CMS will need to support it as well in dispcal/dispread before I can implement support in DisplayCAL anyway (although I could hack around that limitation).

DisplayCAL - Graphical front-end for Argyll CMS display calibration and characterization
Current stable version 3.2.4 released 2017-02-19
Current development snapshot: 3.2.8 Beta (Windows/0install) released 2017-05-20 | Standalone | Changelog
DisplayCAL on Facebook
fhoech is offline  
post #4563 of 4587 Old 05-12-2017, 07:22 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,994
Mentioned: 37 Post(s)
Tagged: 0 Thread(s)
Quoted: 526 Post(s)
Liked: 490
Quote:
Originally Posted by fhoech View Post
Yes, but that option is already there (or rather, there is nothing special necessary to support this, all the user needs to do is measure the display in HDR mode, or create a synthetic HDR destination profile)
If the user creates a synthetic HDR destination profile then you already know everything you need to know, so you can write the 3dlut header correctly, without having to add a new user control. Or am I wrong?

So the only problem is when measuring the display. In that situation currently you don't have to ask the user whether the display was/is in HDR mode when the measurements are taken, right? In order to write the 3dlut header correctly, you need to know that, so you'd have to ask the user, which you currently don't need. Is that correct?

Hmmm... Can you currently even properly measure the display in HDR mode at all? None of the test pattern generators currently supports it, do they? Won't you have to add a user control in the future, anyway, in order to tell the test pattern generators to draw HDR vs SDR test patterns?
madshi is offline  
 
post #4564 of 4587 Old 05-12-2017, 08:00 AM
Advanced Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 851
Mentioned: 37 Post(s)
Tagged: 0 Thread(s)
Quoted: 424 Post(s)
Liked: 280
Quote:
Originally Posted by madshi View Post
If the user creates a synthetic HDR destination profile then you already know everything you need to know, so you can write the 3dlut header correctly, without having to add a new user control. Or am I wrong?
The 3D LUT creation process does not have (and should not need) any details about how the destination profile was created.

Quote:
Hmmm... Can you currently even properly measure the display in HDR mode at all? None of the test pattern generators currently supports it, do they?
Only if there is a way to put the display into HDR mode manually.

Quote:
Won't you have to add a user control in the future, anyway, in order to tell the test pattern generators to draw HDR vs SDR test patterns?
Yes, but that should be the only option pertaining to whether HDR is used or not (because really the only thing that cares about this little detail is the test pattern generator itself, because it needs to put the display into HDR mode).

DisplayCAL - Graphical front-end for Argyll CMS display calibration and characterization
Current stable version 3.2.4 released 2017-02-19
Current development snapshot: 3.2.8 Beta (Windows/0install) released 2017-05-20 | Standalone | Changelog
DisplayCAL on Facebook
fhoech is offline  
post #4565 of 4587 Old 05-12-2017, 09:07 AM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,994
Mentioned: 37 Post(s)
Tagged: 0 Thread(s)
Quoted: 526 Post(s)
Liked: 490
I can understand that DisplayCAL has separate tasks split into separate modules with limited communication flow between them. However, from a naive user point of view, when creating a 3dlut with a synthetic HDR destination profile it sounds reasonable enough (to me) to expect the resulting 3dlut to contain basic information about the destination profile.

Anyway, if you prefer, I can remove the extra header check from madVR. It would cost me only 2 minutes of my time to comment that code out. However, the end result would be that users could load the wrong 3dlut into the wrong section in madVR and there would be no complaints, but still the image would look obviously wrong (e.g. totally washed out). I'm not sure if that's the best approach for usability.

What do you think?
madshi is offline  
post #4566 of 4587 Old 05-13-2017, 05:46 AM
Advanced Member
 
James Freeman's Avatar
 
Join Date: Sep 2013
Posts: 755
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 515 Post(s)
Liked: 340
Quote:
Originally Posted by fhoech View Post
This release brings HDR 3D LUT (BT.2020 & ST.2084) improvements, namely roll-off according to BT.2390 (hermite spline at the top end, black level lift similar to BT.1886 but with tapering factor at the dark end) and a simple form of tone mapping.

Example screen capture of Sony "Camp" HDR demo @ 400 cd/m2 peak luminance (TV gamut roughly Rec. 709):


How to set up DisplayCAL to create a HDR to SDR 3D LUT:

Set HDR peak luminance according to the capability of your display. I wouldn't recommend below 265 cd/m2.
Black output offset controls if there's roll-off at the dark end (0% black output offset = BT.2390), which is similar to BT.1886, or if the whole curve is offset and scaled by the black level (100% output offset).

I've also tweaked the perceptual intent gamut mapping to give better preservation of saturated colors than normally, but I would still recommend colorimetric as it should preserve saturations even better (the above screen capture is from a colorimetric 3D LUT). Note that despite colorimetric normally clipping, there's now always a form of tone mapping when SMPTE 2084 roll-off is selected.

Enjoy!


FANTASTIC!!

After calibrating my Dell U2410 in Wide-Gamut mode and producing a HDR->SDR 3DLUT 2084 (roll-off) at 600nit, I can finally see true P3 color space and utilize my monitor maximum brightness, it looks freaking amazing!
Funny that only in 2017 I can finally utilize the full potential of a 2010 wide-gamut SDR monitor.

Thank you so much Florian, Graeme, and Madshi, for these options.


BTW, my trusty old Dell U2410 covers pretty well P3 (in CIE u'v') but lacks just a smudge in greens.
I think it'll do quite well till I purchase a next gen 4K, Wide-Gamut, HDR, Variable-Refresh-rate PC monitor.
fhoech likes this.

Last edited by James Freeman; 05-13-2017 at 06:14 AM.
James Freeman is offline  
post #4567 of 4587 Old 05-13-2017, 08:11 AM
Advanced Member
 
James Freeman's Avatar
 
Join Date: Sep 2013
Posts: 755
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 515 Post(s)
Liked: 340
Quote:
Originally Posted by madshi View Post
For the madVR option "convert HDR content to SDR by using an external 3dlut", the 3DLUT must have "Input_Transfer_Function PQ" in the header, I think, but no "Output_Transfer_Function" specified, or at least not set to "PQ". This tells madVR that this 3DLUT wants to get PQ data as input, and that the output of the 3DLUT requires the display to be in SDR mode to look right.
When using the pixel-shader HDR->SDR the output curve is decided by the Calibration tab in madVR.
What then madVR decides to use as output gamma curve when using HDS->SDR 3DLUT?
I would assume that it takes the calibration values I chose in DisplayCAL, just like a standard SDR 3DLUT?

Quote:
Originally Posted by madshi View Post
However, the end result would be that users could load the wrong 3dlut into the wrong section in madVR and there would be no complaints, but still the image would look obviously wrong (e.g. totally washed out). I'm not sure if that's the best approach for usability.
As an end user with some experience with calibration and various EOTFs and 3D LUT, etc.. I got confused myself till I read that it is only for the 2084 tone curve.
I would say removing the warnings would be a bad idea and will generate a lot of complaint from new users.
MadVR is not "just press play" type of software in itself and has a steep learning curve, there is not need to generate further hidden mysteries and confusion.
IMO, don't remove the warnings.

Last edited by James Freeman; 05-14-2017 at 12:17 AM.
James Freeman is offline  
post #4568 of 4587 Old 05-13-2017, 04:26 PM
Advanced Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 851
Mentioned: 37 Post(s)
Tagged: 0 Thread(s)
Quoted: 424 Post(s)
Liked: 280
Quote:
Originally Posted by madshi View Post
I can understand that DisplayCAL has separate tasks split into separate modules with limited communication flow between them.
Most of the inter-connected tasks have a relatively seamless integration, with metadata traveling along the chain.

Quote:
Originally Posted by madshi View Post
However, from a naive user point of view, when creating a 3dlut with a synthetic HDR destination profile it sounds reasonable enough (to me) to expect the resulting 3dlut to contain basic information about the destination profile.
But that is simply not the main use of a display profiler, it's a very specific (and, as far as I'm concerned and from what I can tell, seldomly used) corner case. Synthetic profiles should normally be used as working (source) spaces, not makeshift device profiles, which is a function they simply cannot adequately fill (because they were never really intended to). This is especially true for PQ, where the actual device response could easily still be vastly different from any idealized synthetic response, and an almost identity PQ -> PQ transform is not really all that useful (you wouldn't do that for SDR as well, source gamma 2.2 -> synthetic 2.x would only make sense if you know the actual .x is sufficiently different from .2).

Quote:
Originally Posted by madshi View Post
Anyway, if you prefer, I can remove the extra header check from madVR. It would cost me only 2 minutes of my time to comment that code out.
I'm unsure about the best way forward for madVR, so I'll leave that up to you. For DisplayCAL I'm not in a particular hurry and probably going to wait for HDR metadata support in madTPG. Currently I'm more interested in having actual display profiles measured in HDR mode supported for 3D LUT creation, and as it turns out this can already be achieved by simply loading the 3D LUT in the "convert HDR to SDR" slot (of course, this requires a display that can be manually switched to HDR mode, but seems to work as intended, judging from early user feedback I got).

DisplayCAL - Graphical front-end for Argyll CMS display calibration and characterization
Current stable version 3.2.4 released 2017-02-19
Current development snapshot: 3.2.8 Beta (Windows/0install) released 2017-05-20 | Standalone | Changelog
DisplayCAL on Facebook
fhoech is offline  
post #4569 of 4587 Old 05-14-2017, 12:28 AM
Advanced Member
 
James Freeman's Avatar
 
Join Date: Sep 2013
Posts: 755
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 515 Post(s)
Liked: 340
When calibrating, profiling and creating a 3DLUT for HDR->SDR;
Wouldn't it result in more accurate colors if I actually calibrate to my displays maximum backlight brightness, instead letting DisplayCAL do-the-math and calculate/stretch from 100nit to whatever HDR peak nit I select?
In other words, should I calibrate to the actual display setting I would use (including maximum brightness) when watching HDR->SDR with the resulting 3DLUT?

The resulting HDR->SDR 3DLUT looks great even from a 100bit calibration to a 600nit peak 2084 setting, I only raise the brightness to maximum when watching HDR movie with madVR.
I assume DisplayCAL and ArgyllCMS calculations are very sophisticated considering the time they take, and any 'stretching' is done more than adequately.

Last edited by James Freeman; 05-14-2017 at 12:37 AM.
James Freeman is offline  
post #4570 of 4587 Old 05-14-2017, 05:35 PM
Member
 
crestron's Avatar
 
Join Date: Feb 2007
Posts: 20
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 10
Quote:
Originally Posted by fhoech View Post
Most of the inter-connected tasks have a relatively seamless integration, with metadata traveling along the chain.


But that is simply not the main use of a display profiler, it's a very specific (and, as far as I'm concerned and from what I can tell, seldomly used) corner case. Synthetic profiles should normally be used as working (source) spaces, not makeshift device profiles, which is a function they simply cannot adequately fill (because they were never really intended to). This is especially true for PQ, where the actual device response could easily still be vastly different from any idealized synthetic response, and an almost identity PQ -> PQ transform is not really all that useful (you wouldn't do that for SDR as well, source gamma 2.2 -> synthetic 2.x would only make sense if you know the actual .x is sufficiently different from .2).


I'm unsure about the best way forward for madVR, so I'll leave that up to you. For DisplayCAL I'm not in a particular hurry and probably going to wait for HDR metadata support in madTPG. Currently I'm more interested in having actual display profiles measured in HDR mode supported for 3D LUT creation, and as it turns out this can already be achieved by simply loading the 3D LUT in the "convert HDR to SDR" slot (of course, this requires a display that can be manually switched to HDR mode, but seems to work as intended, judging from early user feedback I got).
I think for the projector users are good, such as my Epson 5040 can manually open the HDR mode, and the projector's CMS is not enough precision, perhaps I understand the projector's HDR a correction method.
crestron is offline  
post #4571 of 4587 Old 05-14-2017, 11:56 PM
Newbie
 
Join Date: Mar 2016
Posts: 5
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 0
Quote:
Originally Posted by fhoech View Post
ST.2084 is an absolute curve, i.e. each encoded digital level maps to a specific output luminance. It's no problem to adjust the output, just keep in mind that you then move away from "strict" ST.2084. Generally I would recommend not going much below 400 nits HDR peak luminance for the 3D LUT (irrespective of what your display is capable of). If your display can do a max of (say) 400 nits as well, and you want to keep the same ratio as for SDR (i.e. 50% in your case with 50 nits, assuming 100 nits nominal), then you could double the HDR peak luminance (e.g. 800 instead of 400) to get the desired contrast adjustment (with the display actually calibrated to 400).
Ok, thanks. Another question related to this that I have is regarding gamma for HDR in dark room. Let’s suppose we have a reference display that is hardware calibrated at perfect 2.2 gamma. As PQ is linear by definition, so an HDR to SDR 3DLUT will gamma encode the content with the inverse of 2.2 gamma after tone mapping such that it appears linear on the reference display (I know a 3DLUT doesn't work like this but effectively it will do the same). The content will appear linear to the eyes of the viewer when the room has studio like dim lighting as the HDR content would have been mastered in those conditions. Now if the user switches Off all lights and makes the room completely dark through curtains and all, the same content will be no more linear to the viewer’s eyes. In this case, the 3DLUT should apply some gamma to the PQ content such that when the content is viewed on the reference display, the PQ content is presented with a slight gamma instead of being linear such that in the dark room it appears linear to the eyes of the viewer. Do you agree with this? If yes, is it possible to add this gamma correction (if it’s the right word) to an HDR to SDR 3DLUT via DisplayCAL?
omarank is offline  
post #4572 of 4587 Old 05-15-2017, 05:51 AM
Newbie
 
Join Date: May 2017
Posts: 3
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 2 Post(s)
Liked: 0
Hi fhoech
I do not have a meter. Is there any possibility to create a HDR -> SDR conversion 3dlut for madvr ?when i try to create it the 3d button and verification button are washed out .
Abdo Esmaeal is offline  
post #4573 of 4587 Old 05-15-2017, 11:24 AM
Advanced Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 851
Mentioned: 37 Post(s)
Tagged: 0 Thread(s)
Quoted: 424 Post(s)
Liked: 280
Quote:
Originally Posted by Abdo Esmaeal View Post
Hi fhoech
I do not have a meter. Is there any possibility to create a HDR -> SDR conversion 3dlut for madvr ?
Yes. What's your display make and model?
Abdo Esmaeal likes this.

DisplayCAL - Graphical front-end for Argyll CMS display calibration and characterization
Current stable version 3.2.4 released 2017-02-19
Current development snapshot: 3.2.8 Beta (Windows/0install) released 2017-05-20 | Standalone | Changelog
DisplayCAL on Facebook
fhoech is offline  
post #4574 of 4587 Old 05-15-2017, 04:34 PM
Member
 
Bloodwound's Avatar
 
Join Date: Apr 2007
Posts: 175
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 111 Post(s)
Liked: 31
fhoech. It seems to me black offset is backwards. Meaning 100% equals no offset and 0% equals black level offset (like bt.1186). What is the rationale behind this?
Bloodwound is online now  
post #4575 of 4587 Old 05-15-2017, 08:54 PM
Newbie
 
Join Date: May 2017
Posts: 3
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 2 Post(s)
Liked: 0
My display is - Samsung SM2333T - its not hdr display .thanks for your hard work on DisplayCAL ,and sorry for my bad english .
Abdo Esmaeal is offline  
post #4576 of 4587 Old 05-16-2017, 02:43 AM
Advanced Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 851
Mentioned: 37 Post(s)
Tagged: 0 Thread(s)
Quoted: 424 Post(s)
Liked: 280
Quote:
Originally Posted by Bloodwound View Post
fhoech. It seems to me black offset is backwards. Meaning 100% equals no offset and 0% equals black level offset (like bt.1186). What is the rationale behind this?
It's black output offset. So 0% output offset is 100% input offset.

Quote:
Originally Posted by Abdo Esmaeal View Post
My display is - Samsung SM2333T - its not hdr display .thanks for your hard work on DisplayCAL ,and sorry for my bad english .
Use the standalone tools. First, create a synthetic profile with the Synthetic ICC Creator. Choose the "Rec. 709" preset and set tone curve to custom gamma 2.4. Save the profile. Then, open the 3D LUT maker and set the created profile under "Target profile". Set source profile to BT.2020 and tone curve to SMPTE 2084 (roll-off).
Abdo Esmaeal likes this.

DisplayCAL - Graphical front-end for Argyll CMS display calibration and characterization
Current stable version 3.2.4 released 2017-02-19
Current development snapshot: 3.2.8 Beta (Windows/0install) released 2017-05-20 | Standalone | Changelog
DisplayCAL on Facebook
fhoech is offline  
post #4577 of 4587 Old 05-16-2017, 06:28 AM
Newbie
 
Join Date: May 2017
Posts: 3
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 2 Post(s)
Liked: 0
OK , thanks alot fhoech
Abdo Esmaeal is offline  
post #4578 of 4587 Old 05-16-2017, 06:44 AM
Advanced Member
 
James Freeman's Avatar
 
Join Date: Sep 2013
Posts: 755
Mentioned: 6 Post(s)
Tagged: 0 Thread(s)
Quoted: 515 Post(s)
Liked: 340
For a typical PC monitor I would create a synthetic profile with the following settings:
White level to 100, Black level 0.1.
Gamma 2.2 Relative, Output offset 70%.

On my PC display calibrating to Gamma 2.2. Relative, Output-Offset 70% results in exactly the same gamma curve as without calibration at the black region.
This is a typical black compensated 2.2 gamma curve for 1000:1 PC displays, I would start with that.

The resulting HDR->SDR 3DLUT is quite nice even with a synthetic profile.
Go for 400 to 600 nit, and turn the brightness to maximum in your display when watching with this 3DLUT..
Usually on a PC monitor the "Brightness" control is backlight intensity..... usually.

Last edited by James Freeman; 05-16-2017 at 06:49 AM.
James Freeman is offline  
post #4579 of 4587 Old 05-17-2017, 11:30 PM
Senior Member
 
Soulnight's Avatar
 
Join Date: Dec 2011
Location: Germany
Posts: 403
Mentioned: 15 Post(s)
Tagged: 0 Thread(s)
Quoted: 261 Post(s)
Liked: 169
Quote:
Originally Posted by madshi View Post
I'm confused right now. I don't think we're on the same page.

Situation A):

The user does not have a meter. He has an HDR display, but the display's tone mapping sucks, so he wants madVR to convert HDR videos to SDR, so the TV doesn't even know it's displaying HDR content. The user has the choice to either let madVR do the HDR -> SDR conversion by using pixel shader math, which works well but costs a lot of GPU performance. Alternatively the user can create a HDR -> SDR conversion 3dlut. This 3dlut receives PQ data on the input side, and outputs 2.222 gamma data on the output side. The 3dlut converts to a gamut the user selected (e.g. BT.709), using a peak display luminance value the user selected (e.g. 400 nits).

So in short: The 3dlut input is PQ BT.2020 10000 nits. The 3dlut output is Gamma 2.222 BT.709 400 nits.
I would like to use the HDR to SDR conversion using madvr pixel shader math, However my display (projector Epson EH-LS10000) can track perfectly DCI-D65 with gamma 2.2.
How can I tell madvr the wanted ouput gamut? HDR is not only about brightness but also more saturated color. And right now it seems to always only output REC709...

I also did a rec2020 calibration on the PJ which tracks well within the DCI.

Thank you!
Florian
Soulnight is online now  
post #4580 of 4587 Old 05-17-2017, 11:49 PM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,994
Mentioned: 37 Post(s)
Tagged: 0 Thread(s)
Quoted: 526 Post(s)
Liked: 490
You can set the display calibration to "this display is already calibrated" to "DCI-P3" (or "BT.2020"), then madVR should output DCI-P3 (or BT.2020).
Soulnight likes this.
madshi is offline  
post #4581 of 4587 Old 05-18-2017, 01:36 AM
Newbie
 
Join Date: Mar 2016
Posts: 5
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 0
@fhoech : Just wanted to bring your attention to post#4571, in case you haven't seen. I wanted to know your view here.
omarank is offline  
post #4582 of 4587 Old 05-19-2017, 09:54 AM
Senior Member
 
Soulnight's Avatar
 
Join Date: Dec 2011
Location: Germany
Posts: 403
Mentioned: 15 Post(s)
Tagged: 0 Thread(s)
Quoted: 261 Post(s)
Liked: 169
Quote:
Originally Posted by madshi View Post
You can set the display calibration to "this display is already calibrated" to "DCI-P3" (or "BT.2020"), then madVR should output DCI-P3 (or BT.2020).
Thank you. It works perfectly. Very nice HDR to SDR with natural colorb which are sometimes naturally satuared on the few HDR demo that I own.

We have just created a group on facebook in Germany about Madvr/HTPC/Kodi, that would be awesome madshi if you could join!
Of course Florian Hoech as well since 3dlut is a wonderful tool as well.

Plese ask for membership and I will add you:
https://www.facebook.com/groups/129220307637167/

Thanks!
Florian
Soulnight is online now  
post #4583 of 4587 Old 05-19-2017, 05:57 PM
AVS Forum Special Member
 
madshi's Avatar
 
Join Date: May 2005
Posts: 5,994
Mentioned: 37 Post(s)
Tagged: 0 Thread(s)
Quoted: 526 Post(s)
Liked: 490
I'm not on Facebook, or any other social media...
BlueChris likes this.
madshi is offline  
post #4584 of 4587 Old Yesterday, 01:25 AM
Senior Member
 
Soulnight's Avatar
 
Join Date: Dec 2011
Location: Germany
Posts: 403
Mentioned: 15 Post(s)
Tagged: 0 Thread(s)
Quoted: 261 Post(s)
Liked: 169
Quote:
Originally Posted by madshi View Post
I'm not on Facebook, or any other social media...
While I do understand why, maybe you could create an account only as "madshi", madvr crazy programmer.
Please you would get to discuss with fellow german in german.
Soulnight is online now  
post #4585 of 4587 Old Yesterday, 07:08 AM
Advanced Member
 
fhoech's Avatar
 
Join Date: Apr 2013
Location: Stuttgart, Germany
Posts: 851
Mentioned: 37 Post(s)
Tagged: 0 Thread(s)
Quoted: 424 Post(s)
Liked: 280
Quote:
Originally Posted by omarank View Post
Another question related to this that I have is regarding gamma for HDR in dark room. Let’s suppose we have a reference display that is hardware calibrated at perfect 2.2 gamma. As PQ is linear by definition, so an HDR to SDR 3DLUT will gamma encode the content with the inverse of 2.2 gamma after tone mapping such that it appears linear on the reference display (I know a 3DLUT doesn't work like this but effectively it will do the same). The content will appear linear to the eyes of the viewer when the room has studio like dim lighting as the HDR content would have been mastered in those conditions. Now if the user switches Off all lights and makes the room completely dark through curtains and all, the same content will be no more linear to the viewer’s eyes. In this case, the 3DLUT should apply some gamma to the PQ content such that when the content is viewed on the reference display, the PQ content is presented with a slight gamma instead of being linear such that in the dark room it appears linear to the eyes of the viewer. Do you agree with this? If yes, is it possible to add this gamma correction (if it’s the right word) to an HDR to SDR 3DLUT via DisplayCAL?
Any form of gamma (viewing environment) adjustment is currently not part of the HDR10 PQ standard. I also don't think it's needed for a dark environment, as the grading environment usually is dark as well - it would make more sense for viewing HDR content graded in such a dim environment, in a brighter environment. If such a gamma adjustment were to be implemented, I would assume it would make sense to apply it to the raw PQ values.

EDIT of course nothing is stopping you from playing with Argyll's collink CIECAM02 parameters by adding the respective command line options when creating 3D LUTs.

DisplayCAL - Graphical front-end for Argyll CMS display calibration and characterization
Current stable version 3.2.4 released 2017-02-19
Current development snapshot: 3.2.8 Beta (Windows/0install) released 2017-05-20 | Standalone | Changelog
DisplayCAL on Facebook

Last edited by fhoech; Yesterday at 07:13 AM.
fhoech is offline  
post #4586 of 4587 Old Yesterday, 08:25 PM
AVS Forum Special Member
 
mightyhuhn's Avatar
 
Join Date: Nov 2013
Posts: 1,434
Mentioned: 5 Post(s)
Tagged: 0 Thread(s)
Quoted: 746 Post(s)
Liked: 255
you can change the gamma with the madVR color & gamma settings. i haven't tried it with a HDR -> SDR 3D LUT but i don't see a reason it shouldn't work.

the created SDR signal should be some kind of gamma so it should work reasonable well.
mightyhuhn is offline  
post #4587 of 4587 Old Today, 09:36 AM
Newbie
 
Join Date: Mar 2016
Posts: 5
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 3 Post(s)
Liked: 0
Quote:
Originally Posted by fhoech View Post
Any form of gamma (viewing environment) adjustment is currently not part of the HDR10 PQ standard. I also don't think it's needed for a dark environment, as the grading environment usually is dark as well - it would make more sense for viewing HDR content graded in such a dim environment, in a brighter environment. If such a gamma adjustment were to be implemented, I would assume it would make sense to apply it to the raw PQ values.

EDIT of course nothing is stopping you from playing with Argyll's collink CIECAM02 parameters by adding the respective command line options when creating 3D LUTs.
Ok, I will try using CIECAM02 options in collink. But I just realised using madVR gamma processing would make it easy to test and apply the correction if required, as mightyhuhn suggested.

Quote:
Originally Posted by mightyhuhn View Post
you can change the gamma with the madVR color & gamma settings. i haven't tried it with a HDR -> SDR 3D LUT but i don't see a reason it shouldn't work.

the created SDR signal should be some kind of gamma so it should work reasonable well.
Right. I should have thought of that.
omarank is offline  
Sponsored Links
Advertisement
 
Reply Display Calibration



Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off