In general, there will be some values that neither system can represent with a literal decimal notation (or even a fraction), irrational numbers, e.g. Compare base-10 (decimal) vs base-2 (binary). The same problem in one dimension is the use of different base numeral systems to represent values on a number line. Increasing the bit depth decreases this error, although I'm not sure whether any finite bit depth would be sufficient for error-free conversion. Under the system laid out above, the 256 different shades of grey, from K to W, would appear in the intersection of both sets, but the vast majority, if not all, of the other ≈16.7 million points in each system will be in slightly different locations in space, resulting in error when we convert between them. Both sets will have the same number of points, but they will not be the same points. The set of all points defined by every possible combination of value for each parameter defines the color space. Using the same volume, our YUV white is the same W = (255, 0, 0), and black, k = (0, 0, 0) (we'll allow U and V to span from -128 to 127, with 0 being neutral). Likewise, minimum values, (Rₘᵢₙ, Gₘᵢₙ, Bₘᵢₙ) = (0, 0, 0) = K, point to our neutral "black". For our purposes, we'll just ignore this variety, and say that, for RGB, the point with all three components maxed out, (Rₘₐₓ, Gₘₐₓ, Bₘₐₓ) = (255, 255, 255) = W, gives us a neutral color, and so points to what we'd call 'white' in the chosen volume of color (in real devices, the true max values need to be calibrated to the "white" we're calling neutral, e.g.
HDR10 (and other PQ, "perceptual quantizer", systems) maps parameter values to real-world brightness values, in contrast to sRGB, which maps those same values to voltages on a device, but both do so non-linearly. The actual mappings are a bit more complicated and vary between systems-e.g. If we assume an 8-bit system, starting at 0, our max values for our parameters will be 255 (i.e.
The bit depth just tells us how many different values the parameters can take on. real numbers) for our parameters, then no conversion problem would arise, because both encoding systems would cover every point in the entire volume, but this would require an infinite bit depth, which is not going to work out. If we could encode using continuous values (i.e.
This is accomplished by applying the encoding over a specific volume of color, which is then parameterized by the parameters of our encoding system. in a Euclidean space, the gap between 2 and 3 is the same as 3 and 4, and so-on, but non-Euclidean spaces are possible, and, indeed, we generate the equivalent of a non-Euclidean mapping with the gamma function, or various other OETFs or EOTFs). Alone, these are just different coordinate systems to measure color values, and they only point to specific colors when minimum/maximum values for each parameter are assigned to an actual color (we'll assume a Euclidean space for now, but we'd also need a description of the topology of the space to know how steps relate to changes in the real values for the parameters, e.g. Recall, RGB and YUV are encoding schemes, each using three parameters-for RGB, ('red' = R, 'green' = G, 'blue' = B) and, for YUV, ('luma' = Y, 'blue projection' = U, 'red projection' = V). No, that still won't work because the set of color points available in a color space encoded using RGB aren't the same as YUV because different parameters are used to define those points.
0 kommentar(er)
