Vtyjkyuk

So I'm designing a few programs for editing photos in python using PIL and one of them was converting an image to greyscale (I'm avoiding the use of any functions from PIL).

The algorithm I've employed is simple: for each pixel (colour-depth is 24), I've calculated the average of the R, G and B values and set the RGB values to this average.

My program was producing greyscale images which seemed accurate, but I was wondering if I'd employed the correct algorithm, and I came across this answer to a question, where it seems that the 'correct' algorithm is to calculate 0.299 R + 0.587 G + 0.114 B.

I decided to compare my program to this algorithm. I generated a greyscale image using my program and another one (using the same input) from a website online (the top Google result for 'image to grayscale'.

To my naked eye, it seemed that they were exactly the same, and if there was any variation, I couldn't see it. However, I decided to use this website (top Google result for 'compare two images online') to compare my greyscale images. It turned out that deep in the pixels, they had slight variations, but none which were perceivable to the human eye at a first glance (differences can be spotted, but usually only when the images are laid upon each other or switched between within milliseconds).

My Questions (the first is the main question):

1. Are there any disadvantages to using my 'rough' greyscale algorithm?


2. Does anyone have any input images where my greyscale algorithm would produce a visibly different image to the one that would be 'correct' ?


3. Are there any colours/RBG combinations for which my algorithm won't work as well?

My key piece of code (if needed):

def greyScale(pixelTuple):
 return tuple([round(sum(pixelTuple) / 3)] * 3)

The 'correct' algorithm (which seems to heavily weight green):

def greyScale(pixelTuple):
 return tuple([round(0.299 * pixelTuple[0] + 0.587 * pixelTuple[1] + 0.114 * pixelTuple[2])] * 3)

My input image:

The greyscale image my algorithm produces:

The greyscale image which is 'correct':

When the greyscale images are compared online (highlighted red are the differences, using a fuzz of 10%):

Despite the variations in pixels highlighted above, the greyscale images above appear as nearly the exact same (at least, to me).

Also, regarding my first question, if anyone's interested, this site has done some analysis on different algorithms for conversions to greyscale and also has some custom algorithms.

EDIT:

In response to @Szulat's answer, my algorithm actually produces this image instead (ignore the bad cropping, the original image had three circles but I only needed the first one):

In case people are wondering what the reason for converting to greyscale is (as it seems that the algorithm depends on the purpose), I'm just making some simple photo editing tools in python so that I can have a mini-Photoshop and don't need to rely on the Internet to apply filters and effects.

Reason for Bounty: Different answers here are covering different things, which are all relevant and helpful. This makes it quite difficult to choose which answer to accept. I've started a bounty because I like a few answers listed here, but also because it'd be nice to have a single answer which covers everything I need for this question.

The images look pretty similar, but your eye can tell the difference, specially if you put one in place of the other:

For example, you can note that the flowers in the background look brighter in the averaging conversion.

It is not that there is anything intrinsically "bad" about averaging the three channels. The reason for that formula is that we do not perceive red, green and blue equally, so their contributions to the intensities in a grayscale image shouldn't be the same; since we perceive green more intensely, green pixels should look brighter on grayscale. However, as commented by Mark there is no unique perfect conversion to grayscale, since we see in color, and in any case everyone's vision is slightly different, so any formula will just try to make an approximation so pixel intensities feel "right" for most people.

The most obvious example:

1. Original




2. Desaturated in Gimp (Lightness mode - this is what your algorithm does)




3. Desaturated in Gimp (Luminosity mode - this is what our eyes do)

So, don't average RGB. Averaging RGB is simply wrong!

(Okay, you're right, averaging might be valid in some obscure applications, even though it has no physical or physiological meaning when RGB values are treated as color. By the way, the "regular" way of doing weighted averaging is also incorrect in a more subtle way because of gamma. sRGB should be first linearized and then the final result converted back to sRGB (which would be equivalent of retrieving the L component in the Lab color space))

You can use any conversion equation, scale, linearity. The one you found:

I = 0.299 R + 0.587 G + 0.114 B

is based on average human eye "average" primary color (R,G,B) perception sensitivity (at least for the time period and population/HW it was created on; bear in mind those standards were created before LED,TFT, etc. screens).

There are several problems you are fighting against:

1. 
   

   our eyes are not the same

   
   
   

   All humans do not perceive color the same way. There are major discrepancies between genders and smaller also between regions; even generation and age play a role. So even an average should be handled as "average".

   
   
   

   We have different sensitivity to intensity of light across the visible spectrum. The most sensitive color is green (hence the highest weight on it). But the XYZ curve peaks can be at different wavelengths for different people (like me I got them shifted a bit causing difference in recognition of certain wavelengths like some shades of Aqua - some see them as green some as blue even if none of them have any color blindness disabilities or whatever).

   
   


2. 
   

   monitors do not use the same wavelengths nor spectral dispersion

   
   
   

   So if you take 2 different monitors, they might use slightly different wavelengths for R, G, B or even different widths of the spectral filter (just use a spectroscope and see). Yes they should be "normalized" by the HW but that is not the same as using normalized wavelengths. It is similar to problems using RGB vs. White Noise spectrum light sources.

   
   


3. 
   

   monitor linearity

   
   
   

   Humans do not see on a linear scale: we are usually logarithmic/exponential (depends how you look at it) so yes we can normalize that with HW (or even SW) but the problem is if we linearize for one human then means we damage it for another.

   
   

If you take all this together you can either use averages ... or special (and expensive) equipment to measure/normalize against some standard or against a calibrated person (depends on the industry).

But that is too much to handle in home conditions so leave all that for industry and use the weights for "average" like most of the world... Luckily our brain can handle it as you cannot see the difference unless you start comparing both images side by side or in an animation :). So I (would) do:

I = 0.299 R + 0.587 G + 0.114 B
R = I
G = I
B = I

There are many different methods for converting to greyscale, and they do give different results though the differences might be easier to see with different input colour images.

As we don't really see in greyscale, the "best" method is somewhat dependent on the application and somewhat in the eye of the beholder.

The alternative formula you refer to is based on the human eye being more sensitive to variations in green tones and therefore giving them a bigger weighting - similarly to a Bayer array in a camera where there are 2 green pixels for each red and blue one. Wiki - Bayer array