6 ms·

The real question is: How large is the file and where can I download it or the script to make it?

BillinghamJ 11y ago
While I'm not exactly sure as to the answer, I have some info which would be helpful towards answering it. The file contains 48,140,288 frames. There are only two colors - white and black. Only the very center of the image (where the number is) needs to be updated for each frame. This area is 400x65 pixels, so up to 26,000 pixels could be updated on each frame, minus the space between the numbers, etc., so I'd guesstimate an average of 10,000 pixels changing each frame. Each of those 10,000 pixels can actually only be one of two values, but each occupies exactly one byte when uncompressed. So uncompressed (which GIFs normally are not), it'd be about 481,402,880,000 bytes (~0.5TB), plus the full first frame. However, GIFs use LZW compression. While I do not know a lot about it, I would guess it would probably do quite well in this case. Perfect 100% compression would mean 1 bit per pixel rather than 8. But let's assume LZW would only manage - say - 2 bits per pixel. That'd quarter the total size, making the total about 120GB. Of course, this all assumes that it is actually a single GIF, which I believe is extraordinarily unlikely. I would expect it's actually rendered on the fly. Edit: I'm also assuming that the overall image is actually 1280x960 as the image in the article suggests.
- ghshephard 11y ago
  I don't know about your compression numbers. I just created a 1000x1000 pixel gif with a number 1 in the middle, and it compressed to 4790 bytes equals 38320 bits. So, 1,000,000 pixels divided by 38320 bits means 26 pixels per bit. https://en.wikipedia.org/wiki/GIF https://en.wikipedia.org/wiki/GIF suggests that long runs of a single color compress rather well.
- StavrosK 11y ago
  Why would perfect compression mean 77.5% reduction? I've seen GIFs compressed 90%+.
- hultner 11y ago
  Considering that the numbers look very pixelated we could probably reproduce the same result with a 7x7 pixel grid for each number (29 pixels for an full 8), after that we could just scale up the image to 1280x960 using a cheap nearest neighbour algorithm. That way we could probably get away with a lot less. Even rendering a full 88,888,888 could be done with 232 pixels then.
- gpvos 11y ago
  Compression can do much better than 1 bit per pixel. As a quick test, I just created a 1000x1000 single-colour GIF, which takes 1735 bytes.
  - BillinghamJ 11y ago
    Indeed, but that is single color. GIFs contain the differences between each frame - not a whole frame each time. I was assuming 10,000 (of the ~1 million total) pixels were actually changing, and must be changed to one of two values - thus "perfect" compression for a single pixel would be 1 bit.
    - gpvos 11y ago
      > "perfect" compression for a single pixel would be 1 bit I still don't see how that is a valid conclusion that follows from what you wrote before it. It is an optimal representation of the data before you would apply any form of compression.
- kalleboo 11y ago
  > Only the very center of the image (where the number is) needs to be updated for each frame For most frames, only the final digit needs to be updated (or the final two digits, etc)
shubhamjain 11y ago
Apparently, if you aim to serve the GIF over the internet, you can absolutely avoid creating the file at all. GIFs don't declare how many frames the file has, so the browser will keep loading GIF frames unless you declare that there are no more frames. People have exploited this to create a hackish one-way websocket [1]. [1]: https://github.com/videlalvaro/gifsockets https://github.com/videlalvaro/gifsockets
- pluma 11y ago
  I'm pretty sure people have exploited this in the 1990s to create a hackish webcam (a camera recording each frame as gif and the server "streaming" the individual gif frames as they come in).
- dag11 11y ago
  You don't have to hack gifs to do this. The ability to indefinitely stream frames of an image (of any format) is part of HTTP. I made a live png view counter for funsies with this idea: http://drewgottlieb.net/2012/07/29/real-time-user-count.html http://drewgottlieb.net/2012/07/29/real-time-user-count.html
ayosec 11y ago
12G, according to a [1]picture in the post 1. http://hyperallergic.com/wp-content/uploads/2015/09/ASLAP-one.jpg http://hyperallergic.com/wp-content/uploads/2015/09/ASLAP-on...

