[HN Gopher] Power Consumption of JPEG, WebP, and AVIF
___________________________________________________________________
Power Consumption of JPEG, WebP, and AVIF
Author : robin_reala
Score : 72 points
Date : 2023-08-26 11:12 UTC (11 hours ago)
(HTM) web link (fershad.com)
(TXT) w3m dump (fershad.com)
| 26fingies wrote:
| A lot of screens these days are OLED and as I understand it they
| use more energy when displaying light images than dark images.
| The screen is also a major power hog. So I wonder what the energy
| tradeoff would be by using a dark background instead of changing
| image formats
| amq wrote:
| Would be interesting to additionally see JPEG XL.
| Findecanor wrote:
| Indeed. I expected it to be included before reading.
|
| But I would also expect JPEG-XL to score worse than Webp and
| old JPEG _at_ _the_ _moment_ because it is newer and
| implementations could therefore yet be less optimised.
| tommiegannert wrote:
| > Test 1: 103 uWh (0.000103 kwh)
|
| For those who like SI base units: 100 uWh is 360 mJ.
| Pannoniae wrote:
| I don't see the point of computing the second derivative (not in
| the mathematical sense, in the everyday sense) here. Energy usage
| is a derivative of performance, which is a derivative of time
| spent on running the thing.
|
| Why didn't the blog just compare the _speed_ of those algorithms?
| Power consumption is just calculated by multiplying the runtime
| by a constant here, it 's not measured by a power meter or
| anything....
| emllnd wrote:
| Wall clock speed does not correlate linear to power consumption
| (in the general case). To oversimplify, consider decoding
| singlethreaded on one core versus multithreaded on 8 or 20
| cores.
|
| In some special cases multiplying runtime might be enough to
| achieve some accuracy, but that's not the whole story.
|
| It would be interesting to see this experiment done so that the
| decode is done enough times for each format so the power
| consumption differences could actually be measured on a
| power/watt meter.
| Pannoniae wrote:
| Yup, I know that they are not the same, but they are
| measuring wall clock, and claiming it is power
| consumption....
| zamadatix wrote:
| Where did the author use wall clock as a proxy for power
| consumption? The only time based thing I saw was power
| usage over time and that is still measuring power usage
| directly just explaining when in the process the most power
| was used.
| Sephr wrote:
| Testing on Firefox makes these figures not entirely useful due to
| a lack of support for some hardware decoders.
|
| I'd like to see an ideal comparison using hardware-based decoders
| all from the same vendor and the same manufacturing process node.
| tyzoid wrote:
| Are there any hardware accelerated decoders for static images?
| AVIF and WebP's lossy (vp8) codec might have some support, but
| I'm be curious to see what percentage of browsers actually have
| support for accelerated decoding.
| byyll wrote:
| Interesting experiment though the writer is write it's very tiny.
| Only 1 browser on 1 OS on single hardware, not taking into
| account energy spent for conversion as well as time using a
| device spent for the code doing the conversion. Also not taking
| into account if results would differ if a page has 5 images
| instead of 1. Many variables.
| weitzj wrote:
| Not on this topic, but I wonder why on your cell phone you have
| to opt-in to safe battery/energy.
|
| Like what amount of energy could you save with the leverage of
| iOS/Android if people were to opt-out of energy-saving mode
| Dwedit wrote:
| Note that Lossy Webp and Lossless Webp are two different file
| formats that happen share a file extension and library.
| neilv wrote:
| > _The grid intensity in your location is [...] g /kWh. That's
| higher than average, so this site has been modified to use less
| power on your device._
|
| They could cut their resource usage further, _beyond_ that of the
| power-saving version of their site, by getting rid of the power-
| saving detection behavior. Just do the sensible version all the
| time.
|
| Their actual HTML is pretty clean.
| vlovich123 wrote:
| I have to imagine that over time AV1 will get better CPU and
| hardware acceleration as happens with h264. Not sure measuring
| "carbon footprint" is too elucidating.
| corysama wrote:
| I would expect transmission of the data to require far more
| energy than decoding. Even loading the data from local storage
| should outweigh decoding. Math is cheap, but bits are heavy.
| Moving them is slow and expensive.
| zamadatix wrote:
| Another good control to add would be not using the default
| settings in Sqoosh.app. Just because one format defaults to high
| compression and another low compression does not say anything
| about which is more power efficient at compressing. Ideally you'd
| match up the optimized visual quality.
|
| Though really I'm not sure this question makes sense in the first
| place. Optimizing the power used by the client during decode
| specifically seems unlikely to be the best way to optimize power
| usage of the website transfer. In particular, optimized transfer
| time of the same fewer total bits to all clients should far
| outweigh any savings from using a lighter-to-decode image format.
|
| Video would be a whole different world. I wonder how the energy
| efficiency of different hardware decoders compares for even the
| same format.
| codersfocus wrote:
| I think the author will emit more carbon in their lifetime
| worrying about the web's carbon footprint than the web will emit.
|
| Of ALL the problems with environmental sustainability, you picked
| this one...
| maigret wrote:
| What you say is blatantly wrong. I advise you to read the book
| World Wide Waste. It changed my view on that topic.
| labster wrote:
| He definitely emitted more carbon from us by not including an
| abstract at the beginning.
| tedunangst wrote:
| Does seem pretty incomplete to not consider download time, etc.
| My browser doesn't turn the screen off while downloading images,
| and that uses way more power than decoding the image does.
| mikae1 wrote:
| _> There's plenty of guidance for developers to use modern image
| formats like WebP and AVIF which generally have a smaller file
| size compared to older formats like JPEG._
|
| I wouldn't consider WebP over JPEG for lossy compression of
| photographs: https://siipo.la/blog/is-webp-really-better-than-
| jpeg
| Dwedit wrote:
| Lossless WebP trounces PNG for compression level, and
| decompresses very fast too. Lossless JPEG-XL compresses better
| than Lossless WebP most of the time, but cannot compete for
| decompression performance.
| kristianp wrote:
| https://squoosh.app/
|
| Having a quick look at squoosh, it uses lossy compression of
| webp by default.
| Banditoz wrote:
| > The grid intensity in your location is 387 g/kWh. That's higher
| than average, so this site has been modified to use less power on
| your device.
|
| Interesting, my location has "high grid intensity", so it showed
| me a lite version, with low-res images and some JS <script> tags
| commented out.
|
| But the author explains the steps to determine this:
|
| 1. A Cloudflare Worker checks the request object for the country
| a visitor is located in.
|
| 2. If a location is found, then a fetch request is made to the
| CO2signal API CO2signal sends back data about the current grid
| intensity at the visitor's location.
|
| 3. The current grid intensity is checked against the annual
| average grid intensity for that country (data from CO2.js).
|
| 4. If the grid intensity is equal to or greater than the annual
| average, then the HTML response is modified using the Cloudflare
| Workers HTMLRewriter. If the grid intensity is less than the
| annual average, the regular (unmodified) site is returned to the
| user.
|
| (https://fershad.com/carbon-aware-site/)
|
| Surely all these steps combined above use more power than just
| sending the unchanged HTML page to the user?
| btdmaster wrote:
| I thought it was measuring grid intensity in a different sense,
| like high/low demand for energy. (Sometimes, the grid has high
| demand for electricity, and other times the demand is lower,
| maybe even such that wholesale electricity prices are
| negative.)
|
| Now that I think about it, I'm wondering whether Google could
| change electricity prices by e.g. flipping a switch on YouTube
| H.264 availability in a particular region...
| maigret wrote:
| Might be. For sure anyone should optimize no matter what. Of
| course now many developers only consider the number of feature
| they produce or use ("shiny new library! Will fit well on my
| CV!"), but there is a big satisfaction of improving existing
| things as well.
|
| But to decide whether this approach works, we should first test
| it, improve it, and then we can benchmark it.
|
| I find the idea interesting. Could be cached for all pages, or
| handled by the browser. It would be massively interesting in
| gaming and streaming, helping also support old devices better.
| Telemakhos wrote:
| Why not always send the smaller, simpler version, if it is
| functionally equivalent to the one with extra javascript and
| bigger images? Surely that would be simpler and save even more
| energy.
| jwells89 wrote:
| My thoughts exactly. Maybe add a button that can load the
| "HD" version of a site if the user actually wants it, but I
| suspect for many types of sites and many users it really
| doesn't matter.
| EdJiang wrote:
| I'm in CA and got the same notice. But I checked the grid
| intensity and it's emitting 146g/KWhr.
|
| http://www.caiso.com/TodaysOutlook/Pages/emissions.html
|
| So the data might be wrong as well which may mislead the user.
|
| Tweeted at him here:
| https://x.com/edwardstarcraft/status/1695508531028566090
| [deleted]
| menotyou wrote:
| Would be interesting to research certain other protocols. I
| believe using XML is relevant problem for the climate as the
| ubiquitous XML parsing is notoriously CPU hungry compared to more
| traditional protocols.
| hristov wrote:
| This is completely pointless without considering the power used
| to transmit the data. He has AVIF using about 30% more power than
| Webp, while creating files a little more than half the size of
| webp.
|
| Well one has to consider the power used to transmit the files. If
| I had to guess the power to transmit is much higher than the CPU
| rendering power and one should just optimize for smaller file
| sizes while keeping image quality and rendering time acceptable.
|
| For the usual person to get that file on the internet, one needs
| the processors of about 20 routers/switches and the like to move
| the data back and forth, the data has to go through a couple of
| hundred of kilometers of distance (at least) on fiber optic, the
| signal being generated by power hungry lasers, etc.
| izacus wrote:
| I work on mobile and power use of radios seriously eclipses
| power use of any media decoders later - there's a reason why
| "race to idle" is so important to battery life.
|
| This article is kinda funny and quanit with it's carbon
| calculations while ignoring the biggest difference in power
| use.
| RetroTechie wrote:
| In other words: if data goes over the air, [smallest files]
| practically always wins.
|
| (besides saving recipients' data budgets)
| youngtaff wrote:
| You would also need to consider the power usage to encode the
| images and AVIF can be pretty high there and it's computational
| costs are larger than the other formats
| TacticalCoder wrote:
| Not really because the image is encoded only once and the
| image is typically then served over the Internet a huge
| number of times.
___________________________________________________________________
(page generated 2023-08-26 23:01 UTC)