Re^2: A data selection problem(in3D).

[BrowserUk]

First, this code creates a hash containing an entry for each unique color in an image. Then the colors are sorted by Luma value and broken into 17 groups of colors with similar Luma. Then, an average RGB triple is calculated for each group, weighted by the pixel count of each color in the input image. This produces a coarse gradient of 17 colors with ascending luma. A linear interpolation is then performed between these reference colors to get a gradient of 256 colors.

First: thank you for your response and code.

However, there are problems with that approach.

• Weighting the colors chosen by their pixel counts biases the selection according the amount of light and shade and the balance between light and shade within the source picture.

  The source picture is used to discover the range of tones and tints reflecting from the chosen material/surface, not their proportions.

  Once you apply the gradient to models, the proportions of light and shade are (need to be) dictated by the shape and lighting angles of the target model, not the source image.

• Once you take away the weighting in the choice of the interpolation points, what you've effectively got is a straight forward linear interpolation through the colors present in the source image.

  The problem is that produces too wide a band of dark (near black) and light (near white) shades; and thus throws away too much of the primary shades that will dominate most(*) models.

• Finally, by picking an average (weighted or otherwise) in the first and last groups, you guarantee to discard the darkest and lightest shades.

  That could be addressed by making 15 groups and then end-stopping with the darkest and lightest colors found; but that will tend to emphasis the final issue.

• By interpolating (whether through rgb or hsv) between values present in the source range, you are likely to populate the gradient with colors that never appear in the source input, which unfortunately produces models that don't look right.

  This might be addressed by interpolating the between-chosen-points values and then going back to the dataset to find the 'nearest' value that exists there; but in my attempts, defining 'nearest' in a 3D space is fraught with problems, and inevitably results in uneven jumps in the gradient that stand out like sore thumbs when applied to a model.

[coicles]

It is true that the end points lose the darkest and lightest shades -- this is another point I was too lazy to addres, but assumed you could rectify this. That source image only has 200 unique colors in it, and a lot of them are non-gold shades of gray -- this image does not contain a rich color selection -- so interpolation into absent colors is necessary. And your first point (undesired patterns of brightness density) would be addressed by using brightness levels, instead of the densities of unique colors at a similar brightness, to group the "reference" colors (which I was also too lazy to do here).

[BrowserUk]

That source image only has 200 unique colors in it,

Are we talking about the same "source image"?

Because this is the one (linked from the root node) that I was referring to, and I find 63889 unique colors in it.

I then discarded 1119 outliers to concentrate on the 62770 in the upper half of this image.

[coicles]

On a different note: have you thought about an approach using clustering (like k-means)? This is what I initially thought of when I saw this problem, but then I had a negative experience with a module called Image::DominantColors.