madVR - high quality video renderer (GPU assisted) [Archive] - Page 375

Graeme Gill

6th May 2013, 09:53

@Graeme, are ICC 3dluts hard limited to max 65x65x65 resolution? Would it be worth considering an option to create bigger ICC 3dluts? Maybe not for using them as actual ICC profiles, but it would allow producing a more exact 3dlut for madVR.

The limit is 256x256x256. But in practice it will start to get slow above 65x65x65. If it takes 1 minute at 65x65x65, it will be an hour at 256x256x256.

My thinking is that it might help adding a lot of grayscale measurements to prettify the measured gamma response. E.g. if you go hardcore and measure every 219 possible 8bit grayscale values, producing a 219x219x219 3dlut with a fully scanned gamma curve (and then converting it to a 256x256x256 madVR 3dlut) might noticably improve gamma measurements.

The general approach is typically to do per channel calibration at higher resolution (ie. dispcal goes up to 128 measurements with perceptual like distibution, so it's even closer than 256 steps at the dark end), and then heavily weight the cLUT in the profile by a run of samples down the neutral axis. I'm not sure there is much really to be gained here, without a careful analysis of where the errors come from. The repeatability of the instrument and the display are going to be in there somewhere I think, as well as the limitations of sampling and modelling.

madshi

6th May 2013, 10:07

Does it really make sense to do "per channel calibration" in addition to a big 3dlut? I mean a really big 3dlut can do the same as "per channel calibration". So why doing two separate calibrations?

Graeme Gill

6th May 2013, 10:20

You would need to explain what you mean by equivalence. Different calibration targets do not give equivalent final gamma response on the display with collink generated 3DLUT files.

The stated issue was that a calibration loaded in the graphics card VideoLUT was not behaving the same as one incorporated into the 3dlut. So to check whether these two situations are equivalent, it doesn't matter what the device profile and calibration curves are, it just matters that the two ways of using the calibration are equivalent.

I'm having a bit of trouble wrapping my head around this, and how I'm supposed to have control over the final gamma response measured on my display after a video passes through an Argyll 3DLUT.

By setting the source colorspace details, ie. how the video RGB values are to be interpreted as device independent color values.

Which knob do I need to turn to change the gamma output of an Argyll 3DLUT if I (for example) do not want to use BT.1886 or REC709, and no ICM device profiles exist from my intended target?

None at the moment. It's a matter of establishing why the current controls are not sufficient. - ie. why BT.1886 is either not a good place to start, or is not working as intended.
[Ideally there would be no knobs to turn - the result should be what the creator of the video intended. In practice, that's not entirely knowable or desirable, but it's something to start with.]

My problem with this in general, is you are assuming that a given video does not have a linear response on a particular display, and has a known gamma curve which need to be adapted to something else. I'm of the opinion that the video gamma should not be touched at all input=output. Only the absolute gamma response of the of the display at the end of the chain matters.

That's precisely what we're trying to avoid. Depending on the actual response of the display is fine if you have a studio grade display setup and available to you, but mere mortals have whatever displays they can afford. So the aim is to make a silk purse out of a sow's ear - we want to make the display we've got operate like it's a fully calibrated studio grade display using the device link/3dLut to do the work. And what's defining our perfect studio display is the Rec709 primaries of the source profile + the BT.1886 gamma curve pre-ended to it.

So is the ultimate conclusion that I should just give up on having control over the final gamma response of my display when viewing a video? If so, I don't like that...

See above. Yes, you should have control. You do have control - it's just not via the display calibration curves. If the current control is not satisfactory, and you are able to illustrate how and why it is not, then I'll fix it. I'm already contemplating changing some of the details to improve usability.

I know yesgrey had mentioned dithering before in relationship the processing he did for the creation of 3DLUT files, was he talking about madVR then? Are you positive that his high internal bitdepth pre-processing didn't include dithering? The post is somewhere here on Doom9. His latest

There doesn't seem to be any mention of it in the Manual.txt. It could be that there is an image processing application associated with yCMS that does this. The "denoise" may be some sort of roll off curve to push noise down below black.

madshi

6th May 2013, 10:26

yCMS does not use dithering, never has, never will. Technically not possible.

Graeme Gill

6th May 2013, 10:38

I had forgotten about the 3D gamut projection. Bright green tones are indeed missing compared to Rec709 (white wireframe).
GDM-F520 3D Gamut (http://imageshack.us/a/img444/1327/gdmf5203dgamut.png)

Yes, the gamuts are a similar size, but the primaries are in slightly different places.

I have long had an idea on how to fix this type of problem, at a slight cost to brightness, that would work really well in a full screen Video context. I'll have to look into it a bit further down the track.

My preference is usually to have a gamma curve which goes from somewhere in the range of 1.9-2.2 near-black, ~2.4 in midtones, and ~2.6 in highlights. When I scale a REC709 curve to 32 lux ambient light, that is basically the end-result on my GDM-F520. Recently I've been testing out BT.1886, but still think I prefer the characteristics of the dispcal scaled REC709 curve instead. What all this ultimately comes down to is that I'm just very picky about the final gamma response of my display, and I don't like loosing control and flexibility for the end result.

Right, I understand. Have you had a play with the combination of BT.1886 and CIECAM02 viewing condition adjustments ? The pure CIECAM02 adjustment may be too far the other way, but a combination of low BT.1886 override gamma and CIECAM02 ambient adjustment may be closer to what you are looking for.

I may need to consider getting an i1d3 at some point for cost reasons, as I don't think I'll get lucky and find an i1pro2 for <$600 like I did when I bought my i1pro basic from Amazon when they were closing out the old bundle package.

It will be a while before i1pro2's are available second hand at a good price. An i1d3 that you can calibrate using your i1pro is a good combination.

Graeme Gill

6th May 2013, 10:46

Does it really make sense to do "per channel calibration" in addition to a big 3dlut? I mean a really big 3dlut can do the same as "per channel calibration". So why doing two separate calibrations?

For creating the display characterisation - yes. You quickly use up points trying to fill 3D space. Rough calculation 100x100x100 perceptual L*a*b* cube with 10000 measurement points is 10000^1/3 = 21 points per axis, 100/21 = 5 delta E spacing between the sample points. If the display behaviour curvature is high, you could have several delta E error at points you haven't sampled. But displays are largely additive, so any such curvature is primarily a result of per channel curvature, and you can sample per channel response with high precision with a few hundred points. Use them to transform the sample and cLUT grid space into a much more linear space, and the limited cLUT grid resolution has much less impact on the overall accuracy.

cyberbeing

6th May 2013, 10:54

Playing around with this a bit more, it seems I found a workaround of sorts.

Using that Dispcal REC709 (32lux ambient scaled) profile I posted earlier, I linked it to a REC709 source profile containing a linear 1.0 gamma, set madVR gamma controls to BT.709 2.60 & brightness -90... Problem solved. Gamut correction without the source gamma of the video being modified in any significant way. It's too bad that madVR doesn't have a bigger range for the gamma controls, even though the brightness control is just an extension of gamma control for madVR.

Yes, I'm being serious. First impression is the results actually look quite good, much better than the default collink workflow, so I may actually consider using it this way. Need to take some measurements.

@Graeme Gill
Do you have an opinion about the pros/cons about doing gamut correction using a source profile with a linear curve, and then allowing madVR to handle gamma linear 1.0 gamma to desired gamma? Is there anything technically incorrect or inherent problems with doing things in this way?

madshi

6th May 2013, 11:00

For creating the display characterisation - yes. You quickly use up points trying to fill 3D space. Rough calculation 100x100x100 perceptual L*a*b* cube with 10000 measurement points is 10000^1/3 = 21 points per axis, 100/21 = 5 delta E spacing between the sample points. If the display behaviour curvature is high, you could have several delta E error at points you haven't sampled. But displays are largely additive, so any such curvature is primarily a result of per channel curvature, and you can sample per channel response with high precision with a few hundred points. Use them to transform the sample and cLUT grid space into a much more linear space, and the limited cLUT grid resolution has much less impact on the overall accuracy.
Ah, interesting!

Ok, but this simply means that in addition to the sparse cube measurements we need a few hundred additional measurements across the channel axises (and maybe some more across the grayscale axis). It should still be possible to turn all those measurements into one giant 256^3 3dlut without needing additional 1D VideoLUTs, or am I wrong?

Wouldn't we even get better results using just one 256^3 3dlut instead of a 65^3 3dlut plus three 256^1 1dluts? Using just one 256^3 3dlut would mean only one trilinear interpolation. We'd save the 3 bilinear 1dlut interpolations. That should reduce math/rounding errors, no?

leeperry

6th May 2013, 11:25

I don't know exactly how and when exactly Reclock draws the judder test, so I can't really say...
OK, thought so....anyway, movies appear dead smooth(with the old rendering path on XP) and Reclock's judder test code is prolly ages old and might have been initially coded for XP Overlay for all we know.

I'm not sure if the NVidia driver bug was fixed in XP.
I don't think it's ever been as the new rendering path would appear to cause random presentation glitches from time to time, as if mVR missed the VSYNC fliptime or something....the old rendering path remains the unstoppable train it's always been, and I'm currently having a ball with smooth-motion in 140Hz :p

I do get occasional ghosting and all(even though my brain seems to get used to it), but it's either this or normal 24/25p judder so pick your poison....and you said that the higher the refresh rate the better, so lemme tell you that 140Hz does take care of smoothness. It's funny as sometimes it feels a bit like matrix'eque "bullet time" with more fps than reality hah, excellent work of yours on the smooth-motion feature...business as usual :thanks:

PS: the improved motion smoonthness also drastically increases the subjective pop effect http://forum.slysoft.com/images/smilies/agreed.gif

zoyd

6th May 2013, 13:42

@Graeme User specified transfer functions as input to collink?

cyberbeing

6th May 2013, 14:45

REC709 source profile containing a linear 1.0 gamma
madVR gamma controls to BT.709 2.60 & brightness -90
Gamut correction without the source gamma of the video being modified in any significant way.
....
Need to take some measurements.

My measurements with a linear source profile + madVR gamma have overall improved compared to the default collink BT.1886 workflow.

Maximum monitor gamut within the REC709 gamut is now used with -ir
0-25-75% Saturation points are closer to optimal locations with lower dE
16-16-16 -> 0-0-0 = Black (with default BT.1886 workflow it was near-black)
Grayscale measurements with linear VideoLUT (dispwin -c) almost exactly monitor's native gamma.

So far so good. Sometime this week I'll make some fresh calibrations with both methods and various collink intent parameters to see if this improvement with a linear source profile is reproducible.

corporalgator

6th May 2013, 17:40

Madshi, I cannot get DXVA2 (Native or copyback) decoding through lav filters to work with madvr. The screen goes completely green after a few seconds. It does not happen with evr. Intel Quick sync decoding works fine as well. I've tried several different options within madvr with no luck.

dansrfe

6th May 2013, 18:41

corporalgator

6th May 2013, 18:58

n3w813

6th May 2013, 19:16

@cyberbeing/graeme/madshi

I want to try to put cyberbeing's issue into layman's layman's terms to see if I'm understanding it correctly... (sorry, I'm very new to color managment :p)

Cyberbeing currently have a display with a gamma curve (=cb_gamma_curve) that he prefers. He wants to create a 3DLUT that corrects the gamut but keep the same cb_gamma_curve response.

cb_gamma_curve + 3DLUT = cb_gamma_curve

But the current issue is when incorporating the generated 3DLUT....

cb_gamma_curve + 3DLUT <> cb_gamma_curve

The 3DLUT is based on the reference profile/gamma curve options used with collink.exe. So the problem lies with the options selected not able to produce the gamma curve cyberbeing prefers. So...

1. Cyberbeing wanted an option to disable any gamma processing when creating the 3DLUT. But this is not possible since the 3DLUT needs a gamma target to profile to.
2. Cyberbeing can somehow create a custom target reference .icm file to use instead of Graeme's Rec709.icm
3. Graeme can implement a function in collink.exe that allows the user to specify a custom gamma curve (if technically possible)

Am I on the right track?? ;)

n3w813

6th May 2013, 19:41

Sometimes when I press the next arrow button rapidly when trying to find a scene in a movie the window gets "stuck" on a a few frames and just keeps repeating in exclusive mode. The audio keeps going like normal though. If I go back to windowed mode then the problem goes away but going back to exclusive mode just gives a black screen thereafter. The only resolution at that point is to restart MPC-HC. I have smooth motion on.

Win 7 x64, GTX 670. latest: MPC-HC, LAV Filters, madVR

Ditto, I have this issue also ever since smooth motion was enabled in my setup. Never bothered to report the bug (shame on me) since I could easily exit and restart the player with playback resume with my remote. :p

Win 7 x86, GTS 450. latest: Zoom Player, LAV Filters, madVR
FSE enabled, smooth motion enabled

mrkazador

6th May 2013, 21:02

Having this weird problem with a random black frame appearing during a movie. It probably happens 2 or 3 times during the whole film. At first I thought I was blinking too slow lol but definitely not me. All drivers and filters are up to date.

Intel NUC i3 (HD4000)
Win7 x64
MPC HC x86
LAV Filters

Everything in madVr is set to default except these options.
Upscaling: DXVA2
Downscaling: DXVA2
Chroma: Bicubic 75
Smooth Motion: Enabled (disabled linear light)

With smooth motion enabled I get the random black frames. Once I disabled smooth motion I have not noticed a black frame since... Anyone know what the problem could be? My rendering time was in the high 30's while watching a 720p movie on a 1080p display set to 60hz. Disabling smooth motion reduced my rendering time to around 20ms.

DragonQ

6th May 2013, 23:09

Random black frames appearing with Smooth Motion on is a bug. madshi hasn't updated MadVR in a while as he's busy with other things but presumably this will be fixed in the next version.

Graeme Gill

7th May 2013, 01:01

@cyberbeing/graeme/madshi
3. Graeme can implement a function in collink.exe that allows the user to specify a custom gamma curve (if technically possible)

You don't use a screwdriver to hammer in a nail.

So you don't set the desired reproduction of a device-link/3dlut by changing the calibration of the very device you are trying to make the reproduction not depend on. You set it by choosing the source definition.

There is already lots of possible settings that modify the source definition and the gamut mapping. See the examples in the tutorial (I show 12 as an illustration of where to start).

If you think that this is not capable achieving what you want, then you need to kick off a discussion of what and why, probably starting by justifying why Rec709 encoding + BT.1886 decoding is all wrong, because (as far as I have been able to gather), that's what current best practice says we should be using. See http://www.avsforum.com/t/1409045/how-power-law-gamma-calibration-can-lead-to-crushed-blacks. But none of this is set in stone - there are standards, there is industry practice, there are actual display limitations and viewing conditions, and there is user preference. So the current tool-set is a starting point.

But trying to defy the very way it works is no way to progress.

n3w813

7th May 2013, 01:23

You don't use a screwdriver to hammer in a nail.

But trying to defy the very way it works is no way to progress.

You are preaching to the choir, my friend. :) I was simply suggesting 'possible' fixes to cyberbeing's issue but I know they may not be the 'correct' approach.

I am all for standards. Best scenario, ALL video production houses in the 'world' should all use the same targets. Gamut, gamma, framerate, etc. So the end user can all calibrate their display devices to those targets and be done with it. Especially TV broadcast stations, what you get between one station to another....

cyberbeing

7th May 2013, 03:00

Cyberbeing currently have a display with a gamma curve (=cb_gamma_curve) that he prefers. He wants to create a 3DLUT that corrects the gamut but keep the same cb_gamma_curve response.

cb_gamma_curve + 3DLUT = cb_gamma_curve

But the current issue is when incorporating the generated 3DLUT....

cb_gamma_curve + 3DLUT <> cb_gamma_curve

Yes, you could say that "cb_gamma_curve" the the final measured response I desire on my display.

Gamma adjustments in Source Video (mastering)
Gamma adjustments in 3DLUT
Gamma adjustments in GPU VideoLUT
Gamma adjustments in Software (madVR)
Gamma adjustments in Display/TV

Part of the problem is that there are so many places between video mastering and images actually reaching your eyes that gamma could be changed. There are many ways you could go about this, but I'd prefer to only modify gamma a single time to reach my target. Having multiple gamma adjustments working against each in different portions of a display chain is not lossless process, even when you work in high accuracy.

My optimal display chain would be as follows:

Source Video (unknown gamma, assumed linear in=out)
3DLUT (adjust gamma to desired gamma based on Display/TV response)
madVR Gamma (disabled/linear)
GPU VideoLUT (disabled/linear)
Display/TV (natural/default gamma)
Result = 3DLUT adjusts Display/TV -> Desired Gamma

In my previous post where I'm talking about my workaround using a linear 1.0 source profile:

Source Video (unknown gamma, assumed linear in=out)
3DLUT (adjust gamma to linear 1.0 gamma based on Display/TV response)
madVR Gamma (de-linearize 1.0 linear gamma which 3DLUT outputs restoring input=output response, optionally using mVR gamma for bulk gamma adjustments if you desire something lighter/darker than your display)
GPU VideoLUT (fine-tune gamma to desired gamma based on Display/TV response and/or mVR bulk gamma adjustments)
Display/TV (natural/default gamma)
Result = 3DLUT adjusts Display -> 1.0 Linear -> madVR adjusts 1.0 Linear -> Gamma (video in = video out) -> VideoLUT adjust Gamma -> Desired Gamma

While being complex, and counter-intuitive to the intentions of Argyll & collink, this actually seem to work well and give full control to the user over final gamma output. I seem to remember during yCMS development that there were brief discussions about the possibly of having the 3DLUT output 1.0 Linear to madVR, but it was ultimately decided against for one reason or another. The problem with this, I don't see any way madVR could make this 1.0 Linear -> Gamma process automated without knowledge of the natural gamma response of the display which Argyll collink originally used to convert to 1.0 Linear output in the first place. This is probably the workflow I'll stick to until/unless a superior solution appears which does what I desire.

The 3DLUT is based on the reference profile/gamma curve options used with collink.exe. So the problem lies with the options selected not able to produce the gamma curve cyberbeing prefers. So...

1. Cyberbeing wanted an option to disable any gamma processing when creating the 3DLUT. But this is not possible since the 3DLUT needs a gamma target to profile to.
2. Cyberbeing can somehow create a custom target reference .icm file to use instead of Graeme's Rec709.icm

Unless (2) someone can point me towards a tool which allows me to create an ICC source device profile with my desired target gamma which matches dispcal output, doing (1) disabling 3DLUT gamma adjustments completely would be a viable alternative, at which point I'd do gamma adjustment further down the display chain on the VideoLUT.

If you think that this is not capable achieving what you want, then you need to kick off a discussion of what and why
What = All calibration targets capable with any combination of Dispcal settings
Why = User freedom, subjective viewing experience, objective display measurements

I really hate getting into these discussions about what is "technically correct" & "proper" as far as gamma adjustments. At this point in time, I do not agree that BT.1886 is anything more than a FOTM solution, until it's been proven that the professional video industry are adhering to such a target for all future video mastering. In this day and age I'd suspect all broadcast grade mastering monitors have in internal 3DLUT, with standardized gamma presets + various video transfer curves. I can't say I've ever seen a $20K+ mastering monitor with a BT.1886 preset. Polls on AVSFourm and the like have shown that traditionally studios have used a range of gamma curves during mastering. Tuning your display for the assumed gamma of a mastering monitor is an effort in futility, until we actually have videos releases which state "best viewed at such & such gamma in such @ such & such lighting conditions" which I doubt will every occur.

If the current restrictive behavior is all which you desire for Argyll CMS madVR 3DLUT generating capability, there is no problem with that, other than it limiting its usefulness.

Aleksoid1978

7th May 2013, 05:11

Weird. Why does the problem not occur with MPC-HC? I don't understand, either!!

I do not understand - but call SetWindowText() before madvr add to the graph, then everything is fine.

But - I noticed a difference from MPC-HC. I use Spy++ to see messages and what different

<000392> 004205C8 P message:0xC3A2 [Registered:"madHcNetWindowcast"] wParam:6E63686D lParam:0046078A

In MPC-BE - before WM_SETTEXT.

In MPC-HC - after WM_SETTEXT.

Graeme Gill

7th May 2013, 06:39

Part of the problem is that there are so many places between video mastering and images actually reaching your eyes that gamma could be changed.

I'm not sure there is. Typically there will a final approval. That's the single place where the video is seen as intended.

While being complex, and counter-intuitive to the intentions of Argyll & collink, this actually seem to work well and give full control to the user over final gamma output.

What, unlike the -I parameter, which gives you full control over the final gamma output ?

BTW :- I was looking at some strange things with your TV profile(s), and I have come to the conclusion:

1) You've used a fairly small number of samples, probably in a regular grid.

