GMB Match 3.6.1. bug ?

[32BT]

I recently downloaded match 3.6.1. and tried calibrating an LCD to native white and native gamma, but instead of adjusting the video lut to the closest gamma curve, it simply leaves the video lut untouched it seems.

And as LCDs go, its brightest white is a significantly different color than a shade of gray, so leaving everything native results in terrible calibration, and thus becomes ill advice.

Selecting an actual white point temp and gamma, results in a perfectly usable calibration with uniform graywedges. So the software / puck seem to be ok.

Can anyone concur?

[pobrien3]

I've been experimenting with a couple of demo monitor software packages (ColorEyes and BasICColor), and comparing them with my current software, Monaco Optix.  I have two Apple Cinema Displays running on a WinXP machine, and profiled at native whitepoint.  I think native on my displays is around 5750k.

After getting a good quality profile made for my new printer I had cause to think my monitors were too warm, so I tried re-profiling them with demo versions of the above and with the Monaco. However, I tried again at D65 (6500k) and am now getting a far better monitor-to-print match.

Setting native for your monitor possibly gets you a bigger gamut, but for me it was inaccurate.

Peter

[digitaldog]

I recently downloaded match 3.6.1. and tried calibrating an LCD to native white and native gamma, but instead of adjusting the video lut to the closest gamma curve, it simply leaves the video lut untouched it seems.
[a href=\"index.php?act=findpost&pid=71746\"][{POST_SNAPBACK}][/a]

That's exactly what Native should do, touch nothing.

[32BT]

That's exactly what Native should do, touch nothing.

Why so? Like I said: the white point of most LCDs is quite different from the shades of gray. So, if the white point measures some temp, shouldn't the software try to calibrate the shades of gray to the same temp?

Or to generalize: by chosing native, why would one assume the gray balance is balanced over the entire range?

And additionally, since the graybalance is hardly ever balanced, why is the general advice to choose native for LCDs?

[32BT]

I've been experimenting with a couple of demo monitor software packages (ColorEyes and BasICColor),

The softwares mentioned are well regarded. You can easily choose a non-native white point. And the behavior for those softwares is probably different and more akin to what I would like to see.
With Match I still get decent results when choosing a specific white point. However, when choosing a native white point, all I want to see is a video lut that has its endpoints at (1.0, 1.0, 1.0), but the software should still try to balance the gray over the entire range so that every shade of gray reads the same temp.

[digitaldog]

Why so? Like I said: the white point of most LCDs is quite different from the shades of gray. So, if the white point measures some temp, shouldn't the software try to calibrate the shades of gray to the same temp?

Or to generalize: by chosing native, why would one assume the gray balance is balanced over the entire range?

And additionally, since the graybalance is hardly ever balanced, why is the general advice to choose native for LCDs?
[a href=\"index.php?act=findpost&pid=71762\"][{POST_SNAPBACK}][/a]

The profile should handle the corrections to the WP (and for that matter grays) in ICC aware applications. You can do this with the LUTs or you can do this with the profile. With Native, you're doing it with the profile and not the LUTs. The profile should in theory provide a much better job in ICC aware applications due to a number of factors (like working at a higher bit depth, more data points). If you're using Native, its a good idea if possible to build a LUT based profile (not the default Matrix profile). And when you test this, of course you have to do this in something like Photoshop.

The profile and software should handle grays and the WP among other things.

[32BT]

The profile should handle the corrections to the WP (and for that matter grays) in ICC aware applications. You can do this with the LUTs or you can do this with the profile. With Native, you're doing it with the profile and not the LUTs.

Well, yeah, but so much for theory. Match is giving me profiles with a single point gamma curve (even the lut based versions are merely pure gamma curves and completely linear ABA LUTS). Nothing in the profile suggests it is balancing grays (and/or rebalancing colors)?

In addition, since the lut-based profiles use XYZ luts, as opposed to Lab luts, I strongly doubt the precision gain, and believe it may actually hinder proper conversion. But anyway, like I said: choosing a specific gamma value gives me a perfectly usable profile, either lut-based or matrix-based, so it's not too big a deal...

[Serge Cashman]

Since a rationale for "Native" targets is to minimize or completely eliminate the use of videocard LUTs it's hard to understand why you would complain.  Obviously if your monitor's native state is unuseable then you can't use Native targets...


Could you explain in more detail how you evaluate the profiles?

[32BT]

Since a rationale for "Native" targets is to minimize or completely eliminate the use of videocard LUTs it's hard to understand why you would complain.  Obviously if your monitor's native state is unuseable then you can't use Native targets...
Could you explain in more detail how you evaluate the profiles?
[a href=\"index.php?act=findpost&pid=71816\"][{POST_SNAPBACK}][/a]

Minimize? Yes. Eliminate? Maybe in a perfect world, but then you wouldn't need calibration in the first place, no?

Just to recap:

TRC = Tonal Response Curve
display profiles contain a gamma curve entry that software can use to prepare data for proper display. This gamma curve can either be a single point designating a pure gamma value, or it can be multiple points designating a curve. Precision can be 16bit.

VCGT = Video Card Gamma Type
in addition, profiles can contain a video card lut entry. While it can describe a single gamma value, this entry usually describes an actual LUT. Precision can be 16bit. (As stored in the profile. The video card itself may or may not honor this precision).



There are a couple of possible scenarios for proper display preparation. The 2 relevant cases are:

1. Set a single gamma value in the TRC, and set the video card lut such that the separate channels actually behave like that pure gamma value.

2. Set a specific channel behavior in the TRC, and leave the video card lut linear.

For GMB, native everything apparently means scenario 2, except that GMB seems to add just a single gamma value in the TRC. Device obviously doesn't respond like a pure gamma curve, thus bad calibration results, hence ill advice.

A variation on 1:

3. Find the closest gamma value for each individual channel, set this in the TRC, then adjust the video card lut accordingly.

This is what I would call "Native Gamma", and minimizes video lut corrections.

A variation on 2:

4. Completely describe the device behavior in 3D luts, leave the video card lut linear.

You would think GMB does this in native everything and lut based profiles, but it doesn't. For some reason, the B2A tables (the relevant tables for the job at hand) are completely linear, and the matrix entry is (ab)used for normal matrix based conversions. The gamma curves are pure gamma curves again, except they are now stored in the 3D lut curve entry. And storing gamma curves in the 3D lut curve can actually harm precision. In addition, the tables are XYZ based, which is totally ridiculous for the task at hand since the video pipeline behaves more or less perceptual. A Lab table is more appropriate, and trying to use linear gamma data in profile tables to correct for possible perceptual pipeline deviations is simply IMPOSSIBLE!

(This is similar to the linear RAW data ETTR discussions we all have every now and then, except the linear RAW data is now described in 5 bit precision. Imagine that...)

So, unless I'm doing something seriously wrong, selecting lut-based profiles in GMB is simply misleading, as far as I can tell. Thoroughly not recommended...

[Serge Cashman]

I must admit 3d luts and B2A tables (as well as XYZ and Lab) are still over my head. But I do understand the rest of it.

vcgt is just instructions to the videocard to change colors via LUTs. It doesn't "describe", it "instructs". Or "makes", or "forces" or whatever term you like. Even when it's 16 bit it is delivered to the monitor over an 8 bit connection.

TRC (along with wtpt and perhaps other tags) are the descriptions of the display, used by colormanaged software in gamut conversions....

They are completely different from each other.

You do want videocard LUTs "linear" in case of LCDs (in other words "non-existant") because any adjustment to them is an 8 bit adjustment resulting in less than 256 values on each channel.

[Serge Cashman]

Minimize? Yes. Eliminate? Maybe in a perfect world, but then you wouldn't need calibration in the first place, no?

Native/Native is an equivalent of "Profile, don't calibrate"  option in Basiccolor.

Just like the name implies....

[32BT]

I must admit 3d luts and B2A tables (as well as XYZ and Lab) are still over my head. But I do understand the rest of it.

vcgt is just instructions to the videocard to change colors via LUTs. It doesn't "describe", it "instructs". Or "makes", or "forces" or whatever term you like. Even when it's 16 bit it is delivered to the monitor over an 8 bit connection.

TRC (along with wtpt and perhaps other tags) are the descriptions of the display, used by colormanaged software in gamut conversions....

They are completely different from each other.

You do want videocard LUTs "linear" in case of LCDs (in other words "non-existant") because any adjustment to them is an 8 bit adjustment resulting in less than 256 values on each channel.
[a href=\"index.php?act=findpost&pid=71841\"][{POST_SNAPBACK}][/a]

c'mon Serge, we've had this discussion before. Current video cards have greater than 8bit luts and use temporal dithering to overcome the 8bit video connection. Whether the system actually delivers the VCGT data in 16bit to the video card is another issue.

But even so. If some software is offering the option of not using the video lut, then it can (and probably should) still do the necessary corrections in either the TRC or 3D Tables. The strength of basiccolor is in the meticulous graybalancing during calibration. I may want a linear video lut, but I still want the meticulous graybalance...

As for basiccolor: "no calibration" is probably a better designation, but in basiccolor it actually means "use current video lut", which is different from "use linear video lut". Try making a calibrated run first, then run a profile only. On the mac it simply uses the previous video lut setting and stores that in the profile...

[Jack Flesher]

FWIW:

I recently installed 3.6.1 (Win XP) and profiled my LCD using native white point, but specifying gamma 2.2.  It appears to have worked perfectly, showing very neutral grays and accurate color renderings for print output.  So maybe the gamma choice is the differentiator?

[Nill Toulme]

Jack which monitor do you have? Not one of the new NEC's, is it?

Nill
~~
www.toulme.net

[Serge Cashman]

As for basiccolor: "no calibration" is probably a better designation, but in basiccolor it actually means "use current video lut", which is different from "use linear video lut". Try making a calibrated run first, then run a profile only. On the mac it simply uses the previous video lut setting and stores that in the profile...
[a href=\"index.php?act=findpost&pid=71846\"][{POST_SNAPBACK}][/a]

That's true, I didn'r realize that.

However,  it obviously skips the greybalancing part of the calibration...

Now... What am I looking for in the tags to find out if there is an attempt at greybalancing via TRC tags or something else? (which would obviously only matter for colormanaged applications)...

[Jack Flesher]

Jack which monitor do you have? Not one of the new NEC's, is it?

Nill
~~
www.toulme.net
[a href=\"index.php?act=findpost&pid=71886\"][{POST_SNAPBACK}][/a]

No...  This is on my year-old and correspondingly tired Samsung 23".  

Instead of the NEC, I am trying to work up the courage to spring for the new Adobe-RGB Eizo, but given its cost I may just end up with the 'cheapie' Eizo

[32BT]

FWIW:

I recently installed 3.6.1 (Win XP) and profiled my LCD using native white point, but specifying gamma 2.2.  It appears to have worked perfectly, showing very neutral grays and accurate color renderings for print output.  So maybe the gamma choice is the differentiator?
[a href=\"index.php?act=findpost&pid=71882\"][{POST_SNAPBACK}][/a]

Yes, that is what I eventually did and the results are indeed neutral while endpoints are (close to) 1.0. From a previous run I can select the closest gamma value but it appears that 2.2 is close enough.  

This whole issue has made me aware of something else: Using a lut-based profile and linear video lut, leaves the GUI elements in a different state then what PS is showing. Even after restarting the OS. Apparently the Mac OS X GUI is not as colormanaged as I believed it to be.

This then makes the linear video lut a very questionable endeavor. Problem obviously is that ALL GUI elements become a different gray then the image that is to be judged. All GUI elements includes the gray backing of Photoshop...!!!!

So, again, unless somebody can enlighten me, I suggest that the "native everything" advice is dropped until further notice.

lut-based profiles is another questionable advice if Match is concerned.

Oh well, got that of my chest. Now of-course we can re-open the entire discussion about whether Macs are 1.8 or 2.2 gamma, because if the mac OS is not properly color-managing its GUI, then what is the proper target?
This was tongue-in-cheek, I am actually more interested in whether the OS is really using the high bit video luts to their maximum benefit, and so far it doesn't seem to do so. Neither can I find info on the ATI website about this...

[32BT]

Now... What am I looking for in the tags to find out if there is an attempt at greybalancing via TRC tags or something else? (which would obviously only matter for colormanaged applications)...
[a href=\"index.php?act=findpost&pid=71912\"][{POST_SNAPBACK}][/a]

A bumpy curve. Look at the curves in the VCGT tag of a calibration run. It should deviate here or there. And for LCDs you would definitely have skewed curves near white.

TRCs can be adjusted accordingly (except it will include the familiar gamma curvature). The endpoints can also be something other than 1.0 for specific white-point selections.

Note however that I don't advocate using a TRC for this purpose, but nothing stops software from doing so.

B2A 3D luts contain a curve entry, but for display profiles I wouldn't know why anyone would want to enter a gamma curve in there in combination with XYZ tables to do corrections. If you need a gamma curve there, than Lab tables are most likely more appropriate. In addition, GMB Match seems to do totally nothing in the actual table, so lut based profiles from match are ... well, a waste of diskspace.

[Serge Cashman]

Don't know Oscar. I have very average LCDs. "Native" was designed for average LCDs. A profile that uses no LUT adjustments, no matter if it's created by Match3 or Basiccolor results in the cleanest grayscale gradient on my monitors. BTW, both in colormanaged and non-colormanaged applications those profiles  (i1 and BC) are indistinguishable from each other - looking very closely at a grayscale gradient.

Any other profile to any other target created by any other software (Spyder2 Pro, Coloreyes, Basiccolor, Match3) creates more visible artifacts on a greyscale gradient.

I'm not obsessed over it or anything... I use D65/2.2 now (I have 2 monitors and you may have heard that in XP it may require some micromanagement).   But I really see why Native targets make sense.