MadVR - ArgyllCMS - Page 40 - AVS Forum
First ... 38  39  40 41  42  ... Last
Display Calibration > MadVR - ArgyllCMS
zoyd's Avatar zoyd 07:47 AM 11-28-2013
Quote:
Originally Posted by Kukulcan View Post


Now since I see in your measures same 50% levels for post cal and post LUT, I'd answer no...no effect on higher greys. And that would be great! Is it clear my point? Can you confirm that it's only the black risen and not all the greys above?

I can not compare 1%,2%,3%... video levels (please don't use the term IRE, it is meaningless for digital video) pre and post cal because the pre-cal values are incorrect to begin with, since they are not calibrated to bt.1886. These levels will get lighter by design if you are starting from a flatter 2.2 gamma curve for example. All I can say is that these levels are very close to their intended target luminances:
Code:
......Target...Measured [cd/m^2]
1%    0.071    0.090
2%    0.110    0.112
3%    0.196    0.180
4%    0.268    0.260
5%    0.353    0.360


So from a calibration standpoint the performance is excellent, you can not do this with display controls at all. If however you feel that bt.1886 (technical version -IB) is not appropriate for your viewing environment or tastes then use something like -Ib:2.4 which will darken those levels a bit more.

Kukulcan's Avatar Kukulcan 08:31 AM 11-28-2013
Ok yes thanks, but wait, I meant a comparison between measures of 1%, 2%... video levels after loading the .cal file set with G2.4 -f0, and the same levels after the LUT. -G2.4 -f0 in dispcal, and -IB in collink, should give the same luminance target levels if they have the same starting piont (black level), right?
So I was curious about this comparison, if you have the data to provide it... In the calculator I found in this thread, with 145cd/m2 for white and 0.030 for black, the target at 5% should be 0,315 cd/m2. But I see in your post 0,353, which is the target if black is 0,041. So actually that small rise for the black have an effect on all higher levels.

My hope was that even though the 3dLUT cannot produce the same black of dispcal, the higher video level targets would still be calculated on the floor level of dispcal (0,030)
and not on that of the LUT(0,041). But this is not the case...

What do you think about my idea? I mean that the drop in contrast ratio would be almost invisible if all video level targets were calculated based on the original contrast ratio measured after dispcal, don't you agree with me? Ok that difference between 0 and 1% would not be correct, but only that one! Not all the higher ones...

Anyway don't get me wrong, I'm aware that this whole calibration system is way beyond anything else you can get even by a professional calibrator that has to deal with display controls...
zoyd's Avatar zoyd 09:40 AM 11-28-2013
Quote:
Originally Posted by Kukulcan View Post

My hope was that even though the 3dLUT cannot produce the same black of dispcal, the higher video level targets would still be calculated on the floor level of dispcal (0,030) and not on that of the LUT(0,041). But this is not the case...

I believe the targets are calculated based on the modeled black point so yes, it will generate a transfer function appropriate for the elevated black level. But again, we are talking about very very small shifts in luminance targets, there is more than enough latitude in the linking switch -Ib to account for it. In fact we're talking about a change in Ib from something like Ib:2.3 to Ib:2.305 to account for a 0.01 cd/m^2 shift, this is not something you will ever notice outside of measurements.

Here are the results using just the calibration:
Code:
......Target...Measured [cd/m^2]
1%    0.057    0.060
2%    0.094    0.080
3%    0.171    0.100
4%    0.238    0.200
5%    0.319    0.280

The targets are slightly lower as you would expect and measured values are on the low side of the targets by a higher margin than what collink produces. So from a calibrator's point of view dispcal does a poorer job of matching bt.1886 (even though it is darker) than the entire chain does. This could be the result of me allowing automatic dark hue correction or some other difference between fit weightings within dispcal and collink in achieving the desired transfer function.
kasper93's Avatar kasper93 10:58 AM 11-28-2013
Quote:
Originally Posted by gwgill View Post

It's recommended that the colprof -V parameter be used less aggressively, i.e. -V1.6 rather than -V2.0, and the default value carried over from targen will be automatically adjusted by colprof to make this the case.

I'm not sure if I understand correctly. I should use targen with V2.0 and then colprof with V1.6 or 1.6 for both?
VerGreeneyes's Avatar VerGreeneyes 11:41 AM 11-28-2013
Quote:
Originally Posted by kasper93 View Post

I'm not sure if I understand correctly. I should use targen with V2.0 and then colprof with V1.6 or 1.6 for both?
If you use -V2.0 for targen, this will automatically carry over to colprof which will use 2.0^0.7 = 1.6 unless you override it by supplying your own.
kasper93's Avatar kasper93 11:51 AM 11-28-2013
That's what I though, thanks for explanation.
zoyd's Avatar zoyd 12:06 PM 11-28-2013
@Graeme

A suggestion I have (if it makes sense), is to add a corollary to the -V function for dispcal that would scale the dE calculation used for optimization to a reference white that is 15% of peak white. This would weight optimization towards a viewer who is luminance level adapted to typical average video luminance in a dim environment.
MonarchX's Avatar MonarchX 04:08 PM 11-28-2013
Original black rounded in HCFR - 0.04

dispwin.exe -v -c
dispcal.exe -v2 -dmadvr -c1 -yn -X CCFLFamily_07Feb11.ccss -qh -m "-w0.3127,0.329" -G2.4 -f0 -k0 -A4.0 "dispcal"
targen.exe -v -d3 -e4 -B4 -s33 -g97 -m9 -b9 -f0 -N1.0 -V1.6 -p1.0 ".ti1 name"
dispwin.exe -dmadvr -s dispcal.cal
dispread.exe -v -dmadvr -c1 -yn -X CCFLFamily_07Feb11.ccss -k dispcal.cal ".ti1 name"
colprof.exe -v -qh -bl -aX -V1.6".ti3 name"
collink.exe -v -qh -G -iaw -3m -et -Et -IB:2.4 -a dispcal.cal Rec709.icm .icm name ".3dlut name"

3D LUT black rounded in HCFR - 0.04, but to get exact coordinates I had to make one click in brightness! This is amazing, but what is also amazing is that I can raise my contrast from 77 to 82 without much penalty to image accuracy! The overall accuracy has dramatically improved since the official 1.6.2 version.

So, I am still confused, whether you use dispcal -G2.4 or dispcal -g2.2 and then use collink -IB or collink -ib2.2 or collink IB:2.4 - you still get the same exact BT.1886 curve when using Rec709.icm reference profile for collink... If you use Rec709_Gamma22.icm for collink reference profile then you used to get regular power law 2.2 flat gamma, but blacks were significantly raised. When you use Rec709_Gamma22.icm with either collink -Ib:2.2 or -IB you get a complete messed up gamma of 2.55 and strange curve...

I thought that these changes would allow for little to no black rise and power law 2.2 flat gamma curve.
gwgill's Avatar gwgill 04:18 PM 11-28-2013
Quote:
Originally Posted by zoyd View Post

@Graeme

A suggestion I have (if it makes sense), is to add a corollary to the -V function for dispcal that would scale the dE calculation used for optimization to a reference white that is 15% of peak white. This would weight optimization towards a viewer who is luminance level adapted to typical average video luminance in a dim environment.
Hmm. I'm not sure exactly how that would work. The recent dispcal already scales the tollerance threshold to be not more than half the target step size (down to a limit of 0.05 dE), and with typical calibration curves this seem to make the tolerance ridiculously small, resulting in the iteration typically having to give up. [ A pure power curve is extremely ridiculous, resulting in target dE's of something like 0.00001 ]

