Standard Finishing
4Over

Announcement

Collapse
No announcement yet.

Pantone issue in QRK 6 and 7

Collapse
CanonKonica Minolta
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Pantone issue in QRK 6 and 7

    when pantone colors are created in v6 and 7, they separate differently when converting to CMYK. This happens EVEN when I have the pref selected to "emulate legacy". any other ideas appreciated!

  • #2
    Re: Pantone issue in QRK 6 and 7

    I'll keep my eyes on this thread for a while. This is one of the reasons
    I won't upgrade here. I don't know of a fix unless you can update the
    Quark 6 Pantone library to be on a par with v7. I can't really pull some
    jobs from archive because of it, unless I'm willing to go through the
    entire proofing process again. It's easier for me not to upgrade at the
    moment.

    Good luck.

    Comment


    • #3
      Re: Pantone issue in QRK 6 and 7

      I can tell you any work we get STAYS in the version it was created in. I've learned the hard way.
      what I know of the pantone library, it is updated by pantone several times per year.

      Comment


      • #4
        Re: Pantone issue in QRK 6 and 7

        I downloaded a pdf recently of the Seybold Report, Vol. 6, No. 4 • September 7, 2006 and it talks about the changes in the Pantone Libraries.

        I don't remember where I downloaded it from, but maybe you can get it here: http://www.risiinfo.com/seybold/

        Comment


        • #5
          Re: Pantone issue in QRK 6 and 7

          A very smart thing to do macdudeken. I used to do it for about 6.5 years, haven't done it for about 5 years (haven't had a problem but I guess I've just been lucky), but because of this I'm starting the practice again.

          Don

          Comment


          • #6
            Re: Pantone issue in QRK 6 and 7

            macdudeken, I don't normally use Quark's native Pantone colors, I append Colors by selecting from Pantone's color bridge palette for Quark. I do the same in Illustrator and Photoshop to keep my colors consistent. We all know that "accuracy" is a flexible terms when converting spot to process, but I prefer Pantone's color bridge breakdown over allowing my applications to do it.

            inez

            PS_new versions of color bridge swatches/palettes can be downloaded free on mypantone.com

            Comment


            • #7
              Re: Pantone issue in QRK 6 and 7

              Hi Inez,

              You're a designer, right?
              And you are one of the few who know what they are doing. This goes to show you this issue needs to be taken care of from the beginning! (design stage)
              we printers are faced with unbelievable turnaround times, so an issue like this gets resolved when on press!

              quick test:
              1. new doc in Qrk 7, create a new PANTONE color (in my case, WARM GREY 8) convert to CMYK. You get C;16,M23,Y23,K44
              2. do the SAME test in QRK 6. Or InDesign CS2, OR ID CS3. The SAME VALUE is C;0,M9,Y16,K43

              Comment


              • #8
                Re: Pantone issue in QRK 6 and 7

                one more thing Inez,
                in QRK 6 create a new color (PANTONE WARM GREY 8). SAVE.
                in QRK 7, select APPEND, find QRK 6 doc with the PANTONE WARM GREY 8, AND add to the QRK 7 color list. convert to CMYK and you will get a much different breakdown. APPEND will not work.

                Does Anyone know of a way to select the "correct" PANTONE library for QRK 7?
                BTW, the 7.3 update doesn't address this unless I'm missing something!

                MDK

                Comment


                • #9
                  Re: Pantone issue in QRK 6 and 7

                  macdudeken, maybe I just need to quit taking Quark jobs (or charge double for them). Quark makes some real crazy decisions. If you look in the Quark forum, I just made a new thread talking about Quark 7 stupid color management decisions with Quark 7 and untagged RGB. Here though we will deal with yet another screwed up issue that should have never happened.

                  In Quark 6.5, if you choose PANTONE solid coated and choose your color, then change Model to CMYK, you get the next-to-newest PANTONE CMYK builds.
                  In Quark 7 and higher, if you choose PANTONE solid coated (same friggin' library as you chose in QX6) and choose your color (same friggin' color as you chose in QX6), then change Model to CMYK (same as in QX6), you get the newest PANTONE CMYK builds (aka color bridge numbers).

                  So in Quark 7, instead of Quark just adding the color bridge libraries (and not replacing the old libraries) like Adobe did in InDesign (so that depending on which library you had chosen, the CMYK numbers will be different), Quark just lopped them together, gave you options to use either library, and no matter which one of these two libraries is chosen, you're given the color bridge numbers.

                  As it has been for years, Quark does it wrong and makes it easy to get the job out wrong, and Adobe does it right and makes it easy to do right.
                  Quark needs to shut it's doors. If these "experts" can't even make their HTML output profile sRGB IEC61966-2.1 (as anybody that knows color management for web knows to do), and can't assign the sRGB IEC61966-2.1 profile to untagged RGB (like even those that write books on color management would tell you is the safest and most likely best thing to do when encountering untagged RGB), then they don't deserve to be in business. I'm fed up with them. I've beta tested Quark 7, and they're now on 7.3 and still haven't fixed these glaring problems. Unforgivable if you ask me.

                  Don

                  Comment


                  • #10
                    Re: Pantone issue in QRK 6 and 7

                    Yes, I am a designer and, yes, these things should be addressed on the designer's end. I feel for you.

                    I can't run your version test, but I believe you. That's why I said I NEVER let my applications do my conversion from spot to process.

                    Scenario: if I receive a 2-color logo EPS file for inclusion in a process color piece for layout in Quark, I would first open the logo in Illustrator and replace the spot colors with the corresponding Pantone color bridge colors making sure to set them at global, not spot, then set traps/overprints if needed and save as a new process logo. Then if I want to match those colors in Quark for a consistent color scheme I would go to the Edit menu>Colors>Append>(wherever you keep the Quark color bridge palette) and select the same colors (you'll note the same CMYK values across apps) making sure to edit/uncheck Spot. Quark is not converting the colors because the percentage values are already present and accounted for by Pantone.

                    You can register at http://mypantone.com and download the color bridge palettes for free. They may not be perfect, but they're the best way to assure consistency across apps. Now, there may be other options for you from the prepress/RIP workflow side, but I'm a lowly designer and don't know However, I see no reason for printers to cut off their noses by rejecting Quark files as a rule.

                    (Please note; I use an old version of Quark so menu selections may be different.)

                    inez

                    Comment


                    • #11
                      Re: Pantone issue in QRK 6 and 7

                      A postscript to my post; I rename my color bridge palettes adding month/year like 1007. I prefer appending and selecting colors over using built in palettes; again, for consistency. The better option for all of this might be Pantone to Hexachrome, but who's gonna pay for that, LOL Seriously though, I do frequently wish that Pantone would pin down these conversions and stick to the same values. Sure, we'll always have new colors to deal with, but old colors need to stop changing. There's only so much that can be controlled to the human eye's discernment, and once you change papers or look at it in a different light...well, when will enough be enough?

                      inez

                      Comment


                      • #12
                        Re: Pantone issue in QRK 6 and 7

                        inez,

                        The whole problem is PANTONE not printing their CMYK to the industry standard ISO 12647-2. If they did, then we could use their CMYK numbers and get as close as possible to the PANTONE color. But even their color bridge numbers are not printed to ISO 12647-2! So what this means is that any printer printing to ISO 12647-2 (international standard that is more than ten years old) will not match what PANTONE shows in their guides as what the color should look like when printed. To get as close as possible, one has to actually use PANTONE's Lab values, use color management, the correct output profile (e.g. GRACoL2006_Coated1v2 or ISOcoatedv2 if printing on #1 paper, or ISOuncoated if printing on #4 paper), and one of several rendering intents (which one rendering intent doesn't even always get the closest to the PANTONE color, so tests have to be done with using several rendering intents, proofing them, comparing them to the PANTONE guide's PANTONE color (not CMYK build) under industry-standard 5000K lighting, and choose the set of CMYK values that most closely matches the actual PANTONE color.

                        It gets even more interesting. Even if all CMYK profiles were made from the same characterization data (e.g. GRACoL2006_Coated1v2), the vendors that make the programs that make the profiles from that characterization data, all map out-of-gamut colors differently. This means I can be printing to the GRACoL2006_Coated1v2 (U.S.) specification of the international standard ISO 12647-2, but depending on which program made the profile, I could have my RGB blue turn purple, be a dark blue, or be a lighter more eye-pleasing blue (closer to the actual Hue of the original color). And this goes for all out-of-gamut colors that must be compressed into the gamut of the printing condition. Too much to even want to think about. Makes me feel I'm going crazy.

                        What would really help is if PANTONE came out with a final set of CMYK values (color-bridge2?), where the CMYK values have been made for the international standard. Otherwise, the only way to get closer than the color bridge numbers is to use PANTONE's Lab values and color management. Adobe makes this easy. Quark makes it hard because if we output As Is, we may get PANTONE's Lab values for the colors, but all RGB will be sent without profiles (or the numbers as is), which is awful. No good compromise here.

                        Don

                        Comment


                        • #13
                          Re: Pantone issue in QRK 6 and 7

                          Hi Don,

                          Yes, I remember reading something similar before, probably in the prepress newsgroup, or maybe color science. Can things practically become standardized with Pantone internationally? IOW, would an international standard actually used internationally? I thought there were actual differences in print methodologies between North America, Europe and Asia that might cause actual ink-on-paper variables. Not that I've delved into things to that extent.

                          I'm forced by my old equipment and apps to work with color management off (as much as Adobe apps allow anyway). I'll have quite a steep CM learning/refreshing curve when/if I finally upgrade everything. Fortunately, I don't deal in contract color. Phew! But as a low end designer I have to bow down to Pantone's will since they seem to +own+ color. I have to work with what Pantone offers me; color bridge. I'm even stuck with old versions of that for now because the new downloads don't include my ancient Quark. Well, I'll probably have to manage a workaround unless someone can legacy save the new color bridge palette for me. Anyway, I agree that Pantone should work/print within industry standard and finalize their color bridge set. But Pantone is a business instead of an industry organization... It's kind of a hostage situation, yes?

                          When it comes to RGB in print; I've read about it but simply can't wrap my mind around it. I just don't grock. It boggles me and I stomp, pout and shout "RGB has no business in print." I fortunately have no use for it in Quark. When I upload web image proofs I just open Quark EPS in PS, convert to sRGB and manually adjust colors by eye giving the client a warning that screen colors may not match print colors. I don't attempt color proofs with what I've got. Like I said, gratefully not color critical work Until I can have RGB to CMYK conversions automated in a trustworthy manor I am *completely lost* on that score. I'll have to take your word for Quark's botching of RGB Would Hexachrome print accomplish RGB color matching better (if anyone could afford it)? (Asked purely out of curiosity and a lust to see Hexachrome output

                          Is there no way for you to set up CM for these Quark conversions to be automated, possibly at RIP? I'm clueless (and know it) when it goes that deep into prepress. Ah well, it seems with each new automation comes a new complication. I sympathize, but am grateful to be on the non critical, non technical end of the spectrum. I'd go mad.

                          inez

                          Comment


                          • #14
                            Re: Pantone issue in QRK 6 and 7

                            The U.S. and China are using the G7 method of setting up presses. The characterization data has been finalized and has resulted in the official ICC profile being made available at www.gracol.org, named GRACoL2006_Coated1v2. The G7 method results in an appearance on #1 paper that is close to ISOcoatedv2 (Europe's new ICC profile describing FOGRA39 characterization data). Both ISO 12647-2 and G7 aim for the same solids on #1 paper. Bottom line is that Asia, Europe, and the U.S. are within a few percent of each other now (very close appearance) when it comes to printing on #1 paper. Note: SWOP also uses the G7 method and has released SWOP2006_Coated3v2 and SWOP2006_Coated5v2, and ISOuncoated, although Europe profile and not G7 is very close to what uncoated G7 profile would be. So no matter what paper type we're talking about, or type of printing, we have close enough conditions that PANTONE should know this and should have made the color bridge print to ISO 12647-2.

                            As far as color management of RGB - it's simple if you get the basics down. RGB is created when scanned or a digital camera takes a picture. The RGB is seen by Photoshop as RAW (which gives a designer more control over changing the image upon import in Photoshop) or as RGB (if the camera embedded the ICC profile in the image). This RGB profile is then used to display the image's RGB numbers. If editing is to be done, conversion to a suitable editing space such as Adobe RGB (1998) has been recommended, although many people just keep the image in the scanner's or camera's color space when editing. The RGB profile should be embedded when saved (not always done and why we have untagged RGB coming into prepress). If we receive the image with an RGB profile embedded, we honor/use that profile to keep intended appearance (so if the profile is embedded before we receive it, we can achieve intended appearance within limitations of the output device). The RGB can be converted to CMYK at any point in the workflow, but the intended appearance will not be kept if the embedded profile is ignored/not used at any point in the workflow. If untagged RGB is received by a person or application, it has to use a profile to display the numbers in the file. Which profile is assumed makes the difference as to what the final output looks like. I used to go by Adobe's recommendations and use U.S. Prepress Defaults color settings. I got tired of printing sunburned reds (because the untagged RGB was assuming Adobe RGB (1998) which was Adobe's default RGB profile in that color settings file). I decided to use sRGB IEC61966-2.1 for multiple reasons and have been very satisfied since. So besides reading about it from color management experts, experience has taught me that sRGB IEC61966-2.1 is the best profile to assume for untagged RGB received. Now if everybody embedded the RGB profile when saving their images, then we wouldn't encounter untagged RGB images and all would be better. Quark 7 would see and use the embedded RGB profile in a new Quark 7 project. Adobe does also. The sRGB IEC61966-2.1 would ONLY be used when encountering untagged RGB, and for output destined for the internet.

                            How that RGB is converted in CMYK can be easily done, but that doesn't mean one will get the closest match to the intended appearance. How those out-of-gamut colors (that are outside of the gamut for the destination, such as a press profile) are mapped in the the destination profile all depends on the CMYK profile (and really depends on the program that made that CMYK profile, because all CMYK profiles, even from the same characterization data, are not created equal. They don't give the same results as each other even if based on the same characterization data (such as GRACoL2006_Coated1).

                            Don

                            Comment


                            • #15
                              Re: Pantone issue in QRK 6 and 7

                              Well, I still get completely lost, but I'll have to tackle it when I can finally handle CM. I'll be screaming for help.

                              I am lucky in that I am not prepress/printer and have the time to edit and convert all photos within Photoshop. They're always CMYK before design and layout begins. I can't imagine being in your position and expected to send files with embedded/linked RGB photos direct to print. After I left the newspaper I noted the habit of editorial to just import RGB photos, scale down and just send them. *Horrific!* I was previously charged with editing all photos there and the owner of publishing co. actually wrote our publisher asking how our photos came out so well. Answer: Inez (pats self on back LOL

                              Comment

                              Unconfigured Static HTML Module

                              Collapse

                              Static HTML Module Content
                              4OverStandard FinishingDuploSmartsoft (Presswise)CanonKBAUltimateTharstern
                              4OverStandard FinishingDuploCanonKBAKBA4 PeesSmartsoft (Presswise)TharsternUltimate

                              What's Going On

                              Collapse

                              There are currently 4528 users online. 104 members and 4424 guests.

                              Most users ever online was 6,597 at 10:25 AM on 04-20-2018.

                              Working...
                              X