BPG Image Format (HEVC subset for browsers)

[xooyoozoo]

Website (http://bellard.org/bpg/)

There's a bundled javascript decoder so you can look at examples:


Lena (http://bellard.org/bpg/lena.html)
Alpha content (http://bellard.org/bpg/gallery2.html)
Natural photos (http://bellard.org/bpg/gallery1.html)


Base bitstream is a subset of Main 4:4:4 16 Still Picture, and when present, an alpha plane is simply a separate monochrome bitstream. The key difference is that header syntax is changed to reduce filesize overhead. However, the list (http://bellard.org/bpg/bpg_spec.txt) of allowed coding tools is rather permissive, so almost every present and future HEVC intra-frame should be "remuxable" into this format.

On the site, there are links to the source files and Windows binary. The code by default link to the HM for HEVC encode. You can get it to link to x265, though CQP usage is hardcoded into the glue file, and I'm not sure how developed x265's 12/14-bit and 422/444 code paths are.

Edit: there's a discussion thread for this on HN (https://news.ycombinator.com/item?id=8704629).

[gamebox]

It seems rather powerful (it has a good base technology, anyway), but I can't seem to be able to find the list of command line parameters to test the encoder/decoder myself. :(

Is this a one-man-effort to promote a novel use for HEVC, or is it something being considered as a potential new, worldwide, universal format to replace JPG or co-exist with it (as happened with PNG and GIF before)?

[filler56789]

Thanks for the info *THUMBS UP*

Yes, the thing seems to work :)

And since the application is actually slow, a progress indicator would be nice :p


but I can't seem to be able to find the list of command line parameters to test the encoder/decoder myself.

BPG Image Encoder version 0.9
usage: bpgenc [options] infile.[jpg|png]

Main options:
-h show the full help
-o outfile set output filename (default = out.bpg)
-q qp set quantizer parameter (smaller gives better quality,
range: 0-51, default = 28)
-f cfmt set the preferred chroma format (420, 422, 444,
default=420)
-c color_space set the preferred color space (ycbcr, rgb, ycgco,
default=ycbcr)
-b bit_depth set the bit depth (8 to 12, default = 10)
-lossless enable lossless mode

[easyfab]

Are there others ( hidden) options ?
Because in readme :

x265 is used when the compression level ('-m' option of bpgenc) is < 9

I suppose I must read source code .

[xkinn123]

it would be a great codec this year for sharing secret pictures ;)
i'm surprised with that transparent ability :eek:

[mandarinka]

If anybody is interested in knowing how this compares in lossless mode, I quickly tried compressing some screencaps (mostly old or new animation).

Apparently it beats PNG, but similarly to webp and jpeg-xr, it falls short of jpeg2000 in this usage (lossless, I repeat).



Filesizes for some random images I tried:
(the numbers go like this: (1) PNG level9 through Xnview - (2) BPG via the binary from the original site - (3) Jpeg2000 through Xnview/Lura plugin):
(Here they are in a gallery (http://imgbox.com/g/FMxROgLQOX), refer to picture order to see what results are for which one)


489 KB - 395 KB - 352 KB
2,41 MB - 1,94 MB - 1,85 MB
479 KB - 382 KB - 348 KB
2,28 MB - 1,83 MB - 1,63 MB
943 KB - 705 KB - 734 KB (win for BPG - seems the format favours smooth images... or naughty ones?)

[Bloax]

The program silently dies on indexed PNGs (https://dl.dropboxusercontent.com/u/63152810/64colors.png) and crashes hard on certain JPEG images (https://dl.dropboxusercontent.com/u/63152810/Blessed.jpg) for some reason.

[gamebox]

Quite limited in resolution in my case, too. Won't encode 1920*3206 pixel JPEG. I guess the problem is caused by high RAM requirements for large images, or the reference HEVC encoder itself.

[mandarinka]

Hmm, it seems it does substantially better than J2K in lossless compression of computer screenshots (I tested on a printscreen image of the hacker news thread, 1920x1080), but both are far from competitive with PNG in this case.

JPEG2K: 815 KB
BPG: 331 KB
PNG: 145 KB (still massively better for this usercase).

[Gravitator]

Why such a big difference ? It seems that need to look at working with a bit depth (to save bitrate; use different methods to select more profitable).

[mandarinka]

Large part of the sample image (I already deleted it, but just open the hacker news thread in browser, maximize it, and you have the idea) is just repeat of the same color.

I guess PNG's deflate coding might be more suited to this, whereas HEVC has trouble due to the transforming architecture? (I have no idea if the BPG encoder used the lossless and transform bypass tools of the format properly.)

[LoRd_MuldeR]

Website (http://bellard.org/bpg/)

There's a bundled javascript decoder so you can look at examples:


Lena (http://bellard.org/bpg/lena.html)
Alpha content (http://bellard.org/bpg/gallery2.html)
Natural photos (http://bellard.org/bpg/gallery1.html)


It's not that difficult to beat JPEG nowadays. Did anybody make an in-depth comparison against WebP yet?

[xooyoozoo]

x265 is used when the compression level ('-m' option of bpgenc) is < 9

Oh, maybe the official binary links to both encoders.

It's also weird that the HM is used as the default 'high-quality' option. x265's intra prediction is supposed to be superior to HM by now (https://github.com/strukturag/libde265/wiki/Intra-Prediction-Mode-Algorithm#ssim-quality), and adaptive quant is too good a perceptual-tool to pass up. Perhaps the guy made his judgement before the recent spate of 10bit and 422+ bugfix commits.

Apparently it beats PNG, but similarly to webp and jpeg-xr, it falls short of jpeg2000 in this usage (lossless, I repeat).

HEVC Lossless performance for Intra will be relatively "non-state-of-the-art" until the Screen Content extension and profiles are completed. Most of the new tools there are meant for computer content (where they work REALLY well), but adaptive color transform in particular is extremely useful for lossless photos.

It's not that difficult to beat JPEG nowadays. Did anybody make an in-depth comparison against WebP yet?

The guy referenced Mozilla's study on image codec performance (http://people.mozilla.org/~josh/lossy_compressed_image_study_july_2014/#ms-ssim-data). Assuming that the HEVC intra-test page I linked above still applies, x265 with AQ should do even better here.

[Nintendo Maniac 64]

What I'm interested in is how it compares with Daala currently...

[Tommy Carrot]

It's not that difficult to beat JPEG nowadays. Did anybody make an in-depth comparison against WebP yet?

WebP has the same problem these new image formats have: it's superior at high compression rates, where jpeg starts to fall apart to blocks. But image sizes are no big deal anymore, so nobody uses that high compression on images. At sane compression levels, these new and advanced image formats are not better at all, in fact they look smoother and blurrier than jpeg (partly because jpeg's ringing makes the image look sharper and more detailed, but hey, it looks better). This BPG format is probably the first one that doesn't really have this issue, while being undoubtedly much better at high compression rates.

What I'm interested in is how it compares with Daala currently...

Daala is nowhere near ready for action. It's improving quite rapidly, that's what makes it interesting, but in its current form it's not competitive yet. It has rather noticeable ringing artifacts, and at higher compression rates, chroma artifacts. But i think it has the potential to improve quite a lot in the future, maybe even beyond HEVC.

[mandarinka]

What I'm interested in is how it compares with Daala currently...

One place where the news was discussed had this comparison uploaded:
Bild "1417868877483q5jbq.png" anzeigen. (http://abload.de/image.php?img=1417868877483q5jbq.png)

Looks that at the ridiculously small bitrate used, HEVC currently smokes WEBP as well as current Daala quite handily.

Edit: you can also look at this demo: http://people.xiph.org/~xiphmont/demo/daala/update1-tool2b.shtml and compare x265 to Daala. The encodes probably aren't current though.

[xooyoozoo]

The x265_glue file is easily modified to get more sane x265 settings. Here's a diff (http://pastebin.com/kxjdCNgr) with defaults set to my own tastes.

Edit: Diff changed to version compatible with libbpg 0.9.1. Setting names were also changed, and both deblocking & chroma offsets now also apply to HM encoder.

[Nintendo Maniac 64]

The encodes probably aren't current though.

You can find recent Daala builds here:
https://www.dropbox.com/sh/e1xnuxga4vshbte/AACEE-RGUEcjrHQYqdReMWbka?dl=0

[foxyshadis]

One place where the news was discussed had this comparison uploaded:
Bild "1417868877483q5jbq.png" anzeigen. (http://abload.de/image.php?img=1417868877483q5jbq.png)

Looks that at the ridiculously small bitrate used, HEVC currently smokes WEBP as well as current Daala quite handily.

Edit: you can also look at this demo: http://people.xiph.org/~xiphmont/demo/daala/update1-tool2b.shtml and compare x265 to Daala. The encodes probably aren't current though.

I've tested lots of complex patterned images, and HEVC's (or at least x265's) intra prediction is hands down far better than AVC, VP8, VP9, or Daala. (Never played with VP10 alpha.) It's easily the best in the field today, and other designs have a long way to go to catch up.

For screenshots and the like, always turn --cu-lossless and --tskip on for x265, so that you're not wasting bits fighting the DCT when you don't have to. x265 can already switch DCT on and off adaptively at RDO 3 and up, so even without the screen coding tools it can be a worthy competitor to PNG.

At this point it's kind of pointless to use HM for anything but rExt (12+ bits), now x265 that has full 4:4:4 10-bit support. I like the file format, and the fact that he went to the effort of completely specifying the format using the same semantics as the HEVC spec is a big plus, though "can be supported in hardware" is pretty optimistic.

The only thing missing is basic matrix descriptions, YCbCr is always 601 and RGB just is. You have to include a full ICC profile instead of having a few standards to pick from (601, 709, 2020, sRGB, Adobe RGB, Adobe Wide RGB). That would save a bit of space, so I'll hit him up about it.

Edit: Looks like you can easily compile it without HM support and it'll just use x265 for everything.

[xooyoozoo]

Testing, testing. (http://xooyoozoo.github.io/yolo-octo-bugfixes/)

This is mostly me playing around and trying to graft bpgdec.js and libwebp.js into a copy of xiph.org page linked above. It's a freshman attempt at that (I knew exactly zero html/javascript before this) so expect compatibility errors, especially on mobile.

Note that only Safari can currently decode jpeg2000 images.

[Kurtnoise]

Testing, testing. (http://xooyoozoo.github.io/yolo-octo-bugfixes/)

This is mostly me playing around and trying to graft bpgdec.js and libwebp.js into a copy of xiph.org page linked above. It's a freshman attempt at that (I knew exactly zero html/javascript before this) so expect compatibility errors, especially on mobile.

Note that only Safari can currently decode jpeg2000 images.
Nice work, thank you...

[smok3]

Testing, testing. (http://xooyoozoo.github.io/yolo-octo-bugfixes/)

This is mostly me playing around and trying to graft bpgdec.js and libwebp.js into a copy of xiph.org page linked above. It's a freshman attempt at that (I knew exactly zero html/javascript before this) so expect compatibility errors, especially on mobile.

Note that only Safari can currently decode jpeg2000 images.

Nice work, but not sure how to evaluate this? (jp2k quality-wise fails every time and bpg looks like some sort of high-pass filter), I would almost claim that only original is of "expected" quality for 2014. So maybe original vs hiq bpg makes sense?

[mandarinka]

Testing, testing. (http://xooyoozoo.github.io/yolo-octo-bugfixes/)

This is mostly me playing around and trying to graft bpgdec.js and libwebp.js into a copy of xiph.org page linked above. It's a freshman attempt at that (I knew exactly zero html/javascript before this) so expect compatibility errors, especially on mobile.

Note that only Safari can currently decode jpeg2000 images.

Nice... looking at the Nymph picture and I noticed that webp seems to change color hue, lol... also, taht is a nice test, seeing how the encoders decimate or blur the texture everywhere :)
Edit: the purple cast is also nicely visible on "Hovercraft (no eels)".

P.S. Webp does fairly poorly overal, I have to say. Dumb that they didn't at least upgrade it to VP9, I doubt anybody would have problems with that at this point (since there is zero adoption yet).

[xooyoozoo]

I updated the page so that it's now possible to look at different quality settings. (http://xooyoozoo.github.io/yolo-octo-bugfixes/)

[Edit: JP2K (should) now decode for non-Apple browsers.]

Nice... looking at the Nymph picture and I noticed that webp seems to change color hue, lol... also, taht is a nice test, seeing how the encoders decimate or blur the texture everywhere :)
Edit: the purple cast is also nicely visible on "Hovercraft (no eels)".

Chroma quality seems to be heavily sacrificed as size is lowered. In pictures like the Air Force Academy one, you can see the sky get progressively more purple.

Nice work, but not sure how to evaluate this? (jp2k quality-wise fails every time and bpg looks like some sort of high-pass filter), I would almost claim that only original is of "expected" quality for 2014. So maybe original vs hiq bpg makes sense?

JP2K is definitely surprisingly bad (worse than I remember from last testing Kakadu). I think it's mainly because its standing slipped relatives to (moz)jpeg and WebP, both of which have had a slow and steady stream of improvements.

WebP's encoder also has built-in preprocessing/filtering that's not part of the standard itself, and its decoder has built-in dithering that's also not part of the standard. While I personally think the extra processing is distracting at larger filesizes, it definitely helps WebP punch above its weight at low sizes, and it makes me wish someone had the foresight to bundle libjpeg with a good denoiser for pre-encoding and a good deblocker+ditherer for post-decoding.

[easyfab]

version 0.9.2:

- Fixed encoding of paletted PNG.
- Reduced memory usage in the decoder.
- Added faster 8 bit only Javascript decoder.
- bpgenc: added '-e' option to explicitely select the encoder.
- bpgenc: set default bit depth to 8.
- bpgenc: added lossless support with x265.
- js decoder: handle width and height attributes.

[pieter3d]

BPG can be supported in hardware with standard HEVC decoders and encoders (it uses a subset of the Main 4:4:4 16 Still Picture Profile, Level 8.5).


No one is building HW like this. All the upcoming hardware is Main and Main-10, so 4:2:0 8-bit or 10-bit. Kind of a disingenuous claim that BPG is HW supported.

[mandarinka]

Well, 8bit 4:2:0 is the main usage of JPEG, so for such pictures, it could work.

[phate89]

No one is building HW like this. All the upcoming hardware is Main and Main-10, so 4:2:0 8-bit or 10-bit. Kind of a disingenuous claim that BPG is HW supported.

The majority of photos are 4:2:0 8-bit so a lot of photos will be hardware accelerated

[mandarinka]

The problem I can see though is that video decoders will be limited to 4K resolution at most while photos can often be much bigger today.

[Atak_Snajpera]

The majority of photos are 4:2:0 8-bit so a lot of photos will be hardware accelerated

Majority of .jpg photos (created by cameras) are 4:2:2. Editing software like corel photo-paint does not support 4:2:0 mode while exporting to jpeg.
http://i.cubeupload.com/n8LdBO.png

[Foo2Bar]

I'm not able to download the tar.gz.
The requested URL /bpg/libbpg-0.9.2.tar.gz was not found on this server.

And it would be great if you can mirror (or move) your source to bitbucket or github. :)

[nevcairiel]

The current version as linked from the website is 0.9.3, apparently the previous tar.gz was removed in the update process.

[easyfab]

I updated the page so that it's now possible to look at different quality settings. (http://xooyoozoo.github.io/yolo-octo-bugfixes/)

[Edit: JP2K (should) now decode for non-Apple browsers.]


Nice page.

I would be interested to have the same to compare my local image file.

Is there such a tool with split view ?

[mandarinka]

I think switching back-forth is better way to judge differences, and that is possibel to do in any decent image viewer (XnView for example).

[easyfab]

Yes I also use back-forth ( Xnview or Irfanview ) but for an area comparison this split method ( with mouse mouvement ) from xooyoozoo page is really interesting.

I would like something like this http://exp.martres.me/splitview/ but for image where you can load your own local file.

[xkinn123]

There's hardly difference between BPG and J2K in this photo (http://xooyoozoo.github.io/yolo-octo-bugfixes/#fruits&bpg=l&jp2=l) yet there's a huge difference if we lower the bitrate (http://xooyoozoo.github.io/yolo-octo-bugfixes/#fruits&bpg=t&jp2=t)
and don't tell me if mozjpeg is on final release, because it's so bad.
Anyway, can you add Daala too, easyfab?
I'm curious about their video codec quality compared to x264 and x265

[foxyshadis]

There's hardly difference between BPG and J2K in this photo (http://xooyoozoo.github.io/yolo-octo-bugfixes/#fruits&bpg=l&jp2=l) yet there's a huge difference if we lower the bitrate (http://xooyoozoo.github.io/yolo-octo-bugfixes/#fruits&bpg=t&jp2=t)
and don't tell me if mozjpeg is on final release, because it's so bad.
Anyway, can you add Daala too, easyfab?
I'm curious about their video codec quality compared to x264 and x265

Makes sense; mozjpeg is about getting another 5-10% out of the format, not 100%. J2K could be slightly better than Jasper or Lurawave, but the effort to improve implementations leveled off many years ago.

I'm sure x264 would be nearly identical at high rates, worse at very low rates (where big transforms become more meaningful). I wouldn't be surprised if it was extremely similar to WebP, those blocking patterns are very similar to what I've seen x264 make.

Majority of .jpg photos (created by cameras) are 4:2:2. Editing software like corel photo-paint does not support 4:2:0 mode while exporting to jpeg.
http://i.cubeupload.com/n8LdBO.png

Corel is in rare company. Every other jpeg writer I know either defaults to 4:2:0 or only has it, especially web-based APIs. Photoshop uses 4:2:0 below quality 10, and all the time on save for web.

[mandarinka]

XnView offers 4:4:4, 4:2:2 and 4:2:0, but the last one is default.

[gamebox]

I don't understand something. If HEVC (and H264 before) is developed as the most advanced visual compression and aimed at widest device support, why is it not "diversified" into still-image use as well - by the creators of the standard themselves? They could just define a subset of compression techniques used for that purpose (only intra tools), and (video) decoder chips could (I guess) easily be adapted to still-image use too without any limits on the resolution, as processing speed, decoded image buffer size and data throughput (bitrate) wouldn't be critical there.

MPEG-2 decoding chips easily handled audio (MP3), JPEG files too (it probably used quantization/dct techniques similar to H261/H262). With HEVC it seems the only way to use the technology for still-images on widespread hardware is to create some formal video clip containing all intra frames (as with still-image "galleries" on a DVD), which is an unnecessarily harder and impractical way to do the same thing (that way all the pictures have to be scaled to the same resolution, the maximum resolution is limited (perhaps even the available bitrate/macroblock count), the device needs to have frame-advance commands for the user, etc.).

With BPG and similar efforts it seems to me we just create another "unofficial" format, unsupported, not well known, without hardware support whatsoever, and as such it seems bound to fail right from the start despite all the quality and advancements.

[Atak_Snajpera]

Sorry for being pesimistic but my glass ball tells me that any hevc based formats will end up like jpeg2000. BPG would be very useful in late 90s when I had awesome 56k modem (~5 KiB/s). Now I have 15 mbps connection (~2000 KiB/s) and I really do not care if image weights 200 KiB in old jpeg format or 100 KiB in hevc. Ofcourse video compression is completely different story. We will still need more efficient video encoders.

[Nintendo Maniac 64]

It's like asking the same thing about audio formats and MP3 - even though better things have been made, the incumbent was already "good enough".

So much like Vorbis and AAC, the likes of better lossy image formats will likely be limited to specific niches (Vorbis is used in games, AAC, outside of Apple, is used with video).

[gamebox]

You might be right Atak_Snajpera, but that's a personal level of view. Modern websites, for instance, contain more visual material than ever before and in ever increasing resolutions and sizes. Faster hardware today means it's easier to navigate through large websites, and that means even more material served. Traffic load is probably exponentially larger per user than before, and today more people use internet and on various devices too, so total traffic must be even greater. I wonder how much big sites like Facebook, Google, etc would benefit from newer image technologies serving the same quality with a portion of the bitrate.

When talking about JPEG2000 it's a different story. I've tried it (and many others) myself once I needed to cram lots of large pictures on a single DVD disk, and gave up on it quickly. It simply has severe quality issues (some even when not filesize-constrained) and savings in file size are not as big as you would expect from an advanced format coming after such advancements in technology as we've had in recent decades. BPG (HEVC) on the other hand, does live up to expectations.

Another thing I forgot - HEVC seems to have (postprocessing) tools to (finally) get rid of compression artifacts present in all other older image and video formats. It is really a welcome change to see it in video, and the images would really benefit from it too. If I'm not mistaking, some of those artifacts are present at milder forms even when the file is saved in a very high quality in older formats - and that becomes visible when zooming or printing.

[Atak_Snajpera]

Currently streaming media (youtube,vimeo,soundcloud and so on) generate majority of traffic. JPEG images are not a big problem like in 90s.

[pieter3d]

HEVC seems to have (postprocessing) tools to (finally) get rid of compression artifacts present in all other older image and video formats.

What are you referring to here? Deblocking / SAO? This isn't really post processing, although I guess it ends up being the same thing if you just decode a single still image.

Note that HEVC's deblocker is nearly identical to H.264.

[foxyshadis]

So far not much else has stepped up to replace PNG for lossless & alpha, though. PNG files are not only huge, zlib is very slow to decode and PNG's basic filtering wasn't designed for parallelism; all together, lossless HEVC can actually be faster on large images. WebP wasn't actually designed to improve JPEG, it was more of an engineering project to justify buying On2. If any company other than Google was behind it, it'd have been forgotten after the first press release.

JPEG XR is slowly gaining traction, built into Windows and Flash Player and some editing apps now, and actually supports everything from lossless to fancy colorspaces. We'll see how it evolves. It may not have the extreme compression that HEVC's excellent I-frame format gives, but being a real royalty-free standard is a big advantage.

I don't understand something. If HEVC (and H264 before) is developed as the most advanced visual compression and aimed at widest device support, why is it not "diversified" into still-image use as well - by the creators of the standard themselves? They could just define a subset of compression techniques used for that purpose (only intra tools), and (video) decoder chips could (I guess) easily be adapted to still-image use too without any limits on the resolution, as processing speed, decoded image buffer size and data throughput (bitrate) wouldn't be critical there.

They did, finally. The MP in MPEG is for "Moving pictures;" the video engineers who developed early standards weren't considering their use for anything else, and up until H.264 the I-frame formats were basically JPEG anyway, so there wasn't a point. It wasn't until Google and Microsoft turned the I-frames of their codecs into actual image formats that MPEG & ITU finally started to think about that need. (JPEG XR is from WMV and WebP is from VP8.) HEVC had a "Still Picture" format almost from the beginning thanks to this, but it's relatively limited compared to competing standards like JPEG XR (more like WebP). They punted all the higher-fidelity stuff to the Range Extensions group, which finished its standard this year, adding full fidelity 4:4:4 16-bit in either RGB or YUV.

The Still Image flag doesn't mean anything to the bitstream, it just tells the program not to treat it like a video. (No play buttons or any of that junk.) That doesn't mean hardware gets to ignore size limitations or DPB, but at least it's very relaxed compared to video, and fallback to software is easy.

MPEG-2 decoding chips easily handled audio (MP3), JPEG files too (it probably used quantization/dct techniques similar to H261/H262). With HEVC it seems the only way to use the technology for still-images on widespread hardware is to create some formal video clip containing all intra frames (as with still-image "galleries" on a DVD), which is an unnecessarily harder and impractical way to do the same thing (that way all the pictures have to be scaled to the same resolution, the maximum resolution is limited (perhaps even the available bitrate/macroblock count), the device needs to have frame-advance commands for the user, etc.).

With BPG and similar efforts it seems to me we just create another "unofficial" format, unsupported, not well known, without hardware support whatsoever, and as such it seems bound to fail right from the start despite all the quality and advancements.

Dunno why you'd think that the only way to use HEVC is as a video of intra frames. They'd be used in separate files or in a larger container document just like any other image format. BPG literally is HEVC with a few reversible tweaks to reduce the signalling overhead and add third-party extensibility, so any images saved in a hardware-compatible format will still be hardware-compatible. (Assuming hardware compatibility is a speed win; JPEG isn't accelerated anymore because it decodes too fast on the CPU.)

I think this is more of a "get people talking" format than a real contender, unless some company adopts it and pushes it into international standardization. The patent issues will dog it otherwise, since JPEG, JXR, and PNG are all royalty-free. It's mainly of interest to bandwidth- or size-constrained programs, and the mobile world is still full of that.

[xooyoozoo]

Yes I also use back-forth ( Xnview or Irfanview ) but for an area comparison this split method ( with mouse mouvement ) from xooyoozoo page is really interesting.

I would like something like this http://exp.martres.me/splitview/ but for image where you can load your own local file.

I made an attempt with drag-n-drop (http://xooyoozoo.github.io/half-n-half/). It probably has some problematic corner cases, but at least reloads are easy. :)

[gamebox]

up until H.264 the I-frame formats were basically JPEG anyway
Hm, I thought H263 quantization of MPEG-4 ASP was somehow different than the ones used in previous formats, and that quantization itself was actually responsible for better compression (keeping less space-consuming high contrast/frequency details than MPEG-2, but still more than only the "softest" ones MPEG-1 keeps).

Dunno why you'd think that the only way to use HEVC is as a video of intra frames. They'd be used in separate files or in a larger container document just like any other image format.
That's because I thought there was not going to be Still-image use of HEVC, at least planned by the creators of the standard. Perhaps the thing we need then is the right container format itself and a widely recognized extension - JPEG files have their (recognizable) extension and format, JPEG2000 does too, etc. Perhaps we need something like MKV or PNG here.

any images saved in a hardware-compatible format will still be hardware-compatible.
BPG having H265 quantization is HEVC hardware-compatible, but the container (and file extension) itself has to be supported and handled by the hardware too, right? PNG is a worldwide format, MP4 is an universal container for video, MKV is well-known too and supported likewise, but BPG seems to me like one-man (and novel) effort which will not gain worldwide hardware support (for the time being at least).

As an offtopic, I also hoped company behind (new) WinZIP format would create some worldwide format/extension for "single additionally compressed JPEG", like ZJP or so, so you could view the image directly instead of handling the archive. That would make their compression really usable in everyday life - currently it is only good for creating image archives for rare and "offline" use.

@pieter3d Yes, I'm refering to Deblocking / SAO, but also 4x4 transform from H264 that removes "mosquito" noise.

[foxyshadis]

Hm, I thought H263 quantization of MPEG-4 ASP was somehow different than the ones used in previous formats, and that quantization itself was actually responsible for better compression (keeping less space-consuming high contrast/frequency details than MPEG-2, but still more than only the "softest" ones MPEG-1 keeps).
H.263 quant is just a little better for much lower bitrates, being softer than blockier. But true, MPEG-4p2 did offer very rudimentary block prediction, allowing predicting the block average from the top or left block, instead of just the left block like MPEG-1 & 2, as well as a much less useful first-row AC predictor. Against JPEG, there would only be noticeable gain at very low bitrates (but you could losslessly convert a JPEG to MPEG-4 ASP's I-frame and back, with a few tweaks to the matrix, because it's all frequency domain prediction).

MPEG 4p10's arbitrary spatial prediction were the first that made an appreciable dent in I-frame sizes, which is why they were expanded further for HEVC.

BPG having H265 quantization is HEVC hardware-compatible, but the container (and file extension) itself has to be supported and handled by the hardware too, right? PNG is a worldwide format, MP4 is an universal container for video, MKV is well-known too and supported likewise, but BPG seems to me like one-man (and novel) effort which will not gain worldwide hardware support (for the time being at least).

Players rarely send the container to hardware, they read it, split out the raw video, and upload that. All H.264 hardware I know of works that way. Even if the hardware can read some containers, only the laziest players wouldn't accept anything but hardware-supported containers, because hardware can always accept raw bitstreams. (Though some old chipsets could only read AVI with Divx and MP3.) TVs and set-top boxes that can't be updated blur the line, but that's consumer electronics for you-- the refresh cycle is king.

And don't forget that PNG and MKV started out as one-man hobby projects. Sometimes they catch on, sometimes they don't.

[gamebox]

And don't forget that PNG and MKV started out as one-man hobby projects. Sometimes they catch on, sometimes they don't.
Yes, but I was wondering if there was, for example, something like "MKP" - Matroska Picture container, if we already have MKV for video. I guess hardware support could easily be extended then, as something like that would have that "family of formats" or "sounds familiar" feel to it, and of course be open-source too. Perhaps PNC too (Portable Network Continous-tone image) as a "brother" of PNG?

With BPG (HEVC) for the first time the pictures have that "natural" feel to me. No blocking, no mosquito noise/ringing, no difference between "important" and "less important" parts and details in a picture. Excellent compression is a plus. JPEG-2000 had zones with obviously lowered resolution as a result of wavelet transform, and many "advanced" formats also made distinct visual difference between sharp zones with higher-frequency details and very "softened" ones with low-frequency "background". Sort of like the treatment of information you see in DJVU format - sharp vector-graphic lettering and blurred background. With HEVC loss of details is "gracefull" - affected parts of pictures don't appear blurred or blocky, they seem as they were "simple" and "continuous" to start with. And most of all, HEVC gets rid of "feathery" like look of H264 - that's what I call areas where high and low frequency details mix so H264 uses 4x4 and 16x16 blocks alternatively. You get a sharp edge of something as 4x4 transform always gives you, then just a few pixels away the very same edge gets blurred and dissolved by 16x16 transform, so after applying the deblocking on that the edge it ends up looking like the washed-out material "fleece", also waving left and right and losing shape even if it was actually geometrically precise. That's probably the biggest low-bitrate improvement I noticed in HEVC, and I guess we owe that to SAO.

[easyfab]

I made an attempt with drag-n-drop (http://xooyoozoo.github.io/half-n-half/). It probably has some problematic corner cases, but at least reloads are easy. :)

Thanks xooyoozoo, It work good here and very easily with drag and drop. Also nice to have flip mode and split mode in same tool .
:)