Pages: [1]   Go Down

Author Topic: Anomolies in I1Profiler when RGB values are not in a plane  (Read 647 times)

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2197
Anomolies in I1Profiler when RGB values are not in a plane
« on: September 12, 2020, 04:59:36 pm »

I ran across an odd issue in I1Profiler. It seems to depend on RGB patches existing in planes where the R, G, and B of near patches require the same values, whether fractional or pure integer.

Experiment:
I decided to compare I1Profiler with colprof using a 18x18x18 uniform grid. This results in steps of 17 from 0 to 255. To eliminate the printer variables and just look at how the engine generated profiles, I converted the RGB values to Lab values in Adobe RGB colorspace then combined the RGB and Lab and created PCSLAB ICC profiles.

Running a million random RGB values and testing the resulting Lab values against actual Adobe RGB conversions produced good results. Average dE76 of .04 and worst case of .9 which occurred at the boundaries near R=G=B lower than 10. This is also where the Adobe RGB space has the greatest curve and so the LUTs are not going to be as precise.

However, Argyll's colprof had a much higher error with an average dE76 of .3 and max of 2.5. This seems to be due to a curve fitting to reduce measurement noise that I1Profiler doesn't use. When colprof is run with "-r .01" which tells colprof to assume almost no measurement noise the errors were only slightly more than i1Profiler and consistent with the slightly smaller number of LUTs on a side in the ICC profile.

However, here's the surprise.

I next randomly increased by 1 each of the RGB values (that is each R,G,B had a 50% chance of getting increased by 1) excepting ones that were at 0 or 255 and ran the same tests.

Argyll's colprof had virtually identical dEs while i1Profiler's error rates increased markedly to ave dE76 of .6 and max dE of 9. Further experiments indicate that i1PRofiler appears to be looking for planes where the RGB values are identical. They can be fractional w/o messing things up but the nearby ones must all be identical. It appears like they just expand the nearby search until they encounter RGB values in a plane increasing the separation between points in the plane. This increases errors from Lab curvature. Presumably this is to simplify interpolation processes. Colprof is not sensitive to this at all.

This is not a general problem. I1Profiler's software generates RGB values on planes but for anyone generating their own RGB values it's not a good idea to get fancy.

At this point I checked the special patch sets I made in the past but they all have regular grids that produce planes in nearby RGB points and produced results similarly between Argyll and I1Profiler.
« Last Edit: September 12, 2020, 05:25:15 pm by Doug Gray »
Logged

Ethan Hansen

  • Full Member
  • ***
  • Offline Offline
  • Posts: 148
    • Dry Creek Photo
Re: Anomolies in I1Profiler when RGB values are not in a plane
« Reply #1 on: September 25, 2020, 12:30:31 pm »

Doug,

I expect that the behavior you describe is related to the underlying fitting algorithms.

Argyll mainly relies on regularized splines in fitting measurements to reference points. Regularized splines attempt to meld the strengths of thin plate splines and thin membrane splines. A key point is that the fit does not require reference points be distributed in any particular manner. Having closer spacing of data points at the edges of the gamut space vs. than in the center helps but is not essential.

Thin plate splines [TPS] model slices through the data as deformation of a thin sheet of metal. An increasing tension - or bending penalty function - is imposed as points move away from the plane surface. The penalty function is zero if the fitting function is affine, but increases exponentially as deformations occur. The drawback to TPS is huge overshoots in the case of noisy data - these visually appear as discontinuities in what should be relatively smooth output gradients. Thin membrane splines [TMS] impose a roughness penalty function based on the bending energy of a thin membrane. This may be either a quadratic potential function which fits well but loses rotational invariance. This has the effect of increased error at sharp discontinuities in the measured data, but does not over or under-shoot like a TPS fit.

Regularized splines have a tension/penalty function that tunes the weights all orders of in the smooth seminorm. This has the effect of switching the behavior of the fitted spline from thin plate to thin membrane based on the relation between data and reference. I have not dug into the guts of Argyll's implementation to see whether the penalty basis functions behave only on the distance from the plane or are calculated anisotropically; i.e. if the data behave differently depending on direction, does the penalty function apply scaling coefficients and rotation to the data to weight the tension parameter directionally? If a LuLa reader has some hours to spare, perusal of the Argyll code could answer this or perhaps Graeme could chime in.

Turning to i1Profiler, all we can go by is the behavior as there is no source code available. In the pre-GMB/X-Rite merger, MonacoProfiler required regularly-spaced reference data for all RGB profiles. i1Profiler behaves largely as a combination of Monaco's basic profile with ProfileMaker's ability to handle arbitrary data. Looking at the profile data from regularly spaced input points, it certainly appears that i1Profiler's main profile chops use B-splines (or similar) with some form of penalized smoothing. Splines of this type require regularly gridded data - i.e. evenly spaced steps in the reference data. The smoothing parameter controls the relationship between fitted profile and input data roughness. The Euler-Lagrange equation shows that the penalty function of degree 2x - 1. For 2-dimensional data fitting (x = 2), this implies a cubic spline.

