lcms-user — For users of the little cms library

[Lcms-user] Re: Thanks!, and a question <g>

[<ma...@li...>]

Hi Jack,

I'm forwarding this to the mailing list, seems a very interesting
subject and I would love! to know other opinions about this stuff.

> I have some experience working with other color engines, as well.  And I
> have a general impression that virtually all cms engines think in terms of
> transforms based on a single point, rather than a neighborhood.  But, I
> admit I haven't taken the time to digest the ICC spec.  Quick glances at it
> have given me the impression that it actually does define (the capability
> of) transforms based on area (as well as single point).

To my understanding, most major commercial CMM engines does use
the one pixel approach. I'm unsure about KCMS, but at least
Adobe ACE and ColorSync does operate in such way.

Why this? It seems that a color engine could be "smart" enough to
take advantage of neighborhood to better overall image appearance.
And certainly, this would be possible, despite terribly complex, but in
the way ICC profiles does work, this is ... well, hard to do, to say best.

The profile does not contain measurement of devices, but also all tonal
corrections, tweaks and gamut mapping to accomplish intents.

So, all "smartness" is embedded into profiles, and not in the CMM.
In this way, perceptual intents are done by simply passing the Lab or
XYZ obtained by input profile to output one. Of course, a savvy CMM
could "undo" all these corrections and then operate on raw colorimetric
data, then it theoretically could do, for example, image-dependent gamut
remapping,  and this would be a nice feature for definitively better
perceptual intents.

Pity, there is anything in the profile that give any clues on what to
undo... these corrections are a sort of "secret sauce" applied
by each profile vendor. ICC has released a new spec 4.0, that
intends to address some of these problems, but currently there
are not any 4.0 compliant profiles, nor any CMM that does
support them.  Right now, any output profile does map the near
infinite gamut of  PCS to the finite one of device. And of course
this way ahead from optimal.

In the other hand, embedding all corrections into profile does give
several benefits: Any CMM will use the technology embedded
into profile, so, a gamut remapping implemented today, can
run in a old PhotoShop 5.5 or ColorSync, and this is good.

Also, this is the fastest way to do the translation. A image dependent
process could take hours, even in a today machine.  Probably to only
give a slightly better result, so, overall, the one pixel approach is still
valid and desirable.

> I'm working on an app that need performance as well as image conversion to a
> color space from a unique input profile.  I'm tempted to build a massive 3D
> LUT.  So, I wanted to get your impression of the viability of making the
> transforms so static.

Oh, well, this is a device link profile, so, if you are planing to use same transform
between same profiles over and over, you could build the device link and then
reuse it. This will speed the transform creation time, but not the transform itself.
lams, as most CMM, does compute a device link profile when creating transform.

> Or, if necessary, do you have any suggestions on how to inspect the input
> profile to insure it is strictly single point?

All profiles does convert only one point at time, as said.


Best regards,
Martí Maria
The little cms project
http://www.littlecms.com
ma...@li...

[Lcms-user] Re: to write profiles ICC

[<ma...@li...>]

Hi,

>Today I seek an algorithm in Delphi which makes it possible to
>write profiles ICC when one determined the trichromatic components
>of the primary educations of the monitor and the gammas which are
>dependent for them. Can you advise me again?

Is easy using lcms. You need three things:

- White point
- Primaries
- Gamma curves

Once you have all these, then you can build a "virtual" profile. In the
tutorial (part V)  this is explained in detail, so I will assume you know
how to do. The function is cmsCreateRGBProfile()

Then, you can save the generated virtual profile by calling:

    _cmsSaveProfile(hProfile, 'name.icm')

Please note the leading underscore. You can also add information about
name, copyright, etc. by using  _cmsAddTextTag before saving.

Examples:

_cmsAddTextTag(hProfile, $63707274, 'copyright (c) you')
_cmsAddTextTag(hProfile, $646D6E64, 'Manufacturer')
_cmsAddTextTag(hProfile, $646D6464, 'Model')

