[argyllcms] Re: xicclu -g predictability issue
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Thu, 27 Jan 2011 14:54:17 +1100
Elena [service address] wrote:
mmm... then something strange is happening here ?!
Yesterday I computed a device link profile with -G -qh (maybe redundant) -r100
(the
maximum allowed, -r101 start being refused) in a time that I didn't measure but
which
is infinitely faster than just generating the original -qh (33) profile !
Miracles ? Or just I going mad ? :-D
collink is a bit simpler than colprof. It only creates one grid rather
than 3, and only has to cover the real device gamut, rather than the
L*a*b* cube. The other factor to take into account is the inversion
caching. The effectiveness of the caching depends on the ratio of
sampling density of output table to input. So the smaller the resolution
of the A2B of the output profile, and the higher the resolution of
the device link, the more effective the cache gets. The more memory
you have, the bigger the cache and the more effective it gets. So
the scaling may not be linear, and will depend a lot on the quality
flag you set when creating the profile, the machine you are using, etc.
Here's some benchmarks for a different profile using collink:
res. Time
17 5 mins
33 25 mins
100 25 Hours (estimated)
255 > 1 Year (estimated. It hadn't reached 0.01% after an hour)
diminishes. All right. So with a -r256 [currently refused by collink] I should
definitely see no artifacts at all!
Possibly. It would be interesting to identify three points: two either
side of a discontinuity, and one right inside it, and then explore them
using xicc -fif. Is the CMYK value returned in fact the only one possible
that matches the Lab value and has the closest K to the targetr, or is some
other combination with a more compatible K being ignored ? (The situation has
arisen in the past where the possible K levels become bifurcated, but the
inversion algorithm has not picked the one with K closes to the target level,
due to numerical errors.)
but as trade off I would be happy enough. Since you told you don't think the
standard imposes limits for the LUT resolution, and since [to be understood yet]
I could generate in few minutes a device link with 100^3 points, why don't
allow -r upto 256 ? Nice, huh ? :-)
Memory consumption may still be an issue.
The limit is actually 255. I can change this for collink easily enough.
Graeme Gill.
Other related posts:
