[paavohtl]

I don't know about browser internals, but I would guess that the browser decodes the image once into a format that can be shown on the page (so from PNG/JPG/WEBP into a RGBA buffer) and then discards the original file. This saves a bit of memory in 99.99% of cases when the image is not immediately saved afterwards.

[mkl]

More likely the original file is saved in the browser cache. That's why it loads faster when you reload the page, and slower when you do a full reload by holding down shift. In Firefox you can see the files with about:cache, and find them in ~/.cache/mozilla/firefox/e1wkkyx3.default/cache2/entries/ or similar (they have weird names with no extension, but the file command will identify them, in their original format). In Chrome they're packed into files with metadata like the URL at the start. You can extract the original file by looking at a file in the cache folder [1] and snipping the header off (you can guess where it is by looking at the file contents with xxd or a hex editor).

More info (and link to a Windows viewer tool) here: https://stackoverflow.com/questions/6133490/how-can-i-read-c...

[1] For me on Linux, Chrome's is ~/.cache/google-chrome/Default/Cache/

[causi]

Interesting if that is the explanation. I wonder if any browsers offer a "privacy mode" where the original images are saved, thereby preventing the server from knowing which specific images you chose to save and were therefore interested in. I wonder how often that information is logged, and whether those logs, if they exist, have ever been put to a purpose such as in a court case.

[Aerroon]

I'm pretty sure it only discards the original after x number of other (new) images have been decoded. (Or perhaps it's memory footprint based?)

I ran into a Chrome performance bug years ago with animations, because the animation had more frames than the decoded cache size. Everything ground to a halt on the machine when it happened. Meanwhile older unoptimized browsers ran it just fine.

[ghusbands]

One cool related thing is that (I believe) modern graphics cards (even Intel) can store and use JPG blocks directly from GPU memory, so it's not necessarily beneficial in the long term to convert to RGBA in advance. Though I think no modern browser actually does this, especially given how power-cheap decoding jpeg (with SIMD) already is and how likely it is that gpu bugs would interfere.

[plekter]

I don't think they can use jpg directly, that would be a waste of transistors given that the graphics world use other compression formats like etc1, bc, astc and so on.

It is however perfectly possible to decode blocks of JPG on a GPU by using shader code.

[wiml]

I'm pretty sure that Safari (and probably most browsers) on MacOS renders JPEGs via CoreImage, and I have seen hints that CoreImage has various GPU-accelerated pathways, though I don't know whether those include DCT or JFIF on the GPU.