Hi. I�ve 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 can�t 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 100�s of application specific
profiles are getting dumped into the system profile directory.
That is pretty much it really. So long as items�s 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
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Lcms-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/lcms-user
