A little off topic...

So I didn't post on Friday because I was in a studio working on some new songs with my buddy Scotty. I am in a couple of bands and some of them write new material.  While there I had some experiences that paralleled what I write about here so I thought I would share them.

So the first evening I'm there we bring in two experienced musicians: first a drummer and later on a bass player.  The drummer was very good and had a large repertoire so we had him play a number of short tracks based on our instructions for what we wanted to do.  We had a fairly standard set of mics hooked up: snare, bass, toms, overhead.

So this was all tracked into a DAW which is basically (in this case) an IBM PS/2 with an audio front end that acts like a big tape recorder that can record 16 different microphones at once.  We probably recorded about 8 different drum track sections.  Now the DAW, being older, was fairly limited in what else it could do besides record the tracks.  It didn't have the "modern" PC-esque cut/paste/drag interface and it really operated like a tape recorder - once it was recorded that was basically it except for recording over it.

A little later on the bass player showed up.  So we backed up the DAW to the first drum session and tracked the bass player on his own tracks (the DAW could play the drum tracks so the bass player could hear them and record the bass parts at the same time).  The drummer and bass player also did some combo tracking after we had captured the bass work for the original set of 8 or so drum tracks - so probably all told there were about 12 usable grooves.

So now we've got a lot of great material all tracked (recorded) into this DAW (which was a TASCAM SX 1).  So Scotty says "let's go back and pull out such-and-such - I really like that".  So we wind back and play around a bit and realize that what's there is itself not really a song.  It will need to be cut up into pieces and redone to be useful.

So I foolishly say "just put that over here on my Mac and I will pull out the grooves in question."  And the fun begins...

So "Chicago Dave" - the guy running the DAW - says "we'll have to bounce the audio over to your Mac." (This means hook the audio in on my Mac up to the audio out on the DAW and play the music into the Mac - which would take a long time because there are 8+ tracks at 30+ minutes each and my Mac can only do two at a time.)

I say "No way - there has to be some what to just copy them over - they are both computers..."  Blank looks.  So I say - "where's the manual?"

After digging around I discover the DAW has a network port (Ethernet) and it can act as an FTP site.  Fortunately I always travel to studio sessions with a big bag of goodies - among which is an ethernet cable.  We hook up and bingo - we're into the SX 1 FTP server.  After some poking around we figure out the how the names of the tracks on the screen match the files and we pull them onto the Mac.  (This ancient PS/2 thing sucks as an FTP server - type a "get foo.wav" command where foo.wav doesn't exist and it goes belly up.)

So now the files are all on the Mac.  I open up Logic Pro (which I use) and load the tracks and sadly they don't line up right.  Some start sooner than other and some start later - an artifact of how and when the record button was pushed (there's no need for the recordings to line up across tracks like drum and bass - just the sounds - so their might be 10 seconds of dead time before drums and only 2 seconds before the bass).  What a mess...

So "Chicago Dave" says "Let me mix down the drums to two tracks that line up."  So we do this, re-run the FTP, and now the Mac has workable data for cutting and pasting to form the base of the song.

After the cutting and pasting of the basic rhythm tracks is complete its time to reload this into the TASCAM.  So I think "What would the chances that just uploading these files will do the trick - about zero." so we track the Mac version back into the TASCAM and start recording the additional tracks there.

By the next day we've got all the rest recorded in the TASCAM.

Now Scotty says "hey, I want to take home a copy of this to mix".  (Scotty and I have learned over the years that having backups of irreplaceable performances is a really good thing.)  So back to the FTP to pull down all the new tracks onto my Mac.

So today I'm back in the office with all the tracks safely recorded onto my Mac.  Later on I will push them up to one of my FTP sites so everyone else can download them for mixing.

