Marti wrote: >> When transforming larger images, performance really suffers due to the >> transform unpack/pack functions which are called per pixel. > > Thats a sort of tradeoff. Doing it in such way, you lose some performance > but you gain the formatting capabilities. And that is one of the big > strengths > of lcms. Many usual buffer formats are directly supported, and if your > particular scheme is not, you can easely support it by writting a small > function. Anything other that one pixel would mean temporary buffers, > so the memory requeriments would increase.
Agreed - it is nice to have this simple API and it was easy for me to figure out and use. 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. >> Is there a way to hook into the transform process to avoid the per pixel >> unpack/pack functions, and instead operate on an entire "line" of data >> by calling into the transform API from within my own unpack/pack loop? > > Another way would be using _cmsPrecalculateDeviceLink() too but instead > of dumping the colormap to an ASIC, using the cmsEvalLUT function, > which also takes just one pixel. Then the task of converting your > buffers to > 16 bit, which is the internal format of lcms, is up to you. Ah, this is what I am looking for. I can easily handle the temporary 16-bit line memory myself. But how fast is cmsEvalLUT? I'd have to call that THREE times per pixel. > Anyhow, in 1.16, which I will make a preview available in a week, the > measured performance of RGB -> RGB, 16 bits per channel is about > 10 Mpixel/sec on my AMD 4000+, actually faster than ICM2 and > I think reasonable for most usage. That sounds interesting! Nice work on the API BTW. > > Regards > Marti Maria > The littleCMS project > http://www.littlecms.com > > > ----- Original Message ----- From: "Paul Miller" <[EMAIL PROTECTED]> > To: "Lcms Liste" <lcms-user@lists.sourceforge.net> > Sent: Wednesday, August 02, 2006 3:14 PM > Subject: [Lcms-user] lcms transform performance > > >> When transforming larger images, performance really suffers due to the >> transform unpack/pack functions which are called per pixel. >> >> Is there a way to hook into the transform process to avoid the per pixel >> unpack/pack functions, and instead operate on an entire "line" of data >> by calling into the transform API from within my own unpack/pack loop? >> >> -- >> 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 >> >> > > -- 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
