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).
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.
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?
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.
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.
Just a quick note that I posted an improved version of my script in my blog post here:
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.