So I ask Scotty - "how did you do this last time?" (I wasn't at this studio last time.)

He says "Oh man - I had to bounce each track out to my little hand held recorder two at a time.  It took a lot of concentration and forever to do it."

So what's the point of all this? 

Well, like anything else it seems like technology runs ahead of what people understand how to do with it.  In this case the TASCAM, while a great device for recording, was not a great device for doing other things like cutting and pasting, exporting audio or importing audio in files.

While it was possible to come up with a solution it was a bit tedious and ugly - better than none at all - but still it took a while to get things working smoothly the first time.  This parallels what else I write about here.  There is almost always some solution - but it may not always be the best.

Finally, once you start down a road you may find yourself committed before you realize it.  In this case the drums and bass (which was very, very cool) were locked into an antiquated device that was not friendly with how we wanted to work.

What not to do...

So I got this in the mail the other day:

Looks like a nice example of the latest "VDP personalized marketing", right?  My name appears in spiffy yellow print on a fluorescent green mailer.  Content all personalized, etc.  Even a brand spanking new personalized URL (PURL) with my name to sign up for their course on "cross media marketing".  The bright green color really does make it stand out in the usual junk mail stream that comes to the office.


Only problem is they sent it to an old address.  Our company moved almost a year ago and lucky for this company the USPS caught their mistake and forwarded it to the right location.

Years ago I owned a mailing company which I founded.  We did reasonably well growing to almost 50 employees in four years and doing about $4 million in sales.  So I understand mailing and doing it right - you can't grow that fast in the mailing business without knowing what you are doing.

Mailing 101 - clean up the address list with the latest USPS database.

So, I figure I'd check through the PURL.  Amazingly its actual there.  Unfortunately, once you click through to the second page you get this:

Though it might be a bit small it shouldn't be to hard to see that the "User Information" and "Contact Information" are BLANK!

Now, I would have expected to at least see the wrong address filled in.  But instead I see nothing.
I post this today to demonstrate what the "latest, greatest" technology can do in inexperienced hands.

My guess is that this is a printer/mailer without a lot of experience doing this type of work.  They probably read up on doing this a places like What They Think and figured why not use it to promote themselves.  

The theme of the piece was be Noticed.    I guess it worked - perhaps not like they expected though...


So why am I taking the time to trash this piece?  To illustrate a simple point.  Complex document, mail, and web processing requires experienced, technically savvy folks who understand not only the ins and outs of print, IT, and mailing but also someone who knows and understands integrated QA.  Validating the inputs and outputs of a mailing/purl system appears to be beyond the experience level of this company, and, given that, in my opinion they shouldn't be advertising they can do it for others.


I wouldn't be posting these comments if I hadn't done the same things myself.  In fact, I have a law named after it.

Kueny's First Law of Mailing:  For any given mailing containing at least one wrong piece at least one wrong piece will be received, opened and reviewed by a close relative/spouse/contact of a supervisor of the person who purchased the mailing service from your company in the first place.


Imagine if this where a bank or health care statement with incorrect and/or missing personal account data. 

"Remade" PDF and AFP

So finally we introduce the notion of "remade" PDF and AFP.  What is this?

"Remade" means that we have processed the contents of some static job in a way to remake it into something we can use.  There is something of an elitist model in graphic arts (and particularly in the VDP area) that says this is wrong or it should not be done.

I believe it comes partially from the notion of specialized skills required in the past for graphic arts - but this is changing.  Today you see a lot of IT people doing graphic arts because its cheaper and faster.  Do they understand everything a pro might?  Nope.  But can they get the job "done enough" so the customer will pay for it? Yes they can.

Typical things that show up in "IT generated" PDF and AFP are mixed color modes, e.g., RGB and CMYK, resolution issues, i.e., low res logos where high res are needed, page count issues, i.e., ten thousand one page documents instead of one ten thousand page document, and on and on.  And on and on it goes...

On the one had the fact that these types of file are now being created at all indicate the overall success of PDF penetrating the IT world.  The downside is that the IT folks doing the creating have no idea about the limitations of PDF (or AFP).  None of the designers of PDF ever thought that it would be created by relative novices who really don't understand the gestalt. 

As an aside - recently someone came to me with a file that took a very long time to RIP.  There were not obvious problems externally but, upon examining the contents, I discovered that a number of PDF rules related to constructing the file had been violated - not that the file was invalid mind you.  Changing the file to incorporate the proper structure saved some 50% in RIP time.

Another customer presented a problem file that was very simple - some color box outlines laid over some text.  Previous versions of these files were quick to RIP and RIPing scaled linearly from a thousand page file to a thirty thousand page file.  It turns out that some transparency was used, probably inadvertently, in the newer file.  The customer did not even know this - a symptom of the general "A" list problems mentioned in other posts.  Unfortunately the only solution was to remove the transparency.

As PDF expands outside of graphic arts these problems will become more pronounced and profound.

Problems also revolve around VDP.  Some independent thoughts by someone much like myself can be found here.   No one involved in PDF has any real idea what the issues are for requirement-driven high volume printing.  Simultaneously, no one in AFP has any real good idea about high-end graphic arts.

The sad truth here is that highspeed printers today have gang-RIP options that render PDF/VT useless for the most part.  And any other performance gains can be acquired via "remaking" the PDF.  No VDP format files are required.  Yet the standards bodies march on compounding these messes through ignorance.

At the Lone Wolf we see opportunity in these gaps.  Opportunity to help the AFP folks do better with color and graphics and opportunity to help the PDF people escape the world of the crappy "A" list RIP time and content problems.

The opportunity exists in what we call "remaking".  Taking something someone has already created and altering it so that it meets the needs of the user.

At this point I am going to return to the separate PDF and AFP Outsider blogs and talk more about the tools we have.  I will return to post here when issues common to both emerge.

What colors do we change?

Now that we have discussed in some detail the machinery involved in changing the color we need to discuss how to pick the colors to change.

The first step is to determine which colors are wrong and what the nature of the problems are.  Typically this involves a test print and a review the CSR and customer over document issues.

For many business documents we can order the problems as follows:

1. Key logos and other marks don't meet brand requirements.
2. Tint and shading issues.
3. Consistency.
4. Miscellaneous.

The issues with logos and branding are fairly clear.  Either it matches soda pop blue or red or it doesn't. Strategically there are a couple of ways to choose alternative colors but for this case its usually best to provide a set of choices for the end user to pick.  Depending on the color choice almost invariably the replacement model will be one of replacing either a single color a set of shades of that color.

Sometimes if other work is in-house for a given client then these choices would be automatic.

Tinting and shading generally fall into two categories.  Grays and branding-related  accent colors.  Grays tend to be simple "too light" or "too dark" issues and are usually solved with adjustments to a gray shader.  Invariably gray problems revolve to some degree around RGB colors and its generally a good idea to replace the color space in the output as well as the color, i.e., RGB gray to PDF G gray.

Tinting issues tend to revolve around the comparison of brand marks with supporting marks, e.g., I have a green bank logo and there are green boxes and lines on other parts of the document.  Once the logo color is set correctly the tint of these other items may not match.  (Often logo's are supplied as CMYK and other colors as RGB - usually because whatever process is creating these documents takes as input unchanged logos from graphic art sources whereas line drawing is programmed.)

Consistency typically involves documents where several underlying or competing creation processes have been established.  For example, a parent organization with multiple child organizations.  In these cases you may have a set of brand colors but the brand colors are not consistently applied or the color spaces are for the brand color spaces differ for documents within the entire run.  Again, you may see some with RGB versions of logos and some with CMYK.  Needless to say these do not match with printed.

Miscellaneous issues involve everything else.  The most common can involve embedded profiles that need to be removed, CMYK black issues, and ink usage issues.

The process for creating the color input to the Lexigraph process is currently manual - though this will change in the future.

Tools that allow documents to be inspected generally work better than authoring tools.  A very complex and difficult issue here is the nature of the "A" list family of image and illustration editing software packages.  The general problem is that these packages  cannot be relied on to accurately report on color.

The reason for this is complex but basically boils down to the fact that the "A" list company knows color better than you.   To that end everything its software packages do involve either 1) the injection of profiles or 2) the interactive application of profiles such that the numbers reported by the package for color are not the numbers ultimately placed into the file.

