Sanity Check: Web Offset Ink Consumption Math (Esko CIP3 -> Custom Estimator)

Hi everyone,

I’m a Systems Engineer at a high-volume web offset publication printer. I'm currently building a custom internal estimating dashboard (Angular/TypeScript with a PostgreSQL backend), and I need a sanity check from the estimating veterans here to make sure my ink consumption math is bulletproof before management starts relying on it for financials.

How we are getting the data:
We are scanning our 1-bit Esko TIFF plates (2400 DPI) using ImageMagick to get the mean pixel density (coverage percentage) before they go to press.

• Our press cylinders/plates are a fixed 66" wide x 21" cutoff.
• We evaluate the entire untrimmed 66x21 plate. So if the script returns "10% Cyan," it means 10% of that maximum 66x21 area.

The Epiphany (and the math I need verified):
Originally, the estimating software was applying that 10% Esko coverage to the actual paper roll width being run for the job (e.g., a 38" web). We quickly realized this broke the math—shrinking the paper width artificially shrank the physical volume of the ink, even though the artwork size hadn't changed.

To fix it, we decoupled the material (paper) area from the ink area. Here is the exact formula we are using to calculate physical pounds of ink per color.

Can anyone confirm if this is the industry-standard way to calculate this?

1. Calculate Fixed Plate Area (Perfecting Web): 66" (Max Plate Width) x 21" (Cutoff) x 2 (Front & Back) = 2,772 sq inches
2. Calculate Gross Impressions:(Target Copies + Setup Waste) * (1 + Running Waste %)
3. Calculate Total Pounds of Ink (e.g., for Cyan):(Gross Impressions * 2,772 sq inches * 0.10 Esko Coverage) / Ink Mileage Factor

(Note: We are using a dynamic "Ink Mileage Factor" in our database, currently defaulting to around 350,000 sq inches per pound, depending on coated vs. newsprint).

My main questions for the experts:

1. Does locking the ink calculation to the maximum plate/cylinder width (rather than the paper roll width) align with how commercial estimating software handles CIP3/Esko data on variable web widths?
2. Are there any hidden gotchas in web offset ink consumption that this formula misses?

Any insights would be hugely appreciated!

I assume you are:
heatset web, using solvent based inks, not coldset absorption inks,
also have a 3rd ink mileage factor for uncoated paper, besides coated and newsprint?

SteveSuffRIT said:

I assume you are:
heatset web, using solvent based inks, not coldset absorption inks,
also have a 3rd ink mileage factor for uncoated paper, besides coated and newsprint?

Click to expand...

Yes, we are heatset web. We are running this on a Goss Sunday 2000 and a Goss Sunday 3000 (gapless).

You just hit the exact "gotcha" I was worried about regarding the mileage factor. Right now, that ink calculation is falling back to a hardcoded 350,000 sq-in/lb across the board, but based on your comment, I need to configure the database to fetch a different mileage parameter based on the paper classification.

We primarily run these six stocks:

1. Newsprint (Uncoated/Highly Absorbent)
2. Hi-Brite (Uncoated)
3. SuperCal A (SCA)
4. SuperCal B (SCB)
5. SNC (Standard Newsprint Coated)
6. Coated

For a heatset Sunday press, what mileage factors (roughly) would you assign to those three main buckets (Newsprint vs. SuperCal vs. Coated)? If I can get a baseline, I can unit-test the software's output against our actual pressroom ink consumption logs from last month.

Thank you for helping!

EDIT:
Here is what I found so far (if you could help me verify):

1. Coated (High holdout)

• CMY: ~400,000 sq in/lb
• Black (K): ~450,000 sq in/lb

2. SNC (Standard Newsprint Coated)

• CMY: ~350,000 sq in/lb
• Black (K): ~400,000 sq in/lb

3. SuperCal (SCA & SCB) (Highly calendered)

• CMY: ~300,000 sq in/lb
• Black (K): ~330,000 sq in/lb

4. Newsprint & Hi-Brite (Highly absorbent)

• CMY: ~220,000 sq in/lb
• Black (K): ~250,000 sq in/lb

(Note: I gave Black ink a ~10-15% mileage bump across the board assuming the carbon pigment allows the guys to run a thinner film on the rollers compared to the translucent CMY dyes).

I figure if I start conservative with these numbers, I can dial them up closer to your actuals if my software estimates start coming in heavier than what the pressroom actually consumed.

FYI
The Esko AE is capable of producing a ink coating without ImageMagic.

But overall, everything is correct.
We determined through trial and error how much ink is used per print run and calculated the actual ink consumption for different types of paper.
Then we calculate the ink coverage per print run and get a fairly accurate resul

Ascott: If I can get a baseline, I can unit-test the software's output against our actual pressroom ink consumption logs from last month.

Your estimating software should "model" real production data. Use your historical ink mileage consumption data as the baseline reference. You know the 1) # of impressions, 2) Type of paper (absorption/holdout), 3) Ink consumed. You got everything you need go know from historical data.

Stanislav Rakov said:

FYI
The Esko AE is capable of producing a ink coating without ImageMagic.

But overall, everything is correct.
We determined through trial and error how much ink is used per print run and calculated the actual ink consumption for different types of paper.
Then we calculate the ink coverage per print run and get a fairly accurate resul

Click to expand...

On Esko AE, where would you configure that as output?

ascott said:

On Esko AE, where would you configure that as output?

Click to expand...

Two tickets for it Export PDF info for Native PDF and Create Paf / jpg/xmk for nor,ilezed pdf
then you can calculate in JS you square