I really like GIMP. Version 3 is a major upgrade. In some ways it’s more advanced than commercial competitors like Photoshop and Affinity. I still use Photoshop for some things, but most of my time is in GIMP. (GIMP on Linux is a speed demon.)
But there are a few ways in which GIMP does things that don’t align with industry standards, or introduces quirks that make interoperability difficult with other systems and collaborators. My experience with average colour is a case in point.
I’ve written a follow-up to my blog post about my average colour plug-in. It focuses on why compliance with industry standards is essential for GIMP to take its (deserved) place as a professional imaging tool:
The “pixelize to 1px” seems like a very crude hack and to be honest it is not that surprising that it did not average the colors “correctly.” Seems like decades of argent could have been solved by reading the source code?
If this this function is so important, why not try and upstream this?
Yep, I agree. If you take a look at the other thread about my average colour plugin:
you’ll see there’s support for adopting a better way, as well as surprising defensiveness from some people in reaction to the idea. Sometimes old habits die hard?
Also, that pixelise approach got embedded into search results as over the years people copy/pasted the idea into answers about average colour in GIMP, without ever testing to confirm it works properly.
My experience of the GIMP developers is that they are true professionals and not at all defensive. I’m going to suggest they ingest my plugin as a future feature. But they have a lot on their plates and might decide they need to focus on other enhancements and bug fixes that aren’t already covered by third party plugins.
The “average” as described by OP is just the mathematical average of the sRGB values (#808080) for a checkerboard, average(sRGB(color))).
The average as computed by Pixelize, or a gaussian blur, is the perceived average (ie, the uniform color that look the same as the image seen from a distance) (#bcbcbc for a checkerboard, sRGB(average(color)).
Due to the sRGB curve, the result of operations done directly on sRGB values is too dark.
It isn’t “old habits”. It’s the opposite. From Gimp 0.0 to Gimp 2.8, Gimp worked on 8-bit data only, and worked on sRGB values directly, causing all sort of problems. Since 2.10 Gimp works internally on floating point data and a lot of thought has been put into doing the correct thing. Yes, it is disruptive to some, but it also makes a lot of things work much better. There are places in Gimp where you can pick the old ways (layer modes and gradients, for instance).
Sticking to SRGB processing is the QWERTY syndrome of the image industry. Gimp isn’t the laggard, it is the forerunner.
The article is about aligning GIMP with industry standards so it integrates smoothly into professional workflows. Ignoring those standards makes GIMP less interoperable and less suitable for professional use. I encourage anyone interested to re‑read the article with that in mind.
I’m not denying that some apps are still using direct sRGB computations.
Where I disagree is the “Sometimes old habits die hard?” part, because the current Gimp behavior is recent (appeared in Gimp 2.10), and the old habits dying hard are the industry’s habits.