I’ve published a new plugin that generates the average colour for any RGB or greyscale image. It sits at the end of the Colors menu: “Average colour” (after you install it properly of course).
I was surprised that average colour wasn’t a thing in GIMP. I did a lot of research and discovered the topic generated various solutions that were all challenging in one way or another.
Then I found a thread from 2014 where someone suggested a really simple manual approach. So I took that as inspiration and automated it.
The plug-in is available in the following languages:
Dutch (Nederlands)
English (English)
French (Français)
German (Deutsch)
Italian (Italiano)
Hungarian (Magyar)
Japanese (日本語)
Polish (Polski)
Portuguese (Português)
Spanish (Español)
Ukrainian (Українська)
Chinese (Simplified) (简体中文)
Chinese (Traditional) (繁體中文)
12-01-2025, 12:06 PM (This post was last modified: 12-01-2025, 12:13 PM by Scallact.)
I consider your plugin as an essential from now on. Thanks for your work, and the explanations. And for sure, I'll use the method in some of my plugins where I used some ugly hacks to achieve a less than ideal result.
You rely on the histogram for your calculations. It would be interesting to know how GIMP's histogram calculates its means, and which color space it uses, sRGB or the color profile of the image. The API function Gimp.Drawable.histogram() documentation is not very clear about it, and it would validate the method "scientifically".
Thanks a lot for sharing!
P.S: just a small note: I think it's generally considered good practice to put a personal prefix in front of one's plugin's name, to avoid possible naming collisions in the future.
(12-01-2025, 12:06 PM)Scallact Wrote: I consider your plugin as an essential from now on. Thanks for your work, and the explanations. And for sure, I'll use the method in some of my plugins where I used some ugly hacks to achieve a less than ideal result.
You rely on the histogram for your calculations. It would be interesting to know how GIMP's histogram calculates its means, and which color space it uses, sRGB or the color profile of the image. The API function Gimp.Drawable.histogram() documentation is not very clear about it, and it would validate the method "scientifically".
Thanks a lot for sharing!
P.S: just a small note: I think it's generally considered good practice to put a personal prefix in front of one's plugin's name, to avoid possible naming collisions in the future.
Thank you very much, happy to help!
Interesting question about how GIMP calculates histogram means. My guess is that it's industry standard (whatever that is, I'm not that sciency) because calculations based on the mean values correlate with Photoshop.
I didn't know about the personal prefix convention. I'll use it going forward. Thanks for the tip!
12-02-2025, 04:27 PM (This post was last modified: 12-02-2025, 05:15 PM by Zbyma72age.)
As of January 9, 2017. There is Ofnuts for GIMP 2.10 ofn-average-fill.py, which works reliably on an available basis.
However, it is appropriate to mention that since 2009, there is a simple script sample_avg_color.scm created in by Rob Antonishen in response to requests.
It takes a medium color and allows you to set a medium color in the foreground, background, or add it to the active palette.
Its purpose is to determine the average color of the area of our selection (this can be the entire image).
With me in GIMP 2.10.38 it still works today
The script was in the repository: http://registry.gimp.org/node/16678
For me definition of "average" is whatever Gimp picks when you use the color picker with the Sample average option. On a B&W checkerboard, Gimp 2.8 picks #808080, and Gimp 2.10/Gimp 3.x pics #bcbcbc.
The acid test is to paint over the area using the picked color, normally it should hardly be visible.
(12-02-2025, 08:57 PM)Ofnuts Wrote: For me definition of "average" is whatever Gimp picks when you use the color picker with the Sample average option. On a B&W checkerboard, Gimp 2.8 picks #808080, and Gimp 2.10/Gimp 3.x pics #bcbcbc.
The acid test is to paint over the area using the picked color, normally it should hardly be visible.
I found out that the Chuck Henrich 2025 average-image-colour-v3.py plugin gives an incorrect result because: In the helpers/get_average_color file, it counts the average in sRGB space by gamma: r, g, b = get_average_rgb(drawable) ie. The average of the values after the gamma curve (and non-linear). Only then does it convert this already bad average to linear: r_lin = srgb_byte_to_linear_component® As far as I know, DO NOT count the average on sRGB data (after gamma). Is this true, because the results are always darker.
(12-02-2025, 08:57 PM)Ofnuts Wrote: For me definition of "average" is whatever Gimp picks when you use the color picker with the Sample average option. On a B&W checkerboard, Gimp 2.8 picks #808080, and Gimp 2.10/Gimp 3.x pics #bcbcbc.
The acid test is to paint over the area using the picked color, normally it should hardly be visible.
I found out that the Chuck Henrich 2025 average-image-colour-v3.py plugin gives an incorrect result because: In the helpers/get_average_color file, it counts the average in sRGB space by gamma: r, g, b = get_average_rgb(drawable) ie. The average of the values after the gamma curve (and non-linear). Only then does it convert this already bad average to linear: r_lin = srgb_byte_to_linear_component® As far as I know, DO NOT count the average on sRGB data (after gamma). Is this true, because the results are always darker.
Please no green text
You're right in a general image manipulation scenario. However it may differ depending on the use case. I use GIMP to create height maps, and in such files, the actual rgb values code the altitude. So, the average height must be calculated without conversion to linear.
For photos, which is the case the OP describes, I think that Photoshop is definitely wrong, whatever industry standard it represents. But I can also see cases where one technique would be preferable than the other. In short, I'd rather have the choice.
I’ve updated my average colour plugin to support both RGB and linear images. It detects the image type automatically and calculates the average correctly. You still need to know what kind of image you’re working with, but the plugin handles the math for you.
The traditional GIMP way to get an image’s average colour (pixelise-to-1px) delivers linear average colour. That’s fine in linear space images. But in non-linear RGB images, it gives misleading results.
Most photographers, designers, and editors work in RGB spaces like sRGB, Adobe RGB, ProPhoto, etc. That makes non-linear output the standard. Linear output is fine if your printer, collaborators, or clients expect it; otherwise, non-linear is what people rely on.
For RGB images, the plugin makes average colour easy and reliable. For linear images, you can still use pixelise if you want—but the plugin is faster and simpler. One click, and you’re done.
I've also updated my blog post about industry standards, why they matter, and use average colour in GIMP as an example:
That post explains why Photoshop is not "wrong", among other things. I encourage you to read it so you understand my reasoning.
PS, it's just weird seeing all the convoluted defensiveness in this thread about a technical issue, where I've developed - and proven - a more appropriate way to do something. Again, read my blog posts to understand more.
