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...

[Peter Spier · Accepted solution]

I generally just go to separations preview and read it...

[Jeffrey_Smith]

Pick up the color and change to lab. The "l" value can be used, just invert it. (i.e. "l" reading is 22, gray equivalent would be 78)

[John Hawkinson]

Jeffrey: Would you believe I tried that? At least in my color profiles,

that does not look anywhere close.

[Jeffrey_Smith]

John, after a few more tests, my suggested lab method is flawed.

[rob day]

Without a grayscale space there's no way to get a color managed  conversion to grayscale inside of ID.

With AppleScript I can go get the conversion from Photoshop. This takes the RGB fill of the current selection and gets the grayscale conversion in PS based on the current PS Color Settings:

tell application "Adobe InDesign CS5.5"

    activate

    set {a, b, c} to color value of fill color of selection

    tell application "Adobe Photoshop CS5"

        set theColor to {class:RGB color, red:a, green:b, blue:c}

        set gs to convert color theColor to grayscale

        set k to gray value of gs

    end tell

    set properties of fill color of selection to {space:CMYK, color value:{0, 0, 0, k}}

    display dialog "CMYK 0|0|0|" & k

end tell

Don't know if you can do something similar with JavaScript

edit: I added a line to update the selection fill with the converted CMYK color

[rob day]

This version keeps you in ID. It isn't a color managed conversion but comes close if your doc profile is SWOP:

tell application "Adobe InDesign CS5.5"

    set space of fill color of selection to LAB

    set {a, b, c} to color value of fill color of selection

    set myKvalue to (100 - a) * 1.15

    if myKvalue is greater than 100 then

        set myKvalue to 100

    end if

    set space of fill color of selection to CMYK

    set color value of fill color of selection to {0, 0, 0, myKvalue}

end tell

[John Hawkinson]

Hey Rob:

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.

Don't know if you can do something similar with JavaScript

You can, but it's more of a pain, since you can't use a language feature to dispatch a message to two different apps (well, not without using applescript inside your javascript). So instead you need to use Bridgetalk to send a message to Photoshop. It's enough of a pain that I'm not going to offer you the 10-second version of your script in Javascript. And I'm on a Mac anyhow, it's just a philosophical preference for JS over AS...

This version keeps you in ID. It isn't a color managed conversion but comes close if your doc profile is SWOP:

Oof. That's definitely what I meant by "I suppose one could write a script that uses math...but color math is hard, and it is easy to screw it up."

I suppose you're a domain expert in a way that I'm not,but you suggest converting to Lab, and then setting K = (100-L)*1.15, right?

It's not obvious to me why 1.15 is the right magic value, and while I'm not insisting that you have to "show your work," it'd make me a lot more comfortable to know.

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.

[rob day]

For simplicity, etc., I really do like Peter's idea of using the Sep. Preview.

I missed Peter's post—sep preview does give you the file's exact gray value. For image files the eyedropper gives you correct values for Lab, CMYK, RGB images but not for grayscale because it doesn't exist. I've been wishing out loud for a grayscale space since ID2, but something tells me it won't happen. The missing grayscale space creates a number of display problems, but no output problems so it's probably not a priority.

1.15 is indeed a magic number. Reversing the L value gets you a linear tonal scale, so multiplying by some number imitates a curve—something like what you would get with Photoshop's 20% dot gain grayscale profile.

[John Hawkinson]

Rob:

1.15 is indeed a magic number.

I know it's a magic number, that wasn't my question! What I said was, "It's not obvious to me why 1.15 is the right magic value, and while I'm not insisting that you have to 'show your work,' it'd make me a lot more comfortable to know." I.e. where does it come from?

Reversing the L value gets you a linear tonal scale, so multiplying by some number imitates a curve—something like what you would get with Photoshop's 20% dot gain grayscale profile.

Wait, what?

