New Features of android5.0L: Main Color extraction and new features of android5.0l

New Features of android5.0L: Main Color extraction and new features of android5.0l
At the last weekly meeting, experts introduced some new features of android5.0. One of them is the main color extraction. According to the product manager, we 'd better add this feature in the next phase. So, let's start to study this new feature. This is the newly added interface in the support package, that is, this interface has nothing to do with the android version. It seems that the source code is not too large. :-)
Let's take a look at the official instructions on google. Bytes. A major constructor transmits a bitmap object, and the rest is the get method series. In addition, google has added an asynchronous constructor, similar to imageloader, for ease of use. However, here is a reminder that the return value may be null in the following methods, so we need to make a parameter validity judgment before using it.

    /**     * Returns the most vibrant swatch in the palette. Might be null.     */    public Swatch getVibrantSwatch() {        return mVibrantSwatch;    }    /**     * Returns a light and vibrant swatch from the palette. Might be null.     */    public Swatch getLightVibrantSwatch() {        return mLightVibrantSwatch;    }    /**     * Returns a dark and vibrant swatch from the palette. Might be null.     */    public Swatch getDarkVibrantSwatch() {        return mDarkVibrantSwatch;    }    /**     * Returns a muted swatch from the palette. Might be null.     */    public Swatch getMutedSwatch() {        return mMutedSwatch;    }    /**     * Returns a muted and light swatch from the palette. Might be null.     */    public Swatch getLightMutedSwatch() {        return mLightMutedColor;    }    /**     * Returns a muted and dark swatch from the palette. Might be null.     */    public Swatch getDarkMutedSwatch() {        return mDarkMutedSwatch;    }

Reasonable, such a good interface should be able to get started quickly. However, in the demo, we found that in many cases, this interface did not get what we wanted, that is, we think the most color on the attached image. For example, if a gray-colored image is the dominant image at a glance, the returned result is indeed red or yellow. The color obtained from the image is no longer within the scope of normal understanding. It seems that you have to study the source code.
Like the open interface of this feature, the source code of this feature is not too complex. Package android. support. v7.graphics contains only four files, one of which is public class. Of the other three classes, two are the capability-layer code. The details are as follows:
Palette. java interface class. Provides methods and Swatch definitions.
ColorUtils. java tool class with strong business relevance. There are some static methods.
ColorHistogram. java implements the color extraction algorithm capability class.
ColorCutQuantizer. java is an encapsulation class sandwiched between ColorHistogram. java and Palette. java. However, this class provides a set of color splitting algorithms.
Here we will first look at how the ColorHistogram class implements primary color extraction. The constructor transmits an array of pixel color values. After being passed in, all color values are sorted once. The countDistinctColors method shows the color types, and the countFrequencies method shows the proportion/number of each color. This algorithm is very common. The first time I met someone who combined google comments, it seemed quite fast.

    private static int countDistinctColors(final int[] pixels) {        if (pixels.length < 2) {            // If we have less than 2 pixels we can stop here            return pixels.length;        }        // If we have at least 2 pixels, we have a minimum of 1 color...        int colorCount = 1;        int currentColor = pixels[0];        // Now iterate from the second pixel to the end, counting distinct colors        for (int i = 1; i < pixels.length; i++) {            // If we encounter a new color, increase the population            if (pixels[i] != currentColor) {                currentColor = pixels[i];                colorCount++;            }        }        return colorCount;    }    private void countFrequencies(final int[] pixels) {        if (pixels.length == 0) {            return;        }        int currentColorIndex = 0;        int currentColor = pixels[0];        mColors[currentColorIndex] = currentColor;        mColorCounts[currentColorIndex] = 1;        if (pixels.length == 1) {            // If we only have one pixel, we can stop here            return;        }        // Now iterate from the second pixel to the end, population distinct colors        for (int i = 1; i < pixels.length; i++) {            if (pixels[i] == currentColor) {                // We've hit the same color as before, increase population                mColorCounts[currentColorIndex]++;            } else {                // We've hit a new color, increase index                currentColor = pixels[i];                currentColorIndex++;                mColors[currentColorIndex] = currentColor;                mColorCounts[currentColorIndex] = 1;            }        }    }

Everything is normal here. The extracted colors should all be extracted. You can only look up. The result of ColorHistogram construction is directly thrown to the constructor of ColorCutQuantizer as a parameter. In this constructor, we found the cause:

        // Now go through all of the colors and keep those which we do not want to ignore        mColors = new int[rawColorCount];        int validColorCount = 0;        for (int color : rawColors) {            if (!shouldIgnoreColor(color)) {                mColors[validColorCount++] = color;            }        }

Google performs a color filter based on a certain standard. That is to say, the results we get through the interface are filtered out by a specific service. If we don't know the business, the color we get is of course not the color we need. Remove the filtering logic and obtain the dominant color, which is what we need. The most color in the image.
In addition, according to the official instructions of google, this interface is very fast. In the following method, google compresses the image size into a smaller image, which is an important reason for fast processing:

    public static Palette generate(Bitmap bitmap, int numColors) {        checkBitmapParam(bitmap);        checkNumberColorsParam(numColors);        // First we'll scale down the bitmap so it's shortest dimension is 100px        final Bitmap scaledBitmap = scaleBitmapDown(bitmap);

I personally think the interface layer provides better capabilities. If this interface layer provides two sets of interfaces: 1. Single Main Color extraction capability, 2. a certain color extraction algorithm. In this way, apps may be more convenient to use in the business layer.