2) It turns out that colprof -ax (or -aX etc. - anything with an XYZ cLUT) can work quite badly with a small number of samples in a regular grid. (I wasn't aware of this myself until now.)

3) You will get a better profile with your particular sample set with a L*a*b* cLUT profile, ie. -al, the default profile type.

Even using a L*a*b* cLUT there there are signs of noticeable inaccuracies near black, because there are far too few sample points there. So first thing I would do before worrying about gamma values any further, is make a better profile.

I really hate getting into these discussions about what is "technically correct" & "proper" as far as gamma adjustments. At this point in time, I do not agree that BT.1886 is anything more than a FOTM solution, until it's been proven that the professional video industry are adhering to such a target for all future video mastering. In this day and age I'd suspect all broadcast grade mastering monitors have in internal 3DLUT, with standardized gamma presets + various video transfer curves. I can't say I've ever seen a $20K+ mastering monitor with a BT.1886 preset. Polls on AVSFourm and the like have shown that traditionally studios have used a range of gamma curves during mastering. Tuning your display for the assumed gamma of a mastering monitor is an effort in futility, until we actually have videos releases which state "best viewed at such & such gamma in such @ such & such lighting conditions" which I doubt will every occur.

I'm not about to spend a whole lot of time coding up stuff that might be 1) Useless to most people, 2) misleading and 3) confusing.

