[wp-trac] [WordPress Trac] #36477: Responsive images (srcset) can include images larger than the full size

[WordPress Trac]

#36477: Responsive images (srcset) can include images larger than the full size
-------------------------------------------------+-------------------------
 Reporter:  peterdavehello                       |       Owner:  pbearne
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Media                                |     Version:  4.4.2
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing dev-         |     Focuses:
  feedback has-unit-tests                        |  performance
-------------------------------------------------+-------------------------

Comment (by nosilver4u):

 Alright, first off, I realized I gave you the wrong versions of a couple
 images. One had some weird artifacts, though I can't remember exactly how
 that happened. The other simply wasn't an indexed PNG, though it had few
 enough colors to be indexed, so here are the corrected images for testing:
 https://ewwwio-downloads.b-cdn.net/png-tests/Palette_icon-or8.png
 https://ewwwio-downloads.b-cdn.net/png-tests/rabbit-time-paletted-or8.png

 Second, ImageMagick, or at least the imagick extension, I'm not sure
 which, seems to struggle at identifying palette PNG images. Any image with
 transparency was identified as color type 7, which is
 imagick::IMGTYPE_TRUECOLORMATTE. So that’s not helpful for the detection
 side. There are ways of getting around that, which I had already
 implemented for EWWW IO, and you’ll see included in my code (link below).

 As I said before, the quantizeImage() method seems to be the key, but I
 was struggling to get the same results I saw earlier, when I first started
 fiddling with this.  After further examination, it is also helpful to
 check how many colors the original image has. For example, test8.png only
 has 9 colors, but is saved with a bit/pixel depth of 8, which allows 256
 colors. If we allow quantizeImage() to use 256 colors, we get a much
 larger file size.

 Instead, we could limit the new/resized image to the same number of colors
 as the original. That gives us a smaller file size, but in some cases, I
 noticed the coloration wasn’t as good, so I would recommend giving a
 buffer of 8. With test8.png, that means we allow it to use up to 17
 colors, and I always cap the maximum colors to the corresponding bit depth
 --256 for PNG8, 16 colors for bit depth 4, and so on.

 There was still a niggling issue where Imagick would refuse to save images
 as color type 3 (palette) when there was transparency. Thanks to Danack
 (maintainer of Imagick), I found the key to fixing this was to preserve
 the tRNS chunk.

 Unfortunately, even after reducing the colors and ensuring the use of a
 palette, some thumbs might still be a bit larger than the original.
 However, things are a LOT better than where we started.

 Ultimately, I’m not certain how one can build tests for this, given there
 will always be some thumbs with file sizes larger than the original, but
 here is what I’ve put together for quantizing PNG images after resizing
 and ensuring they use indexed mode:
 https://github.com/WordPress/wordpress-develop/compare/trunk...nosilver4u
 :wordpress-develop:png8-resize

 Perhaps one can just build in some “grace” for the encoder in the tests,
 and consider things “passed” if the resized image is within 10% of the
 original. Or, you could just avoid trying to generate a 1500px version of
 a 2000px PNG during testing. For example, with deskcat8.png, resizing to
 1140x1102 is just fine, but 1536x1485 was about 8kb larger than the
 original (2000x1934).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/36477#comment:57>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform