[argyllcms] Re: Question regarding gamut mapping for photographic images
- From: "Greg Sullivan" <greg.sullivan@xxxxxxxxxxxx>
- To: <argyllcms@xxxxxxxxxxxxx>
- Date: Wed, 31 Aug 2005 18:50:31 +1000
Thanks Graeme and Alastair - much appreciated! :)
(Graeme - I take it you'll make an announcement to the list when the fix is
available on your web site?)
Greg.
-----Original Message-----
From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of Graeme Gill
Sent: Wednesday, 31 August 2005 15:31
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Question regarding gamut mapping for photographic
images
Alastair M. Robinson wrote:
> The B2A generation gets to 37% then stalls. After what I'm guessing is
> 5-10 minutes, it finally moves on to 38% and zips through the rest.
>
> What's interesting is that if you remove the last sample (and reduce the
> sample count to match), then run the profile command again, it zips
> straight through.
>
> The difference between the two profiles once they're generated is minimal.
OK - thanks for the example, it showed up a problem in the code. Due to
a fairly complex combination of things, some very slow reverse lookups
were taking place in the per channel 1D curves. Changing the algorithm
used slightly (hopefully without affecting the results), drops the
execution time significantly.
For the example give, from 5 min 17, to 55 seconds.
For Greg Sullivans example, the execution time for
no perceptual & saturation tables is:
2 min 17 seconds.
while with these tables it is:
2 min 54 seconds (down from 40-50 minutes).
For high res. with perceptual and saturation tables,
the execution time is:
17 min 24 seconds.
I would imagine these performance problems showed up
when I switched from CIECAM97 to CIECAM02, late last year.
Graeme Gill.
[ For those interested in the gory details:
CIECAM02 has some really nasty properties when it comes to actually
applying it to the real world for gamut mapping. Within the physically
realizable colors of a real device it works fine, but in the process of
gamut mapping one has to deal with colors out of a real devices gamut.
CIECAM02 has the habit of "blowing up" quite easily under these
circumstances, producing nonsensical results (divide by zero's,
infinities,
hues swaps etc.)
Although I've attempted to overcome these problems, it still produces
some ridiculously large values at times. These large values were being
fed into the inverse per channel curve lookup, and the default clipping
algorithm used for out of range values (vector clip) was taking a very
long time to produce a result (it tracks the vector cell by cell into
valid range). Switching to the "nearest" clip algorithm for these
lookups speeds up the handling of ridiculously large values.
]
Other related posts:
