Port Dominant Color from performance plugin to core

[pbearne]

As part of the performance module life cycle, we want to port this site health check to the core.
​https://github.com/WordPress/performance/tree/trunk/modules/images/dominant-color

Performance issue GH link: ​https://github.com/WordPress/performance/issues/417

Trac ticket: https://core.trac.wordpress.org/ticket/56151

[joyously]

When I was writing a similar function, I noticed that using a 1 x 1 resize results in a muddy color that is sort of the average of the colors in the image, but not any of those colors.
The test cases use a lot of single color images to test with, so you might not see this.

@pbearne Coding standard issues.

[pbearne]

Replying to joyously:

When I was writing a similar function, I noticed that using a 1 x 1 resize results in a muddy color that is sort of the average of the colors in the image, but not any of those colors.
The test cases use a lot of single color images to test with, so you might not see this.

Yes, the colors are muddy/muted which is fine for this use

[johnbillion]

Proposal: ​https://make.wordpress.org/core/2022/07/21/proposal-add-a-dominant-color-background-to-images/

this version has a theme feature flag option

Trac ticket: https://core.trac.wordpress.org/ticket/56151

this version has a theme feature flag option

Trac ticket: https://core.trac.wordpress.org/ticket/56151

All references to dominant_color_ function names should be renamed to wp_dominant_color_

@pbearne Before assigning me to code review, please ensure that coding standards and unit tests are passing.

[davidbaumwald]

Thinking and talking about this during WCUS, I am on board with gathering the dominant color of the image on upload and saving it with the rest of the serialized metadata.

However, I still think the usage of the meta should purely be a theme decision. Duotone images were one instance I thought about where a user would potentially get a color not represented in the image.

[pbearne]

Replying to davidbaumwald:

Thinking and talking about this during WCUS, I am on board with gathering the dominant color of the image on upload and saving it with the rest of the serialized metadata.

However, I still think the usage of the meta should purely be a theme decision. Duotone images were one instance I thought about where a user would potentially get a color not represented in the image.

that is why we have added the theme support flag so fin grain control can be done via the theme :-)

[nickchomey]

FYI, I will be submitting a PR for this issue ​https://github.com/WordPress/performance/issues/2519 in the near future. It is a vastly better, yet similarly lightweight, solution than the solid placeholder images. Would be fantastic if it could get into Core for 7.1, along with things like the Client-side media processing.

ps. As part of that effort, I did EXTENSIVE experimentation into how to extract the dominant color, which is a necessary component in generating the gradients, and ultimately concluded that the simple 1x1 resize was the best approach. The differences in final gradient images were negligible as compared to complicated and expensive things like ColorThief. It was just a bonus that the plugin already did 1x1, so cleanest to piggyback that.

[pbearne]

Replying to nickchomey:

FYI, I will be submitting a PR for this issue ​https://github.com/WordPress/performance/issues/2519 in the near future. It is a vastly better, yet similarly lightweight, solution than the solid placeholder images. Would be fantastic if it could get into Core for 7.1, along with things like the Client-side media processing.

ps. As part of that effort, I did EXTENSIVE experimentation into how to extract the dominant color, which is a necessary component in generating the gradients, and ultimately concluded that the simple 1x1 resize was the best approach. The differences in final gradient images were negligible as compared to complicated and expensive things like ColorThief. It was just a bonus that the plugin already did 1x1, so cleanest to piggyback that.

It was always my hope for this to be in the core
and hidden behind a theme feature flag so theme dev can turn it on

Happy to help once this is blessed
We will need to refresh the code to reflect the updates made in the performs plugin since my original patch

[nickchomey]

Curious why hidden behind a theme feature flag? (I'm not all that familiar with theme or core development)

[pbearne]

Replying to nickchomey:

Curious why it's hidden behind a theme feature flag? (I'm not all that familiar with theme or core development)

The issue is that a theme might already have code in place, and this conflict

Look up add_theme_support()