Thread: [Lcms-user] ICC profiles -> primaries
An ICC-based CMM for color management
Brought to you by:
mm2
Menu
▾
▴
lcms-user
|
From: Kai-Uwe B. <ku...@gm...> - 2005-10-03 10:24:58
|
Hi,
is there a example to get the real xy primaries from an given matrix
profile, including white point adaption?
regards
Kai-Uwe Behrmann
+ development for color management
+ imaging / panoramas
+ email: ku...@gm...
+ http://www.behrmann.name
|
|
From: Kai-Uwe B. <ku...@gm...> - 2005-10-06 17:48:41
|
Hi,
even in danger to repeat this toppic, here comes my own take:
The primaries stored in the rXYZ,gXYZ and bXYZ tags are part of the
RGB<->XYZ conversion matrix. They are related to D50.
The whitepoint in wtpt represents the original whitepoint of the media.
To convert from D50 primaries to oroginal wtpt primaries the chad tag was
introduced. It holdes the conversion matrix to come from D50 primaries to
wtpt primaries.
Additional the chromaticity (chrm) tag, natively being in wtpt, can be
used to hold the origin in the profile.
Without knowing the chromaticities (chrm) or the transform (chad)
conversion is guessing of the right transform. Bradford is a good
candidate.
The good news, now I understand it, the chrm tag is included by lcms
during RGB matrix profile generation. Thanks!
regards
Kai-Uwe Behrmann
+ development for color management
+ imaging / panoramas
+ email: ku...@gm...
+ http://www.behrmann.name
Am 03.10.05, 12:38 +0200 schrieb Kai-Uwe Behrmann:
> Hi,
>
> is there a example to get the real xy primaries from an given matrix
> profile, including white point adaption?
>
> regards
> Kai-Uwe Behrmann
> + development for color management
> + imaging / panoramas
> + email: ku...@gm...
> + http://www.behrmann.name
>
|
|
From: Hal V. E. <hv...@as...> - 2005-10-09 20:10:02
|
I would like to setup LPROF so that it will create vgct tabs in monitor profiles. I looked at the LCMS docs and it has nothing about vgct tags there so I am not sure where to begin. Does anyone here know anything about this? If so could you point me to sources of information about this to help me get started? Thanks, Hal |
|
From: Marti <ma...@li...> - 2005-10-14 17:57:31
|
Hi, > I looked at the LCMS docs and it has nothing about vgct tags lcms does currently NOT implement it because it is not on ICC spec. Alas, I'm a bit critical on such practices. Using this kind of stuff will make profiles "active" in the sense they are no longer a characterization of the hardware but a way to set specific configurations. I have seen many times desktops completely ruined by different software, each one trying to load its own vgct profile. Also, this is hardly non-portable and very hardware specific. The whole point of this tag is specify a set of curves for loading the hardware gamma ramp. But this puts hardware in "half way" since primaries are not modified at all, so the CMM has still some work to do. At that point I think this is useless, since non-color managed apps will continue displaying wrong colors and color-managed ones will continue processing the raster data. Exactly the same amount of work that doing all conversion, including gamma ramp. Some people would argue its is better half color management that nothing at all, but at that point the topic is no longer on color management, so let's forgot the whole stuff. I have added the tag signature in lcms.h, but quite probably this is all the support 1.15 will include. Regards -- Marti Maria The littlecms project. www.littlecms.com ----- Original Message ----- From: "Hal V. Engel" <hv...@as...> To: <lcm...@li...> Sent: Sunday, October 09, 2005 10:09 PM Subject: [Lcms-user] vgct tags >I would like to setup LPROF so that it will create vgct tabs in monitor > profiles. I looked at the LCMS docs and it has nothing about vgct tags > there so I am not sure where to begin. Does anyone here know anything about > this? If so could you point me to sources of information about this to help > me get started? > > Thanks, > > Hal > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > > > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.344 / Virus Database: 267.11.13/126 - Release Date: 09/10/2005 > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.12.0/134 - Release Date: 14/10/2005 |
|
From: Marti <ma...@li...> - 2005-10-10 16:54:38
|
Kai-Uwe, Just take the ICC profile as a black-box. The fact some profiles are implemented as matrix-shaper should be irrelevant. If you understand primaries as the chromaticity of colorants, obtaining the primaries should be as easy as using an absolute colorimetric transform from the given profile to XYZ space, and then obtaining the XYZ value of each colorant. This will work on all colorspaces, not only on RGB. Regards, -- Marti Maria The littlecms project. www.littlecms.com ----- Original Message ----- From: "Kai-Uwe Behrmann" <ku...@gm...> To: "Lcms Liste" <lcm...@li...> Sent: Thursday, October 06, 2005 8:01 PM Subject: Re: [Lcms-user] ICC profiles -> primaries > Hi, > > even in danger to repeat this toppic, here comes my own take: > > The primaries stored in the rXYZ,gXYZ and bXYZ tags are part of the > RGB<->XYZ conversion matrix. They are related to D50. > The whitepoint in wtpt represents the original whitepoint of the media. > > To convert from D50 primaries to oroginal wtpt primaries the chad tag was > introduced. It holdes the conversion matrix to come from D50 primaries to > wtpt primaries. > > Additional the chromaticity (chrm) tag, natively being in wtpt, can be > used to hold the origin in the profile. > > Without knowing the chromaticities (chrm) or the transform (chad) > conversion is guessing of the right transform. Bradford is a good > candidate. > > The good news, now I understand it, the chrm tag is included by lcms > during RGB matrix profile generation. Thanks! > > regards > Kai-Uwe Behrmann > + development for color management > + imaging / panoramas > + email: ku...@gm... > + http://www.behrmann.name > > > Am 03.10.05, 12:38 +0200 schrieb Kai-Uwe Behrmann: > >> Hi, >> >> is there a example to get the real xy primaries from an given matrix >> profile, including white point adaption? >> >> regards >> Kai-Uwe Behrmann >> + development for color management >> + imaging / panoramas >> + email: ku...@gm... >> + http://www.behrmann.name >> > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > > > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.344 / Virus Database: 267.11.13/126 - Release Date: 09/10/2005 > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.13/126 - Release Date: 09/10/2005 |
|
From: Kai-Uwe B. <ku...@gm...> - 2005-10-11 16:38:01
|
Marti,
thanks for the hint.
An other question comes to my mind:
for the absolute intent you need to guess, when chrm or chad are absent?
Or how does you find out the original primaries, which are lost during the
Wtpt->D50 transformation?
regards
Kai-Uwe Behrmann
+ development for color management
+ imaging / panoramas
+ email: ku...@gm...
+ http://www.behrmann.name
Am 10.10.05, 18:54 +0200 schrieb Marti:
>
> Kai-Uwe,
>
> Just take the ICC profile as a black-box. The fact some profiles
> are implemented as matrix-shaper should be irrelevant.
>
> If you understand primaries as the chromaticity of colorants,
> obtaining the primaries should be as easy as using an absolute colorimetric
> transform from the given profile to XYZ space, and then obtaining the XYZ
> value of each colorant. This will work on all colorspaces,
> not only on RGB.
>
> Regards,
> --
> Marti Maria
> The littlecms project.
> www.littlecms.com
>
>
>
>
>
> ----- Original Message ----- From: "Kai-Uwe Behrmann" <ku...@gm...>
> To: "Lcms Liste" <lcm...@li...>
> Sent: Thursday, October 06, 2005 8:01 PM
> Subject: Re: [Lcms-user] ICC profiles -> primaries
>
>
> > Hi,
> >
> > even in danger to repeat this toppic, here comes my own take:
> >
> > The primaries stored in the rXYZ,gXYZ and bXYZ tags are part of the
> > RGB<->XYZ conversion matrix. They are related to D50. The whitepoint in
> > wtpt represents the original whitepoint of the media.
> > To convert from D50 primaries to oroginal wtpt primaries the chad tag was
> > introduced. It holdes the conversion matrix to come from D50 primaries to
> > wtpt primaries.
> >
> > Additional the chromaticity (chrm) tag, natively being in wtpt, can be
> > used to hold the origin in the profile.
> >
> > Without knowing the chromaticities (chrm) or the transform (chad)
> > conversion is guessing of the right transform. Bradford is a good
> > candidate.
> >
> > The good news, now I understand it, the chrm tag is included by lcms
> > during RGB matrix profile generation. Thanks!
> >
> > regards
> > Kai-Uwe Behrmann
> > + development for color management +
> > imaging / panoramas
> > + email: ku...@gm...
> > + http://www.behrmann.name
> >
> >
> > Am 03.10.05, 12:38 +0200 schrieb Kai-Uwe Behrmann:
> >
> > > Hi,
> > >
> > > is there a example to get the real xy primaries from an given matrix
> > > profile, including white point adaption?
> > >
> > > regards
> > > Kai-Uwe Behrmann
> > > + development for color management +
> > > imaging / panoramas
> > > + email: ku...@gm...
> > > + http://www.behrmann.name
> > >
> >
|
|
From: Marti <ma...@li...> - 2005-10-14 18:10:33
|
Hi Kai-Uwe. chad applies only to illuminant, so it depends on which kind of profile. On printer profiles, no chromatic adaptation is assumed. On Display profiles, lcms uses a sort of linear Bradford (same as sRGB). Works well on most workspace profiles. Regards, -- Marti Maria The littlecms project. www.littlecms.com ----- Original Message ----- From: "Kai-Uwe Behrmann" <ku...@gm...> To: "Marti" <ma...@li...> Cc: "Lcms Liste" <lcm...@li...> Sent: Tuesday, October 11, 2005 6:37 PM Subject: Re: [Lcms-user] ICC profiles -> primaries > Marti, > > thanks for the hint. > > An other question comes to my mind: > for the absolute intent you need to guess, when chrm or chad are absent? > > Or how does you find out the original primaries, which are lost during the > Wtpt->D50 transformation? > > > regards > Kai-Uwe Behrmann > + development for color management > + imaging / panoramas > + email: ku...@gm... > + http://www.behrmann.name > > > > Am 10.10.05, 18:54 +0200 schrieb Marti: > >> >> Kai-Uwe, >> >> Just take the ICC profile as a black-box. The fact some profiles >> are implemented as matrix-shaper should be irrelevant. >> >> If you understand primaries as the chromaticity of colorants, >> obtaining the primaries should be as easy as using an absolute colorimetric >> transform from the given profile to XYZ space, and then obtaining the XYZ >> value of each colorant. This will work on all colorspaces, >> not only on RGB. >> >> Regards, >> -- >> Marti Maria >> The littlecms project. >> www.littlecms.com >> >> >> >> >> >> ----- Original Message ----- From: "Kai-Uwe Behrmann" <ku...@gm...> >> To: "Lcms Liste" <lcm...@li...> >> Sent: Thursday, October 06, 2005 8:01 PM >> Subject: Re: [Lcms-user] ICC profiles -> primaries >> >> >> > Hi, >> > >> > even in danger to repeat this toppic, here comes my own take: >> > >> > The primaries stored in the rXYZ,gXYZ and bXYZ tags are part of the >> > RGB<->XYZ conversion matrix. They are related to D50. The whitepoint in >> > wtpt represents the original whitepoint of the media. >> > To convert from D50 primaries to oroginal wtpt primaries the chad tag was >> > introduced. It holdes the conversion matrix to come from D50 primaries to >> > wtpt primaries. >> > >> > Additional the chromaticity (chrm) tag, natively being in wtpt, can be >> > used to hold the origin in the profile. >> > >> > Without knowing the chromaticities (chrm) or the transform (chad) >> > conversion is guessing of the right transform. Bradford is a good >> > candidate. >> > >> > The good news, now I understand it, the chrm tag is included by lcms >> > during RGB matrix profile generation. Thanks! >> > >> > regards >> > Kai-Uwe Behrmann >> > + development for color management + >> > imaging / panoramas >> > + email: ku...@gm... >> > + http://www.behrmann.name >> > >> > >> > Am 03.10.05, 12:38 +0200 schrieb Kai-Uwe Behrmann: >> > >> > > Hi, >> > > >> > > is there a example to get the real xy primaries from an given matrix >> > > profile, including white point adaption? >> > > >> > > regards >> > > Kai-Uwe Behrmann >> > > + development for color management + >> > > imaging / panoramas >> > > + email: ku...@gm... >> > > + http://www.behrmann.name >> > > >> > > > > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.344 / Virus Database: 267.11.13/126 - Release Date: 09/10/2005 > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.12.0/134 - Release Date: 14/10/2005 |
|
From: Hal V. E. <hv...@as...> - 2005-10-10 16:29:01
|
On Sunday 09 October 2005 05:46 pm, Graeme Gill wrote: > Hal V. Engel wrote: > > I would like to setup LPROF so that it will create vgct tabs in monitor > > profiles. I looked at the LCMS docs and it has nothing about vgct tags > > there so I am not sure where to begin. Does anyone here know anything > > about this? If so could you point me to sources of information about > > this to help me get started? > > icclib supports vgct tags - see <http://www.argyllcms.com/icclibsrc.html> > and look for "VideoCardGamma" in icc.c and *.h. > > Graeme Gill. Graeme, Great that helps allot. I don't really want to use two libraries to get this all working but at the present time lcms has no direct support for vcgt tags. Perhaps Marti would consider adding this support? The XCalib has a patch for lcms that allows reading the vcgt data. But does not have anything related to creating them. In anycase I think I have enough to start looking at this. Thanks, Hal |
|
From: Hal V. E. <hv...@as...> - 2005-10-11 16:49:43
|
I notice that lcms 1.15 has defined the vcgt tag (version 1.14 does not) but the documentation does not list vcgt as one of the implemented tags. So I am wondering if the documentation is correct or if version 1.15 has support for adding a vcgt tag to a profile. On Monday 10 October 2005 09:29 am, Hal V. Engel wrote: > On Sunday 09 October 2005 05:46 pm, Graeme Gill wrote: > > Hal V. Engel wrote: > > > I would like to setup LPROF so that it will create vgct tabs in monitor > > > profiles. I looked at the LCMS docs and it has nothing about vgct > > > tags there so I am not sure where to begin. Does anyone here know > > > anything about this? If so could you point me to sources of > > > information about this to help me get started? > > > > icclib supports vgct tags - see <http://www.argyllcms.com/icclibsrc.html> > > and look for "VideoCardGamma" in icc.c and *.h. > > > > Graeme Gill. > > Graeme, > > Great that helps allot. I don't really want to use two libraries to get > this all working but at the present time lcms has no direct support for > vcgt tags. > > Perhaps Marti would consider adding this support? The XCalib has a patch > for lcms that allows reading the vcgt data. But does not have anything > related to creating them. > > In anycase I think I have enough to start looking at this. > > Thanks, > > Hal > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user |
|
From: Graeme G. <gr...@ar...> - 2005-10-15 00:11:13
|
Marti wrote: > lcms does currently NOT implement it because it is not on ICC spec. > Alas, I'm a bit critical on such practices. Using this kind of stuff will > make profiles "active" in the sense they are no longer a characterization > of the hardware but a way to set specific configurations. You're quite right about this. vgct is not the correct approach to calibration. What should happen is that the profile should contain the desired device response in the outputResponseTag, and some separate system should calibrate the hardware to make sure it meets the expected response for a given display profile. This provides a mechanism to track device drift. Unfortunately we're stuck with software systems that expect the vgct tag to be present (Apple systems won't load the profile if the tag is missing), even though it no longer captures all the settings of a modern display system, such as the monitor controls etc., and is the wrong information to store in a profile .... Graeme Gill. |
|
From: Kai-Uwe B. <ku...@gm...> - 2005-10-15 08:01:17
|
Marti and Graeme,
thanks for sharing your thoughts.
I cc to OpenICC, as the vcgt in littleCMS reading may be of interesst
there too.
More below I write about the Genereal aspect of this particular issue.
The original thread is partitial included at bottom.
a practical view:
yesterday I showed some jpegs from a digital camera to friends. I opened
gqview, a popular image browser under linux, and could see the images
there in wrong colours. I draged them all to CinePaint to view them colour
managed. My X setup loads automatically the vcgt in a monitor profile from
a (minimalistic) hardware database.
Currently, as in CinePaint is no reading of the monitor profile in X atom,
I must enshure myself the profiles match. Even with setting the profile
from a central configuration this is not shure, as it may get changed
during runtime. This incompletenes is probably the point you make here.
On the other side the decoration looks with vcgt much more neutral. I have
allmost all decorations set to some shade of gray. The appearence is more
balanced.
Now my point, and possibly the one of Hal, here is, currently
the majority of desktops suffer from uncalibrated 8-bit LUT capable
graficcard/monitor combinations. The vcgt enshures a minimum of
calibration. It is mostly like an linearised printer. No one want missing
it, even being not in a final (profiled) state.
The same applies for printer and other devices. They lack in allmost any
case driver specific information, which is worse as it make the profiles
in an high degree application dependent and opaque to most other
applications. This is worst case to an open minded environment.
Generally:
Vcgt is one step to add more of the hardware configuration information
to one place - the profile. My doubt is the current ICC approach prohibits
inclusion of more hardware information to make the configuration complete.
This is due to the non changing policy of many profilers expressed in
copyrights.
As I understand, Microsoft will differ to osX in the way to set up
things, as well as Linux will. The ICC did not try to cover such
differences under one cover. If we find a way to include Linux OS
specifics into the profile I would like to support it.
Option A
is we have to create an meta format covering the hardware configuration +
the unchangeable profile. As I see it all OSes goes currently that way.
Option B
is device profiles could have an general configuration tag
containing:
o driver identifier (which every application can eighter understand or
reject the whole profile)
o a set of options specific to that driver
This enshures an application knows if it is capable to handle a certain
profile. And the application knows how to talk to the driver with a
specified configuration set (including profile) or can look up a
suitable profile by given options.
I know this is something technical. And most users want to stay with a
configuration and dont change it once it works. The difficulty I see here
is, this sheme is too static.
Further I have to look at the outputResponseTag Graeme mentions below.
regards
Kai-Uwe Behrmann
+ development for color management
+ imaging / panoramas
+ email: ku...@gm...
+ http://www.behrmann.name
Am 15.10.05, 10:11 +1000 schrieb Graeme Gill:
> Marti wrote:
>
> > lcms does currently NOT implement it because it is not on ICC spec.
> > Alas, I'm a bit critical on such practices. Using this kind of stuff will
> > make profiles "active" in the sense they are no longer a characterization
> > of the hardware but a way to set specific configurations.
>
> You're quite right about this. vgct is not the correct approach
> to calibration. What should happen is that the profile should
> contain the desired device response in the outputResponseTag,
> and some separate system should calibrate the hardware to
> make sure it meets the expected response for a given display
> profile. This provides a mechanism to track device drift.
>
> Unfortunately we're stuck with software systems that expect
> the vgct tag to be present (Apple systems won't load the
> profile if the tag is missing), even though it no longer
> captures all the settings of a modern display system, such
> as the monitor controls etc., and is the wrong information
> to store in a profile ....
>
> Graeme Gill.
>
|
|
From: <co...@do...> - 2005-10-15 12:35:35
|
Please see my comments on these tags inline. > yesterday I showed some jpegs from a digital camera to friends. I opened > gqview, a popular image browser under linux, and could see the images > there in wrong colours. I draged them all to CinePaint to view them colour > managed. My X setup loads automatically the vcgt in a monitor profile from > a (minimalistic) hardware database. > On the other side the decoration looks with vcgt much more neutral. I have > allmost all decorations set to some shade of gray. The appearence is more > balanced. this is exactly the great advantage of a corrected LUT: every application benefits. And as long, as these applications simply assume a defined state (which will most likely be sRGB), it's an elegant way to do it. I think, the main point for the invention was, that MacOS did always hold the profiles for all apps and the OS, so there's no application that will need access to this information except the OS, which applies the calibration data and sets the corresponding profile as the default monitor profile. > Am 15.10.05, 10:11 +1000 schrieb Graeme Gill: >> Marti wrote: >> >> > lcms does currently NOT implement it because it is not on ICC spec. >> > Alas, I'm a bit critical on such practices. Using this kind of stuff will >> > make profiles "active" in the sense they are no longer a characterization >> > of the hardware but a way to set specific configurations. >> >> You're quite right about this. vgct is not the correct approach >> to calibration. What should happen is that the profile should >> contain the desired device response in the outputResponseTag, >> and some separate system should calibrate the hardware to >> make sure it meets the expected response for a given display >> profile. This provides a mechanism to track device drift. >> >> Unfortunately we're stuck with software systems that expect >> the vgct tag to be present (Apple systems won't load the >> profile if the tag is missing), even though it no longer >> captures all the settings of a modern display system, such >> as the monitor controls etc., and is the wrong information >> to store in a profile .... I have to add a very important item: The profiles, created with ProfileMaker, basicccolor display, Monaco, ... do include the vcgt and are not containing valid device characterization if the vcgt is not taken into account. This does mean, that an ICC-lib should support vcgt tags, as they are required to correctly apply the data of these profiles (which are most likely the majority). On the other hand, this does mean, that this information belongs somehow to the profile. I must admit, that it's not right to include the actual calibration data instead of the desired device response. Oh, and becaus of this I would vote for vcgt support in LCMS to support these legacy profiles (and operating systems ;-) Stefan -- Stefan Döhla mailto:co...@do... |
|
From: Kai-Uwe B. <ku...@gm...> - 2005-10-15 15:25:55
|
Am 15.10.05, 14:36 +0200 schrieb Stefan D=C3=B6hla:
> I have to add a very important item: The profiles, created with
> ProfileMaker, basicccolor display, Monaco, ... do include the vcgt and
> are not containing valid device characterization if the vcgt is not
> taken into account. This does mean, that an ICC-lib should support
This is an OS issue. Independent of an CMM.
> vcgt tags, as they are required to correctly apply the data of
> these profiles (which are most likely the majority).
Again an OS issue. The profile attached to an screenshot image is=20
completely valid in the sense of the ICC spec. Why would someone need the=
=20
linearisation data of an printer, With the Cmyk ICC profile a separated=20
image is completely described, as it can be converted to pcs.
> On the other hand, this does mean, that this information belongs
> somehow to the profile. I must admit, that it's not right to include
> the actual calibration data instead of the desired device response.
My impression is, the profilers do embedd a device response information=20
due to the lack of standardisation.
I hope to come up soon with an draft about an file format, suitable to=20
include both ICC compliant information and device configuration=20
information. I need it in Oyranos as devices are not solved.
> Oh, and becaus of this I would vote for vcgt support in LCMS to
> support these legacy profiles (and operating systems ;-)
regards
Kai-Uwe Behrmann
+ development for color management=20
+ imaging / panoramas
+ email: ku...@gm...
+ http://www.behrmann.name
|
|
From: <co...@do...> - 2005-10-17 17:58:05
|
>> I have to add a very important item: The profiles, created with >> ProfileMaker, basicccolor display, Monaco, ... do include the vcgt and >> are not containing valid device characterization if the vcgt is not >> taken into account. This does mean, that an ICC-lib should support > This is an OS issue. Independent of an CMM. >> vcgt tags, as they are required to correctly apply the data of >> these profiles (which are most likely the majority). > Again an OS issue. The profile attached to an screenshot image is > completely valid in the sense of the ICC spec. Why would someone need the > linearisation data of an printer, With the Cmyk ICC profile a separated > image is completely described, as it can be converted to pcs. What I wanted to say is simply: You should not ignore these tags completely, since they are accidentaly very powerful. E.g. changing the whitepoint with a vcgt tag is fairly easy, so don't apply it and all data contained in the profile is invalid. You are right in terms: it's the responsibility of the OS to apply these changes. But there's no better/cleaner way for now to say that certain calibration data lead to a certain profile (at least it's the impression when looking at all the commercial profilers). Stefan -- Stefan Döhla mailto:co...@do... |
|
From: Greg S. <gre...@co...> - 2005-10-18 06:18:48
|
I too would like LCMS to support monitor calibration. (although I don't = care how and where it stores the calibration data - just as long as there is = a means to load the data into the graphics card)=20 Having said this I understand the reasons why it doesn't, and may never support calibration. But it'd be nice. :) :) Greg. -----Original Message----- From: lcm...@li... [mailto:lcm...@li...] On Behalf Of Stefan = D=F6hla Sent: Tuesday, 18 October 2005 03:51 To: Lcms Liste Subject: Re: [Lcms-user] Re: [Lcms-user][OpenICC] vgct tags >> I have to add a very important item: The profiles, created with >> ProfileMaker, basicccolor display, Monaco, ... do include the vcgt = and >> are not containing valid device characterization if the vcgt is not >> taken into account. This does mean, that an ICC-lib should support > This is an OS issue. Independent of an CMM. >> vcgt tags, as they are required to correctly apply the data of >> these profiles (which are most likely the majority). > Again an OS issue. The profile attached to an screenshot image is=20 > completely valid in the sense of the ICC spec. Why would someone need = the > linearisation data of an printer, With the Cmyk ICC profile a = separated > image is completely described, as it can be converted to pcs. What I wanted to say is simply: You should not ignore these tags completely, since they are accidentaly very powerful. E.g. changing the whitepoint with a vcgt tag is fairly easy, so don't apply it and all data contained in the profile is invalid. You are right in terms: it's the responsibility of the OS to apply these changes. But there's no better/cleaner way for now to say that certain calibration data lead to a certain profile (at least it's the impression when looking at all the commercial profilers). Stefan --=20 Stefan D=F6hla mailto:co...@do... ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, = discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Lcms-user mailing list Lcm...@li... https://lists.sourceforge.net/lists/listinfo/lcms-user |
|
From: Hal V. E. <hv...@as...> - 2005-11-21 20:34:36
|
I'm pleased to announce that version 1.11.0 of LPROF is now available. LPROF is an open source application that will create ICC profiles for use with other applications such as Scribus, CinePaint, Krita, UFRAW and the development version of GIMP. This is the first development snap shot of the work that has been underway since LPROF became a SourceForge project. Please see the LPROF SourceForge web pages http://sourceforge.net/projects/lprof This is a development snap shot of what will become version 1.12 when it is stable. Although testing by the development team indicates that this snap shot appears to be stable it is a development release and as such it should not considered to be a stable release. It has not been extensively tested and may have significant unknown bugs. This is being made available so that users can test the new release and report problems and make suggestions for improvements. The major goals of this version are: 1.Consolidation of the user interface into a single executable to facilitate an improved and simplified work flow. 2.Elimination or a major reduction of duplicate code to facilitate maintenance and future enhancements. 3.Use of a standardized location for storing configuration information. 4.Improved documentation and the addition of a help system. 5.Increased portability. Significant changes in this version include: 1.A unified user interface with a greatly simplified work flow. 2.The user interface and logic for placing the IT8.7 picker template has been hugely improved and will now work for skewed chart images that would have been impossible to use with the old picker template positioning user interface. The user interface is also much simpler to use. 3.A new help system has been implemented and new documentation written for the help system. This includes information on how to use this version of LPROF and there is also has a section on how to create profiles for use with UFRAW. 4.The charts for setting monitor gamma in the rough monitor profiler are now the Norman Koren gamma charts. These are being used with the permission of Norman Koren. These new charts will also help users set the black point for their monitors. See http://www.normankoren.com/makingfineprints1A.html for more information about these charts. 5.LPROF now uses system standard locations for saving and locating profiles by default. On Linux/Unix systems profiles will be saved to $HOME/.color/icc and when looking for profiles it will look in /usr/share/color/icc if these directories exist. On Windows systems it will use the default Windows directory for ICC profiles (normally c: \Windows\system32\spool\drivers\color). Users can specify other locations. 6.LPROF configuration and temporary files are now stored in $HOME/.lprof. 7.On Linux systems SCons is now used as the build system. The SCons build is not currently working on Windows or other platforms. 8.The library used to support tiff IT8.7 target images has been changed from QTiffIO to TiffIO for increased portability (QTiffIO does not build on Windows). LPROF can be built and will run without this library installed but it will not support the use of tiff files unless this library is installed. 9. A new target reference file installer has been added. This installs target reference files in a standard location and also requires the user to select the correct picker template when installing a new target reference file. LPROF will automatically use the specified picker template when ever the user selects a target reference file in the Camera/Scanner Profiler tab. 10.A significant amount of work has been done on Windows portability issues and most of the features are working on Windows systems. 11.Some work has been done to insure that this will run on big-endian systems. This code still needs to be tested. (The development team only has access to little-endian hardware). 12.A bunch of other bug fixes and improvements. Please feel free to download, build, install and test the development snap shot. User feedback is very much appreciated. In addition, LPROF could use your help in other ways and we are looking for volunteers to handle various tasks. For example, I would really like to have someone work on getting the Windows SCons build working correctly and there are many other areas where we could use additional help. Many of the things that need to be done are non-technical so even those that do not have a technical back ground can contribute. Please contact me if you would like to get involved in this effort in any way. |
