Implementation of principal-component color reduction.

ui/gfx/color_utils.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef UI_GFX_COLOR_UTILS_H_
 #define UI_GFX_COLOR_UTILS_H_
 
 #include "base/basictypes.h"
 #include "third_party/skia/include/core/SkColor.h"
 #include "ui/base/ui_export.h"
+#include "ui/gfx/rect.h"
+#include "ui/gfx/vector3d_f.h"
 
 class SkBitmap;
 
 namespace color_utils {
 
 // Represents an HSL color.
 struct HSL {
   double h;
   double s;
   double l;
@@ skipping 49 matching lines @@
 // NOTE: This won't do anything but waste time if the supplied foreground color
 // has a luma value close to the midpoint (0.5 in the HSL representation).
 UI_EXPORT SkColor GetReadableColor(SkColor foreground, SkColor background);
 
 // Invert a color.
 UI_EXPORT SkColor InvertColor(SkColor color);
 
 // Gets a Windows system color as a SkColor
 UI_EXPORT SkColor GetSysSkColor(int which);
 
+// Apply a color reduction transform defined by |color_transform| vector to
+// |source_bitmap|. The result is put into |target_bitmap|, which is expected
+// to be initialized to the required size and type (SkBitmap::kA8_Config).
+// If |scale_result|, result is linearly scalled to fit 0-0xFF range. Otherwise,
+// data is clipped to fit the range.
+// Returns the effective processed range.

[Alexei Svitkine (slow), 2013/02/21 16:49:59]

Can the comment elaborate more on what "the effective processed range" is? In
which cases would it differ from the size of the source bitmap?

[motek., 2013/02/21 18:38:43]

Changed the return type, this whole idea wasn't any good. Should be simpler now.

+UI_EXPORT gfx::Rect ApplyColorReduction(const SkBitmap& source_bitmap,
+                                        const gfx::Vector3dF& color_transform,
+                                        bool scale_result,
+                                        SkBitmap* target_bitmap);
+
+// Compute a monochrome image representing the principal color component of
+// the |source_bitmap|. The result is stored in |target_bitmap|, which must be
+// initialized to the required size and type (SkBitmap::kA8_Config).

[Alexei Svitkine (slow), 2013/02/21 16:49:59]

Why not have the function do the initialization of the resulting bitmap? In
fact, I'd suggest just returning a SkBitmap here instead of taking the second
param and returning a SkBitmap() in case of failure (which the caller can check
.empty() on to detect this).

[motek., 2013/02/21 18:38:43]

In processing images it is generally expected that the same buffer will be
reused over and over and so I believe that for this set of cases we are
generally better off with a convention where an allocated image is passed as a
parameter. In this particular case it doesn't matter much, there is only a
negligible improvement I'll be able to extract from that (if principal component
computation fails, I'll need to put out some other monochrome image; luminance
most likely), so what you suggest would work. But in general I thought the
convention should be as implemented here. 

+// Returns true if the conversion succeeded. Note that there might be legitimate
+// reasons for the process to fail even if all input was correct. This is a
+// condition the caller must be able to handle.
+UI_EXPORT bool ComputePrincipalComponentImage(const SkBitmap& source_bitmap,
+                                              SkBitmap* target_bitmap);
+
 }  // namespace color_utils
 
 #endif  // UI_GFX_COLOR_UTILS_H_