3 ms·

Looking at the examples http://xooyoozoo.github.io/yolo-octo-bugfixes/#zoo-bird-head&jpg=l&bpg=l http://xooyoozoo.github.io/yolo-octo-bugfixes/#zoo-bird-head...

Looking at the examples http://xooyoozoo.github.io/yolo-octo-bugfixes/#zoo-bird-head&jpg=l&bpg=l http://xooyoozoo.github.io/yolo-octo-bugfixes/#zoo-bird-head... Comparing large size to large size, the difference in resolution (to me) seems minor. The difference in filesize is 2kb, but it takes 56kb javascript to add browser support. Can somebody explain what I'm not understanding about the benefits here?

bgirard 8y ago
You'd only ship the library to polyfill for legacy browsers that don't support the format and don't have more efficient native decoders. This is an alternative to having an image pipeline where you encode your images in multiple format or if you have sufficient images to make up the 56kb initial download and are willing to comprise on the initial load. It's also a good way to start deploying the technologies before it receives full adoption.
Buge 8y ago
On that same (zoo bird) example, set them both to medium, and BPG looks much better to me, the crown feathers are smooth and clean, and the background is a pleasant gradient, while in JPG it is horribly blocky. Even bumping BPG down to small still seems better than JPG's medium. I think the hope is that soon browsers will implement BPG themselves, so no javascript will be required.
zokier 8y ago
Compare JPEG medium against BGP small and it makes more sense. BGP looks better while being 40% smaller
manigandham 8y ago
Try small vs small on any of the images and it's a vast difference in quality, especially with any backgrounds or gradients.
Fnoord 8y ago
If you go to [1] you get a random picture from the list. The RNG overlords gave me Pont de Quebec at Night. My first focus point was the light on the right bottom side. My second focus point was the details of the bridge where it blends with the sky. My third focus point was the sun. My fourth focus point was the rest of the framework I missed in ref point two. Medium vs medium BPG is slightly bigger. We're talking about < 1 kB here. Small vs small JPG is slightly bigger. We're once again talking about < 1 kB here. Such differences are irrelevant over 2G even, so I'm cool with them. The quality however, on these 3 focus points, is night and day. As soon as you get JPG to small or tiny, you see block artifacts. BPG not. From this sample, I'd say that JPG medium =~ BPG small and JPG small =~ BPG tiny. So, based on that example, BPG delivers a better quality or a better compression depending on your viewpoint/interests. Also, browser support is just a temporary bloat issue. But yeah, we'll see which standard takes over from JPEG... there are so many, right? Plus, hardware will have to start supporting that standard as well. Look at how difficult microUSB and 3.5 mm are to replace. [1] https://xooyoozoo.github.io/yolo-octo-bugfixes/ https://xooyoozoo.github.io/yolo-octo-bugfixes/ [2] https://xooyoozoo.github.io/yolo-octo-bugfixes/#pont-de-quebec-at-night&jpg=s&bpg=s https://xooyoozoo.github.io/yolo-octo-bugfixes/#pont-de-queb...

bgirard 8y ago

You'd only ship the library to polyfill for legacy browsers that don't support the format and don't have more efficient native decoders. This is an alternative to having an image pipeline where you encode your images in multiple format or if you have sufficient images to make up the 56kb initial download and are willing to comprise on the initial load. It's also a good way to start deploying the technologies before it receives full adoption.

Buge 8y ago

On that same (zoo bird) example, set them both to medium, and BPG looks much better to me, the crown feathers are smooth and clean, and the background is a pleasant gradient, while in JPG it is horribly blocky. Even bumping BPG down to small still seems better than JPG's medium. I think the hope is that soon browsers will implement BPG themselves, so no javascript will be required.

zokier 8y ago

Compare JPEG medium against BGP small and it makes more sense. BGP looks better while being 40% smaller

manigandham 8y ago

Try small vs small on any of the images and it's a vast difference in quality, especially with any backgrounds or gradients.

Fnoord 8y ago

If you go to [1] you get a random picture from the list. The RNG overlords gave me Pont de Quebec at Night. My first focus point was the light on the right bottom side. My second focus point was the details of the bridge where it blends with the sky. My third focus point was the sun. My fourth focus point was the rest of the framework I missed in ref point two. Medium vs medium BPG is slightly bigger. We're talking about < 1 kB here. Small vs small JPG is slightly bigger. We're once again talking about < 1 kB here. Such differences are irrelevant over 2G even, so I'm cool with them. The quality however, on these 3 focus points, is night and day. As soon as you get JPG to small or tiny, you see block artifacts. BPG not. From this sample, I'd say that JPG medium =~ BPG small and JPG small =~ BPG tiny. So, based on that example, BPG delivers a better quality or a better compression depending on your viewpoint/interests. Also, browser support is just a temporary bloat issue. But yeah, we'll see which standard takes over from JPEG... there are so many, right? Plus, hardware will have to start supporting that standard as well. Look at how difficult microUSB and 3.5 mm are to replace. [1] https://xooyoozoo.github.io/yolo-octo-bugfixes/ https://xooyoozoo.github.io/yolo-octo-bugfixes/ [2] https://xooyoozoo.github.io/yolo-octo-bugfixes/#pont-de-quebec-at-night&jpg=s&bpg=s https://xooyoozoo.github.io/yolo-octo-bugfixes/#pont-de-queb...