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.
As mentioned in the other thread, I’ve updated my average colour plugin to detect the image type (RGB vs linear) automatically and calculate the average correctly.
I’ve also updated my blog post about industry standards, using average colour in GIMP as an example:
I don’t have much technical insight to add here but thought I would chime in with support for what @chuckhenrich is saying, from a professional user perspective.
I work in a printworks where I photograph paintings, make the colour and tone match and print reproductions.
Over the years our digital archive of clients’ artwork has grown to number in the thousands of images and we have clients ordering giclee prints to be made from digital files that I created for them almost 15 years ago.
Over the last year or two I have been transitioning my ‘department’ (just me doing the image reproduction) to a F/OSS workflow, for several reasons including stability/reliability, guarantee of future access and insulation from price gouging/enshittification.
There are now very few gaps in my F/OSS workflow at the printworks which are still filled by proprietary software, but I wouldn’t currently have full confidence in dropping Adobe Photoshop for printing for the simple reason that prints sent from GIMP do not match the colour of those sent from Photoshop. I believe I’ve been as diligent as possible with colour management when I’ve done comparisons/testing and have experimented with different variables.
This wouldn’t necessarily be a problem going forward if images were only ever to be created in and printed from GIMP but my colleagues within the business will not necessarily print from GIMP, the hard proofs of archived work that were signed off by artists were printed in Photoshop (and therefore would require manually adjusting if now printed from GIMP), and if I/we needed to transition back away from GIMP in future we would have the same headache again, only in reverse.
I’ve been hoping that I’ve simply overlooked a mistake, discrepancy or gap in my knowledge when managing colour while doing comparative tests but I haven’t found anything yet. The difference is usually only slight but ultimately any difference at all is not good enough in this context.
If even I, as a somewhat zealous free software enthusiast, have reservations about this then I will definitely struggle to convince the rest of the business to transition away from Adobe, even though I’m certain that in the long run it is a wise move.
I continue to use GIMP for everything except this colour-critical printing but I think it highlights an important area of improvement for GIMP (unless I have been a dummy and have just been doing it wrong!).