Hi Claudiu, Ok, here is some background on black preservation.
We humans see the color as a tridimensional space. This is because we have 3 different types of cones in the eyes, L, M and S which roughly corresponds to red, green and blue. So, 3 channels should be enough to represent any color. And in fact, they are. But in some situations, additional channels may offer additional attributes. One clear example is CMYK. Since this is a 4 channels color model, there is redundancy and several combinations will give the same color. For example, CMYK=(0, 0, 0, 50) and CMYK=(20, 20, 20, 0) can result in a dark gray. In the first representation, color is obtained by using only black ink. In the second one, color is obtained by using equal amount of cyan, magenta and yellow. So far so good. We have two ways to represent a color that gives identical colorimetry. Now lets see if those are really identical in other aspects. So, instead of using a D50 as illuminant, let's use a D65, which is significantly bluish. If the set of inks are not metameric (usually they are not) the two representations are no longer giving the same color. That is, when we vary illuminant, using K only or CMY makes a big difference on the variation of color we get. Other similar effect would be bronzing, for example. So, two CMYK values can give same color *if* fixed illuminant and viewing conditions. And this is one of the main reasons to preserve black channel, just because we are using a color model that has redundancy and because the redundancy happens only on a controlled viewing conditions. With this I can now answer some of your questions... What about black preservation in RGB? or CMYK to RGB? The answer is: it is not needed, because RGB is already 3 channels. It has no redundancy, so there is only one way to represent colors and therefore no extra information will be lost when converting between spaces. ICC color management is based on Lab or XYZ as PCS, all input colors are converted to those colorimetric spaces. It is up to the output CMYK profile to do the black generation. And this is very complicated if you take into account gray replacement and specially total area coverage (TAC) or ink limiting. Now some info about lcms algorith for black preservation. There are 2 different ways to do that, the "easy one" that only keeps K if CMY are zero. This is intended for keep black text to use K ink only. The "good one" is more complicated. lcms uses the reverse direction to find a suitable CMY combination that keeping same proportion of K as input, gives the intended colorimetry. Since CMYK profiles do have TAC or ink limit, lcms first detects the amount of TAC and after computing the black preservation, replies the TAC on the new transform by using the hypercube algorithm. This is constrained by smoothing requeriments and needs a good proof direction in the profile to work properly. If you split the original CMYK image in planes and take a look on the K plane, a black preserving transform will return a K plane with similar apperance, whilst a normal colorimetric transform will return something completly different, just because original CMYK has been converted to Lab and this Lab has been used to generate a CMYK image, with the black generation algorihm that the ICC profile has embedded, which probably is very different from the original image. In lcms, you can do black preservation as long as you keep CMYK as input space and the ICC profile doing black generation last in the profile chain. This is needed because the TAC thing I explained above. I am investigating on composite TAC and allowing a devicelink CMYK->CMYK last in the chain, but still this is just an open investigation. Doing two transforms is *not* the same, as it just limit ink twice, but it can work to some extent. Plese let me know if you need additional information Regards Marti Claudiu Cebuc <cce...@gmail.com> escribió: > Hi , > > As the black preserving intents (BPI) are to be used on a CMYK->CMYK > transform, I have the following questions regarding the restrictions > imposed on the profiles chain: > > Q1) Should a BPI transform be allowed to be created on a single CMYK->CMYK > devicelink profile ? > In LittleCMS v2.3, I have noticed that this is allowed for K only and not > allowed for K plane. > Also a CMYK->RGB devicelink would be allowed on K only, and result in an > error, while on a K plane it will default to a normal transform made on the > BPI's corresponing ICC intent. > > Q2) Should a BPI transform be allowed to be created on a chain of profiles > that contains a devicelink profile, as long as the chain realizes a > CMYK->CMYK transform ? > Q2.1) What about the case when the devicelink is the last profile in the > chain? > > Q3) Should there be any differences in the restrictions imposed to the > chain of profiles between the black-ink-only preservation and black-plane > preservation transforms ? > > Q4) For the case when the CMYK->CMYK transform condition is not satisfied, > shouldn't LittleCMS issue an error and do nothing as a response to the > client's invalid request? > This is mostly a policy strategy question, whether to inform the client of > LittleCMS that its BPI request was invalid (and the client may take the > opportunity to adjust its request and retry) or provide the client with a > result that may not be the one that the client is looking for. > > These questions arose after seeing the way the CMYK->CMYK transform is > checked in the black-ink-only (BlackPreservingKOnlyIntents function) and > black-plane (BlackPreservingKPlaneIntents function) transforms, where there > may be some problems. > > Thank you, > Claudiu. > ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user