Assigning a profile via Image > Mode > Assign Profile yields different results than previewing a profile using Proof Setup via View > Proof Setup > Custom.
What needs to be changed to make these identically match?
I’m not converting the images’ profiles.
I’ve read a lot on this before posting (Bruce Fraser, etc.) but must be missing something (hopefully not too obvious) because I don’t see any mention on how to get them to be identical if they are off. Therefore… which one should be trusted without having to do trial-and-error printouts ad infinitum? It would help to be able to get closer proofing for different paper stocks.
Learn how to rescue details, remove flyaways, add volume, and enhance the definition of hair in any photo. We break down every tool and technique in Photoshop to get picture-perfect hair, every time.
Assigning a profile is attaching a color appearance to the numbers in the document.
Proof Setup is mainly about previewing Conversions, not assignments.
Consider the text string
gift
If you interpret the string as English, it means a present
If you interpret the string as German, it means a poison
It’s the same 4 characters either way.
Saying "this is English" or "this is German" is like assigning a profileyou aren’t changing the characters, you’re just assigning an interpretation to them.
Converting to a profile, on the other hand, is like doing a translation that preserves the meaning.
If I take the string ‘gift’ and Assign German to it, I get the string ‘gift’ meaning poison.
If I take the string ‘gift’ with English Assigned to it, and Convert to german, I get the string ‘geschenk’ meaning a present.
Proof Setup lets you preview Conversions, rather than Assignments. Converting to a profile should generally produce a different result from assigning a profile. You need to get the distinction between assigning and converting clear.
Bruce’s explanation is –and has always been– crystal clear to me. However, I have no way of gauging whether it has the same impact on someone who is not proficient in the two languages involved.
Just think of Soft Proof (View > Proof Setup) as something telling you "this is what you can expect in print if you use this ink/paper/printer combination".
Assigning a profile to an untagged file is like guessing what the creator of the image file had in mind but forgot to tell you what language (color space profile) he was using when he created, manipulated and saved the image.
As a matter of fact, Ronald, with a lot of (most) ink/paper/printer-combination profiles, View > Proof Setup should look DIFFERENT, as the printed copy on paper will not look like what your monitor can display.
Since the assigned profile can display an image that is so far from what the conversion will actually be… is its purpose mainly for guessing at what untagged files’ profiles perhaps should have been?
It seems that assigning a profile is a little like finding the word gift completely out of context, and taking a stab at maybe it may mean present, and maybe it may mean poison.
Whereas viewing soft proofs are similar to finding the word ‘gift’ translated correctly and unambiguously into German… ?
….with a lot of (most) ink/paper/printer-combination profiles, View > Proof Setup should look DIFFERENT, as the printed copy on paper will not look like what your monitor can display.
Ramon
Wouldn’t that make soft proofing nearly useless then? That is — other than only to get you somewhere in the vicinity of the actual print out. Not to argue the point but… it would then seem that Adobe is deceiving us by including soft proofing that imparts such subtle changes to the images viewed when the profiles are changed. I realize that print outs are the only real way but I would hope that soft proofing is not only for a somewhere-in-the-ballpark approach.
…with a lot of (most) ink/paper/printer-combination profiles, View > Proof Setup should look DIFFERENT, as the printed copy on paper will not look like what your monitor can display. Ramon
Wouldn’t that make soft proofing nearly useless then? That is — other than only to get you somewhere in the vicinity of the actual print out. Not to argue the point but… it would then seem that Adobe is deceiving us by including soft proofing that imparts such subtle changes to the images viewed when the profiles are changed. I realize that print outs are the only real way but I would hope that soft proofing is not only for a somewhere-in-the-ballpark approach.
Quite the opposite, Ronald! That is precisely what makes Proof View so incredibly valuable. Depending on your ink/paper/printer-combination profile, the change you see can even be far from subtle. The image literally dies before your eyes as soon as you apply the soft proof view profile.
With certain ink/paper/printer-combination profiles the change may be not quite as drastic (that’s what happens with the Pictorico Photo Gallery Glossy Paper profile on my 2200), but with other papers (watercolor art paper, for instance) the change can be quite substantial.
The reason this is so valuable is that it’s at that point that you apply whatever corrections are necessary to your image so that the print comes out exactly like you intend it to look.
By the way, the title of this thread can be misleading. It’s not a question of "Assign Profile versus Soft Proofing". It should be "Assign Profile AND Soft Proofing".
First you get a tagged image file (i. e. a file with a proper profile embedded), then you work on your image, AND then go to View > Proof Setup, apply the correct paper profile for your ink and paper to watch your image "die" on you on your monitor, so you can then fine tune the image to print as intended.
If everyone played nice and embedded profiles so that we knew what colors the numbers were supposed to represent, Assign Profile would be either unnecessary or an expert feature for total geeks.
Yes, soft-proofing should be similar to finding the word ‘gift’ translated unambiguously into German.
As far as matching the hard copy goes, I firmly believe that you can get much closer than ‘somewhere in the ballpark’ but a lot of factors come into play.
First, as with all color management, the various devices need to behave the way their profiles say they do. Since the soft proof is a product of at least three profilesthe document space, the printer, and the monitorif any one of those is off, so will be the soft proof.
Second, the laws of physics come into play. Most printing devices can print colors that your monitor can’t display, particularly in the region of dark, saturated cyans and greens.
Third, and often overlooked, is the lighting you use to evaluate the print. Ideally, you need to balance the amount of light falling on the print to the amount of light being emitted by the monitor.
Fourth is learning to interpret the proof. The only time I ever saw a proof that really matched the manufactured product, it was a press proof (think: pre$$ proof). Matchprints were always contrasty and usually abit pink, but we learned to filter out the discrepancy.
There’s some learning involved in relating a glowing self-luminous image on a display to a reflective hard copy. But quite honestly, the Sony Artisan is thus far the most reliable proofing system I’ve worked with, and that includes Kodak Approvals and Creo Spectrums as well as all the old analog stuff.
What is your test file’s correct embedded SourceSpace?
I ask because there is no logic in Assigning the wrong Profile to a file…it is instantly hosed.
With a (correctly) embedded tag on a test file:
Image> Mode > Assign (any other) Profile hoses the file
From any (correctly) embedded SourceFile, the ONLY space move we can make is Image> Mode> CONVERT to (Target) Profile (ColorSpace) — then as Ramón says, SoftProof the Target device profile.
Since the soft proof is a product of at least three profilesthe document space, the printer, and the monitorif any one of those is off, so will be the soft proof.
Bruce
It seems like the weak link may be the printer profile. Few canned profiles seem to be very exact. It seems that creating custom printer profiles would make the soft proofing much more accurate. As you’ve written about.
Depending on your ink/paper/printer-combination profile, the change you see can even be far from subtle.
Ramon
Yes I realize that… it’s just that. It’s when you said…
….as the printed copy on paper will not look like what your monitor can display.
…. it appeared that this was such a generalization that it seemed you were implying that soft proofing was an exercise in futility.
G
My work space is Adobe RGB (1998) with a Proof Setup of Working CMYK.
What got me wondering about this is that (out of curiosity) I assigned profiles of paper stock via Image > Mode > Assign Profile to already correctly tagged PSD files.
When I saw that the results displayed were sometimes very obviously different from the display via View > Proof Setup > Custom it made me more than a little curious and I mistakenly assumed that they should look identical.
The image literally dies before your eyes as soon as you apply the soft proof view profile.
Ramon
By this I take it you mean that your eyes color correct for the gamut.
But you can have many windows opened of the same file — each displaying a different soft proof (as Bruce has written about) — so you can compare them side-by-side. This helps to offset any adjusting your eyes try to do.
Depending on your ink/paper/printer-combination profile, the change you see can even be far from subtle.
Ramon
Yes I realize that… it’s just that… it’s when you said…
…as the printed copy on paper will not look like what your monitor can display.
… it appeared that this was such a generalization that it seemed you were implying that soft proofing was an exercise in futility.
That’s because you are taking that part of the sentence out of context.
Here’s what I wrote:
As a matter of fact, Ronald, with a lot of (most) ink/paper/printer-combination profiles, View > Proof Setup should look DIFFERENT, as the printed copy on paper will not look like what your monitor can display.
[Emphasis added]
What I was referencing was the difference between what the monitor displays before you go to to Proof Setup and what you would get on paper if you do not apply any corrections whatsoever.
(out of curiosity) I assigned profiles of paper stock via Image > Mode
Assign Profile to already correctly tagged PSD files.
That, of course, wrecks the file immediately and unavoidably. It has nothing to do with "View > Proof Setup > Custom". There’s no way you should EVER get those two to look alike, let alone identical. 🙂
It seems that creating custom printer profiles would make the soft proofing much more accurate.
But of course, absolutely! It does. Some canned profiles can be pretty good, but custom made profiles for your specific printer (the unit itself, not the model number in general), your specific inks and your specific paper are ideal. That’s why we pay good money for such custom profiles. 🙂
By this I take it you mean that your eyes color correct for the gamut.
But you can have many windows opened of the same file — each displaying a different soft proof (as Bruce has written about) — so you can compare them side-by-side. This helps to offset any adjusting your eyes try to do.
(out of curiosity) I assigned profiles of paper stock via Image > Mode
Assign Profile to already correctly tagged PSD files.
That, of course, wrecks the file immediately and unavoidably.
Ramon
Not actually… I never saved them with the assigned profile. <g>
Oh, yes, the image gets immediately and unavoidably wrecked as soon as you assign a different profile to an already correctly tagged image file –not permanently if you don’t save, of course, but immediately and unavoidably wrecked all the same.
If the SourceFile was last saved in the AdobeRGB ColorSpace — tagged or untagged — and we reopen it (do not color manage it) and Image> Mode> Assign any other profile than AdobeRGB:
We have indeed just hosed the file.
Likewise, if the SourceFile was last saved in the sRGB Colorspace — tagged or untagged — and we reopen it (do not color manage it) and Image> Mode> Assign any other profile than sRGB:
We have indeed just hosed the file.
Photoshop HAS to know the true SourceSpace BEFORE anything good can happen.
There are only three ways Photoshop can know the SourceSpace of the SourceFile:
1) The file is tagged, we honor the tag.
2) We Photoshop> Image> Mode> ASSIGN (the correct) Profile.
3) The file’s SourceSpace EQUALS Photoshop’s working space (by chance).
Me: I didn’t save the files with an assigned profile… therefore to me they weren’t hosed. You: They were hosed when I assigned a profile even though it isn’t a permanent hosing.
Very interesting. As far as I was able to determine in my very shallow investigation of some of the controversies surrounding L*a*b convinced me to stay away from it.
Here’s an excerpt from the link below:
"Another interesting observation from the table relates to native Lab encoding. The established methods of integer encoding of Lab color (Lab TIFF, ICC, Photoshop) will clip some of the Lab Gamut. But even more devastating than that is the gross coding inefficiency (only 35%). This means that nearly two-thirds of Lab coding space is wasted on colors that do not even exist. This may be seen here. This inefficiency "squeezes" real colors tightly together, resulting in possible quantization losses. So converting an image into Lab for the purposes of applying a color correction in Photoshop can severely reduce the number of unique colors in your image. This is discussed further here. Whether this is a significant loss depends on the particular situation, but you should at least be aware of it."
There’s an awful lot of numbers and technical stuff there, but the bottom line was that it reinforced my fears that the implementation of LAB in practice, more than the theory involved, could indeed lead to losses in detail and quality. Since I’m far from qualified to know how significant the problem is or can be, I just decided to stay away from L*a*b.
Don’t get me wrong, but I only do a LAB workflow for 8 bit drum scanning. If my scanner software were 16 bit, I’d take ProPhoto RGB 16 bit ANY DAY over LAB. I choose LAB scans because I don’t have a choice for the most part.
LAB has many rounding errors that are unavoidable due to color mapping and compression into a CMYK 8 bit color space. Go ask Bruce, he likes to ramble off facts and figures. My focus is implementation and workflows.
LAB offers a mono color space to work from and is a common language for most high end commercial scanners.
If we open a tagged AdobeRGB file, honor the tag — then — Image> Mode> Assign any other profile than AdobeRGB: We have indeed just hosed the file. If we open a tagged sRGB file, honor the tag — then — Image> Mode> Assign any other profile than sRGB: We have indeed just hosed the file.
Could we get a definition of "hosed"? i assume it doesn’t mean clean a dirty picture.
When I assign different profiles to an RGB image, whether it’s been tagged or not, the preview changes but the RGB numbers don’t, so I don’t think the image has been damaged in anyway–it’s just my interpretation of what it looks like has changed.
Hosed = changing the meaning of the numbers via a profile without consent or knowledge.
Like Bruce has said:
Color mgnt does two things,
1. By assigning a profile, you are giving a meaning to the numbers or changing the meaning from one space to the next. (numbers stay the same, but the meaning changes)
2. By converting the numbers, you are change the numbers.
They both can hose you if you don’t know what you are doing.
They both can help you if you know where and when to do so.
What MO (and Bruce said) — changed, knocked it out of original color balance.
Open any file in PS:
Image> Mode> Assign (sRGB) Profile
Image> Mode> Assign (AdobeRGB) Profile
Image> Mode> Assign (AppleRGB) Profile
Image> Mode> Assign (MonitorRGB) Profile
NOTICE THE FILE CHANGES becauce we are telling Photoshop the file is in different ColorSpaces…PS is basing its understanding of the SourceFile on different "numbers," different color "maps." BTW, this is "fishing" around for the best profile — Bruce’s Mystery Meat analogy.
Not to trick you 🙂 but:
Open any file in PS:
Image> Mode> Convert to (sRGB) Profile
Image> Mode> Convert to (AdobeRGB) Profile
Image> Mode> Convert to (AppleRGB) Profile
Image> Mode> Convert to (MonitorRGB) Profile
NOTICE THE FILE DOES not CHANGE" This is because Photoshop knows the SourceSpace, and is merely CONVERTING to TargetSpaces — whilst all the time Converting SourceSpace> MonitorRGB, on-the-fly, (so’s we can PROOF it accurately on the monitor)…
Not tricking me at all–that’s my point, there’s a huge difference between converting to a profile and assigning a profile. Assigning different profiles will not change the values in the file itself, it will effect the new values if there is a conversion made to a new color space, but the conversion has to be made for that to happen and there is no conversion when you assign.
I understood it before. Convert to Profile potentially "hoses" the file depending on how it is done–it’s the same as making a color correction. Assigning does nothing to the file other than embedding a new tag–doesn’t damage the file at all because the original values are maintained, just changes the way it is displayed.
You could change profiles a thousand times via Assign Profile and the image would not degrade, but if you did a thousand Convert to Profiles the image would be damged in the same way as if you did a thousand curve corrections.
Assigning different or wrong profiles "hoses" the accuracy of the color mangement setup but doesn’t touch the file’s values. If you start with an RGB file tagged with Adobe RGB and assign 10 different tags, come back to Adobe RGB and look at the file’s histogram it’s identical every step of the way–how the file is color managed changes not the file. My definition of a hosed file is that it’s values have changed. Do the same experiment with Convert to Profile and the histogram will change at every conversion including the final back to Adobe RGB.
–>You could change profiles a thousand times via Assign Profile and the image would not degrade
Inasmuch as the numbers in the file wouldn’t change, this is true. But it would display incorrectly, and convert to any other space incorrectly, so it’s fair to say that while the integrity of the data hasn’t been compromised, and you can rescue the file by assigning the correct profile, for all practical purposes, it’s hosed.
Yes, and assigning the wrong profile guarantees a bad conversion down stream.
I’ve seen more files wrecked by people opening perfectly good tagged files and either stripping the profile deliberately, having the software set up to discard the embedded profile, or using some antedeluvian version of Photoshop that doesn’t understand profiles, than from any other cause.
If I ruled the world, Assign Profile would be only be enabled for already-tagged files if the user correctly answered 100 or so fairly tough color managent questions, and signed a waiver. It’s fine for people who know what they’re doing to experiment with Assign Profile, but it’s really an expert feature…
if a file comes in with the wrong profile embedded, most color-managed users will assume it’s a bad file and start hammering on it (or use it as is).
more savvy users will start Assigning various color spaces to see if the color improves…
if a file is Converted to the wrong space (with the profile intact), at least Photoshop will understand the file and be able to correctly Convert, including to the monitor.
on the dark side:
if a caveman, an old-school dog, the persons who hose AdobeRGB on a daily basis, opens the file, he will hose RGB in most cases — anyway…
Except you would have to guess what the original correct profile was.
Unless you knew where it was originated and could ask for the source profile, but that would be quite the leap of faith. Of course believing in an embedded profile from an unknown source requires a fair amount of faith anyway.
It’s actually fairly hard to embed the wrong profile UNLESS you dick around with Assign Profile. Most of the people I hear say that you can’t trust embedded profiles from unknown sources are making lame excuses for having color management broken at an institutional or enterprise level.
you can’t trust embedded profiles from unknown sources
That’s the first time I heard that.
More likely he can’t trust his own monitor to PROOF it (and his own broken workflow to Convert it).
In any case — simply — opening an RGB file in Photoshop, HONORING the embedded profile, and PROOFing (viewing) it on a calibrated, profiled, accurate monitor will tell you one way or the other how good the file is.
it’s actually fairly hard to embed the wrong profile UNLESS you dick around with Assign Profile.
Well how about this; the originator of the files works in Adobe RGB and tags the file accordingly (BTW, I’ve never suggested files shouldn’t be tagged) but he either hasn’t calibrated his monitor or has the wrong display profile loaded (how would I know that?) So, according to Bruce’s earlier post —
the soft proof is a product of at least three profilesthe document space, the printer, and the monitorif any one of those is off, so will be the soft proof.
which I agree with–the originator of the file doesn’t have an accurate soft proof, but color corrects to taste anyway. If I open that file and honor the Adobe RGB tag on my correctly calibrated and tagged display I’m not seeing the same color, so the Adobe RGB tag could be deceiving me depending on how far off the original monitor is.
I open that file and honor the Adobe RGB tag on my correctly calibrated…display
I’m not seeing the same color
Then the person who balanced the file has a bad monitor profile. Period (for all practical purposes).
so the Adobe RGB tag could be deceiving me
Actually, a tag allows us to accurately view the source file on screen and Convert it to other spaces — how is the tag deceiving you (unless you have a bad monitor or bad target profiles)?
I agree with–the originator of the file doesn’t have an accurate soft
proof
If the originator doesn’t have a good monitor profile s/he does not have the ability to accurately SoftProof in Photoshop. Photoshop’s SoftProof feature is based on an accurate monitor profile.
You should be able to change it, but not discard the tag.
Tags are only useful if the file needs to be edited downstream. I never assign tags to CMYK files because they are built for a single output device and I want to be sure my numbers are the output numbers. Tagging the file increases the risk of a CMYK to CMYK conversion whether, it’s inadvertent or not, on the printers end.
Rob) I never assign tags to CMYK files because they are built for a
single output device and I want to be sure my numbers are the output numbers.
I have the feeling Rob knows the output device, can trust the people he hands the file to, and doesn’t want anyone dinking with his numbers.
Good and smart under that scenerio.
The trouble with handing off untagged anything — or recommending that approach — when we don’t know the output device or can’t trust the people we are handing the file to not dink with it — is the color will likely get hosed (when the genius downstream opens it or Converts it)…
Actually, a tag allows us to accurately view the source file on screen — how is it deceiving you (unless you have a bad monitor profile)?
well, the purpose of the RGB tag is to display a file’s color the same from one screen to the next, but only on the assumption that the monitor tag is accurate on both systems. If the originator doesn’t have an accurate monitor profile loaded in System Preferences>Displays>Color we won’t be seeing the same color–for it to work we BOTH have to have an accurate monitor profile loaded in Displays
If the originator doesn’t have a good monitor profile s/he does not have the ability to accurately SoftProof in Photoshop. SoftProff is based on an accurate monitor profile.
Right, that’s my point: she’s made a bad color correction because her soft proof is not accurate and I don’t know what she intended because we are not seeing the same color despite the fact that we are both in Adobe RGB.
Tagging necessary to communicate color. It’s not sufficient…
(I don’t tag DeviceCMYK when I know it’s going straight to the device, either. But if it isn’t going straight to the device, the final output is someone else’s responsibility, and unless I know that it’s going to cause a screaming disaster because the recipient is clueless, I tag, because that way the recipient has a clue as to the intended color.)
Well, I don’t ever mess with CMYK files, but if I ever did, I certainly wouldn’t want to work with someone who doesn’t tag his files.
I can see that, but consider this: You have a print project with both full color CMYK and grayscale images you want to print as quad CMYK to get more dynamic range. The sophisticated approach would be to separate the grayscales with a Heavy Black Generation so you get a long black plate and avoid color shifts on press, and separate the color with light black generation and avoid too much black. You dutifully assign the different profiles and place the files in InDesign. At print time Color Mangement is on and default US Coated SWOP is chosen by the printer in the print driver. ALL of your separations are going to get blown off and you will get a CMYK to CMYK conversion–no more light or heavy black plate.
Without a tag you will maintain the original separated values.
But if it isn’t going straight to the device, the final output is someone
else’s responsibility
but that begs the question, why convert to CMYK at all. If you don’t want to be responsible for the CMYK, send RGB and let the conversion happen in the print driver via whatever CMYK tag they think works. The problem with a CMYK to CMYK conversion at print time is that the numbers in the file no longer match the numbers on the plate. Who wants to sort that out?
This is a bit off topic, but is there a way on a Mac to scroll through the assigned profiles? I’ve noticed that with a PC you can use the scrolling wheel to look through profiles to see which one you want to assign (after highlighting the box where you choose the profile to assign. I rarely assign profiles in such a manner, but it is handy if you want to intentionally hose the profile (on a copy of a file) in order to get either a better looking picture or an intentionally bad (for example, to give a certain "look") image.
<< At print time Color Mangement is on and default US Coated SWOP is chosen by the printer in the print driver. ALL of your separations are going to get blown off and you will get a CMYK to CMYK conversion–no more light or heavy black plate. >>
Which is why it is better to send a PDF (instead of the InDesign file) and to make the PDF using "Leave Color Unchanged" in the Advanced dialog.
–>but that begs the question, why convert to CMYK at all. If you don’t want to be responsible for the CMYK, send RGB and let the conversion happen in the print driver via whatever CMYK tag they think works.
Cause color usually sucks big time!
If most printers and service bureaus (and even RGB photo labs with digital output devices) had a clue about how to handle your tagged RGB file using good output profiles, that would work just fine. Problem is, they don’t.
Which is why it is better to send a PDF (instead of the InDesign file) and to make the PDF using "Leave Color Unchanged" in the Advanced dialog.
Ann, you would think that would work, but all my testing shows that when exporting a PDF, files stay untouched if they are not tagged, and if the embedded tag matches your current CMYK working space at the time of export. Any file with a different tag gets converted. So, it would be easy to have unintended conversions if EVERYTHING isn’t tagged consistently when color mangement is on. If you turn off color mangement what you suggest should work.
You also need to leave "Include ICC Profiles" unchecked in the Advanced dialog. And send hard copy proofs with the CD too.
I do this for Press advertising and it works extremely well but i do have the advantage of still being able to "proof" print on an Epson 1270 using PressReady which provides virtual "Contract Proof" output.
–>but that begs the question, why convert to CMYK at all.
Because people who ask for CMYK are almost invariably totally unqualified to even look at an RGB file. I work in ProPhoto RGB. There are about 5 shops in the country I’d consider sending a ProPhoto RGB file to. For the rest, it’s courting disaster.
1. Set working space in Photoshop to ProPhoto RGB 2. Open ProPhoto RGB image in matched working space. 3. Edit/Proof/Etc. 4. Convert to output device colour space 5. Print
….Disaster? Am I missing something? I sure hope not. I use this working space most of the time now. Works great with the RAW workflow I am using. Sure can give some scary looking thumbnails in the FB tho!
You also need to leave "Include ICC Profiles" unchecked in the Advanced dialog. And send hard copy proofs with the CD too.
Ann, That didn’t work for me. If you try this you can see what happens:
Set your Color Setting to US Prepress Defaults in both ID and Photoshop. In Photoshop make a file with a square of 0|0|0|100 (make sure only the K channel is filled) next to a square of 100% cyan–this file makes a CMYK to CMYK conversion easy to spot later. Save the file and make sure Embed Color Profile: US Web Coated SWOP is checked. Do a Save As with a new name but this time uncheck embed profile so the file is untagged. Place the 2 files in ID. If you check the file’s link info the untagged file should show NA next to profile, while the tagged file should show US Web Coated.
If a conversion is taking place it will be easy to spot because the black square will become a 4-color mix. To maintain the original values of the tagged file when you export to PDF you have to either assign the same tag that’s with the PS file to the ID file or, if the ID file is untagged, the working CMYK has to be set to the same profile. So, it would be impossible to stop some conversion if there were placed files with different tags. If you want to be absolutely certain a conversion won’t happen you would have to leave everything untagged or, all the placed files AND the ID file would have to have the same tag.
Because people who ask for CMYK are almost invariably totally unqualified to even look at an RGB file. I work in ProPhoto RGB. There are about 5 shops in the country I’d consider sending a ProPhoto RGB file to. For the rest, it’s courting disaster.
So, you don’t have a clue what the CMYK should be but you’re going to make the conversion anyway? With what profile–default SWOP? That’s going to blow away any advantages the ProPhoto space has, and then you’re going to ask the printer to correct the CMYK for her press with a CMYK to CMYK conversion at print time. Yeow.
–>With what profile–default SWOP? That’s going to blow away any advantages the ProPhoto space has, and then you’re going to ask the printer to correct the CMYK for her press with a CMYK to CMYK conversion at print time.
NOT if the shop really is printing SWOP (and quite specifically TR001 SWOP). When a printer actually conforms to this print "standard", the U.S. Web Coated (SWOP) v2 profile is hard to beat. Of course everyone tells you they print SWOP (one of the three biggest lies in the world..)
Given the option between guessing and using U.S. Web Coated (SWOP) v2 verses giving someone an RGB file and hoping they will produce a good conversion, I’ll take door number one. Of course I’d prefer to build a custom CMYK profile for their process (usually the contract proof). If most of these shops had a clue and would supply their output profile, I’d use that. 99 times out of 100, they either tell you they can’t supply said profile because it’s proprietary info that they don’t want their competitors to get hold of (nonsense) or when you ask for an ICC profile you either hear laughter on the other end of the phone or mumbling of confusion.
Of course everyone tells you they print SWOP (one of the three biggest lies in the world..) – Andrew
And since Sheetfed is more common… it makes me wonder why Adobe doesn’t have that as the default for U.S. Prepress Defaults? Especially since the dot gain is going to change noticeably if someone leaves it in the default.
As yet, a "standard" for printing sheetfed ala TR001 isn’t yet written in stone. TR004 is still undergoing drafting by GRACoL.
I still hear printers telling me (and other users) to convert to SWOP even if the job is to be run sheetfed since this is such a convenient answer for them and I suspect so few users call them on this. That’s why it’s one of the three biggest lies in the world…
Right, and the discussion is whether to tag CMYK or not. If you are confident in your CMYK profile then once the conversion’s been made a tag isn’t necessary because there shouldn’t be any further conversions (CMYK to CMYK) given that it’s a good profile. If you are guessing what the profile should be and provide a tagged CMYK file that is in turn converted to different CMYK by the printer, then I don’t see how that (RGB>CMYK>CMYK) workflow is any easier to pull off than providing the printer with a good tagged RGB file (RGB>CMYK). In both cases your asking him to make a conversion that would only work if the correct profiles are in place.
Being a Gemini, I have two views of embedding profiles:
Twin A. Always embed because folks down the line may need to open, view or even convert the data. Without a profile, you have the famous Fraser CMYK mystery meat.
Twin B. You’ve got the data in the output space. The numbers are correct for the device, no one will or should open or alter the data. That being the case, the profile does absolutely nothing but add up to a few meg’s in each file.
CMYK to CMYK can be a dangerous game for all but the most adventurous. At the very least, I’d be a bit more open to it using a device link.
I think life would be a lot simpler if by and large, printers would simply take the CMYK numbers they get and output them to their device as is UNLESS a customer specifically requests otherwise. Then I’d be insured the numbers I provide will go out to the device with no alterations. Printers wouldn’t have to worry that some bonehead gave them totally inappropriate CMYK since "you get what you get." If the customer does this but asks for assistance, the printer charges big bucks to fix the issue or get the original RGB data or use some kind of CMYK to CMYK conversion. If the customer doesn’t ask for this, they get either a butt ugly proof or output on press but then they "get what they get." I on the other hand don’t have to worry that I did my homework, built a good profile and didn’t have someone try to out-think me by fixing the numbers I’ve provided. In such a case, I certainly don’t need to embed a profile.
<< You also need to leave "Include ICC Profiles" unchecked in the Advanced dialog. And send hard copy proofs with the CD too. >>
<< That didn’t work for me. If you try this you can see what happens: >>
Rob:
Try this experiment:
Open an RGB file in Photoshop CS and convert to CMYK using standard US Prepress Defaults and Save As to CMYK_image_1 .
Open the same RGB and and convert to CMYK using a doctored version of US web SWOP 2 with GCR Heavy K Gen and Save As to CMYK_image_2 .
Place both CMYK images in the same InDesign CS document.
Export to PDF with: Color = "Leave Unchanged" and "Include ICC Profiles" unchecked.
Look at the seps. in Acrobat 6 Pro. — particularly at the black plate.
The two images ARE different.
Try it with CM ON and with it OFF in InDesign.
Provided that your PDF settings are as stated (Color = "Leave Unchanged" and "Include ICC Profiles" unchecked); BOTH PDFs will match each other and will show completely different Black plates for the two images.
It makes no difference whether CM was on or off in InDesign: the Profile used at the point at which you converted RGB to CMYK in Photoshop is retained in the separations.
I think life would be a lot simpler if by and large, printers would simply
take the CMYK numbers they get and output them to their device as is UNLESS a customer specifically requests otherwise. Then I’d be insured the numbers I provide will go out to the device with no alterations.
That’s what happens if you don’t tag anything. If you hand a printer an untagged ID file with untagged placed files the only way for her to alter the CMYK values is to open the ID file, assign a CMYK profile, and then chose a different destination space at print time–highly unlikely–and even then only the ID values would get converted, the placed files would be left untouched.
I could care less if the printer looks at the files and they don’t display correctly because I’ve asked that there be no edits.
For the most part, a service provider gives you what you give them, granted that their output device is set to some standard. Hopefully some kind of SWOP tolerance.
Service providers_DO_ have to deal with TIL and Black generation issues because pubs request it even if the client knows it or not…
If you are sending files directly to publications, you should be able to find the press requirements listed, together with the Ad. sizes, bleed and screen lpi, in the Rate Card. If they are not, call Production and ask for the info.
We have had excellent results from the PDFs which we submit.
It (the Honor/Convert theory?) HAS to be that simple, MO — or — me and my fellow pea brains will never grasp the concept (let alone the implementation).
Not to mention the old dogs who refuse to take a few reads, an hour or so, to actually learn how to use the tool (or at least how NOT to hose my color on a daily basis)…
When dealing with publications and pub materials, as a vendor for ad agencies, it is often the case whereas, we, the vendor, are responsible for total in limits, regardless of how in the hell the client created the separations, art work and the like.
The client really does not care what’s wrong with the files, the files just have to have a TIL of 300% as an example for a Web press. It’s the unfortunate reality of a service related industry dealing with people that have no business computing.
–>When dealing with publications and pub materials, as a vendor for ad agencies, it is often the case whereas, we, the vendor, are responsible for total in limits, regardless of how in the hell the client created the separations, art work and the like.
Sounds like a historically BAD business decision which I don’t fault you or your company on (it’s probably been this way for years). It’s kind of silly to take any old CMYK file provided and be responsible for how wrong or crappy the conversion is. I suspect if someone in the business had a time machine and had any clue to what it would be like handing files in the late 20th/early 21st century would be like, they would have never agreed to this kind of acceptance. It’s like going into a Restaurant with stale food and asking for dinner only to complain that not only did the food produced taste bad, it made you quite ill.
The people were never called Soviets, Mike. The word Soviet means "Council", that’s all. The communist "Councils" do not exist any more in any of the various countries into which the USSR disintegrated.
I just discovered what MO meant by the nonlinearity of assigned scanner and printer profiles and editing in that space rather than converting to a working space.
I do "profile fishing" by assigning different Fuji Frontier printer profiles off Dry Creek Photo’s site to my 35mm color negs scanned and burned to CD off the Fuji. I settle on a profile that makes the image match closest to the print, cancel out and use it to convert to after assigning the scanner profile off Fuji’s site which also makes the jpegs match very close to the prints.
I edit in the scanner space and convert to the Fuji printer profile. On reading about MO’s linearity comment, I decided to assign these downloaded profiles to a 21 step RGB grayramp. Yikes!
I’ve got about eight different Fuji printer profiles and one scanner profile and they all create slightly funky nonneutral color bleeds and shadow density variances between them. Some more drastic than others. Even the scanner profile creates an inconsistant grayramp, just not as bad. If I assign a working space or monitor profile, the grayramp is very clean.
From reading through this post am I to understand that if I assign any profile that makes the image look the way I like even though the image’s data is nowhere near that space that I will not retain that look when converting to a chosen output profile? Or will I just not get as accurate a print as intended?
In other words the untagged scans and prints off the minilab appear to be a bit dull but closer to reality and the way I remember the shot when I assign these Fuji specific profiles only. I mean reality isn’t as colorful as Madison Avenue and Kodak like to portray it. I don’t have anything to go by because the Fuji doesn’t read tags. I go by my memory of the shot.
If I assign something like ProPhotoRGB or even NTSC, the colors really beef-up with greens taking on a slight cyan cast among other slight hue shifts in other regions. Will I get that look when I convert? Or does this hose the colors when trying to improve the look by assigning wider gamut profiles rather than beefing up through curve and hue/saturation tools in the proper space?
Editing in an input space or moving directly from an input to output space has some issues (depending on the device) that make the concept of RGB working space really attractive. You’ve seen this already in your examples.
One useful illustration I like to show is opening a digital camera file shot linear (linear encoded gamma). That’s an option with some cameras. Open untagged and the image looks about 3 stops too dark and the Histogram is real odd looking (all pushed up to the left). Assign the camera profile and the preview looks great (numbers and histogram still odd). This first illustrates why we need profiles for describing the numbers in the file.
Now convert from this input space to a working space. Preview doesn’t really change but when you look at the Histogram, it’s all nice and even (I’m doing this of course on a high bit file). Mapping from the Linear gamma to the working space spreads out the data as we’d expect. This would be one funky file to be editing in an input space.
It’s an extreme example but it does illustrate the unique kinks in some input devices and why it’s usually a real good idea to get into a well behaved editing space asap.
The other useful thing about all working space is that when R=G=B, it’s neutral. That’s simply not the case with all input color spaces.
As I understand you, I should use the histogram in determining the need to convert to working space? If so, then the data written to the untagged Fuji CD images is giving very spread out and balanced histograms and is probably OK to edit in the scanner assigned space. Correct?
I’m trying to avoid an additional conversion step to these comparatively low quality jpegs so I can retain most of my data during the editing phase. Or instead of an extreme amount of editing, I could just pick a wider gamut that beefs up the colors with the least amount of degradation using tonal adjust tools.
I guess the farther away the assigned profile is to the data (assigning ProPhotoRGB for example) and then converting to working space would severely degrade the image more than if I assigned a profile closer to its data-Fuji Neg scan profile-and then converted to AdobeRGB.
–>As I understand you, I should use the histogram in determining the need to convert to working space?
No, the point was that you can have a file in an input space that looks butt ugly both visually and through a histogram prior to a conversion into a working space which is designed for editing images.
You can edit in your scanning space but there are also compelling reasons to convert into a working space, one of which is how the data is distributed for editing, the gamma for applying the edits throughout the tone range evenly, and the ability to use R=G=B as a known neutral aimpoint.
Andrew, thats interesting…but surely that can only happen with high bit files…surely if your image comes in with the highlights shot and the histogram shows this, if you convert it to a working space the histogram will only move slightly. I think your seeing the strengths of high bit images, as opposed to your method.
What i suspect is that your method only really pays dividends with high range/bit images, but i fear that it wont do much for standard images. If the range is shot on a scan in 8 bit then its pretty shot on any profile…you may be able to get a better colour feel, but the damage has been done. (by the scanner)
You’d want to do this on high bit files but that doesn’t have to happen. The same histogram and redistribution would happen in an 8 bit file, you’d just lose a lot more data. The original Histogram looks funky due to the way the data was captured (linear). Most products provide a gamma corrected image from RAW data (in the case of a camera). The point is that the mapping into the working space can handle this gamma correction.
The critical reason why we want to edit in a linear RGB working space is the simple fact that the editing tools are linear. ie. Curves, Levels.
If you are looking at a severely whacked non-linear color space and making color edits and/or assessing the image based upon that which you see – and using color adjustment tools, the edits in which you preform may be totally off or inappropriate to what you see.
Color correction by the numbers only works if the person who is doing the correction understands how the output device behaves and is usually based upon the users "known" knowledge of such device. Usually, somewhat SWOP-ish. but never totally accurate and often flawed.
I personally enjoy telling a color operator that their full of crap when they think they are color correcting "by the numbers." I usually proceed to set the monitor profile to greyscale and tell them to go for it.
Learn how to optimize Photoshop for maximum speed, troubleshoot common issues, and keep your projects organized so that you can work faster than ever before!
Related Discussion Topics
Nice and short text about related topics in discussion sections