If I have a linear scale (blue line) and I multiply it by a constant (1.15) I get a linear scale back (red line). This is obvious since y_blue = mx + b and so y_red = (mx + b)*1.15 = (1.15m)x+1.15b, so I get a line with a slope that's 1.15 times my original slope and a slightly bigger y intercept:

[rob day]

where does it come from?

Trial and error. As I mentioned in post 6 there's no CM here.

I was about to say a color managed conversion from neutral RGB colors to a black only CMYK is impossible, but remembered I use this profile to convert a grayscale image to black only CMYK and it will also work for neutral RGB:

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

With the profile assigned to your doc, AdobeRGB 169|169|169 converts to 0|0|0|40.75—the same conversion you would get in PS converting from AdobeRGB to 20% Dot Gain grayscale.

So this simple script works:

tell application "Adobe InDesign CS5.5"

          set docprofile to CMYK profile of active document

          set CMYK profile of active document to "MaxBlack"

          set space of fill color of selection to CMYK

          set CMYK profile of active document to docprofile

end tell

[John Hawkinson]

Trial and error. As I mentioned in post 6 there's no CM here.

Oh. Ha ha, that's what I get for failing to define my terms.

In my mind (twisted and warped as it is!), if it's trial and error, it is not "magic." A magic number is one that is special; is a unique and [mostly] unchanging constant; and while its derivation may be complicated and confusing, is somehow generally accepted. For instance: "the ratio of a circle's diameter to its circumference is the magic number pi." I realize that no reasonable person might have picked my definition of magic, though.

It's also funny because the 1.15 you select is quite similar to the 1.16 (well, 116) that appears as a constant all over the Lab color space wikipedia page:

CIE XYZ to CIE L*a*b* (CIELAB) and CIELAB to CIE XYZ conversions

The forward transformation

...

The reverse transformation

The reverse transformation is most easily expressed using the inverse of the function f above:

but actually I guess it's just a coincidence since they're dividing by 116 and you're multiplying by 1.15; and we're ignoring the f(t) function, which is not insignificant. Not that XYZ tristimulus colors are CMYK colors -- in fact really they're a transformation away from RGB colors!

Oof.

[rob day]

but actually I guess it's just a coincidence

Definitely a coincidence. If you are trying to find a K value that has the same appearance as a neutral RGB value there isn't a single constant that would get you there. If you change profiles the number wouldn't work and it probably doesn't work over the entire tonal scale anyway.

The maximum black profile trick does get you the correct conversion of RGB to Dot Gain 20% grayscale, but doesn't necessarily get you the same appearance because the black only CMYK color you get is previewed through your document's CMYK profile not a Dot Gain 20% grayscale profile. If your doc is all black/grayscale you could assign the MaxBlack profile and it would work. Otherwise Sep Preview is the way to go.

[John Hawkinson]

Definitely a coincidence. If you are trying to find a K value that has the same appearance as a neutral RGB value there isn't a single constant that would get you there

For the record, that's not the actual goal -- the goal is to get the K value out of a CMYK PDF with nothing on the C/M/Y plates. The only reason RGB comes up here is because ID uses an RGB preview as a proxy to sample the dots.

(I'm sure you knew this, but I didn't want to confuse everyone else reading along who is already confused...all 198 of them! Whoa, 198 views? Geeze, that seems high. I thought this would be a lot more esoteric.)

I've marked Peter's answer as Correct. Nice that you can upgrade from Helpful to Correct in the new forum software.

[Peter Spier]

I'm not sure it really deserves a "correct" tag since it doesn't answer the question of how to use the eyedropper. It was really more of an observation than a suggested workaround.

[John Hawkinson]

While I think we should have a long debate about the merits of correctness here, because that is what dreary Saturday mornings are for, I believe it answers this question that I posed initially:

Is there a reasonable way to get the equivalent gray value out of InDesign?

