Hacker News Reader

Comment by worldofmatthew | Hacker News Reader

1MB per photo is massive. Its easy to compress photos down to 100KB or less.

This is simply false, even if you mean using AVIF.

Here's a test case, using a moderate sized (3000x2000) image. Nothing ridiculously huge or anything, and it's not an especially complex image. I'm linking the best I can do for both JPEG (at 200 KB) and AVIF (at 100 KB). If you can create a passable versions of these images at 100 KB with either codec (or WEBP for that matter), please do show us how.

Original image: https://0x0.st/o9x5.png

JPEG (200 KB): https://0x0.st/o93i.jpg

AVIF (100 KB): https://0x0.st/o9xC.avif

Maybe JPEG XL will get us closer, but not all the way there, that's for sure: https://0x0.st/o9xd.jxl - JPEG XL is intended for high quality images, so it is not optimized for this kind of extremely low bitrate (~0.1 bpp) usage.

I normally deal with 720P images for internet distribution. For 3000x2000 that would be around 230KB to 250KB.

You replied to a thread about a photography website. I don't think 720p images are the norm for that use case.

In any event, I don't think the AVIF result at 250 KB is acceptable for photography either: https://0x0.st/o93a.avif - There's a ton of smearing and blurring that's very obvious when you're viewing the image at full size.

3000x2000 basically means "fullscreen on a retina display @ full resolution". You can only reasonably show one picture like that at a time. So it's completely OK to have the currently displayed picture at that resolution/size.

But all photo should be loaded at a much lower size, initially, and only downloaded at full size the the user puts them in full screen.

I know lazy loading is in vogue, but as a user it only ever seems to create problems for me. I’d much rather the website download all the images ahead of time on page load, so I don’t have to wait for full quality versions each time I full screen a different image.

This is the restaurant equivalent of : "We are at an all you can eat buffet, let me take 10 plates even if I only realistically will eat 4, so that if I want any more I don't have to stand up again".

While the other way (loading each image as you view them, or lazy) is functionally equivalent to waiting in line for each separate dish, which isn't quite so fun.

Maybe gallery sites could consider offering a preference to load all images upfront if you intend to view them all.

A good example would be housing sites, where viewing higher quality photos of each listing is a primary use case.

Downsize the 3000x2000 to the dimensions it will be displayed at and you will be able to go below 100KB.

What if it will be displayed at 3000x2000? I mean that's the whole conversation here, we're talking about images that are the focus point of the page.

Yes, then 100KB is usually not enough.

> JPEG XL is intended for high quality images, so it is not optimized for this kind of extremely low bitrate (~0.1 bpp) usage.

It's better than AVIF at low bitrates. I did a comparison of the latest builds 3 months ago, and was amazed that JPEG XL has more detail than AVIF at 0.05-0.1 bpp (~120KB 1080p). It's a bit subtle, but I could see it. Once browsers ship full support (at least Firefox + Chrome), I'll be on board.

> and was amazed that JPEG XL has more detail than AVIF at 0.05-0.1 bpp (~120KB 1080p)

bpp = bits per pixel, not bytes. At 1080p, "0.05-0.1 bpp" is 13-26 KB. Much smaller than what you were testing. Might want to recheck your sizes, if you are actually looking at 0.5 bpp it would not surprise me at all that you found JPEG XL superior.

At very small sizes like 0.1 bpp the results are debatable, but I think AVIF is a pretty clear winner if you aren't too bothered by blurring. Samples at 0.15 bpp:

https://afontenot.github.io/image-formats-comparison/#air-fo...

https://afontenot.github.io/image-formats-comparison/#citroe...

https://afontenot.github.io/image-formats-comparison/#festa-...

In the experimental Document-Policy HTTP header, "bpp" does seem to signify bytes per pixel.

Document-Policy explainer: https://github.com/wicg/document-policy/blob/main/document-p...

I tried it out on my own site, and through trial-and-error I found that Chromium does in fact treat the "max-bpp" Document-Policy directives as bytes-per-pixel.

I could be wrong; my memory has faded. Please correct me if this is the case.

I'm not sure what HTTP headers have to do with anything. Using "bpp" to mean bits per pixel is extremely common in image encoding. See e.g. https://en.wikipedia.org/wiki/Color_depth where an uncompressed image is often 24 bpp (8 bits per channel). It's also common to use bitrate (rather than byterate) in audio encoding, see e.g. https://wiki.hydrogenaud.io/index.php?title=Bitrate

