4 ms·

When you usually try to download an image, your browser opens a connection to the server and sends a GET request asking for the image. I'm not a web designer,

by causi 5y ago

When you usually try to download an image, your browser opens a connection to the server and sends a GET request asking for the image. I'm not a web designer, but that seems rather ass-backwards. I'm already looking at the image, therefore the image is already residing either in my cache or in my RAM. Why it is downloaded a second time instead of just being copied onto my drive?

forgotmypw17 5y ago
This used to be common behavior, but changed over time in most browsers. Your guess is as good as mine as to why.
Tuna-Fish 5y ago
Oh no, it's still downloading the one it's displaying on screen. You can even see a spinny thing as the icon of the tab on Chrome. The format allows for showing images when they are partially downloaded, and also allows pushing data that doesn't actually change the image.
- netizen-936824 5y ago
  Okay? So we still seem to have an accurate representation of the image we want. Why can't I just download that and what's the point of the rest of the data. If we already are seeing the image, the rest of the data is pointless no?
  - chii 5y ago
    but the browser doesn't know that the image is already done, and since there's still data coming in, the browser is obliged to continue downloading. you could right click, and copy image, rather than save as. It achieves what you wanted - save a copy of the image.
  - gipp 5y ago
    Certainly so, yes. But your browser doesn't know that.
paavohtl 5y ago
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.
- ghusbands 5y ago
  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 5y ago
    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 5y ago
    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.
- Aerroon 5y ago
  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.
- causi 5y ago
masswerk 5y ago
As far as I remember from a previous project from a few years ago, the browser doesn't include a referrer for the download request, which can be used for a distinction. (You'll have to disable caching and E-Tags for this to work.) However, this is easily defeated by the use of the console: Select the sources tab, locate the image and simply drag-and-drop the image from there, which will use the local cache instance for the source. Works also with this site, at least with Safari.
- Omin 5y ago
  > [...] which will use the local cache instance for the source I don't understand why browsers aren't always doing this. They already have the image, why redownload it?
  - JimDabell 5y ago
    > They already have the image, why redownload it? They don’t already have the image. They have part of the image. Because the connection hasn’t closed, as far as the browser is concerned, it’s still in the process of downloading it.
  - masswerk 5y ago
    I guess, this is for historical reasons. Mind that there is no such thing as a single, cached image. There's the downloaded content, a decoded bitmap derived from this, a buffer for any instance of the image, which may be clipped or distorted (and may have local color management applied, e.g., converted to 8-bit color range). (At least, it used to be that way. I faintly remember that this used to be a 4-step process.) When memory wasn't ample, any of these, but the instance buffer(s), may have been purged, and an instance buffer doesn't represent the original image anymore. So it makes sense to get a new clean image in the original encoding.
stiray 5y ago
I have problem understanding what problem is this solving? When the image is on my screen I can just screenshot it. This is a common problem, using something in insecure environment, thats why companies are going into such extents to encrypt movies on whole train from source to the display and even those are regularly dumped.
- dkersten 5y ago
  And even if they figured out some DRM method to prevent screenshotting/screen recording, I can still point my phone camera at my monitor and capture it that way, if I really want to. There is always a way around whatever they try to do. If I can see it, I can make a copy of it.
  - cesarb 5y ago
    > I can still point my phone camera at my monitor and capture it that way Back in the late 1990s/early 2000s (this was so long ago that I cannot quickly find a reference), there were proposals to require all non-professional audio and video recorders to detect a watermark and disable recording when one was found. Needless to say this was a terrible idea, for several reasons.
  - Aerroon 5y ago
    But because they try the rest of us suffer the consequences of more expensive and slower hardware and all kinds of other problems.
    - dkersten 5y ago
      Yes. DRM always hurts the legitimate users more than the "pirates". Same with disabling right click or otherwise trying to prevent downloading images.
- gipp 5y ago
  It's not "solving" anything, just demonstrating an interesting gimmick
oefrha 5y ago
You can totally "download" the image in your RAM by right clicking / long pressing -> "copy image" or equivalent in most browsers. It's just not going to be a byte by byte identical file, and may be in a different format, e.g. you get a public.tiff on the clipboard when you copy an image from Chrome or Safari on macOS, even if the source image is an image/svg+xml.
- snvzz 5y ago
  That's the first thing I tried, "copy image" then, on gimp, file->create->from clipboard. And it just worked, with no hassle.
