> 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.
> “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?
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
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.
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.
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.
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.
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.
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.
And I did something similar to steam live video via an infinite gif: https://github.com/jbochi/gifstreaming#live-video-streaming-...
> “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?
That is 1. Cursed, and 2. Definitely in the right place here.
This is the stuff that I come here for.
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.
I can't see any way this would beat regular steganography.
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 :)
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 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.
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 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
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.
insanity of content aside, that's a really nice website. Kudos.
If the online porn industry hasn't used it, it's probably worthless. Still funny, though.
Safari just freezes in place until the image is entirely finished downloading.
Works fine for me on iOS
hmm interesting
My jaw dropped. Very cool. Thanks for sharing.
Thanks for sharing