Latest results on color models

The development log has not been written for more than a week, but it does not mean that there is no progress. On the contrary, the color model has undergone several major changes in this week.

First, consider the following basic questions:

1. Indexes should be stored in a format rather than a color pattern.
2. Each color data should also contain an Alpha value.
3. Only lab colors (or even 32 bits) are absolute. Other colors cannot exist independently, but color management files are required.

Next we will discuss it slowly:

Previously, the color and pixel concepts were obfuscated, leading to the constant consideration of the index mode as the color mode. Later, this was completely wrong. The color mode of Photoshop is only its working mode, indicating the storage mode of pixels, and the true color mode is not that rich-even in the indexing mode, it still needs to point to specific color information. Therefore, the indexing mode only uses the indexing method to store RGB/8 color information. In this way, all colors will come down to the concept of "channel color". Each color is composed of one or more channels, and each channel uses the same color bit depth, it has its own continuous value range.

In addition to its own channel, each color data also has an Alpha value. In storage, the Alpha value is completely equal to other channel values (such as R, G, and B) and has its own value range. It uses the same bit depth as other channels. If you think of it as a channel, you can use the same processing mechanism as other channels, which seems to be a good choice. However, this idea soon came into trouble: in fact, when two colors are mixed, the Alpha and channel values are not equal:

R = R' * Alpha + R * (1-alpha)
G = G' * Alpha + G * (1-alpha)
B = B '* Alpha + B * (1-alpha)

That is to say, the Alpha value is not the same as the essence of the channel of the hidden color component. It is an "added value ".

It seems easy to convert different color modes. Although there are many conversion formulas on the internet, almost no one has mentioned the concept of color management files. In fact, if there is no color management file, there is no conversion between RGB and CMYK colors because they are only relative colors. In this way, the concept of color management files must be introduced in our model, and the conversion between different color modes is carried out by the corresponding color management files. Therefore, there are two types related to the color value itself: the color mode and the color management File (colorprofile ). Colormode is used to define the channel information used by the mixed color, including the name, bit depth, and value range of each channel. colorprofile is used to define the ing between the color mode and the lab absolute color.

The reason why the color model is hard to handle is not in RGB, CMYK, and other modes. When the concept of "channel color" appears, all different modes have been transformed into one. The real trouble lies in the color depth: Apart from Bitmap 1bpc (bit per channel), there are 8bpc, 16bpc and 32bpc. When return channel values, they correspond to completely different data types (byte, int16, single ). The return types cannot be polymorphism, and the essential differences (integer and floating point) between these three data types cannot be uniformly computed at the byte level. There is a huge conflict between the abstraction of the color concept, the complexity of the color type, and the performance of data processing. To solve this problem, I decided to change the floating point to an integer and use int32 to store and calculate the 32 BPC color value. In fact, the precision will not be lost. Therefore, we came up with a special idea: we considered all the color data as a continuous int32 array, and then set the mask and offset for each precision to get the specific channel component through bitwise operations. For example, the mask of the r channel is 0x00ff0000 and the offset is 16:

R = (Value & Mask)> offset

In this way, the length of digits is also reduced. I once thought this was a perfect solution. Then a new problem emerged soon. The color model like CMYK, coupled with the alpha channel, has five components. If you use the method just now, A color occupies 8 bytes (two int32 characters), but only five bytes are used to save the information. The three bytes are greatly wasted.

With this problem, I went to study Photoshop's storage behavior and wanted to see if it would generate such a waste of space caused by byte alignment. The result is naturally none. A single 100-pixel image is 400 bytes in RGB mode (with transparency added), and 500 bytes in CMYK mode, without waste. What surprised me more is that if the image does not use every channel, or the content of a channel is completely solid, this channel will not generate data at all! That is to say, if the brightness in the r channel of an image does not change in RGB mode, only 300 bytes of memory will be used. If there is no transparency, the memory is only 200 bytes. This phenomenon proves that Photoshop stores bitmaps in units of channels, rather than pixels. Clearly, bitmap is divided into several channels. Each channel is a grayscale bitmap that only contains brightness information.

As a result, the color and bitmap model will undergo another baptism.