T-Shirt Forums - Reply to Topic

Hi, Unregistered. | Today's Posts

T-Shirt Forums
User Name

Register Today For Free!

Forgot Your Password?

Site Navigation

+   T-Shirt Forums > T-Shirt Industry Information > Direct to Garment (DTG) Inkjet Printing > DIY DTG > [DIY DTG] RIP Software Options
Thread: RIP Software Options Reply to Thread
Type Your Message Below:
Do NOT Post Self Promotional URLs (links to your website), Advertisements, or offer your services in the forum threads. It is against our Forum Guidelines.
Send Trackbacks to (Separate multiple URLs with spaces) :
Post Icons
You may choose an icon for your message from the following list:

Register Now

In order to be able to post messages on the T-Shirt Forums, you must first register.

Please enter your desired user name, your email address and other required details in the form below.

Your username must be between 2 and 16 characters and contain only letters and numbers (no special characters like hyphens, *, ', ~, etc)
User Name:
Please enter a password for your user account. Note that passwords are case-sensitive.
Confirm Password:
Email Address
Please enter a valid email address for yourself.

A confirmation email will be sent to this address, so please make sure it is accurate and that your email software is set to allow emails from our domain: t-shirtforums.com (sometimes the confirmation email gets accidently filtered into Yahoo/AOL/Hotmail/Gmail spam folders)

You won't be able to post until your email address has been confirmed. We take your privacy very seriously. Feel free to review our Privacy Policy in a new window.
Email Address:
First Name
It's nice to be able to be on a "first name" basis with the people you talk to in a forum. This is a totally optional field; if you like being on a first name basis, please enter your first name below :)


Additional Options
Miscellaneous Options
Fancy Media Options

Topic Review (Newest First)
December 6th, 2010 02:54 PM
Re: RIP Software Options

Very usefull read... How does a RIP work?
June 21, 1999

Laurel Brunner explains the workings of the Rip and its historic relevance at the crux of prepress working.
For many printers, digital prepress technologies are still shrouded in mystery, and perhaps none more so than that of the raster image processor, or Rip. And in addition to the wonders of the mighty Rip, we also keep hearing about the somewhat less mighty embedded controller. What is that all about one might ask, while thoughts of Thomas the Tank Engine's Fat Controller meander idly on the mind's lost horizons. In fact the answer is pretty basic: Rips and embedded controllers are essentially the same, but different. Confused? Well, be confused because Rip technologies are confusing, although they are definitely worth the effort of learning about.
Without Rip and printer controller technologies, the promise of printing anything anywhere with complete data, image and colour integrity is meaningless. As for variable information printing, or customised publications, or anything that manages digital data for output, it is all no more than a fine idea without the right Rip or controller technology. Raster image processors are at the heart of any digital prepress system regardless of location, application or attendant technologies. A raster image processor lays down pixels (picture elements) either on film or plate, on paper, or to the screen. Back in the dim, dark days of predigital prepress, the Rip was output device specific, which meant that for each digital typesetter a different black box technology was required to turn the collection of bits and bytes into screen or page-based content. With the advent of PostScript however, all that changed and Rip technologies started to evolve into something relevant for any output application.
PostScript is a page description language, and with its introduction, the desktop publishing revolution began, and the prepress sector has not been the same since. It was the introduction of the Apple LaserWriter in 1985 that gave the world the first PostScript printing device with an embedded controller. In basic terms, this baby Rip's job was to interpret the PostScript language code stream coming from the Apple Macintosh computer and into the printer, into raster dots at the printer's 300 dpi output resolution. In the same year, Linotype in its more than infinite wisdom, announced the Linotype 300 typesetter, and in so doing changed the face of graphic arts irrevocably. A powerful page description language combined with the means to interpret the language, and turn the instructions into image dots, meant that for the first time the same file could be output on devices from two different manufacturers. Thus was the imagesetter born.
With the advent of PostScript, no longer were Rip technologies intrinsic to the output devices they drove. The Rip's function was no longer merely to provide a bridge between specific front and back end systems where the number of known variables was fixed and the output resolution known. However, with PostScript Rips came a marauding hoard of new problems and, although these have been for the most part resolved with new versions of PostScript and more powerful hardwares, still persist. Inevitably, different PostScript Rips may interpret instructions differently and rather irritatingly, will not always produce the same output. Whether a Rip will output a file or otherwise depends on the file and its content.
The most basic form of Rip or embedded controller simply converts the dots on a computer screen into a series of dots on a simple line printer, where both image at 72 dpi. All that the controller has to do is to tell the line printer when to print a dot or not. However, if the output device is imaging at 300 dpi the control technology has to convert the 72 dpi screen resolution into 300 dpi and, by the way, ensure that the fonts are all rendered beautifully without jagged edges. This simple task is not desperately complicated, but it does require some clever programming; programming that has become incredibly sophisticated over the years. Before you try to work out the equation that turns 72 dpi into 300 dpi, bear in mind that each pixel could be made up of eight bits if it is to render 256 shades of grey. While you are wrestling with the calculator on that, consider the difficulties of rendering type at very small sizes, the problems of hairline rules, plus the problems of smooth blend rendering and screening. Muddled?
Indeed you should be; because this is why the money Rip vendors expect to get for their efforts is more than well earned. PostScript and Rip technology have truly changed the world and their twin evolution has spread to virtually every aspect of printed matter. In the general market, we have very basic embedded controller technology such as that found in office printers, most of which can be configured to be PostScript compatible devices. Further up the scale, we have colour copiers controlled with dedicated Rip systems such as the Image Technologies' product line, Electronics for Imaging's (EfI) Fiery, or Splash Technologies' Rip.
Output device specification
These dedicated systems are output device specific which has always seemed a touch retro, even though they are designed to get the best out of specific colour copiers. Their strength is in ensuring fast consistent colour output from printers that were not originally designed as dedicated printing engines. Their weakness lies in their device specificity: the Splash Rip only works with Xerox devices and the Fiery has to be configured for each printer it drives. Strangely, a single Fiery Rip cannot be set up to drive multiple output engines, even though EfI has Oem arrangements with most, if not all, major colour copier manufacturers. Colorbus does howver offer this feature driving both colour copiers and large fomrat inkjet printers from the same Rip. Perhaps that sort of functionality is coming with other suppliers?
In the graphic arts proper, Rip architectures are increasingly at the heart of digital workflow management, and as such there are several schools of thought regarding the best approach to Rip functions. In general terms they can be acronymically summarised as the Norm or Room approaches. Normalise Once Render Many (Norm) refers to a processing architecture whereby the PostScript language commands are interpreted to create the image of a page or pages. This interpreted file which can be PDF or a display list, can then be used as the basis for other actions such as defining traps, OPI or placing pages into an imposition. Perhaps the greatest proponent of the Norm architecture is Agfa, which has implemented a version of the Adobe Normaliser technology, to generate PDFs to provide the base format for Agfa's Apogee print production and workflow management system.
The Norm approach is not dissimilar to Harlequin's and Barco Graphics' approach whereby the data is interpreted, but not rendered. For example, Harlequin's ScriptWorks Rips, used by many Oems, create an interpreted file or display list, into which can be plugged additional modules such as those for trapping or colour management. Perhaps the best known implementation of this technology is Purup-Eskofot's New Age Rip used to drive its film and platesetters. In the Taiga Rip, Screen combines its own Rip structure with an implementation of Scriptworks, and Barco Graphics interprets incoming files to its GRO data format.
Separate contone and linework
Render Once Output Many (Room), was pioneered by Scitex with the Brisque Rips. The idea is that the file is interpreted to separate contone and linework elements which are then merged at output, with resolution and screening added at output according to the specific output requirements and device parameters. This has also been the basic approach taken by Heidelberg with Delta which interprets the incoming file and creates a compressed contone rasterised file. The main argument for Room is that it ensures absolute output integrity across devices because the file is already rendered.
But, because Room works with interpreted and rendered files (though not screened), the file sizes are large which can be cumbersome around a network. Also, there is some question as to the data integrity of files which are downsampled, for example for proofing purposes. Despite the different approaches in terms of architecture, increasingly there is consensus among developers that the Rip is the place where certain tasks should be executed, such as using job tickets for imposition instructions, OPI and trapping. With Harlequin now able to divide a Rip across a number of platforms, the big question is where that Rip should be placed.
EfI founder Efi Arazi, who also founded Scitex, was once asked the difference between what he did with Scitex and what he was doing with EfI. His answer summed up the difference between what specialised Rips and their more generalised counterparts do. He said: "When you want to blow your nose, it is quite a wonderful experience to use a fine Irish linen mouchoir. It's marvellous, soft, effective, it's a joy, the best. But a Kleenex tissue is a lot easier and far more of us use tissues than linen handkerchiefs." There are, fortunately, Rip technologies at all points along the scale and whether your business needs the finesse of a mouchoir or the tissue, you can be sure that there is a technology to suit. and there is the knowledge available to to help get the best out of our Rip architectures.
April 15th, 2010 06:14 AM
Re: RIP Software Options

While this thread is related to RIPs I wanted to provide a link to another useful piece of software. Justin shared a tip for keeping your print heads from clogging. Basically one only needs to print a small job daily to help prevent the heads from drying out... Very good tip indeed. Here is a little freeware application that someone wrote to just that thing!

Keep Your InkJet Print Head Clean - CodeProject


Bob ?;O)
March 29th, 2010 12:05 PM
Re: RIP Software Options

