Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Accurate formula to measure display GAMMA !

9 views
Skip to first unread message

Rodney

unread,
Jun 12, 2008, 8:30:05 AM6/12/08
to
Dear ALL,

I am in process of measuring GAMMA of my display device, and wanted
some advice for the same. I refer http://www.brucelindbloom.com/index.html?Eqn_BestGamma.html
to calculate the gamma value, but not getting the correct GAMMA value
as expected.

Steps, i used to measure GAMMA:

a) Measured Luminance for various grayscale using a calibrator.
GrayScale values (val, val, val)
where val range from 1 to 254

b) Normalized grayscale array by dividing each value by 255

c) Normalized luminance array by dividing each value by highest value
of luminance ( 197 in my case)

d) Used formula mentioned in http://www.brucelindbloom.com/index.html?Eqn_BestGamma.html
to compute GAMMA

Also plotted graph on excel for those values. The graph is a proper
curve as expected. BUT, the gamma comes out to be 2.01 for a display
device which has a GAMMA of 2.2. I verfied the GAMMA of device by
measuring it with a third party application which gives GAMMA as 2.21.

Also i tested with other gamma values, my application could not give
correct GAMMA values.

What can be the issue ?
Is the formula accurate mentioned in this site ?
Can you please suggest some alternative formulae?

Please comment.

Thanks,
Rodney

Gernot Hoffmann

unread,
Jun 12, 2008, 8:48:06 AM6/12/08
to

Rodney schrieb:

Rodney,

IMHO the mathematical formulation as used by B.L. is too
simple. Alternatives are here:

http://www.fho-emden.de/~hoffmann/measgamma10022004.pdf

The formulation by logarithms lead in my tests to very bad
results.

Best regards --Gernot Hoffmann

Graeme Gill

unread,
Jun 12, 2008, 9:32:43 AM6/12/08
to
Rodney wrote:

> d) Used formula mentioned in http://www.brucelindbloom.com/index.html?Eqn_BestGamma.html
> to compute GAMMA
>
> Also plotted graph on excel for those values. The graph is a proper
> curve as expected. BUT, the gamma comes out to be 2.01 for a display
> device which has a GAMMA of 2.2. I verfied the GAMMA of device by
> measuring it with a third party application which gives GAMMA as 2.21.

What makes the third part application your golden reference ?

Given that a real device will never have a perfect power curve,
there are an infinite number of ways it can be approximated by a pure
power curve.
Methods off the top of my head :

Compute the 50% input value ratio to the 100% value. Call the
gamma the power that would give this same ratio.

Same as above, but subtract the output value black offset.

Same as above, but remove the non-zero black value as a device offset.

Compute the least squares best fit of a gamma curve measured in device output space.

Compute the least squares best fit of a gamma curve measured in L*a*b* space.

Compute the least maximum error fit ......

etc.

Take your pick.

Graeme Gill.

Rodney

unread,
Jun 12, 2008, 8:19:45 PM6/12/08
to
On Jun 12, 9:48 pm, Gernot Hoffmann <hoffm...@fho-emden.de> wrote:
> Rodney schrieb:
>
>
>
>
>
> > Dear ALL,
>
> > I am in process of measuring GAMMA of my display device, and wanted
> > some advice for the same.  I referhttp://www.brucelindbloom.com/index.html?Eqn_BestGamma.html

> > to calculate the gamma value, but not getting the correct GAMMA value
> > as expected.
>
> > Steps, i used to measure GAMMA:
>
> > a) Measured Luminance  for various grayscale using  a calibrator.
> > GrayScale values (val, val, val)
> > where val range from 1 to 254
>
> > b) Normalized grayscale array by dividing each value by 255
>
> > c) Normalized luminance array by dividing each value by highest value
> > of luminance ( 197 in my case)
>
> > d) Used formula mentioned inhttp://www.brucelindbloom.com/index.html?Eqn_BestGamma.html