Given the quantization and inconsistency in the display+instrument near black, I suspect that the point by point approach that dispcal uses is not actually optimal, and that a more statistical approach might make more efficient use of the number of readings. I did start with something like that when I originally wrote dispcal, but didn't have much success, winding up with the rather brute force approach it currently uses.
N3W813's Avatar N3W813 04:21 PM 11-28-2013
Quote:
Originally Posted by MonarchX View Post

If you use Rec709_Gamma22 for collink reference profile then you do get regular power law 2.2 gamma, but blacks are significantly raised.

You are using the Rec709_Gamma22.icm from a DispcalGUI install correct? Please do not use this source ICM when using ArgyllCMS's collink.exe. In my experience (as well as others in this thread), using this icm as a source does not generate an accurate 3dlut. I'm not quite sure what is 'wrong' with this source icm. I've also tried creating my own custom icm file with a rec709 gamut and power law 2.2 gamma, but collink still cannot produce a correct 3dlut. AFAIK, there is no easy way currently to generate a 3dlut with a power law 2.2 gamma curve.

BTW, using Ib:2.2 and IB:2.4 results in different gamma curves for my 3dluts. Slightly different, but definitely measurable.
zoyd's Avatar zoyd 05:51 PM 11-28-2013
Quote:
Originally Posted by N3W813 View Post


