diff options
Diffstat (limited to 'doc/Source.html')
| -rw-r--r-- | doc/Source.html | 219 |
1 files changed, 219 insertions, 0 deletions
diff --git a/doc/Source.html b/doc/Source.html new file mode 100644 index 0000000..5ea423e --- /dev/null +++ b/doc/Source.html @@ -0,0 +1,219 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> +<html> +<head> + <title>Argyll Overview</title> + <meta http-equiv="content-type" + content="text/html; charset=ISO-8859-1"> +</head> +<body> +<h2><u>Source Code Documentation</u></h2> +Some general comments about how different software works.<br> +<br> +<b>TARGET</b><br> +<br> + Nearly all current Color correction systems generate test charts +(or device characterization target charts) by laying out a regular +rectangular grid of test points in device space (Targen will do this if +you feed it a non-zero <span style="font-weight: bold;">-m</span> +option). On some consideration, this approach is far from optimal. Not +only is a regular grid inefficient in packing the multidimensional +device space but if the points are spaced evenly in device space, they +will probably not be optimal in determining the underlying device +characteristic, sampling too finely where the device behavior is +smooth, and too coarsely where the device behavior changes rapidly. +Some commercial color systems tackle +the latter problem by "pre-linearizing" the device, which amounts to +distorting +the regular device space grid points with a perceptual inverse per +device +channel lookup curve.<br> +<br> +The approach I have taken with Argyll, is a little different. Both a +device independent and device dependent approach are available. In the +device independent mode, test points are distributed so as to minimize +the distance from any point in the device space to the nearest test +chart value. When the device dependent approach is used, test points +are chosen so as to minimize the expected error between the resulting +profile and the underlying device response.<br> +<br> +For higher dimensional spaces, where the aim is to create a more +approximate device profile, I've used an "incremental far point" point +generator, that starting with a previous test point as a seed, use a +minimization algorithm to locate another point that is as far as +possible from the nearest existing test point in perceptual space, +while remaining in gamut at all tines. This means that ideally each +point "fills in" the gaps in the existing distribution.<br> +<br> +Another issue with laying test points out in regular grids, is that +this means that the device response is poorly sampled (since the grids +are usually coarse), and this can make it impossible to create detailed +device linearisation "shaper" curves from the resulting data ! Ideally, +in any colorspace (input or output), when viewed from any possible +angle, none of the test data points should appear to line up. The +Argyll target generator seems to achieve this goal.<br> +<br> +<br> +target/printtarg.c:<br> +<br> +printtarg simply generates a PostScript file containing the patches +laid out for an Xrite DTP51/DTP41/SpectroScan. It allows them to be +laid out on +a choice of paper sizes, with the appropriate contrasting color spacers +between +each patch for the strip reading instruments. Unlike other charts, +Argyll +charts are generated as required, rather that being fixed. Also unlike +most +other strip reading charts, the spacers may colored, so that the +density contrast +ratio is guaranteed, even when two patches are about 50% density.<br> +<br> +Another feature is the pseudo random patch layout. This has three +purposes. One is to try and average out any variation in the device +response in relationship to the location of the patch on the paper. +Color copiers and printing presses (for instance), are notorious in +having side to side density variations.<br> +<br> +Another purpose of the random patch layout, is that it gives the +reading program a good mechanism for detecting user error. It can guess +the expected values, compare them to the readings, and complain if it +seems that the strip is probably the wrong one.<br> +<br> +The final purpose of the random patch layout is to optimize the +contrast +between patches in a strip, to improve the robustness of the strip +reading. +Using this, small charts may be even be generated without any gaps +between +the test patches.<br> +<b><br> +RSPL</b><br> +<br> +A lot of core Argyll algorithms are bound up in the RSPL (Regular +Spline) class. The RSPL class is closely related to the CLUT table +structure used in the ICC profile format, and is a general purpose way +of mapping one multi-dimensional value to another, using interpolation +to reduce the mapping function to a manageable size.<br> +Regular splines are not directly related to other types of splines, and +do not generally suffer from the sort of "wiggles" and "overshoot" +characteristic of other spline systems.<br> +<br> +The RSPL class adds three basic methods to the underlying data +structure:<br> +<br> +1) Interpolation<br> +<br> +2) Creation from scattered data<br> +<br> +The regular spline implementation was inspired by the following +technical reports:<br> +<br> +D.J. Bone, "Adaptive Multi-Dimensional Interpolation Using Regularized +Linear Splines," Proc. SPIE Vol. 1902, p.243-253, Nonlinear Image +Processing IV, Edward R. Dougherty; Jaakko T. Astola; Harold G. +Longbotham;(Eds)(1993).<br> +<br> +D.J. Bone, "Adaptive Colour Printer Modeling using regularized linear +splines," Proc. SPIE Vol. 1909, p. 104-115, Device-Independent Color +Imaging and Imaging Systems Integration, Ricardo J. Motta; Hapet A. +Berberian; Eds.(1993)<br> +<br> +Don Bone and Duncan Stevenson, "Modelling of Colour Hard Copy Devices +Using Regularised Linear Splines," Proceedings of the APRS workshop on +Colour Imaging and Applications, Canberra (1994)<br> +<br> +see <http://www.cmis.csiro.au/Don.Bone/><br> +<br> +Also of interest was:<br> +<br> +"Discrete Smooth Interpolation", Jean-Laurent Mallet, ACM Transactions +on Graphics, Volume 8, Number 2, April 1989, Pages 121-144.<br> +<br> +3) Inversion<br> +<br> +Simplex interpolation is normally done in Baricentric space, where +there +is one more baricentric coordinate than dimensions, and the sum of all +the +baricentric coordinates must be 1.<br> +To simplify things, we work in a "Simplex parameter" space, in which +there are only <dimension> parameters, and each directly +corresponds with a cartesian coordinate, but the parameter order +corresponds with the baricentric order.<br> +For example, given cartesian coordinates D0, D1, D2 these should be +sorted from smallest to largest, thereby choosing a particular simplex +within a cube, +and allowing a correspondence to the parameter coordinates, ie:<br> +<br> +D1 D0 D2 Smallest -> Largest cartesian sort<br> +P2 P1 P0 Corresponding Parameter coordinates +(note reverse order!)<br> +<br> +B0 = P0 Conversion to Baricentric +coordinates<br> +B1 = P1 - P0<br> +B2 = P2 - P1<br> +B3 = 1 - P2<br> +<br> +The vertex values directly correspond to Baricentric coordinates,<br> +giving the usual interpolation equation of:<br> +<br> + VV0 * B0<br> ++ VV1 * B1<br> ++ VV2 * B2<br> ++ VV3 * B3<br> +<br> +where VVn is the vertex value for each of the 4 vertices of the simplex.<br> +<br> +Reversing the Parameter -> Baricentric equations gives the<br> +following interpolation equation using Parameter coordinates:<br> +<br> + VV0 - VV1 * P0<br> ++ VV1 - VV2 * P1<br> ++ VV2 - VV3 * P2<br> ++ VV3<br> +<br> +It is this which is used in rev.c for solving the reverse interpolation +problem. Within a simplex, only linear algebra is needed to compute +inverses. To deal with the 4D->3D nature of a CMYK profile, the SVD +(Singular Value Decomposition) approach is used to solving a CMYK for a +given CIE value, the result being the equation of the line of +solutions. The lines from adjacent simplexes form a solution locus, +that can be resolved into a single point solution once a black +generation rule is applied.<br> +<br> +Outline of inversion processing:<br> +<br> + Basic function requirements: exact, +auxil, locus, clip inversion.<br> + Fwd cell - reverse cell list lookup<br> + Basic layout di -> fdi + auxils + ink limit<br> + Basic search strategy<br> + Sub Simplex decomposition & properties<br> + How each type of function finds solutions<br> + Sub-simplex dimensionality & +dof + target dim & dof<br> + Linear algebra choices.<br> + How final solutions are chosen<br> +<b><br> +XICC</b><br> +<br> + Profiling using concatenated shapers to augment thin +plate splines for per channel curves.<br> +<br> +<b>IMDI</b><br> +<br> +This module generates C code routines which implement an integer +multi-channel transform. The input values are read, passed through per +channel lookup tables, a multi-dimensional interpolation table, and +then a per channel output lookup table, before being written.<br> +<br> +<b> MPP<br> +</b> <br> +Outline model parameter optimization using slope accelerated error +metric, and initial parameter speedup for adjacent spectral bands etc.<br> +<br> +<br> +<br> +</body> +</html> |