1

I'm currently trying to start with an original RGB image, convert it to LUV, perform some operations (namely, rotate the hues), then rotate it back to RGB for display purposes. However, I'm encountering a vexing issue where the RGB-to-LUV conversion (and vice versa) seems to be changing the image. Specifically, if I begin with an LUV image, convert it to RGB, and then change it back to LUV, without changing anything else, the original image is different. This has happened for both the Python (cv2) and Matlab (open source) implementations of the color conversion algorithms, as well as my own hand-coded ones based on. Here is an example:

luv1 = np.array([[[100,6.12,0]]]).astype('float32')
rgb1 = cv2.cvtColor(luv1,cv2.COLOR_Luv2RGB)
luv2 = cv2.cvtColor(rgb1,cv2.COLOR_RGB2Luv)
print(luv2)
[[[99.36293    1.3064307 -1.0494182]]]

As you can see, the LUV coordinates have changed from the input. Is this because certain LUV coordinates have no direct match in RGB space?

bulldog91
  • 73
  • 1
  • 9
  • Can you give a specific RGB or LUV value that shows the kind of discrepancy you report here? Your code doesn't include any inputs. – Mark Ransom Dec 14 '18 at 00:02
  • Added, sorry for the original bad formatting. – bulldog91 Dec 14 '18 at 21:41
  • If you're interested in rotating hue without requiring LUV, you could look at https://stackoverflow.com/a/8510751/5987. Strangely enough I left a Python answer on an Objective-C question. – Mark Ransom Dec 14 '18 at 21:57
  • As I suggested, your Luv value is out of gamut. At L=100, u and v can only be 0, as L=100 is pure white, color cannot be distinguished. See the picture of the Luv gamut that I had linked in my answer. – Cris Luengo Dec 15 '18 at 00:41

1 Answers1

3

Yes, remove the astype('uint8') bit in your code, and the difference should disappear if the conversion is implemented correctly.

You can see the equations for the conversion in Wikipedia. There is nothing there that is irreversible, the conversions are perfect inverses of each other.

However, this conversion contains a 3rd power, which does stretch some values significantly. The rounding of the conversion to an integer can introduce a significant shift of color.

Also, the Luv domain is highly irregular and it might not be easy to verify that Luv values will lead to a valued RGB value. Your statement "I've verified that luv1 has entries that all fall in the allowable input ranges" makes me believe that you think the Luv domain is a box. It is not. The ranges for u and v change with L. One good exercise is to start with a sampling of the RGB cube, and map those to Luv, then plot those points to see the shape of the Luv domain. Wikipedia has an example of what this could look like for the sRGB gamut.

The OpenCV cvtColor function will clamp RGB values to the [0,1] range (if of type float32), leading to irreversible changes of color if the input is out of gamut.

Here is an example that shows that the conversion is reversible. I start with RGB values because these are easy to verify as valid:

import numpy as np
import cv2

rgb1 = np.array([[[1.0,1.0,1.0],[0.5,1.0,0.5],[0.0,0.5,0.5],[0.0,0.0,0.0]]], 'float32')
luv1 = cv2.cvtColor(rgb1, cv2.COLOR_RGB2Luv)
rgb2 = cv2.cvtColor(luv1, cv2.COLOR_Luv2RGB)
np.max(np.abs(rgb2-rgb1))

This returns 2.8897537e-06, which is numerical precision for 32-bit floats.

Cris Luengo
  • 55,762
  • 10
  • 62
  • 120