BTW, using Ib:2.2 and IB:2.4 results in different gamma curves for my 3dluts. Slightly different, but definitely measurable.

yes, Ib:2.2 sets gamma at the 50% video level to 2.2 regardless of black level, while for IB the 50% video level varies with black level but is typically between 2.2 and 2.3. If you have a zero black level, IB gamma will equal 2.4 for all video levels and Ibx.x will equal x.x for all levels.
zoyd's Avatar zoyd 05:58 PM 11-28-2013
Quote:
Originally Posted by gwgill View Post

Hmm. I'm not sure exactly how that would work.

What I imagined was that meeting the pass/fail criteria (I think it's 0.6 for -qm) would be harder at certain levels so more iterations would be forced:

Normal peak white reference


15% peak white reference luminance


So for example in the second case the 60% level moves the furthest (2.45 dE vs. 1.33 dE) and the program would have to work harder relative to the other points to meet pass criteria.
gwgill's Avatar gwgill 06:21 PM 11-28-2013
Quote:
Originally Posted by N3W813 View Post

You are using the Rec709_Gamma22.icm from a DispcalGUI install correct? Please do not use this source ICM when using ArgyllCMS's collink.exe. In my experience (as well as others in this thread), using this icm as a source does not generate an accurate 3dlut. I'm not quite sure what is 'wrong' with this source icm.

Note that the way the collink BT.1886 mapping works is to assume that the purpose of the source profile is to define the encoding space of the input, and it will only work with a matrix type profile because it needs to be able to convert input space decoded XYZ back into input space linear light RGB to be able to apply the BT.1886 transform.

The data flow is:

Input RGB space -> input profile -> XYZ -> input matrix^-1 -> linear light input RGB space -> Rec.709 encoding curve -> BT.1886 offset + gamma decode curve -> XYZ .... -> output profile -> display RGB.

So one way of interpreting this is that the BT.1886 option adds a "Rec709 encoded to BT.1886 decoder viewing conditions transformation".

I'll leave it to others to determine what a non Rec.709 input profile does to the resulting overall response curve.
gwgill's Avatar gwgill 06:35 PM 11-28-2013
Quote:
Originally Posted by zoyd View Post

So for example in the second case the 60% level moves the furthest (2.45 dE vs. 1.33 dE) and the program would have to work harder relative to the other points to meet pass criteria.
Right, but it already does this due to the log type spacing of the test points, and the target of ensuring that each step is monotonic, as detailed in http://www.avsforum.com/t/1471169/madvr-argyllcms/1170#post_24008620

See also http://www.avsforum.com/t/1471169/madvr-argyllcms/1020#post_23970468
MonarchX's Avatar MonarchX 06:47 PM 11-28-2013
Quote:
Originally Posted by N3W813 View Post

You are using the Rec709_Gamma22.icm from a DispcalGUI install correct? Please do not use this source ICM when using ArgyllCMS's collink.exe. In my experience (as well as others in this thread), using this icm as a source does not generate an accurate 3dlut. I'm not quite sure what is 'wrong' with this source icm. I've also tried creating my own custom icm file with a rec709 gamut and power law 2.2 gamma, but collink still cannot produce a correct 3dlut. AFAIK, there is no easy way currently to generate a 3dlut with a power law 2.2 gamma curve.

BTW, using Ib:2.2 and IB:2.4 results in different gamma curves for my 3dluts. Slightly different, but definitely measurable.

The same applies to sRGB.icm collnk usage with dispcal -gs gamma setting.


BTW, i1Profiler, while does not change color gamut, manages to create a very accurate 2.2 flat gamma for an .icm profile. It does suck though as it completely ignores the black end, which turns my blacks brown tongue.gif .
VerGreeneyes's Avatar VerGreeneyes 01:10 PM 11-29-2013
Ugh, I just tried the new dispcal with my ColorMunki Photo and the following commandline:
Code:
dispcal -m -v2 -dmadvr -qu -w 0.312713,0.329016 -g709 -a64 -k0 -H -Ibw "Acer P243W 2013-11-29-01"

... and it produced this thing (loaded into my laptop's videoLUT, so mislabeled):

Rf5W2cR.png
How could raising black that much ever be right? It looks awful ;_; Here's the .cal file itself: http://www.mediafire.com/view/ppr1mdv55jst9jg/Acer%20P243W%202013-11-29-01.cal. I'm retrying now with |-G2.4 -f0| as zoyd used, but man that was a depressing result after all this discussion about the black point. For reference, my black point before calibration is measured as XYZ 0.1639 0.1717 0.2735 (white as XYZ 89.894 94.842 100.608), so not great to begin with. Note I've had bad results much like this in the past, but I was hoping the recent changes had fixed it.

Edit: Actually, I'm going to try again first with the target brightness set to 100 cd/m² (and the actual brightness of the monitor set to 105 or so) to see if 'unclamping' the brightness will help.

Edit: Nope, that just lowered white a bit (as expected), but black is still just as high..
MonarchX's Avatar MonarchX 03:42 PM 11-29-2013
WOOAH! I just tried to get a 3DLUT for my ASUS VG248QE LightBoost monitor which has almost no controls in LightBoost mode.

The results were incredibly bad. I am not sure what I did wrong, but I attached 2 HCFR results - before and after 3D LUT application. I also provided a .cal file and some other files small enough to be uploaded! I like this monitor's super fast response time and would love to watch some movies with improved picture quality!

VG248QE.zip 315k .zip file

dispwin.exe -v -c
dispcal.exe -v2 -dmadvr -c1 -yn -X WLEDFamily_07Feb11.ccss -qh -m "-w0.3127,0.329" -G2.4 -f0 -k0 -A4.0 "LUT"
targen.exe -v -d3 -e4 -B4 -s40 -g128 -m9 -b9 -f1000 -N1.0 -V1.6 -p1.0 "TestChart"
dispread.exe -v -dmadvr -c1 -yn -X WLEDFamily_07Feb11.ccss -k LUT.cal "TestChart"
colprof.exe -v -qh -bl -aX -V1.6 "TestChart"
collink.exe -v -qh -G -iaw -3m -et -Et -IB:2.4 -a LUT.cal Rec709.icm TestChart.icm "madVR"

No offense, I think I did something wrong, but I can do better with regular Windows color management. biggrin.gif

Any ideas?
Attached: VG248QE.zip (315.5 KB) 
zoyd's Avatar zoyd 04:16 PM 11-29-2013
Quote:
Originally Posted by gwgill View Post

Right, but it already does this due to the log type spacing of the test points, and the target of ensuring that each step is monotonic, as detailed in http://www.avsforum.com/t/1471169/madvr-argyllcms/1170#post_24008620

See also http://www.avsforum.com/t/1471169/madvr-argyllcms/1020#post_23970468


ok, thanks and scratch that idea seeing as it already does something much like what I was thinking of.
gwgill's Avatar gwgill 04:29 PM 11-29-2013
Quote:
Originally Posted by VerGreeneyes View Post

Ugh, I just tried the new dispcal with my ColorMunki Photo and the following commandline:
Code:
dispcal -m -v2 -dmadvr -qu -w 0.312713,0.329016 -g709 -a64 -k0 -H -Ibw "Acer P243W 2013-11-29-01"

... and it produced this thing (loaded into my laptop's videoLUT, so mislabeled):

How could raising black that much ever be right?
It would be right if your display has a large dead band from black.
But if you think that's unlikely, than I'd need to see the "-v3" log to figure anything out.
VerGreeneyes's Avatar VerGreeneyes 04:41 PM 11-29-2013
Quote:
Originally Posted by gwgill View Post

It would be right if your display has a large dead band from black.
But if you think that's unlikely, than I'd need to see the "-v3" log to figure anything out.
I've had a raised black level like this before, and it's very visibly gray on the display (I can't attest to the accuracy of other colors if a lower black level is used though). I'm doing a run right now with a dirty hack in dispcal.c to use force_0 in a few places (in the same places as it currently does force_1, but not conditional on x.nat), and seeing what that does. But after that I'll get you a log with -v3.

Edit: Here's the log you requested: http://www.mediafire.com/view/l8irrr46053t764/log.txt

By the way, my hack did 'fix' the problem, in that it forced the black point in the LUT down to 0, but I think it caused it to generate some measurements below RGB(0, 0, 0), which isn't surprising I guess. Going to try again setting it to the measured black level as done higher up in the file, instead of 0.0.
Kukulcan's Avatar Kukulcan 06:46 AM 11-30-2013
Great!!! Finally black didn't rise. options below:
Warning: Spoiler! (Click to show)
dispwin -v -c
dispcal -v -dmadvr -yn -X ccflfamily_07Feb11.ccss -qh -w0.3127,0.329 -G2.4 -f0 -k0 -A4.0 "30nov"
targen -v -d3 -e4 -B4 -s33 -g97 -m9 -b9 -f0 -N1.0 -V1.6 -p1.0 "30nov"
dispread -v -dmadvr -yn -Xccflfamily_07Feb11.ccss -k30nov.cal "30nov"
colprof -v -qh -bl -aX -V1.6 "30nov"
collink -v -3m -qh -et -Et -G -IB:2.4 -iaw -a30nov.cal Rec709.icm 30nov.icm 30novlut.icm

Awesome results, accuracy seems the same with the exception that now black hasn't risen. But also very important, I noticed that all kind of minor artifacts in shadow areas are completely disappeared. Now the image is true reference. I posted previoulsy tests that had big artifacts, but even in the LUTs that were good and free of major issues, there was always some minimal quantization that appeared because of strange shadow hues. Well now with the new executables, image is free of any minimal problem. Thanks Graeme!!!

I will update the thread in an italian forum where I'm strongly pushing this solution, unknown by anyone, and now that these minor issues have been solved, I can easily say that this is a killer combination that can change a consumer grade display in almost a broadcast one with the plus of BT1886 processing. Ok well......anyway a LCD display won't become a Sony Trimaster Oled.

@Graeme

I know your opinion and Zoyd's one, but please think again whether it's possible to offer in collink the option for a transfer curve with power law and black point compensation. Don't get me wrong, with my Planar vpr (3.000:1 contrast ratio) I prefer BT1886, and with display with even higher dynamic range, in my opinion BT 1886 wins hands down. But for typical IPS lcd display with 1.000:1 of contrast, BT1886 may be questionable.... yes, it's rigorous about the correct shadow proportion, but with this low contrast parameter, BT 1886 pushes too high the shadows and the image sometines may look too flat.

Anyway again...thanks to you, madshi, Zoyd and all the other who has contributed to this great CMS solution.
MonarchX's Avatar MonarchX 07:12 AM 11-30-2013
Is it normal to get a lot of extra detail when using dispread.exe -f1000 instead of -f0 ? It really looks like there is a big improvement in overall details of the image, like facial details when you use -f1000.

If you use -f0 in dispcal.exe then does it mean that -f1000 in dispread.exe will have no effect or the same effect as using -f0 ?
Kukulcan's Avatar Kukulcan 07:27 AM 11-30-2013
I don't know what you're talking about, details sholudn't be involved at all. Anyway -f in dispcal is completely different from -f in targen (you wrote dispread but you probably meant targen)
MonarchX's Avatar MonarchX 02:22 PM 11-30-2013
Quote:
Originally Posted by Kukulcan View Post

I don't know what you're talking about, details sholudn't be involved at all. Anyway -f in dispcal is completely different from -f in targen (you wrote dispread but you probably meant targen)

Yes, I just realized that. I am just saying that I can see a difference in picture between using targen.exe -f0 and -f1000.
10k's Avatar 10k 02:58 PM 11-30-2013
Quote:
Originally Posted by Kukulcan View Post

Great!!! Finally black didn't rise. options below:
Warning: Spoiler! (Click to show)
dispwin -v -c
dispcal -v -dmadvr -yn -X ccflfamily_07Feb11.ccss -qh -w0.3127,0.329 -G2.4 -f0 -k0 -A4.0 "30nov"
targen -v -d3 -e4 -B4 -s33 -g97 -m9 -b9 -f0 -N1.0 -V1.6 -p1.0 "30nov"
dispread -v -dmadvr -yn -Xccflfamily_07Feb11.ccss -k30nov.cal "30nov"
colprof -v -qh -bl -aX -V1.6 "30nov"
collink -v -3m -qh -et -Et -G -IB:2.4 -iaw -a30nov.cal Rec709.icm 30nov.icm 30novlut.icm

Awesome results, accuracy seems the same with the exception that now black hasn't risen. But also very important, I noticed that all kind of minor artifacts in shadow areas are completely disappeared. Now the image is true reference. I posted previoulsy tests that had big artifacts, but even in the LUTs that were good and free of major issues, there was always some minimal quantization that appeared because of strange shadow hues. Well now with the new executables, image is free of any minimal problem. Thanks Graeme!!!
Thanks, that workflow worked perfectly for me. Black level raised by .001 which is almost definitely within the normal measurement variation of my colormunki display. Overall I get much lower dE across grayscale, primaries & secondaries, and color checker. Additionally green saturations on my set have been straightened out on the CIE chart (previously had a dog leg type pattern from 0-100%) so success all around. One thing I noticed immediately was that I'm getting a lot more shadow detail with a proper bt1886 gamma than with the somewhat flat 2.2 I was able to achieve with my TV's internal controls only.

What are you using to play media? I'm currently using xbmc and wmc for liveTV and it seems like incorporating a 3dlut is a major PITA. I guess the only true solution is to pick up one of the eecolor boxes smile.gif
N3W813's Avatar N3W813 03:22 PM 11-30-2013
Quote:
Originally Posted by MonarchX View Post

Yes, I just realized that. I am just saying that I can see a difference in picture between using targen.exe -f0 and -f1000.

'You' will need to determine the set of patches that works best for your specific display device. A patch set that works well for one device will not necessarily work well with others. It all depends on the behavior of the display device itself.

For example, for my Sharp Elite TV, I need to use a combination of neutral, single channel, large grid, and OFPS patches (4000 patches minimum) in order to generate a satisfactory 3DLUT (average dEs < 3). I have tried patch sets larger than 10,000. Although the 3DLUT generated does result in lower dEs, law of diminishing returns sets in and the time increase for the entire workflow is not worth it. I won't be able to perceive the difference visually anyway. wink.gif
MonarchX's Avatar MonarchX 04:12 PM 11-30-2013
Quote:
Originally Posted by N3W813 View Post

'You' will need to determine the set of patches that works best for your specific display device. A patch set that works well for one device will not necessarily work well with others. It all depends on the behavior of the display device itself.

For example, for my Sharp Elite TV, I need to use a combination of neutral, single channel, large grid, and OFPS patches (4000 patches minimum) in order to generate a satisfactory 3DLUT (average dEs < 3). I have tried patch sets larger than 10,000. Although the 3DLUT generated does result in lower dEs, law of diminishing returns sets in and the time increase for the entire workflow is not worth it. I won't be able to perceive the difference visually anyway. wink.gif

targen.exe -v -d3 -e4 -B4 -s40 -g128 -m9 -b9 -f1000 -N1.0 -V1.6 -p1.0 worked incredibly well for me.

Do I determine that simply with trial and error method? Or is there a guide of some sort?

Also, is there a hotkey in dispcalGUI to upload whichever LUT into videocard (dispwin.exe)? Games reset LUT, but I wonder if using a hotkey after starting a game can temporary force another LUT.
MonarchX's Avatar MonarchX 04:21 PM 11-30-2013
Quote:
Originally Posted by Kukulcan View Post

@Graeme

I know your opinion and Zoyd's one, but please think again whether it's possible to offer in collink the option for a transfer curve with power law and black point compensation. Don't get me wrong, with my Planar vpr (3.000:1 contrast ratio) I prefer BT1886, and with display with even higher dynamic range, in my opinion BT 1886 wins hands down. But for typical IPS lcd display with 1.000:1 of contrast, BT1886 may be questionable.... yes, it's rigorous about the correct shadow proportion, but with this low contrast parameter, BT 1886 pushes too high the shadows and the image sometines may look too flat.

Anyway again...thanks to you, madshi, Zoyd and all the other who has contributed to this great CMS solution.

I second that. I think that the way black level point is treated in ArgyllCMS prevents the possibility of a flat line gamma for most TVs/monitors. I wonder if there is a way to look at how i1Profiler does it and come up with something similar. Well, its actually possible to have a flat 2.2 gamma if you use -np with colprof.exe, but @ 10% IRE my gamma was 2.7, which surely crushed blacks. The best explanation I can think of is that the entire system was designed around BT.1886 gamma curve and to get a 2.2 flat gamma curve you need super-deep blacks.
VerGreeneyes's Avatar VerGreeneyes 04:45 PM 11-30-2013
Quote:
Originally Posted by MonarchX View Post

targen.exe -v -d3 -e4 -B4 -s40 -g128 -m9 -b9 -f1000 -N1.0 -V1.6 -p1.0 worked incredibly well for me.
Note that the -V parameter won't do anything in this setup unless you also attach a preconditioning profile with the -c parameter. You can use Rec709.icm for this, or if you already made a profile for your monitor you can use that one. Anyway, -f1000 will set the total amount of patches generated to 1000, which isn't that much (but hey, if it's enough for your display, great!). Though if -m9 and -b9 push the total amount of patches over 1k on their own, -f1000 won't do anything.

Edit: Actually yeah -m9 is completely redundant here I think, since its 9^3 points should overlap the 9^3 + 8^3 points of -b9. That will generate 9^3 + 8^3 = 1241 points on its own, so -f1000 also won't do anything. Oh, and I'm pretty sure -p1.0 matches the default, so you can leave that out too.

Edit 2: Also, since -b9 doesn't generate a perceptual distribution, -V1.6 won't do anything even if you do attach a profile. You'll have to use the perceptual equivalent instead (-f1483 -I) if you want the -V parameter to matter. Nope, wrong about that, didn't see the note at the bottom.

Edit 3: Well now I'm just confused. Maybe you don't need to attach a preconditioning profile if you use -V with -b, since it's not a perceptual distribution.
fhoech's Avatar fhoech 07:58 PM 11-30-2013
Quote:
Originally Posted by VerGreeneyes View Post

Note that the -V parameter won't do anything in this setup unless you also attach a preconditioning profile with the -c parameter.
Indeed. And
Quote:
Originally Posted by MonarchX View Post

targen.exe -v -d3 -e4 -B4 -s40 -g128 -m9 -b9 -f1000 -N1.0 -V1.6 -p1.0
will create exactly the same chart as (e.g.) targen.exe -v -d3 -e4 -B4 -s40 -g128 -m9 -b9 -f0 -N1.0 -V1.6 -p1.0 because the total number of patches generated by -e4 -B4 -s40 -g128 -m9 -b9 is 1483, so to add any full spread patches using -f, you need to set -f to a value above 1483.
First ... 38  39  40 41  42  ... Last

Up
Mobile  Desktop