Re: [Lcms-user] Question related to curve smoothing
An ICC-based CMM for color management
Brought to you by:
mm2
From: Pekka P. <pek...@ha...> - 2025-05-12 12:12:05
|
On Fri, 9 May 2025 09:51:47 +0200 <mar...@li...> wrote: > Regarding your question, a good test would be to chain two ICC profiles for > real devices. Take LUT-based ones, which you can identify easily by looking > at file size, big sizes mean they are using CLUT and are complex. Take a > profile for a real camera and a profile for a real monitor and try the > algorithm to model the color transform with those. If you try sRGB + > AdobeRGB, you are just chaining two matrixes and you can't see the real > power, although the algorithm works equally well. Hi Marti, so any combination of real camera and display CLUT profiles should be able to hit most of the pitfalls? That sounds good! Now we just need to find profiles we can store in the Weston project, so we can use them in the automated test suite. > Here is a description on how to implement it: > > a) Use LittleCMS to create a color transform from source RGB to destination > RGB. Use cmsFLAGS_NOOPTIMIZE to get maximum accuracy. With this you have a > way to evaluate RGB->R'G'B' > b) Compute the neutral curves. For example, on 256 values, for (i=0; i < > 256; i++) R[i]=G[i]=B[i] = i; and then using a) obtain the R'G'B' of those > 256 values. It is certainly possible that R' != G' != B' if you use real > devices. > c) Smooth a little bit those curves, make sure those are monotonic. You can > use any algorithm you wish. The important thing is to get rid of abrupt > changes and make them monotonic to allow the inverting. > d) Invert the curves. LittleCMS gives you a function to do that. You can use > any other algorithm you wish. > c) Build the LUT for GPU by sampling all RGB cube. You want to obtain the > R'G'B' for all RGB to model the color transformation in just one 3D table. > You could do this directly and it would work more or less, but what the > paper says is that if you use those inverted curves to linearize the RGB > values first, the cube interpolation is much more efficient and you could > get more accurate results with less nodes. > > Hope that makes sense to you It does, thanks! pq |