I don't believe the fellow that says he was printing using open source software was printing from Gutenprint. The Gutenprint plugin can not print layers. Any ideas?

Bob ?;O)
March 10th, 2010 06:00 PM
Re: RIP Software Options

Anyone got colorburst windows version to work with the epson 2200...its not supported in the windows version for some reason but it for the mac...if so what profile/enviorment did you use..
February 11th, 2010 09:33 AM
Re: RIP Software Options

Note: I haven't actually done this...

I have been researching this for some time and I think I may have a solution for the necessity of a RIP... There are a few developments in open source software that you might find helpful.

1) Gutenprint - While Gutenprint alone will not necessarily solve our problems, its existence is quite beneficial since they have created many print drivers for the Epsons we love.

2) Gimp - Gimp is an open source image editing program ( A poor man's Photoshop)...

GIMP - The GNU Image Manipulation Program

3) Gutenprint for Windows - A plugin for Gimp that allows us to use the Gutenprint print drivers

Gutenprint for windows | GIMP Plugin Registry

4) GPLin - A tool that allows us to get grandular control over the print channels in Gutenprint.

Black Five Imaging - GPLin - experimental linearization software for Gutenprint

I believe that in Linux these tools could be used together to gain the control needed to print white on dark using the excess channels on our Epson printers. On Windows, using Gimp, it may be possible to perform the same tasks.