Nothing worse that going to all that trouble and then have people ask "which one should I used ? What values should I set ?" and only being able to reply "Dunno - all those options are there because someone thought you needed them - so you figure it out". A lot of people give up at that stage.

Asmodian

7th May 2013, 09:04

After much trial and error I have found a method I like for calibrating my monitor with Argyll and creating a 3Dlut for MadVR. I really like the lack of black crush.
Thanks for all the work on this both of you. :)

I used:
dispcal.exe -d 1 -v -m -q h -y e -w 0.3127,0.3290 -G 2.4 -f 0 -o X270OCmtx.icm X270OC
targen.exe -v -d 3 -G -s 20 -g 100 -f 2000 -c X270OCmtx.icm X270OC
dispread.exe -v -d 1 -y e -k X270OC.cal X270OC
colprof.exe -v -a X -q h -b h X270OC
collink.exe -v -3 m -e t -E t -I b -I 2.2 -G -i a Rec709.icm X270OC.icm X270OC_HD

I then load this X270OC.icm into winodws color management and use X270OC_HD.3dlut in MadVR.
I have an i1d3 colorimeter and an IPS monitor that I think has a white led backlight.

Does my workflow make sense? Any suggestions?

Uncalibrated ~7100K:
http://i1222.photobucket.com/albums/dd496/asmodian3/x270OC_zps433f1b44.png