> > to compute GAMMA
>
> > Also plotted graph on excel for those values. The graph is a proper
> > curve as expected. BUT, the gamma comes out to be 2.01 for a display
> > device which has a GAMMA of 2.2. I verfied the GAMMA of device by
> > measuring it with a third party application which gives GAMMA as 2.21.
>
> > Also i tested with other gamma values, my application could not give
> > correct GAMMA values.
>
> > What can be the issue ?
> > Is the formula accurate mentioned in this site ?
> > Can you please suggest some alternative formulae?
>
> > Please comment.
>
> > Thanks,
> > Rodney
>
> Rodney,
>
> IMHO the mathematical formulation as used by B.L. is too
> simple. Alternatives are here:
>
> http://www.fho-emden.de/~hoffmann/measgamma10022004.pdf
>
> The formulation by logarithms lead in my tests to very bad
> results.
>
> Best regards --Gernot Hoffmann- Hide quoted text -
>
> - Show quoted text -

HI
Below is data, can anybody compute the gamma from his best/approx best
algo and share the algo? I get 2.051916 gamma using
inhttp://www.brucelindbloom.com/index.html?Eqn_BestGamma.html
//////////
Input_stimulus
0.003922
0.023529
0.043137
0.062745
0.082353
0.101961
0.121569
0.141176
0.160784
0.180392
0.2
0.219608
0.239216
0.258824
0.278431
0.298039
0.317647
0.337255
0.356863
0.376471
0.396078
0.415686
0.435294
0.454902
0.47451
0.494118
0.513725
0.533333
0.552941
0.572549
0.592157
0.611765
0.631373
0.65098
0.670588
0.690196
0.709804
0.729412
0.74902
0.768627
0.788235
0.807843
0.827451
0.847059
0.866667
0.886275
0.905882
0.92549
0.945098
0.964706
0.984314

//////////
Luma
0.001044
0.003034
0.004183
0.005075
0.006317
0.007405
0.0088
0.010078
0.012046
0.014251
0.016191
0.019073
0.022423
0.026112
0.029536
0.033975
0.039181
0.046165
0.052021
0.058742
0.066459
0.075504
0.08405
0.09491
0.10624
0.116753
0.129794
0.143859
0.158203
0.173312
0.190866
0.208449
0.23089
0.251784
0.273881
0.301429
0.32794
0.359782
0.389697
0.425495
0.461436
0.502597
0.547773
0.593995
0.644025
0.702238
0.755649
0.81671
0.867771
0.926902
1
//////////
Rodney.

Gernot Hoffmann

unread,
Jun 13, 2008, 3:23:33 AM6/13/08
to

Rodney schrieb:


Rodney,

I had plugged your data into my program, version B.
The result is Gamma=3.09. This data set isn't even near to 2.0,
but much nearer to 3.0, as it can be shown by drawing such a
function without offset.
Your function table should be built by input 0 (black) as first
input and input 1 (white) as last input. This is necessary for
the normalization. Output should be the luminance in cd/m2.
The normalization can be done by the program.
Please use only 1+ 8 value pairs (input 0.0, 0.125, ..., 1.0).
If you prepare a new set, then I can calculate gamma again.
Meanwhile you may check gamma for R,G,B and for gray by
test patterns, mainly p.7:
http://www.fho-emden.de/~hoffmann/caltutor270900.pdf

Best regards --Gernot Hoffmann

Rodney

unread,
Jun 13, 2008, 4:01:47 AM6/13/08
to
Dear Gernot,
Please find below the updated table, Please share your views for the
same
//////////
Input Stimulus
0
0.12549
0.25098
0.376471
0.501961
0.627451
0.752941
0.878431
1
//////////
Output Stimulus
0.00092
0.002908
0.019715
0.089258
0.203187
0.353551
0.532005
0.744232
1
/////////

Also what approach are you following ?
Rodney

Gernot Hoffmann

