Although it doesn't have the weight of support Google can throw behind WebP, BPG produces images of about half the size of WebP’s with the same or better quality (with no artifacts worth noting at less than %20 the file size of JPEG) — while there have been some patent concerns regarding creation of BPG files, there are none with reading them (there are javascript decoders available for it on the Web), and by 2020 the patent holders for HEVC/H.265 will have switched entirely to hardware support making BPG completely free and also the fastest rendering image format available for most devices so it seems the likely way of the future.
So the question is — will YACReader be supporting it in CB* files any time soon?

Image format support is provided by the Qt toolkit. If the toolkit adds support we can add support. You can try to send a feature request to the Qt upstream (see wiki.qt.io/Reporting_Bugs for instructions), maybe they'll add it.

After looking around the QT site … and a little more digging I think the request should be changed a little — not necessarily .BPG support, but rather .HEIC support … they are (for the purposes of comics/comic-readers essentially the same thing (ie. they compress based on the HEVC codec) but HEIC is already a standard (in fact default!) on Apple devices (newer ones anyway, and even many not-so-new) so it’s pretty much guaranteed support (searching for it at QT’s site actually brings up the supported image formats page, but it’s not actually shown on the page — weird) …
 
  Additionally there is FLIF (github.com/spillerrec/qt-flif-plugin) which apparently is already supported — I was aware of it, but really thought it was a bit too obscure and bleeding edge to ask for, however in doing the BPG/HEIC research I’ve found that other Comicviewers have or have stated intentions of supporting it … so … I guess this is a request for that too — and staying ahead of the curve …

Actually it doesn't matter which format - if it's non-standard and we have to go to great lengths to support it it simply isn't worth the trouble. If adding support is trivial we will add it. If it isn't we will only consider it if the format is mission critical. We probably would accept patches though.

As I wrote before, your best call is to ask the Qt guys if they can add support for it.

I've had a second look at FLIF. If you're interested I could adjust our current code for image support so that it gets it's information for supported files from the Qt plugin system. That would enable you to use the qt plugin you've linked to.