folmar 5y ago
> When you usually try to download an image, your browser opens a connection to the server and sends a GET request asking for the image. I can't vouch for chromium-*, but my Firefox does NOT do that. I've just tested it.

by causi 5y ago

forgotmypw17 5y ago

This used to be common behavior, but changed over time in most browsers. Your guess is as good as mine as to why.

Tuna-Fish 5y ago

Oh no, it's still downloading the one it's displaying on screen. You can even see a spinny thing as the icon of the tab on Chrome. The format allows for showing images when they are partially downloaded, and also allows pushing data that doesn't actually change the image.

netizen-936824 5y ago
Okay? So we still seem to have an accurate representation of the image we want. Why can't I just download that and what's the point of the rest of the data. If we already are seeing the image, the rest of the data is pointless no?
- chii 5y ago
  but the browser doesn't know that the image is already done, and since there's still data coming in, the browser is obliged to continue downloading. you could right click, and copy image, rather than save as. It achieves what you wanted - save a copy of the image.
- gipp 5y ago
  Certainly so, yes. But your browser doesn't know that.

paavohtl 5y ago

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.

ghusbands 5y ago
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 5y ago
  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 5y ago
  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.
Aerroon 5y ago
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.
causi 5y ago

masswerk 5y ago

As far as I remember from a previous project from a few years ago, the browser doesn't include a referrer for the download request, which can be used for a distinction. (You'll have to disable caching and E-Tags for this to work.) However, this is easily defeated by the use of the console: Select the sources tab, locate the image and simply drag-and-drop the image from there, which will use the local cache instance for the source. Works also with this site, at least with Safari.

Omin 5y ago
> [...] which will use the local cache instance for the source I don't understand why browsers aren't always doing this. They already have the image, why redownload it?
- JimDabell 5y ago
  > They already have the image, why redownload it? They don’t already have the image. They have part of the image. Because the connection hasn’t closed, as far as the browser is concerned, it’s still in the process of downloading it.
- masswerk 5y ago
  I guess, this is for historical reasons. Mind that there is no such thing as a single, cached image. There's the downloaded content, a decoded bitmap derived from this, a buffer for any instance of the image, which may be clipped or distorted (and may have local color management applied, e.g., converted to 8-bit color range). (At least, it used to be that way. I faintly remember that this used to be a 4-step process.) When memory wasn't ample, any of these, but the instance buffer(s), may have been purged, and an instance buffer doesn't represent the original image anymore. So it makes sense to get a new clean image in the original encoding.

stiray 5y ago

I have problem understanding what problem is this solving? When the image is on my screen I can just screenshot it. This is a common problem, using something in insecure environment, thats why companies are going into such extents to encrypt movies on whole train from source to the display and even those are regularly dumped.

dkersten 5y ago
And even if they figured out some DRM method to prevent screenshotting/screen recording, I can still point my phone camera at my monitor and capture it that way, if I really want to. There is always a way around whatever they try to do. If I can see it, I can make a copy of it.
- cesarb 5y ago
  > I can still point my phone camera at my monitor and capture it that way Back in the late 1990s/early 2000s (this was so long ago that I cannot quickly find a reference), there were proposals to require all non-professional audio and video recorders to detect a watermark and disable recording when one was found. Needless to say this was a terrible idea, for several reasons.
- Aerroon 5y ago
  But because they try the rest of us suffer the consequences of more expensive and slower hardware and all kinds of other problems.
  - dkersten 5y ago
    Yes. DRM always hurts the legitimate users more than the "pirates". Same with disabling right click or otherwise trying to prevent downloading images.
gipp 5y ago
It's not "solving" anything, just demonstrating an interesting gimmick

oefrha 5y ago

You can totally "download" the image in your RAM by right clicking / long pressing -> "copy image" or equivalent in most browsers. It's just not going to be a byte by byte identical file, and may be in a different format, e.g. you get a public.tiff on the clipboard when you copy an image from Chrome or Safari on macOS, even if the source image is an image/svg+xml.

snvzz 5y ago
That's the first thing I tried, "copy image" then, on gimp, file->create->from clipboard. And it just worked, with no hassle.

folmar 5y ago

> When you usually try to download an image, your browser opens a connection to the server and sends a GET request asking for the image. I can't vouch for chromium-*, but my Firefox does NOT do that. I've just tested it.