unread,
Jun 13, 2008, 6:41:04 AM6/13/08
to

Rodney schrieb:

Rodney,

it's the mathematical model Type B here on p.3:
http://www.fho-emden.de/~hoffmann/measgamma10022004.pdf
The curve fitting is based on numerical optimization (Steepest
Descent), as explained.

Your actual data deliver Gamma=2.175 and Offset=-0.023.
This says: your monitor is too dark at the dark end. Dark
input values will be clipped visually.

Assumed, your white has 100cd/m2, then your black would be
about 0.1cd/m2. More realistic is 0.3cd/m2.

Feel free to send new measured data after a re-calibration
concerning the blackpoint.

Best regards --Gernot Hoffmann

Rodney

unread,
Jun 15, 2008, 9:20:56 PM6/15/08
to
> Best regards --Gernot Hoffmann- Hide quoted text -
>
> - Show quoted text -

Dear Gernot,
Below is the monitor current measurement
Brightness: 213 cd/m2
Black level: 0.2 cd/m2
CT: 6500
///////
Input
0.000000
0.125000
0.250000
0.375000
0.500000
0.625000
0.750000
0.875000
0.996094
////
Output
0.000857
0.004562
0.026489
0.088656
0.183950
0.326179
0.518590
0.744004
1.000000
////
B/w I hope you are using "single dimension steepest descent" algo as u
mentioned in the previous mail. Can you share xls sheet implementing
the same? Or C/C++ implementation?
Thanks,
Rodney

Gernot Hoffmann

unread,
Jun 16, 2008, 2:48:51 AM6/16/08
to

Rodney schrieb:

Rodney,

I'm using the algorithm chapter 4.2,Steepest descent with one-dimen-
sional search.
C/C++ is not a available, only the algorithm and PostScript code.
If you have Photoshop or InDesign or Illustrator or Ghostscript, then
you can use my Postscript code Reference [5] (rename as EPS).
Just replace the one table GamWht for White (gray) by your data, using
e.g. WordPad (plain text). Input left, output right.

Here is the result for your recent data:
http://www.fho-emden.de/~hoffmann/rodney16062008.gif

Note that my program ignores the first value (at 0.0), because this is
mostly uncertain. The next value is IMHO still too dark which leads
in
the curve fitting to a negative offset and it may affect the
appearance
on the monitor.
Please search in this forum for related topics. We ha longer
discussions
about.

Best regards --Gernot Hoffmann

Rodney

unread,
Jun 16, 2008, 6:41:39 AM6/16/08
to

Thanks Gernot, That was quite helpful.
Rodney

Gernot Hoffmann

unread,
Jun 16, 2008, 10:41:03 AM6/16/08
to

Rodney schrieb:

Rodney,

you're welcome. Checking your input data I found a
tiny mistake in my concept.
The normalized input data are 0, 1/8, 2/8, ...,8/8.
This is OK in PostScript, but finally we need integer
numbers. For instance: 4/8 delivers 255/2=127.5 as
input value in the table, but 128 for the color value of
the test pattern.
I would now choose
xi = 0 32 64 96 128 160 192 224 255
The normalized values are then Xi = xi / 255.
The last value is an exception.
These numbers are used for the generation of the
test patterns and for the curve fitting. Therefore I cannot
repair the bug immediately.
Considering all the uncertainties, the mistake isn't very
important, at the moment.

Best regards --Gernot Hoffmann

Gernot Hoffmann

unread,
Jun 19, 2008, 1:33:22 PM6/19/08
to

Gernot Hoffmann schrieb:

The PDF and the program file were updated. A new realistic
example for Eizo CG19 (TFT monitor) was added.
http://www.fho-emden.de/~hoffmann/measgamma10022004.pdf

G.H.

Rodney

unread,
Jun 21, 2008, 1:24:38 AM6/21/08
to

Dear Gernot,

