Thread: [Lcms-user] Confused about cmsCreateMultiprofileTransform error
An ICC-based CMM for color management
Brought to you by:
mm2
Menu
▾
▴
lcms-user
|
From: Steve M. <sm...@mu...> - 2008-05-07 15:11:25
|
I'm in the midst of adding lcms support to our portable code. The Mac build already uses ColorSync, built on semiportable classes that the portable code can talk to. Our app is a page layout app. The user can choose the printer and proofer profiles. When graphics or colors are colormatched to screen via ColorSync, we build a CMWorldRef with anywhere from 2 to 4 profiles: 1. Input profile, which is the user-selected rgb or cmyk profile for colors, the default OS xyz profile for Pantone colors, or a profile embedded in a graphic (rgb, cmyk, grey, or Lab). 2. Printer profile (optional) 3. Proofer profile (optional) 4. Monitor profile. In my first test after adding support for lcms, I'm getting "cmsCreateMultiprofileTransform: ColorSpace mismatch" from line 1935 in cmsCreateMultiprofileTransform. I'm building the xform with the same list of profiles as we would when using ColorSync (although they're in cmsHPROFILE format of course). The profiles for this test are an embedded rgb profile, a cmyk printer profile, and the rgb monitor profile. What could be the problem here? Failure to understand how cmsCreateMultiprofileTransform should be used, or lack of an equivalent function in lcms like I use with ColorSync? _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com |
|
From: Steve M. <sm...@mu...> - 2008-05-08 23:23:44
|
On May 7, 2008, at 10:11:01, Steve Mills wrote: > I'm in the midst of adding lcms support to our portable code. The Mac > build already uses ColorSync, built on semiportable classes that the > portable code can talk to. Our app is a page layout app. The user can > choose the printer and proofer profiles. When graphics or colors are > colormatched to screen via ColorSync, we build a CMWorldRef with > anywhere from 2 to 4 profiles: > > 1. Input profile, which is the user-selected rgb or cmyk profile for > colors, the default OS xyz profile for Pantone colors, or a profile > embedded in a graphic (rgb, cmyk, grey, or Lab). > 2. Printer profile (optional) > 3. Proofer profile (optional) > 4. Monitor profile. > > In my first test after adding support for lcms, I'm getting > "cmsCreateMultiprofileTransform: ColorSpace mismatch" from line 1935 > in cmsCreateMultiprofileTransform. I'm building the xform with the > same list of profiles as we would when using ColorSync (although > they're in cmsHPROFILE format of course). The profiles for this test > are an embedded rgb profile, a cmyk printer profile, and the rgb > monitor profile. What could be the problem here? Failure to understand > how cmsCreateMultiprofileTransform should be used, or lack of an > equivalent function in lcms like I use with ColorSync? Hello? Anyone around? _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com |
|
From: Alastair M. R. <bla...@fa...> - 2008-05-09 00:15:22
|
Hi,
>> In my first test after adding support for lcms, I'm getting
>> "cmsCreateMultiprofileTransform: ColorSpace mismatch" from line 1935
>> in cmsCreateMultiprofileTransform. I'm building the xform with the
>> same list of profiles as we would when using ColorSync (although
>> they're in cmsHPROFILE format of course). The profiles for this test
>> are an embedded rgb profile, a cmyk printer profile, and the rgb
>> monitor profile. What could be the problem here? Failure to understand
>> how cmsCreateMultiprofileTransform should be used, or lack of an
>> equivalent function in lcms like I use with ColorSync?
Well, reading the API documentation for
cmsCreateMultiprofileTransform(), I see:
- Colorspaces must be paired with the exception of
Lab/XYZ, that can be interchanged.
So I guess that means you can't directly create an RGB -> CMYK (->CMYK)
-> RGB transform with this function.
What you probably could do is create the individual stages of your
transform with cmsCreateTransform(), convert these transforms to
DeviceLinks with cmsTransform2DeviceLink(), and then chain the
devicelinks together using cmsCreateMultiprofileTransform().
In practice, you're prebably better off using this only for the case
where you need four profiles - and using cmsCreateTransform when you
have two, and cmsCreateProofingTransform() when you have three.
Hope this helps
--
Alastair M. Robinson
|
|
From: Steve M. <sm...@mu...> - 2008-05-09 13:08:14
|
On May 8, 2008, at 19:15:12, Alastair M. Robinson wrote: > Well, reading the API documentation for > cmsCreateMultiprofileTransform(), I see: > - Colorspaces must be paired with the exception of > Lab/XYZ, that can be interchanged. > So I guess that means you can't directly create an RGB -> CMYK (- > >CMYK) > -> RGB transform with this function. The api comment didn't make any sense to me. Paired how? (rhetorical) > What you probably could do is create the individual stages of your > transform with cmsCreateTransform(), convert these transforms to > DeviceLinks with cmsTransform2DeviceLink(), and then chain the > devicelinks together using cmsCreateMultiprofileTransform(). > > In practice, you're prebably better off using this only for the case > where you need four profiles - and using cmsCreateTransform when you > have two, and cmsCreateProofingTransform() when you have three. I'll give that a shot. Seems like a lot of work and a lot of extra objects to keep track of and delete. ColorSync's CWConcatColorWorld is a much more elegant model. I'll submit a suggestion that lcms also get similar functionality added. _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com |
|
From: Marti.Maria <mar...@li...> - 2008-05-09 07:19:15
|
Hi, CreateMultiprofileTransform needs colorspaces to match between profiles. So, if you use Input, printer, monitor, You are connecting the profiles in this way: RGB -> Input -> Lab - > Printer -> CMYK -> *Monitor* When reaching the monitor, space is CMYK and since the profile is RGB that is an error. What you probably want is a softproof chain, which is Input, Printer, Printer, Monitor RGB -> Input -> Lab - > Printer -> CMYK -> Printer -> Lab -> Monitor -> RGB But be careful with that because you need mixed intent in order to do the right proof. I suggest to use cmsCreateProofingTransform instead Regards Marti Maria The littleCMS project www.littlecms.com -----Original Message----- From: lcm...@li... [mailto:lcm...@li...] On Behalf Of Steve Mills Sent: Wednesday, May 07, 2008 5:11 PM To: lcms-user Subject: [Lcms-user] Confused about cmsCreateMultiprofileTransform error I'm in the midst of adding lcms support to our portable code. The Mac build already uses ColorSync, built on semiportable classes that the portable code can talk to. Our app is a page layout app. The user can choose the printer and proofer profiles. When graphics or colors are colormatched to screen via ColorSync, we build a CMWorldRef with anywhere from 2 to 4 profiles: 1. Input profile, which is the user-selected rgb or cmyk profile for colors, the default OS xyz profile for Pantone colors, or a profile embedded in a graphic (rgb, cmyk, grey, or Lab). 2. Printer profile (optional) 3. Proofer profile (optional) 4. Monitor profile. In my first test after adding support for lcms, I'm getting "cmsCreateMultiprofileTransform: ColorSpace mismatch" from line 1935 in cmsCreateMultiprofileTransform. I'm building the xform with the same list of profiles as we would when using ColorSync (although they're in cmsHPROFILE format of course). The profiles for this test are an embedded rgb profile, a cmyk printer profile, and the rgb monitor profile. What could be the problem here? Failure to understand how cmsCreateMultiprofileTransform should be used, or lack of an equivalent function in lcms like I use with ColorSync? _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao ne _______________________________________________ Lcms-user mailing list Lcm...@li... https://lists.sourceforge.net/lists/listinfo/lcms-user |
|
From: Steve M. <sm...@mu...> - 2008-05-09 13:03:11
|
On May 9, 2008, at 02:18:26, Marti.Maria wrote: > CreateMultiprofileTransform needs colorspaces to match between > profiles. > So, if you use > > Input, printer, monitor, > > You are connecting the profiles in this way: > > RGB -> Input -> Lab - > Printer -> CMYK -> *Monitor* > > When reaching the monitor, space is CMYK and since the profile is > RGB that > is an error. So this function is not analogous to the ColorSync model of creating a color world (a transform) by simply giving it the list of profiles in order. That's too bad. > What you probably want is a softproof chain, which is > > Input, Printer, Printer, Monitor > > RGB -> Input -> Lab - > Printer -> CMYK -> Printer -> Lab -> Monitor > -> RGB > > But be careful with that because you need mixed intent in order to > do the > right proof. The user can supply the intent between each profile. > I suggest to use cmsCreateProofingTransform instead cmsCreateProofingTransform only accepts 3 profiles. What do I do with the 4th? _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com |
|
From: Marti.Maria <mar...@li...> - 2008-05-09 14:14:35
|
>So this function is not analogous to the ColorSync model of creating a >color world (a transform) by simply giving it the list of profiles in >order. That's too bad. Right, lcms is not a ColorSync clone. But many people has managed to get same functionality. It is certainly possible to implement it without too much effort. Lcms gives you more flexibility, but requires more detail from your part. Linking 4 profiles "as is" is not possible in any case, just because the connection spaces are not compatible. Somehow a profile should be duplicated in order to get it working. ColorSync does it automatically, lcms requires you to specify which profile to duplicate. > The user can supply the intent between each profile. No. At least not in lcms cmsCreateMultiprofileTransform, which forces you a single intent. This is not intrinsically bad, as mixing intents makes no sense in all but softproofing scenarios. >cmsCreateProofingTransform only accepts 3 profiles. What do I do with the 4th? Do you need proofer AND monitor combined? Why? If you really need 4 profiles (because abstract profiles, etc) you may consider using cmsTrasform2Devicelink, but I would not recommend to use that unless really needed, because may result in loss of accuracy. Maybe just using cmsCreateMultiprofileTransform and specifying the printer profile twice would solve the problem. All the best Marti Maria The littleCMS project www.littlecms.com -----Original Message----- From: lcm...@li... [mailto:lcm...@li...] On Behalf Of Steve Mills Sent: Friday, May 09, 2008 3:03 PM To: lcms-user lcms-user Subject: Re: [Lcms-user] Confused about cmsCreateMultiprofileTransform error On May 9, 2008, at 02:18:26, Marti.Maria wrote: > CreateMultiprofileTransform needs colorspaces to match between > profiles. > So, if you use > > Input, printer, monitor, > > You are connecting the profiles in this way: > > RGB -> Input -> Lab - > Printer -> CMYK -> *Monitor* > > When reaching the monitor, space is CMYK and since the profile is > RGB that > is an error. So this function is not analogous to the ColorSync model of creating a color world (a transform) by simply giving it the list of profiles in order. That's too bad. > What you probably want is a softproof chain, which is > > Input, Printer, Printer, Monitor > > RGB -> Input -> Lab - > Printer -> CMYK -> Printer -> Lab -> Monitor > -> RGB > > But be careful with that because you need mixed intent in order to > do the > right proof. The user can supply the intent between each profile. > I suggest to use cmsCreateProofingTransform instead cmsCreateProofingTransform only accepts 3 profiles. What do I do with the 4th? _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao ne _______________________________________________ Lcms-user mailing list Lcm...@li... https://lists.sourceforge.net/lists/listinfo/lcms-user |
|
From: Steve M. <sm...@mu...> - 2008-05-09 19:25:29
|
On May 9, 2008, at 09:12:54, Marti.Maria wrote: >> The user can supply the intent between each profile. > > No. At least not in lcms cmsCreateMultiprofileTransform, which > forces you a > single intent. > This is not intrinsically bad, as mixing intents makes no sense in > all but > softproofing scenarios. I meant the user can choose the intent that goes between each profile in our UI. They can choose the intent that comes after the input profile, after the printer profile, and after the proofer profile. Since cmsCreateMultiprofileTransform doesn't provide a place to provide these intents, I assumed lcms would use the intent currently set in each profile at each step. When the user sets the intent in the UI, we set that intent in the profile object. > Do you need proofer AND monitor combined? Why? Yes, I need the monitor profile because I'm color matching to the screen, as stated in my original message. This might be "soft proofing". > If you really need 4 profiles > (because abstract profiles, etc) you may consider using > cmsTrasform2Devicelink, but I would not recommend to use that unless > really > needed, because may result in loss of accuracy. > Maybe just using cmsCreateMultiprofileTransform and specifying the > printer > profile twice would solve the problem. Can you explain why the printer profile would be given twice? Would the proofer profile also need to be given twice? E.g. input->printer- >printer->proofer->proofer->monitor? _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com |
|
From: Marti.Maria <mar...@li...> - 2008-05-10 14:14:57
|
Hi, >I meant the user can choose the intent that goes between each profile >in our UI. They can choose the intent that comes after the input >profile, after the printer profile, and after the proofer profile. Ok, that makes sense. However, this is not currently implemented in lcms. Only one intent is allowed in multiprofile transforms and two intents are allowed in proofing transforms. Of course you can do it by yourself, using low-level functions. I guess 100-200 lines of code would be enough. The trick is to generate one transform per intent and then join them together using cmsSample3DGrid. Take a look on the source code of cmsCreateMultiprofileTransform, file is cmsxform.c, you need something like the MultiprofileSampler. > Yes, I need the monitor profile because I'm color matching to the > screen, as stated in my original message. This might be "soft proofing". Ok, this is the point of cmsCreateProofingTransform(), you specify the input profile, the profile for the device you are going to simulate, printer in this case, and the profile for the device to render the simulation, a monitor in this case. That is 3 profiles. On the other hand you may want to use a different printer to do the proof, so then you use the proofer profile instead of monitor. That's still 3 profiles. >Can you explain why the printer profile would be given twice? Would >the proofer profile also need to be given twice? E.g. input->printer- > >printer->proofer->proofer->monitor? Is just a matter of matching colorspaces. Profiles may work in both directions Lab -> Colorspace and Colorspace -> Lab, then any multiprofile transform should have compatible colorspaces in the joints. Tahe for example a sRGB as input, a CMYK printer and a monitor as proofer (RGB) If I try to join together in a multiprofile transform, I can join sRGB and the printer since both have Lab as connection point: RGB - [sRGB ICC] - Lab - [CMYK Printer] - CMYK But please note the connexion point now is in CMYK space, so I cannot put a RGB monitor there. The Monitor profile has either RGB or Lab connexions, but no CMYK. So I need to get Lab or RGB to plug monitor profile. I can do that by using the printer profile twice: RGB - [sRGB ICC] - Lab - [CMYK Printer] - CMYK - [CMYK Printer] - Lab - [Monitor RGB] -> RGB So far so good. But this is not only because mechanical reasons, putting the profile twice means something. And in fact this is the "proofing" stage. In the first part, Lab to CMYK, the printer profile is used in the output direction. This is the same as if it were used in normal workflow. It is giving the native CMYK for the target printer. That is the workflow to be proofed. Then we need to know the colorimetry of those CMYK, and this is the reason of using the output profile in the reverse direction. The AToB direction is something like an "embedded spectrophotometer" in the profile. It can "measure" the CMYK values out to Lab. Then we have to convert those Lab to the proofing device, a monitor in this case. If we use a proofer printer instead of monitor, all remains same, but instead of monitor we have to use the proofer profile. RGB - [sRGB ICC] - Lab - [CMYK Printer] - CMYK - [CMYK Printer] - Lab - [Proofer CMYK] -> CMYK Then comes the intents. The first one is the intent used in the workflow you want to proof, which may be any. For the "measurement" using reverse direction you need relative colorimetric (since white point does not change) and for the proofer the intent may be any, preferable relative or absolute colorimetric. That is: two intents selectable by the user, as the "measurement" part should be relative colorimetric to work. And this is how cmsCreateProofingTransform works. Hope this helps All the best Marti Maria The littleCMS project www.littlecms.com -----Original Message----- From: lcm...@li... [mailto:lcm...@li...] On Behalf Of Steve Mills Sent: Friday, May 09, 2008 4:24 PM To: lcms-user lcms-user Subject: Re: [Lcms-user] Confused about cmsCreateMultiprofileTransform error On May 9, 2008, at 09:12:54, Marti.Maria wrote: >> The user can supply the intent between each profile. > > No. At least not in lcms cmsCreateMultiprofileTransform, which > forces you a > single intent. > This is not intrinsically bad, as mixing intents makes no sense in > all but > softproofing scenarios. I meant the user can choose the intent that goes between each profile in our UI. They can choose the intent that comes after the input profile, after the printer profile, and after the proofer profile. Since cmsCreateMultiprofileTransform doesn't provide a place to provide these intents, I assumed lcms would use the intent currently set in each profile at each step. When the user sets the intent in the UI, we set that intent in the profile object. > Do you need proofer AND monitor combined? Why? Yes, I need the monitor profile because I'm color matching to the screen, as stated in my original message. This might be "soft proofing". > If you really need 4 profiles > (because abstract profiles, etc) you may consider using > cmsTrasform2Devicelink, but I would not recommend to use that unless > really > needed, because may result in loss of accuracy. > Maybe just using cmsCreateMultiprofileTransform and specifying the > printer > profile twice would solve the problem. Can you explain why the printer profile would be given twice? Would the proofer profile also need to be given twice? E.g. input->printer- >printer->proofer->proofer->monitor? _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao ne _______________________________________________ Lcms-user mailing list Lcm...@li... https://lists.sourceforge.net/lists/listinfo/lcms-user |
|
From: Steve M. <sm...@mu...> - 2008-05-11 02:50:29
|
On May 10, 2008, at 09:14:19, Marti.Maria wrote: > Ok, that makes sense. However, this is not currently implemented in > lcms. > Only one intent is allowed in multiprofile transforms and two > intents are allowed in proofing transforms. > Of course you can do it by yourself, using low-level functions. I > guess 100-200 lines of code would be enough. The trick is to > generate one transform per intent and then join them together using > cmsSample3DGrid. > Take a look on the source code of cmsCreateMultiprofileTransform, > file is cmsxform.c, you need something like the MultiprofileSampler. That's a lot of code just to do something that ColorSync can do with 1 line. I'd rather not go down such a costly path. > Ok, this is the point of cmsCreateProofingTransform(), you specify > the input profile, the profile for the device you are going to > simulate, printer in this case, and the profile for the device to > render the simulation, a monitor in this case. That is 3 profiles. > On the other hand you may want to use a different printer to do the > proof, so then you use the proofer profile instead of monitor. > That's still 3 profiles. Printing to a proofer is one thing. Soft proofing to the monitor is another. The user can turn on the proofer profile so they can see *onscreen* how it will print to the proofer and still have the printer profile in the chain. Input->printer->proofer->monitor = 4 profiles. > And this is how cmsCreateProofingTransform works. Thanks for the detailed explanation of why the printer profile would need to be added twice. So since I *do* need 4 profiles, I can't use cmsCreateProofingTransform. Will I be able to interject an intent at each step if I were to go down the path of creating multiple xforms with cmsCreateTransform or cmsCreateProofingTransform and then convert those to linked profiles, then use those to create a final xform? _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com |
|
From: Kai-Uwe B. <ku...@gm...> - 2008-05-12 20:29:25
|
Am 09.05.08, 16:12 +0200 schrieb Marti.Maria: > Do you need proofer AND monitor combined? Why? If you really need 4 profiles > (because abstract profiles, etc) you may consider using > cmsTrasform2Devicelink, but I would not recommend to use that unless really > needed, because may result in loss of accuracy. > Maybe just using cmsCreateMultiprofileTransform and specifying the printer > profile twice would solve the problem. How can a quality lost for DL's be avoided or minimised by lcms? The lcms CMM for Oyranos relies on this feature very much for caching and so on. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org |
|
From: Steve M. <sm...@mu...> - 2008-05-16 13:48:02
|
On May 13, 2008, at 17:32:25, Steve Mills wrote: > OK, so now I'm trying to use cmsCreateProofingTransform and am > getting an error that the output format space does not match the > output profile's space. I don't understand why it's checking the > *output* profile's space against the output format space. Shouldn't > it check the *proofer* profile's space to make sure it matches the > output format space? The it goes input->output->proofer, right? > That's how I assume it would go. If I'm color matching to the > monitor, the output format space is rgb, but the output profile is > for a cmyk printer and the proofer profile is for the monitor. Nobody has an answer for this? Supplying the cmsFLAGS_SOFTPROOFING flag doesn't make any difference in this respect, but then I don't fully understand (nor do the docs explain) why the cmsFLAGS_SOFTPROOFING flag needs to be given, when the function is called cmsCreatePROOFINGTransform. _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com |
|
From: Frédéric <fre...@gb...> - 2008-05-16 14:08:23
|
Le 16/5/2008, "Steve Mills" <sm...@mu...> a écrit:
>Nobody has an answer for this? Supplying the cmsFLAGS_SOFTPROOFING
>flag doesn't make any difference in this respect, but then I don't
>fully understand (nor do the docs explain) why the
>cmsFLAGS_SOFTPROOFING flag needs to be given, when the function is
>called cmsCreatePROOFINGTransform.
>From TUTORIAL.TXT file, you can read:
NOTES: For activating the preview or gamut check features, you MUST
include the corresponding flags
cmsFLAGS_SOFTPROOFING
cmsFLAGS_GAMUTCHECK
This is done in such way because the user usually wants to compare
with/without softproofing. Then, you can share same code. If any of the
flags
is present, the transform does the proofing stuff. If not, the transform
ignores the proofing profile/intent and behaves like a normal
input-output
transform. In practical usage, you need only to associate the check
boxes of
"softproofing" and "gamut check" with these flags.
Hope this helps.
|
|
From: Steve M. <sm...@mu...> - 2008-05-16 14:42:54
|
On May 16, 2008, at 09:08:06, Frédéric wrote: > From TUTORIAL.TXT file, you can read: Ah, I didn't check there, since a "tutorial" is used to show one how to use something, not to *explain* the API. That's what I'd expect from a file named LCMSAPI.TXT. I'm still looking for an answer about why the output format space is being checked against the output profile space and not the proofer profile space. _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com |
|
From: Marti M. <mar...@li...> - 2008-05-16 14:57:51
|
This is the entry in LCMSAPI.TXT for cmsCreateProofingTransform:
------------
Same as cmsCreateTransform(), but including soft-proofing. The
obtained transform emulates the device described by the
"Proofing" profile. Useful to preview final result whithout
rendering to physical medium.
Parameters and returns same as anterior, but with the addition of
Proofing: a handle to proofing profile.
ProofingIntent: Is the intent for translating emulated
colors. Default is
INTENT_ABSOLUTE_COLORIMETRIC.
dwFlags:
cmsFLAGS_GAMUTCHECK: Color out of gamut are flagged to a
fixed color defined by the function
cmsSetAlarmCodes(int r, int g, int b);
cmsFLAGS_SOFTPROOFING: (Does need preview tag to work) does
emulate the Proofing device.
You need to add a combination of these flags to enable any proof!
-------------
So, it goes input -> Proofed device -> Output. You can call proofer to the
output device if you prefer to do that.
See my other post on multiprofile transforms for more details
Regards
Marti Maria
The littleCMS project
www.littlecms.com
-----Original Message-----
From: lcm...@li...
[mailto:lcm...@li...] On Behalf Of Steve Mills
Sent: Friday, May 16, 2008 4:42 PM
To: lcms-user lcms-user
Subject: Re: [Lcms-user] Confused about cmsCreateMultiprofileTransform error
On May 16, 2008, at 09:08:06, Frédéric wrote:
> From TUTORIAL.TXT file, you can read:
Ah, I didn't check there, since a "tutorial" is used to show one how
to use something, not to *explain* the API. That's what I'd expect
from a file named LCMSAPI.TXT.
I'm still looking for an answer about why the output format space is
being checked against the output profile space and not the proofer
profile space.
_________________________________________________________
Steve Mills Me: 952-401-6255
Senior Software Architect MultiAd
sm...@mu... www.multi-ad.com
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user
|
|
From: Steve M. <sm...@mu...> - 2008-05-16 15:13:56
|
On May 16, 2008, at 09:56:46, Marti Maria wrote: > So, it goes input -> Proofed device -> Output. You can call proofer > to the > output device if you prefer to do that. > See my other post on multiprofile transforms for more details Well that certainly seems confusing, or at least it does when coming from the ColorSync world, and given the order of the parameters. So in this case, I'd provide the printer profile as the "prooferProfile" and the monitor profile as the "outputProfile"? _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com |
|
From: Frédéric M. <fre...@gb...> - 2008-05-16 16:21:17
|
On vendredi 16 mai 2008, Steve Mills wrote: > Well that certainly seems confusing, or at least it does when coming > from the ColorSync world, and given the order of the parameters. So in > this case, I'd provide the printer profile as the "prooferProfile" and > the monitor profile as the "outputProfile"? Yes, that's it. I also made the mistake ;o) -- Frédéric http://www.gbiloba.org |
|
From: Steve M. <sm...@mu...> - 2008-05-21 14:58:00
|
On May 8, 2008, at 19:15:12, Alastair M. Robinson wrote: > What you probably could do is create the individual stages of your > transform with cmsCreateTransform(), convert these transforms to > DeviceLinks with cmsTransform2DeviceLink(), and then chain the > devicelinks together using cmsCreateMultiprofileTransform(). I've had time to get back to handling a 4-profile transform and have run into a problem. I'll start with the profiles in use in my test case, in this order: profs[0] = input (rgb) profs[1] = printer (cmyk) profs[2] = proofer (cmyk) profs[3] = monitor (rgb) I first create 2 xforms, one for input -> printer, and another for proofer -> monitor. xform1 = cmsCreateTransform(profs[0], fromFormat, profs[1], lcmsSpace2lcmsFormat(cmsGetColorSpace(profs[1]), true, bytesPerChannel), cmsTakeRenderingIntent(profs[0]), 0); xform2 = cmsCreateTransform(profs[2], lcmsSpace2lcmsFormat(cmsGetColorSpace(profs[2]), true, bytesPerChannel), profs[3], toFormat, cmsTakeRenderingIntent(profs[2]), 0); Note that fromFormat is the format for the input data used with the input profile, and toFormat is the format for the output data used with the monitor profile. What I might be getting wrong here are the other 2 formats; xform1's output format, and xform2's input format. Does my code look correct for those? The xforms are then converted to device link profiles: link1 = cmsTransform2DeviceLink(xform1, 0); link2 = cmsTransform2DeviceLink(xform2, 0); And the final xform is created from those: xform = cmsCreateMultiprofileTransform(links, 2, fromFormat, toFormat, cmsTakeRenderingIntent(profs[1]), 0); The end result is that I get error "Invalid PCS" when GetPhase is called on the link2 profile - it's icSigRgbData. How do I fix this? If I instead call: xform = cmsCreateTransform(link1, fromFormat, link2, toFormat, cmsTakeRenderingIntent(profs[1]), 0); which I did just as a test, I get the error "Device link is operating on wrong colorspace on output" for link1. _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com |
|
From: Case, I. <Isa...@xe...> - 2008-05-21 16:11:08
|
Sorry for coming in on this much later, but what exactly are you trying to do? It looks like you're trying to softproof what rgb prints from the proofer would look like, if the proofer was emulating the printer. Is that correct? Isaac Case Software Engineer PCDT Color Workflow Team Xerox Corporation p 585.265.5472 > -----Original Message----- > From: lcm...@li... [mailto:lcms-user- > bo...@li...] On Behalf Of Steve Mills > Sent: Wednesday, May 21, 2008 10:58 AM > To: lcms-user lcms-user > Subject: Re: [Lcms-user] Confused about cmsCreateMultiprofileTransform > error > > On May 8, 2008, at 19:15:12, Alastair M. Robinson wrote: > > > What you probably could do is create the individual stages of your > > transform with cmsCreateTransform(), convert these transforms to > > DeviceLinks with cmsTransform2DeviceLink(), and then chain the > > devicelinks together using cmsCreateMultiprofileTransform(). > > > I've had time to get back to handling a 4-profile transform and have > run into a problem. I'll start with the profiles in use in my test > case, in this order: > > profs[0] = input (rgb) > profs[1] = printer (cmyk) > profs[2] = proofer (cmyk) > profs[3] = monitor (rgb) > > I first create 2 xforms, one for input -> printer, and another for > proofer -> monitor. > > xform1 = cmsCreateTransform(profs[0], fromFormat, profs[1], > lcmsSpace2lcmsFormat(cmsGetColorSpace(profs[1]), true, > bytesPerChannel), cmsTakeRenderingIntent(profs[0]), 0); > xform2 = cmsCreateTransform(profs[2], > lcmsSpace2lcmsFormat(cmsGetColorSpace(profs[2]), true, > bytesPerChannel), profs[3], toFormat, > cmsTakeRenderingIntent(profs[2]), 0); > > Note that fromFormat is the format for the input data used with the > input profile, and toFormat is the format for the output data used > with the monitor profile. What I might be getting wrong here are the > other 2 formats; xform1's output format, and xform2's input format. > Does my code look correct for those? > > The xforms are then converted to device link profiles: > > link1 = cmsTransform2DeviceLink(xform1, 0); > link2 = cmsTransform2DeviceLink(xform2, 0); > > And the final xform is created from those: > > xform = cmsCreateMultiprofileTransform(links, 2, fromFormat, toFormat, > cmsTakeRenderingIntent(profs[1]), 0); > > The end result is that I get error "Invalid PCS" when GetPhase is > called on the link2 profile - it's icSigRgbData. How do I fix this? > > If I instead call: > > xform = cmsCreateTransform(link1, fromFormat, link2, toFormat, > cmsTakeRenderingIntent(profs[1]), 0); > > which I did just as a test, I get the error "Device link is operating > on wrong colorspace on output" for link1. > > _________________________________________________________ > Steve Mills Me: 952-401-6255 > Senior Software Architect MultiAd > sm...@mu... www.multi-ad.com > > > > ------------------------------------------------------------------------ - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user |
|
From: Steve M. <sm...@mu...> - 2008-05-21 16:17:12
|
On May 21, 2008, at 11:10:15, Case, Isaac wrote: > Sorry for coming in on this much later, but what exactly are you > trying > to do? > > It looks like you're trying to softproof what rgb prints from the > proofer would look like, if the proofer was emulating the printer. > > Is that correct? That sounds correct. We soft proof to the screen what the resulting document would look like when printed to a proofer, taking the printer into account. The input space can be rgb, cmyk, grey, xyz, or Lab. _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com |
|
From: Case, I. <Isa...@xe...> - 2008-05-21 20:06:17
|
I just made up a quick test to see if I understand how it works (where
p1 and p2 are two different cmyk profiles). Compiled and ran fine.
How is this different than what you're doing?
#include "lcms.h"
#include <stdio.h>
typedef struct _RGB_ {
BYTE r,g,b;
} RGB;
int main()
{
cmsHPROFILE srgb;
cmsHPROFILE p1,p2;
srgb = cmsCreate_sRGBProfile();
p1 = cmsOpenProfileFromFile("p1.icc","r");
p2 = cmsOpenProfileFromFile("p2.icc","r");
cmsHPROFILE proof[4];
proof[0] = srgb;
proof[1] = p1;
proof[2] = p2;
proof[3] = srgb;
cmsHTRANSFORM multi = cmsCreateMultiprofileTransform(proof,4,
TYPE_RGB_8,TYPE_RGB_8,
INTENT_RELATIVE_COLORIMETRIC,0);
RGB pix;
RGB outPix;
for( int i = 0; i < 256; i++ )
{
pix.r = pix.g = pix.b = i;
cmsDoTransform(multi,&pix, &outPix,1);
printf("%d %d %d -> %d %d %d\n",
pix.r,pix.g,pix.b,
outPix.r,outPix.g,outPix.b);
}
return 0;
}
Isaac Case
Software Engineer
PCDT Color Workflow Team
Xerox Corporation
p 585.265.5472
> -----Original Message-----
> From: lcm...@li... [mailto:lcms-user-
> bo...@li...] On Behalf Of Steve Mills
> Sent: Wednesday, May 21, 2008 12:17 PM
> To: lcms-user lcms-user
> Subject: Re: [Lcms-user] Confused about cmsCreateMultiprofileTransform
> error
>
> On May 21, 2008, at 11:10:15, Case, Isaac wrote:
>
> > Sorry for coming in on this much later, but what exactly are you
> > trying
> > to do?
> >
> > It looks like you're trying to softproof what rgb prints from the
> > proofer would look like, if the proofer was emulating the printer.
> >
> > Is that correct?
>
>
> That sounds correct. We soft proof to the screen what the resulting
> document would look like when printed to a proofer, taking the printer
> into account. The input space can be rgb, cmyk, grey, xyz, or Lab.
>
> _________________________________________________________
> Steve Mills Me: 952-401-6255
> Senior Software Architect MultiAd
> sm...@mu... www.multi-ad.com
>
>
>
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user
|
|
From: Steve M. <sm...@mu...> - 2008-05-21 20:17:06
|
On May 21, 2008, at 12:16:16, Case, Isaac wrote: > How is this different than what you're doing? Because you're calling cmsCreateMultiprofileTransform with 4 profiles with 1 rendering intent, and I'm calling it with 2 device link profiles with possibly different intents between each of the 4 original profiles. _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com |
|
From: Marti.Maria <mar...@li...> - 2008-05-23 14:38:18
|
Hi,
>That sounds correct. We soft proof to the screen what the resulting
>document would look like when printed to a proofer, taking the printer
>into account. The input space can be rgb, cmyk, grey, xyz, or Lab.
Ok, now I understand. This "double proofing" capability is not in the
LittleCMS library because patents.
If you want to implement this feature, a way may be to just create
abstract profiles for each emulation layer and link them
together with cmsMultiprofileTransform. You can create such abstract
profiles using _cmsComputeSoftProofLUT() and storing the lut in a
identity Lab profile.
hAbstract = cmsCreateLabProfile(NULL)
Lut = _cmsComputeSoftProofLUT(hProfileToProof, IntentToProof)
cmsAddTag(hAbstract, icSigAToB0Tag, Lut);
return hAbstract;
I have just typed this code without checking it. I think it may work.
> IsProperColorSpace is being called from
> CreateDeviceLinkTransform(p- >InputProfile,
> p->OutputFormat, TRUE). I want to make sure there
> isn't a typo in the lcms code and that should
> be sending p- >OutputProfile instead.
It is not a typo. Such transforms have only a profile and it is
placed in input. See what documentation says about:
"
For creating a device-link transform, you must open the device link
profile as usual, using cmsOpenProfileFromFile(). Then, create
the transform with the device link profile as input and the output
profile parameter equal to NULL:
hDeviceLink = cmsOpenProfileFromFile("MYDEVLINK.ICC", "r");
hTransform = cmsCreateTransform(hDeviceLink, TYPE_RGB_8,
NULL, TYPE_BGR_8,
INTENT_PERCEPTUAL,
0);
"
Regards
Marti
|
|
From: Kai-Uwe B. <ku...@gm...> - 2008-05-21 18:51:12
|
Am 21.05.08, 11:16 -0500 schrieb Steve Mills:
> On May 21, 2008, at 11:10:15, Case, Isaac wrote:
>
> > Sorry for coming in on this much later, but what exactly are you
> > trying
> > to do?
> >
> > It looks like you're trying to softproof what rgb prints from the
> > proofer would look like, if the proofer was emulating the printer.
> >
> > Is that correct?
>
>
> That sounds correct. We soft proof to the screen what the resulting
> document would look like when printed to a proofer, taking the printer
> into account. The input space can be rgb, cmyk, grey, xyz, or Lab.
If you want a chain like, you might want to look at CinePaint's sources as
a living example:
input[scanner,camera,image] profile ->
manipulation/effects profile(s) ->
simulation/proofing profile ->
local output[printer,display] profile
I have slightly changed the terminology to better fit what we do in
CinePaint.
Look at app/cms.c:cms_create_transform() .
I am about exporting the same functionality into the Oyranos library for a
more straight forward API, even though the lcms API is already nice.
The default transform engine in the Oyranos CMS will be almost based on
Lcms.
kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org
|
|
From: Steve M. <sm...@mu...> - 2008-05-21 20:12:31
|
On May 21, 2008, at 13:57:10, Kai-Uwe Behrmann wrote: > If you want a chain like, you might want to look at CinePaint's > sources as > a living example: > > input[scanner,camera,image] profile -> > manipulation/effects profile(s) -> > simulation/proofing profile -> > local output[printer,display] profile > > I have slightly changed the terminology to better fit what we do in > CinePaint. > > Look at app/cms.c:cms_create_transform() . > > I am about exporting the same functionality into the Oyranos library > for a > more straight forward API, even though the lcms API is already nice. > The default transform engine in the Oyranos CMS will be almost based > on > Lcms. I changed my code to call cmsCreateProofingTransform as the last step instead of creating a 2nd device link profile and creating the final xform with cmsCreateMultiprofileTransform. But I still get the same error "Device link is operating on wrong colorspace on output". In IsProperColorSpace, Space is PT_RGB, lUsePCS is true, and hProfile's cms is PT_CMYK. IsProperColorSpace is being called from CreateDeviceLinkTransform(p- >InputProfile, p->OutputFormat, TRUE). I want to make sure there isn't a typo in the lcms code and that should be sending p- >OutputProfile instead. _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multi-ad.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X