Hi :) Justus Jonas wrote:
> Could you explain it more detaily? I'm very interested. Well, the maths involved in creating viable LUTs from scattered data points is pretty complicated - the details are over my head - but the general principle is that you can't use your data points "raw" - because they will almost certainly not fall on the grid points you need in the profile's LUTs. Instead, you need to use an interpolation method - as Gerhard put it in his post, fit a model of the device behaviour to your data points. From that model you can obtain values for the grid points of your profile's LUTs. Building that model is the hard part. > geometric interpolations like > splines, tetrahedrons, statistical regressions models. Those are probably the relevant bits. > As far as I understand the 'real professional' icc > printer profiles with the big cluts includes just more points than the > measured points that are interpolated/estimated from the measured points. They don't just use *more* points, they use a 3D table of regularly spaced points - it's cubic (for RGB profiles) and the printer profiles I use generally have 17 x 17 x 17 (i.e. 4913) entries for each LUT, even though the profile's built from either 400 or 800 measured patches. > So want to try the following: > normally a printer RGB clut has the 1D-3D-1D structure. I just let the > values two 1D-tables directly pass through (1:1) without any distortion > and just write the measured 288 points to the 3D table. So is this a > feasible profile? I'm afraid not - because (a) your 288 data points won't be arranged in an evenly spaced cubic grid, and (b) you need at least one inverse table, too - more than one if you want your profile to support Perceptual and Saturation rendering intents. This means that not only do you have to be able to interpolate from your data points, you need to be able to do it in both directions. As I understand it, you need a table of PCS values corresponding to an evenly spaced grid of RGB values for the AtoB table, and several tables of RGB values corresponding to an evenly spaced grid of PCS values for the BtoA tables. In the latter case you also have to deal with the fact that *many* (in fact most!) of the colours in the PCS can't be printed. They must, nonetheless, have an RGB value associated with them - so you have to decide how to map these non-printable colours to printable colours. That's where the different intents come in. Hope this is some help - there are plenty of people here more knowledgable than me who I'm sure will correct any mistakes in what I've written there... All the best, -- Alastair M. Robinson ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
