Getting a greyscale value from the Eyedropper?

[John Hawkinson]

Today, someone asked me how to pick up a gray value with the Eyedropper, and get a grayscale (K-only) color value in an otherwise CMYK document.

As we all know, the eyedropper tool gives RGB colorspace back, at least for raster images. So, fine, I get a gray rectangle with RGB:

Now, how can I convert this to grey? I can't really find a reasonable way. Converting to CMYK gives me 35/28/28/0, which is useles.

Converting to L*ab gives me 69/0/0, which seemed promising, but also is kind of a dead end:

In Illustrator, I have the choice for greyscale:

So, short of ducking over to Illustrator, is there a reasonable way to get the equivalent gray value out of InDesign?

I suppose one could write a script that uses math...but color math is hard, and it is easy to screw it up.

Of course, there is some amusing color science irony that if one tries to go the other way, say, from 39.0% K to RGB, one gets 169/171/174 . I suppose it relates to color profiles and whatnot (as does why Illustrator and InDesign may not end up with the same numbers).

Anyhow, any tips or convenient workarounds?

Sure would be nice if ID had "Grayscale" as an option like Illustrator...

[rob day]

When I ran it on my test the top returned 38, the bottom returned 47—not very useful in either case if you are looking for 40%

[Peter Spier]

And dot gain is a non-linear curve. You get more at larger dot size and less at smaller sizes (well, up to a point -- at some point the dots will merge and they all become 100%).

[Harbs.]

My equation is non-linear.

It's not perfect, but eyeballing various shades in InDesign seemed to give good results.

I wonder how good the Grayscale option in Illustrator is. Rob, do you care to run tests there?

[Peter Spier]

Harbs. wrote:

My equation is non-linear.

I didn't look closely before, but I take it the non-linearity comes from this line:

calcValue+=(calcValue/5.5);

How did you arrive at 5.5

[Harbs.]

Peter Spier wrote:

How did you arrive at 5.5

Trial and error...

[rob day]

The results are the same out of Illustrator.

Remember the question here is can you get the grayscale output value from the eyedropper (the value that shows in Sep Preview)? ID doesn't apply any dot gain to grayscale images, the values go unchanged on to the black plate. When the grayscale is inside of a PDF and the PDF includes a CMYK profile the preview depends on the embedded CMYK profile, or the ID document CMYK profile if there's no profile included. You won't be able to come up with a working formula because the sampled RGB values are dependent on the assigned CMYK profile.

[Harbs.]

rob day wrote:

The results are the same out of Illustrator.

Same as what? Same as each other (i.e. accurate), or similar to the results of my script (i.e. inaccurate)?

[rob day]

In my post 23 test I placed the grayscale in ID and exported the page as PDF/X-1a (no profile) and then as PDF/X-4 (embed profiles). Then I placed both files in an ID doc with Preserve Embedded as the policy. The two placed PDFs have different RGB proxies even though the gray output values are identical. If I do the same out of Illustrator I get the same results.

Here's my test:

http://www.zenodesign.com/forum/gspdf.zip

[Harbs.]

My question was directed at the Grayscale option in the colors panel in Illustrator.

John was looking for the same functionality in InDesign.

I just tested, and the results of my script were superior to the results in Illustrator.

It looks like Illustrator just does a straight conversion of RGB values to K -- like my first attempt at my script.

The Grayscale option in Illustrator has no color adjustment whatsoever.

[rob day]

If the aim really is to get the output K value there's no way.

Depending on what profiles are embedded the same original gray value can produce any number of RGB eyedropper values. So below is a doc with US Sheetfed Uncoated assigned with it's profile policy set to Preserve. The top PDF has no embedded profile (it gets the doc's profile). The bottom PDF has US SWOP Coated embedded and the profile is preserved. When I eyedropper the 40% patch from each image I get very different values 168|174|174 for the uncoated version, and 153|153|153 for the bottom version. In both images Sep Preview has the output as 0|0|0|40:

[Peter Spier]

So why has nobody yet asked the obvious question?

If ID KNOWS the correct grayscale numbers (and CMYK numbers, for that matter, in CMYK images), which it clearly does in seps preview, WHY is it not possible to pick those up directly from placed rasters?

[Harbs.]

Oh. I'm sure it's possible.

You interested in attempting to write a plugin to do this?

There's just very little exposed to scripting about placed images...

Harbs

[rob day]

Oh. I'm sure it's possible.

Not until ID has a grayscale space.

[Harbs.]

rob day wrote:

Not until ID has a grayscale space.

Well, it depends what you are expecting. Peter was asking why you can't get the values of the separations preview. I'm sure it's possible to get those values. If you want proper color-managed values, the yes, you are right it's not possible until InDesign supports gray profiles...

Harbs

[rob day]

I'm sure it's possible to get those values.

I can't find anything on the Sep Preview panel in the AS dictionary. Is there something there?

[Harbs.]

I'm talking C++.

Using scripting, I'm quite sure it's not possible...

Harbs

[Peter Spier]

I did not mean why is it not possible for one of you guys or through scripting, I meant why was this functionality left out of the eydropper to begin with? I guess there must be some major difference between how seps preview and the eydropper work, and that there is no easy way to connect them (well, for one thing, seps preview shows cmyk values for everything -- but it DOES need to know the real numbers at any point in order to fuction, so that information must be accessible somehow).

[Harbs.]

My guess?

The eyedropper functionality is proabably a throw-back from the very early versions.

Maybe it's time to revisit that...

[rob day]

I'm talking C++.

With the 3 native color spaces, the eyedropper accurately picks up the image's values which may or may not be the output values.

Sep Preview always shows the output values, which could be different if profiles conflict. So if the aim of the eyedropper is to pickup the image's native color then there is a difference. In the case of PDFs, Sep Preview is showing the grayscale's output value (CMYK 0|0|0|K) not the actual gray value. In the real world they are the same but in the CM world they are not. Given the complexity of PDF color, maybe reading native file color inside of a PDF isn't as easy to engineer as we are imagining?

[John Hawkinson]

I would tend to think that the eyedropper predated the Seperation Preview and whatever was written to handle the Seperation Preview was not added in to the eyedropper.

Though there is a noticable delay when starting up the Sep. Preview. Would that translate into a problematic

delay in the Eyedropper? I doubt it, but I suppose someone should think about it.

There is also a consistency problem. If the Eyedropper picks up the sep. preview values for a CMYK PDF, then is it an inconsistency that it picks up the RGB values for a legitimately RGB image? Suppose the whole ID document is going to be converted to CMYK on Export anyhow? Some might argue the tool should be consistent.

As a practical matter, I don't see it being a real issue. But.

[rob day]

If the Eyedropper picks up the sep. preview values for a CMYK PDF, then is it an inconsistency that it picks up the RGB values for a legitimately RGB image?

I think that's the engineering problem with PDF. I want the eydropper to pickup actual color value, which it does nicely for RGB, CMYK, or Lab images. Maybe those numbers aren't easily accessible with PDF.

[John Hawkinson]

Oof, this thread has begun to become difficult to keep track of [ahem!].

Anyhow, Peter asked:

So why has nobody yet asked the obvious question?

I believe I did, but no one was paying attention. Namely, back in post #5 I said:

For simplicity, etc., I really do like Peter's idea of using the Sep. Preview. I always forget about that choice. Though that makes me think that the eyedropper's RGB limitation is even dumber than I thought, and really ID should be able to eyedrop grayscale. Perhaps I'll file something.

...

But honestly, I think I'm going to avoid the color math and just use the sep. preview; oh, and maybe file a feature request. But thanks.

Perhaps that was too oblique with too many Maybes.  But it is done.

[rob day]

WHY is it not possible to pick those up directly from placed rasters?

It does for CMYK and RGB images.

The eye dropper returns 100 Black when I sample a directly placed grayscale image. PDFs could have any number of color objects and embedded profiles, so I'm guessing that's why it's an RGB proxy.

Also, the eyedropper/PDF proxy relationship isn't reliable in anyway making a script impossible. It looks like the eyedropper picks up RGB values based on the color management setting when the PDF is placed, but the preview of an untagged PDF changes with the document's profile assignment. So below I've placed the PDF into a doc with US Sheetfed Uncoated assigned, switched the assignment to US Sheetfed Coated, sampled the 40% patch, and the RGB value isn't even close:

[Harbs.]

Just a quick note that I posted an improved version of my script in my blog post here:

http://in-tools.com/article/scripts-blog/convert-colors-to-grayscal-in-indesign/

[rob day]

In your blog you're implying the eyedropper can't pick up accurate color from placed images, but as long as the link is an image (tiff, psd, jpeg) and the color space is supported by ID (RGB, Lab, CMYK) the eyedropper does get accurate source values. PDFs can have multiple color spaces, and there's no ID grayscale space, so in those cases the eyedropper returns the RGB proxy values.