We’ve just installed a new DI press, and I’ve been reading this forum for information about how to calibrate/profile the press. Everyone seems to be pushing different standards (SWOP, Graycol). But I’m wondering why I would want to limit my DI to a standard such as SWOP, when it can achieve much more. Wouldn’t I want to profile my press at it’s optimal settings (stable running condition) and then use profiles to control my colour from there? What are the downsides to this?
Thanks.
IF you don’t want to run to a standard but DO supply a profile for your press condition, I’m cool with that. Problem is, lots of printers don’t do either, in which case, producing the optimal CMYK numbers for customers is nearly impossible. If you conformed to say TR001, then anyone with the Photoshop U.S. Web Coated (SWOP) v2 profile would be good to go. So go ahead and exceed standards if you must but please provide communication about this process using an ICC profile that is freely distributed to those using the process.
You would still be ‘good to go’ using U.S. Web Coated (SWOP) v2. We always honour embedded profiles and convert them appropriately.
We tend to shy away from distributing output profiles because we need to be able to update them frequently if the press condition changes.
[quote="
t_username"]
You would still be ‘good to go’ using U.S. Web Coated (SWOP) v2. We always honour embedded profiles and convert them appropriately.
We tend to shy away from distributing output profiles because we need to be able to update them frequently if the press condition changes.
[/quote]
The U.S. Web Coated (SWOP) v2 profile assumes TR001 press conditions.
If the press is always changing, profiling is always going to be an issue. Better would be to profile the contract proofing system, keep it calibrated, then let the pressman tweak the press to match that. Then one profile will fly.
Pardon me for being a dummy, but I’m not that familiar with Press “colour management”. How do you have a proofing system if you don’t have a profile for your press? My guess would be that you proof SWOP/TR001 on your profiled proofer, but now you’re restricting your press to have to match your proofer (SWOP/TR001).
Could you not calibrate your press to it’s optimal colour reproduction settings and keep it stable through calibration? Then profile it and have your proofer proof that profile. If you get a SWOP CMYK file, then the proofer/press can simulate that. But if you get an AdobeRGB RGB file, the proofer/press is now not limited to the SWOP gamut.
Why limit your press to a standard when you got ICC profiles? Just characterize your devices.
[quote="
Pardon me for being a dummy, but I’m not that familiar with Press “colour management”. How do you have a proofing system if you don’t have a profile for your press? My guess would be that you proof SWOP/TR001 on your profiled proofer, but now you’re restricting your press to have to match your proofer (SWOP/TR001).
Could you not calibrate your press to it’s optimal colour reproduction settings and keep it stable through calibration? Then profile it and have your proofer proof that profile. If you get a SWOP CMYK file, then the proofer/press can simulate that. But if you get an AdobeRGB RGB file, the proofer/press is now not limited to the SWOP gamut.
Why limit your press to a standard when you got ICC profiles? Just characterize your devices.[/quote]
Press color management is just process control and some kind of profile that defines that behavior. You could force the press into a standard behavior such as TR001 which the original poster feels isn’t as compelling a story as producing what he feels is “optimal” behavior. Fine. But it still needs to be a consistent device and needs some description of that behavior. In addition, one could attempt (rightfully so) to have a contract proofing system that is equally consistent and matches this press. Or to put it another way, have the press produce color matching of the contract proofing system. In that scenario, the profile could be of the proofing device of which customers and others use to define how it produces color. Now its up to the pressman to match the proof. So going full circle, the profile doesn’t necessarily have to be built from the press but the press and the contract proof produce a color appearance expected from one profile (in this case, built from the contract proofing system).
So yes, you calibrate the press to its optimal color reproduction. You calibrate your proofer to match that and you profile the proofer.
Profiles don’t limit a press to anything, they simply describe a condition.
The question becomes, is a target condition such as TR001 limiting the press potential and if so, how much? Is having a standard a lot easier to communicate to others who may not have the profile? Why have printers said for so many years their presses conform to SWOP when they never did? All TR001 brought to the party was a measurable means of defining a condition that one would think is (based on the SWOP commette) a reasonable behavior.
Again, as a user, I have no problems if you wish to “exceed” a standard as long as you provide a way to produce that, using an ICC profile. But saying you’re going to exceed it and then say you can’t communicate that behavior because the device is changing it’s behavior doesn’t wash with me. If you have a device that’s always changing its behavior and you either can’t or will not “calibrate” it (quotes because this might be the process of the pressman getting the press to a consistent behavior), you have bigger problems than a lack of a profile. Color management can’t help but then again, you’re screwed anyway.
IF I send the same CMYK numbers to a press (or any device), shouldn’t I get the same color appearance evert time?
Yes, you have it correct that the press needs to be stable. But sometimes variables change (ink, paper, coating, blankets) and profiles need to be rebuilt. That’s not a big deal.
The problem with ‘match the proof’ is that this is a waterless DI press. I have no abiltiy to adjust colour on press. So I can’t play that game, and I think that it’s kind of a weird game to begin with. That’s like making colour the pressman’s problem, instead of a prepress problem.
No, I’m thinking create a press profile, then a proofer profile, then creating a device link between the two.
Well, that’s not right. We have HP inkjet printers that print with an amazingly huge gamut. We feed them files that are converted to U.S. Web Coated (SWOP) v2 all the time. If we just sent them through as CMYK numbers they would look terrible. But we don’t, we convert from the input profile (U.S. Web Coated (SWOP) v2) to the output profile (the device profile). This effectively limits the inkjet printer to reproducing only the colours availible in the U.S. Web Coated (SWOP) v2 gamut. Right?
What SWOP brought to the party was a standard for all web offset presses. So if it is a standard for all, then that means that it must be the definition of the poorest colour reproduction that is acceptable. If every press can hit the SWOP specification, then that means it is the lowest common denominator.
I’m not saying I can’t calibrate this press, or find a stable running condition. I’m staying I’d like to reserve the right to update my profile should any of my variables change. Maybe I find a new ink that works much better. Then I have to reprofile. I don’t want to have to redistribute 80 profiles to customers, that’s impossible to control.
What I’m saying is that I can exceed the standard (the way my inkjets do), but still ‘simulate’ the standard if someone has gone and converted all of their files using said standard. What do you do if you are runinng your press to TR001, and someone comes in with files converted to “EuroScale Coated.icc”. Do you recalibrate your press to EuroScale?
No, of course you shouldn’t. That’s one of the basic tenets of colour management. Device dependant CMYK values are not colours.
I understand you’ll have variables in inks, papers and so forth and this isn’t vastly different from other output processes even processes like film development where one needs to replenish chemistry to bring the process back to some baseline. The point is, the process has to appear to be a constant or we run into real problems.
As to profiles altering a process, that’s not the case. All a profile does is record the process. The reason your HP would look awful sending the file SWOP numbers is those numbers are absolutely not correct for that process. Yes it has a huge gamut and yes, if you profile that, you now define that color space. But the profile doesn’t alter that behavior. What yo need to do is of course convert the CMYK numbers optimized for SWOP to a new set of numeric values optimized for the HP such that it simulates the original process. The limitation was set when you converted the RGB data to SWOP not when you converted from SWOP to HP.
Using a device like would work, expect if one or both processes change from the original condition. So going back to square one, doesn’t matter if you use one or more profiles or a device link. They only produce a set of numbers that are supposed to describe a device condition and if the condition isn’t met, then it all falls apart. Back to process control. You could profile the process every day or for that matter every hour but unless someone has that profile to build those numbers and uses those numbers before the process changes again, it’s all just a big waste of time.
As for SWOP aiming for the lowest common dominator, that’s quite possible and as I’ve never owned a press let alone many, I simply can’t say how far the apple would fall from the tree. And I have no specific issue with people exceeding standards as long as they communicate what they are doing. There are reasons why having standards can work but I’ll fully admit that this could be at an expense of better behavior. But if you have the best behaving press on the planet and I send you the wrong numbers, the output is going to look far worse than if I sent the correct numbers for a process that is standardized. I’ll take the later over the former any day.
I understand process control, and the need for calibration/linearization. But I don’t understand why you say that re-profiling is going to cause changes in colour appearance. You send me a file that is a red square, converted to CMYK using your U.S. Web Coated (SWOP) v2 profile. I CONVERT that file to my output profile and print it on my press. Then I load a completely different ink, totally different setup and create a new output profile which characterizes this new process. Then I convert your original U.S. Web Coated file into my new press profile and print it out. The visual colour appearance will be exactly the same. Why would you (as a customer) care what profile I’m using? The colour appearance is the same.
Of course the profile doesn’t actually change the behavior of the machine. But by converting the values in your SWOP file to the values for the HP, I am effectively limiting the HP to only print colours within the gamut of SWOP.
This is exactly what I’m doing. Converting values to reproduce colours. And that’s why we never recommend to anyone to convert their files to U.S. Web Coated (SWOP) v2, because they are limiting their colours to a very small gamut.
Again, this is why we don’t distribute output profiles. You seem to be confused on the issue of converting from one colour space to another. If you build a CMYK value in U.S. Web Coated (SWOP) v2 colour space, we convert that colour into new values for whatever device we are outputting. You don’t need to know those final values, we know what your intended colour is.
Again, the customer is not going to even notice anything as long as they send files with attached ICC profiles of some sort. Be it U.S. Web Coated (SWOP) v2, Adobe RGB, EuroScale, Japan Standard, whatever. It’s the colours we are concerned with, not values.
Reprofling isn’t going to change color appearance its the fix for device drift however, if the next person doesn’t have that newer profile, the old profile is invalid which is of course problematic. If you’re doing all the work in house, no worries. Just tell the fellow running the conversions to toss the old profile and use the new one. Where it gets tough is anyone outside your shop. Ultimately the best solution is to keep the process in line, then the original profile is valid.
I don’t know why I’d send you a file in U.S. Web Coated (SWOP) v2 only to have you convert it again to some other flavor of CMYK. I mean, it could work but it’s a kludge. CMYK to CMYK conversions can be real problematic depending on the black generation of each. If your process isn’t anything but TR001, then no one should be using the U.S. Web Coated (SWOP) v2 or similar profile.
You say you’re supplying your profile, great. Then all I need to do is feed my RGB data to it and U.S. Web Coated (SWOP) v2 never enters (nor should it) the picture. But if your process is changing then I need the latest greatest profile before I convert. Obviously you can notify me everytime you change the profile and that’s going to be necessary.
In RGB yes, in CMYK OK but not at all ideal. If I send you a CMYK file separated for newsprint, you’re in a big world of hurt compared to sending the file in Adobe RGB (1998). Ideally the customer who knows how to use color management has the final output profile so they can decide what rendering intent is best per image and can edit the file in the output color space if necessary. They can proof your process on their output devices too. But there’s a world of difference sending you a separated file in CMYK for U.S. Web Coated (SWOP) v2 versus sending you a file in Adobe RGB (1998) plus in either case, that user can’t possibly soft proof your final process unless they have the final output profile.
The end user needs the final output profile. That profile has to define the current output conditions. Its as simple as that.
I agree. However, if the process changes out of our control, then the old profile is inaccurate anyhow. Hence a new profile. I don’t disagree that process control is paramount, however it’s not always possible to control all variables.
Welcome to Real World Printing. We are primarily a digital shop, with Xerox, HP, Lightjet, solvent printers, ect. Probably 90% of our CMYK files are separated using good ol’ U.S. Web Coated (SWOP) v2. The others are some other random CMYK profile. CMYK to CMYK conversions are not ideal, but I’d hardly go as far as referring to them as a ‘kludge’ or problematic. In fact, they work quite well, we use them all day long.
Yep. But why convert your images to CMYK? Just send me tagged Adobe RGB files. If you need s profile in order to softproof, that’s fine.
If a customer sends a file separated to newsprint, that’s their problem. We are printers, our job is to faithfully reproduce the file as we receive it.
OK, I see where you are going here. You actually care about your colour reproduction. I bet you have a calibrated monitor. This is a rare thing.
“Ideally” is the key word here. I would estimate less than 2% of our customers softproof or simulate our process on their output devices. Or even have an understanding of how to do so.
Why not do your softproofing/editing with the profile, then send the tagged AdobeRGB file?
If maximum colour reproduction is your goal, then we always recommend profiled RGB as your best bet.
But this is the thing: We also care about your colour reproduction. That’s why we don’t want to run TR001, because quite frankly, it sucks. We can do better.
And we also have calibrated monitors. And D50 lighting.
Yup. But the answer to ignorance is education. Part of that is supplying the profile and asking users to convert their RGB files, not some arbitrary CMYK color space. Or, go to the standard of which the Photoshop supply profile expects (TR001).
Or, have customers leave their images in tagged RGB, which is converted to the output profile when it’s ripped. That’s the ideal.
And again, there’s really not much difference in running TR001, or doing a CMYK/CMYK conversion from U.S. Web Coated (SWOP) v2 to an output profile. In fact, one could argue that because of the degree of tolerances in the TR001 specification, that creating an accurate custom profile and doing a conversion would probably result in higher accuracy overall.
I see you both have different philosophies for how the colour management workflow ought to be implemented. silversufer wants the printers/prepress to do all the important work, so the client doesn’t have to worry about it. andrewrodney wants the client to have all the control; the printers, then, just communicate how they print to the clients, the clients setup their files, and the printer just prints the files.
The problem I see with andrewrodney’s philosophy is that this sounds like a nightmare and unnecessary burden to place on the client. Suppose I’m a designer that works with multiple print houses (small format, large format, photographic, signage, screenprinting) and each print house has multiple devices. I must, then, have all the profiles from all these printers on all these devices (not to mention constantly updating them as they are updated) and determine beforehand which files are going to be printed on which devices then convert them all appropriately. Alternatively, every print house could force their device to conform to one standard (e.g. SWOP) and then the client could just work in that standard and be confident that every device in every print house prints the same. Neither choice seems ideal.
Would it not be better to have the clients work in a common working space like AdobeRGB and then let the printers convert the document depending on which device they are printing to?
I’m assuming that this can all apply to presses as well. (?)
It doesn’t have to be a black or white situation. There ARE clients (like most of the Photographers I work with) that want full control over the process and rendering of their images. Not a nightmare at all, they want a definition of the process. They need the profiles to define the process so they can see and edit the images as they see fit. Lest we forget, we’re just working with big piles of numbers when handling images on a computer. The numbers are either correct or they are not.
There are clients that don’t know a pixel from a pickle and want the printer to handle all the conversions from their RGB documents. That’s fine (and they should pay the printer for that service). You guys do need to educate them not to convert to some totally bizarre CMYK color space and expect you to “fix it”. Then the question becomes, can you deal with tagged RGB and can you educate them to tag the documents.
Photographers are used to standardized processes like E6, C41, RA4 etc. Doesn’t matter what lab you go to, as long as they are pro’s, the conform to standards. There are customers who want Costco to process their film or prints. Both customers have needs that the provider they work with must fill.
Too often, printers (4-color, prepress) doesn’t have the ability to handle both ends of this customer scale and I think that’s a big mistake. Its not too difficult to handle the designer who doesn’t know SWOP from SNAP. The tough part is getting files they can handle (hopefully tagged RGB not some incorrect CMYK recipe). But the color management savvy customer also needs to be treated correctly. That means they DO have a calibrated display, know how to setup Photoshop color settings, rely on a good soft proof and do want to edit their CMYK files in their proper output color space. That means either they or the service provider supply a profile. And again, the profile reflects a process that isn’t a moving target.
I can build a CMYK profile that will produce really good results as long as the provider keeps the process in line. I’ve been burned however with contract proofs that don’t match the press run or processes that deviate from how the profile was original generated (IOW, bad process control). Give me a good profile or control your process and I can build a good profile to produce the right CMYK numbers. But its not fair to expect all customers to drop $5000 on a Spectrophotometer and good software (sorry Steve) and build profiles for a device they don’t own and can’t control.
A client that works with multiple print houses should be provided multiple profile OR all the print houses actually conform to a standard, then they use one. See, standards can work, it’s been successful in the film world (real film or photo) for decades.
Yes, you could work in a common RGB space. That means you never see how the image will really output (soft proof) you never control the rendering intent, and you can’t edit the image based on the output device to appear as you wish. Oh, you can’t proof it in house either. I guess that’s not the worst situation but it doesn’t take today’s technology anywhere as far as it can go. You either care about these issues or you don’t. If you do, then you need that output profile. If you don’t, no worries, hand off the tagged RGB file and be done.