In MadVR after calibration 6546K:
http://i1222.photobucket.com/albums/dd496/asmodian3/x270OC_3dlut_zpsc2159d7d.png

In HCFR vs "HDTV- REC 709" I get less than 3 dE for all color saturations and all gray scale measurements except 20% and below, most errors are below 2 dE. The gamma is average 2.20 but with a slight curve down near black and up near white; 2.07 at 10%, 2.22 at 50%, and 2.28 at 90%. I am very impressed with the picture.

Using my previous favorite Ti3 Parser method I actually managed to get even better dE's for gamut and saturations and the gamma was almost exactly 2.20 at all IREs but black crush was a problem when watching blurays. The "near black" measurements in HCFR are much closer now.
:thanks:

cyberbeing

7th May 2013, 09:46

What, unlike the -I parameter, which gives you full control over the final gamma output ?
I wouldn't know, since I've only had poor subjective results so far when using "-I b" with an -I override. Is the -I gamma override parameter functional when not using -Ib, in order to scale the source profile curve directly without BT.1886? Or is it expected to use the -c and -d viewing condition parameters? Playing around with -c and -d are still on my to-do list.

BTW :- I was looking at some strange things with your TV profile(s), and I have come to the conclusion:

1) You've used a fairly small number of samples, probably in a regular grid.

2) It turns out that colprof -ax (or -aX etc. - anything with an XYZ cLUT) can work quite badly with a small number of samples in a regular grid. (I wasn't aware of this myself until now.)

3) You will get a better profile with your particular sample set with a L*a*b* cLUT profile, ie. -al, the default profile type.

Even using a L*a*b* cLUT there there are signs of noticeable inaccuracies near black, because there are far too few sample points there. So first thing I would do before worrying about gamma values any further, is make a better profile.

1) I've just been using the patch sets bundled with Dispcal GUI. The BT.1886 profile was just a quick test, so it used "Default Test Chart for LUT profiles" to cut down on time. The REC709 profile used the "Large Test Chart for LUT profiles". If they are bad combinations, maybe you should request they replace them. I don't have a CRT suction cup for my i1pro so it gets a bit tiresome to profile on any of the larger 1000+ patch sets very frequently. Any recommendation for a targen set in the range of 200-500 patches which you'd think would generate a better profile on my CRT?

2 & 3) Thanks for the advice. The main reason I moved away from LAB cLUT profiles previously, is because XYZ + Matrix profiles have better overall application compatibility. I'll try to once again get into the habit of creating an additional LAB profile for critical work.

The reason I've been avoiding too many sample points near black, is because my i1pro isn't always accurate and repeatable near-black. If I take sample point too close together in the lower luminance range, I get bogus non-sequential Y values readings occasionally. This why I suspect that ambient light scaled REC709 curves give me better profiles, just from the fact that near-black readings aren't as low of luminance compared to a BT.1886 curve. Argyll CMS does not seem to contain any kind of sanity check for and discard bogus/invalid readings, which can cause really my ICC profiles to behave extremely strange near black if I take too many readings. If Dispcal/Colprof could automatically detect and re-try in cases where Y value reading which should be sequential are not, as well as have an option to ignore any near-black color temperature readings below a certain Y threshold (using last known valid reading), that would be useful for my i1pro. If you look at a 1% stepping 3D projection of my gamut in those ICC profiles, they have a massive sized gamut larger than the HVS near-black from those incorrect readings. This is also why dispcal frequently likes to raise my 0-0-0 values in the VideoLUT higher than it should, and make really weird corrections near-black. I've gotten into the habit of manually normalizing the VideoLUT near black before profiling.

I'm open to any other suggestions you can offer to improve quality of profiles, given my troubles.

I'm not about to spend a whole lot of time coding up stuff that might be 1) Useless to most people, 2) misleading and 3) confusing.
Do users find the plethora of dispcal settings misleading and confusing when used via Dispcal GUI? Does dispcal supporting gamma curves which are useless to most people, cause problems for you in some way? Why did you spend time implementing those specialty curves in the first place, if not for the small minority of users who actually needed them or found them useful? If coding time required to implement all dispcal curves in collink is the main reason why you don't want to support them currently, I'll stop bothering you about it and only hope you consider it for a future enhancement when you have nothing better to do between Argyll CMS releases.

Nothing worse that going to all that trouble and then have people ask "which one should I used ? What values should I set ?" and only being able to reply "Dunno - all those options are there because someone thought you needed them - so you figure it out". A lot of people give up at that stage.
You could avoid user confusion smartly defining default behavior in collink.

Simplify the default command line to something like:
collink -3m TV.icm
But translates internally to, while still allowing for user-defined overrides:
collink -v -3m -et -Et -Ib -I2.2 -G -ir -qh Rec709.icm TV.icm HD.icm

"Which one should I use?"
Answer: The defaults.

