Hi,
> 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. > 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? There are several levels, on depending of your needs. If you *really* need big performance, maybe because you are creating some sort of device like a printer, a digital cinema processor or something like that, then software based transforms are not enough and you need an ASIC. Littlecms supports that by _cmsPrecalculateDeviceLink(). I have used this way and it works. 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. 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. 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 > > ------------------------------------------------------------------------- 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
