Choosing the class of your raster image processor (RIP) – Part II

Part II: Factors influencing your choice of integration

If you’re in the process of building a digital front end for your press, you’ll need to consider how much RIPing power you need for the capabilities of the press and the kinds of jobs that will be run on it. The RIP converts text and image data from many file formats including PDF, TIFF™ or JPEG into a format that a printing device such as an inkjet print head, toner marking engine or laser plate-setter can understand. But how do you know what RIP is best for you and what solution can best deliver maximum throughput on your output device? In this second post, Global Graphics Software’s CTO, Martin Bailey, discusses the factors to consider when choosing a RIP.

In my last post I gave a pointer to a spreadsheet that can be used to calculate the data rate required for a digital press. This single number can be used to make a first approximation of which class of RIP integration you should be considering.

For integrations based on the Harlequin RIP® reasonable guidelines are:

  • Up to 250MB/s: can be done with a single RIP using multi-threading in that RIP
  • Up to 1GB/s: use multiple RIPs on a single server using the Harlequin Scalable RIP
  • Over 1GB/s: use multiple RIPs spread over multiple servers using the Harlequin Scalable RIP

These numbers indicate the data rate that the RIP needs to provide when every copy of the output is different. The value may need to be adjusted for other scenarios:

  • If you’re printing the same raster many times, the RIP data rate may be reduced in proportion; the RIP has 100 times as long to process a PDF page if you’re going to be printing 100 copies of it, for instance.
  • If you’re printing variable data print jobs with significant re-use of graphical elements between copies, then Harlequin VariData™ can be used to accelerate processing. This effect is already factored into the recommendations above.

The complexity of the jobs you’re rendering will also have an impact.

Transactional or industrial labelling jobs, for example, tend to be very simple, with virtually no live PDF transparency and relatively low image coverage. They are therefore typically fast to render. If your data rate calculation puts you just above a threshold in the list above, you may be able to take one step down to a simpler system.

On the other hand, jobs such as complex marketing designs or photobooks are very image-heavy and tend to use a lot of live transparency. If your data rate is just below a threshold on the list above, you will probably need to step up to a higher level of system.

But be careful when making those adjustments, however. If you do so you may have to choose either to build and support multiple variations of your DFE, to support different classes of print site, or to design a single model of DFE that can cope with the needs of the great majority of your customers. Building a single model certainly reduces development, test and support costs, and may reduce your average bill of materials. But doing that also tends to mean that you will need to base your design on the raw, “every copy different”, data rate requirements, because somebody, somewhere will expect to be able to use your press to do just that.

Our experience has also been that the complexity of jobs in any particular sector is increasing over time, and the run lengths that people will want to print are shortening. Designing for current expectations may give you an under-powered solution in a few years’ time, maybe even by the time you ship your first digital press. Moore’s law, that computers will continue to deliver higher and higher performance at about the same price point, will cancel out some of that effect, but usually not all of it.

And if your next press will print with more inks, at a higher resolution, and at higher speed you may be surprised at how much impact that combination will have on the data rate requirements, and therefore possibly on the whole architecture of the Digital Front End to drive it.

And finally, the recommendations above implicitly assume that a suitable computer configuration is used. You won’t achieve 1GB/s output from multiple RIPs on a computer with a single, four-core CPU, for example. Key aspects of hardware affecting speed are: number of cores, CPU clock speed, disk space available, RAM available, disk read and write speed, band-width to memory, L2 and L3 cache sizes on the CPU and (especially for multi-server configurations) network speed and bandwidth.

Fortunately, the latest version of the Harlequin RIP offers a framework that can help you to meet all these requirements. It offers a complete scale of solutions from a single RIP through multiple RIPs on a single server, up to multiple RIPs across multiple servers.

 

The above is an excerpt from our latest white paper: Scalable performance with the Harlequin RIP. Download the white paper here.

Read Part I – Calculating data rates here.

Harlequin RIP helps to drive the new HP Production Pro for Indigo Labels & Packaging

Our corporate communications director, Jill Taylor, talks to Roy Faigenbloom of HP Indigo at Labelexpo Europe last month about the new digital front end driving the HP Production Pro for Indigo labels & packaging.

HP Indigo chose the Harlequin RIP as the RIP engine in this new DFE, which has been designed to drive all HP Indigo digital labels and packaging presses and has been rated as 5x faster than the previous DFE.

 

Fundamentally it’s…

8 Fundamentals _black

It’s been a really interesting week chatting to vendors and the press about our new software and services package for inkjet. In case you missed it, we’ve called it Fundamentals because it combines essential software components and engineering expertise that press vendors need to build a Digital Front End.

What’s the big deal you might say?  Well, The Times They Are A Changing to quote Bob Dylan both in terms of the progression of inkjet technology and the swing towards digital printing in the labels and packaging sector which is where we have focussed our initial offering of Fundamentals.

Thanks to our lengthy graphic arts experience – we’ve been supplying software to drive digital presses since 2002 – we are regularly approached by inkjet press vendors either to intervene at some point in an existing workflow or because they’re starting from a blank sheet of paper and need to figure out how to build a Digital Front End for a new press.

If they have an existing DFE a press vendor might be stuck on output quality, or maybe they can’t get the throughput in speed that they need. If they’re building a new press they might not know where to quickly source the components they need. Or often they can’t allocate enough engineering resource to the DFE when they need to. Plus it takes a very special skill set to know how to wire it all together.

How do we know all this? Because vendors tell us so. And Fundamentals is our response to this market demand. It offers best of breed software products with an engineering service that allows the press vendor to address their specific applications.

It will grow, of course. We are already looking at a Fundamentals software bundle for industrial inkjet for example. But the good news for press vendors is that we can do all of the above and then some!