"What values should I set?"
Answer: Just use the defaults unless you know what you're doing.

Overall these answers are not that different than what people get told when they ask what settings to use with x264 cli (http://www.mediafire.com/view/?w0bec16ai2bwqdw). You could even go the x264 route and create single switch presets for different scenarios you define in your documentation. Add something like a -tune parameter for different bright/mid/dark viewing conditions, that that should be plenty for the non-technical user. I'm sure madshi is going to try to automate standard 3DLUT generation behavior with collink called through that madVR GUI anyway.

"collink -3m -preset rec709" = "collink -v -3m -et -Et -Ib -I2.2 -G -ir -qh Rec709.icm TV.icm HD.icm"
"collink -3m -preset ntsc" = "collink -v -3m -et -Et -Ib -I2.2 -G -ir -qh SMPTE_RP145_NTSC.icm TV.icm SD_NTSC.icm"
"collink -3m -preset pal" = "collink -v -3m -et -Et -Ib -I2.2 -G -ir -qh EBU3213_PAL.icm TV.icm SD_PAL.icm"
"collink -3m -preset advanced" = no defaults for any switch, must manually define every parameter needed, allows custom gamma targets

yesgrey

7th May 2013, 11:11

I know yesgrey had mentioned dithering before in relationship the processing he did for the creation of 3DLUT files, was he talking about madVR then?
Yes.

Are you positive that his high internal bitdepth pre-processing didn't include dithering?
yCMS does not use dithering, never has, never will. Technically not possible.
madshi is right. The idea of dithering is to avoid creating a pattern due to repeating the same rounding error all the time. In a tool like yCMS, or ArgyllCMS, you are processing the individual colors, and, even though we are using floating point for the internal computations (64 bit in yCMS), since you will round the FP number to 16 bit integer only once (one per color), the term dither would not apply. Any random noise added during that conversion would only make the 3DLUT less accurate.

His latest version of yCMS even added a Denoise_Black_Level option, which was just one of the latest of the special tweaks he did internally in yCMS when calculating gamma and gamut correction for 3DLUT files.

That was not one of the latest tweaks... It was addded a long while ago, but since it was not needed anymore, and was giving some problems, I added that option to disable it by default, and allow people to enable in the rare case they would need it. ;)

He also used to say that yCMS did neither Perceptual or Relative Colorimetric gamut adaption, but some kind of custom hybrid approach. What this means, who knows?
That was related to Out of Gamut colors clipping. I use a simple custom method. It's not a very good one, and I think it's the cause of some of the problems people referred lately, but it would be solved only in yCMS v2.0, if it ever sees the light...

cyberbeing

7th May 2013, 11:50

Thanks for the clarifications yesgrey, and nice to see that you do still hang around doom9 occasionally. If yCMS v2.0 does ever see that light of day, I can only hope it retains the ability to scale down all the way to the simplified "Gamut_Measurements" only 3DLUTs of yCMS v1.0.

If this discussion with Graeme is any indication, that functionality without grayscale/gamma correction will forever be useful for the most basic of gamut corrections, and something which makes yCMS v1.0 unique in its current usefulness. 6233638 also mentioned how he's the opposite of me and uses Grayscale_Measurements in a non-standard way (gamut correction disabled) with custom Y values to force the generated 3DLUT to output a BT.1886 gamma curve which is verified by measurements against a calculator. Last thought would be that, it may also be a good idea to continue to allow pure measurement data for 3DLUT generation, and not turn it into yet another ICC profile device linking solution like ti3 parser or collink. Having a unique approach to achieving standard behavior isn't always a bad thing.

Aleksoid1978

7th May 2013, 13:32

madshi

About SetWindowText()

I made some test - and i can say that some bug in madVR. I do some change in MPC-HC-> call SetWindowText() after graph is build, and main window Title is also broken(replace non english/locale characters with '?').
Here mpc-hc.exe + file name(with Chinese or Korean characters).
http://aleksoid.voserver.net/MPC-BE/mpc-hc_madVR_SetWindowText.7z

screen:
http://s53.radikal.ru/i140/1305/b8/d977848d8cc0t.jpg (http://radikal.ru/F/s53.radikal.ru/i140/1305/b8/d977848d8cc0.png.html)

Graeme Gill

7th May 2013, 14:23

Is the -I gamma override parameter functional when not using -Ib, in order to scale the source profile curve directly without BT.1886?

No it's not - but the difference is black point matching, which you want done somewhere, or else black detail will be lost.

The REC709 profile used the "Large Test Chart for LUT profiles". If they are bad combinations, maybe you should request they replace them.

Yes, the other profile is a very much better, but it still looks like a regular grid, and the XYZ and L*a*b* profile differ in details. I didn't refer to dispcalgui in my guide to creating a .3dlut for MadVR, so what it recommends isn't pertinent.

I don't have a CRT suction cup for my i1pro so it gets a bit tiresome to profile on any of the larger 1000+ patch sets very frequently. Any recommendation for a targen set in the range of 200-500 patches which you'd think would generate a better profile on my CRT?

Yes, use the default full spread patches, as per my tutorial and guide.

2 & 3) Thanks for the advice. The main reason I moved away from LAB cLUT profiles previously, is because XYZ + Matrix profiles have better overall application compatibility. I'll try to once again get into the habit of creating an additional LAB profile for critical work.

Sometimes XYZ cLUT profiles are a better fit to the device, and if your display gamut exceeds the limits of ICC L*a*b* PCS, you pretty much have to use them. But a L*a*b* cLUT profile is a good sanity check.

The reason I've been avoiding too many sample points near black, is because my i1pro isn't always accurate and repeatable near-black. If I take sample point too close together in the lower luminance range, I get bogus non-sequential Y values readings occasionally. This why I suspect that ambient light scaled REC709 curves give me better profiles, just from the fact that near-black readings aren't as low of luminance compared to a BT.1886 curve.

Does dispcal/dispread -Ib help at all ?

Argyll CMS does not seem to contain any kind of sanity check for and discard bogus/invalid readings, which can cause really my ICC profiles to behave extremely strange near black if I take too many readings. If Dispcal/Colprof could automatically detect and re-try in cases where Y value reading which should be sequential are not, as well as have an option to ignore any near-black color temperature readings below a certain Y threshold (using last known valid reading), that would be useful for my i1pro.

Yes and no. The nature of the interpolation ensures a certain degree of consistency, but at some level it has to believe the data. You can crank up the smoothing by using "colprof -r N", where N > 0.5, which may help a little, at the cost of poorer fitting to the data points.

If you look at a 1% stepping 3D projection of my gamut in those ICC profiles, they have a massive sized gamut larger than the HVS near-black from those incorrect readings. This is also why dispcal frequently likes to raise my 0-0-0 values in the VideoLUT higher than it should, and make really weird corrections near-black. I've gotten into the habit of manually normalizing the VideoLUT near black before profiling.

I am kind of surprised that your profile claims that black is perfect zero.

Do users find the plethora of dispcal settings misleading and confusing when used via Dispcal GUI?

Yes, people find a lot of the options in ArgyllCMS confusing, and I don't blame them. It is largely designed to default to useful behaviour, but people too often end up going down a strange path because they've felt a need to use something because it's there, not because they've found that they need it.