Since I don't have a working model to demo I can't verify these actually do what I expect. Perhaps if you are already there and are looking for a solution these might be helpful.

Bob ?;O)
December 16th, 2009 12:52 AM
Re: RIP Software Options

Their site have a bit more expensive prices....

Pjannto Software, Produktliste, Deutschland

Has anyone used the Epson RIP?

Epson StylusRIP Professional 2.0 for the Epson Stylus Photo 2200, Overview - Product Information - Epson America, Inc.
December 11th, 2009 09:18 PM
Re: RIP Software Options

This sounds toooo gooood to be true... A Software RIP for $1.90 and supports Epson printers...

Pjannto RIP Print & Cut Suite - Free software downloads and software reviews - CNET Download.com
December 8th, 2009 05:24 PM
Re: RIP Software Options

I comprimised and built mine from a Kit. It prints white just fine. It's based on an Epson 2200 printer. The bed is reset by hand but it is resetable to .001 inches or better, because it has a direct belt drive. Which is better than most automatic machines that reset to around .005, either is great, but a good RIP is a requirement, the RIP also contains the choke settings which will shrink the white layer to keep it from peeking out. Provides auto mask capability, cannot imagine doing white without that. I use Cobra RIP. Power RIP, Cobra Rip, DTG RIP Pro, MultiRIP GP are all about the same, written by the same programmer, excellent program for DTG, produces excellent output, differences are price and printer profiles, Higher the price the more support you will from the vendor. Depends on your needs and how smart you are. Mark has produced some excellent videos on MultiRIP GP . PM me for specifics on my setup.
December 8th, 2009 12:42 PM
Re: RIP Software Options