Philosophically, I think if one answer stands above the rest, even if it is only 90% correct, it's probably better to flag it as Correct. In this case, I originally had yours and Rob's marked as Helpful, but after further consideration (and Rob's comments on yours), I think it's useful to distinguish yours from his.

Perhaps more to the point, it seems unlikely anyone is going to come up with answer that it more correct.

[Peter Spier]

Short debate. You win.

[Harbs.]

I'm a bit late to this party, but how's this?

var color = app.selection[0].fillColor;
if(color.space == ColorSpace.LAB||
    color.space == ColorSpace.CMYK){
    color.space = ColorSpace.RGB
}
if(color.space == ColorSpace.RGB){
    var totalValue = color.colorValue[0] + color.colorValue[1] + color.colorValue[2];
    var averageValue = totalValue/3;
    color.colorValue = [averageValue,averageValue,averageValue];
}
var calcValue = 100 - (averageValue/255 * 100);
if(calcValue > 100){
    calcValue = 100;
}
if(calcValue < 0){
    calcValue = 0;
}
color.space = ColorSpace.CMYK;
color.colorValue = [0,0,0,calcValue];

[John Hawkinson]

Harbs:

I'm a bit late to this party, but how's this?

if(color.space == ColorSpace.RGB){
    var totalValue = color.colorValue[0] + 
        color.colorValue[1] + color.colorValue[2];
    var averageValue = totalValue/3;
}
var calcValue = averageValue/255 * 100;
color.space = ColorSpace.CMYK;
color.colorValue = [0,0,0,calcValue];

Err. That does a terrible job! But what I didn't think of and just thought to try (by misreading your post!) is 100-(rgb/255). Which actually seems pretty good:

You can still see differences though. I think Peter's answer is still the best so far though...

[Harbs.]

I was tired when I wrote the script.

I fixed the code to what it should have been...

[Harbs.]

Well, any differences are InDesign's fault!

[Peter Spier]

Harbs. wrote:

Well, any differences are InDesign's fault!

RGB black is much darker than 100K. Are you guys taking that into account?

[Harbs.]

I think InDesign has dot gain in the calculations.

I'm trying to come up with an equation which will work to compensate across the spectrum...

This seems to work reasonably well when K is over 50%:

var fudgeFactor = -12;
var color = app.selection[0].fillColor;
if(color.space == ColorSpace.LAB||
    color.space == ColorSpace.CMYK){
    color.space = ColorSpace.RGB
}
if(color.space == ColorSpace.RGB){
    var totalValue = color.colorValue[0] + color.colorValue[1] + color.colorValue[2];
    var averageValue = totalValue/3;
}
var calcValue = 100 - (averageValue/255 * 100);
calcValue-=fudgeFactor;
if(calcValue > 100){
    calcValue = 100;
}
if(calcValue < 0){
    calcValue = 0;
}
var inverseValue = Math.abs(calcValue-100);
color.space = ColorSpace.CMYK;
color.colorValue = [0,0,0,calcValue];

[rob day]

Grayscale image values are put on the black plate and output unchanged (ID ignores grayscale profiles). Their previews are adjusted by the assigned CMYK profile, which could be anything. Even if you could come up with an equation that converts the RGB to the output K value, it would only work for one profile.

[Harbs.]

Like Rob says, there's no perfect method, but this is pretty darn good:

var color = app.selection[0].fillColor;
if(color.space == ColorSpace.LAB||
    color.space == ColorSpace.CMYK){
    color.space = ColorSpace.RGB
}
if(color.space == ColorSpace.RGB){
    var totalValue = color.colorValue[0] + color.colorValue[1] + color.colorValue[2];
    var averageValue = totalValue/3;
}
var calcValue = 100 - (averageValue/255 * 100);
calcValue+=(calcValue/5.5);
if(calcValue > 100){
    calcValue = 100;
}
if(calcValue < 0){
    calcValue = 0;
}
var inverseValue = Math.abs(calcValue-100);
color.space = ColorSpace.CMYK;
color.colorValue = [0,0,0,calcValue];