Does dispcal supporting gamma curves which are useless to most people, cause problems for you in some way?

Not as such, because it's done, and there are a wider range of uses for dispcal than Video calibration - people more often use it to calibrate their computer desktop. Some of the options were speculative - but I'm always striving to improve the usage, both by improving the documentation, and trying to guide people to start simple, and use other options when they've proven that they help.

Simplify the default command line to something like:
collink -3m TV.icm
But translates internally to, while still allowing for user-defined overrides:
collink -v -3m -et -Et -Ib -I2.2 -G -ir -qh Rec709.icm TV.icm HD.icm

Maybe I could default the -et -Et, but in earlier versions of MadVR, different encodings are needed. SD source material should use different source profiles, and the source profile + destination profile is fundamental to creating a device link. -G isn't a default, because it's not normal ICC CMM, and it's slow. Same with -qh. -Ib is part of defining the link processing. -I2.2 is a tweak to -Ib. While some of these could be made defaults, then extra controls are needed to be able to disable them, and it gets even more confusing as to what defaults are being triggered by -3m.

Answer: Just use the defaults unless you know what you're doing.

Agreed - but some peoples minds don't work like that.

Overall these answers are not that different than what people get told when they ask what settings to use with x264 cli (http://www.mediafire.com/view/?w0bec16ai2bwqdw). You could even go the x264 route and create single switch presets for different scenarios you define in your documentation. Add something like a -tune parameter for different bright/mid/dark viewing conditions, that that should be plenty for the non-technical user.

It's a little out of scope - ArgyllCMS is the set of tools, it's not the polished UI.

pie1394

7th May 2013, 14:47

madshi

About SetWindowText()

I made some test - and i can say that some bug in madVR. I do some change in MPC-HC-> call SetWindowText() after graph is build, and main window Title is also broken(replace non english/locale characters with '?').
Here mpc-hc.exe + file name(with Chinese or Korean characters).
http://aleksoid.voserver.net/MPC-BE/mpc-hc_madVR_SetWindowText.7z

In WinCE , there is one issue. But it is not described in the normal MFC API's document. So I don't know if it is the root cause of this weird result...

Calling SetWindowText with any amount of text will cause the control to initialize to UNICODE. Calling SetWindowText with empty text will not cause the control to initialize to UNICODE

cyberbeing

7th May 2013, 15:38

I didn't refer to dispcalgui in my guide to creating a .3dlut for MadVR, so what it recommends isn't pertinent.
...
Yes, use the default full spread patches, as per my tutorial and guide.
The profiles I linked you were all existing profiles from before you added madVR 3dlut support to collink. A fresh calibration per your "Putting it all together" guide, along with fresh attempts with "dispcal -G2.4 -f0 -qh" & "dispcal -g709 -a32 -qh" as well as "dispcal -gl -qh" for good measure I'll try to get done tomorrow.

Does dispcal/dispread -Ib help at all ?
More than something like -Ib, the i1pro would likely benefit from pausing calibration/profiling every 10 minutes or so to have the internal sensor offsets recalibrated on its dark plate as the method to compensate for it warming up.

For awhile I had been using the -Ib black drift option, but it didn't seem to help so I stopped. I believe it may have actually made things worse because it doesn't wait long enough after a white screen is displayed before taking a new dark reading, which is problematic for a CRT display. For the same reason I usually get better profiles if patch sets go from darkest to lightest in sequential fashion. Targen only does this half-way for the sequential patches, so it's a bit annoying. 100% White gets placed before 0% Black, 100% Red gets placed before Darkest Green, and so on. Accuracy of the dark readings always suffer whenever this occurs. Dispcal likely has the same problem to some degree as it near the darker grayscale tones, with Y measurements getting thrown slightly off, but that's how it's always been in Argyll.

You can crank up the smoothing by using "colprof -r N", where N > 0.5, which may help a little, at the cost of poorer fitting to the data points.
I'll give it a try.

I am kind of surprised that your profile claims that black is perfect zero.
The new DispcalGUI "Black Point Compensation" hack for colprof which seems to be enabled by default is probably to blame. It was likely still enabled, since I don't believe I took note of its existence after updating. Could that have thrown off collink? Don't worry, for these upcoming calibrations I'll be using CLI only.

loa-ash

7th May 2013, 16:41

hello, i've a problem using latest version of MPC-HC stable release with madvr 0.86.1... When i try to open any video it tooks about 10 seconds to mpc to show the images. It stay with "Opening..." for 10 seconds then, the icon of madvr appears in system tray and video start reproduce without problems... how can i fix that?

XRyche

7th May 2013, 21:28

At least it is for me. You have to run the signal through ffdshow raw filter and under "output" then "stream settings" check the "set interlace flag in output media". Everything else I didn't touch. If this is already known....oops :P . Last time I checked everyone was saying you still couldn't us madVR with TV.

loa-ash

7th May 2013, 23:08

digitech

8th May 2013, 02:03

Hi guys, i have an Acer Revo 3610 witn an Nvidia Ion gpu htpc, actually it has lots of obvious limitations, i can't do 1080p native playback and 720p upscaled to 1080 with smooth motion (i can't live without that madvr feature) on has lots of hiccups, without it i dont have any troubles, only if i upscale 720p to 1440x810 i can have a pretty decent playback with smooth motion on but i have to settle with bilinear or dxva image upscaling, my question is if i play all my 720p material without upscaling it to 1080p, it plays flawlessly even with more demanding upscaling methods, but are there really too much disadvantages if i only play in 720p with the best upscaling methods (even if i dont need them cause im not upscaling) vs 720p upscaled to 1080p or in my case 1440x810 but only with bilinear or dxva image upscaling, which is better or what do you recommend, i'd love if this question can be answered by madshi, if not i'll be glad too if anyone can give a little light in this issue, i've always wanted to ask this but i don't know why i had to wait until now :)

Graeme Gill

8th May 2013, 05:15

More than something like -Ib, the i1pro would likely benefit from pausing calibration/profiling every 10 minutes or so to have the internal sensor offsets recalibrated on its dark plate as the method to compensate for it warming up.

Yes, this could help, but I doubt it would completely solve the problem. I've seen significant changes to the black level over much smaller time periods. Maybe 10 minutes may work if the instrument is well acclimatised to the screen temperature beforehand. One of the disadvantages of recalibrating though is that it introduces small re-positioning errors, but these will be a lesser problem than black drift. I'll contemplate adding an option for this, but it makes profiling a whole lot more painful.

[ Hand holding the instrument probably doesn't help much - it's hard to leave it to acclimatise, and body warmth will affect its stability. ]

For awhile I had been using the -Ib black drift option, but it didn't seem to help so I stopped. I believe it may have actually made things worse because it doesn't wait long enough after a white screen is displayed before taking a new dark reading, which is problematic for a CRT display.

For the same reason I usually get better profiles if patch sets go from darkest to lightest in sequential fashion. Targen only does this half-way for the sequential patches, so it's a bit annoying. 100% White gets placed before 0% Black, 100% Red gets placed before Darkest Green, and so on. Accuracy of the dark readings always suffer whenever this occurs. Dispcal likely has the same problem to some degree as it near the darker grayscale tones, with Y measurements getting thrown slightly off, but that's how it's always been in Argyll.

