[wp-trac] [WordPress Trac] #57238: Criteria for Responsive Images of WebP: Preserve Alpha + Preserve Lossless + Smaller in size than original
WordPress Trac
noreply at wordpress.org
Tue Feb 21 12:07:37 UTC 2023
#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
More information about the wp-trac
mailing list