As the input data deviate from regular spacing, nonparametric function estimation becomes less accurate. In this case, one can still use B-spline fitting with narrow basis penalty functions around small grids of input. In this case, to avoid intractable computations, the basis functions are usually equally spaced even if the input/reference data are not. Nevertheless errors increase as the input is off a regular grid. In years past we used this approach for the basic profile creation. We calculated a penalty function for the regular grid data from a Fourier expansion of the measurement data. The penalty function was then applied in the frequency domain rather than on the data directly.

Doug: Have you checked whether the default i1Profiler behavior of generating 16-bit reference data but only 8-bit targets affects error rates? Alter the reference values by +/- 0.5 but keep the output at 8-bit resolution. I can't fathom why i1Profiler behaves this way unless it internally rounds 16-bit data to 8-bit. I recall older versions (1.x) of i1P truncated 16-bit values rather than rounding.

A hint for aspiring profile software creators: Our experience is that barycentric rational interpolation with no poles provides excellent fitting for arbitrary input data. This allows targeting areas where printer output is discontinuous without adversely affecting fitting in more stable regions.

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2197
Re: Anomolies in I1Profiler when RGB values are not in a plane
« Reply #2 on: September 26, 2020, 12:02:58 am »

Doug: Have you checked whether the default i1Profiler behavior of generating 16-bit reference data but only 8-bit targets affects error rates? Alter the reference values by +/- 0.5 but keep the output at 8-bit resolution. I can't fathom why i1Profiler behaves this way unless it internally rounds 16-bit data to 8-bit. I recall older versions (1.x) of i1P truncated 16-bit values rather than rounding.

I1Profiler creates fractional RGB using the patch generator. Setting the patch count to 1006 creates a fractional 10x10x10 grid array with 6 extra solid colors at the end. The grid is evenly spaced in deltas of 28 1/3. When the patches are saved as a patch set (pxf), it truncates the fractional part. For instance the second in sequence, 56 2/3 is saved as 56.  However, the tif chart, which is 8 bits, is rounded and thus saved as 57. If the patch file is saved immediately after it's created, then the truncated values will be loaded and the tif chart generated will match. Thus I recommend always saving any created patch chart first then loading it in i1Profiler. It the freshly created patch file is saved as a CGATs rgb it rounds to two decimals, or 56.67. Further, tests indicate that it calculates profiles based on the fractional data which at least is going to be close to the rounded, 8 bit data in the tif. However, I've detected no drop in profile quality using rounded (8 bit) RGB values even though their spacing is no longer perfectly spaced. Another reason to use 8 bits is that when the measurement data is saved in a profile, it rounds RGB values to 8 bits.
« Last Edit: September 26, 2020, 02:42:46 pm by Doug Gray »
Logged

GWGill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 608
  • Author of ArgyllCMS & ArgyllPRO ColorMeter
    • ArgyllCMS
Re: Anomolies in I1Profiler when RGB values are not in a plane
« Reply #3 on: September 26, 2020, 01:18:04 am »

Regularized splines have a tension/penalty function that tunes the weights all orders of in the smooth seminorm. This has the effect of switching the behavior of the fitted spline from thin plate to thin membrane based on the relation between data and reference. I have not dug into the guts of Argyll's implementation to see whether the penalty basis functions behave only on the distance from the plane or are calculated anisotropically; i.e. if the data behave differently depending on direction, does the penalty function apply scaling coefficients and rotation to the data to weight the tension parameter directionally? If a LuLa reader has some hours to spare, perusal of the Argyll code could answer this or perhaps Graeme could chime in.

I'm not sure that "distance from the plane" is really an applicable concept - the error is simply the difference in (linearly interpolated) modelled value from reference value at the particular sample point input value. The regular spline balances this against its measure of smoothness of its regular grid points.

The smoothness (or stiffness) factor is global in the Argyll code. Don Bone's original paper described using a non-linear stiffness, that allowed curvature to increase near discontinuities - I haven't really played with that idea though. An approach I have explored and sketched out (but not pursued to completion) is to introduce local smoothness factors that are automatically determined by cross correlation ("leave one out" approach). The idea is that this would adapt robustly and near optimally to the distribution of sample data.

In the context of regular splines, I found regularly spaces sample points to be a distinct disadvantage, since they leave certain spatial frequencies and their harmonics unconstrained when their zero nodes coincide with the sample point grid. Pseudo randomly spaced sample points don't have this weakness.
« Last Edit: September 26, 2020, 03:36:16 am by GWGill »
Logged
Pages: [1]   Go Up