Interesting - no-one has reported this before nor have I noticed it myself, probably because earlier instruments weren't stable enough near black for it to be obvious. It also depends to a degree on how long an instrument takes to take a dark measurement - shorter is more sensitive.

A random type patch order is normally a good thing, because it spreads any systematic errors (such as instrument or display changes over time) randomly through the colorspace, allowing the profile smoothing to reduce such errors, as well as preventing them having a concentrated effect.

There are two things I can do about it. One is to make the patch delay sensitive to the change in color, so extra time is allowed for a change from light to dark. I imagine this may also help Plasma and LCD displays, both of which take some time to stabilze at a level. The other is to sort the display patches so as to minimise the extra response time needed. A short term workaround would be to set the ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS environment variable to (say) 500.

This could make -Ib work a little better, but it will also make it slower...

The new colprof "Black Point Compensation" option which recent DispcalGUI seems to now seems to enable by default is to blame.
Sorry, I simply don't know what that flag does. I'd have to look at the resulting command line(s) to figure it out.

cyberbeing

8th May 2013, 05:48

@Graeme Gill

Here are the files resulting from my attempt at the default scenario:

http://www.mediafire.com/?cs01sbjo0c7158a

dispcal -v -o -ql -H -F -w0.312713,0.329016 -gs -o F520mtx.icm F520

targen -v -d3 -s20 -g100 -f1000 -c F520mtx.icm 1000_F520

dispread -v -H -F -k F520.cal 1000_F520

dispwin F520.cal

colprof -v -qh -bl 1000_F520

Before I continue, I'd like to hear how you judge the profile quality this time around. Good? Bad? Better or worse than before?

I changed my pre-calibration black and white level targets quite a bit from those previous profiles, and used the -F switch instead of a black desktop wallpaper w/o icons visible.

