Thread: [Lcms-user] Embedded profile and ColorSpace tag
An ICC-based CMM for color management
Brought to you by:
mm2
From: Frédéric M. <fre...@gb...> - 2008-04-20 10:18:16
|
Hello, Geeqie (Gqview fork) developpers are doing really a great job. They added a complete color management support, but we have some behaviour questions... I suggested them to first get and use the embedded profile, if it exists, as source profile. Then, if no profile is embedded, use ColorSpace or InteropIndex tags. And if nothing is defined, or if tags does not set any valid color space (values other than 1 or 2 for ColorSpace, for example), use sRGB. Do you think it is the good way? In case of inconsistant situation (embbeded profile does no match tag), the embbeded profile will be used. Is is correct? Thanks for your suggestions, -- Frédéric http://www.gbiloba.org |
From: Glenn W. <gw...@pa...> - 2008-04-23 20:15:35
|
Hi Im hoping someone can help me, Im converting an CMYK colour via perceptual rendering intent to a printer colour, in this case its 6 colour printer (CMYK+2Spots) What I need to do is find an RGB colour that results in the same Printer Colour using Perceptual and Relative Colourmetric intents. This means I need to perform a reverse Lookup from the Printers Colour to RGB. Did I mention im using a Visual basic Class I wrote to interface with lcms.dll but can't directly access the internal procedures of Lcms? Currently Im doing a B2A transform then testing all combinations of RGB within a range to find the closest match. (Slow and not 100% accurate) Glenn Wilton |
From: Glenn W. <gw...@pa...> - 2008-04-24 00:23:23
|
Thanks Mike I think I need to clarify what im trying to acheive. Im actually printing with a 6 colour inkjet printer using disperse dyes with profiles i have made. The Gamut of disperse dyes is about 70% of standard CMYK except where we use spot colours. Therefore the RIP is setup using Perceptual Rendering intent. This is 'safe' but not good for spot matching. Since I need to match Spot colours accurately you would think I would use Relative Colourmetric intent. However I often have images and vectors that must use the same intent or they would look different. (ie Flattened PDF's) So I cant set vector to Relative Colorumetric and Raster to Perceptual. The way we solve this at the moment is to choose an RGB colour from a test print which is usually has a much stronger chroma than the resulting spot, However with Perceptual compression it will print accurately. This is a manual process of looking up colours on charts. My first email was a little inaccurate. What I would like to do is convert a CMYK/Lab colour via Relative Colourmetric intent to the printer profile, The resulting 6 colour formula is my 'ideal match'. However since the RIP is using Perceptuial Intent I need to do a reverse lookup to find an RGB colour which when convered RGB>Perceptual>Printer will give me the same 6 colour formula. I use RGB has a bigger gamut and gives room to compresate for perceptual compression. One consideration is that both Perceptual and Relative Colorumetric may not produce the same 'formulas' At the moment I calcualte a close RGB colour then iterate through a few thousand combinations to find the cloest match. What I would like to do is perform a reverse A2B lookup but NOT a B2A lookup as the printers B2A table only uses 5 data points vs the 33 datapoints for the A2B Table. Tricky? Glenn Mike Russell wrote: >> Hi Im hoping someone can help me, >> >> Im converting an CMYK colour via perceptual rendering intent to a >> printer colour, in this case its 6 colour printer (CMYK+2Spots) >> >> What I need to do is find an RGB colour that results in the same Printer >> Colour using Perceptual and Relative Colourmetric intents. This means I >> need to perform a reverse Lookup from the Printers Colour to RGB. >> >> Did I mention im using a Visual basic Class I wrote to interface with >> lcms.dll but can't directly access the internal procedures of Lcms? >> >> Currently Im doing a B2A transform then testing all combinations of RGB >> within a range to find the closest match. (Slow and not 100% accurate) > > Considering only the CMYK part of your problem, Create a transform > that uses your RGB profile as the source, and something like the SWOP > v2 transform for CMYK, and do a direct conversion. It will be > lightning fast. You will get somewhat brighter colors using Relative > Colorimetric intent instead of Perceptual. > > Re adding the two spot colors, this been done already with hexachrome > and hifi color. Use their inks and profiles, and you'll get a better > result than rolling your own. If you do step outside the hexachrome > inks, spot colors are not the same as a process inks. Some of them > are more opaque, for example, and mixing them will produce > unpredictable results. To predict what the screened versions will > look like, you must do your own measurements of various combinations > of the six colors screened together. If you do that, pick spot colors > that are reasonably transparent. > > Stepping back a bit from your question, instead of doing a six color > job, pay a professional to do the conversions and perhaps use better > stock. This will look better, even in four colors, than an automated > conversion to hexachrome. Post your question to a printing oriented > group, such as comp.publish.prepress for advice > > Mike Russell - www.curvemeister.com > |
From: Mike R. <gr...@cu...> - 2008-04-25 23:50:08
|
From: "Glenn Wilton" <gw...@pa...> > Thanks Mike > > I think I need to clarify what im trying to acheive. > Im actually printing with a 6 colour inkjet printer using disperse dyes > with profiles i have made. The Gamut of disperse dyes is about 70% of > standard CMYK except where we use spot colours. Therefore the RIP is setup > using Perceptual Rendering intent. This is 'safe' but not good for spot > matching. OK. > Since I need to match Spot colours accurately you would think I would use > Relative Colourmetric intent. For Spot color matching only, I would consider abscol, which preserves the white of the source color space. > However I often have images and vectors that must use the same intent or > they would look different. (ie Flattened PDF's) So I cant set vector to > Relative Colorumetric and Raster to Perceptual. > The way we solve this at the moment is to choose an RGB colour from a test > print which is usually has a much stronger chroma than the resulting spot, > However with Perceptual compression it will print accurately. This is a > manual process of looking up colours on charts. Another possibility would be to print the same test print on fabric and match the spot color directly from that. This would save a lot of steps and give a visually accurate result, which profiles are not going to do.. > My first email was a little inaccurate. What I would like to do is convert > a CMYK/Lab colour via Relative Colourmetric intent to the printer profile, > The resulting 6 colour formula is my 'ideal match'. Gotcha. > However since the RIP is using Perceptuial Intent I need to do a reverse > lookup to find an RGB colour which when convered RGB>Perceptual>Printer > will give me the same 6 colour formula. I use RGB has a bigger gamut and > gives room to compresate for perceptual compression. One consideration is > that both Perceptual and Relative Colorumetric may not produce the same > 'formulas' So, in effect you want to "overdrive" the preceptual intent conversion, so that it ends up with the same color you would have gotten, had been able to set the RIP to relcol. > At the moment I calcualte a close RGB colour then iterate through a few > thousand combinations to find the cloest match. Simulating a B2A lut, using something like a linear search of the A2B LUT or some such in VB. > What I would like to do is perform a reverse A2B lookup but NOT a B2A > lookup as the printers B2A table only uses 5 data points vs the 33 > datapoints for the A2B Table. Did you consider regenerating the B2A by inverting the A2B LUT? I believe there is an argyll command line utility by Graeme Gill that does exactly this. Lcms will then allow you to concatenate transforms ad infinitum, so you could create what amounts to a device profile that converts from your original RGB color, to your "disperse relcol" , identity transform back to Lab, and from there to "disprese preceptual". Once the transform is set up, you use it like any other transform. Another thought would be to modify the profile used by the RIP. Replace the perceptial LUT with the relcol LUT. > Tricky? Yes, basically you have to turn carwheels to get around the perceptual intent of the RIP. Your task would be infinitely simpler and more accurate if there were no conversion in the RIP at all, and you could provide a 6 channel image, one per jet. Which leads me to a couple of words about how I would do this. The profile method described above, while mathmatically sound, won't really work well. This is because mathmatical compromises were made to match the patches that were used to generate the printer profile. Those patches, in turn, were different from the spot colors you are interested in. The end result will be a poor match to many of your spot colors. To better match the spot colors, if the number of them is not onerous, I wouldn't use profiles for preparing the input color values. Instead I would individually target each spot color as follows. First, I would print your RGB test image via the RIP, and use the swatch book to manually match each color using a light source that closely matches the final viewing conditions. Then reate a test image that contained a swatch for each spot color, print it, and verify that each swatch matches it counterpart in the swatch book reasonably well. Then I would tweak the RGB values of the swatch colors that were still significantly off until they were acceptably close. Lather, rinse, repeat. After you have a good visual match for each of the swatches, use a spectrophotometer to record these printed values, and convert them to CIELAB D50. The D50 illuminant is not critical but it is the widest standard. These measurements are not used to generate the input swatch values, but they can be used for process control. If the images are photographs that include spot colors, then I would add additional "pseudo spot" colors for neutral gray, a skin tone, foliage, and other important colors in your images. For each image to be printed, check each spot color manually, including the hue (not brightness) of each pseudo spot color, and use curves to set it to the value from the swatch image. If the number of images is large, I would use the same curve on all of them, or have several curves, one for each category of image. Mike Russell - www.curvemeister.com |
From: Glenn W. <gw...@pa...> - 2008-04-26 01:08:03
|
The way we solve this at the moment is to choose an RGB colour from a test >> print which is usually has a much stronger chroma than the resulting spot, >> However with Perceptual compression it will print accurately. This is a >> manual process of looking up colours on charts. >> > > Another possibility would be to print the same test print on fabric and > match the spot color directly > from that. This would save a lot of steps and give a visually accurate > result, which profiles are not going to do. > This is basically what we do, I have an RGB colour chart printed on Fabric, We then use an Spectromter to measure the charts and find the RGB colour with the lowest Delta-E, In Effect an Absolute Colorimetric Match. The results are recorded in a Database for future use, The Problem is with so many different fabrics this is a time consuming process that could be automated. > So, in effect you want to "overdrive" the preceptual intent conversion, so > that it ends up with the same color you would have gotten, had been able to > set the RIP to relcol. > Thats right, I want to find an RGB colour that when printed via a peceptural intent gives me the right spot match. > there is an argyll command line utility by Graeme Gill that does exactly > this. Lcms will then allow you to concatenate transforms ad infinitum, so > you could create what amounts to a device profile that converts from your > original RGB color, to your "disperse relcol" , identity transform back to > Lab, and from there to "disprese preceptual". Once the transform is set up, > you use it like any other transform. > Thats Mike, I will look up Argyll. This may work as it avoids the low resolution B2A table. > Another thought would be to modify the profile used by the RIP. Replace the > perceptial LUT with the relcol LUT. > I can just set this on the RIP, But then I end up with the problem of the colours clipping again in RelCol. > Yes, basically you have to turn carwheels to get around the perceptual > intent of the RIP. Your task would be infinitely simpler and more accurate > if there were no conversion in the RIP at all, and you could provide a 6 > channel image, one per jet > I would love to do this, But it would basically involve making my own Colour managed Postscript RIP less the print driver. No small task. Even Ghostscript only has basic support for ICC profiles. If only my RIP had decent support for modifying Named Spot Colours reliably. > First, I would print your RGB test image via the RIP, and use the swatch > book to manually match each color using a light source that closely matches > the final viewing conditions. Then reate a test image that contained a > swatch for each spot color, print it, and verify that each swatch matches it > counterpart in the swatch book reasonably well. Then I would tweak the RGB > values of the swatch colors that were still significantly off until they > were acceptably close. Lather, rinse, repeat. > Thats a lot of time ... Perhaps something I can delegate an apprentice can do. :-) > If the images are photographs that include spot colors, then I would add > additional "pseudo spot" colors for neutral gray, a skin tone, foliage, and > other important colors in your images. For each image to be printed, check > each spot color manually, including the hue (not brightness) of each pseudo > spot color, and use curves to set it to the value from the swatch image. If > the number of images is large, I would use the same curve on all of them, or > have several curves, one for each category of image. > Thanks for your help Mike. One other option I was just thinking about is to print out all the RGB colours in 17 steps and measure them, Something like 4913 swatches. Then build a high resolution Lab>RGB lookup table. This is a little beyond me at the moment however this process sounds a lot like creating a profile - I could use the AbsCol intent especially if the PCS of the Profile is D50. So what options are there for creating such a High Resolution RGB Profile which had a High Res B2A table? If so I guess I would simply create a LabD50 > RGB Transform? Glenn |
From: Gerhard F. <nos...@gm...> - 2008-04-27 13:00:01
|
Glenn Wilton wrote: > One other option I was just thinking about is to print out all the RGB > colours in 17 steps and measure them, Something like 4913 swatches. > Then build a high resolution Lab>RGB lookup table. This is a little > beyond me at the moment however this process sounds a lot like > creating a profile - I could use the AbsCol intent especially if the > PCS of the Profile is D50. So what options are there for creating such > a High Resolution RGB Profile which had a High Res B2A table? If so I > guess I would simply create a LabD50 > RGB Transform? Basically you can characterize your perceptual RGB to print transformation chain with a normal RGB ICC profile; i.e. print a RGB characterization chart (with not too few patches), measure the printed samples, and run the profiler to create the profile [in the same way as you would create a RGB printer profile for a RGB driven printer under Windows]. IMO there is nothing special. (But eventually this is double profiling, and whenever you rebuild your printer profile, you would need to build a new RGB profile as well.) -Gerhard |
From: Gerhard F. <nos...@gm...> - 2008-04-26 12:14:56
|
Glenn Wilton wrote: > What I would like to do is perform a reverse A2B lookup but NOT a B2A lookup as the printers B2A table only uses 5 data points vs the 33 datapoints for the A2B Table. > The command command "xicclu -fif ..." from Argyll CMS can do reverse A2B lookups. But note, in case of a CMYK color space [or in case of any device color space with more than three color components], the result of a A2B reverse lookup is not unique, but there may exist an infinite number of different CMYK combinations, which all result in the same color, when printed. Also keep in mind, that spot colors with higher saturation may be out of gamut on your medium, particularly if the gamut is small, as you said. And your B2A tables really have only 5 grid points? Couldn't you build them with higher resolution? (But basically I agree, that the accuracy of B2A table generally suffers more or less, since the grid points of the B2A table need to cover the whole CIELAB space (even the regions outside the visual gamut), while the A2B table only needs to cover the device gamut, which is only a fraction of the whole CIELAB gamut. An exception are certainly multicolor profiles, which cannot use too many A2B grid points, otherwise they would become too large). Regards, Gerhard |
From: Kai-Uwe B. <ku...@gm...> - 2008-04-24 04:49:22
|
The steps to handle CM for images in a viewing applciation are outlined in a small use case study: https://www.oyranos.org/wiki/index.php?title=Oyranos/Use_Cases It is somewhat Oyranos centric as a place for interapplication settings. In sumary: * embedded profile - use it, if not * EXIF - use it, if not * ask a device profile data base, if no result * ask user peferences for popping up a dialog and handle, if not popping * ask user preferences, what to assign (for Rgb), if no result * use sRGB for displaying, dont embedd for this case kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org Am 20.04.08, 12:17 +0200 schrieb Frédéric Mantegazza: > Geeqie (Gqview fork) developpers are doing really a great job. They added a > complete color management support, but we have some behaviour questions... > > I suggested them to first get and use the embedded profile, if it exists, > as source profile. Then, if no profile is embedded, use ColorSpace or > InteropIndex tags. And if nothing is defined, or if tags does not set any > valid color space (values other than 1 or 2 for ColorSpace, for example), > use sRGB. > > Do you think it is the good way? In case of inconsistant situation > (embbeded profile does no match tag), the embbeded profile will be used. > Is is correct? > > Thanks for your suggestions, |
From: Frédéric M. <fre...@gb...> - 2008-04-24 19:43:01
|
On jeudi 24 avril 2008, Kai-Uwe Behrmann wrote: > The steps to handle CM for images in a viewing applciation are outlined > in a small use case study: > https://www.oyranos.org/wiki/index.php?title=Oyranos/Use_Cases > It is somewhat Oyranos centric as a place for interapplication settings. > > In sumary: > * embedded profile - use it, if not > * EXIF - use it, if not > * ask a device profile data base, if no result > * ask user peferences for popping up a dialog and handle, if not popping > * ask user preferences, what to assign (for Rgb), if no result > * use sRGB for displaying, dont embedd for this case Thanks! -- Frédéric http://www.gbiloba.org |