Bob Friesenhahn wrote: > On Fri, 4 Aug 2006, Paul Miller wrote: >> >> Unfortunately, we loading a 5K x 4K JPEG image (RGB8 -> RGBA8), it takes >> 3 times longer to use the profile transform than not. Since it sounds >> like the transform resolves to a simple 16 bit lookup after the unpack, >> MOST of this time is tied up in the pack/unpack. > > I would not make any such assumption without proof. The pack/unpack is > done using the most efficient mode of the CPU with most > instructions/data resident in the cache and linear data access. It can > be quite fast. The "simple 16 bit lookup" may in fact be a > cache-busting random access and be much slower.
Yes, I dug further into the transform (and the CalcLUT code that Marti mentioned) and it seems that that is probably the bottleneck afterall, with potentially 3D lookups and matrix operations. Yuck. I guess it all depends on the profile as well. I was expecting (for some odd reason) a simple 2D table lookup per channel, but that isn't the case. I "solved" the problem by setting the default interpretation of profiles to "use the embedded one", which equates to a no-op in my software. -- Paul Miller | [EMAIL PROTECTED] | www.fxtech.com | Got Tivo? ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
