So if we're going to change color with data...

We need a way to talk about color and changes to color that makes sense for what we are trying to do.

There is a lot written about color and profiling and so forth but I have yet to find something that talks about color in the way we need it here for changing it with data.  Since I had paying customers that needed a new way to manage color I had to invent one.

So what drives this new description of color?

For one thing, we have to work with a layman's perspective on color:

• One thing that's obvious but for which I can find very little is non-color specialists think about color in terms of lighter and darker shades, i.e., not "more black" is darker.  Mathematica has this notion built in but as far as I know things like Illustrator do not.

• Non-color specialists seem to like quantized color values - that is a set of color choices presented with some "distance" between choices.  For example, Red = 0%, Red = 5%, Red = 10%, and so on.

• Non-color specialists also seem to like statements like "this is too green" or "too yellow" - particularly for things like images and shading.  Though they don't seem to be able to vocalize "not green enough".

From a device perspective we have to able to work with difference between devices  - both in a technical sense as well as in the layman's sense:

• We need to parameterize how the device responds to quantized color values.  So instead of looking at a smooth curve relating to how a device presents a colorant we instead look at the presentation of the colorant in fixed steps.

• We need to understand how the device responds to the ink limits we need to produce jobs economically.  So our focus is not so much on making the inkjet output look like the output from an Indigo, iGen or Xeikon but instead focus on a customer-acceptable at the ink limits we must work at.

• We need to understand the devices calibration limits, i.e., to what tolerance can the device be calibrated in a regular production cycle.  In particular we need to understand this relative to the quantized color values we are interested in.

• We are not concerned here with all devices but only the set of devices tied to our manufacturing process.

From a descriptive perspective we need to be able to "measure" and "write down" differences in color values:

• We need a Rosetta stone that will allow everyone to talk about the color they are working with in the same external way.  This concept is much like traditional profiling - but with one significant difference:  The Rosetta stone has to be accessible to the user.  In today's profiling the use of calibrated systems allows profiles to be created and embedded in files.  However, these profiles are not easily accessed nor are they even "visible" to production personnel, i.e., I need special tools to inspect the file for even the presence of such information.  So we want to "extract" the notion of calibration from the process so that it can stand separately.

•  We need a tool that allows users to capture differences in color values - both interactively and systematically.

• We need a language to describe concrete color changes as well as a language to talk about what kind of "thing" the color changes apply to.

From a mathematical perspective we need to have a model of color to address our needs:

• We need a model that supports both discontinuous changes as well as continuous changes.  For those without math backgrounds continuous means I can draw a smooth curve to describe what I am talking about, i.e., a continuous function describes what I am talking about.

• We need a model that "looks like" what must be done to the color.  This is rather a hard concept to pin down but I will try a bit later.  The idea is that someone can easily visualize the model from what's required and vice versa.

• Our model must support continuous and discontinuous color change simultaneously.  In our world a given item may have two, unrelated color issues.  Another way to say this is that there is discontinuity between the color issues.  For example - the document may appear "too red" and an issue with the color of red text.  While a continuous change of red over the document in general might solve one of the problems it makes the other worse.

Given all of this we need to come up with an underlying mathematical model that can be controlled by data.  So what does this mean?

Well, for a statement or direct mail piece today data controls things like the addressee, their account number, and so forth.  We have a direct mapping between data values the output - the data changes the text.  In more complex VDP applications there may also be an indirect relationship between the data the output - for example the notion of a selector value (say 1 through 5) that controls which coupon is associated with the document.

What we need here is a data model that says what dynamic color changes, i.e., we need to parameterize the change process.  So, like case of the coupon above we might say #1 means use the "$5 off coupon", #2 means use the "$10 off coupon", and so forth.   We don't actually store a copy of each coupon in our database, we store a parameter that controls which coupon is used.

So, like the coupons we take our example of red and say that a parameter, say #1, says apply the correct set of red color transforms and for another parameter, say #2, says we apply the correct green color transform and so on.

Unlike coupons there is a notion applying color transforms only when a given color issue is present.  For example, we need very light RGB grey to be a bit darker.  This may be a general device problem which requires all documents to be processed accordingly as opposed to the notion of the red problem as described above.