GNOME Bugzilla – Bug 576124
Screen Color Picker Is Incorrect (OS X X11)
Last modified: 2013-10-28 18:06:36 UTC
Please describe the problem: The eyedropper tool, which is supposed to let you grab any color from your screen, does not return the correct color. Often times it is way off. Only sometimes is it close, and never is it actually correct. Steps to reproduce: 1. Create a new image of any size 2. Fill the image with a solid color (#6bb0af for instance) 3. Open up the Change Foreground Color Dialog 4. Click the eyedropper 5. Position the eyedropper over the solid color image and click 6. Repeat steps 4 and 5 multiple times and notice the erratic behavior Actual results: The eyedropper never chooses the correct, original color that you filled it with. Instead it reports seemingly random colors that are clearly wrong. Expected results: I would expect to get back the same color (#6bb0af) that I filled the image in with. Does this happen every time? Yes. Other information: My platform is Mac OS 10.4.
Hi - thanks for the bug report. I cannot reproduce this with a recent SVN version on linux. Please update to the latest stable version of GIMP (2.6.5) and report whether or not the problem persists.
I updated to GIMP 2.6.5 via http://gimp.lisanet.de/Website/Download.html The problem still persists given the original steps I described. The eyedropper appears to be simply broken for OS 10.4.
I wonder whether this is a color-management bug. What happens when you use the color picker tool (not the one in the color editing dialogs, the one that is a tool in the same sense that Airbrush is a tool). Are the results correct or incorrect? What happens when you go to 'View->Display filters' and turn off color management? Does the problematic behaviour stop?
Ah, ok, the color picker tool itself seems to work just fine. Turning off color management did not fix the original problem. It also did not affect the color picker tool (it remains correct).
What you have described suggests to me that either the OS or GTK+ is performing color management independently of GIMP. There is no other reason for the picked color to significantly mismatch, except perhaps if GTK+'s color picker is FUBAR on MacOS. This can be further narrowed down by browsing to http://html-color-codes.com/, and checking whether GIMP's color editor's color picker tool picks correct colors from the browser window. If the results of this are correct, then I would bet that this bug is caused by miscommunication between GTK+ and MacOS. On a separate topic, the way you are using GIMP is very slow. You could just use a keyboard shortcut to switch to a paint tool like Paintbrush, and CTRL+Click to pick up the foreground color. I do this constantly and it's much easier than what you say you do.
I guess the problem is not color management but the fact that the Apple X11 server does not have a root window. Thus picking the color from screen using gdk_drawable_get_image(gdk_screen_get_root_window()) is likely going to fail. Perhaps someone should contribute some OS X specific code to do this. Without the help from a developer on a Mac, there is nothing we can do.
The code for this is in libgimpwidgets/gimppickbutton.c
Sorry, I didn't mean to post that comment twice. Thanks for the tips regarding shortcuts: I will definitely use that instead. I tried using the color picker on the suggested HTML page, but changing doing so changed the focus to Safari, and the color picker was not able to pick up anything outside of the GIMP windows.
Carl-Erik, can you please check if File->Create->Screenshot works for you? This plug-in is using similar code, so this might shed some light on the issue.
Doing a screenshot doesn't let me select anything outside of the X11 GIMP windows. When I try to take a screen shot of the GIMP tool window, I just get a black image (but it seems to be the correct size). All the screen shot options seem to be limited to GIMP windows and only produce black images. There is, however, an option to Grab, which is a common OS X utility for taking screenshots. Using this option and the Grab app, I'm able to take a screenshot of anything and it is imported into GIMP.
I don't think this is surprising; what you see outside of the GIMP windows is probably not rendered by an X server.
What if you take a screenshot of the entire screen?
A shot of the whole screen creates a black canvas that seems to be the dimensions of my display. It seems like the workaround for screenshot is to use File>Create>Grab instead, and the workaround for the color picker is to use a painting tool and ctrl click the desired color.
It's somewhat difficult to point out where the bug is here. Apple provides an X11 server and it should be safe to assume that it implements all features of an X11 server. But that is obviously not the case. So I guess our best bet is to disable the color picker and the screenshot plug-in when building for OS X with the X11 backend.
You could try to use a Quartz-based build instead of using X11.
re: comment #14 the color picker thing is not really a work around, since using the color-editor colorpicker to pick colors from the image is fairly extraordinary (and quite possibly wrong, since the displayed color at a given pixel can differ somewhat from the color in the image due to things like quantization and dithering.) If I was, say, using filters on photos all the time and not painting or really using many other tools, I would instead use the color picker keyboard shortcut and just leftclick to pick colors. The paint-tool CTRL+click method is of course intended for people who paint on the image more than anything else.
I bumped with this bug today. I found that when color management is on (I'm on Linux - Ubuntu 9.04 - 64 bit, GIMP 2.6.6) the screen picker grabs a different color from the canvas. Chatting about this in the IRC channel I learned that it is because that picker isn't color managed, and makes some sense, but from the user perspective that looks odd. I use the color dialog a lot and a very common practise in my workflow is to grab a color from the canvas and drag it to a selection to fill it. I'd expect that the color grabbed is the same that I see in the canvas, but it doesn't happen. I wonder if this tool shouldn't work as the regular eyedroper when the sample is taken from the canvas and with the current behavior when the sample is taken from anywhere outside the canvas. Or at least add a warning in the status bar that it isn't color managed.
No longer occurs on gimp gtk+quartz. I can color pick just fine.
Really? Are you sure you use the screen-wide color picker?
Well, the "Change Background/Foreground Color" has it's own color picker tool button, and I can't even click it. Well, I can, but it kind of freezes Gimp's interface. Sometimes I get it back, other times I don't and it just sits there. Holding the command button and panning over to chose a color works. Using the color picker tool also works.
I Have a similar problem with the color picker tool, i am using the latest version, gimp 2.8.0 on windows. However i find that every time i use the colour picker in the fg/bg dialog to select a color, no matter where i click on the screen, i get black as my foreground colour. However the color picker tool in the tools dialog works and is accurate. The color picker tool from the fg/bg dialog worked fine, before i updated to the latest version. I have repreatedly tested it in the latest version and get the same results of the colour black each time.
The reason for this is in GDK: see bug #676362. *** This bug has been marked as a duplicate of bug 676362 ***
Grr, not the same bug after all, we use the cairo surface to copy from the window.
Created attachment 215146 [details] [review] Use the Quartz core graphics API to implement gimp_pick_button_pick when building with GDK Quartz. I don't believe there's any way to implement gdk_cairo_set_source_window for the Quartz root window, short of creating a special type of cairo surface just for that. As a proof of concept I made a version of gimp_pick_button_pick that uses native Quartz calls instead of GDK. This patch is basically the same code as the MyPaint patch, tweaked a bit to be pure C. It's still impossible to pick colors outside of the gimp window though because GTK+Quartz doesn't implement a real pointer grab.
I have the same problem, using Win 7 64 bit. When I create a completely new image, fill it with the color #888888, the color picker of the foreground color window will choose #878787. When I fill the area with this color and use the color picker again, it picks #868686. Repeating this will result in #858585, next turn in #848484 and so on. The "normal" color picker from the toolbox works fine. Switching off color management did not have any effect.
Now that we supply native packages, this issue is obsolete. Any further bugs on other platforms should go into their own respective bug reports.
I don't know why this bug was closed, it's not fixed.
It was closed because it had been reported with a X11-based version. Bug #694422 was reported with a native one.
Ah I see, I'll leave it open anyway until I looked into the attached patch, it's needed anyway.
X11 on osx is no longer supported.
*** Bug 694422 has been marked as a duplicate of this bug. ***