Thank you, @ecksite. That looks very promising! 🙂
Would you mind fixing the whitespaces and adding a unit test for this?

Also, please help me understand: This also adds the lazy-loading functionality for images that don't have an wp-image-* class? But are the colors also generated during the add_attachment action for those kinds of images? I am not familiar with WooCommerce, which is why I am asking.

Would you mind fixing the whitespaces and adding a unit test for this?

Sure, im trying to find time for it.

Also, please help me understand: This also adds the lazy-loading functionality for images that don't have an wp-image-* class?

If you refer to my post in the wp support forum:
Aactually I missed the point, that the "the_content" filter in fact addresses shortcode output (if priority is high enough).
But no, it does not add the functionality to woocommerce images, because their output seems not to be filtered by 'the_content'.
Nevertheless it adds lazy-loading functionality for all those images, that could be found in the media library and is a step forward for other filters.
To achieve the dominant color matching it looks like it is necessary to find the corresponding attachment id.
I used wp_get_attachment_url to achieve that in general. Because this hook use the correct "full" url of the images, this did not work out of the box for html src-tags with cropped images (like https://localhost/image-300x300.jpg. I added some regex in order for this to work. I'm not quite a regex master, so my pattern could be optimized.

But are the colors also generated during the add_attachment action for those kinds of images? I am not familiar with WooCommerce, which is why I am asking.

Well, so far as i can tell is woocommerce using the native wordpress media uploader. So everytime someone adds a image by hand, the add_attachment actions should be called and the colors should be generated and saved, right?
After filtering the woocommerce output (not just the woocommerce shortcode output) the general + color functionality should then be given for product images as well.
Thats something for the next issue, i think. But because i dont like those messy lazy load plugins from the wp plugin library, there is a good chance that I will make a pr for that.

Let me paraphrase that, so I know I understand it correctly…

WordPress, by default, outputs the attachment ID in its HTML classes (wp-image-1337). WooCommerce outputs images without an ID, but there's the handy attachment_url_to_postid function, which queries the database for the image URL and returns its attachment ID? But the function only works for the original URL, not cropped versions of an image?

So everytime someone adds a image by hand, the add_attachment actions should be called and the colors should be generated and saved, right?

Yes, it should, if WooCommerce isn't doing anything out of the ordinary.

WordPress, by default, outputs the attachment ID in its HTML classes (wp-image-1337).

Correct, if you insert the image using the media uploader in posts/pages etc.

WooCommerce outputs images without an ID, [...]
WC adds several classes, but without adding a id - correct.

The WooCommerce Output could be proceed using your filter and the 'post_thumbnail_html' filter, something like that:

function filter_woocommerce_post_thumbnail_html( $html, $post_id, $post_thumbnail_id, $size, $attr  ) {

    if (preg_match('/((?s).*)(<img [^>]+>)((?s).*)/', $html, $image)) {
        return $image[1] . apply_filters( 'dominant_colors', $image[2], $post_thumbnail_id) . $image[3];
    }

    return $html;
};
add_filter( 'post_thumbnail_html', 'filter_woocommerce_post_thumbnail_html', 10, 5 ); 

[...] but there's the handy attachment_url_to_postid function, which queries the database for the image URL and returns its attachment ID? But the function only works for the original URL, not cropped versions of an image?

Correct. This even enables lazy loading with dominant colors for all those images, that couldn't addressed because of the missing "wp-image-[id]" class (img tags created by hand, or img tags from shortcode output for example). Because this hook looks more expensive, I added it only as fallback in your "else" statement.

Edit:
I just saw, that I refered to "wp_get_attachment_url" (wrong) instead of the "attachment_url_to_postid" in the title of the issue, branch and commit... Just to make it clear for everyone: I used the correct hook in my code. Sorry 🤦‍♂️

Awesome, and thank you for explaining! ☺️
As soon as I find the time to test the changes locally I'll get back to you. If everything's fine I'll merge your changes and prepare a new release.

I managed to get my VVV running again (didn't touch it in a year so I had to update Virtual Box and Vagrant first), but couldn't get PHPUnit to run.

I have manually tested your changes, though, and it seems to work perfectly.

Blog Post

Images

<img class="alignnone size-medium wp-image-12" src="http://one.wordpress.test/wp-content/uploads/2018/11/abstract-300x169.png" width="300" height="169">
<img class="alignnone size-medium wp-image-13" src="http://one.wordpress.test/wp-content/uploads/2018/11/daisy-300x195.jpg"width="300" height="195">

Gallery

[gallery ids="13,12"]

URL

<img class="alignnone size-medium" src="http://one.wordpress.test/wp-content/uploads/2018/11/daisy-150x150.jpg" width="150" height="150">

Dominant Colors

Lazy-Loading

I will write a changelog entry and prepare a new release. Hopefully my SVN client still works … 😅