<p>Let's suggest an analogy. I have a distance of 1 centimeter and 2.54 centimeters. If I transform the latter distance to inches, then it's 1 inch. This has the same value as the first distance.</p>

<p>But 1 inch is still longer than 1 centimeter, no matter the fact that they both use the numeral 1. These numbers are attached to <em>different units</em>, so simply comparing their numerical values is meaningless.</p>

<p>So it doesn't matter if the 8-bit unsigned, normalized value of 255 happens to have the same value of 1. Because you cannot compare them when they are in different spaces like that. Your original values were both in 8-bit normalized, unsigned integer space. If you want to compare them in a floating-point space, you have to transform <em>both</em> of them.</p>

CC BY-SA 4.0
2019-11-06T05:05:38.330Z
superb, I never realised that data type was changing while converting and yes, when converting to same data-type they are giving the expected result.
Mark
CC BY-SA 4.0
2019-11-06T03:53:59.523Z
2019-11-06T03:53:59.523Z
Nicol Bolas
<p>There is a popular technique of normalising images by dividing each pixel with 255 so that it comes in the range of 0 and 1.<br>
But, then how the same colours are formed when we normalize images.<br>
for instance, there is a pixel with value <code>0 1 1</code> and other <code>0 255 255</code>, I checked on <a href="https://www.rapidtables.com/web/color/RGB_Color.html" rel="nofollow noreferrer">RGB colors chart</a>, both are showing different colors, but if we normalise the second pixel values then its value will be same as the first one and it should produce different results but on plotting the set of normalized pixels, they come out to be same as the previous one.</p>

<p>I have previously asked this question - <a href="https://computergraphics.stackexchange.com/questions/9104/how-rgb-images-are-formed">how RGB images are formed</a>
so deriving out conclusions from the above question.</p>

CC BY-SA 4.0
2019-11-05T20:33:31.257Z
Somewhere down the line this is still mapped to whatever you monitor supports.
lightxbulb
<image-processing><image>
How RGB images are formed when normalized between 0 and 1
Mark
# How RGB images are formed when normalized between 0 and 1

(Asked by: username_0 on 2019-11-05)

There is a popular technique of normalising images by dividing each pixel with 255 so that it comes in the range of 0 and 1.  
But, then how the same colours are formed when we normalize images.  
for instance, there is a pixel with value `0 1 1` and other `0 255 255`, I checked on [RGB colors chart](https://www.rapidtables.com/web/color/RGB_Color.html), both are showing different colors, but if we normalise the second pixel values then its value will be same as the first one and it should produce different results but on plotting the set of normalized pixels, they come out to be same as the previous one.

I have previously asked this question - [how RGB images are formed](https://computergraphics.stackexchange.com/questions/9104/how-rgb-images-are-formed)
so deriving out conclusions from the above question.

**Tags:** image-processing, image

> **Comments:**
> **username_1**: Somewhere down the line this is still mapped to whatever you monitor supports.  

---

## 1 answers

### Answer by username_2 on 2019-11-06. Score: 1 | Accepted answer

Let's suggest an analogy. I have a distance of 1 centimeter and 2.54 centimeters. If I transform the latter distance to inches, then it's 1 inch. This has the same value as the first distance.

But 1 inch is still longer than 1 centimeter, no matter the fact that they both use the numeral 1. These numbers are attached to *different units*, so simply comparing their numerical values is meaningless.

So it doesn't matter if the 8-bit unsigned, normalized value of 255 happens to have the same value of 1. Because you cannot compare them when they are in different spaces like that. Your original values were both in 8-bit normalized, unsigned integer space. If you want to compare them in a floating-point space, you have to transform *both* of them.

> **Comments:**
> **username_0**: superb, I never realised that data type was changing while converting and yes, when converting to same data-type they are giving the expected result.  

---