You can see this for yourself by opening an "A" list illustration package, creating some simple blocks of color with specific CMYK or RGB values, saving out a PDF, and then inspecting the actual PDF produced directly or with a non-A-list application.

I suppose all the work to make sure you never "see" the profiles is all to make your job easier - which is fine as long as your job works like the "A"-list folks expect.

Lexigraph's tools require that they you identify the actual color you are asking the imaging device to image.

A real example (part #2)

Now that we have a language to quantify the differences in colors how do we make use of it.

Let's take our example with the green logo from the previous post and assume that documents to print contain this logo.   Further, we assume that if we print the document "as is" the logo color is wrong.

So the first thing we need is a mechanism to name a set of transforms for application to some input.   We will use pseudo XML that use parends instead of greater/less than to avoid blogger bugs.  So we might say:

(TRANSFORMS)

  (TRANSFORM name='fix_logo')

  ...

  (/TRANSFORM)

(/TRANSFORMS)

We also need a way to talk about the colors (outside a mathematical context) we are interested and we need tell our system what to do with those colors.  To do this we use sets of colorant values along with an identifying color type, for example CMYK(0,.2,0,.01).  In practice we want to restrict our color specifications a bit more so we create some more complicated color types: "CMYK" means stroke CMYK color, "cmyk" means fill CMYK color, "icmyk" mean image CMYK color, and so on (the other types are just combinations of these basic types).  So we could say something like:

(COLOR name="c1" type="CMYK0,.2,0,.01)" /)

Finally we need a way to talk about the mathematical transforms and what colors, if any, they might use.  We're not going to put the mathematical parts out here.  Instead we will assign names to them like this:

(OPERATION name="fix_green" input="c1" output="c2" function="shader1" param=".75" ... /)

So here we have a transform called fix_green that takes as an input color c1 and transforms it to c2 via a function shader1.  shader1 is controlled by some additional parameters identified by the param attribute.  The shader1 function controls the stretching and shrinking operations we've describe earlier. For our purposes here we can imagine shader1 to use the param value to control how closely an input color has to match c1 in order to convert it to c2.

Putting it all together we might end up with something like this:

(TRANSFORMS)

  (COLOR name="c1" type="CMYK0,.2,0,.01)" /)

  (OPERATION name="fix_green" input="c1" output="c2" function="shader1" param=".75" ... /)
  ...

  (TRANSFORM name='fix_logo_A')

    (APPLY name="fix_green"\)
    (APPLY name="fix_red" \)

  (/TRANSFORM)

(/TRANSFORMS)


Next we need a way to tell our system when to apply the fix_logo_A transform.  To do this we need some meta data that associates a page in a stream of documents to alter with a transform.  We might use something like this:

(DOCUMENT id='0123456' transform='fix_logo_A'/)

(DOCUMENT id='0123457' transform='fix_logo_B'/)

(DOCUMENT id='0123458' transform='fix_logo_A'/)

...

This let's us selectively apply transformations based on inputs.

Note:  There is no reason that parameters like param='.75' have to be static relative to the document stream.  We could, for example, also say

(DOCUMENT id='0123456' transform='fix_logo_A' param='.65' /)

It really all depends on what you need to do.

So now we can describe the color changes we are interested in.  We have a programmatic way that supports parameterization to allow us to control the color changes with data.

However, there are still some items we have to cover in order to define a complete system (which we will do in subsequent posts):

1. How do we figure out what transforms should do?
2. How do we figure out what color to change and what to change them to?
3. How do we handle differences in color between devices?

Besides stretching...

We have covered most of what you can do by stretching a color representation.

There is an additional type of transformation we will now consider before returning to our real example.  Let's consider a typical situation where a file is received that contains the "wrong" color.  How the color gets to be "wrong" is not important at this point.  What I mean by wrong here is that its red and not blue.  Now usually the difference is much more subtle but that's irrelevant here.

On the left is the logo using the "wrong" green.  There are several points to notice.  First, though the logo is primarily composed of the green indicated by #14 there are other green's present as well (see #15 for example).  There are also residual colors like those indicated by #18.

On the right is what we want (and actually did) transform the image on the left into.  First, you'll note that #17 indicates the primary color difference.  But you'll notice as well that colors similar to #14 are also transformed.   While we could have only transformed the single, primary color value the result would have been unacceptable.

So how can we think about this color transform?  Obviously its not exactly "stretching" because we need colors other than the primary green to be transformed as well and "stretching" the primary green around is not going to address this.

To address this we need to extend our "model" of transforms from a 1-D one (stretching a single value along a line) to a 3-D.  Let's imagine for a moment that our #14 green is an RGB color.

We can imagine that our original green is the point is (x1, y1, z1) and that our new green is (x2, y2, z2).  The lines from the origin through each of these points represents the shade of each color (as in moving more "toward" white in this case).

If we imagine a matching colors along the (x1, y1, z1) axis then we can imagine matching shades of the that color as well as a specific color.  Alas, not all the colors we are interested in fall along the line described by (x1, y1, z1).  So now what?

If we sample the colors in our image we can create a set of data points about our line (x1, y1, z1) that show us "how far" from that line the colors we wish to change are.

So here we see that (x0, y0, z0) is "too far" from our line and hence too far from our original "green" color.  On the other hand (x1', y1', z1') is close enough.  Now imagine a shape, for example a cone, with the tip at the same origin as the line that encloses our points of interest around (x1, y1, z1).  This shape, when applied to our input, captures all the colors "around" the original green we are interested in.

The next step is transforming these colors to new colors.  If we visualize another line for the replacement green (along the line defined by the origin and (x2, y2, z2)) we can see that transforming the cone from the original line to the new line is much the same as transforming the scan as I described from the 1-D transformation.

Recall our previous discussions about stretching.  In the 3-D case we simply have three dimensional objects which are deformed (we use this topological term instead of stretching).  If we weren't changing color then the same properties we discussed for stretching would apply to the cone instead of the scan or graph.

Since we are also changing the color we need to translate our cone from the line defined by (x1, y1, z1) to the line defined by (x2, y2, z2) and then apply the deforming transformations.

The use of a cone is arbitrary here though the choice of a shape is critical to the function of the overall transformation of color.  In fact there is no limit on the shapes that can be used nor is it required that the source and target shapes match so long as there is a continuous function mapping from the first shape to the second and vice versa.

The nature of stretching...

There are some other thoughts I want to throw out at this point regarding the stretching and shrinking.  One is that the nature of the shrinking/stretching is where the real work gets done.  The nature of this is basically do we stretch/shrink things evenly, and so forth.  Also there is the issue of A and B ability to produce given colors or ranges of colors - which is not addressed by a transform per se.
So let's go back to this example for a moment:

So let's think for a moment about what happens in the case where we transform the color from Source #2 to Source #1 (B to A).  If we stretch B in the region indicated by #5 then our color response will be similar to A.  But there are two questions you should have been asking in the previous post:  1) What happens to the "left over" part of B (to the right of #5 on Source #2) when we stretch things and 2) what if the stretching required to align A and B is not smooth.  There is also a third question about how to resolve color for a device that produces quantized output.

Let's first address the "left over" part of B (Source #2) above.  Let's imagine that the left edge of #5 where it touches Source #2 moves right, stretching the area where #5 touches Source #2, until the angle of #5 is basically eliminated.  (Alternatively the bottom of #5 is stretched to the right expanding the area it touches Source #2 until the length of the bottom of #5 matches the top.)  Below I will try and illustrate this:

So in terms of color the shading of Source #2 is more like Source #1.  But something else has happened - the distance between the tick marks has changed as well and some of Source #2 has extended beyond the 0% point (the end of Source #1).

For a minute let's forget a about the fact we've extended #2 beyond the end of #1.

First let's requantize #2 by taking away the stretched tick marks and replacing them with tick marks that match things before stretching, i.e., they are in the same position as Source #1.

So you now now see that Source #2 does not "line up" with Source #1 any more - but that's okay.

So if we now compare each section of Source #1 and Source #2 and we re-stretch and re-shrink sections of Source #2 its easy to see that eventually we can get them to match.  Since the lines represent the points where the color is quantized and if we quantized the color down to a point where the user cannot easily distinguish between the quantized colors we have matched the sources as closely as we can.

Note - this is not the same as matching color with a ICC profile or with a calibrated color system.  That's not the point of this process and those systems cannot address the full requirements of what we will cover here.  This system's success requires that the devices be calibrated to start with.  What we are doing here is extending the notion of color matching beyond what that type of system can do.

And what about the left over part of Source #2?  A couple of points on this.  First the left over part is not usable because if the last tick mark areas of Source #1 and Source #2 match up then the left over part represents a part of the color space that doesn't make any sense in terms of Source #1.  Second, while there may be color values represented in this area we would never use them (because they make no sense) so we don't care about them.  Bottom line - we can take our scissors and get rid of them.

Now if you think about it there is an analogous situation if we reverse Source #1 and Source #2 and think about shrinking Source #1 to match Source #2.  Since the right of Source #1 is at 0% we would basically extend 0% to the left.

Because the range of what's happening always occurs between 100% and 0% for both devices and we never are in the position of somehow "creating" colors that the devices cannot produce.  We may be reducing the range of color for the device - but we can always produce the color.

Similarly - this works at the 100% end in the same way.

Now we have to translate what we are doing back into the context of "industrial color management".

We have not choice but to limit the color spectrum of what we produce to the given device, i.e., we cannot "print outside the color gamut of the device".  All we are doing is "moving the gamut around" to best match the two devices.

To this point you will probably say "so what - this is just ICC profile management" and, given what we have covered to this point you'd be right - at least to a point.  The difference being that we can parameterize these operations, i.e., make them automatic and driven by data.  Secondly the ultimate expression of this is designed for non-color production people.  As I pointed out earlier the economics of this require that color is handled by regular operational personnel.

A real example (part #1)

We have two printing devices.  Let's call them "A" and "B".

In the "industrial world" A and B have a defined relationship.  A is coming off lease soon and B is taking over for A.  Since A has been in place for several years millions of impressions a month pass through it.  The owner's of A have many customers who supply this work and they rely on A to produce the output they know and love and, most importantly, they are heavily invested in the process with proofing, approvals, etc.

So after B is set up we run some tests and we discover some interesting differences between A and B (remember, B is years new than A in terms of technology).  The gradient shades are scans of the color output for a set of quantized color values.  The vertical bars are indicators that tell us where each quantized value changes.  Both machines are properly calibrated and use identical profiles, paper and input.

Here Source #1 is printer A and Source #2 is printer B (though it doesn't really matter which is which as we will see in a minute).  This image represents a span of some color C from a value of 100% to 0% (and again, what C is is not important right now).

So what does this tell us?  In general we see that printer A takes about 20 steps to go from say 50% color to 0% color and printer B takes only about 10 steps (marked by #5).  We generally see that B's color output relative to the steps is "compressed" toward the left.

So if we imagine that this represents "gray" output (say the shaded gray's around boxes on statements and so forth) then B's shaded boxes, all things considered, will be lighter than A's.  We can also imagine that this represents a colorant (say yellow) then we would expect weakness in yellow in lighter shades of color using yellow.  Finally, this could be any specific color - say a red used in a sign for a cola company.  In any case the output of B is not going to match A.

So we have identified a problem with B's output.  Note that B is not broken and is in fact working as advertised.  We are simply examining the usability of B's output relative to A.

The next step is to quantify what we see here visually in a mathematical sense.  For this purpose we collect this data via a scanner.

Now we have a characterization of the differences (A on the left, B on the right).  We illustrate some of the differences (note these scales are not normalized) between the two:  #3 indicates a bump in A's output which B does not have, #4 indicates a sharper "knee" in B's output which A does not have.

What's important to note here is that all things being equal for acquiring this information the relative differences between A and B we show here are, for the most part, completely independent of paper, lighting, etc.

Next we normalize the scaling and remove the comb-like spikes introduced by the "tick marks".  Once we do that we can display things more clearly.

Here on the left top we see A's output and on the bottom left B's.  If we superimpose A and B we get the differences between the two devices for color C (the area marked by the bars and #6).

Now remember, the amount of color C is 100% at the left and 0% at the right.

The next step is to characterize the difference between A and  B with a mathematical function.  Before we do that I am going to try and motivate for you what we want to accomplish so hopefully the math, even if its not clear, will not get in the way of understanding.

So let's imagine the large gray area under #6 (the plot of B's output) to be made of rubber so that it can be stretched (or shrunk).  So, naively, if we want to make B's output look more like A's we would want to stretch B's curve to the right and make B's curve taller on the left.   The reverse, making A like B, also works by shrinking - in this case shrinking A's output on the right and left.  So if we could somehow link the stretching to somehow altering A or B we would be able to eliminate the difference between the machines.

In a more formal mathematical sense two things are important here.  First, that the stretching and shrinking between the curves is continuous.  That means we don't use a knife or scissors to get the job done - we only stretch or shrink these areas.  Second that we can "reverse" the stretching and shrinking operations we do for the transition from A to B to create a B to A transition.

We will call these stretching and shrinking operations transformations.