I was going through your algorithm mentioned in
http://www.fho-emden.de/~hoffmann/measgamma10022004.pdf
4.2 Mathematics ( One dimensional search by comparison of ten samples)

and found a small issue in it.

Under "One dimensional search"
q1 = p1
q2 = p2
////
Fm = 999 ----------> ISSUE
///

I suppose it should be "Fm = Fo" instead of "Fm = 999"

PLEASE clarify.
Thank-you,
Rodney

Gernot Hoffmann

unread,
Jun 21, 2008, 2:09:17 AM6/21/08
to

Rodney schrieb:

Rodney,

thanks for the hint. There is indeed a discrepancy between the
(really working) PostScript code with Fm=Fo and the algorithmical
explanation with Fm=999. The PostScript code is valid, but the
other version would IMO work as well.
Explanation:
The number 999 indicates a nonsensical large starting value
for the function F which has to be minimized. Any executed step
will deliver a smaller value. Fo and Fu are the previous and the
actual
values for a global steepest descent step.
Fm is the starting value for the one-dimensional search. The
direction is fixed (no new gradient) but the stepsize has to be
adjusted. This is done by an extremely robust method: subdivide
the global stepsize (which is often too large) into 10 steps and
find the minimum along the trajectory. Under normal circumstances
this would work as well with Fm=999.
Please follow in any case of doubt the PostScript version (new since
a few days, same as in the updated doc).

Best regards --Gernot Hoffmann

Rodney

unread,
Jun 21, 2008, 4:13:12 AM6/21/08
to


Dear Gernot,

Yes, I was in process of implementing the same in C, and this found
this small issue. IF we use Fm=999, the gamma value would not be
accurate. After changing Fm = Fo, the results were quite good.

I have a small query:
1. Why only taking 9 steps for input stimulus 0, .125, ..1.0 ???? Why
not all 255 steps?
2. Why dividing the global stepsize into 10 only??

Thank-you,
Rodney

Gernot Hoffmann

unread,
Jun 21, 2008, 5:53:52 AM6/21/08
to

Rodney schrieb:

Rodney,

meanwhile I've corrected the algorithmical part.

First the second question, about the one-dimensional search.
It's quite common to visualize the function F(p1,p2) as a parabolic
pot. The minimum of this pot is wanted. Any walk downhill would
improve the solution, but more effective is the steepest descent.
If the minimum had the value F=0 then the stepsize control would
be effective. If the minimum has a value F>0 then one has to search,
preferably along the previous gradient direction.
The minimum is a relative one, therefore a better resolution than 1/10
would not improve much.
I had also tried the replacement of the one-dimensional trajectory
by a parabola (which delivers the minimum directly), but there are
so many odd special cases that I prefered my robust method.

First question:
I'm using only 9 measurements (value at 0 ignored) because more
won't improve the accuracy. My instrument is Eye-One Pro.
Indicated are steps 0.1 cd/m2. The repeatability is worse.
The luminance depends considerably on the position on the moni-
tor. I'm measuring in the center, approximately in the position
which was used for calibration and characterization.
Then we have the offset problem. During new measurements for
Eizo CG19 I found settings with little offsets. Therefore I have
modified the program additionally for Type A, the simple power
function.
As a result I would say: a monitor doesn't have a well defined
gamma or four distinct well defined gammas for the channels
and the composite 'channel'. Measuring more points would be
wasted time, IMHO.

A least squares curve fitting algorithm can be accurate with double
precision (not so in PostScript), but this accuracy says almost
nothing about the physical relevance of the results.

Best regards --Gernot Hoffmann

HA HUY THANH

unread,
Jun 21, 2008, 7:39:17 AM6/21/08
to
On Jun 21, 1:53 am, Gernot Hoffmann <hoffm...@fho-emden.de> wrote:


Hi Gernot:
I don't agree with you. More measured points will give us much better
results.
Using too few points (as your case: 9) is risky since if one or two
measurements are not accurate, the overall curve fitting error will
blow up.