White Level: 100 cd/m2 -> 85 cd/m2
Black Level: Optimal pre-calibration -> Ignored for minimum black level
This usually has the side-effect of making my native monitor gamma much much higher, probably ~2.6 (didn't check).

I also sucked it up and did the 1000 full-spread patches, but I'm probably not going to do that again as it takes extreme patience to hold my meter on screen that long, especially with adaptive measurements. Considering "targen -v -d3 -s20 -g100" alone generates 160 patches, what is the smallest number of additional full-spread patches you think I could get away with and still be effective for future attempts?

A short term workaround would be to set the ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS environment variable to (say) 500.
You're talking about adding ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS to the MS Windows Environmental Variables correct?

Sorry, I simply don't know what that flag does. I'd have to look at the resulting command line(s) to figure it out.
It does exactly what you saw, it normalizes all the measurements in a ti3 file so Black = 0.

[ Hand holding the instrument probably doesn't help much - it's hard to leave it to acclimatise, and body warmth will affect its stability. ]
I'd assume so as well. If you think its enough a problem that it greatly degrades my profile quality, I could try holding it in place with lots of masking tape. I've done that a few times before in the past when I tried tackling a 4000 patch set, but not really practical and a waste of tape.

Graeme Gill

8th May 2013, 09:02

@Graeme Gill

Here are the files resulting from my attempt at the default scenario:

http://www.mediafire.com/?cs01sbjo0c7158a

Before I continue, I'd like to hear how you judge the profile quality this time around. Good? Bad? Better or worse than before?

Looks pretty good by the numbers. Profile gamut surface looks good, test point distribution looks good, and the device link predicts an effective gamma of close to 2.2.
Sanity check of resulting .3dlut shows no surprises.

I changed my pre-calibration black and white level targets quite a bit from those previous profiles, and used the -F switch instead of a black desktop wallpaper w/o icons visible.

This usually has the side-effect of making my native monitor gamma much much higher, probably ~2.6 (didn't check).

I think it just makes it seem higher. Certainly anything not black raises the black level elsewhere on a CRT.

I also sucked it up and did the 1000 full-spread patches, but I'm probably not going to do that again as it takes extreme patience to hold my meter on screen that long, especially with adaptive measurements. Considering "targen -v -d3 -s20 -g100" alone generates 160 patches, what is the smallest number of additional full-spread patches you think I could get away with and still be effective for future attempts?

I think what I would do in your situation is make my way to the nearest haberdashery store, and buy the following:

A length of 1" nylon webbing, long enough to go around your CRT.
Side release clip ends for the above.
Two plastic buckles for the above.

I'd then cut a shorter length of webbing, and make a loop 1/3 from one end of the main webbing, using the two buckles. The idea is that you strap the i1pro firmly in the loop by the body. Then fasten the webbing around the CRT and tighten it to hold the instrument against the screen. You may need to prop something underneath to stop it slipping.

You're talking about adding ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS to the MS Windows Environmental Variables correct?

Yes, although you only need to do that if you want everything to use it. If you are just working in a cmd shell, then "set ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS=500" is enough, but you'll have to do it for each cmd window you open.

Or you can grab the latest code from here: http://www.argyllcms.com/Win32_collink_3dlut.zip, and use targen, dispcal & dispread from it instead.

It does exactly what you saw, it normalizes all the measurements in a ti3 file so Black = 0.

Right. Not something I can ever imagine using.

cyberbeing

8th May 2013, 13:47

Looks pretty good by the numbers. Profile gamut surface looks good, test point distribution looks good, and the device link predicts an effective gamma of close to 2.2.
Sanity check of resulting .3dlut shows no surprises.
Thanks. I'll run through everything once again with the updated tools you provided below, before testing out the 3DLUT, taking measurements, and ultimately making a final judgment on subjective quality compared against my linear source profile + madVR gamma collink & yCMS results. Per your request, I'm making a true effort to give the currently supported collink gamma controls the best chance they can get by optimizing profile quality as much as possible. I don't want to bias myself any more before then, by checking more preliminary results.

I think it just makes it seem higher. Certainly anything not black raises the black level elsewhere on a CRT.
According to ColorHCFR gamma calculations and comparison against a reference power-curve, it really does push my gamma up when setting the black level of my CRT so low. You can see this be looking at how high dispcal pushed up VideoLUT levels in that CAL file. For that prior BT1886 ICC profile I provided you, the dispcal VideoLUT was almost linear. While not really being crushed on a CRT, the curve becomes so shallow near-black that it gives that appearance on images and videos until I get down to batcave levels of ambient light (working-as-intended, but not practical for general viewing...). Pushing my black level up to the optimum level determined by dispcal pre-calibration prevents this, but then black level suffers. It's a trade-off.

I guess it would make sense if the ANSI contrast ratio lowered effective gamma on a CRT, but I'm not measuring patches in that fashion. I've actually experimented before in the past with doing measurements against a neutral gray (128-128-128) background instead of black, but while results seemed good I was concerned it'd be too detrimental for proper distinction in luminance for near-black readings.

I think what I would do in your situation is...
Does this mean my CRT is unpredictable enough that it requires so many full-spread patches, or that full-spread patches just aren't effective enough in Argyll until you get close to the default value of 836?

Or you can grab the latest code from here: http://www.argyllcms.com/Win32_collink_3dlut.zip, and use targen, dispcal & dispread from it instead.
Thanks, I'll check it out tomorrow. Does targen now sort patches the way you mentioned by default or do I need to use a switch to trigger the new behavior?

Also just to clarify, does this mean I should go back and try using the -Ib black drift option in dispcal & dispread once again? Is ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS now defaulting to 500 in those builds, or did you make some other change so the min delay between measurements is adaptive based on difference in patch luminance?

Also is there a reason why collink in the \link\ folder and the one in \bin\ folder have different dates and are not identical? I assume I should be using the on in the \bin\ folder because it's 1 day newer?

[Edit: @madshi I apologize for taking over your thread with color management talk, we probably need a new thread here on Doom9 dedicated to Argyll CMS discussions]

Graeme Gill

8th May 2013, 14:41

Does this mean my CRT is unpredictable enough that it requires so many full-spread patches, or that full-spread patches just aren't effective enough in Argyll until you get close to the default value of 836?

Not at all, but (up to a point) more patches is better. The point of diminishing returns is probably between 1500 and 2500 patches, but even more isn't likely to do harm to anything other than your patience, unless your instrument drifts too much. An i1d3 is probably a better proposition from that point of view. But I wouldn't be afraid of using what you've currently got.

Does targen now sort patches the way you mentioned by default or do I need to use a switch to trigger the new behavior?

It sorts video looking patch sets by default. There's still a measurement time penalty to pay with the extra settling time though.

Also just to clarify, does this mean I should go back and try using the -Ib black drift option in dispcal & dispread once again?

It's up to you to decide if it helps or harms at this stage - my original testing was a little mixed, and I haven't tried to determine if the latest modification helps or not yet.

Is ARGYLL_MIN_DISPLAY_UPDATE_DELAY_MS now defaulting to 500 in those builds, or did you make some other change so the min delay between measurements is adaptive based on difference in patch luminance?

It's more sophisticated than that - there's a rise and fall time constant used to make a (hopefully) worst case estimate of the needed settling time. If the default 200msec is not enough, then the the computed time is used. I'm counting on the fact that CRT's probably have the longest settling time but the shortest update latency, while things like Plasma and LCD have longer update latencies but shorter settling times.

Also is there a reason why collink in the \link\ folder and the one in \bin\ folder have different dates and are not identical? I assume I should be using the on in the \bin\ folder because it's 1 day newer?
Yes - they get built in the sub-directory and copied to the bin director for binary distribution. I just grabbed it from the wrong place in an earlier snapshot. Delete the one in link.

cyberbeing

8th May 2013, 15:30

It sorts video looking patch sets by default.
I'm a bit confused, since targen still seems to be making identical patch sets to the official Argyll CMS 1.5.1.

Yes - they get built in the sub-directory and copied to the bin director for binary distribution. I just grabbed it from the wrong place in an earlier snapshot. Delete the one in link.
All the binary's are still dated 5/3/2013 as well, while only /doc/ & /ref/ are dated 5/8/2013 so I'm unsure you uploaded the correct versions to your server. I tried clearing browser cache and re-downloading multiple times with different browsers, but I'm still getting all 5/3/2013 binaries. Considering you only mentioned the possibility of making these changes on 5/7/2013 , that shouldn't be so unless I'm misunderstanding something.

I'm counting on the fact that CRT's probably have the longest settling time but the shortest update latency, while things like Plasma and LCD have longer update latencies but shorter settling times.
That logic makes sense, since up to this point my i1pro takes much more reliable quick measurements on my Plasma than it does on my CRT, which I'd suspect is because of that long CRT settling time. Visually it almost seem like my CRT takes up to 2-4 seconds worse-case to completely settle between fullscreen pure white and pure black. This settling time is shorter if I raise the black level, so I'd suspect an interrelationship between maximum contrast ratio & CRT settling time (voltage_discharge_amount:phosphor_lag). Lower maximum contrast ratio, less settling time. Higher maximum contrast ratio, more settling time. I assume I don't need to flag my display type for this new compensation your doing, considering I have an i1pro?

Graeme Gill

8th May 2013, 15:57

I'm a bit confused, since targen still seems to be making identical patch sets to the official Argyll CMS 1.5.1.

Sorry about that - try downloading it again.

cyberbeing

8th May 2013, 16:29

Sorry about that - try downloading it again.
Thanks, it works now. 5/9/2013 dates on all binaries in /bin/

1 100.00 100.00 100.00 95.314 100.00 107.67
2 7.0707 7.0707 7.0707 1.0454 1.0961 1.1823

Quick observation that this new optimization logic does not seem to be taking -e properly into account. Could you make another minor change to Targen, so the first -e White patch is placed after the last near-white grayscale? I'm still seeing a single White patch -> Near-black at the very beginning, while the other three -e white patches are optimized and thrown in more logical locations. Increasing -e >4 results in more white patches at the beginning.

digitech

8th May 2013, 17:35

Is this 3Dlut mambo jambo talk purely MadVR related?

n3w813

8th May 2013, 17:40

@cyberbeing
I think you should invest in either....

1.) Tripod mount for your i1Pro
http://www.avsforum.com/t/1404147/tripod-mount-mod-for-i1pro-c6
http://store.spectracal.com/i1pro-tripod-holder.html

2.) Purchase a i1D3 colorimeter to profile against your i1Pro. *Best option IMO since the i1D3 does not require dark calibrations every 10-15 minutes and is more stable and accurate at lower light level readings

Just some suggestions :)

n3w813

8th May 2013, 18:00

Is this 3Dlut mambo jambo talk purely MadVR related?

Nope...but is it not interesting? ;)

Anyway, I kindly invite all future ArgyllCMS discussions over to my thread at AVSForum :)

http://www.avsforum.com/t/1471169/madvr-argyllcms

hdboy

8th May 2013, 22:17

I reported earlier that this mp4 trailer

http://www.hd-trailers.net/yahoo-redir.php?id=94eacdcc-ade6-35fa-aa14-5d22c8d71934&resolution=1080

gave me massive frame drops with smooth motion on. Then I said using FSE fixed it. But turned out I was wrong. It's when I zoom in the picture in MPC (hit Pan&Scan increase size about 8 times) that I get the frame drops with smooth motion on. Playing in unzoomed size or smooth motion off causes no problem. windowed/windowed overlay/FSE makes no difference.

Oddly, most stuff play fine. I don't know what's different with that video (and others).

XRyche

9th May 2013, 00:17

why i've to use ffdshow? actually i'm using lav filters...

I have no clue. I'm not a techy or a videophile. I'm just stating how I am able to use madVR with my TV card using MPC-HC. I just use ffdshow raw video filter not the ffdshow decoder itself. Sorry if I'm not making myself clear enough. Maybe a more technically inclined individual can add their input.

Graeme Gill

9th May 2013, 01:09

Quick observation that this new optimization logic does not seem to be taking -e properly into account. Could you make another minor change to Targen, so the first -e White patch is placed after the last near-white grayscale?

Not really - it does what it does. dispcal/dispread take the sequence into account. targen is just trying to minimise the extra read time this causes.

n3w813

9th May 2013, 02:01