Profile Anatomy – why A2Bn & B2An ?

[Lorna Wiles]

Following on from a previous post, for an input profile why are the B2A tables required, and for an output profile why are the A2B tables required?

eg: The A2B tables in printer profile would be used soft proofing but why not just use the inverse of the B2A tables to map the printer gamut back to the PCS.
The relevance of this can be seen within a work flow where an input profile equals the output profile. I have been using this work flow (I now realise incorrectly!) within a RIP to effectively turn off the colour management assuming that if the input gamut was the same as the output gamut no mapping would take place.

Oddly this 'assumed' behaviour can be confirmed in Photoshop under Edit > Convert to Profile. If the selected 'Destination Space' is the same as the 'Source Space' then no transformation takes place and different rendering intents have no effect on the output.

However this is not what happens within my (old!) workflow in the RIP where a transformation dose takes place. Here, the numbers in do not equal the numbers out. This would seem to confirm that the B2A tables and the A2B are different and that gamut mapping is different in each direction.


Can anyone help with my understanding please?

1) Why there is a difference when converting in Photoshop and when converting in the RIP as explained above?

2) Why dose an output profile requires the A2B tables instead of just using the inverse of the B2A tables (and presumably vice versa for an input profile)?

Many thanks

 

[Schnitzel]

2) Why dose an output profile requires the A2B tables instead of just using the inverse of the B2A tables (and presumably vice versa for an input profile)?

Because you don't start with the B2A tables!

When you create a printer ICC profile, you print combinations of CMYK values and measure them to get the CIELab values. This will give you the "device to PCS" side of the ICC profile, which is the A2B tables. From these measurements, the profiling software then calculates the B2A tables. Without the A2B, you can't create the B2A.

As a side note, the tables cannot be inverses of each other, because the "PCS to device" side of a profile has a one-to-many relationship. This means that a single CIELab color can be created using different CMYK combinations. This is the reason converting a black only color will always result in a rich black (unless you are using a device-link profile or special instructions in the RIP).

An input profile (camera, scanner) is different, because there is no logical point in using the device as a display. Meaning, you don't get a CIELab image, and ask "I wonder what this image looks like if my scanner scanned it" (?). That's why an input profile generally requires only the "device to PCS" side.

 

[curiosity]

1) Why there is a difference when converting in Photoshop and when converting in the RIP as explained above?

I use Prinergy and came across this same situation years ago. The folks at Kodak once explained to me that the difference is in the converting engines and that because the engines are proprietary, for some reason, Kodak couldn't design their engine to render results the same as when Pshop converts.

In Prinergy, we can assume input profile (to be same as we use in Pshop) unless otherwise tagged. If tagged with something else, Prinergy will convert from that to the same profile we se in Pshop. Unfortunately, the conversion isn't exactly the same in Prinergy as it is in Pshop.

 

[Lorna Wiles]

Thanks Guys for your really good explanations. Really helpful. It's making sence!!

"PCS to device" side of a profile has a one-to-many relationship. This means that a single CIELab color can be created using different CMYK combinations.

So what is it that determines the actual combination used; The profile GCR policy, the Color engin used (different in the RIP and Photoshop) or both?

Unfortunately, the conversion isn't exactly the same in Prinergy as it is in Pshop.

So which do you find gives the best conversion, (or which is the most pleasing on the eye), the RIP or Photoshop. As previously mentioned, in our workflow we have been doing the conversions in Photoshop because soft proofing and the effects of different rendering intents are just easier to see.

Thanks

 

[mihas]

There is a A2B0, A2B1, A2B2 and B2A0... in the profiles, but not all of these tables are mirrored. Colorimetric tables are mirrored within gamut, perceptual tables are not mirrored. The inverse function is not applicable to profile tables, for the reason that B2A direction tables contain all possible colors and a limited number of paints, and A2B tables contain all possible paint combinations, but all colors cannot be obtained from them.

 

[Schnitzel]

1) Why there is a difference when converting in Photoshop and when converting in the RIP as explained above?
...Kodak couldn't design their engine to render results the same as when Pshop converts.

Well, who says Photoshop converts colors best? Yes, the color engines are most likely different. The thing is, ICC profiles and the whole color management workflow, have a lot of limitations and leave a lot of freedom in the hands of color engine designers, and ICC profile creators, to do as they see fit.

For instance, in a cLUT based profile, such as for a printer, an A2B table is arranged as a grid of equally-spaced points in the CMYK color space. For file size reasons, the number of grid points in each channel is limited to around 35 (depending on the quality of the profile and the software creating it). This means the ICC profile knows how the printer behaves in increments of 2-3% tone value. What do you do with tone values that aren't there in the table? You need interpolation.
Suppose your RIP software uses fast piecewise linear interpolation due to RIP time considerations, but the guys at Adobe decided to use more complex cubic interpolation because they prefer smoother results, rather then fast. The two engines will give different results. That's one example of freedom software engineers have in color management. There are more.

So what is it that determines the actual combination used; The profile GCR policy, the Color engin used (different in the RIP and Photoshop) or both?

Both, and more. It starts with the B2A table which provides the data, and continues with the color engine which decides how to use and manipulate these data.
When the profiling software creates the colorimetric B2A1 table, ideally it should have one responsibility: give the most accurate color reproduction for a given CIELab (i.e. lowest delta-E possible). On top of that, there are restrictions such as the GCR curve, total ink limit, smoothness of the profile, size of the tables etc.