Huy Thanh


> First question:
> I'm using only 9 measurements (value at 0 ignored) because more
> won't improve the accuracy. My instrument is Eye-One Pro.
> Indicated are steps 0.1 cd/m2. The repeatability is worse.
> The luminance depends considerably on the position on the moni-
> tor. I'm measuring in the center, approximately in the position
> which was used for calibration and characterization.
> Then we have the offset problem. During new measurements for
> Eizo CG19 I found settings with little offsets. Therefore I have
> modified the program additionally for Type A, the simple power
> function.
> As a result I would say: a monitor doesn't have a well defined
> gamma or four distinct well defined gammas for the channels
> and the composite 'channel'. Measuring more points would be
> wasted time, IMHO.
>
> A least squares curve fitting algorithm can be accurate with double
> precision (not so in PostScript), but this accuracy says almost
> nothing about the physical relevance of the results.
>

Phil Sherrod

unread,
Jun 21, 2008, 10:09:40 AM6/21/08
to

Sorry I'm late to the party.

Using my general nonlinear regression curve fitting program NLREG
(http://www.nlreg.com) on this data, I computed the following parameter values:

for y = y0 + (1-y0)*x^G

Y0 = -0.00780997971
G = 2.32531353

This fit explains 99.94% of the variance (R^2)
You can see a plot of the fitted function at
http://sherrod.sandh.com/test/CRTcurve.jpg

--
Phil Sherrod
(PhilSherrod 'at' comcast.net)
http://www.dtreg.com (Decision trees, Neural networks, SVM and Genetic
modeling)
http://www.nlreg.com (Nonlinear Regression)

Gernot Hoffmann

unread,
Jun 21, 2008, 11:03:49 AM6/21/08
to

Phil Sherrod schrieb:

Phil,

thanks for your test:
yo=-0.0078
G = 2.325

In my test the value pair at x=0 was ignored. If I add this pair
then I get:
yo=-0.01
G =2.311

Within PostScript accuracy, using a rather coarse exit
condition, this is almost the same.
The algorithms are always tested by samples which
are derived directly from a mathematical function of the
appropriate type.

My investigation has its roots in unsatisfying comparisons
between three instruments for monitor calibration all over the
years:
X-Rite DTP-92
Avantes Spectrocam
Gretag Macbeth Eye-One Pro

Some years ago the black calibration for CRT monitors
was a big issue. This uncertainty and also the mostly uncertain
measuring result at the dark end led to the conclusion that
it might be better to ignore the first value pair at 0.

My intention was the discussion of concepts. For serious
numerical investigations I wouldn't use PostScript (which
is perfect for vector graphics and text), but another language
with double precision arithmetic.

Best regards --Gernot Hoffmann

Phil Sherrod

unread,
Jun 21, 2008, 11:10:36 AM6/21/08
to

On 21-Jun-2008, Gernot Hoffmann <hoff...@fho-emden.de> wrote:

> In my test the value pair at x=0 was ignored.

If I ignore the pair with x=0, I compute:

Y0 = -0.0132206242
G = 2.29734648

Here is the NLREG program for the analysis. You can download a demo version of
NLREG from http://www.nlreg.com and run the analysis yourself with different
data.

Variables x,y;
Parameters y0,G=2.5;
Function y = y0 + (1-y0)*x^G;
Plot;
Data;
0.000000, 0.000857
0.125000, 0.004562
0.250000, 0.026489
0.375000, 0.088656
0.500000, 0.183950
0.625000, 0.326179
0.750000, 0.518590
0.875000, 0.744004
0.996094, 1.000000

HA HUY THANH

