If you needed this for any page that loaded lots of images, all of the above would significantly increase page-load time, and memory usage. Especially on a mobile browser, it would use more resources (hence more battery), than otherwise. So personally I wouldn't like to see this be the future. Maybe just as a fall back, but detection for that might be a little hard.
Right now, it would appear that the with a hard reload of the demo: http://bellard.org/bpg/lena.html on chromium, the BPG images are initially loaded with the page, then the posts.js file scans through the page's images to find the ones who's src ends in '.bpg', then posts.js re-downloads the same files with ajax, which are then decoded to PNG files rendered in canvas tags with no identifying information.
The extra request to re-download images is unnecessary but easily removed to just process the data loaded with the initial page load.
>> Can CSS reference them without javascript changing the styles?
Not from what I can see. The images are being rendered to canvas elements without any identifying information. The decoder will need to be modified to add identifying id's or classes. This again is an easy fix.
>> Can they be cached locally if downloaded directly?
This is what I perceive to be an issue. Try downloading the image rendered to the 5kb bpg example... The image that is being rendered is a 427.5kb PNG and that's for a 512x512 image size.
PNGs aren't lossy... so any difference in file size is going to be the product of rendering size or how much the bpg compression has simplified the source image. ( I'm guessing the file size follows something like a logarithmic curve where it jumps initially based on rendered image dimensions and then approaches a limit as the compression approaches lossless. )
Because of the rendered out PNGs' large file size, I would expect that if you are rendering out large images or a lot of images, you would definitely use more resources than with comparable quality JPGs regardless of whether you cache the BPGs for rendering and you would indeed experience the drawbacks you mentioned in both memory and page-load time.
That being said, this is a cool idea, an incredible proof of concept and I'm very thankful to Fabrice for putting it out there.
Are you sure you are not inspecting with the cache disabled. If the appropriate cache headers are applied, this shouldn't issue another request.
grabs all image urls of a page
checks which have .bpg extensions
replaces all these .bpg img tags with canvas tags
loads all the images with Ajax and renders them into the canvas tags
Still, to become truly widespread you need to have support in all kinds of software out there, "everything you need is js plugin" is unreasonable optimism in my opinion. And, anyway, decoding using js isn't fast enough to be one and only solution forever, you need to get to have browser and other software support sooner or later, and for that you need 1 standardized format, not "whatever your plugin supports" as thread-starter suggests.
The only problem I see for now is SEO. Ofcourse the title and alt attributes can give some context but the images wont get indexed
Still, it is quite amazing.
This is the software video decoder, by the way: https://github.com/brion/ogv.js
If this is the case, then putting in a hardware decoder would be a needless expense.
I believe that some browsers actually keep in RAM all the images uncompressed, that can acually be the reason that makes the potential for optimizations less obvious.
Very large images are fairly rare on the web. In particular phones don't have giant displays, so it's usually a waste of bandwidth to send a huge picture to a phone as part of a webpage. And, speaking only for mobile Firefox at the time I worked on it, we had lots of bigger problems with large images than decoding speed. For example, Firefox would keep the whole decoded image in memory while it was onscreen, even if it was only displaying only part of the image or only a downsampled version of the image. If it's a giant image, the decoded image could use up a large fraction of the device's memory.
I'm also not aware of any major phones with have GPGPUs -- I'm not an expert in this stuff, but I think you'd need that to get any serious acceleration from JPEG decoding.
the demos reminded me what browsing on dialup was like. in fact dialup was better cause at least the decoding/loading was progressive/incremental, which doesnt seem to be the case here. i assume it's just the way the decoder is implemented?
Not quite production-ready, I think.
Safari/iOS and Chrome/Android worked with no issue. Desktop Firefox also worked.
If only the rightclick menu could be customized by JS. Adding only a limited number of entries to the menu seems like it'd be okay.
Google Animated doodle with JPEG and opacity
http://zoompf.com/blog/2012/04/how-do-google-animated-doodle...
So we don't like HVEC due to patent worries? Fine, we can swap in another format and use the same technique.
We don't have an I-frame format for Daala that's finalized yet? Fine, we can use work-in-progress. The format does not need to be finalized. If you update it, you rebuild your images and bundle a new JavaScript decoder.
The ability to ship media along with a sandboxed, runnable decoder is awesome, and I'm surprised it hasn't caught on until now. I remember Google a while back implemented their own "video" codec in JavaScript using JPEGs and primitive inter-frame processing, exactly because there wasn't a universal video codec format they could use.