While I'm not exactly sure as to the answer, I have some info which would be helpful towards answering it. The file contains 48,140,288 frames. There are only two colors - white and black. Only the very center of the image (where the number is) needs to be updated for each frame. This area is 400x65 pixels, so up to 26,000 pixels could be updated on each frame, minus the space between the numbers, etc., so I'd guesstimate an average of 10,000 pixels changing each frame. Each of those 10,000 pixels can actually only be one of two values, but each occupies exactly one byte when uncompressed. So uncompressed (which GIFs normally are not), it'd be about 481,402,880,000 bytes (~0.5TB), plus the full first frame. However, GIFs use LZW compression. While I do not know a lot about it, I would guess it would probably do quite well in this case. Perfect 100% compression would mean 1 bit per pixel rather than 8. But let's assume LZW would only manage - say - 2 bits per pixel. That'd quarter the total size, making the total about 120GB. Of course, this all assumes that it is actually a single GIF, which I believe is extraordinarily unlikely. I would expect it's actually rendered on the fly. Edit: I'm also assuming that the overall image is actually 1280x960 as the image in the article suggests.

ghshephard 11y ago
I don't know about your compression numbers. I just created a 1000x1000 pixel gif with a number 1 in the middle, and it compressed to 4790 bytes equals 38320 bits. So, 1,000,000 pixels divided by 38320 bits means 26 pixels per bit. https://en.wikipedia.org/wiki/GIF https://en.wikipedia.org/wiki/GIF suggests that long runs of a single color compress rather well.
StavrosK 11y ago
Why would perfect compression mean 77.5% reduction? I've seen GIFs compressed 90%+.
hultner 11y ago
Considering that the numbers look very pixelated we could probably reproduce the same result with a 7x7 pixel grid for each number (29 pixels for an full 8), after that we could just scale up the image to 1280x960 using a cheap nearest neighbour algorithm. That way we could probably get away with a lot less. Even rendering a full 88,888,888 could be done with 232 pixels then.
gpvos 11y ago
Compression can do much better than 1 bit per pixel. As a quick test, I just created a 1000x1000 single-colour GIF, which takes 1735 bytes.
- BillinghamJ 11y ago
  Indeed, but that is single color. GIFs contain the differences between each frame - not a whole frame each time. I was assuming 10,000 (of the ~1 million total) pixels were actually changing, and must be changed to one of two values - thus "perfect" compression for a single pixel would be 1 bit.
  - gpvos 11y ago
    > "perfect" compression for a single pixel would be 1 bit I still don't see how that is a valid conclusion that follows from what you wrote before it. It is an optimal representation of the data before you would apply any form of compression.
kalleboo 11y ago
> Only the very center of the image (where the number is) needs to be updated for each frame For most frames, only the final digit needs to be updated (or the final two digits, etc)

shubhamjain 11y ago

Apparently, if you aim to serve the GIF over the internet, you can absolutely avoid creating the file at all. GIFs don't declare how many frames the file has, so the browser will keep loading GIF frames unless you declare that there are no more frames. People have exploited this to create a hackish one-way websocket [1]. [1]: https://github.com/videlalvaro/gifsockets https://github.com/videlalvaro/gifsockets

pluma 11y ago
I'm pretty sure people have exploited this in the 1990s to create a hackish webcam (a camera recording each frame as gif and the server "streaming" the individual gif frames as they come in).
dag11 11y ago
You don't have to hack gifs to do this. The ability to indefinitely stream frames of an image (of any format) is part of HTTP. I made a live png view counter for funsies with this idea: http://drewgottlieb.net/2012/07/29/real-time-user-count.html http://drewgottlieb.net/2012/07/29/real-time-user-count.html

ayosec 11y ago

12G, according to a [1]picture in the post 1. http://hyperallergic.com/wp-content/uploads/2015/09/ASLAP-one.jpg http://hyperallergic.com/wp-content/uploads/2015/09/ASLAP-on...