unread,
Jun 21, 2008, 2:48:29 PM6/21/08
to
On Jun 21, 7:03 am, Gernot Hoffmann <hoffm...@fho-emden.de> wrote:
> My investigation has its roots in unsatisfying comparisons
> between three instruments for monitor calibration all over the
> years:
> X-Rite DTP-92
> Avantes Spectrocam
> Gretag Macbeth Eye-One Pro
>
> Some years ago the black calibration for CRT monitors
> was a big issue. This uncertainty and also the mostly uncertain
> measuring result at the dark end led to the conclusion that
> it might be better to ignore the first value pair at 0.

Measurement instruments made several years ago often have bad accuracy
in low luminance. Using these instruments we might get very bad
measured data in the low digital values while rather good data in the
mid- and high ranges. That is why a single curve doesn't fit the data
well.
According to Webb law, human visual system is more sensitive with the
changes in low luminance range than that in the high range. Therefore,
ignoring low levels is not acceptable for some assessment applications
using softcopy environment.
A better solution to this issue is to use two non-linear curves, one
for low digital levels and the other one for mid and high digital
levels. In our work, the cut-off point we choose is 85 in a range from
0-255, and our piecewise Gain-Offset-Gamma model works very well.

Best,

Huy Thanh

Gerhard Fuernkranz

unread,
Jun 21, 2008, 3:20:00 PM6/21/08
to
HA HUY THANH wrote:
> On Jun 21, 1:53 am, Gernot Hoffmann <hoffm...@fho-emden.de> wrote:
>
>
> Hi Gernot:
> I don't agree with you. More measured points will give us much better
> results.
> Using too few points (as your case: 9) is risky since if one or two
> measurements are not accurate, the overall curve fitting error will
> blow up.
>

Basically, more samples are expected to result in a better averaging out
of the repeatability error [at least as long it is random error, and not
systematic error, like e.g. drift or spatial variations].

If we compute the mean value of N samples from a (normally distributed)
random variable with standard deviation s, then the mean of the N
samples is not the mean of the original distribution, but just an
estimator for the true mean, with an uncertainty (standard deviation) of
1/sqrt(N)*s; i.e. the more samples, the better is the confidence that
the mean value computed from the samples corresponds to the true mean
value. A similar rule applies to curve fitting as well; the more samples
are used, the better will be the confidence that the estimated model
fits the average behavior of the device [which we cannot measure
directly, due to the measurement errors]. But there is certainly a
practical limit beyond which it does no longer make sense to use even
more points - once the model fits the data with a reasonably low
variance (say 0.25 delta E, or whatever one finds appropriate), so that
the residuals are vastly determined by the bias of the model, then more
samples won't be helpful, IMO.

The distribution of the used samples can make a significant difference
too. If the model is biased [i.e. if the average device behavior does
not exactly follow the assumed model - and likely this is the case in
practice] then the curve fitting will [even in absence of any
repeatability noise] end up with different estimates for the model
parameters, if the samples are for instance

1. evenly spaced in RGB space
2. evenly spaced in Y space
3. evenly spaced in L* space
4. evenly spaced in desity [log(Y)] space
5. etc.

Similarly, the error metric being minimized plays a significant role as
well, and we will also get different result if we minimize for instance
the sum of the squared errors in Y space, or if we minimize a perceptual
error metric like the SSE in L* space. That's also the reason why the
linear regression log(Y) vs. log(RGB) did not give reasonable results,
since an unweighted linear regression in log space minimizes the SSE in
log(Y) space and therefore overweights the perceptual error of dark
samples significantly [i.e. the error of dark samples in log space may
be huge, although the corresponding perceptual error in L* space may be
very small; e.g. densities D=3 and D=4 are visually virtually
indistinguishable (for an observer adapted to a white level of D=0),
despite the huge density difference of 1]. IMO it is still possible to
do a linear regression in log space in order to find a good approximate
solution for a model Y=R.^gamma.*exp(scale), but it is necessary to do a
weighted linear regression which minimizes
sum((w.*(log(Y)-log(R)*gamma+scale)).^2), where the individual weight
w(i) of each data point i is chosen according to the desired error
metric, for instance w = d Y / d log(Y) for minimizing the SSE in Y
space, or w = d L* / d log(Y) if a perceptual error metric is desired, etc.

One more issue is that the "repeatability noise" may not be
homoscedastic, i.e. the repeatability may be better in some regions than
in others. This can be for instance addressed by using lower weights for
data point in a region with higher repeatability error, and
overweighting data points in a region with better repeatability.

A finial issue to consider which comes into my mind is that the
repeatability error may not be normally distributed [or at least not in
in the space in which we want to compute the error metric], so that
least squares may no longer be be the best unbiased maximum likelihood
estimator.

Regards
Gerhard

Gerhard Fuernkranz

unread,
Jun 21, 2008, 4:27:38 PM6/21/08
to
HA HUY THANH wrote:
> A better solution to this issue is to use two non-linear curves, one
> for low digital levels and the other one for mid and high digital
> levels. In our work, the cut-off point we choose is 85 in a range from
> 0-255, and our piecewise Gain-Offset-Gamma model works very well.
>

Interesting approach. I'm wondering, how do you avoid a discontinuity at
the point where the two curves are crossing? The 1st derivatives will
likely not match, or do they? Do you smoothly blend between the two curves?

Granted that a simple GGO model is not sufficient, what's the advantage
of the piecewise GGO model over fitting the data with any other function
with more than three degrees of freedom? Or was it more or less
arbitrarily chosen, because it basically did fulfill your needs?

-Gerhard

HA HUY THANH

unread,
Jun 21, 2008, 11:26:02 PM6/21/08
to
Good question, Gerhard.
To avoid the discontinuity, we apply two GOG curves, one fits the
whole range including the low and high digital values, the other one
fits only the low digital values. Since there are close outputs and
slope at the boundary we can obtain an acceptable smoothness there.

On Jun 21, 12:27 pm, Gerhard Fuernkranz <nospam...@gmx.de> wrote:
>
> Interesting approach. I'm wondering, how do you avoid a discontinuity at
> the point where the two curves are crossing? The 1st derivatives will
> likely not match, or do they? Do you smoothly blend between the two curves?
>


> Granted that a simple GGO model is not sufficient, what's the advantage
> of the piecewise GGO model over fitting the data with any other function
> with more than three degrees of freedom? Or was it more or less
> arbitrarily chosen, because it basically did fulfill your needs?
>
> -Gerhard

Yes, it did. We used a spectroradiometer PR-705 which provides with an
acceptable measurement accuracy in the low luminance range. When we
used a single GOG to fit the data, we observed that the curve fits
well the points in the mid and high luminance range, but badly in the
low range. That is why two-curve approach, one for the mid and high
ranges, and the other one for the low range was considered. BTW, this
approach was developed by a graduate in our lab a few years ago and I
know he published it somewhere.

HA HUY THANH

unread,
Jun 21, 2008, 11:34:24 PM6/21/08
to

I totally agree with you. However probably, there is misunderstanding
here. In my earlier post, I did not mean that using too many samples
will be a good idea. I know, doing that way may lead to the
overfitting the model. What I meant is that we need "enough" data. 9
samples as suggested by Gernot is not enough, in my opinion.

BTW, if I can measure many points and if the hardware is OK, I will
generate a look-up table which contains 256 inputs and 256 outputs.
That is much better than using any non-linearity model.
Thanh

Gerhard Fuernkranz

unread,
Jun 22, 2008, 5:29:47 AM6/22/08
to
HA HUY THANH wrote:
>> Basically, more samples are expected to result in a better averaging out
>> of the repeatability error [at least as long it is random error, and not
>> systematic error, like e.g. drift or spatial variations].
>>
>> If we compute the mean value of N samples from a (normally distributed)
>> random variable with standard deviation s, then the mean of the N
>> samples is not the mean of the original distribution, but just an
>> estimator for the true mean, with an uncertainty (standard deviation) of
>> 1/sqrt(N)*s; i.e. the more samples, the better is the confidence that
>> the mean value computed from the samples corresponds to the true mean
>> value. A similar rule applies to curve fitting as well; the more samples
>> are used, the better will be the confidence that the estimated model
>> fits the average behavior of the device [which we cannot measure
>> directly, due to the measurement errors]. But there is certainly a
>> practical limit beyond which it does no longer make sense to use even
>> more points - once the model fits the data with a reasonably low
>> variance (say 0.25 delta E, or whatever one finds appropriate), so that
>> the residuals are vastly determined by the bias of the model, then more
>> samples won't be helpful, IMO.
>
> I totally agree with you. However probably, there is misunderstanding
> here. In my earlier post, I did not mean that using too many samples
> will be a good idea.

Thanh, actually my intention was not to object your previous posting. I just wanted to contribute a couple of thoughts to the discussion, and your posting just happened to be the point, where I joined :-)


> I know, doing that way may lead to the overfitting the model.

But here I disagree, since overfitting is not caused by too many
samples, but is also a consequence of too few samples [compared to the
number of model parameters]. Basically, the number of samples can never
be too large, IMO; the more the better. What I wanted to say is that
beyond a particular number there may be any practical relevance for
using even more ones. And there may also be practical limitations which
make the acquisition of a huge number of samples impossible.

> What I meant is that we need "enough" data. 9
> samples as suggested by Gernot is not enough, in my opinion.

This may indeed be the case (it's my subjective feeling too), but it is
hard to assess objectively w/o having more information like e.g. the
repeatability of the readings in the individual case.

And if one takes a large number of readings, which takes quite some
time, there is on the other hand a risk that the device may drift while
the readings are acquired, introducing additional measurement errors.
This may be not so much an issue for high-end displays, but at least for
consumer-grade displays [like my notebook's display] the drift over time
seems not to be negligible.

[Particularly the backlight intensity seems to be an issue on my
display, so what I tried is to take a white reading after every N
readings, and compute a "current white level" (which is a function of
time) as a moving average of these white readings, in order to
compensate the drift by normalizing all readings to a fixed white level]

> BTW, if I can measure many points and if the hardware is OK, I will
> generate a look-up table which contains 256 inputs and 256 outputs.
> That is much better than using any non-linearity model.

I think that directly filling 256 LUT entries with 256 noisy readings
may not be a good idea either, but some kind of smoothing my certainly
be appreciated. And one way to smooth the readings is fitting them to a
smooth model [this does not need to be a GGO model, but could also be a
non-parametric one, like polynomials, splines, etc.] and to resample the
estimated model in order to fill the LUT.

Regards,
Gerhard

Gerhard Fuernkranz

unread,
Jun 22, 2008, 5:31:58 AM6/22/08
to
Gerhard Fuernkranz wrote:
> be too large, IMO; the more the better. What I wanted to say is that
> beyond a particular number there may be any practical relevance for
>

Sorry, this should read:
... may NOT be...

> using even more ones.

Gernot Hoffmann

unread,
Jun 24, 2008, 5:13:24 AM6/24/08
to

>...


> > What I meant is that we need "enough" data. 9
> > samples as suggested by Gernot is not enough, in my opinion.
>
> This may indeed be the case (it's my subjective feeling too), but it is
> hard to assess objectively w/o having more information like e.g. the
> repeatability of the readings in the individual case.

>...
> Regards,
> Gerhard

Gerhard,

I'm really not insisting on 8+1 samples per channel.
Let's have a look at the target GMB
LCD Monitor Reference 2.0.txt

Total number of samples: 99
Red samples: 11+black
Green samples: 11+black
Blue samples: 11+black
Gray samples: 8+black
The other 58 samples contain two or three primaries.
This indicates, that a per-channel interpretation is
of limited value.
For instance: the sum of the channel luminances
is not exactly equal to the composite luminance.

Best regards --Gernot HoffmannThe test results

0 new messages