[wp-trac] [WordPress Trac] #57238: Criteria for Responsive Images of WebP: Preserve Alpha + Preserve Lossless + Smaller in size than original

[WordPress Trac]

#57238: Criteria for Responsive Images of WebP: Preserve Alpha + Preserve Lossless
+ Smaller in size than original
-----------------------------+------------------------------
 Reporter:  abitofmind       |       Owner:  adamsilverstein
     Type:  feature request  |      Status:  assigned
 Priority:  normal           |   Milestone:  Future Release
Component:  Media            |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  performance
-----------------------------+------------------------------

Comment (by abitofmind):

 1) Goal setting of Responsive Images
 >> The main goal of Responsive Images is definitely asset loading speed
 > Yes... that is one goal and it is also about serving the right sized
 image for the viewer (device).

 The usability goals are to get optimal: 1) quality, 2) speed and to some
 degree 3) compatibility (multiple file formats).

 - Goal 1 could technically be achieved by just providing a single high
 definiton image, and each devices scale down as needed. For this alone no
 Responsive Image  solution like SRCSET would be necessary.
 - Responsive Images solutions only exists mostly to facilitate goal 2!
 - Seeing our end goals clearly can be helpful in the decision process how
 to fulfill the criteria (stated in issue title).

 2) When the generated images are larger than the original, it indeed makes
 no sense to include them in the SRCSET.
 - a) In theory this should not happen if the sizing algorithm gets further
 optimized now (and continually gets improved whenever new edge cases get
 reported). Please investigate with the source material and findings I
 provided to you.
 - b) I agree that as a "last safety net" it is clever to exclude the
 smaller sized variants if larger in file size. I will create a separate
 ticket and cross-reference them.
 - c) You asked for which variants this happens: My assumptions from the
 observations:
   - c1) Each sized variant created by WP Core Media will always be smaller
 in file size then the next higher sized variant. I can truly not imagine
 any anomaly with these.
   - c2) But the first X (ca. 1-2) sized variants may be larger in file
 size than the provided original if that original was very heavily
 optimized (as my provided samples prove, I'm a pro).
     - c2a) For lossless originals the only remaining possible explanation
 that I see is that the sized versions create an alpha channel with
 unnecessarily more information density (bit-depth, compression, etc) than
 in the original. Please investigate from my provided samples/findings.
 Once thats fixed I cannot foresee this to happen.
     - c2b) Metadata/byte-padding/etc you confirmed to not being happening
 for the sized variants.
     - c2c) For lossy originals with strong compression, the first Y (ca.
 1-3) lossy sized variants may be larger, as long as WP Media Core has no
 perceptual analytics and adaptive target quality but simply a fixed target
 compression a la "works well on average". For these anomalies the fallback
 solution "exclude from SRCSET" could kick in.
     - c2d) Perceptual analysis and quality targetting is out of scope for
 WP Media Core.
       - Who needs this must use a specialized 3rd party service IMHO.
       - Implementing the simple ruleset "lossless in → lossless out" and
 "lossy in → lossy out" which was implicit in PNG and JPEG, now also for
 WEBP (which can be both!) will solves the majority of anomalies, I'm sure.
       - Because competent content creators create line art images as
 lossless (and have better quality and in many cases ALSO smaller file size
 than with average lossy most of the times) and will save photos as lossy.
       - And mere "image users" (editors, bloggers) anyhow mostly get the
 images from content creators (directly or via stock image services) who
 know what they are doing.
       - Even amateur image creators will be safe with most WEBP software
 which defaults to lossy and offers lossless only in advanced settings. On
 a very few occasions they may manage to save a photo as lossless
 unintentionally. This very unlikely unhappy edge case would result in
 "larger than nesessary" reponsive image files. I think this is is better
 than punishing all pros who knowingly create line art as lossless files
 which WEBP compresses very reasonable  anyhow (contiguous areas, color
 palette reduction, etc).
     - c2e) If the collective expert conclusion here is to not preserve
 lossless WEBPs but compress all WEBPs by default, then offer a way how a
 WEBP file can signal to WordPress "I'm a lossless original and I demand
 lossless sized variants"
       - c2e1) with a very particular filename suffix such as "--lossless"
 which gets removed after upload (for nice filenames / SEO)
       - c2e2) marker in the metadata
       - c2e3) "serve lossless" checkbox in the media library / upload
 dialog. (greyed out and unchecked for lossy WEBPs)

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