Wat.

1MB per photo is tiny when the photo is the content. You need ~100KB for a high quality 512x512 WebP. AVIF will be slightly better but still doesn’t have universal support.

We’ve had 4K (8MP) screens for a decade now and normal DSLRs shoot 25MP so you can zoom in.

Bandwidth is extremely carbon intensive. Someone viewing a couple of few 25MP images online could use 20g to 100g of CO2 (depending on compression).

Source ?

https://www.emergeinteractive.com/insights/detail/does-irres...

In the US as of 2020, it was 3KG CO2 per GB Data.

I don't agree with the reasoning presented. It takes the estimate for the amount of energy that it takes to run the internet infrastructure and clients (141GW * 8765h in a year = 1235865 GWh), divides it by the amount of data transferred yearly (241 billion GB) and gets to 5.12kWh/GB.

You might argue that if people download more data, more equipment needs to run to enable it, but really all this energy consumption is happening regardless of my PC being idle or saturating its fiber pipes with torrents. If your website weights 14kb, all this same equipment needs to be on for my PC to load it.

The website usage on the client side is more to do with resource usage. Unnecessary usage of Javascript is often what makes websites laggy.

You computer will normally down-clock (you can turn this off in the bios) when under lighter loads.The difference between a JS-free webpage and a bloated web page that uses multiple JavaScript with extra Javascript for ads and tracking could be around 10W/H to 40W/H on Desktops.

I agree with this. I was disagreeing with the statement

> Bandwidth is extremely carbon intensive.

and the reasoning that supports that statement.

If people used less bandwidth, less new equipment would be bought to serve the increasing demand. Less bandwidth = Less carbon.

Maybe, or maybe the new equipment is much more efficient than the one it's replacing. It sounds true, but you can't really tell if it is or not, and really my annoyance is in saying it costs any estimated amount of energy, or carbon, to transfer 1GB of data. It does not, the transfer itself is basically cost-less. What costs money is running the infrastructure that makes it possible, and that's much harder to measure.

What matters is the marginal consumption. It should be really small. Averages don't mean much. I can download one GB of Data for almost free, I doubt I would burn 3 kg of CO2 doing that

And how much carbon would they use having those photos printed out and mailed to them to look at?

Given that they could be streaming 1080p video instead, I think viewing a few photos is a relatively harmless hobby

Physical item that can be looked out for 20 to 50 years vs a digital image. Not the same thing.

And who pays for that?

We create 40kg of CO2 a day each through our diet, transport, consumption and other energy use. The idea we need to target our energy burden on Internet routers is absurd.

14 tons per year is pretty high. Most calculators estimate my usage at 6 tons per year.

The US average is 15 metric tons and that's production-based, ie counting exports and not counting imports. If you count imports and stop counting exports it would be higher. Now the US does rank highly in this measure but that's also where the 'typical' HN reader is. The typical reader is also well off which can make a huge difference(flights etc).

I lament the day this becomes policy to regulate average internet usage due to a few religious fanatics who fail to understand that higher levels of CO2 enrich the Earth, and that science has been sabotaged to suit political ambitions fueled by fear porn.

The bandwidth used for single images is dwarfed... massively by streaming video content... I don't think it's a use case that is worthy of excessive time/effort to optimize for size because of bandwidth cost/effects.

edit: I'm not saying don't do it if you can get away with a smaller image dimension, or do basic optimizations... but if your concern is the environmental impact from a simgle high-resolution image from a photography site, you're putting the emphasis in the wrong place.

If it’s an illustrative photo for an article, sure.

If it’s a gallery photo for a site promoting a photographers skill or library, nah…

Its best to have a compressed low res thumbnail that you can click to open the full resolution file in another tab imo

That 1MB is the full resolution image you open in another tab.

In that case, it shouldn't be counted into the webpage weight.

Wondering how. The banner image won't be displayed by Facebook or Twitter unless it's 1200x650 in size.

I done photos larger than that at closer to 50KB with AVIF. 100KB with JPEG should be doable.

Webp could be worth trying. Stripping metadata also. If staying with jpg - Jpgoptim could help.

Reply on news.ycombinator.com