On Sunday 05 February 2006 18:28, Bob Friesenhahn wrote: > On Sun, 5 Feb 2006, Boudewijn Rempt wrote: > > It's been a while, but we're now at a stage with Krita where having to > > loop by hand through all pixels to copy the alpha channel is getting > > rather prohibitively expensive :-(. When the display profile or > > colorspace isn't the same as the image profile we spend about half our > > cycles in cmsDoTransform, and about 30% in the alpha copy loop when > > loading an image and simply displaying it. > > It may be that you are dealing with too much data at once. If you are > currently feeding lcms the entire image, you may obtain better results > with row-by-row processing due to the effect of caching. Primary and > secondary cache accesses are much faster than going all the way to the > primary RAM storage device. If you are processing a large image in > one operation, then the second pass is likely taking a cache hit for > every access. My experience is that second passes can be almost > unnoticeable in overall run-times if the data is already cached.
We do feed lcms our images a chunk at a time -- for a 5000 * 1200 image about 70.000 chunks, or so callgrind tells me. But we need to convert the entire image, of course. We do that before scaling down to display size, maybe that's the problem. I'm not sure whether first scaling and then correcting would still give useful results. -- Boudewijn Rempt http://www.valdyas.org/fading/index.cgi
pgpcnng4d0yyC.pgp
Description: PGP signature
