> so playback is entirely dependent on network delay
Ultimately true, but I set up my server to send each "frame" separately, with a fixed delay between each. Each frame is small so unless your network is unusually slow, the timing is set by my server.
If you have control over the HTTP server, a different technique is to set "refresh" in the response header[1], which makes the client fetch new animation frames periodically. This is the technique used in a 2013 IOCCC entry to show a continuously updated clock that's rendered as PNG[2].
I've been here screaming "Motion JPEG EXISTS and is well supported in browsers" the entire time those gif hacks were popular. I've built a bunch of cool stuff with it.
I did this once, 20 years ago, with an animated GIF to add a live streaming air quality layer to a map application at work. The image itself was rendered using Java2D. I had a version I was working on that used JOGL to make gradient blobs instead of point clouds, but I couldn't get the server admin to install the OpenGL driver to get it to work.
Weekend HN is definitely where the more interesting and offbeat content lives, and I often find myself enjoying it significantly more as a result.
During the week, well, it would be unfair to call it LinkedInified, but it can often feel like a somewhat higher tier of that sort of strata. Plenty of good stuff in there still, but much more “serious business”.
I wonder if and how you can use this for steganography, hiding data in plain sight. I bet most automated image analysis programs would only consider the final image. I sure some highschooler can use this to bypass their schools contentfilter
You could probably implement a server that is purposefully slow enough so that the human frame shows up for however long you want. Just need to send the keepalive bytes one-by one.
> “Besides unconventional rickrolls and other trolling, this has no practical applications: there's no way to add timing information, so playback is entirely dependent on network delay.”
A progress bar for something that’s loading in parallel over the same network, to give the user an idea of how much the delay is?
If i remember correctly, some other places of the internet (4chan) completely this sort of behavior because people use it to hide images of ...unsavory topics
Nice! I think you can approximate timing somewhat, by making your web server create the "jpeg" on the fly and send it to the client in timed chunks. The source could even be a webcam, so the "jpeg" would go on forever.
You can do this with the gif too, I have once created a toy cgi that combined a gif sending one frame at a time with an image map allowing you to Remote Desktop with no JavaScript and click around. JPEG may have been a better choice, maybe I’ll revisit this.
Works fine for me in desktop Firefox. But on mobile iOS the “whole video within a jpeg” is 3 frames, all of which are nearly entirely solid color brown->orange->red with a vague cat silhouette. The color changes each frame, so you can tell it’s “working” but it’s certainly not what I’d call a video.
I was surprised when I pulled it up on my desktop and it did actually play like a video. Wonder if it’s causing some weird iOS image decoding glitch/edge case.
Adjacent advice:
I've recently played with opengl and jpeg turbo and I wanted to display images fast. I don't remember exact numbers, but enabling progressive for a jpeg was a significant slowdown for decoding.
So if anyone like me is stuck with the old school advice that progressive is an nice to have, it's likely not. I personally don't remember any visual progressive image buildup in like decades, so it's not doing anything valuable at all.
>I personally don't remember any visual progressive image buildup in like decades, so it's not doing anything valuable at all.
Maybe you just don't notice? It can be pretty invisible sometimes. I sometimes notice that image soon after page load an image is slightly blurry, and then another pass "sharpens" it. Yeah it's not like in the "old times" when the first progressive level was almost unreadable, but there's still value in sending a lower resolution version of image in 30% of the total file-size, basically for free
I haven't been able to see it even setting Chrome developer tools to crazy slow network speeds. Maybe chrome developer tools simulation isn't enough to see it?
The observations you are reporting are from images you created yourself and you know are in fact progressive jpegs? (not "regressive", although that's funny). There are of course other techniques to start with a lower resolution image that do "work" (in the sense of actually displaying a lower resolution image first at least).
I deliberately was talking about decode speed. The question is if you serve even via moderately fast infra, does it display faster? In my case on a (indeed fast) local system absolutely not. Mere size can be a decode problem of course. But it's extremely hard to tell that a single digit percent size difference is an advantage for serving.
But if better compression for storage or you can verify progressive serves faster then it is of course a benefit.
I guess the point I am making is that most people think: I heard it's somehow better so lets use it.
Progressive decoding isn't expected to speed up decoding, it's expected to speed up displaying large image files, especially for downloads via slow mobile connections.
I've started using computers in the 90s, I've seen this every day back then.
Still the question is, does it help? Trying to access an average web app will probably take minutes before the browser may even see an image. If you do everything possible to render reasonably fast on very slow speeds, then progressive is nice. On a fast connection I don't think the average user will notice the difference.
Where it helps is in finding out if it's even the image you wanted. You get a sense of it from the fast first pass, and then can hit back if it's not the thing you thought it was.
Excellent hack! Should definitely be possible to make an animated gif to jpeg converter. I guess the animation could be slowed a little by repeating frames.
Wow, Firefox never fully loads the page, while WebKit fails to load it altogether, instead it displays "Operation was cancelled" in system font after a short freeze. I didn't manage to see the images change in any way as the post would suggest though, which left me confused.
Now you just have to mod your webserver to send the image chunk by chunk (with waits in-between). That way network latency does not matter. Also it probably reduces artefacts as bytes from one frame most likely are received in one network packet.
The format supports progressive decoding but IIRC none of the current browser implementations support it. The first Chrome and Firefox implementations did, and I think it's on their roadmap for the new Rust implementation. No idea about WebKit/Safari.
Edit: the format also supports region-of-interest decoding and I suspect you can make some cool maps or fractal images with both features. But I think they're not quite prioritizing implementing that right now.
> The first Chrome and Firefox implementations did
I was about to say: I'm sure I've seen it work a t some point? I imagine it's a valuable thing to add for the web though. It would be really cool if you could use the same image source for thumbnail and full image, and the browser both just figures out how much to download based on pixel size and can resume previously partially downloaded images.
And yeah, the tiling isn't implemented anywhere yet, jxl doesn't really get enough funding for that. But it'll be really cool once it does since it also makes it really useful for giant images of geographic data. I don't know if it combines with streaming downloads as well, but it would be crazy cool if we effectively got OpenSeaDragon[0] support inside an image format
I love the first JPEG where the final image is... a different picture of the cat. "The first images you see are just approximations to the final, exact version." Audience's heads nod in understanding
I did something very similar with progressive (adam7 interlaced) PNG: https://www.da.vidbuchanan.co.uk/adamation/image.png
> so playback is entirely dependent on network delay
Ultimately true, but I set up my server to send each "frame" separately, with a fixed delay between each. Each frame is small so unless your network is unusually slow, the timing is set by my server.
If you have control over the HTTP server, a different technique is to set "refresh" in the response header[1], which makes the client fetch new animation frames periodically. This is the technique used in a 2013 IOCCC entry to show a continuously updated clock that's rendered as PNG[2].
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
[2] https://www.ioccc.org/2013/mills/index.html
The "Refresh" header is encoded backwards on this line:
https://github.com/ioccc-src/winner/blob/619f554bbdb19e5003a...
And I did something similar to steam live video via an infinite gif: https://github.com/jbochi/gifstreaming#live-video-streaming-...
Interesting that people are making hacks of PNG to do animations, yet there's also APNG sitting over there saying "Hey I exist!"
You don't even need a hack, there's built-in support for this.
https://en.wikipedia.org/wiki/Motion_JPEG
I've been here screaming "Motion JPEG EXISTS and is well supported in browsers" the entire time those gif hacks were popular. I've built a bunch of cool stuff with it.
https://github.com/donatj/mjpeg-php/blob/master/mjpeg.php
https://github.com/donatj/imgboard/blob/master/main.go
The PHP example here is an illustration of how easy it is to pull off, and the Go example is part of a JavaScript-free multiuser drawing board.
Sure, but most sites strip the animation out of APNGs while still allowing GIFs, which is frustrating.
We even have proper video codecs like h264!
I did this once, 20 years ago, with an animated GIF to add a live streaming air quality layer to a map application at work. The image itself was rendered using Java2D. I had a version I was working on that used JOGL to make gradient blobs instead of point clouds, but I couldn't get the server admin to install the OpenGL driver to get it to work.
That is 1. Cursed, and 2. Definitely in the right place here.
Meanwhile the big techs:
"Hmm how can we use this for fingerprinting"
This is the stuff that I come here for.
Weekend HN is definitely where the more interesting and offbeat content lives, and I often find myself enjoying it significantly more as a result.
During the week, well, it would be unfair to call it LinkedInified, but it can often feel like a somewhat higher tier of that sort of strata. Plenty of good stuff in there still, but much more “serious business”.
Me too, thanks for reminding me of that
I wonder if and how you can use this for steganography, hiding data in plain sight. I bet most automated image analysis programs would only consider the final image. I sure some highschooler can use this to bypass their schools contentfilter
Yep this is an AI subversion technique for sure. Put the message to the humans in the first frame, and the message to the AI in the final frame.
This is how we defeat skynet: by sending each other pictures of cats.
You could probably implement a server that is purposefully slow enough so that the human frame shows up for however long you want. Just need to send the keepalive bytes one-by one.
I can't see any way this would beat regular steganography.
> “Besides unconventional rickrolls and other trolling, this has no practical applications: there's no way to add timing information, so playback is entirely dependent on network delay.”
A progress bar for something that’s loading in parallel over the same network, to give the user an idea of how much the delay is?
If i remember correctly, some other places of the internet (4chan) completely this sort of behavior because people use it to hide images of ...unsavory topics
I think you dropped a word.
It's an onomatopoeia
You mean an onomatope (to be pendantic)? In any case, it's not clear to me exactly what you mean.
Someone accidentally the whole thing.
Apparently "onomatope" is a much less popular name for the same thing (e.g. Wikipedia uses my version).
I mean that the "remove a word" 'symbol' is a 'word' that represents the verb he was trying to invoke, by sounding like it.
Birds chirp, bees buzz, moderators, toilets flush.
Apologies if I'm being totally thick, but you're saying the lack of a word is acting as an onomatope (or an onomatopoeia if you prefer)?
Nice! I think you can approximate timing somewhat, by making your web server create the "jpeg" on the fly and send it to the client in timed chunks. The source could even be a webcam, so the "jpeg" would go on forever.
There are already webcams which do this- but they use a mime trick for 'multipart/x-mixed-replace'.
That's basically the server telling the client 'That data I just sent you, well now replace it with this new thing'.
No JavaScript needed, and can work with plain http and jpeg
A lot of IP cameras already do this via https://en.wikipedia.org/wiki/Motion_JPEG
You can do this with the gif too, I have once created a toy cgi that combined a gif sending one frame at a time with an image map allowing you to Remote Desktop with no JavaScript and click around. JPEG may have been a better choice, maybe I’ll revisit this.
> so playback is entirely dependent on network delay
You can use Service Worker to emulate a slow connection :)
Weird that it’s inconsistent
Works fine for me in desktop Firefox. But on mobile iOS the “whole video within a jpeg” is 3 frames, all of which are nearly entirely solid color brown->orange->red with a vague cat silhouette. The color changes each frame, so you can tell it’s “working” but it’s certainly not what I’d call a video.
I was surprised when I pulled it up on my desktop and it did actually play like a video. Wonder if it’s causing some weird iOS image decoding glitch/edge case.
Adjacent advice: I've recently played with opengl and jpeg turbo and I wanted to display images fast. I don't remember exact numbers, but enabling progressive for a jpeg was a significant slowdown for decoding. So if anyone like me is stuck with the old school advice that progressive is an nice to have, it's likely not. I personally don't remember any visual progressive image buildup in like decades, so it's not doing anything valuable at all.
>I personally don't remember any visual progressive image buildup in like decades, so it's not doing anything valuable at all.
Maybe you just don't notice? It can be pretty invisible sometimes. I sometimes notice that image soon after page load an image is slightly blurry, and then another pass "sharpens" it. Yeah it's not like in the "old times" when the first progressive level was almost unreadable, but there's still value in sending a lower resolution version of image in 30% of the total file-size, basically for free
I haven't been able to see it even setting Chrome developer tools to crazy slow network speeds. Maybe chrome developer tools simulation isn't enough to see it?
The observations you are reporting are from images you created yourself and you know are in fact progressive jpegs? (not "regressive", although that's funny). There are of course other techniques to start with a lower resolution image that do "work" (in the sense of actually displaying a lower resolution image first at least).
I use cjpegli as encoder and it compresses best with its default progressive and full 4:4:4 approach, so it's not only a nice to have feature.
I deliberately was talking about decode speed. The question is if you serve even via moderately fast infra, does it display faster? In my case on a (indeed fast) local system absolutely not. Mere size can be a decode problem of course. But it's extremely hard to tell that a single digit percent size difference is an advantage for serving.
But if better compression for storage or you can verify progressive serves faster then it is of course a benefit.
I guess the point I am making is that most people think: I heard it's somehow better so lets use it.
Is you have a normal CPU then does decode speed matter?
But a lot of people do have slow connections sometimes.
JPEG photos stored as progressive usually take ~5% less space so there is value.
And it is possible to losslessly transcode JPEG to progressive.
Lossless transcoding to JPEG XL gives even more space savings though.
Progressive decoding isn't expected to speed up decoding, it's expected to speed up displaying large image files, especially for downloads via slow mobile connections.
Example: https://youtube.com/watch?v=UphN1_7nP8U
I've started using computers in the 90s, I've seen this every day back then.
Still the question is, does it help? Trying to access an average web app will probably take minutes before the browser may even see an image. If you do everything possible to render reasonably fast on very slow speeds, then progressive is nice. On a fast connection I don't think the average user will notice the difference.
Where it helps is in finding out if it's even the image you wanted. You get a sense of it from the fast first pass, and then can hit back if it's not the thing you thought it was.
I tried to think about difficult ways to compute the high frequency coefficients to work from the "wrong" coefficients of the first image...
But this is clever - just smash them together. Low frequency of one image concatenated with high frequency from another. This works surprisingly well!
Excellent hack! Should definitely be possible to make an animated gif to jpeg converter. I guess the animation could be slowed a little by repeating frames.
You can also deliberately have the server sending data at the right rate for the right playback time.
Easy enough to add a delay() each frame if your server is python/nodejs/PHP/whatever
Is it possible to acquire lower frequency components with a camera too?
This also reminded me of MRI where low frequency is acquired first in a space called k-space
Wow, Firefox never fully loads the page, while WebKit fails to load it altogether, instead it displays "Operation was cancelled" in system font after a short freeze. I didn't manage to see the images change in any way as the post would suggest though, which left me confused.
oh i thought this was going to be a jpeg that loaded the highest-frequency data first and added the lower frequency data later
insanity of content aside, that's a really nice website. Kudos.
Now you just have to mod your webserver to send the image chunk by chunk (with waits in-between). That way network latency does not matter. Also it probably reduces artefacts as bytes from one frame most likely are received in one network packet.
This website appears to be maliciously using IP address blocking. Here is a less-censored link: https://web.archive.org/web/20260718065449/https://maurycyz....
Obviously the demonstrations that rely on server-side timing don't work through archive.org.
I wonder if you can do this in JPEG-XL. I know that that has actual animation support, but this would be a different thing.
The format supports progressive decoding but IIRC none of the current browser implementations support it. The first Chrome and Firefox implementations did, and I think it's on their roadmap for the new Rust implementation. No idea about WebKit/Safari.
Edit: the format also supports region-of-interest decoding and I suspect you can make some cool maps or fractal images with both features. But I think they're not quite prioritizing implementing that right now.
> The first Chrome and Firefox implementations did
I was about to say: I'm sure I've seen it work a t some point? I imagine it's a valuable thing to add for the web though. It would be really cool if you could use the same image source for thumbnail and full image, and the browser both just figures out how much to download based on pixel size and can resume previously partially downloaded images.
And yeah, the tiling isn't implemented anywhere yet, jxl doesn't really get enough funding for that. But it'll be really cool once it does since it also makes it really useful for giant images of geographic data. I don't know if it combines with streaming downloads as well, but it would be crazy cool if we effectively got OpenSeaDragon[0] support inside an image format
[0] https://openseadragon.github.io/
I love the first JPEG where the final image is... a different picture of the cat. "The first images you see are just approximations to the final, exact version." Audience's heads nod in understanding
If the online porn industry hasn't used it, it's probably worthless. Still funny, though.
I like how that website has not just a "Dark" and "Light" mode, but also a monochromatic "TTY" mode.
my kinda hackin' so much creative potential ...
Safari just freezes in place until the image is entirely finished downloading.
Works fine for me on iOS
Your website is inspiring
hmm interesting
Now, stuff like _this_ is why I keep coming back to HN.
Here is another cat https://idiod.video/njz0kx.mp4
My jaw dropped. Very cool. Thanks for sharing.
Thanks for sharing