These weird numbers are tag identifiers. To know wich numbers
are tied to each tag, you can browse the ICC spec (http://www.color.org)
or take a look into ICC34.H

Usually, these 3 above are the only ones needed.

Hope this helps,
Martí Maria
The little cms project
http://www.littlecms.com
ma...@li...


----- Original Message -----
From: Color ID
To: Martí Maria
Sent: Monday, April 01, 2002 6:08 PM
Subject: to write profiles ICC


Hello,
At the beginning of February of this year me usefully advised you to use in Delphi the library " Lcmsdll ". I could develop an
application which reads and uses profile ICC of the monitors.
Today I seek an algorithm in Delphi which makes it possible to write profiles ICC when one determined the trichromatic components
of the primary educations of the monitor and the gammas which are dependent for them. Can you advise me again?
cordially,
Jean-Pierre Guillemin
e-mail jp...@co...

[Lcms-user] About LCMS utilities

[<ma...@li...>]

Hi,

I'm forwarding this to the mailing list. Hope it would not be a problem to you.

>what do I do, or where do I put the "precompiled binaries"?

Well, these binaries are mostly examples on how to use the lcms library,
however, they have its own use.

Several are console based. You can place these everywere you like, since
they don't depend on any DLL but the Win32 system ones. Console-based
is handfull for both, cross-platform and batch mode. Batch mode is a very
desirable feature for tifficc, for example, since conversion of several
(or hundreds) of  TIFF files can be done at time. They are also are
representative of the footprint lcms has in real applications.

tifficc: Maybe the most usefull one. It can apply profile pairs to
TIFF files. This means this small program can color correct, make CMYK
separations, read CIELab files converting to RGB... etc.

icctrans: This is a sort of "colorspace calculator". While tifficc does convert
between images, this one converts between numbers. Is very usefull to check
values across profile transforms, i.e, give Lab to sRGB calculator, for example.

These are the nutshell. There are other, more arcane utilities, like the white
point inferer, matrix-shaper profiler or it8 measurement generator. They solve
specific problems.

The profilers are GUI based (on Trolltech's Qt) and needs to be installed on
its own directory. Just unzip the distribution in any newly created folder.
The profilers are programs generate specific ICC profiles for your devices.
Specific  profiles are most times better that any generic profiles that comes
with scanner or monitor. Just because they are intended for your device
instead of the manufacturer standard. Many times this is the only way to
obtain relatively accurate results.

Regards,
Martí Maria
The little cms project
http://www.littlecms.com
ma...@li...

Re: [Lcms-user] conversion sRGB to L*a*b* fatal error

[<ma...@li...>]

Hi,

>good news for you.
>conversion with icctrans works quite well - in both directions.
>  now i know how to deal with it :-) values are the same as in
>  photoshop - except for rounding differences.
>
>i must admit - hmmh - i made a beginners mistake...
>when choosing color values with photoshop 'color picker' i was in
>  L*a*b* color space - and so was very often out of RGB gamut...
>  got a hot flush when i realised this.
> sorry Mart=ED for this false alarm, my only excuse is that i _am_ a
>  newbie to color models and color handling.

Don't apologize :-) You have done a great job checking the engine=20
and then reporting what seemed a bug to the list. This is the way we=20
uncovered bugs, so this is really a contribution, and it is welcome.

>in that situation i threw my eyes upon the L*a*b* color model which
>  hopefully gives me what i want - at least it has one value to adjust
>  'lightness'.

Yep. Lab is very adequate for doing image manipulation. In first place,
is near perceptually uniform. This is good for most operations. Then, it
has Luma separated from chroma, again a nice feature.=20

Here are some "tricks" on Lab:

 - Addition works far better than in RGB. Adding two Lab values does =
give the resulting Lab color.
 - To modify "brigtness" just add o substract a constant to L
 - To modify "contrast" apply a exp() on L.=20
 - You can also use polar form of Lab LCh. There are a couple of =
functions to convert Lab <-> LCh
 - You can "desaturate" or "oversaturate" color by =
incrementing/decrementing C in LCh
 - Saturation of color is given by s =3D C/L
 - Hue angle is given by h

Best Regards,
Mart=ED Maria
The little cms project
http://www.littlecms.com
ma...@li...



  ----- Original Message -----=20
  From: Andreas Sch=F6mann=20
  To: lcm...@li...=20
  Sent: Saturday, March 16, 2002 9:34 AM
  Subject: Re: [Lcms-user] conversion sRGB to L*a*b* fatal error


  hi Mart=ED,

  good news for you.
  conversion with icctrans works quite well - in both directions.
    now i know how to deal with it :-) values are the same as in
    photoshop - except for rounding differences.

  i must admit - hmmh - i made a beginners mistake...
  when choosing color values with photoshop 'color picker' i was in
    L*a*b* color space - and so was very often out of RGB gamut...
    got a hot flush when i realised this.

  sorry Mart=ED for this false alarm, my only excuse is that i _am_ a
    newbie to color models and color handling.

  maybe you like to know how i came to lcms...
  i intend to make a tool to adjust brightness of each individual pixel
    of a picture - for now JPEGs.
  to do so i modified the IJG source code - needed three days of
    hard work...
  when i came to the point where i had access to the sample data i
    wondered how to modify the RGB values in order to modify
    brightness - but without changing the 'color' or at least my
    perception of a color becoming 'lighter'.
  whatever this _really_ means - need to find out more about it -
    i figured this must be difficult modifying three independent color
    values at once.
  in that situation i threw my eyes upon the L*a*b* color model which
    hopefully gives me what i want - at least it has one value to adjust
    'lightness'.
  but how to convert RGB to L*a*b* from within C code? now i know
    the answer and am very happy with it.

  thank you Mart=ED and all others involved in lcms project!

  andreas

    ----- Original Message -----=20
    From: Mart=ED Maria=20
    To: Andreas Sch=F6mann ; lcm...@li...=20
    Sent: Saturday, March 16, 2002 3:14 PM
    Subject: Re: [Lcms-user] conversion sRGB to L*a*b* fatal error


    Hi,

    > i am trying to validate the 'icctrans'-values for sRGB =
IEC61966-2.1 to L*a*b* conversion.=20

    Humm... I have checked this utility extensively, and seemed to work. =

    Are you sure Photoshop is using sRGB as workspace (Edit-Color =
settings-Working spaces RGB)?

    I'm also attaching latest source, with some small additions. But =
anyway the old one did work properly to me...=20

    This would give sRGB to Lab

    icctrans -v

    And this Lab to sRGB

    icctrans -i*Lab

    If this don't work to you, could please send any values that makes =
it fail? Thanks.

    Regards,
    Mart=ED Maria
    The little cms project
    http://www.littlecms.com
    ma...@li...






      ----- Original Message -----=20
      From: Andreas Sch=F6mann=20
      To: lcm...@li...=20
      Sent: Friday, March 15, 2002 5:10 PM
      Subject: [Lcms-user] conversion sRGB to L*a*b* fatal error


      hello marti,

      i am trying to validate the 'icctrans'-values for sRGB =
IEC61966-2.1 to L*a*b* conversion.
      i want to validate against adobe photoshop - i simply use the =
'color picker' to get values.
      i am unlucky :(
      neither the built in profile 'cmsCreateLabProfile(NULL)' nor =
'lcmstiff8.icm' nor 'tifflab8spac.icm' give me the photoshop values.

      i built lcms 1.08 with cygwin on win2000, build looked ok.

      what do you think?
      maybe i missed something?
      i'm not sure whether i use the right profiles.

      regards,
      andreas

Re: [Lcms-user] conversion sRGB to L*a*b* fatal error

[<ma...@li...>]

Hi,

> i am trying to validate the 'icctrans'-values for sRGB IEC61966-2.1 to L*a*b* conversion.

Humm... I have checked this utility extensively, and seemed to work.
Are you sure Photoshop is using sRGB as workspace (Edit-Color settings-Working spaces RGB)?

I'm also attaching latest source, with some small additions. But anyway the old one did work properly to me...

This would give sRGB to Lab

icctrans -v

And this Lab to sRGB

icctrans -i*Lab

If this don't work to you, could please send any values that makes it fail? Thanks.

Regards,
Martí Maria
The little cms project
http://www.littlecms.com
ma...@li...






  ----- Original Message -----
  From: Andreas Schömann
  To: lcm...@li...
  Sent: Friday, March 15, 2002 5:10 PM
  Subject: [Lcms-user] conversion sRGB to L*a*b* fatal error


  hello marti,

  i am trying to validate the 'icctrans'-values for sRGB IEC61966-2.1 to L*a*b* conversion.
  i want to validate against adobe photoshop - i simply use the 'color picker' to get values.
  i am unlucky :(
  neither the built in profile 'cmsCreateLabProfile(NULL)' nor 'lcmstiff8.icm' nor 'tifflab8spac.icm' give me the photoshop
values.

  i built lcms 1.08 with cygwin on win2000, build looked ok.

  what do you think?
  maybe i missed something?
  i'm not sure whether i use the right profiles.

  regards,
  andreas

Re: [Lcms-user] conversion sRGB to L*a*b* fatal error

[<and...@we...>]

hi Mart=ED,

good news for you.
conversion with icctrans works quite well - in both directions.
  now i know how to deal with it :-) values are the same as in
  photoshop - except for rounding differences.

i must admit - hmmh - i made a beginners mistake...
when choosing color values with photoshop 'color picker' i was in
  L*a*b* color space - and so was very often out of RGB gamut...
  got a hot flush when i realised this.

sorry Mart=ED for this false alarm, my only excuse is that i _am_ a
  newbie to color models and color handling.

maybe you like to know how i came to lcms...
i intend to make a tool to adjust brightness of each individual pixel
  of a picture - for now JPEGs.
to do so i modified the IJG source code - needed three days of
  hard work...
when i came to the point where i had access to the sample data i
  wondered how to modify the RGB values in order to modify
  brightness - but without changing the 'color' or at least my
  perception of a color becoming 'lighter'.
whatever this _really_ means - need to find out more about it -
  i figured this must be difficult modifying three independent color
  values at once.
in that situation i threw my eyes upon the L*a*b* color model which
  hopefully gives me what i want - at least it has one value to adjust
  'lightness'.
but how to convert RGB to L*a*b* from within C code? now i know
  the answer and am very happy with it.

thank you Mart=ED and all others involved in lcms project!

andreas

  ----- Original Message -----=20
  From: Mart=ED Maria=20
  To: Andreas Sch=F6mann ; lcm...@li...=20
  Sent: Saturday, March 16, 2002 3:14 PM
  Subject: Re: [Lcms-user] conversion sRGB to L*a*b* fatal error


  Hi,

  > i am trying to validate the 'icctrans'-values for sRGB IEC61966-2.1 =
to L*a*b* conversion.=20

  Humm... I have checked this utility extensively, and seemed to work.=20
  Are you sure Photoshop is using sRGB as workspace (Edit-Color =
settings-Working spaces RGB)?

  I'm also attaching latest source, with some small additions. But =
anyway the old one did work properly to me...=20

  This would give sRGB to Lab

  icctrans -v

  And this Lab to sRGB

  icctrans -i*Lab

  If this don't work to you, could please send any values that makes it =
fail? Thanks.

  Regards,
  Mart=ED Maria
  The little cms project
  http://www.littlecms.com
  ma...@li...






    ----- Original Message -----=20
    From: Andreas Sch=F6mann=20
    To: lcm...@li...=20
    Sent: Friday, March 15, 2002 5:10 PM
    Subject: [Lcms-user] conversion sRGB to L*a*b* fatal error


    hello marti,

    i am trying to validate the 'icctrans'-values for sRGB IEC61966-2.1 =
to L*a*b* conversion.
    i want to validate against adobe photoshop - i simply use the 'color =
picker' to get values.
    i am unlucky :(
    neither the built in profile 'cmsCreateLabProfile(NULL)' nor =
'lcmstiff8.icm' nor 'tifflab8spac.icm' give me the photoshop values.

    i built lcms 1.08 with cygwin on win2000, build looked ok.

    what do you think?
    maybe i missed something?
    i'm not sure whether i use the right profiles.

    regards,
    andreas

[Lcms-user] conversion sRGB to L*a*b* fatal error

[<and...@we...>]

hello marti,

i am trying to validate the 'icctrans'-values for sRGB IEC61966-2.1 to =
L*a*b* conversion.
i want to validate against adobe photoshop - i simply use the 'color =
picker' to get values.
i am unlucky :(
neither the built in profile 'cmsCreateLabProfile(NULL)' nor =
'lcmstiff8.icm' nor 'tifflab8spac.icm' give me the photoshop values.

i built lcms 1.08 with cygwin on win2000, build looked ok.

what do you think?
maybe i missed something?
i'm not sure whether i use the right profiles.

regards,
andreas

[Lcms-user] Re: is LCMS thread safe?

[<ma...@li...>]

Hi,

>cmscnvrt.c:static cmsCIEXYZ IlluminantD50 = {D50X, D50Y, D50Z};
>cmserr.c:static BOOL nDoAbort = LCMS_ERROR_ABORT;
>cmsgmt.c:       static WORD RGBblack[4]  = { 0, 0, 0 };
>cmsgmt.c:       static WORD RGBwhite[4]  = { 0xffff, 0xffff, 0xffff };
>cmsgmt.c:       static WORD CMYKblack[4] = { 0, 0, 0, 0xffff };
>cmsgmt.c:       static WORD CMYKwhite[4] = { 0, 0, 0, 0 };
>cmsgmt.c:       static WORD LABblack[4]  = { 0, 0, 0 };
>cmsgmt.c:       static WORD LABwhite[4]  = { 0xFF00, 0x8000, 0x8000 };
>cmsgmt.c:       static WORD Default[MAXCHANNELS];

All those are constants (read only) or global settings.

> cmsintrp.c:static Fixed32  Cube[27];

This one should NOT be present on lcms1.08.

>cmsio1.c:static size_t UsedSpace;
>cmsio1.c:    static icLut8 LUT8;
>cmsio1.c:    static icLut16 LUT16;

Humm... again these are gone on 1.08. Are you using latest version?

>cmsio1.c:       static char Name[2048];
>cmsio1.c:       static char Name[2048];
> cmsio1.c:       static char Info[4096];

These are for info functions. As said these functions are meant to be used in UI,
which is not willing to be used on separate thread. You could modify them if wish
so, however.

> cmsxform.c:static WORD AlarmR = 0x7fff, AlarmG = 0xfffe, AlarmB = 0x7fff;
>cmsxform.c:static icTagSignature Device2PCS[] = {icSigAToB0Tag,       /* Perceptual */
> cmsxform.c:static icTagSignature PCS2Device[] = {icSigBToA0Tag,       /* Perceptual */
>cmsxform.c:static icTagSignature Preview[]    = {icSigPreview0Tag,

More constant tables or global settings.

>is there anything to be concerned about LUT8, LUT16, Default[MAXCHANNELS],
>Cube[27], and UsedSpace.
>Thanks,

The only suspicious one is 'UsedSpace', but this is used by the profile writting extensions,
which are undocumented in ver 1.08 and only used by the profilers.
Anyway, please make sure you are using 1.08, previous versions were not tested
on multiple threads. LUT8 and LUT16 are fixed in 1.08

Regards,
Marti.



----- Original Message -----
From: "Dhiraj Kacker" <dk...@sh...>
To: "'Martí Maria'" <ma...@li...>
Cc: "Russ Muzzolini" <ru...@sh...>
Sent: Tuesday, March 05, 2002 12:34 PM
Subject: RE: is LCMS thread safe?



Thanks for the reply, Marti.
Are there any other threading issues with LCMS (outside of the ones below)?

I did a : "grep static *.c | awk '$2 != "" {print $0}'"
in the lcms src dir and found :

cmscnvrt.c:static cmsCIEXYZ IlluminantD50 = {D50X, D50Y, D50Z};
cmserr.c:static BOOL nDoAbort = LCMS_ERROR_ABORT;
cmsgmt.c:       static WORD RGBblack[4]  = { 0, 0, 0 };
cmsgmt.c:       static WORD RGBwhite[4]  = { 0xffff, 0xffff, 0xffff };
cmsgmt.c:       static WORD CMYKblack[4] = { 0, 0, 0, 0xffff };
cmsgmt.c:       static WORD CMYKwhite[4] = { 0, 0, 0, 0 };
cmsgmt.c:       static WORD LABblack[4]  = { 0, 0, 0 };
cmsgmt.c:       static WORD LABwhite[4]  = { 0xFF00, 0x8000, 0x8000 };
cmsgmt.c:       static WORD Default[MAXCHANNELS];
cmsintrp.c:static Fixed32  Cube[27];
cmsio1.c:static size_t UsedSpace;
cmsio1.c:    static icLut8 LUT8;
cmsio1.c:    static icLut16 LUT16;
cmsio1.c:       static char Name[2048];
cmsio1.c:       static char Name[2048];
cmsio1.c:       static char Info[4096];
cmsxform.c:static WORD AlarmR = 0x7fff, AlarmG = 0xfffe, AlarmB = 0x7fff;
cmsxform.c:static icTagSignature Device2PCS[] = {icSigAToB0Tag,       /*
Perceptual */
cmsxform.c:static icTagSignature PCS2Device[] = {icSigBToA0Tag,       /*
Perceptual */
cmsxform.c:static icTagSignature Preview[]    = {icSigPreview0Tag,


is there anything to be concerned about LUT8, LUT16, Default[MAXCHANNELS],
Cube[27], and UsedSpace.
Thanks,

-Dhiraj

-----Original Message-----
From: Martí Maria [mailto:ma...@li...]
Sent: Tuesday, March 05, 2002 5:39 AM
To: Dhiraj Kacker
Cc: lcm...@li...
Subject: Re: is LCMS thread safe?


Hi,

I'm forwarding this to mailing list... could be interesting for someone
else.

> I have been looking through some of the LCMS code and it seems like it is
> not
> thread-safe. In particular I looked at
>
> cmsTakeProductName
> cmsTakeProductDesc
> cmsTakeProductInfo
>
> all of which have static chars defined that could cause threading issues.
> Is there a particular reason why these are set as statics? What would
> happen if I would just change that.

Yes, you are right. Those functions are NOT thread safe, since they
write to a static buffer. However, those  functions are ment to be used
on UI only. The transform code is thread safe with USE_C method.
I did check on a multiprocessor machine and did work.

And you can change them if wish so... I used the static buffer just for
simplicity sake. Nothing prevents to use a buffer pointer as a parameter,
for example. But please note that those functions would be very rarely used
on separated threads.

About the "nDoAbort". This is supposed to be a global setting. Probably
a multithreaded application would replace whole error handling by its own.
Is as easy as write repacements for cmsSignalError() and cmsErrorAction().

Regards,
Martí Maria
The little cms project
http://www.littlecms.com
ma...@li...




----- Original Message -----
From: "Dhiraj Kacker" <dk...@sh...>
To: "'Martí Maria'" <ma...@li...>
Sent: Tuesday, March 05, 2002 12:09 AM
Subject: is LCMS thread safe?


> Hi Marti,
>
> I have been looking through some of the LCMS code and it seems like it is
> not
> thread-safe. In particular I looked at
>
> cmsTakeProductName
> cmsTakeProductDesc
> cmsTakeProductInfo
>
> all of which have static chars defined that could cause threading issues.
> Is there a particular reason why these are set as statics? What would
> happen if I would just change that.
>
> Also in the error handling the gloabal variable "nDoAbort" is used making
> that too risky to use with multiple threads.
>
> Thoughts?
>
> -Dhiraj
>
>

[Lcms-user] Re: is LCMS thread safe?

[<ma...@li...>]

Hi,

I'm forwarding this to mailing list... could be interesting for someone else.

> I have been looking through some of the LCMS code and it seems like it is
> not
> thread-safe. In particular I looked at
>
> cmsTakeProductName
> cmsTakeProductDesc
> cmsTakeProductInfo
>
> all of which have static chars defined that could cause threading issues.
> Is there a particular reason why these are set as statics? What would
> happen if I would just change that.

Yes, you are right. Those functions are NOT thread safe, since they
write to a static buffer. However, those  functions are ment to be used
on UI only. The transform code is thread safe with USE_C method.
I did check on a multiprocessor machine and did work.

And you can change them if wish so... I used the static buffer just for
simplicity sake. Nothing prevents to use a buffer pointer as a parameter,
for example. But please note that those functions would be very rarely used
on separated threads.

About the "nDoAbort". This is supposed to be a global setting. Probably
a multithreaded application would replace whole error handling by its own.
Is as easy as write repacements for cmsSignalError() and cmsErrorAction().

Regards,
Martí Maria
The little cms project
http://www.littlecms.com
ma...@li...




----- Original Message -----
From: "Dhiraj Kacker" <dk...@sh...>
To: "'Martí Maria'" <ma...@li...>
Sent: Tuesday, March 05, 2002 12:09 AM
Subject: is LCMS thread safe?


> Hi Marti,
>
> I have been looking through some of the LCMS code and it seems like it is
> not
> thread-safe. In particular I looked at
>
> cmsTakeProductName
> cmsTakeProductDesc
> cmsTakeProductInfo
>
> all of which have static chars defined that could cause threading issues.
> Is there a particular reason why these are set as statics? What would
> happen if I would just change that.
>
> Also in the error handling the gloabal variable "nDoAbort" is used making
> that too risky to use with multiple threads.
>
> Thoughts?
>
> -Dhiraj
>
>

Re: [Lcms-user] LCMS on OS/X

[<ma...@li...>]

Hi,

Tested on MacOS X 10.1 SERVER Edition (from sourceforge) and all worked
fine. Just untar the lcms-1.08.tar.gz distribution and type 'make'

The only configuration needed is to uncomment USE_BIG_ENDIAN in lcms.h
Anyway, if you forgot to do so, the testbed complains about it.

Regards,
Martí Maria
The little cms project
http://www.littlecms.com
ma...@li...


----- Original Message -----
From: "Robert Raleigh" <ro...@ra...>
To: <lcm...@li...>
Sent: Sunday, February 24, 2002 11:05 PM
Subject: [Lcms-user] LCMS on OS/X


> Has anyone had any luck compiling LCMS on MacOS X, or even better, is there
> any known binary distribution of LCMS available for MacOS X? I'm trying to
> build a Digital Asset Management System that utilizes ImageMagick to convert
> images on the fly to various different formats while using LCMS to maintain
> accurate color quality. This system will need to run on OS/X, so if anyone
> has any tips on how to make LCMS work, drop me a line.
>
>
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>

[Lcms-user] LCMS on OS/X

[Robert R. <ro...@ra...>]

Has anyone had any luck compiling LCMS on MacOS X, or even better, is there
any known binary distribution of LCMS available for MacOS X? I'm trying to
build a Digital Asset Management System that utilizes ImageMagick to convert
images on the fly to various different formats while using LCMS to maintain
accurate color quality. This system will need to run on OS/X, so if anyone
has any tips on how to make LCMS work, drop me a line.

 

[Lcms-user] Re: Gamut mapping algorithms

[<ma...@li...>]

Hi,

> I am asking your help to find resources about mapping=20

> techniques for LAB <-> CMYK color spaces. I am=20

> interested in an image independent function based on=20

> the ICC profile.=20



You have choosen a hard subject :-)

One very interesting source:
http://colour.derby.ac.uk/~jan/gamut_mapping.html

Also, CIE has a lot of stuff:
http://www.colour.org/info/TCs.htm

Please note that all this is necessary only when building profiles,=20
if you are going to use existing profiles, you don't need to worry about =

all this stuff: the profile will do all gamut remapping for you.

If you simply want to convert form Lab <-> CMYK by using lcms, this
is fair simple; just use Lab and CMYK profiles in a transform.

Hope this helps
Mart=ED Maria
The little cms project
http://www.littlecms.com
ma...@li...

  ----- Original Message -----=20

    Hi!

    I am asking your help to find resources about mapping techniques for =
LAB <-> CMYK color spaces. I am interested in an image independent =
function based on the ICC profile.=20

  =20

    Thank you,

    Mihai Zahorski

[Lcms-user] Re: thanx and query.

[<ma...@li...>]

Hi,

> Thanx for making this stuff available. I have been trying to get a handle
> on ICM WRT modifying a epson inkjet profile for use with a 3'rd party ink
> (enhanced generations). I've spent the weekend reading specs and stuff but
> I'm not sure I quite have it.
> The profiles I'm interested in seem to have both RGB to PCS and PCS to RGB
> conversion tables (epson printers take RGB not CMYK). If both tables are
> used by the CMM it seems to defeat the point of using the PCS - you still
> need one profile per input-output combo?

Think about profiles as a abstract representation of colorspace, no matter
how are they built internally. If you take a profile of your epson inkjet, this
is a representation of the particular RGB space of that printer.

So, if you want to print, for example, a image that is in sRGB space, you
need to convert from sRGB to the epson inkject RGB space in order to keep
original colors.

And that is the job of the CMM. It converts between colorspaces.
No more, no less.  If you use same profile on input and output... well, you
are converting form your inkjet colorspace to your inkjet colorspace.
No changes at all.  This is the reason why the CMM does need at less
two profiles.

> I would have expected the CMM to need a pair of profiles?

You need a pair of *different* profiles in order to get meaninfull results.
You need to know the colorspace of the image in order to print it
accurately. This is the function of embedded profiles, or the sRGB space.
sRGB is a "reasonable default" when you have not any information on
which space the image is.

> Your profile viewer has been very useful, I'm about to play some of your
> other programs. My plan is the print 16^3 test patches using OEM ink and
> try to match as far as possible the new ink. The archival ink is much
> colder in the yellow and magenta.

Unfortunately, we have still no printer profiler available. We are working on this
stuff, but is harder that it seems. I do expect to have a prototype in middle of
next summer. Meanwhile, you have free scanner & monitor profiles in site.


Regards,
Martí Maria
The little cms project
http://www.littlecms.com
ma...@li...

----- Original Message -----
From: "Eddie Matejowsky" <ed...@op...>
To: <in...@li...>
Sent: Sunday, February 17, 2002 9:48 PM
Subject: thanx and query.


> Hi,
> Thanx for making this stuff available. I have been trying to get a handle
> on ICM WRT modifying a epson inkjet profile for use with a 3'rd party ink
> (enhanced generations). I've spent the weekend reading specs and stuff but
> I'm not sure I quite have it.
> The profiles I'm interested in seem to have both RGB to PCS and PCS to RGB
> conversion tables (epson printers take RGB not CMYK). If both tables are
> used by the CMM it seems to defeat the point of using the PCS - you still
> need one profile per input-output combo?
> I would have expected the CMM to need a pair of profiles?
> Your profile viewer has been very useful, I'm about to play some of your
> other programs. My plan is the print 16^3 test patches using OEM ink and
> try to match as far as possible the new ink. The archival ink is much
> colder in the yellow and magenta.
> My motto of "they're only numbers - how hard can it be" is going to tested.
> Ciao Eddie.

[Lcms-user] Re: scanner calibration and "possible inconsistency"

[<ma...@li...>]

Hi,

I'm also forwarding this to mailing list.

> I have had the opportunity to calibrate a scanner using two different
> ransparency targets, one profesional, one from Wolf Faust. I'm not
> saying that the latter is not professional, but anyway:
>
> My calibration profile produced with professional software and the
> first target seemed OK, but using the latter target (E0105111 I think)
> produced a questionable result regarding the Red Colorant rXYZ.
>
> First I thought it's a bug in the software, but yesterday I used the
> free tools to produce a measurement sheet, and then a profile. During
> that process I got a warning about a "possible inconsitency", so I
> wonder if the target or the target description data has a problem.

Doublecheck if you are mismatching target sheets. I have done several
testing with Wolf's targets and they are clear winner on accurancy and
big gamut. This warning is issued when regression is not convergent,
that could be a clue of wrong target sheet selected.
Also note that reflective and film are completly different. If you are using
reflective sheet and a film target, you will find this kind of problems.


> Unfortunately the free software does not allow to save the output of

For saving output of progress, right click over text, click on "Select All",
right click again, click on "Copy" and then paste text on your favourite
text editor.

> "Progress". Also I could not use the 16bit per RGB TIFF, but had to
> convert it to 8bit/channel PNG.
>

Yes... measurement tool is very limited. This is in part due I'm using Qt
for portability. Unfortunately, Qt support on imaging is minimal.
No TIFF, no 16 bps in any way and a few supported formats. Otherwise
measurement tool functionality is quite simple: It only reads pixels and
creates a IT8 sheet containing RGB values per patch.

I did separate programs in order to better the profile generation, leaving
the RGB collection in a second plane. This has been my fault, since for
now seems evident a carefull RGB picking plays a vital role. 16 bps
would be a big improvement, specially on dark zones. Also some
processing instead simple mean value seems more adequate.

But as said these are measurement tool limitations. The scanner & monitor
profiles does not have such limitations since they read IT8 files and does
write profiles. Probably measurement tool should be almost fully rewritten
for next revision.

Any thoughts?

Regards,
Marti Maria


----- Original Message -----
From: "Ulrich Windl" <Ulr...@rz...>
To: <kw...@co...>
Cc: "Martí Maria" <ma...@li...>; <wf...@co...>
Sent: Tuesday, February 12, 2002 4:05 AM
Subject: scanner calibration and "possible inconsistency"


> Hello,
>
> I have had the opportunity to calibrate a scanner using two different
> ransparency targets, one profesional, one from Wolf Faust. I'm not
> saying that the latter is not professional, but anyway:
>
> My calibration profile produced with professional software and the
> first target seemed OK, but using the latter target (E0105111 I think)
> produced a questionable result regarding the Red Colorant rXYZ.
>
> First I thought it's a bug in the software, but yesterday I used the
> free tools to produce a measurement sheet, and then a profile. During
> that process I got a warning about a "possible inconsitency", so I
> wonder if the target or the target description data has a problem.
>
> Unfortunately the free software does not allow to save the output of
> "Progress". Also I could not use the 16bit per RGB TIFF, but had to
> convert it to 8bit/channel PNG.
>
> I'm quite new to all those topics, so giving me some useful advice
> would be great. I could also provide more data if you should need such.
>
> Regards,
> Ulrich
>
>
>

[Lcms-user] Re: Reading ICC profil

[<ma...@li...>]

Hi,

I'm taking the freedom to submit your letter to mailing list, since it seems an
interesting subject. Forgive me if this is not ok to you.

> I examined the source code Delphi of the project
> " Chromaticity.dpr ", and I could use the functions
> of reading of the ficiers of profile ICC with the DLL " lcms.dll ".
> However I did not find the possibility of reading the values gamma
> attached to each primary and white point.
> If exist such functions in the DLL in this case can you indicate the protopypes,
> if not if exist a DLL more complete can you send me it ?

The overall idea behind lcms is to operate at high level. This means that lcms
is hidden all complexity of profile internals to you. Also, you don't see
profiles as containers of curves, chromaticities, etc but a black box holding
a colorspace representation. This has evident benefits over low-level appproach.
Just an example: you want to extract TRC curves from profile, but
not all profiles are implemented as matrix-shaper. Profiles using 3D CLUT
does not store such tables. Transfer functions are embedded into grid LUT.

Otherwise, what are you trying to do is perfectly reasonable, and there
IS a clean way to do this, in a form ALL profiles will work.

I'm assuming you want to plot the gamma curves on a particular
colorspace represented by a profile. First, you need a reference
space. A good choice would be XYZ. It has gamma 1.0 and
Y comes separated from chroma. So, you may create a
transform between your profile -> XYZ and then feed the
transform with intended r, g and b, obtaining Y and chroma
component XZ. For reverse curves, all is same but the
transform comes XYZ -> RGB. There are big implications
of gamut here.

Code would be some like:

   In  := cmsOpenProfileFromFile('theprofile.icm','r);
   Out  := cmsCreateXYZProfile();

   cmsCreateTransform(In, TYPE_RGB_8, Out, TYPE_XYZ_16, INTENT_PERCEPTUAL, 0)
  ...
   cmsDoTransform(@YourRGB, @ObtainedEncodedXYZ, 1)
  cmsXYZEncoded2Float(@ObtainedEncodedXYZ, @FloatXYZ);
...


 Note also that examining gamma at, for example (r, 0, 0),
that is, form (0, 0, 0) to (255, 0, 0) is taking curve *at gamut
boundaries*, so, probably this will give false curves in all but
syntetic spaces like thos of matrix-shaper profiles. The concept of
3 independent gamma curves is only a subset of possible color
spaces.

Hope this helps
Martí Maria
The little cms project
http://www.littlecms.com
ma...@li...


----- Original Message -----
From: Color ID
To: in...@li...
Sent: Thursday, February 07, 2002 12:58 PM
Subject: Reading ICC profil


Hello,
I examined the source code Delphi of the project " Chromaticity.dpr ", and I could use the functions of reading of the ficiers of
profile ICC with the DLL " lcms.dll ". However I did not find the possibility of reading the values gamma attached to each primary
and white point.
If exist such functions in the DLL in this case can you indicate the protopypes, if not if exist a DLL more complete can you send
me it ?
Thank you to inform me on this subject.
Cordially
__________________________
Jean-Pierre Guillemin
Color i.d.
BP 2216 51081 Reims Cedex
tel 03 26 79 83 42
fax 03 26 79 83 43
mobile 06 08 73 34 52
e-mail jp...@co...
_________________________

[Lcms-user] New utility for applying ICC profiles to JPEG

[<ma...@li...>]

Folks,

I've put on site a experimental new utility for applying ICC profiles
to JPEG files. It is to be considered in ALPHA stage, and probably
still buggy, but I belive it could be interesting. Suggestions are
welcome.

http://www.littlecms.com/JPEGICC.ZIP

It behaves very similarly to TIFFICC, but dealing with JPEG. It does
accept embedded profiles as well as Gray, RGB, CMYK and the
default encoding of ITU T.42/Fax  Lab JPEG via an included  profile.

More about ITU/Fax profile on http://www.littlecms.com/itufax.htm

The ZIP does contain source code and a precompiled binary for Win32.
It is using Tom Lane's IJG library http://www.ijg.org However, I have
been forced to slightly modify IJG code in order to support properly
Adobe's variant of CMYK JPEG. If anybody is interested in the
modified IJG version, plea let me know. I will send sources or put a zip
in site.

Regards,
Martí Maria
The little cms project
http://www.littlecms.com
ma...@li...

Re: [Lcms-user] Fw: scanner gamut & Q60R1/IT8

[<ma...@li...>]

Hi,

:-) You have pointed one of the most difficult parts of
profile generation.

The fact is, IT8 targets, in general, does NOT have a big
gamut. So, an extrapolation must be used in order to
accomodate  these out of target gamut colors, as well as
highlights, flourescent colors and so one.

Actually, the scanner profiler is using a sort of weighted
multiple linear polinomical regression up to x^5 terms.
This represents a maximum of  50 terms and a very
big matrix inversion.

According to several authors, Kang for example, this
gives a good extrapolation near gamut boundaries.

For my testings extrapolation does work well *if* you deal
with correct data, and very bad if the data is mismatched.

For example, in one test I did try what happens if someone
picks the wrong target reference. In that case, grid inside
gamut fitted patches, but outside got badly mixed.
And why this? Just becase the input data is wrong, and the
transitions aren't smooth. Any abrupt change yelds in bigger
coefficients on higer terms, above x^2, and the overall gamut
hull must distort to accomodate these points. Somewhat like
to "stench" the gamut hull to fit outliers.

This don't happen on good data, since there are no abrupt
changes. The hardware don't give step functions. And then,
extrapolation does work fine.

Anyway, I tried several profiles with out of gamut colors,
for example pure blue (0, 0, 255) that no scanner will give.
And all worked fine, but as said only if proper target & scanout
were used. Actually, the profile does signal a warning if it detects
input data is not well behaved.

Regards,
Marti.


----- Original Message -----
From: "Martí Maria" <ma...@li...>
To: <lcm...@li...>
Sent: Tuesday, January 29, 2002 4:04 PM
Subject: [Lcms-user] Fw: scanner gamut & Q60R1/IT8


>
>
>   How does "scanner profiler" address the main critcism of the Q60R1 (other
>  than the measurement file being accurate) ... that being, a scanner's
>  potential gamut exceeding that of the target?  Having profiled my scanner,
>  the profile seems to be accurate enough, but I'm wondering about how well it
>  determined its gamut.  Does the profile assume the colors measured are the
>  limit of gamut??  Or, is it able to (somehow) extrapolate based in the
>  gamut's interior?
>
>  cheerios ... shAf  :o)
> Avalon Peninsula, Newfoundland
>
>
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>

[Lcms-user] Fw: scanner gamut & Q60R1/IT8

[<ma...@li...>]

  How does "scanner profiler" address the main critcism of the Q60R1 (other
 than the measurement file being accurate) ... that being, a scanner's
 potential gamut exceeding that of the target?  Having profiled my scanner,
 the profile seems to be accurate enough, but I'm wondering about how well it
 determined its gamut.  Does the profile assume the colors measured are the
 limit of gamut??  Or, is it able to (somehow) extrapolate based in the
 gamut's interior?
 
 cheerios ... shAf  :o)
Avalon Peninsula, Newfoundland
 
 

Re: [Lcms-user] Re: Mixing Lab color

[<ma...@li...>]

Armindo,

Let's start from beginning.

I do assume you want to somehow emulate in your app ink mixing.
As said, I belive this is_very_ difficult, and can be done only very
coarsely, but anyway, icc profiles seems to me the only reasonable
way.

Assuming you are using Lab as a means to store colors to be mixed,
and  want a Lab, or better a visualitation of resulting mixture.

Ok. As said, this is _hardly_ dependent of printer. It involves a lot
of things like substrate (paper), illuminant, etc, etc. Is not same
mixing inks of one vendor that from other vendor, no matter all
inks are same color. But since you are using a profile of
printer, some of these factors are handled by the
profile.  Including mixing behaviour. All Ok right now.

Printers, as well as inks, are real devices; not math models!
So, there is no "universal CMYK", in the sense there are no
perfect inks. The photoshop CMYK profile is really a "generic"
separation. A good separation. This is handling reald world inks,
and as such, it takes into consideration factors like 4 inks cannot
represent all colors, but only a reduced amount. This is known as
the gamut, and has important implications on how will work all your
system.

Since printers does have limited gamut, if you print a image, the
profile does convert or collapse several colors. This is known as
gamut remapping. Intents are only strategies to follow when any
of these unrepresentable colors are found.

Then, a CMYK separation profile does include 2 ways to operate:
one, from Lab to CMYK and other from CMYK to Lab.

The CMYK to Lab is the easy one. Is just a bunch of measurements
of each ink combinations on Lab space. For example, amounts 19%,
15%, 16%,  1% of CMYK inks will result in Lab = 82, 2, 2.
These are just measurements, and there is no problem since all amount
of inks can be really painted on paper, and can be measured by a
colorimeter. There are no undefined cases here.

But then, it is the Lab -> CMYK. This is not easy, since it includes
a amount of color science, device settings and *art* to guess the
necessay amount of inks (the plates) of separation. Undercolor
removal, black generation, dot gain, gamut remapping, paper
absortion and a wide etc.

The "magic" here is when you do a transform from Lab to CMYK.
The photoshop profile has a lot of magic embedded, but it cannot do
impossible things, and some Lab colors cannot be done by mixing
any inks, so, the profile guesses a near color. This is going to give
difference on almost any image. So, when you are doing
Lab -> CMYK you are doing the separation, and when you do
CMYK->Lab you are only measuring the results of the separation.

So, the the chain Lab -> CMYK -> Lab is really a softproof of the
separation.

The CMYK->Lab (measurement) is smart enough to deal with ink
combinations that the separation will never give. Then you can
play with the inks, and the measurement will return a educated guess
on the mesurement of resulting color. No more, no less.

So, trying to mix colors, would involve to convert the desired
colors to CMYK, note that this _may_ move these colors, and you
can preview the print by CMYK -> RGB, then operating on inks, and
then again preview result by CMYK -> RGB.  But again, this depends
*entirely* on separation profile.

Regards,
Marti.

----- Original Message -----
From: "Armindo Da Silva" <tec...@wa...>
To: "Martí Maria" <ma...@li...>
Cc: <Lcm...@li...>
Sent: Tuesday, January 29, 2002 8:32 AM
Subject: Re: [Lcms-user] Re: Mixing Lab color


> > Normally perceptual intents are used, but for pigments perhaps saturation
> > could be usefull. Anyway it depends on how do you want to handle the
> > unrealizable colors.
>
> My problem here is that the CMYK is only used for my transformation (color
> mixing)  and at this moment I don't want to worry about unrealizable colors,
> I would like to worry only when converting from CMYK to RGB.
>
> I have noticed a "visible" difference between  Lab-> and Lab->CMYK->RGB , of
> course that's normal because there's 2 transform, but my goal is to have the
> smallest difference possible
>
> > Besides, your Lab->CMYK->RGB is doing a softproof of the printer, you
> > should see in monitor the *exact* color as printed on paper. Of course
> assuming
> > the printer profile is accurate and proper.
>
> Humm, Maybe I have forgotten to tell, I use here the photoshop CMYK profile
> (not a printer one) because as I said I use only CMYK for mixing colors.
>
> Armindo
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>

Re: [Lcms-user] Re: Mixing Lab color

[Armindo Da S. <tec...@wa...>]

> Normally perceptual intents are used, but for pigments perhaps saturation
> could be usefull. Anyway it depends on how do you want to handle the
> unrealizable colors.

My problem here is that the CMYK is only used for my transformation (color
mixing)  and at this moment I don't want to worry about unrealizable colors,
I would like to worry only when converting from CMYK to RGB.

I have noticed a "visible" difference between  Lab-> and Lab->CMYK->RGB , of
course that's normal because there's 2 transform, but my goal is to have the
smallest difference possible

> Besides, your Lab->CMYK->RGB is doing a softproof of the printer, you
> should see in monitor the *exact* color as printed on paper. Of course
assuming
> the printer profile is accurate and proper.

Humm, Maybe I have forgotten to tell, I use here the photoshop CMYK profile
(not a printer one) because as I said I use only CMYK for mixing colors.

Armindo

Re: [Lcms-user] Re: Mixing Lab color

[<ma...@li...>]

Hi,

> So for the CMYK to RGB no problem.
> But about the Lab to CMYK what should I use? (here I use INTENT_PERCEPTUAL,
> but I don't know if I should also use RenderIntent)

Is in this transform when render intent does make physicall sense... You have a
Lab color and want to realize it in inks. If the color can be represented, then all
intents are going to be same. But if color cannot be represented, then the intent
does apply. What do you want on these unrepresentable colors? to maintain
saturation? if so, use INTENT_SATURATION. If you want to keep contrast,
then use INTENT_PERCEPTUAL. The profile will remap the color to the
most proper, attending the rules the intent is specifying.

Normally perceptual intents are used, but for pigments perhaps saturation
could be usefull. Anyway it depends on how do you want to handle the
unrealizable colors.

Besides, your Lab->CMYK->RGB is doing a softproof of the printer, you
should see in monitor the *exact* color as printed on paper. Of course assuming
the printer profile is accurate and proper.

Regards,
Marti.

----- Original Message -----
From: "Armindo Da Silva" <tec...@wa...>
To: "Martí Maria" <ma...@li...>
Cc: <Lcm...@li...>
Sent: Tuesday, January 29, 2002 7:23 AM
Subject: [Lcms-user] Re: Mixing Lab color


> Marti,
>
> Concerning the mixing color a question about profile transform :
>
> To convert from Lab to CMYK I do :
>   Lab2CMYKTransform:= cmsCreateTransform(hLabProfile,
>                 TYPE_Lab_16,
>                 hCMYKProfile,
>                 TYPE_CMYK_16,
>                 INTENT_PERCEPTUAL,0);
>
> to convert the mixing result to RGB I do
>
> CMYK2DisplayTransform:= cmsCreateTransform(hCMYKProfile,
>                 TYPE_CMYK_16,
>                 hDisplayProfile,
>                 TYPE_BGR_8,
>                 RenderIntent,0);
>
> where here RenderIntent is a variable that the user can set for using
> Saturation, perceptual....
>
> So for the CMYK to RGB no problem.
> But about the Lab to CMYK what should I use? (here I use INTENT_PERCEPTUAL,
> but I don't know if I should also use RenderIntent)
>
> thanks
>
> Armindo
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>

[Lcms-user] Re: Mixing Lab color

[Armindo Da S. <tec...@wa...>]

Marti,

Concerning the mixing color a question about profile transform :

To convert from Lab to CMYK I do :
  Lab2CMYKTransform:= cmsCreateTransform(hLabProfile,
                TYPE_Lab_16,
                hCMYKProfile,
                TYPE_CMYK_16,
                INTENT_PERCEPTUAL,0);

to convert the mixing result to RGB I do

CMYK2DisplayTransform:= cmsCreateTransform(hCMYKProfile,
                TYPE_CMYK_16,
                hDisplayProfile,
                TYPE_BGR_8,
                RenderIntent,0);

where here RenderIntent is a variable that the user can set for using
Saturation, perceptual....

So for the CMYK to RGB no problem.
But about the Lab to CMYK what should I use? (here I use INTENT_PERCEPTUAL,
but I don't know if I should also use RenderIntent)

thanks

Armindo

Re: [Lcms-user] Fw: "tweeking parameters" for scanner profile

[<ma...@li...>]

Hi,

There is actually almost no documentation, just because this
is a preliminary release. There is some help as tooltips in the
profiler, and here are some additional clues. It is expected full
documentation when the release of the printer profile. Hopefully
in a near future.

"Resolution (CLUT points)" - This is compromise quality/size. On more
points bigger files and more precission. 16 points would be enough for
normal usage. 33 point is the theorical limit, more points would result in
bigger files with no quality gain.

"Strategy" - This is the internal strategy used by profiler to compute the
profile tables. Set this one to "Global". Local analyse does give slightly
better results in a very few cases, but generally results in bad profiles.
We are seriously thinking on to remove this option on next revisions.

"Prelinearization" This is the degree on "smothness" to be applied to
curves. Smooth curves are more pleasing to eye and does minimize
noise and target error. Leave untouched for normal usage.

"Chormatic adaptation" - This is the CIECAM97 model, that can
be used to emulate viewing condition and other wonders. For example,
it can be used to profile a camera translating colors from outdoors
to pich dark interiors. CIECAM97 per se is worth of a whole book,
however you can find some explanation of it on
http://www.colour.org/tc8-01/pics00moroney.pdf


Regards,
Marti.

----- Original Message -----
From: "Martí Maria" <ma...@li...>
To: <lcm...@li...>
Sent: Monday, January 28, 2002 5:09 PM
Subject: [Lcms-user] Fw: "tweeking parameters" for scanner profile


>   I've been able to create a relatively accurate profile for my flatbed with
>  a Kodak Q60R1 IT8, but I would appreciate knowing a bit more about the lCMS
>  scanner profiler's parameter's tweeks.  Is there a FAQ or description of the
>  options somewhere?
>
>  cheerios ... shAf  :o)
>  Avalon Peninsula, Newfoundland
>
>
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
>
>

[Lcms-user] Fw: "tweeking parameters" for scanner profile

[<ma...@li...>]

  I've been able to create a relatively accurate profile for my flatbed with
 a Kodak Q60R1 IT8, but I would appreciate knowing a bit more about the lCMS
 scanner profiler's parameter's tweeks.  Is there a FAQ or description of the
 options somewhere?
 
 cheerios ... shAf  :o)
 Avalon Peninsula, Newfoundland
 
 

Re: [Lcms-user] Mixing Lab color

[<ma...@li...>]

Hi,

> What is the name of the profile I should use for CMYK?

Just the profile for the intended printer. Remember, CMYK
is device dependent.=20

Regards,
Marti.