Skip navigation
This discussion is locked

Who should do  rgb-CMYK conversion - designers or printers?

Aug 14, 2009 4:59 AM

  Latest reply: Peter Spier, Aug 16, 2009 3:04 PM
Replies 1 2 3 Previous Next
  • Currently Being Moderated
    Aug 15, 2009 11:03 AM   in reply to Jeremy bowmangraphics-DQuh1B

    PDFX-1a does not guarantee everything will be ok.  Things such as bleeds, page imposition, some fonts families and spot colors can be an issue.


    PDFX-1a compliant files does not mean a successful job, but its better then doing nothing.


    The other problem is the RIP in which you send the files to.


    For example:


    If you have text and graphics on ONE layer with transparency - when you write out the PDF and send it to a RIP that separates CT from Line work or is not a level 3 RIP, you could get text that is rasterized that lays over a CT file that is places in In Design.


    There are many upon many issues that can just make a job go sideways, but to answer your question, use PDFX-1a, but its not a flawless workflow.


    YOU need to do your homework.

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 15, 2009 11:06 AM   in reply to Jeremy bowmangraphics-DQuh1B

    is it sufficient to simply use the [PDF/X-1a:2001] preset for that task, as long as all images look OK on the (perfectly calibrated) screen?

     

    PDF/X-1 assumes all color management is complete—you are willing to commit to one output CMYK profile and no further color management (conversions) will happen at output time (it does not include profiles). It also flattens transparency during the export. It works if you are sure of the CMYK destination, and you have used that output profile throughout the workflow.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 11:08 AM   in reply to Mike Ornellas

    YOU need to do your homework.

    Evidently, but is there some reason why my "homework" can't involve asking some experts a beginner's question?

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 11:10 AM   in reply to Rob Day

    rob day wrote:

     

    is it sufficient to simply use the [PDF/X-1a:2001] preset for that task, as long as all images look OK on the (perfectly calibrated) screen?

     

    PDF/X-1 assumes all color management is complete—you are willing to commit to one output CMYK profile and no further color management (conversions) will happen at output time (it does not include profiles). It also flattens transparency during the export. It works if you are sure of the CMYK destination, and you have used that output profile throughout the workflow.

    But what if you are using Buko's workflow -- which involves keeping all images as RGB right up till the end, as well as being completely sure about the CMYK destination profile?

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 15, 2009 11:18 AM   in reply to Jeremy bowmangraphics-DQuh1B

    But what if you are using Buko's workflow -- which involves keeping all images as RGB right up till the end, as well as being completely sure about the CMYK destination profile?

    There wouldn't be a problem with that, because the preset converts RGB and Lab objects to your document CMYK space which should be the correct output profile.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 11:23 AM   in reply to Jeremy bowmangraphics-DQuh1B

    Jeremy -

     

    yes you can do that workflow. It's the preferred way to do things, but the problems come around if you want to start doing critical color edits for CMYK. There are things such as rounding of numbers with RGB to CMYK conversions. We can go into details but to answer your question, yes it's a valid workflow to have In Design convert the files upon export of a PDF.

     

    As long as you UNDERSTAND what the job consists of.

     

    Key words...

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 11:35 AM   in reply to Jeremy bowmangraphics-DQuh1B

    Jeremy,

     

    If you look at the X-1a setting you'll notice that the conversion is set to Convert to Destination (preserve numbers).

     

    What does this mean, and is it a good choice? Well, it means that any any CMYK content that doesn't match the destination space will be retagged (not really converted) to the destination space. This is good in the sense that your 100% K type will remain 100% k and won't be converted to a rich black pressman's nightmare (100% K overprints by default, remember, but rich black does not), but it also means that your other colors will also still have the same numbers, and their appearance will change slightly.

     

    A true conversion form one space to another involves altering the numbers to preserve the APPEARANCE of the color from space to space as much as different gamuts will allow. So using the X-1a preset is sacrificing some color fidelity for preserving 100% solids or tints of single colors. In many cases this might be desirable, but probably wouldn't be for most photos, since they are unlikely to have large areas of single ink usage and registration of the colors is already required. It is, however, "safe" in the sense that something will print and it should look somewhat like what you expect.

     

    Note also that the target profile is, by default, Document CMYK. If the Document is already in the correct space for output, it makes no difference whether you preserve numbers or appearance for native objects because no changes will happen. If most of the imported art is vector, you might want to preserve numbers, for raster I'd prefer to preserve appearance. All of this applies only to CMYK objects in the file. All RGB will be converted to CMYK (preserving appearance, I believe -- Rob, please jump in and correct this if I haven't got it right), so the preserve numbers/appearance question would not affect RGB photos -- a plus for leaving the conversion to output.

     

    I've always tried, and advised others to do the same, to assign the correct output space as the working space for any document BEFORE exporting to PDF. This will preserve the type and other native objects while allowing you to preserve the appearance of imported content.

     

    The other disadvantage to the X-1a standard is that it flattens transparency. This means it should be printable virtually anywhere, but it is generally accepted that the best time to flatten is in the RIP, if possible.

     

    Peter

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 15, 2009 12:14 PM   in reply to Peter Spier

    Well, it means that any any CMYK content that doesn't match the destination space will be retagged (not really converted) to the destination space.

     

    Peter I'm not seeing that. If you look at the description field for Convert to Destination(Preserve Numbers) it says that placed images with profiles which conflict with the document CMYK profile will get converted, while images without tags or images with tags that are ignored by ID will have their numbers preserved (no conversion). Everything is forced into document CMYK.

     

    This is what I've always assumed would happen. I just ran a quick test with a PS file filled with 50% K and a visible, conflicting tag and the image did get converted with PDF/X-1a.

     

    But, in a well managed PDF/X1-a workflow you wouldn't have conflicting tags.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 12:22 PM   in reply to Rob Day

    Interesting read Peter.

     

    Rob, I agree with your quesiton to Peter.


    but I as well disagree with...

     

    But, in a well managed PDF/X1-a workflow you wouldn't have conflicting tags.

     

     

    You assume here -

     

    File formats also play a part in color mayhem. There are too many variables still in the Applications to guarentee nothing.

     

    Other then that, maybe a little prayer before you break bread on a big press job would be in order.

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 15, 2009 12:38 PM   in reply to Mike Ornellas

    I understand that printers can't control conflicting profiles, but the content makers surely can. I've never created a page layout with conflicting CMYK profiles.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 12:56 PM   in reply to Rob Day

    Well maybe you never have....

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 1:14 PM   in reply to Rob Day

    Thanks Rob,

     

    I ran a test, too, but I used a vector .eps logo, and it wasn't converted. Seems that although I tagged it SWOP in the filename, I didn't embed the profile in either the eps or .ai versions (probably so color numbers would be preserved). I also noticed that I hadn't reset my color settings (I'm running on my test system at the moment) and import options were set to preserve numbers, so I've reset to my regular settings that preserve profiles and tried again with the same files and a couple of more, a tiff version that contains only 100% K and 100% magenta and is tagged SWOP Coated, and another untagged vector with the same colors. I've reassigned the working space from Sheetfed Coated to Fogra 27, just to be sure the number would be really wrong.

     

    Some interesting results.

     

    First, all of the numbers in the PDF match the reported numbers in ID using the separations preview.

     

    Second, the type of vector file makes a difference. The tiff was tagged with SWOP, and was converted, as expected, to a rich black and a tint of magenta, but none of the vector files were tagged. The .eps files preserved the numbers, the .ai did not IF the black was already a rich black, but did preserve 100% K.

     

    What really surprised me was that Although all my policies are set for mismatch warnings I was never asked what to do with the mismatched profile or the untagged files.

     

    This is waaay outside my normal practice of assigning the correct working space to start and using files with the numbers I want to start.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 1:25 PM   in reply to Peter Spier

    I was never asked what to do with the mismatched profile or the untagged files.

    and there my friends is where the black hole of Adobe products reside...

     

    Please fix.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 1:31 PM   in reply to Peter Spier

    Thought I'd post my color settings, just so you could see waht they are without struggling to imagine them.

    ColorSettings.png

     

    For some reason Bridge doesn't want me to synch the settings, probably because I didn't install the whole suite on this machine, just an extra stand-alone ID I had floating around (I've got my suite activated on two machines already).

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 1:32 PM   in reply to Mike Ornellas

    Mike Ornellas wrote:

     

    I was never asked what to do with the mismatched profile or the untagged files.

    and there my friends is where the black hole of Adobe products reside...

     

    Please fix.

    I'll report the bug and see what happens.

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 15, 2009 2:17 PM   in reply to Peter Spier

    I ran the same test with an .ai file with a conflicting tag and it got converted in the PDF—same as the PSD. The .eps did not get converted, but that's not too surprising given that there's not an option to include a profile when you save that format—I think ID always assigns the doc profile to eps—another reason not to use it. I also tried TIFF and it converted.

     

    One thing to keep in mind here is, in CS3 and I assume CS4, the policies are set at document creation and changing them later has no effect, which might explain your missing warnings. I ran my tests on a new document, where I had set the policy to Preserve and the Working Space to JapanColor, before making it.

     

    Also, you can't tell if ID is ignoring profiles of incoming PDF (or .ai) because the embedded profile never shows in the Links panel, and you don't have the option to reassign their profiles via Object>Image Color Settings the way you can with images. That means if you are placing PDF the initial policy setting is going to have more impact. You really have to decide if you want to ignore incoming conflicting profiles up front.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 2:25 PM   in reply to Rob Day

    And then there are the issuses of nested files.

     

    Let me know when the fun starts...

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 15, 2009 2:28 PM   in reply to Peter Spier

    What really surprised me was that Although all my policies are set for mismatch warnings I was never asked what to do with the mismatched profile or the untagged files.

     

    The mismatch and missing policies are for when you open a document with a profile which conflicts with your current Working Space, not for when you place files.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 3:54 PM   in reply to Rob Day

    I know the settings are applied when you create the doc, so I made a new one after resetting to what is shown and that file was used to generate the second set of results I posted.

     

    If you look at the message in the description box at the bottom of the dialog (I was hovering over the Pasting option during the screen cap) it implies that that option should be active during pasting and placing operations. I don't see anywhere else you would be able to set a policy for handling placed files that have mismatched or missing profiles -- am I just not looking in the right place?

     

    Peter

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 15, 2009 4:40 PM   in reply to Peter Spier

    For pasting it's only native objects (description says colors not placed art). Make two docs with your settings, one with a different Working Space, make a new color in one doc and drag it into the other. I get this:

     

    http://www.zenodesign.com/scripts/Pasteconflict.png

     

    When you cut and paste an image, its profile (or lack of profile) travels with it so a warning isn't necessary.

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 15, 2009 5:02 PM   in reply to Peter Spier

    In case your interested here's my test, where everything except the .eps converted to new numbers

     

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 5:06 PM   in reply to Rob Day

    So you are saying "drag and drop" only means from another ID doc, not from bridge? That means we should expect all tagged content to be converted when placing, if the policy is set to preserve profiles. SO... can you explain why an .ai file saved with embed profile selected shows as untagged in bridge and preserves numbers when the profile doesn't match?

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 15, 2009 5:39 PM   in reply to Peter Spier

    I think paste means only ID color.

     

    Take a look inside my zip. My .ai file with the conflicting tag is getting converted on the export.

     

    When you save an .ai file the save dialog doesn't tell you what profile you are embedding, and when you place in ID the profile doesn't show even though it's there. Just to make sure try going back to your .ai file and assign the conflicting profile via Edit>Assign, then resave with include profiles checked.

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 15, 2009 5:47 PM   in reply to Peter Spier

    Here's my Acrobat output—the gray it's reading was 50% K in AI:

     

    http://www.zenodesign.com/scripts/PDFReadings.png

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 6:00 PM   in reply to Rob Day

    and to no surprise, the EPS retains the numbers, but the AI file gets hosed.

     

    Throw in transparency and there you go.

     

     

    Pick your poison.

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 15, 2009 6:15 PM   in reply to Mike Ornellas

    In my test the .ai file doesn't get hosed, it gets converted which is what I asked for by setting my policy to Preserve and embedding a conflicting profile.

     

    If for some crazy reason I actually wanted to use EPS in the layout and thought that it had to be converted, I could make the conversion in AI. Or do the right thing and just resave it as .ai.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 15, 2009 6:30 PM   in reply to Rob Day

    Yes Rob - it gets converted - the AI file.  Yes, the EPS numbers remain the same.

     

    Two very different formats doing two different things - even if the color settings are the same.  So hosed is subjective if you really look at what is happening...

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 16, 2009 5:51 AM   in reply to Mike Ornellas

    The one I love the best is when you place an EPS in a page layout and you have spot colors - but tell it to convert in In Design. Yes, more idiot boxes come up when one tries to set the color in the list as process, but never gets converted. So, is this an issue of holding on to old file formats to preserve the color numbers or would you rather have a file that preserves the color appearance?

     


    And like the average user understands that concept....

     


    please....

     

    It's really too bad that adobe continues to think in individual terms and not best practice workflows - cuz basically they are scared of implementing anything other then adding to the [edited by forum host] for color management.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 16, 2009 5:28 AM   in reply to Rob Day

    rob day wrote:

     

    I think paste means only ID color.

     

    Take a look inside my zip. My .ai file with the conflicting tag is getting converted on the export.

     

    When you save an .ai file the save dialog doesn't tell you what profile you are embedding, and when you place in ID the profile doesn't show even though it's there. Just to make sure try going back to your .ai file and assign the conflicting profile via Edit>Assign, then resave with include profiles checked.

    I thought paste also meant drag and drop from Illy or Photoshop, but apparently not. If I drag the same file from Illy into the doc, the numbers are preserved, rather than converted, so it looks like I have been misunderstanding what's happening for a while.

     

    By the way, I went back this morning to redo my testing after making sure I knew what files had embedded profiles and what didn't, and that the profiles actually were the ones I thought they should be, and I now get results entirely consistent with yours. Mismatched embedded profiles (though Bridge still refuses to see a profile -- possibly because Illustrator files are really PDF now and can contain linked content with its own conflicting profile? I'll have to play with that) are converted when placed, untagged preserve numbers, and changing the assigned profile for the doc changes the numbers for tagged imports, but not untagged.

     

    Peter

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 16, 2009 5:50 AM   in reply to Mike Ornellas

    Mike Ornellas wrote:

     

    Yes Rob - it gets converted - the AI file.  Yes, the EPS numbers remain the same.

     

    Two very different formats doing two different things - even if the color settings are the same.  So hosed is subjective if you really look at what is happening...

    I agree that this can be confusing for users, but .eps is not a color managed format and shouuld not be used in a managed workflow (that's probably why Quark's color management wasn't very good for so long). If you can't embed a profile, you can't expect a managed workflow to know what the numbers mean, and I wouldn't, personally, want the application to start making any assumption other than untagged content is in the current working space, which is exactly what happens now.

     

    As far as what's "best practice," I think that's subjective. Printers like to look at a file and say these are the numbers you delivered, and we put that amount of ink on the paper. Designers like to say this is the color I see, and I don't know from numbers, I want to see the same color on the paper. From the designer's perspective, best practice is to convert and maintain appearance, but that has its dangers, like conversion of type to rich black.

     

    The world has changed for the print industry, and like it or not both printers and designers need to understand at least the rudiments of color management. Designers, in particular, need to learn more about the printing process and how to prepare files that are printable. When I was teaching I devoted a fair amount of time to trying to get my students to understand the differences between spot and process color, solid and rich black, and overprint or knockout, and to think about what was happening in their files. I won't say I was always successful, but it wansn't for lack of trying.

     

    On the other hand, one of my pet peeves is printers who fix files without telling the designer, or who return files for correction without explaining why they don't work on press and what needs to be done to solve the problem. This just perpetuates the cycle of bad files or bad output.

     

    One final note, Mike. as forum moderator I'm asking you to watch your tone and language. Let's all try to keep this discourse on a polite and professional level.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 16, 2009 6:13 AM   in reply to Mike Ornellas

    Mike Ornellas wrote:

     

    The one I love the best is when you place an EPS in a page layout and you have spot colors - but tell it to convert in In Design. Yes, more idiot boxes come up when one tries to set the color in the list as process, but never gets converted.

    I don't know what you're doing, but I don't see this at all. It wouldn't surprise me if a swatch from an imported .eps could not be edited, but I've just tried it in 6.0.3 and had no problem redefining the swatch from spot to process, nor was there an issue with doing it the right way and using the Ink Manager to convert spot color to process.

     

    What you can't do is redefine the process numbers associated with the swatch definition, though if you use ink manger you can ignore them and choose to use Lab values instead. You can also cheat. Define a new spot color swatch in ID, then in the Ink Manager alias the spot from the .eps to the new spot color, and finally convert that new spot to process. Pantone 132 becomes anything at all that you want it to be.

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 16, 2009 6:36 AM   in reply to Peter Spier

    (though Bridge still refuses to see a profile -- possibly because Illustrator files are really PDF now and can contain linked content with its own conflicting profile?

     

    I've always assumed that the opaqueness of PDF and profiles was because PDF can have multiple profiles. I can see where it might cause issues in a less disciplined workflow, or at least as we can see it's a bit harder to know what's going on.

     

     

    changes the numbers for tagged imports, but not untagged.

     

    ID has no choice but to assign the document profile to an untagged placed file, so it makes sense to preserve numbers in that case.

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 16, 2009 6:48 AM   in reply to Mike Ornellas

    And like the average user understands that concept....

     

     

    A piano looks like a pretty straight forward instrument to me—just a bunch of white and black keys. I can pick out chopsticks, but the New York Philharmonic knows better than to hirer me. That doesn't mean I'm expecting Baldwin to come up with a new instrument that lets me play Mozart without practicing.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 16, 2009 6:56 AM   in reply to Peter Spier

    When Adobe wakes up and addresses a REAL WORLD workflow I shall go quiet into thy good night. The abuse of files and waste of time and money on both ends of the spectrum is out of control and education in itself will not solve the problems. Hard in your face professional opinions and for that matter language must be used to convey how screwed up things are in the commercial arena.

     


    Adobe MUST embrace a full PDF workflow from concept to output and scrap this whole open ended architecture mess we now have. I can only blame the developer because they dont want the liability of instituting a best practice workflow. Yes you are correct in your statement between designers and printers, but the way color management is developed as of now is nothing more then a joke.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 16, 2009 7:36 AM   in reply to Mike Ornellas

    A piano looks like a pretty straight forward instrument to me—just a
    bunch of white and black keys. I can pick out chopsticks, but the New
    York Philharmonic knows better than to hirer me. That doesn't mean I'm
    expecting Baldwin to come up with a new instrument that lets me play
    Mozart without practicing.

    Rob -

     

    Now days everyone can buy a piano and play it. You dont have to be hired by someone to understand that you dont know what you are doing.  That and knowing the piano does not change every 18 months....

     

    The world is out of control and only the developer can real it in - or lose its customers in a bevy of garbage features developed by some marketing genius that has no concept of how to develop for markets they affect.

     

    Someone put me in touch with the head of marketing and I will enlighten them with a flash light.  That's a simple enough tool. It's either on or off - but it may depend upon where I shine it...

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 16, 2009 8:03 AM   in reply to Mike Ornellas

    If there really is a problem the market will take care of it. If Adobe's color management is so deeply flawed surely another software developer will crush them. If not then eventually buyer's of design and print will attach the correct price to different levels of competence. There's plenty of gorgeous printing around, so not everyone's lost.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 16, 2009 8:14 AM   in reply to Mike Ornellas

    Mike,

     

    I suspect that during the first twenty years of development there was quite a bit of experimentation and refinement in the production of good piano designs (and there are good pianos and less good painos, today, even after a long history). Color management is a developing field, as is the use of computers to produce printed materials, and there are still a few rough edges here and there. We've come a long way in the last five years alone, but I don't believe anyone disputes a need for improvement.

     

    I surely couldn't produce the kinds of things I do in InDesign if I had to work in metal type with engraved photos, and I don't want to go back to Quark 4 and have to tell my customers that the color they see on the screen probably won't match what comes off the press. At least now, with a little training and some monitor calibration, I'm able to hold up a print and look at the screen and recognize the colors I was using.

     

    Peter

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 16, 2009 8:25 AM   in reply to Rob Day

    Rob -

    If there really is a problem the market will take care of it. If Adobe's color management is so deeply flawed surely another software developer will crush them. If not then eventually buyer's of design and print will attach the correct price to different levels of competence. There's plenty of gorgeous printing around, so not everyone's lost.

     

     


    That is the silliest thing I have ever heard Rob. Adobe's color management is not deeply flawed. It works, The implementation is a mess is what I'm trying to convey and I dont think they know how or want to fix it...I highly doubt that there will ever be any competition for the company at this point. They are king of the hill in the graphics arena so they should with all good will, fix the mess for their own sake as well as their customers. Don't tell me you think that it's too late that they have become such a bureaucracy that shall just keep making widgets to promote short sales...

     


    Not everything is lost. I'm not preaching doom and gloom here. I have a solid understanding of the technical aspects of the softwares as well as market share and market trends - AND what is going on in the real world.  It's broken is my conclusion.  The implementation.

     
    |
    Mark as:
  • Currently Being Moderated
    Aug 16, 2009 8:29 AM   in reply to Peter Spier

    Peter -

     

    I can not argue with your statement and I fully agree with your observations.  But not much has really changed for the better relative to circa 1998 when color management became main streem. Actually in some regards it has gotten worse in some areas, but yes - evolution has a price.  My problem is that there is no cohesive workflow for specific markets that Adobe carters to.

     

    We have a bridge why not a road?

     
    |
    Mark as:
  • Rob Day
    3,123 posts
    Oct 16, 2007
    Currently Being Moderated
    Aug 16, 2009 8:39 AM   in reply to Mike Ornellas

    Sorry, I guess I misunderstood "but the way color management is developed as of now is nothing more then a joke."

     
    |
    Mark as:
Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)