Open oparoz opened 8 years ago
From @jospoortvliet on June 23, 2015 11:50
aw this is really cool ;-)
Except that almost nobody has collections in that format :D . It also remains to be seen how much time the processing takes when you have photowalls with 50 BPG pictures.
I think this would be most useful as a format for thumbnails, but it won't happen before ownCloud uses PHP7 as the minimum version of PHP...
Let's see what the GD team has to say about it :) https://github.com/libgd/libgd/issues/168
From @vi on June 23, 2015 14:40
Can it use the JavaScript version as a fallback when libbpg is not available?
I suppose you're talking about using it for thumbnails in core, but unfortunately, it wouldn't work. The javascript converts BPG files to an HTML5 canvas object. What we need is something which converts PSD, RAW, JPG, etc. to BPG and only ImageMagick can do that today.
I could create an app which would only work with that format, but it would only work with Gallery and would mean having 2 copies of each thumbnail, one in PNG and one in BPG.
So currently, the only thing we can do is show BPG images and let users convert their collections using their favourite tools.
From @vi on June 23, 2015 15:30
I don't want ownCloud to convert pictures, I just want to save storage and traffic by using BPGs which I provide.
Typically middle/low-quality photo in BPG already have size of a thumbnail (50-100 KB), so can be used both as a thumnail and a a full-sized photo (thumbnails being just rescaled on client instead of on server).
bpgdec.js
should provide BPG decoding features to clients that does not have native BPG decoding.
bpgdec.js
can turn <img>
s with bpg to <canvas>
with decoded data on the fly. Can't ownCloud just connect bpgdec.js
and use plain <img>
for bpgdec.js
to decode them?
Since there is not a single browser supporting BGP, the app would need to always decode files. As mentioned in the OP, it would work like for SVGs. We would be sending the raw BPG file and let the browser do the resize, but it would only work in the Gallery app and its slideshow and the resized images would look different since no cropping would take place (unless someone writes a cropping method in JS).
Also, since there is no Javascript source code for the decoder, it might not be possible to integrate it. It's an all-or-nothing approach and we would probably need to manually call the decoder.
I think I've found the source code.
From @vi on June 23, 2015 16:28
Why no JavaScript source code for the decoder? It's probably this: https://github.com/mirrorer/libbpg/blob/master/post.js . It probably requires some Emscripten and friends to complile...
Here is example of using BPGDecoder
from other JavaScript...
Yes, that's the one. There is no need to compile it as it provides a load(url)
method, so the approach is the same as the one used in the SO question. Build the canvas and paste the result on it.
I did some testing and it's a not easy to work with. We would need our own decoders since the methods available are too rigid and since we would need to add our own. Also, it's clear that this can't be used on mobile, so shared albums would be empty... Not a great experience.
I did not enable asset pipe-lining in the tests, so you could probably shave off 4s to the loading time, which means that you get from 1.5s with PNGs to 6s with BPG with a resizing algorithm and that's with only 18 pictures... BUT All the large pictures for the slideshow are already loaded, so we would probably regain the wasted time, but not everybody is using the slideshow and people will probably have a mix of pictures. so, what you save in disk space 36.1MB vs 1.5MB, you pay in waiting time when navigating through albums.
Things to test:
Now that BPG has evolved into a standard we should reconsider this. Struktur has made a library we can use: https://github.com/strukturag/libheif
BPG is different than HEIF, and it is more complex. There is also AVIF, which is a simpler (subset?) version of HEIF, probably less problematic with patents.
BPG, HEIF, and AVIF have little or zero support in browsers. IMHO, broad support is more likely to come to AVIF in the mid-term, but that is not the current situation. I don't think BPG has future (e.g.: probably less than FLIF).
BPG is different than HEIF
Different container, same codec
it is more complex
As far as I understand, bpg container is simpler than HEIF container (which is basically mp4). Features seem to match.
There is also AVIF, which is a simpler (subset?) version of HEIF
AVIF is based on AV1 video codec. I don't think it is subset of HEIF (based on HEVC codec). The main common part is usage of MP4-like container.
probably less problematic with patents
Probably.
I don't think BPG has future
Maybe it is correct, given "future" and "large vendor support" is very correlated. I'm thinking about a tool that losslessly converts bpg files to heic files...
Different container, same codec
Not really. HEIF can contain images and image sequences coded in different formats.
As far as I understand, bpg container is simpler than HEIF container (which is basically mp4). Features seem to match.
Sorry, I wrote the opposite of what I wanted to say, HEIF can be more complex to implement.
AVIF is based on AV1 video codec
I think AVIF files are valid HEIF files that use the AV1 codec. Therefore, the format is based on both HEIF and AV1.
From @oparoz on June 22, 2015 18:22
Introduction
BPG (Better Portable Graphics) is a new image format. Its purpose is to replace the JPEG image format when quality or file size is an issue. Its main advantages are:
Source: http://bellard.org/bpg/
Converters
Plan
After a preliminary analysis, I concluded that it would not be too difficult to add support to ownCloud via the Gallery app, but the use cases are quite limited at the moment, since mobile browsers would not be able to show the images.
image/bpg
to the list of core media types https://github.com/owncloud/core/pull/17206Avenues to explore
Advantages
Caveats
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Copied from original issue: owncloud/gallery#185