Ask Your Question

Revision history [back]

Converting LUV-->RGB-->LUV results in different values

Hello, I am currently doing a project that involves manipulating images in LUV space (specifically, equating the average magnitude of the UV vector for a set of images), then converting them back to RGB. However, I am having an issue, where if I start with an image in LUV space, then convert it to RGB, then convert it back, the image changes (in Python):

luv1 = copy.copy(obj_colored) rgb1 = (cv2.cvtColor(np.array(luv1), cv2.COLOR_Luv2RGB)255).astype('uint8') luv2 = cv2.cvtColor(np.array(rgb1).astype('float32')/255, cv2.COLOR_RGB2Luv) rgb2 = (cv2.cvtColor(np.array(luv2), cv2.COLOR_Luv2RGB)255).astype('uint8') luv3 = cv2.cvtColor(np.array(rgb1).astype('float32')/255, cv2.COLOR_RGB2Luv)

np.max(luv2-luv1) Answer: 21.93

However:

np.max(np.abs(rgb2.astype(float)-rgb1.astype(float))) Answer: 1 barely any change

np.max(np.abs(luv3.astype(float)-luv2.astype(float))) Answer: 0 no change

So, in short, it seems to be the case that the RGB values don't change: the initial LUV image is cast to some set of RGB values, and when you convert those RGB values back to LUV, you get new values. So, two sets of LUV coordinates seem to map to the same RGB coordinates... and as long as you're creating the LUV values from RGB values, you get consistent results, but if you start with some LUV values and map to RGB, you won't necessarily get the same LUV values if you try to go back the other way.

I have verified that the initial image, obj_colored (which is in LUV space), has values that fall within the acceptable range in all channels (0<l&lt;100, -134<u&lt;220,="" -140<v&lt;122).="" <="" p="">

Any idea what might be going on? Are there some LUV values that have no corresponding RGB values, so the conversion algorithm does the best it can?

Converting LUV-->RGB-->LUV results in different values

Hello, I am currently doing a project that involves manipulating images in LUV space (specifically, equating the average magnitude of the UV vector for a set of images), then converting them back to RGB. However, I am having an issue, where if I start with an image in LUV space, then convert it to RGB, then convert it back, the image changes (in Python):

luv1 = copy.copy(obj_colored) rgb1 = (cv2.cvtColor(np.array(luv1), cv2.COLOR_Luv2RGB)255).astype('uint8') luv2 = cv2.cvtColor(np.array(rgb1).astype('float32')/255, cv2.COLOR_RGB2Luv) rgb2 = (cv2.cvtColor(np.array(luv2), cv2.COLOR_Luv2RGB)255).astype('uint8') luv3 = cv2.cvtColor(np.array(rgb1).astype('float32')/255, cv2.COLOR_RGB2Luv)

np.max(luv2-luv1) Answer: 21.93

np.max(luv3-luv2) Answer: 0.78480256

However:

np.max(np.abs(rgb2.astype(float)-rgb1.astype(float))) Answer: 1 barely any change

np.max(np.abs(luv3.astype(float)-luv2.astype(float))) Answer: 0 no change

So, in short, it seems to be the case that the RGB values don't change: the initial LUV image is cast to some set of RGB values, and when you convert those RGB values back to LUV, you get new values. So, two sets of LUV coordinates seem to map to the same RGB coordinates... and as long as you're creating the LUV values from RGB values, you get consistent results, but if you start with some LUV values and map to RGB, you won't necessarily get the same LUV values if you try to go back the other way.

I have verified that the initial image, obj_colored (which is in LUV space), has values that fall within the acceptable range in all channels (0<l&lt;100, -134<u&lt;220,="" -140<v&lt;122).="" <="" p="">

Any idea what might be going on? Are there some LUV values that have no corresponding RGB values, so the conversion algorithm does the best it can?

Converting LUV-->RGB-->LUV results in different values

Hello, I am currently doing a project that involves manipulating images in LUV space (specifically, equating the average magnitude of the UV vector for a set of images), then converting them back to RGB. However, I am having an issue, where if I start with an image in LUV space, then convert it to RGB, then convert it back, the image changes (in Python):

luv1 = copy.copy(obj_colored)
copy.copy(obj_colored) 
rgb1 = (cv2.cvtColor(np.array(luv1), cv2.COLOR_Luv2RGB)255).astype('uint8')
cv2.COLOR_Luv2RGB)*255).astype('uint8')
luv2 = cv2.cvtColor(np.array(rgb1).astype('float32')/255, cv2.COLOR_RGB2Luv)
rgb2 = (cv2.cvtColor(np.array(luv2), cv2.COLOR_Luv2RGB)255).astype('uint8')
cv2.COLOR_Luv2RGB)*255).astype('uint8')
luv3 = cv2.cvtColor(np.array(rgb1).astype('float32')/255, cv2.COLOR_RGB2Luv)

cv2.COLOR_RGB2Luv)

np.max(luv2-luv1) Answer: 21.93

np.max(luv3-luv2) Answer: 0.78480256

However:

np.max(np.abs(rgb2.astype(float)-rgb1.astype(float))) Answer: 1 barely any change

So, in short, it seems to be the case that the RGB values don't change: the initial LUV image is cast to some set of RGB values, and when you convert those RGB values back to LUV, you get new values. So, two sets of LUV coordinates seem to map to the same RGB coordinates... and as long as you're creating the LUV values from RGB values, you get consistent results, but if you start with some LUV values and map to RGB, you won't necessarily get the same LUV values if you try to go back the other way.

I have verified that the initial image, obj_colored (which is in LUV space), has values that fall within the acceptable range in all channels (0<l&lt;100, -134<u&lt;220,="" -140<v&lt;122).="" <="" p="">

Any idea what might be going on? Are there some LUV values that have no corresponding RGB values, so the conversion algorithm does the best it can?

click to hide/show revision 4
None

updated 2018-12-16 06:42:43 -0600

berak gravatar image

Converting LUV-->RGB-->LUV results in different values

Hello, I am currently doing a project that involves manipulating images in LUV space (specifically, equating the average magnitude of the UV vector for a set of images), then converting them back to RGB. However, I am having an issue, where if I start with an image in LUV space, then convert it to RGB, then convert it back, the image changes (in Python):

luv1 = copy.copy(obj_colored) 
rgb1 = (cv2.cvtColor(np.array(luv1), cv2.COLOR_Luv2RGB)*255).astype('uint8')
luv2 = cv2.cvtColor(np.array(rgb1).astype('float32')/255, cv2.COLOR_RGB2Luv)
rgb2 = (cv2.cvtColor(np.array(luv2), cv2.COLOR_Luv2RGB)*255).astype('uint8')
luv3 = cv2.cvtColor(np.array(rgb1).astype('float32')/255, cv2.COLOR_RGB2Luv)

np.max(luv2-luv1)
Answer: 21.93

np.max(luv3-luv2)
Answer: 0.78480256

np.max(luv2-luv1) Answer: 21.93

np.max(luv3-luv2) Answer: 0.78480256

However:

np.max(np.abs(rgb2.astype(float)-rgb1.astype(float)))
Answer: 1 barely **barely any change

change**

So, in short, it seems to be the case that the RGB values don't change: the initial LUV image is cast to some set of RGB values, and when you convert those RGB values back to LUV, you get new values. So, two sets of LUV coordinates seem to map to the same RGB coordinates... and as long as you're creating the LUV values from RGB values, you get consistent results, but if you start with some LUV values and map to RGB, you won't necessarily get the same LUV values if you try to go back the other way.

I have verified that the initial image, obj_colored (which is in LUV space), has values that fall within the acceptable range in all channels (0<l&lt;100, -134<u&lt;220,="" -140<v&lt;122).="" <="" p="">

(0<L<100, -134<u<220, -140<v<122).

Any idea what might be going on? Are there some LUV values that have no corresponding RGB values, so the conversion algorithm does the best it can?