according to what I read (e.g. in Sharma’s new book) the tags A2B0, A2B1 and A2B2 specify lookup tables for the different rendering intents in an ICC profile. As far as I understand, this is a transformation from source colour space to destination colour space. But how can this transformation be specified at the time of profile generation when the destination colour space is not (yet) known (e.g. creating a scanner profile and use this later in RawTherapee to render the scans in a colour space of my choice or display them on the monitor)? Obviously I do not understand some fundamental issues on this topic.
Hi @Jossie - As you’ve already surmised, A2B tables - oh, wait, maybe that’s B2A, sorry, I don’t have much experience with making and using LUT profiles and the terms are easy to confuse .
Anyway, what I started to say was that when making a LUT destination profile such as a printer profile, you simply cannot know the color gamut of the source ICC profile. At the point of generation, the person making the profile must decide exactly what the presumed source color gamut is going to be. It might be:
the color gamut of a preselected source ICC profile.
the color gamut of a source image file (which itself is in some ICC profile color space, but consider that images seldom fill all of the color space they happen to be in).
a standardized source color gamut such as the ICC V4 spec’s PRMG (“Profile Reference Medium Gamut”)
But in your use case the scanner profile isn’t a destination profile, it’s a source/input profile, and there’s no law that says you must make a LUT profile. It can also be a shaper matrix profile, and so I think the only table that will matter if you make a LUT profile is the relative colorimetric table which doesn’t require knowing anything about any color gamut other than the scanner itself. But maybe I’m missing something, so take what I just said with a grain of salt:
thank you for your comments. I had read the Argyll documentation several times before but must say I still do not understand the issue.
I am talking about the source profile created for my scanner with an IT8-target. When the profile is created, nothing is know about the potential destination target, maybe it is the monitor, maybe the printer. Nevertheless profilers like SilverFast create the tags A2B0 … A2B2 for the various intents the user can choose from during rendering. My question is concerned with these profilers. How could one calculate the transformation without knowing the destination colour space?
NB: As pointed out by Sharma and others, it is quite common that the three tags A2B0 … A2B2 all point to the same data set in the profile. Sharma writes “Reusing tags can be done in all profile types and is efficient – it reduces file size – but the end user should appreciate that choosing a different rendering intent in such a profile will not make an difference to the processed data”. Very irritating!
With “ICC profile inspector” I see that Argyll always only creates the A2B0 (perceptual), although in the documentation it is stated that only the colorimetric table is created. This is the first confusion. Ignoring that I do not yet understand how to get the other intents from that with argyll. But this is another issue, I hope to solve once I understand the more fundamental question outlined above.
for Input, Display, and Output profiles the AToB tags convert from the device to the PCS, which will either be XYZ or LAB.
A scanner is an input profile. If the whole point of profiling your scanner is to get an accurate description of its actual color gamut, the only intent that’s relevant is the Colorimetric intent. Checking the ArgyllCMS colprof documentation:
For output profiles (which the scanner profile is not):
-s -S In order to generate perceptual and saturation intent B2A tables for output profiles, it is necessary to have something that defines what source gamut should be used to create the source to destination gamut mapping. [For more information on why a source gamut is needed, see About ICC profiles and Gamut Mapping]. The -S parameter is used to do this, and doing so causes perceptual and saturation tables to be generated. If only a perceptual intent is needed, then the -s flag can be used, and the saturation intent will use the same table as the perceptual intent.
For input profiles (which the scanner profile is):
Note that input profiles and matrix profiles will only contain a colorimetric intent table or matrix, and hence the -s and -S option is not relevant.
When making a LUT input (or output or display) profile, it’s required by the ICC that there be an AtoB0 tag. The other AtoB tags are optional. So if the scanner input profile only has one tag, it will be the AtoB0 tag. But for an input profile that tag will actually contain a relative colorimetric mapping, which is the only mapping that makes sense if you are trying to make a profile that describes the scanner’s actual color gamut.
If the scanner profile has all three AtoB tables, it seems to me that all three tables should be identical. Is this the case when using Silverfast to make the scanner profile?
@gwgill, hoping that what I wrote above is accurate - I should go look at my camera input LUT profile to see what actual tags are included - here is a related question that I’ve wanted to ask someone for a long time:
When using ArgyllCMS “cctiff” (cctiff) to convert a tiff or jpeg from one ICC profile to another ICC profile, it’s required to give the intent twice, once for the source profile and once again for the destination profile.
But in all the ICC profile color-managed editing applications that I’ve ever used, the user only gets to specify the conversion intent once, presumably from the source profile to the destination profile. Is this “one user-chosen intent” used for both profiles? Or is some other mechanism (perhaps looking at the header tags where an intent is stored?) used to determine the intent used for the source profile?
@Elle , okay, it makes sense to me if the A2B… tags only are for the transformation to the PCS. But this has, as far as I can see, nothing to do with the rendering intents. These come into play, when the scanned image is rendered e.g. into sRGB. Although the latter is a matrix profile and thus, according to what Graeme Gill wrote, only the colorimetric intents are applicable (I guess for mathematical reasons) . But this is not the issue since it should be possible to create also a LUT instead a matrix profile for sRGB. So in principle one should have the opportunity e.g. in RawTherapee or PhotoShop to choose one of the four rendering intents and see differences in the output. This is what I am aiming at: I just wanted to see with some examples the influence of the different rendering intents. There are examples printed in books, but I would like to get my own experience with my own images.
Well, you can’t make a LUT sRGB profile and still technically have the actual sRGB ICC profile as defined in the original sRGB ICC profile specs (or rather the closest we still have publicly available), which clearly describes making a matrix ICC profile.
But in the meantime, the ICC has come out with V4 LUT profiles that they call “sRGB” thus leading to untold confusion it seems to me. So here are links where you can get the new LUT sRGB profiles:
@Elle, of course the LUT sRGB will not be exactly according to the specs, but it could be as close as one would like. Graeme Gill (in an exchange on argyllcms-bounce@freelists.org) had given a rough outline on how to proceed to get an sRGB LUT but I did not have the time to try that out. There now also is the Rec2020 profile available which, as Sharma writes, should replace sRGB on the long run, and has a much larger gamut than sRGB.
I am just trying to understand all this in detail and create examples. Whereas Graeme Gill says, that for the scanner only the colorimetric intent makes sense, Sharma states that for images one should normally use the perceptual, which, however, does change the colours. So it should be up to the user and its images, which intent to use. This is just what I would like to find out for myself.
@Jossie - Maybe what you really want is to make a device-link ICC profile, to link your scanner input profile to your desired sRGB output profile. I’ve never done this, but see if this isn’t the sort of thing you want to do:
The LUT sRGB profile from color.org uses the PRMG as the source color gamut, which isn’t likly to be a close match your scanner’s color gamut.
Well, making a scanner input profile isn’t the same as dealing with output profiles. The claim that normally for images one should use perceptual intent is widely made, but there are two problems with this advice:
This advice completely ignores the fact that RGB color spaces of the sort we commonly use in the digital darkroom as RGB working spaces don’t have perceptual intent tables because they are matrix profiles. So asking for perceptual just gets you relative colorimetric, which clips, which might or might not change colors depending on the colors in the image as encoded in the source color space.
This advice completely ignores the fact that even if the destination profile is a LUT profile with all the tables, if the color gamut of the actual image is small enough, it might fit in the destination color space with little or no clipping, and using perceptual intent when you don’t need to does run the risk of excessively desaturating the resulting colors, and also runs the risk of clipping anyway if the source colors are very saturated, as LUT destination profiles do require specifying an input color gamut during the creation of the profile.
So using or not using perceptual intent depends first on whether there is a perceptual intent table in the destination profile. And depends second on whether resulting color changes are acceptable or even necessary.
One always has the option to soft proof the old-fashioned way, modifying the image while still in the source color space to look acceptably nice, before doing a relative colorimetric conversion (which both LUT and matrix profiles support) to the destination color space.
But for your use case and assuming I understand what device-link profiles do (again, I’ve never made or used one), it might make sense to also make a device-link profile from your scanner input profile to sRGB. And then use soft proofing if the resulting image isn’t acceptable in any given case.
thanks a lot for your clarification on the perpetual intent. As I said, I am at the beginning of the learning curve. I hope it will get steeper with time . One thing I will have to pick up again is the production of a LUT-based sRGB or AdobeRGB profile so I can really experiment with the intents.
I had already thought about device-link profiles and had an exchange with Graeme Gill about this. I created one but that was at the time, when PhotoShop did not understand these profiles. Now with PS CC it should work. What the situation with RawTherapee is, I have to find out.
It’s up to the profile maker. Input profiles can have perceptual and saturation tables, but what exactly that means, and how it interacts with the CMM and output profiles is unknown.
But in all the ICC profile color-managed editing applications that I’ve ever used, the user only gets to specify the conversion intent once, presumably from the source profile to the destination profile. Is this “one user-chosen intent” used for both profiles?
I’m pretty sure that the same intent is used for both profiles. It may be simpler, but its a whole lot less flexible, and (as the story was told to me) was one of factors that lead to the ICCV4 Display profiles dropping support for a real Absolute Colorimetric intent.
Large gamut spaces (like ProPhotoRGB or Rec.2020) introduce issues that are largely ignored when using smaller gamut spaces like sRGB. The issue is that with small gamut spaces you can get away with assuming that images fill the colorspace gamut, i.e. that the gamut of the space can be used as a proxy for the image gamut you wish to preserve. Often this is because an sRGB image has already been rendered to fill the space - i.e. created in sRGB space so that it fills the gamut, or for things like photo’s, compressed and clipped by the camera/RAW processing to fill the space.
To work properly with large gamut spaces, you have to pay attention to the gamuts of the images encoded in the space. The workflow is more complex, and currently is poorly supported by most tools.
Perhaps you can help me find the answer to my initial question.
The scanner profile created by the profiler from an IT8-target characterizes the response of the scanner + emulsion combination. The profiler creates the transformation (let me assume as a LUT for simplicity) from scanner colour space to PCS, which is stored in the tags A2B0 … A2B2 for the various intents. Here are my two questions:
What does the transformation scanner to PCS has to do with the rendering intents (specifying the A2Bxs)? I would have thought that the PCS is always the full (theoretically possible) colour space (XYZ or Lab) so there is no need for any rendering intent.
If the distinction between the A2Bxs does refer to the rendering intent when transforming from PCS to the output colour space (e.g. in my case rendering from PCS to, say, AdobeRGB, assuming it is a LUT, which normally is not the case, I am aware of this, but just for the sake of simplicity of the argument), how can this transform be specified by the profiler? At the time of profiling, the output colour space the user will choose later, is not yet known. This puzzles me for a long time.
The ICC format allows for different rendering intents in the A2B tables. The contents and operation of the non-colorimetric tables is Profiler specific.
The ICC spec. doesn’t cover this - it is Profiler specific. (The ICC format provides some mechanisms, it’s up to the Profiler how they are used.)
A hypothesis is that a Profile may attempt to do part of the gamut mapping in the A2B table, and part in the B2A table, perhaps mapping to and from an intermediate gamut. This is the use that the PRMG seems to be intended for.
As explained in the previous link, ArgyllCMS doesn’t work this way. Source profiles are colorimetric, and the user has to specify the source gamut when creating an output profile that will contain gamut mapping tables.
@gwgill I have a situation where I use ProPhoto as the working space, and I have an output profile in a smaller space to which I would like to add a perceptual rendering intent, so that it will compress from the ProPhoto gamut to this smaller output gamut (let’s say it’s sRGB). How would I add that perceptual mapping to this existing ICC output profile?
The only (ArgyllCMS) method that I know would work is similar to the explanation for making an sRGB cLUT profile - create a .ti1, use fakeread to create test patches, then re-create the profile using colprof and the gamut mapping you want.
But typically no-one wants to compress from a ProPhoto gamut - the compression would leave most images looking pretty bad. Instead you need to compress from something closer to the images gamut (i.e. see tiffgamut).
I’ve been following this thread like “a dog watching TV”, lots of pretty colors, but I have no idea what’s going on. However, your last post struck to the heart of something I’ve been doing, working in Rec2020 and transforming to sRGB for JPEG output. I do this with relative_colorimetric intent (in LittleCMS, if that’s pertinent), mainly because my profiles don’t have the requisite LUTs for perceptual. But, from your last post I’m gathering the compression of the full gamut range with perceptual is probably a poorer choice for large transforms like ProPhoto->sRGB than just letting relative_colorimetric deal with the edges of the receiving gamut. Or, doing something like ProPhoto->AdobeRGB->sRGB with perceptual intents?
I sometimes shoot in environments where extreme colors are problematic, like in theaters. So, I’m trying to develop a “mechanic’s” understanding of how to handle it, how to wrestle the available tools to accommodate. Anders Torger’s extensive dcamprof pages have been extremely helpful, but I’m trying to keep my toolset confined to ICC profiles right now.
Oh, keep writing at your grade level, so-to-speak; I’m really learning from your explanations. Thanks…
What’s happening when you use perceptual really depends on the profiles you are using. It could be that the perceptual tables aren’t compressing from the full ProPhoto gamut but from something smaller, meaning that the result is OK. Using colorimetric will certainly retain the colorfulness of the original image, but of course you will get clipping of anything out of (destination) gamut, so you may loose detail in those regions of the image.
Nothing is likely to beat a hand tuned rendering (with good tools) of an original image into a smaller gamut. The next step down in terms of quality vs ease is likely to be an automatically generated gamut mapping made specifically for an image (i.e. something like an image specific gamut mapping device link made using ArgyllCMS). Next step down would be a more generic device profile or device link from a gamut typical of the images you are dealing with. The bottom rung would be assuming a generic gamut like sRGB as the source to be preserved, or a generic type of gamut compression with a “knee” point set in the range of general image gamuts. Often the best approach is a bit of both - hand tuning the gross rendering, and then cleaning up the rest using an automatically generated gamut mapping using color management tools.
@gwgill
Good morning,
towards understanding of the ICC-profile content, I used the ICC Profile Inspector to look into a profile created with Argyll. Unfortunately the axes are not labelled. I would very much appreciate, if you could briefly explain to me what I see there in the following three panels Input channels, CLUT and output channels. Here are the screenshots:
towards understanding of the ICC-profile content, I used the ICC Profile Inspector to look into a profile created with Argyll. Unfortunately the axes are not labelled.
For a basic understanding of the ICC profile format, I suggest you take a look at the introduction section of the standard. In particular, section 0.5 has explanations and diagrams for the different processing elements.
.
- I should go look at my camera input LUT profile to see what actual tags are included - here is a related question that I’ve wanted to ask someone for a long time:
However, your last post struck to the heart of something I’ve been doing, working in Rec2020 and transforming to sRGB for JPEG output. I do this with relative_colorimetric intent (in LittleCMS, if that’s pertinent), mainly because my profiles don’t have the requisite LUTs for perceptual. But, from your last post I’m gathering the compression of the full gamut range with perceptual is probably a poorer choice for large transforms like ProPhoto->sRGB than just letting relative_colorimetric deal with the edges of the receiving gamut. Or, doing something like ProPhoto->AdobeRGB->sRGB with perceptual intents?
