From: Auke N. <au...@na...> - 2004-05-25 19:58:21
|
Hi everyone, Like Gerhard I checked the speed of lcms 1.12 and 1.13 conversions (16bit sRGB to printer output profile): lcms 1.12 7.0 M pix/sec lcms 1.13 9.0 M pix/sec The computer used is equipped with an AMD XP 2800+ processor (2.1GHz Barton). I realize these numbers are much higher than the numbers quoted earlier by Gerhard (1.2 and 2.8 Mpix/sec). I do not know the reason(s). I did compile my 'own' lib using Borland cbuilder, version 6, optimized for Pentium Pro processor. Does anyone have a clue? Greetings, Auke Nauta ---------------- BTW, nice speed increase, Marti! |
From: Gerhard F. <nos...@gm...> - 2004-05-25 23:39:39
|
Auke Nauta schrieb: > Hi everyone, > > Like Gerhard I checked the speed of lcms 1.12 and 1.13 conversions > (16bit sRGB to printer output profile): > > lcms 1.12 7.0 M pix/sec > > lcms 1.13 9.0 M pix/sec > > The computer used is equipped with an AMD XP 2800+ processor (2.1GHz > Barton). > > I realize these numbers are much higher than the numbers quoted > earlier by Gerhard (1.2 and 2.8 Mpix/sec). > > I do not know the reason(s)… > > I did compile my ‘own’ lib using Borland cbuilder, version 6, > optimized for Pentium Pro processor. > > Does anyone have a clue? > Hi, I compiled on Linux with gcc 3.2, using "make CFLAGS=-O6". I also wouldn't expect that your processor is more than 10% faster than mine, and I'm curious what's the cause of such a *BIG* difference. How did you measure? Can you attach your test program? Regards, Gerhard |
From: John C. <joh...@ng...> - 2004-05-26 09:23:36
|
Auke Nauta wrote: > Like Gerhard I checked the speed of lcms 1.12 and 1.13 conversions=20 > (16bit sRGB to printer output profile): >=20 > lcms 1.12 7.0 M pix/sec > lcms 1.13 9.0 M pix/sec > =20 > The computer used is equipped with an AMD XP 2800+ processor (2.1GHz=20 > Barton). >=20 > I did compile my =91own=92 lib using Borland cbuilder, version 6, optim= ized=20 > for Pentium Pro processor. Another data point: on a 2.5 GHz P4 Xeon I get 1.2 and 2.2 Mpix/sec for l= cms 1.12 and 1.13. My benchmark was=20 time tifficc -w -oprofile.icc test.tif fred.tif where profile is an HP inkjet printer profile and test.tif is a 65 Mpix 1= 6 bit sRGB image. Built with gcc 2.95.3, -O2. Maybe the difference is float handling? My ancient gcc is too dumb to gen= erate SSE2 so I guess it's using the very clunky x87 float instructions. = Again, congratulations on the impressive speed up Marti. John |
From: Marti M. <ma...@li...> - 2004-05-26 08:29:34
|
Hi, > Does anyone have a clue? Perhaps you are using Mb/sec? 9.0 Mbytes/sec ---------------- = 2.25 Mpixel/sec. 4 bytes/pixel On my Compaq EvoN610c (a 2GHz portable) numbers are quite similar... Regards, Marti. ----- Original Message ----- From: Auke Nauta To: lcm...@li... Sent: Tuesday, May 25, 2004 9:58 PM Subject: [Lcms-user] lcms 1.13 speed Hi everyone, Like Gerhard I checked the speed of lcms 1.12 and 1.13 conversions (16bit sRGB to printer output profile): lcms 1.12 7.0 M pix/sec lcms 1.13 9.0 M pix/sec The computer used is equipped with an AMD XP 2800+ processor (2.1GHz Barton). I realize these numbers are much higher than the numbers quoted earlier by Gerhard (1.2 and 2.8 Mpix/sec). I do not know the reason(s). I did compile my 'own' lib using Borland cbuilder, version 6, optimized for Pentium Pro processor. Does anyone have a clue? Greetings, Auke Nauta ---------------- BTW, nice speed increase, Marti! |
From: Auke N. <au...@na...> - 2004-05-26 08:41:14
|
> > Hi, > >> Does anyone have a clue? > > Perhaps you are using Mb/sec? > > 9.0 Mbytes/sec > ---------------- = 2.25 Mpixel/sec. > 4 bytes/pixel > Oh yes, Sorry Marti and Gerhard! Forgot to engage my brain. You are right. I used megabytes / sec. BTW, should this not be 9.0 / 3 bytes/pixel = 3.0 Mpixel/sec ? Once again, sorry for the confusion, Auke |
From: Marti M. <ma...@li...> - 2004-05-26 08:48:13
|
>BTW, should this not be 9.0 / 3 bytes/pixel = 3.0 Mpixel/sec ? Yes, if you are using RGB. Sorry, my brain works mostly in CMYK, so I assumed 4 components :-) Regards, Marti. ----- Original Message ----- From: "Auke Nauta" <au...@na...> To: "Marti Maria" <ma...@li...> Cc: <lcm...@li...> Sent: Wednesday, May 26, 2004 10:41 AM Subject: Re: [Lcms-user] lcms 1.13 speed > > Hi, > >> Does anyone have a clue? > > Perhaps you are using Mb/sec? > > 9.0 Mbytes/sec > ---------------- = 2.25 Mpixel/sec. > 4 bytes/pixel > Oh yes, Sorry Marti and Gerhard! Forgot to engage my brain. You are right. I used megabytes / sec. BTW, should this not be 9.0 / 3 bytes/pixel = 3.0 Mpixel/sec ? Once again, sorry for the confusion, Auke |
From: Stuart N. <Stuart@NixonWeb.com> - 2004-05-26 12:10:00
|
Hi. Ive been watching the Linux CMS and LCMS performance emails with interest. To my mind, CMS performance is not the issue we need to address in order to get standard and widespread use of ICC profiles and CMS systems under Linux. LCMS performance ---------------- CMS performance is not an issue. With minor tuning (3x loop unrolling for the common RGB case and optimised Double to Int conversion) for 16 bit data under VC++ 6 under Windows, on an average (e.g. AMD 2000+ or Intel 2Ghz) machine, LCMS 1.12 achieves throughput as follows: Full CMS conversion, for RGB input 16 bit per channel (48 bit total) to RGB (or Lab) 16 bit-per-channel output (48 bits total): 180 ns/pixel conversion time e.g. 5.5 M pixels/second or 33 M bytes/second This is for production code (e.g. in a real application) and using C code (not ASM) in the LCMS library. I believe Marti is putting the minor tweaks noted above into a future version. ICC/CMS under Linux ------------------- To get widespread usage of ICCs and CMS engines under Linux, we need a couple of things: 1. A standard system profile directory. I believe a directory has already been proposed although I cant find the original email. 2. A set of standard ICC profiles that are always present, for Default situations. These should include: - Standard 2.2 gamma monitor - Standard 1.8 gamma monitor - sRGB - Adobe RGB These need to be copyright free and clean ICC profiles, so that applications can at least run generic CMS on a machine using generic monitor profiles. Note that many monitor manufacturers now provide a monitor profile (particularly for LCD displays) that is at least going to be better than an uncalibrated device. 3. There should be a way to get the current monitor profile for each display, so that applications can ask the system for this profile and use it, rather than having to ask the user for the profile name. It should handle multiple displays (e.g. allow multiple profiles, one for each monitor). Ditto for printers. Harder, because printer profiles depend on paper used. 4. Developers should be encouraged to keep their own application specific profiles in their own application private directories. This is to stop the problem that is starting to happen under Windows - particularly with digital SLR apps - where 100s of application specific profiles are getting dumped into the system profile directory. That is pretty much it really. So long as itemss 1 to 3 are done, then any self respecting application can implement the full CMS process under Linux in a user friendly way. Even now, full CMS is doable under Linux; you just have to ask the user a couple of questions at the start. In my view, the monitor profile output, which is the final stage for onscreen display (even with soft proofing) is something the application needs to be aware of as part of its CMS processing. It should not be at the OS or X server level. Note that things like Adobe Gamma are simply simple attempts to get the monitor roughly in spec without a true profile. So long as an application knows what the monitor profile is, then correct CMS profiling is quite straight forward. Cheers Stuart |
From: Bob F. <bfr...@si...> - 2004-05-26 15:25:54
|
On Wed, 26 May 2004, Stuart Nixon wrote: > Hi. I=92ve been watching the Linux CMS and LCMS performance emails with i= nterest. > > To my mind, CMS performance is not the issue we need to address > in order to get standard and widespread use of ICC profiles and > CMS systems under Linux. Agreed. > ICC/CMS under Linux > ------------------- > > To get widespread usage of ICCs and CMS engines under Linux, we > need a couple of things: > > 1.=09A standard =93system=94 profile directory. I believe > =09a directory has already been proposed although I can=92t find the > =09original email. While it may be possible to establish a "standard" directory for=20 Linux, the solution should be OS-agnostic. That means that the=20 "standard" shared directory should be relative to the software=20 installation prefix. When installing on a proprietary OS, the base=20 installation prefix is likely not '/'. The standard default for open=20 source apps is to install under '/usr/local' in order to avoid=20 accidentally corrupting the OS. A path like=20 "${prefix}/share/cms/profiles" would be ideal. The reason why I suggest that an XML configuration file be used=20 (similar to the way fonts are handled under Red Hat) is this allows=20 multiple applications to be configured via one common file. > 3.=09There should be a way to get the current monitor profile for > =09each display, so that applications can ask the system for this > =09profile and use it, rather than having to ask the user > =09for the profile name. It should handle multiple displays Yes. This configuration should be supported both at the=20 system/network level and at the user level so that the user may=20 override or extend the defaults. > 4.=09Developers should be encouraged to keep their own > =09application specific profiles in their own application > =09private directories. This is to stop the problem that > =09is starting to happen under Windows - particularly with > =09digital SLR apps - where 100=92s of application specific > =09profiles are getting dumped into the system profile directory. Windows was not really designed for sharing files and applications via=20 networking. It promotes the "PC" mentality. Unix/Linux can naturally=20 be be better. Bob =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Bob Friesenhahn bfr...@si... http://www.simplesystems.org/users/bfriesen |
From: Kai-Uwe B. <ku...@gm...> - 2004-05-26 20:46:16
|
Am 26.05.04, 20:07 +0800 schrieb Stuart Nixon: > ICC/CMS under Linux > ------------------- > > To get widespread usage of ICCs and CMS engines under Linux, we > need a couple of things: > > 1.=09A standard =93system=94 profile directory. I believe > =09a directory has already been proposed although I can=92t find the > =09original email. /usr/share/color/icc and ~/.color/icc is the current state used by CinePaint. Others are application specific. > 4.=09Developers should be encouraged to keep their own > =09application specific profiles in their own application > =09private directories. This is to stop the problem that > =09is starting to happen under Windows - particularly with > =09digital SLR apps - where 100=92s of application specific > =09profiles are getting dumped into the system profile directory. What kind of application specific profiles is to been rolling over linux? I like to ask for an example. Thanks > That is pretty much it really. So long as items=92s 1 to 3 are done, > then any self respecting application can implement the full CMS > process under Linux in a user friendly way. Even now, full CMS > is doable under Linux; you just have to ask the user a couple of > questions at the start. last is proofed > In my view, the monitor profile output, which is the final stage > for onscreen display (even with soft proofing) is something > the application needs to be aware of as part of its CMS processing. An application should go the easy way and not care about, what is the display doing and asking for further complications. It is simple and sufficient to know about the workspace (Lab or sRGB, even CMYK as workspace should remain used by experts only). Tuning of monitors and printers is an very different thing. Or does it make creative to think about the printer gamma while painting an flower? > It should not be at the OS or X server level. To reach an consitent feel over the desktop it would be nice to handle the monitor as an whole device, not simple from the view of an application window. Of course handling video, openGL, new data formats like nvidias half and X-rendering consitently seems not an simple reachable goal. Ka-Uwe |