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. ]
