[argyllcms] colprof with 836 data points
- From: <graxx@xxxxxxxxxxxx>
- To: <argyllcms@xxxxxxxxxxxxx>
- Date: Mon, 3 Feb 2020 15:13:40 -0500
Decided to "Go for the gold!" and got 836 data points for my lowly NEC
PA271W monitor.
Here are the important statistics:
peak err = 1.146645, avg err = 0.277301, RMS = 0.314956
For 300 data points, the statistics were:
peak err = 0.888202, avg err = 0.244000, RMS = 0.285845
As Gerard pointed out, the statistics may have gone up but the "splines"
have more "real data" to "chew on" instead of leaving whole swaf of color
space uncharacterized.
What is the meaning of "Overdetermination" in the context of fitting
splines?
/ Roger
From: argyllcms-bounce@xxxxxxxxxxxxx <argyllcms-bounce@xxxxxxxxxxxxx> On
Behalf Of Gerhard Fuernkranz
Sent: Sunday, February 2, 2020 6:03 PM
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: colprof
Am 02.02.20 um 23:22 schrieb graxx@xxxxxxxxxxxx <
mailto:graxx@xxxxxxxxxxxx>
:
Gerard,
The outFile300 -> XYZ Lux + Matrix profile 'stats' are as follows :
peak err = 0.888202, avg err = 0.244000, RMS = 0.285845
This is way better than the '-as' Matrix+shaper profile stats:
peak err = 2.220396, avg err = 0.642870, RMS = 0.747308
CLUT models can adapt even more "flexiby" to the data than matrix/shaper
profiles, having a typical number of 50...200 effective parameters,
depending on the chosen amount of smoothing (just a rough number from my
experience). So 300 points may still be too low in order to achive a
significant overdetermination.
One comment.
A quick look at the TRC tags reveals an important difference in the -ag
compared to the -as encoding.
The -ag encoding starts at 0 where the -as encoding does not. That's an
important difference.
A power function y=x^gamma always passes through the point (0,0). The
display's black level may not be zero, though. A potential idea to might be
to fit a gamma+offset model, and record the resulting TRC as 1D LUT (but I
think this would need to be implemented first, and I can't say in advance
whether it would provide the expected value). Generally it is always a good
idea to use the "stiffest" model (with the fewest number of parameters)
which can describe the (noise-free) device characteristics accurately
enough.
Regards,
Gerhard
Other related posts:
