RIPping through data - Challenges faced in the digital front end

1,065 views
1,016 views

Published on

"The challenge isn’t just to be fast enough", says Global Graphics' chief technology officer, Martin Bailey. "The real challenge is to achieve that goal without incurring an uneconomically high cost for the bill of materials to build the Digital Front End."

• Digital Front Ends (DFE) Face Rapidly Increasing Data Processing Requirements as Print Jobs become More Complex
o Increased Use of Transparency
o Need for Increased Variable Data Coverage
• Race for Speed is On-going Competitive Challenge
o DFE Must Process Data Quickly Enough to Drive Press at Full Rated Speed
o Press Manufacturers want to Minimize DFE Costs Vs. Cost of Press
o Must Respond to Market Needs & Opportunities: Photobooks, Personalized Marketing Materials, etc.
• The Holy Trinity
o Speed, Quality & Reliability
• Once the Hardware is Optimized – What Then?

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,065
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

RIPping through data - Challenges faced in the digital front end

  1. 1. RIPping through dataChallenges faced in the digital front end<br />Martin Bailey<br />CTO, Global Graphics<br />
  2. 2. This presentation was created with assistance from our partners at Hewlett Packard. <br />Especial thanks are due to Dave Staas, Lead Software Architect, Indigo Digital Press DFE<br />Acknowledgements<br />
  3. 3. Introduction<br />A Controller or Digital Front End (DFE) provides a number of functions for digital press print jobs:<br /><ul><li>Workflow definition, control, and management
  4. 4. Job management (submission, status, view, edit, cancel, etc.)
  5. 5. Color, ink, and media management
  6. 6. Imposition and finishing management and control
  7. 7. The conversion of rich document formats like PDF and PPML into “print ready bits” – data that is rendered and formatted for the marking engine of the digital press</li></ul>HP Indigo W7200 Digital Press<br />
  8. 8. Constructing a DFE<br />Control process<br />RIP<br />RIP<br />Press controller<br />Pre-processing<br />Post-processing<br />RIP<br />Raster cache<br />Job cache<br />HP Indigo 7500Digital Press<br />
  9. 9. Work allocation<br />Interpreting/rendering – <br />Color management – <br />Imposition – ,  or <br />Trapping –  or <br />Screening –  or <br />Font handling –  <br />Variable data – <br /> + for PPML etc  for PDF with no h/w assist + for PDF with h/w (+) or (++) for PDF/VT<br />Control process<br /><br />RIP<br /><br />Press controller<br /><br />Pre-processing<br /><br />Post-processing<br /><br />RIP<br /><br />RIP<br />
  10. 10. What’s the Problem?<br /><ul><li>A typical print shop can have many digital presses and DFEs (Consolidated Graphics, for example, has more than 50 Indigo digital presses across several sites1)
  11. 11. A standard mid-range digital press (120 PPM) requires the processing of over one hundred million pixels every second, worst-case, with possibly multiple transforms, and in 4 (or more) colors
  12. 12. HP’s high-end presses (like the T400 below) require nearly three billion pixels every second
  13. 13. The primary performance goal for a DFE is to process any job or workflow at or above press speed – strive to always have the DFE outpace the press over a shift
  14. 14. Maximum efficiency must be exploited in every aspect of the system’s design in order to achieve this goal within reasonable cost constraints</li></ul>HP T400 Color Inkjet Web Press<br />HP Indigo 7500 Digital Press<br />
  15. 15. 18”<br />12”<br />
  16. 16. Each color plane is 32 pixels/mm2 (4096 pixels as shown)<br />1mm<br />1mm<br />1 mm2<br />
  17. 17. It’s solved for current jobs and current presses, but:<br />Presses need higher data rates<br /><ul><li>Larger format/wider webs
  18. 18. Higher paper speeds/pages per minute
  19. 19. Higher resolution (2x resolution = 4x raster size)</li></ul>It’s a solved problem, isn’t it?<br />
  20. 20. Larger coverage of variable data in direct marketing, triggered by<br /><ul><li>Better demographic data
  21. 21. Better data mining techniques
  22. 22. Proven better response rates to well-crafted personalised mail</li></ul>More use of live transparency<br /><ul><li>Driving adoption of PDF for direct marketing
  23. 23. Expanding out of general design practice for books, publication, POD, print-for-pay and general commercial print
  24. 24. Many designers don’t even know they’re using transparency!</li></ul>In a well-optimized RIP transparency requires more processing than an opaque job<br /><ul><li>Color transforms & read/modify/write cycles</li></ul>Jobs are getting more complex<br />
  25. 25. This is transparency …<br />
  26. 26. And this …<br />
  27. 27. And this<br />
  28. 28. PDF/VT (ISO 16612-2) defines structures in a PDF file to:<br /><ul><li>Allow easier identification of re-used and single-use graphical elements
  29. 29. Define which sets of pages go together in a hierarchical structure
  30. 30. E.g. as components that will be supplied to a single direct mail recipient
  31. 31. Enable pseudo-streaming</li></ul>This means that PDF/VT is a useful standard!<br />But it does not address the fundamental issues of:<br /><ul><li>Compute power required to process transparency
  32. 32. Sheer data volume required to drive current and future digital production presses</li></ul>Doesn’t PDF/VT fix the problem?<br />
  33. 33. Architectural Considerations<br /><ul><li>Some of the more relevant architectural considerations for enabling maximum efficiency:</li></ul>Reliability<br />Fast, unreliable systems usually aren’t worth much. Stability first, performance second<br />Work Avoidance<br />Look for ways to move or eliminate work first rather than scaling an inefficiency<br />Centralized or Distributed Caching<br />Caching can avoid work and improve performance<br />Watch for centralized caches becoming a bottleneck<br />Instrumentation and Measurement<br />Establish a way to measure performance in your code and system<br />Planning<br />An ounce of design effort up-front will save more than a pound in efficiency and cost-savings in development and manufacturing<br />If you drive a range of devices you may gain from a common, scalable solution across at least some of that range<br /><ul><li>No universal right answer on most of these considerations; they’re useful topics to think about in the context of efficiency</li></li></ul><li>With the right architecture and components you can make a DFE drive your press at engine speed<br /><ul><li>Every component makes a difference</li></ul>What matters is the throughput achievable per $ total bill of materials<br /><ul><li>Include hardware and software</li></ul>The target is to drive the press at rated speed while minimizing the cost of the DFE<br /><ul><li>If the software is faster or more efficient you can reduce the hardware required</li></ul>Reducing hardware reduces power consumption and cooling<br /><ul><li>Going green can be profitable!</li></ul>The real goal<br />
  34. 34. <ul><li>Many machines per rack
  35. 35. Typically one DFE per rack</li></ul>For very high end needs, one DFE in multiple racks<br /><ul><li>Up to 12 Indigo presses per DFE, depending on their type and speed </li></ul>“Ultra” version allows many more<br /><ul><li>Each DFE can drive:</li></ul>Multiple presses<br />Multiple press controller machines<br />Multiple RIP machines<br />Multiple pre-RIP and post-RIP storage arrays<br />Multiple remote UI instances<br /><ul><li>Each DFE has a central System Manager</li></ul>Generally speaking, no post-RIP data flows through<br />Parallelism – Within the DFE<br />
  36. 36. Parallelism – End-to-End Solution<br />Press controllers deliver to presses<br />Split into page ranges and assign to RIPs<br />RIPs deliver data in parallel to press controllers<br />Split files into multiple “partitions” or chunks and process in parallel<br />Parallelize early, maintain multiple parallel pipelines<br />Parallelize in pre-RIP, where the data is much smaller (1/7th the size)<br />Process multiple jobs in parallel<br />Different variations optimize first-page-out, engine loading or throughput<br />
  37. 37. <ul><li>Multiple CPUs per machine
  38. 38. Multiple cores per CPU
  39. 39. Multiple physical disks per machine
  40. 40. Multiple physical disks per logical disk
  41. 41. Multiple (teamed/bonded) network interfaces per logical network connection
  42. 42. Multiple RIPs per machine
  43. 43. Multiple threads per RIP</li></ul>Parallelism – Within a Machine<br />We invest effort to take advantage of all of these machine-level parallelisms:<br />
  44. 44. Digital printing architectures need careful design<br />Many different strategies must be employed in unison for the best effect<br />Key architectural considerations can help guide your efforts<br />Selection of the best components and supplier/partners is an important aspect<br />The ultimate goal is to reduce cost, power, and cooling for customers<br />Summary<br />
  45. 45. Q&A<br />More information at www.globalgraphics.com/imiconf<br />

×