my kinda hackin'
so much creative potential ...
Regressive JPEGs
41–50 of 72 posts
Re: Regressive JPEGs
#42Now 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.
Re: Regressive JPEGs
#43I 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
Re: Regressive JPEGs
#44Adjacent 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 doin…
>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
Re: Regressive JPEGs
#45I 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.
Interesting that people are making hacks of PNG to do animations, yet there's also APNG sitting over there saying "Hey I exist!"
Re: Regressive JPEGs
#46I 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.
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.
Re: Regressive JPEGs
#47> “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
Re: Regressive JPEGs
#48I 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.
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.
Re: Regressive JPEGs
#49Adjacent 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 doin…
>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 sti…
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).
Re: Regressive JPEGs
#50Earlier quoted context omitted.
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.