That would be great... RIP software is pretty advanced so one might understand why there isn't anything free... I wonder if you were to use the Ghostprint and manipulate the separations or something...
December 8th, 2009 11:58 AM
Re: RIP Software Options


Does anyone know if there are any free rip software available? I have an Epson 4400 printer and can't obtian the correct colours when printing dyesublimation inks.

I would appritiate any help on this matter.


August 14th, 2009 08:03 AM
Re: RIP Software Options

I knew this thread would eventually provide some useful information... Thanks guys, the two of you have both opened up some very good possibilities.

Bob ?;O)
August 14th, 2009 07:20 AM
Re: RIP Software Options

Try to visit ICC Resource Center.

There are several useful tools, in particular Huang Zeng's icc profile inspector. With the profile inspector, you can doubleclick on the curves, export, modify and import them. In this way, you can modify a CMYK profile, so e.g. the cyan channel alone can be converted to black. Than you can attach the profile to a color postscript driver, and in this way get separations from any program, that can send output to a postscript printer.

The sample profile dumper may also be useful.
You should also visit LittleCms, Great color at small footprint. There are utilities you can use to chain together profiles.
You can find a standalone CMS system at Argyll Color Management System Home Page.
August 14th, 2009 06:16 AM
Re: RIP Software Options

Originally Posted by DrakeRemory
Hi, I'm facing the same problem right now. I build an Epson 1400 DIYDTG. I found the open source driver Gutenprint, which is available for Linux and also for Windows as a GIMP pluigin. I didn't have the time to really play around with it, but as far as I could see it should be rather simple to add new profiles for an Espon DIYDTG that will address the right channels. I will keep on working on that. Maybe someone is willing to help.
Smashing... Haven't had time to deal with this but please share the new profile if you get it working....

Thanks! ?;O)
August 14th, 2009 02:28 AM
Re: RIP Software Options

Hi, I'm facing the same problem right now. I build an Epson 1400 DIYDTG. I found the open source driver Gutenprint, which is available for Linux and also for Windows as a GIMP pluigin. I didn't have the time to really play around with it, but as far as I could see it should be rather simple to add new profiles for an Espon DIYDTG that will address the right channels. I will keep on working on that. Maybe someone is willing to help.
April 26th, 2009 11:52 AM
Re: RIP Software Options

Originally Posted by Naga
Remember you have to interface with a lot of libraries, all written in c++ or c.
I hope you are aware how big a project it is.
Be aware that most people who "has made a RIP", are actually just licensing the RIP engine from Artifex (Ghostscript), EFI or a few others.
Nope, don't think that is necessary... We aren't talking of the old school type of RIP which necessarily relies on postscript. There are other technologies and ways of getting things done... It will be a task but it isn't as overwhelming as you make it. First you don't need postscript... You would if you wanted to make screens separations but you are simply printing a raster image to a printer. No need for the extra complexity. Secondly, Epson provides the language specifications freely. The challenge is in controlling the print channels which have nothing to do with the postscript language. Lastly, you only have to use C or C++ if you have to borrow someone elses code. There is more than one way to skin a cat. I am forever an optimist and I usually complete what I set out to do in a straightforward manner. Thanks for the feedback... Are you trying to write a RIP?

Bob ?;O)
This thread has more than 15 replies. Click here to review the whole thread.

Posting Rules

Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -8. The time now is 09:16 AM.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2020, vBulletin Solutions, Inc.
vBulletin Security provided by vBSecurity v2.2.2 (Pro) - vBulletin Mods & Addons Copyright © 2020 DragonByte Technologies Ltd.
Copyright 2004-2014 T-ShirtForums.com. All rights reserved.