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 .
:)

[foxyshadis]

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?
I used .mki and .m4i as analogues to .mka and .m4a, but that's just me.

Sort of like the treatment of information you see in DJVU format - sharp vector-graphic lettering and blurred background.

Of topic, but damn, I hate this so much. MrSID seems to be a really terrible encoder; I regularly see text completely blurred out in old maps I request from libraries. Region of interest coding is extremely important, but it seems like a lot of institutions use a perfect/horrible dichotomy instead of gracefully degrading, or at least keeping the background ok instead of horrible, for when it does screw up. Text at 600 DPI and background at 72 or less is just too much.

[ruesberg]

libbpg-0.9.4 is out. Extract of the changelog:

version 0.9.4:

- Modified alpha plane encoding to allow progressive display and
streaming encoding. This change is incompatible, so images
containing alpha from the previous versions of the format cannot be
decoded.

- Added 4:2:2 and 4:2:0 chroma formats with MPEG2 chroma sample position.


http://bellard.org/bpg/libbpg-0.9.4.tar.gz

[Nintendo Maniac 64]

Hey, perfect for comparing to the newest Daala build that just came out today!

A windows binary (https://www.mediafire.com/?4my77zfj4rd1az9) from today...

The changelog available here (https://git.xiph.org/?p=daala.git;a=shortlog).

[djcj]

Static Linux binaries (32 and 64 bit) with x265 support: http://www.mediafire.com/?muwfwcucsglr217
In case someone has trouble compiling them.

[xooyoozoo]

In case this is of use to some, I'll share my personal fork (https://github.com/xooyoozoo/libbpg.git) of libbpg with a few quality-of-life additions to encoding flags.

CRF 18 (as opposed to CQP 18) encode with weaker deblocking, higher quality chroma:
-q 18 -deblocking -2 -chroma_offset -3

Try to produce output within 3% of 200kB using at least 2 and up to 8 total passes:
-s 200 -size_tol 3 -max_passes 8

CRF 18 encode. Use output if <200kB (+ default tolerance), else try up to (default # passes) to get 200kB.
-q 18 -s 200 -size_limit

[easyfab]

Hi xooyoozoo,

Thank you for sharing, I made some little tests.
I build under msys/mingw-w64 x64
I changed makefile with
CONFIG_WIN32=y
CROSS_PREFIX:=x86_64-w64-mingw32-
#USE_JCTVC_HIGH_BIT_DEPTH=y
and removed -fno-asynchronous-unwind-tables from CFLAGS for correct build ( don't know why this cause error with x64 ? it's the same with original 0.9.4 ).

Now for your build I have this with -e JCTVC :
***************************************************************************
** WARNING: Transform skip fast is enabled (which only tests NxN splits),**
** but transform skip log2 max size is not 2 (4x4) **
** It may be better to disable transform skip fast mode **
***************************************************************************
and a corrupt image :
http://i61.tinypic.com/5lct9l.jpg

With my build of original 0.9.4 it's ok.

With -e x265 all is ok but setting quality -q is now difficult/different between JCTVC/X265 ( your change CQP -> CRF ) for example -q 18 for -e JCTVC and original -e x265 give ~340kB with your -e x265 -q 18 ( crf 18 ) ~170kb therefore same as -q 25 for JCTVC
If possible I think it would be better to keep -q -> CQP and create a new option -crf for crf

I will try multipass latter.

[xooyoozoo]

Now for your build I have this with -e JCTVC :
***************************************************************************
** WARNING: Transform skip fast is enabled (which only tests NxN splits),**
** but transform skip log2 max size is not 2 (4x4) **
** It may be better to disable transform skip fast mode **
***************************************************************************
and a corrupt image :


Whoops missed that. Thanks.


With -e x265 all is ok but setting quality -q is now difficult/different between JCTVC/X265 ( your change CQP -> CRF ) for example -q 18 for -e JCTVC and original -e x265 give ~340kB with your -e x265 -q 18 ( crf 18 ) ~170kb therefore same as -q 25 for JCTVC
If possible I think it would be better to keep -q -> CQP and create a new option -crf for crf

I will try multipass latter.

Hmmm I'll look into it.

I don't see CQP as a serious mode because it also turns off CUTree, but the straightforward solution would be to turn off CUTree at 0 aq_strength. That would automatically put x265 into CQP mode. Even then, however, the original settings still relied on magical, arbitrary offsets (which I've removed) to match JCTVC and x265, and there's no reason not to make our own magic with CRF.

Edit:

I was wrong about CUTree being useful. Either it only works in inter prediction, or intra propagation of quality doesn't extend much more than a couple of CUs. Turning CUTree off now means that x265 CRF matches JCTVC QP a bit better, but it's still not 100% equal.

Also, color-x265 + alpha-jctvc is now possible again. JCTVC's alpha qp is now obtained from x265's output's headers when needed.

[xooyoozoo]

I put up a comparison (http://xooyoozoo.github.io/yolo-octo-bugfixes/#psycomp) between default x265-based BPG and the same but with things like Psy-Rd activated. You'd probably prefer pressing Shift to switch between versions.

To my eyes, broadly-textured, "scenic" images like Machu Picchu (http://xooyoozoo.github.io/yolo-octo-bugfixes/#psycomp#machu-picchu), Isle of Skye (http://xooyoozoo.github.io/yolo-octo-bugfixes/#psycomp#isle-of-skye), and Eaglefairy (http://xooyoozoo.github.io/yolo-octo-bugfixes/#psycomp#eaglefairy) benefitted the most. Localized, finely detailed areas are next in line (the statue surface in Nymph (http://xooyoozoo.github.io/yolo-octo-bugfixes/#psycomp#nymph), the girl's outfit in Production (http://xooyoozoo.github.io/yolo-octo-bugfixes/#psycomp#production), the wings in Swallowtail (http://xooyoozoo.github.io/yolo-octo-bugfixes/#psycomp#swallowtail)).

What stops this from being an unmitigated improvement is the occasional artifacts popping up in extremely flat regions (background edges in Fruits (http://xooyoozoo.github.io/yolo-octo-bugfixes/#psycomp#fruits) and Ballet Exercise (http://xooyoozoo.github.io/yolo-octo-bugfixes/#psycomp#ballet-exercise)). I had to lower psyrd slightly because it was even worse before. Psyrdoq seems to cause less issues, at least at low single digits. Meanwhile, deblocking actually barely made a visual quality dent, and chroma qp was only changed to stop haphazard moments of chroma noise with psyrd+psyrodq is on.

[smok3]

xooyoozoo; looking at your example page, to my eyes psy wins with scenic images, portraits are always worse (But this may be a bit over-compressed for that purpose).

p.s. Trying to compile libbpg on osx .... (did it with some help from homebrew to install libjpeg).

edit: testing testing (https://dl.dropboxusercontent.com/u/79532365/tmp/bpg/bpg.htm) here as well on the more CGI type of images. Especially interesting is the 2nd image with its 6.8K size, wow (quality sucks thought).

Problems:
- some/most images have some green line on the left/right border < fixed by using the full version of js decoder
- "quantizer parameter" mode is obviously not the way to use this, if you have slightly/extremely varied image types (yes I need to re-read this thread more carefully).
- interesting stuff happening with seemingly simple rotated dark-grey quads on pixelmoon image (4:4:4 encoded).

Revelations:
- The range of stuff this thing can/will compress well is really breath-taking.

Image License:
- You are allowed to use this images in your own compression tests, keep in mind that: certain logos portrait-ed are probably copyrighted to their respective brands.

Questions:
a. How do I use x265 mode? crf?

[easyfab]

a. How do I use x265 mode? crf?

If you build bpg with libx265, you can use x265 with -e x265
and crf is default with x265 ( xooyoozoo version )

[smok3]

If you build bpg with libx265, you can use x265 with -e x265
and crf is default with x265 ( xooyoozoo version )

I did build it that way (the official and xooyoozoo/s version), now I guess the official version can't use crf or, or ....?

[xooyoozoo]

My libbpg fork still uses JCTVC as the default. x265 can only do either 8bit or 10bit without recompiling, and I'm not sure I completely trust it for 422 & 444. But obviously, my version isn't meant to be official or even remotely static. Options can and will change (though I keep `-h` messages up to date).

In smok3's use-case of 444 artificial content, I think JCTVC's RExt tools are indispensable. Even AQ and psy won't do well against 20%+ compression improvements. :)

some/most images have some green line on the left/right border

The line doesn't appear when using the full-featured JS decoder instead of the 8bit-limited one. My local binary decoder can also decode the images just fine even when high-bit-depth jctvc is disabled, so I'm guessing this is a temporary bug with 8bit-js and some RExt tools.

a. How do I use x265 mode? crf?

`-e x265` in my version will automatically give the equivalent (in x265's cli) of `--CRF # --no-cutree`.

Edit:

The previous bpg-psy comparison page was just normal vs psy at a single size, but here's a version that includes various sizes and the other codecs too (http://xooyoozoo.github.io/yolo-octo-bugfixes/#addpsy).

The only thing to add is that even though I tried scaling psyrd/oq along with size "tier", it's still untenable at Tiny. Small is a bit give and take, but I think Medium is almost completely better. Except for a few situations (the soft background grain in Ballet Exercise (http://xooyoozoo.github.io/yolo-octo-bugfixes/#addpsy#ballet-exercise)), it's hard to see changes at Large.

[smok3]

Still don't get it:

bgpenc -q A -e x265
will become `--CRF A --no-cutree`?

:thanks:

The line doesn't appear when using the full-featured JS decoder instead of the 8bit-limited one.
I see, should be fixed now.

[xooyoozoo]

I wrote about CUtree a few posts up. It wildly affects "expected" filesize (relative to JCTVC) but it didn't measurably change/improve quality, probably because it's meant for multi-frame inter-prediction.

I only noted CUTree just in case you were expecting file size to exactly match the *actual* x265 cli. Sorry if that became confusing. But yes, `-e x265 -q #` will bring in x265's expected CRF mode.

[smok3]

In smok3's use-case of 444 artificial content, I think JCTVC's RExt tools are indispensable.
So a nice try would be 10bpc, 4:4:4 for this type of images? (going for close-to-transparent, but with cool file-size)

The only thing to add is that even though I tried scaling psyrd/oq along with size "tier", it's still untenable at Tiny. Small is a bit give and take, but I think Medium is almost completely better. Except for a few situations (the soft background grain in Ballet Exercise), it's hard to see changes at Large.
Still prefer BPG-medium over even BPG-psy-large, I think it's due to the fact than if the faces look artificial, then the grain/texture on carpet will not matter at all. < just my eyes.

edit:
Another silly try with a goal of near-transparency;
https://dl.dropboxusercontent.com/u/79532365/tmp/bpg444/bpg.htm
(10bpc,4:4:4, starting with quant 10 and max size limit means reducing quant)

Definitely looks better, but filesizes are bloat.

[Milaa]

Hi,

Can anyone share his windows build of BPGenc with x265 encoder support (and/or linux one)?

Thanks in advance,

Milaa

[easyfab]

Here a windows build of xooyoozoo fork with x265 ( x64 version ) : http://sendbox.fr/pro/bvghs4jmqcva/bpg.7z.html
it work here, perhaps this will also work for you.
For testing only

[smok3]

Should this compile on wheezy?

bpgenc.c: In function ‘read_png’:
bpgenc.c:984:9: warning: implicit declaration of function ‘png_set_alpha_mode’ [-Wimplicit-function-declaration]
bpgenc.c:984:37: error: ‘PNG_ALPHA_ASSOCIATED’ undeclared (first use in this function)
bpgenc.c:984:37: note: each undeclared identifier is reported only once for each function it appears in
bpgenc.c:984:59: error: ‘PNG_GAMMA_LINEAR’ undeclared (first use in this function)
bpgenc.c:1069:26: warning: passing argument 5 of ‘png_get_iCCP’ from incompatible pointer type [enabled by default]
In file included from bpgenc.c:32:0:
/usr/include/png.h:2488:8: note: expected ‘png_charpp’ but argument is of type ‘png_byte **’
make: *** [bpgenc.o] Error 1


and after installation of latest libpng;
/source/libbpg-0.9.4/bpgdec.c:118: undefined reference to `png_set_longjmp_fn'
collect2: error: ld returned 1 exit status
make: *** [bpgdec] Error 1

[xooyoozoo]

0.9.4 needs some newer version of libpng that isn't in the repos for some reason related to compatibility. I forget the exact details.

You have to compile and install libpng16 yourself and replace all `-lpng` in the makefile with `-lpng16`. There might be an extra step related to `-lz` but my memory is fuzzy.

[Milaa]

Thank you, easyfab, for your Windows build with x265.
However, I am running Windows 7 (64 bit) and bpgenc64.exe is crashing, event without any file to compress (just running "bpgenc64.exe") :'-(
Regards

[Kurtnoise]

Try this build (http://www.mediafire.com/download/s57vet76qij9hb6/libbpg-0.9.4_20150107.7z)...

[Tommy Carrot]

Thanks for the build. Is it possible to use crf mode somehow? X265 seems to use CQ, and i cannot find a way to enable adaptive quantization.

BTW, JCTVC encoder seems to be much more efficient at lossless encoding than x265. It compresses some images almost half the size x265 does (and i checked, it is indeed lossless). Maybe x265 does not support lossless encoding properly yet, or it has some bugs that bloat the filesize.

[xooyoozoo]

BTW, JCTVC encoder seems to be much more efficient at lossless encoding than x265. It compresses some images almost half the size x265 does (and i checked, it is indeed lossless). Maybe x265 does not support lossless encoding properly yet, or it has some bugs that bloat the filesize.

x265 is currently limited by HEVC v1. JCTVC has access to extra compression tools introduced in the Range Extensions.

[Tommy Carrot]

x265 is currently limited by HEVC v1. JCTVC has access to extra compression tools introduced in the Range Extensions.

Oh, i see. I haven't realised that the range extensions are already finalised. It seems there are some nice improvements in compression efficiency over the baseline HEVC standard.

[smok3]

0.9.4 needs some newer version of libpng that isn't in the repos for some reason related to compatibility. I forget the exact details.

You have to compile and install libpng16 yourself and replace all `-lpng` in the makefile with `-lpng16`. There might be an extra step related to `-lz` but my memory is fuzzy.

Replacing `-lpng` in the makefile with `-lpng16` did the trick.

[djcj]

Hi,

Can anyone share his windows build of BPGenc with x265 encoder support (and/or linux one)?

Thanks in advance,

Milaa

Static Linux binaries with x265 support: http://forum.doom9.org/showthread.php?p=1703857#post1703857


@smok3: If you want to compile your own .deb (statically linked against libpng16 though, no x265) you could try the build stuff here (https://github.com/darealshinji/debian/tree/master/graphics/libbpg).
Run "make PBUILDER=0" inside graphics/libbpg. Build dependencies are debhelper quilt wget libjpeg8-dev zlib1g-dev.

edit: I've enabled x265 (requires cmake and yasm)

[smok3]

@djcj; thanks, will give it a try.

[birdie]

I'm utterly confused. In most situations when the amount of preserved details is paramount, JPEG beats BGP (with similar file sizes). JPEG was invented over 20 years ago, whereas H.265 is just a year old.

JPEG loses only if the image contains gradients which occupy a great amount of the resulting image - BGP compressed them more efficiently, thus it has the freedom to allocate more data to graphically complex parts of the image.

Why haven't we invented a codec which is more efficient than JPEG in all situations without exceptions?

The amount of blurring in BGP is simply unacceptable for almost all sizes except "large" (I'm talking about http://xooyoozoo.github.io/yolo-octo-bugfixes/ )

In certain cases BGP kills the picture, i.e. http://xooyoozoo.github.io/yolo-octo-bugfixes/#saint-catherine&bpg=l&jpg=l look at the woman's face

From my amateurish visual inspection at LARGE file sizes, JPEG almost always wins, WebP is a runner up and BGP produces the worst results (I haven't tried other codecs, but JPEG 2000 is also better than BGP).

[Bloax]

In certain cases BGP kills the picture, i.e. http://xooyoozoo.github.io/yolo-octo-bugfixes/#saint-catherine&bpg=l&jpg=l look at the woman's face
BPG looks better than JPEG on that image so I don't know what you're talking about.
Although I have to say that JPEG does look a bit better if I configure my monitor to display a very blurred image.

I'm utterly confused. In most situations when the amount of preserved details is paramount, JPEG beats BGP (with similar file sizes). JPEG was invented over 20 years ago, whereas H.265 is just a year old.
I also hope you understand the implications of fresh implementations of new concepts that has had a couple of years worth of development contending with implementations of a concept that have had over a decade of tuning and improvement. Maybe BPG isn't as good as JPEG (even though it sure looks like it is to me) but if it was as even remotely as mature as JPEG it would absolutely destroy it.

[Skarstorm]

When i try encoding a 7500x7500 file original jpg is 9.097kB the encoder crashed, however the same file cropped to 5888x4248 just works fine.

Is there a maximum file size or a way to prevent the crash of the encoder?

i used and standard encoder from bellard.org/bpg/ with jctvc and the one provided by Kurtnoise with x265 enabled, both of them crashed

thanks

[vivan]

The maximum resolution HEVC supports is 8192x4320.

[Skarstorm]

Bummer,
this encoding tool is based on HEVC but HEVC is specifically for video,
is it possible to discard this standard max resolution from HEVC for an image encoder "based" on HEVC?

[birdie]

BPG looks better than JPEG on that image so I don't know what you're talking about.
Although I have to say that JPEG does look a bit better if I configure my monitor to display a very blurred image.


I also hope you understand the implications of fresh implementations of new concepts that has had a couple of years worth of development contending with implementations of a concept that have had over a decade of tuning and improvement. Maybe BPG isn't as good as JPEG (even though it sure looks like it is to me) but if it was as even remotely as mature as JPEG it would absolutely destroy it.


Aside from an awful diagonal gradient and the loss of detail, yeah, BGP looks "better". Probably your should replace your TN monitor with something a tad better, like S-IPS or something.

[foxyshadis]

Bummer,
this encoding tool is based on HEVC but HEVC is specifically for video,
is it possible to discard this standard max resolution from HEVC for an image encoder "based" on HEVC?

It's quite easy to internally segment a large image into smaller encodable ones, that's how a lot of formats support large images right now. It just hasn't been implemented yet.

[mandarinka]

The maximum resolution HEVC supports is 8192x4320.

That is probably just the implementation used, the Still Image profile IIRC has unbound level (level 8.5) specified, that can go as high on resolution as it wants. According to Wikipedia, that was added in the Range Extensions amendment.

But naturally, the encoder itself must be written to handle huge resolutions...

[foxyshadis]

Aside from an awful diagonal gradient and the loss of detail, yeah, BGP looks "better". Probably your should replace your TN monitor with something a tad better, like S-IPS or something.

BPG probably needs to pick up grain modeling if it's going to compete with JPEG at low rates. The noisiness of JPEG looks terrible if you enlarge it at all, but it's just good enough at regular size that it fools the eye into thinking there's more detail than there really is. The science behind noise pleasing the eye has been around for decades, so generating fake grain seems like the way to go, especially if it's deterministic. (Note that in general, the AVC and HEVC standards committees didn't care about grain retention, they cared much more about sharp detail at low bitrates, which is why it's so hard to coax good grain from either format. The deblocking filter and SAO were designed to smooth out the image.)

JPEG, for all its warts, is a brilliant format and has been since the beginning. It's time to stop the argument that HEVC is immature, because it's actually relatively mature now, it's more a matter of getting developers to care about other use cases. It's not going to just happen, it may never happen because it's such tedious work. Marrying x265 with SCC would sure be nice -- maybe a screensharing use case would get them to work on it -- but that only helps screenshots, not smooth faces, and it isn't finished yet.

[xooyoozoo]

I'm utterly confused. In most situations when the amount of preserved details is paramount, JPEG beats BGP (with similar file sizes).

In situations where "preserved" details is paramount, I'd typically assume that the content creator would be more interested in real detail and not just quantization noise that happens to look good at a very specific PPI. Try zooming in via your browser (bilinear) or the in-page lanczos scaler to get a different vantage point and see which image would actually survive even the tiniest bit of processing.

Does JPEG work well when compression is light enough to suppress obvious artifacts but still heavy enough to suppress "real" detail? Yea, but honestly, I don't think that middle-ground is actually very common. Scrolling through the frontpages of CNet, DPreview and Boston Globe's Big Picture, all I can say is that JPEG-ness is quite obvious. Maybe there're corners of the internet where all image content is sized within the jpeg sweet-spot, but I don't think that's ever going to be applicable for most people and most websites (dat time to glass).

Still, I hope more effort is spent on grain modeling and better psychovisual tunings. (You can play with a version of the comparison page that uses x265's psy (http://xooyoozoo.github.io/yolo-octo-bugfixes/#addpsy#avenches&jpg=l&bpg=l) to see where and how psy-rd/oq helps).

When i try encoding a 7500x7500 file original jpg is 9.097kB the encoder crashed, however the same file cropped to 5888x4248 just works fine.

Is there a maximum file size or a way to prevent the crash of the encoder?

Could this be due to a 32bit build hitting a memory wall? Because 8000x8000 (edit: also 18K by 18K) via x265 10bit works fine for me.

Edit: BPG's modified header syntax limits width and height to unsigned 32bit each, which is a bit less than L8.5's literally unbounded dimensions.

While limiting ourselves to 4.29 billion pixels per side is such a terrible hardship, there's a bigger wall in libavcodec itself. That decoder won't create buffers that could mess up 32bit pointers, so even when we're using a 64bit build, bpgdec will still silently give up on 260+ megapixel images.

[djcj]

I've added a simple configure script to the source and did some clean-up with the Makefile: https://github.com/darealshinji/libbpg
This should make custom builds with different build flags much easier.

[Kurtnoise]

libbpg 0.9.5 has been released (http://bellard.org/bpg/)...

version 0.9.5:

- Added animation support.
- added bpgview utility.
- bpgenc: fixed support of some JPEG parameter combinations
- fixed JS 8 bit only decoder and renamed it to bpgdec8.js
- libbpg: added CMYK output format

[Milaa]

Thank you Kurtnoise and djcj for the Windows and Linux binary!!!!

[Kurtnoise]

A 0.9.5 windows binary (http://www.mediafire.com/download/89dokq3uecaqkb3/libbpg-0.9.5_20150112.7z) from today w/ x265 support...

btw, I found a strange thing...when you transcode a jpeg input file losslessly, the color space does not seem to be correct. I mean, using lossless mode, we should have the color space as RGB but with jpeg, I've got the YCbCr one.

Using png, it seems to be correct though...are you able to reproduce guys ?

[djcj]

v0.9.5 static 64bit (http://www.mediafire.com/download/uyyccmbnpvec6z0/bpg-0.9.5-linux-amd64.tar.xz) Linux binaries with x265 support.

And I've updated the configure script and Makefile on Github (https://github.com/darealshinji/libbpg) for the new version. (Tested only on Ubuntu 14.04. The configure script still doesn't check if all libraries are available! The actual source code is unmodified.)

Debian and Ubuntu users can build their own packages (https://github.com/darealshinji/debian/tree/master/graphics/libbpg) (run `make PBUILDER=0').


@xooyoozoo:
Encoding a picture using your libbpg mod fails if I don't specify a quantizer:
djcj libbpg-0.9.5 $ ./bpgencmod -e jctvc -o out-jctvc.bpg outfile.png
Error: QP exceeds supported range (-QpBDOffsety to 51)
djcj libbpg-0.9.5 $ ./bpgencmod -e jctvc -q 28 -o out-jctvc.bpg outfile.png
djcj libbpg-0.9.5 $
This doesn't happen to me with the original version.

[Bloax]

A 0.9.5 windows binary (http://www.mediafire.com/download/89dokq3uecaqkb3/libbpg-0.9.5_20150112.7z) from today w/ x265 support...

btw, I found a strange thing...when you transcode a jpeg input file losslessly, the color space does not seem to be correct. I mean, using lossless mode, we should have the color space as RGB but with jpeg, I've got the YCbCr one.
It works as expected for me with -e jvtvc, but -e x265 bitches out on my initial test image (https://dl.dropboxusercontent.com/u/63152810/n/s/n/test.jpg):
https://dl.dropboxusercontent.com/u/63152810/x265error.png
(it's 55x80)
It does parse the second image (https://dl.dropboxusercontent.com/u/63152810/n/s/n/test2.jpg) (which is the same thing except 160x120)

But other than that, I'm not seeing any visual degradations at all in neither jctvc nor x265 when recoding a YUV444 JPEG image. (Nor a RGB JPEG, but that's not included here.)
Even if I'm throwing it into the meat grinder. (It's extremely easy to spot visible degradation on a sprite like this.)
Test results + Images here (https://dl.dropboxusercontent.com/u/63152810/bpg_test.zip)

[foxyshadis]

btw, I found a strange thing...when you transcode a jpeg input file losslessly, the color space does not seem to be correct. I mean, using lossless mode, we should have the color space as RGB but with jpeg, I've got the YCbCr one.

Using png, it seems to be correct though...are you able to reproduce guys ?

Why would it? JPEG is natively YCbCr (except JPEG-LS and other variants can have RGB), and BPG just reads the raw data out and feeds it into itself. It helps that BPG specifies JPEG chroma siting and matrix, so it doesn't need to change anything at all -- it was specifically designed for this use case. Sure beats a round-trip to RGB, which might not even be lossless.

[Kurtnoise]

Because of this, from bpgenc.c file :

for(;;) {
c = getopt_long_only(argc, argv, "q:o:hf:c:vm:b:e:a", long_opts, &option_index);
if (c == -1)
break;
switch(c) {
case 0:
switch(option_index) {
case 0:
p->sei_decoded_picture_hash = 1;
break;
case 1:
keep_metadata = 1;
break;
case 2:
p->alpha_qp = atoi(optarg);
if (p->alpha_qp < 0 || p->alpha_qp > 51) {
fprintf(stderr, "alpha_qp must be between 0 and 51\n");
exit(1);
}
break;
case 3:
p->lossless = 1;
color_space = BPG_CS_RGB;
p->preferred_chroma_format = BPG_FORMAT_444;
bit_depth = 8;
limited_range = 0;
break;
case 4:
limited_range = 1;
break;
case 5:
premultiplied_alpha = 1;
break;
case 6:
p->loop_count = strtoul(optarg, NULL, 0);
break;
case 7:
p->frame_delay_num = 1;
p->frame_delay_den = strtoul(optarg, NULL, 0);
if (p->frame_delay_den == 0) {
fprintf(stderr, "invalid frame rate\n");
exit(1);
}
break;
case 8:
frame_delay_file = optarg;
break;
default:
goto show_help;
}
break;

[xooyoozoo]

I think that's a quick shortcut around how YCbCr is the default colorspace. Rgb PNGs would be converted otherwise, and the jpeg handling pathway just ignores that setting.


@xooyoozoo:
Encoding a picture using your libbpg mod fails if I don't specify a quantizer:


Thanks. Should be fixed now.

[Kisa_AG]

Hello!

Is it possible to encode to BPG anything other than JPEG? I'm trying to encode TIFF but it tells me "Not a JPEG file: starts with 0x49 0x49".

[Bloax]

BPG also supports PNG input, and since you're using BPG you'd probably be right at home converting .tiff to .png with imagemagick (http://www.imagemagick.org/).

[djcj]

Thanks. Should be fixed now.
It does work now. Thanks.

PS: anyone interrested to implement Kvazaar (https://github.com/ultravideo/kvazaar) as a third hevc encoder?

[xooyoozoo]

As the default method to to get bpgenc to produce animations is really really frustrating, I eked out a "bpgmux" of sorts in my modded libbpg (https://github.com/xooyoozoo/libbpg).

The muxer will be quite verbal if it sees something it dislikes, but most x265 encodes with --ref 1 --bframes 0 --rect --amp will work.

It will also work with single frame encodes (or manual muxing frame-limit), but color & gamma is always a frustrating topic, so it'd probably be better to just use bpgenc for still-images. For advance usage, though, the muxer will respect relevant VUI flags and handle them accordingly.

[djcj]

Was anyone able to build the javascript decoders from source? I can't get that to work on Linux (might be relevant for distribution packaging once a stable release comes out).

[easyfab]

As the default method to to get bpgenc to produce animations is really really frustrating, I eked out a "bpgmux" of sorts in my modded libbpg (https://github.com/xooyoozoo/libbpg).

The muxer will be quite verbal if it sees something it dislikes, but most x265 encodes with --ref 1 --bframes 0 --rect --amp will work.



Could you give me an example that work for you.
I try multiples files ( only files < 3 frames works )
for example : x265 foreman.y4m -o foreman.hevc --amp --rect --ref 1 --bframes 0

and I always have this :
bpgmux.exe foreman.hevc -o foreman.bpg
too many neg (2) or pos (0) refs
error while parsing (alpha? 0) NALs
Error while building modified hevc buffer with 2 frames processed
Muxing has failed.

[xooyoozoo]

I originally couldn't reproduce your issue, but then I remembered that I've been using a locally "fixed" (see bug report (https://bitbucket.org/multicoreware/x265/issue/99/vpsnumreorderpics-should-be-0-when-theres)) build of x265. :o

Apparently without the patch, x265 is counting the single ref frame twice. I'm not sure why x265 does this, especially as the behavior is unrelated to weighted pred, but decoders are usually based on uniqueness, so no harm no foul. :)

I just committed an allowance for this into the muxer.

[easyfab]

Thank you xooyoozoo.
I confirm it work now and a lot easier and faster than with bpg

foreman:
gif 9.43 Mo and bad quality ( with ffmpeg )
x265/bpg 497 ko ( crf23)

Animated bpg should soon rules :)

[Nintendo Maniac 64]

Any new comparisons with Daala? A new presentation video claims they're better than x265 in texture details and, when above 1bit per pixel, also on clean edges.

[Zero3K]

Is there any BPG viewer that is small in size? If not, one should be made. Thanks in advance.

EDIT: Is it possible to convert animated GIFs to BPGs? If so, how?

[benwaggoner]

Any new comparisons with Daala? A new presentation video claims they're better than x265 in texture details and, when above 1bit per pixel, also on clean edges.
Above 1 bpp seems like a questionable requirement.

x265 doesn't have a --tune stillimage equivalent yet, which would be the proper comparison point. Although I've had some success in early experience by copying the equivalent x264 parameters over.

[djcj]

I was able to use the GNU automake system to build libbpg: https://github.com/darealshinji/libbpg/tree/automake
You can link bpgenc just to x265 without building jctvc if you want, you can build a shared library (will be named libbpg-version.so.0 since there's no official libbpg.so.0 yet) and simple manpages will be generated. A pkg-config file will be created too.
The javascript libraries aren't generated yet (use Makefile-original for that).

By the way kvazaar is now licensed under LGPL which might be a good opportunity to enable it as an encoder: https://github.com/ultravideo/kvazaar

[Nintendo Maniac 64]

Above 1 bpp seems like a questionable requirement.

I'm just reporting what was said in a recent presentation on Daala. I believe the 1bpp thing just happens to be where the threshold of bitrate where they cross.

[birdie]

Lossless WEBP heavily beats lossless BPG.

In my case we're talking about 12% difference in resulting file sizes which is kinda weird since VP8 is not nearly as advanced as H.265.

I'm testing just one image but I still didn't expect such a result. I thought BPG would be a clear winner or at least there would be a tie.

[Skarstorm]

Why are you talking about lossless compression?

[mandarinka]

Lossless WEBP heavily beats lossless BPG.

In my case we're talking about 12% difference in resulting file sizes which is kinda weird since VP8 is not nearly as advanced as H.265.


That could be because lossless WebP isn't really VP8, it uses custom encoder and format with various additions and special tools to improve lossless intra compression.

[benwaggoner]

That could be because lossless WebP isn't really VP8, it uses custom encoder and format with various additions and special tools to improve lossless intra compression.
That's still a surprising result. Do you have details for the specific image and settings used? A 12% delta is HUGE with lossless compression.

Some of the standard images used in J2K v. JPEG evaluation would be interesting, since there are already data points for other image codecs. I'm most interested in natural images (non-synthetic) myself. I know HEVC is getting some improvements for screen capture and that sort of content.

it might also be interesting to see how the latest version of x265 compare. Although I'd expect relatively small version-on-version improvements since rate control and interframe compression don't apply to still image encoding.

HEVC's intra-frame prediction should be a big differentiator from past codecs for still frame encoding in general, including (but probably to a lesser degree) lossless.

[Tommy Carrot]

Lossless WEBP heavily beats lossless BPG.

In my case we're talking about 12% difference in resulting file sizes which is kinda weird since VP8 is not nearly as advanced as H.265.

I'm testing just one image but I still didn't expect such a result. I thought BPG would be a clear winner or at least there would be a tie.

Did you use x265 or the reference encoder for lossless encoding? Because the latter is massively better for lossless compression, probably because x265 doesn't support the recently added features of the h.265 standard, which are improving the lossless efficiency quite significantly.

[birdie]

I used the reference BPG encoder ( http://bellard.org/bpg/ ) using maximum compression (-m 9).

Here are the source files (https://d.maxfile.ro/xptohvgdne.zip) if anyone's interested.

These are three pictures stitched together and the difference is 7%. When I make a collage containing over 50 images (I cannot post the others, sorry), there's 12% difference. What's even funnier is that zip manages to compress WEBP files (2% is like nothing but anyways), while BPG files are incompressible.

[foxyshadis]

The latest XnView MP (http://newsgroup.xnview.com/viewtopic.php?f=82&t=31559) beta claims to support bpg. I haven't had time to test it yet, but it's a start.

[Tommy Carrot]

I used the reference BPG encoder ( http://bellard.org/bpg/ ) using maximum compression (-m 9).

Here are the source files (https://d.maxfile.ro/xptohvgdne.zip) if anyone's interested.

These are three pictures stitched together and the difference is 7%. When I make a collage containing over 50 images (I cannot post the others, sorry), there's 12% difference. What's even funnier is that zip manages to compress WEBP files (2% is like nothing but anyways), while BPG files are incompressible.

I'm not really sure why it performs so relatively badly, BPG with the ref encoder compresses your image barely any better than PNG does, even though on most images i've tried it it's at least 10-20% more efficient. Possible reason could be that your image is very blurry with very little spatial detail, and HEVC lossless mode is not really optimized for such circumstances.

I've tried x265 on your image too, it compressed it to 818533 bytes, which is even worse by 30%.

[birdie]

So far H.265 is full of myths while IRL it performs worse (at least at high bitrates when the details are paramount) than the x264 encoder based on H.264.

[benwaggoner]

So far H.265 is full of myths while IRL it performs worse (at least at high bitrates when the details are paramount) than the x264 encoder based on H.264.


For still images? And current builds?



Please share your settings and sources



Edit: Sorry, you linked tour sources above. I'll try to take a swing with a current x265 build.

[birdie]

I used the latest available BPG release.

I didn't use any fancy settings other than -m 9 (maximum compression).

[Jamaika]

Hi
Recently in other forums for questions about images of BPG and WebP I was banned. Questions about something unreal should not have happened and incitement to the use of fiction is unacceptable. I see that here is quite sizable topic.
I have therefore a loose Vacation question.
Do BPG files are used in cameras?
Can I take screenshot BPG with videos X265? If so, how?

Thank you for your response.

[jethro]

no, and IMO you would not be able for the forseeable future, probably never. WEBP may be possible, though especially in android phones.

[Jamaika]

I became curious lossless compression HEVC / VP9 (All-I) from RAW. I don't know whether I'm doing it correctly. I have many doubts.
I can't do RAW (RGBA) doesn't using during the conversion to YUV444p10le. I don't think it is possible. Nor do I know what RAW files (eg. YUV420p10le) can be imported directly into BPGenc.

I started with the demuxing of the RAW file PNG (RGBA-32bit)
ffmpeg.exe -y -s 3840x2160 -r 120.000 -pix_fmt yuv420p10le -loglevel warning -i "input.yuv" -frames 20 -s 1920x1080 -an -sn -f image2 -pix_fmt rgba %%03d_1_image.png
and create animations HEVC (RGBA-32bit) All-I.
bpgenc.exe -v -a -q 0 -alphaq 0 -lossless -f 444 -m 9 -b 8 -c rgb -fps 120 -keepmetadata "%%03d_1_image.png" -o "rgba_32bit_lossless.bpg"
Here I have many doubts. Why BGPenc converter creates the file first yuv444p 8bit and then it HEVC (BPG) rgba (32bit) ??? Why is there no alpha channel ???
File yuv444p08le
Input File : C:\Users\KOMPUT~1\AppData\Local\Temp\out5624-1.yuv {How is it RAW and can be imported directly into BPGenc?}
Bitstream File : C:\Users\KOMPUT~1\AppData\Local\Temp\out5624-1.bin
Reconstruction File : (null)
Real Format : 1920x1080 25Hz {Why does not the function framerate -fps ???}
Internal Format : 1920x1080 25Hz
Sequence PSNR output : Linear average only
Sequence MSE output : Disabled
Frame MSE output : Disabled
Cabac-zero-word-padding : Disabled
Frame/Field : Frame based coding
Frame index : 0 - 19 (20 frames)
Profile : main-RExt (main_444_16 [NON STANDARD]) ???
CU size / depth : 64 / 4
RQT trans. size (min / max) : 4 / 32
Max RQT depth inter : 4
Max RQT depth intra : 4
Min PCM size : 8
Motion search range : 96
Intra period : 250
Decoding refresh type : 0
QP : 0.00
Max dQP signaling depth : 0
Cb QP Offset : 0
Cr QP Offset : 0
Max CU chroma QP adjustment depth : -1
QP adaptation : 0 (range=0)
GOP size : 1
Input bit depth : (Y:8, C:8)
MSB-extended bit depth : (Y:8, C:8)
Internal bit depth : (Y:8, C:8)
PCM sample bit depth : (Y:8, C:8)
Extended precision processing : Disabled
Intra reference smoothing : Enabled
Implicit residual DPCM : Enabled
Explicit residual DPCM : Disabled
Residual rotation : Disabled
Single significance map context : Disabled
Cross-component prediction : Enabled (encoder-side-residual-based estimate)
High-precision prediction weight : Disabled
Golomb-Rice parameter adaptation : Enabled
CABAC bypass bit alignment : Disabled
Cost function: : Lossless coding with fixed QP of 0
RateControl : 0
Max Num Merge Candidates : 5

TOOL CFG: IBD:0 HAD:0 RDQ:1 RDQTS:1 RDpenalty:0 SQP:0 ASR:0 FEN:0 ECU:0 FDM:1 CFM:0 ESD:0 RQT:1 TransformSkip:1 TransformSkipFast:1 TransformSkipLog2MaxSize:2 Slice: M=0 SliceSegment: M=0 CIP:0 SAO:0 PCM:0 TransQuantBypassEnabled
: =1WPP:0 WPB:0 PME:2 WaveFrontSynchro:0 WaveFrontSubstreams:1 ScalingList:0 TMVPMode:1 AQpS:0 SignBitHidingFlag:1 RecalQP:0

Input ChromaFormatIDC = 4:4:4
Output (internal) ChromaFormatIDC = 4:4:4

RVM: 0.594
Bytes written to file: 47132828 (471328.280 kbps)
File HEVC/BPG (RGBA/32bit)
Input File : C:\Users\KOMPUT~1\AppData\Local\Temp\out5624-2.yuv
Bitstream File : C:\Users\KOMPUT~1\AppData\Local\Temp\out5624-2.bin
Reconstruction File : (null)
Real Format : 1920x1080 25Hz
Internal Format : 1920x1080 25Hz
Sequence PSNR output : Linear average only
Sequence MSE output : Disabled
Frame MSE output : Disabled
Cabac-zero-word-padding : Disabled
Frame/Field : Frame based coding
Frame index : 0 - 19 (20 frames)
Profile : main-RExt (main_444_16 [NON STANDARD])
CU size / depth : 64 / 4
RQT trans. size (min / max) : 4 / 32
Max RQT depth inter : 4
Max RQT depth intra : 4
Min PCM size : 8
Motion search range : 96
Intra period : 250
Decoding refresh type : 0
QP : 0.00
Max dQP signaling depth : 0
Cb QP Offset : 0
Cr QP Offset : 0
Max CU chroma QP adjustment depth : -1
QP adaptation : 0 (range=0)
GOP size : 1
Input bit depth : (Y:8, C:8)
MSB-extended bit depth : (Y:8, C:8)
Internal bit depth : (Y:8, C:8)
PCM sample bit depth : (Y:8, C:8)
Extended precision processing : Disabled
Intra reference smoothing : Enabled
Implicit residual DPCM : Enabled
Explicit residual DPCM : Disabled
Residual rotation : Disabled
Single significance map context : Disabled
Cross-component prediction : Disabled
High-precision prediction weight : Disabled
Golomb-Rice parameter adaptation : Enabled
CABAC bypass bit alignment : Disabled
Cost function: : Lossless coding with fixed QP of 0
RateControl : 0
Max Num Merge Candidates : 5

TOOL CFG: IBD:0 HAD:0 RDQ:1 RDQTS:1 RDpenalty:0 SQP:0 ASR:0 FEN:0 ECU:0 FDM:1 CFM:0 ESD:0 RQT:1 TransformSkip:1 TransformSkipFast:1 TransformSkipLog2MaxSize:2 Slice: M=0 SliceSegment: M=0 CIP:0 SAO:0 PCM:0 TransQuantBypassEnabled
: =1WPP:0 WPB:0 PME:2 WaveFrontSynchro:0 WaveFrontSubstreams:1 ScalingList:0 TMVPMode:1 AQpS:0 SignBitHidingFlag:1 RecalQP:0

Input ChromaFormatIDC = 4:0:0 ???
Output (internal) ChromaFormatIDC = 4:0:0 ???
RVM: 0.000
Bytes written to file: 1169 (11.690 kbps)
'it-depth' is not recognized as an internal or external command,
operable program or batch file.

For comparison, recording commands codec VP9.(frames aren't All-I)
ffmpeg.exe -y -loglevel warning -i "%%03d_1_image.png" -s 1920x1080 -an -sn -f rawvideo -pix_fmt yuv444p10le - | /
vpxenc.exe -v --bit-depth=10 --input-bit-depth=10 --i444 -w 1920 -h 1080 --profile=3 --threads=4 --passes=1 --pass=1 --best --codec=vp9 --cpu-used=3 --fps=120000/1000 /
--test-16bit-internal --lag-in-frames=1 --color-space=sRGB / {functions for me, I don't know of unknown use}
--lossless=1 - -o "vp90_444p10le.webm"

Codec: WebM Project VP9 Encoder v1.4.0-745-gdb50037
Source file: - File Type: RAW Format: I44416 ???
Destination file: vp90_444p10le.webm
Encoder parameters:
g_usage = 0
g_threads = 4
g_profile = 3
g_w = 1920
g_h = 1080
g_bit_depth = 10
g_input_bit_depth = 10
g_timebase.num = 1
g_timebase.den = 1000
g_error_resilient = 0
g_pass = 0
g_lag_in_frames = 1
rc_dropframe_thresh = 0
rc_resize_allowed = 0
rc_scaled_width = 0
rc_scaled_height = 0
rc_resize_up_thresh = 60
rc_resize_down_thresh = 30
rc_end_usage = 0
rc_target_bitrate = 256
rc_min_quantizer = 0
rc_max_quantizer = 63
rc_undershoot_pct = 25
rc_overshoot_pct = 25
rc_buf_sz = 6000
rc_buf_initial_sz = 4000
rc_buf_optimal_sz = 5000
rc_2pass_vbr_bias_pct = 50
rc_2pass_vbr_minsection_pct = 0
rc_2pass_vbr_maxsection_pct = 2000
kf_mode = 1
kf_min_dist = 0
kf_max_dist = 600
Pass 1/1 frame 20/20 53249681B 21299872b/f 2555984688b/s 608028 ms (0.03 fps)[K
Oddly enough, I can't create a file WebM (RGBA) ie. in WebP. :( {Edit: Already known. WebP (lossy) doesn't RGBA.}

[foxyshadis]

I'm confused what you're comparing here, since multi-frame BPG already has a format: HEVC. Compressing 20 frames to BPG doesn't make sense, and still images have no fps.

BPG stores RGB32 streams as one 444 stream and one 400 alpha stream, maybe that'll explain what you're seeing. It looks like you're pulling the analysis from HM, which is incorrect, since BPG isn't HEVC. You need a BPG parser to get BPG information.

[Jamaika]

Compressing 20 frames to BPG doesn't make sense,...
Why I chose only 20 frames of the movie? Video compression lasted 1 hour.
...and still images have no fps.
I don't understand. Videos MJPG has fps and similarly MBPG.
BPG stores RGB32 streams as one 444 stream and one 400 alpha stream, maybe that'll explain what you're seeing.
I didn't know. Strange record and double the waiting time.:helpful:
It looks like you're pulling the analysis from HM, which is incorrect, since BPG isn't HEVC.
I see a transition file *.bin. FFplayer reads it as HEVC. Then BPGenc converter puts it into a container of BPG.
https://www.sendspace.com/file/zemyom
Input #0, hevc, from 'out5624-1.bin':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: hevc (Rext), yuv444p(tv) <-- rgb24(pc), 1920x1080, 25 fps, 25 tbr, 1200k tbn, 25 tbc
nan M-V: nan fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0
I understand that HEVC not read RGBA and content must be in BPG. Otherwise we will not open.

[foxyshadis]

Why I chose only 20 frames of the movie? Video compression lasted 1 hour.

Use -e x265

I don't understand. Videos MJPG has fps and similarly MBPG.

Unless you're specifically trying to make an embeddable animation (like an animated GIF), I think what you really want is real HEVC. Built-in alpha channel support is handy, but that doesn't make sense for a normal movie, and compression will suffer without B frames and only a single reference frame.

The 25fps framerate you wondered about is because bpgenc throws away the encoder's framerate and writes its own instead, so it doesn't bother to pass one to the encoder.

I didn't know. Strange record and double the waiting time.:helpful:

Not double, it's the same time whether it's compressed all at once (which means modifying the encoder) or separately. Each plane is just mostly-unrelated monochrome information to the encoder.

I see a transition file *.bin. FFplayer reads it as HEVC. Then BPGenc converter puts it into a container of BPG.
https://www.sendspace.com/file/zemyom
Input #0, hevc, from 'out5624-1.bin':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: hevc (Rext), yuv444p(tv) <-- rgb24(pc), 1920x1080, 25 fps, 25 tbr, 1200k tbn, 25 tbc
nan M-V: nan fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0
I understand that HEVC not read RGBA and content must be in BPG. Otherwise we will not open.

Same thing, BPG just uses the usual YUV planes for whatever purpose necessary. You have to use bpgdec to get the real information from the bpg header.

[Jamaika]

I think what you really want is real HEVC. Built-in alpha channel support is handy, but that doesn't make sense for a normal movie, and compression will suffer without B frames and only a single reference frame.
Okay, we can throw out the channel alpha and B-frames encoder X265. Only in this case, what is the point of using the old codec BPGenc (X265 1.4+96). Not better to take X265.exe --amp --rect --ref 1 --bframes 0 --lossless ?
Problematic is also the elimination of the alpha channel. There is no function -noalpha. You have to replace PNG files by changing RGBA to RGB24.
The 25fps framerate you wondered about is because bpgenc throws away the encoder's framerate and writes its own instead, so it doesn't bother to pass one to the encoder.
I don't know what is the function of -fps? For me it is a dead function.
Info with BPGdec
size=1920x1080 color_space=RGB format=4:4:4 limited_range=0 bit_depth=8 animation=1
Extension data:
tag=5 (Animation control) length=3

PS. When will update v0.9.5 (2015-01-11)? Because it can actually wasting time on things that have fallen into disuse.

[foxyshadis]

Okay, we can throw out the channel alpha and B-frames encoder X265. Only in this case, what is the point of using the old codec BPGenc (X265 1.4+96). Not better to take X265.exe --amp --rect --ref 1 --bframes 0 --lossless ?

You can build it with a newer x265, some builds might be available. I had it dynamically linking to the x265 dll when it first appeared, but I didn't keep the changes up through later versions.

The format has a very specific purpose: Coding single pictures, with exif information and other photography-specific stuff. Recently it added the ability to do animated GIF-like sequences. It was never intended to be a competing video format, because HEVC itself already serves that role. This is a picture format first and an animation format second (and a movie format not at all).

You can use x265 directly and then bpgmux (from https://github.com/xooyoozoo/libbpg) to convert encodes to BPG. You could create a simple batch file to emulate bpgenc that way.

Problematic is also the elimination of the alpha channel. There is no function -noalpha. You have to replace PNG files by changing RGBA to RGB24.

That can easily be done with the C library, but yeah, it's a missing function from the command line. The command-line also can't encode from a pipe, which would be another way to work around it.

I don't know what is the function of -fps? For me it is a dead function.
Info with BPGdec
size=1920x1080 color_space=RGB format=4:4:4 limited_range=0 bit_depth=8 animation=1
Extension data:
tag=5 (Animation control) length=3

Looks like bpgdec just doesn't show the contents of the animation tag, only its existence; it only reports the size and colorspace. I have looked with a hex editor and I can guarantee that it's whatever you set for fps, not just 25; -fps 120 shows up as 01 78, or 1/120 second per frame. bpgview and the js decoder both respect that framerate.

I'll see if it's possible to get more complete support in MediaInfo so you don't have to rely on bpgdec.

[Jamaika]

You can build it with a newer x265, some builds might be available. I had it dynamically linking to the x265 dll when it first appeared, but I didn't keep the changes up through later versions.
Okay, but we can scratch off such advertising as color spaces RGB, RGBA, CMYK for BPG.
You can use x265 directly and then bpgmux (from https://github.com/xooyoozoo/libbpg) to convert encodes to BPG. You could create a simple batch file to emulate bpgenc that way.
Supposedly there is a small advantage with respect to compress the file size for the function. On the forum Videohelp told that it is best to compress with minimal loss of data or quality of 95%.
The problem is, I don't know how to set it up for the X265 codec or BPG. :o
Looks like bpgdec just doesn't show the contents of the animation tag, only its existence; it only reports the size and colorspace. I have looked with a hex editor and I can guarantee that it's whatever you set for fps, not just 25; -fps 120 shows up as 01 78, or 1/120 second per frame. bpgview and the js decoder both respect that framerate.
I confess that I did not check the EXIF.
On the other hand, I discovered later versions BPGdec/enc where you can convert to BMP, RGB and YUV. I can also conwertować BMP to BPG.
https://www.reaconverter.com/convert/bmp_to_bpg.html
https://convert.zone/BMP-to-BPG
http://pragmaticjoe.blogspot.com/2015/05/using-bpg-image-format-on-android.html
PS. Converting other formats is payable.:(
The format has a very specific purpose: Coding single pictures, with exif information and other photography-specific stuff. Recently it added the ability to do animated GIF-like sequences. It was never intended to be a competing video format, because HEVC itself already serves that role. This is a picture format first and an animation format second (and a movie format not at all).
Hmmm, just what does it do?
Size file lossless RGB24: | Size file quality 95% RGB24
BMP 6.220.854 | none
PNG 2.996.039 | none
JPG 3.133.548 (RGB24) | 1.224.531 (RGB24)
BPG 2.986.506 | 1.713.554 (-q 12)
WEBP (VP8) 2.671.754 (RGB24) | 0.591.536 (-q 96) (YUV)

[foxyshadis]

Hmmm, just what purpose is being done?
Size file lossless RGB24: | Size file quality 95% RGB24
BMP 6.220.854 | none
PNG 2.996.039 | none
JPG 3.133.548 | 1.224.531
BPG 2.986.506 | ~1.500.000 (???)
WEBP 2.671.754 | 0.551.310

You can make any of the lossy formats any size you want and call it a percentage or anything you want. Only comparisons of how it looks at similar sizes are meaningful. If you have a rough target of what you want to hit, say 1mb, adjust the quality setting to roughly hit it. I can tell you that the rough equivalent of "95%" in JPEG is -q 12 in BPG, -q 96 in WebP, and -q 70 in JPEG-XR, for 8-bit YV12, but if you change the colorspace then all bets are off.

Since WebP can't store lossless RGB, only YV12, it's not really lossless and will always be much smaller than BPG's true RGB. JPEG can never be lossless at all, even without quantization, due to rounding errors and conversion to YUV. (JPEG-LS exists but isn't compatible.) If you're comparing to formats that can't store RGB, then why bother storing RGB at all?

WebP is just a better-looking JPEG; it doesn't support more than 8-bit or wide gamut or full color, plus it's much slower than x265. VP8 is a terrible format to base a new image format on, it ended up not even being patent-free. BPG is more comparable to JPEG-XR, the VC-1-based image format.

Edit: OK, I take part of this back; WebP lossless is actually 3 or 4 monochrome planes compressed like PNG, so it actually can store RGB(A). However, that's only in lossless mode, not regular.

[Jamaika]

I'm a beginner so you can suggest me a lot.
I can tell you that the rough equivalent of "95%" in JPEG is -q 12 in BPG, -q 96 in WebP, and -q 70 in JPEG-XR, for 8-bit YV12, but if you change the colorspace then all bets are off.
:thanks: Are the network to any tables?
JPEG can never be lossless at all, even without quantization, due to rounding errors and conversion to YUV.
I see no loss of data in HEX BMP.
http://i58.tinypic.com/1zxo0h4.png
I don't know, is it a JPEG-LS?
(JPEG-LS exists but isn't compatible.) If you're comparing to formats that can't store RGB, then why bother storing RGB at all?
Understandings that isn't compatible web browsers. Many converters are already JPEG (RGB24). It says that compatible with Adobe.
However, that's only in lossless mode, not regular.
Why? Is this record lossy not WebP RGB24, the quality factor of 95%? (-q 0:small..100:big)
cwebp.exe -v -q 96 -noalpha -m 6 -progress -metadata all "001_1_image.png" -o "001_1_image_95%.webp"
http://i59.tinypic.com/344tx52.png

[foxyshadis]

I just downloaded Image Converter Plus, created a true lossless JPEG just like your screenshot, and couldn't open it in Photoshop ("Could not complete your request because reading spatial/lossless JPEG files is not implemented.") or anything else for that matter. The format does exist, but it's not used at all outside of specialized medical software. Same with JPEG-LS.

Why? Is this record lossy not WebP RGB24, the quality factor of 95%? (-q 0:small..100:big)
cwebp.exe -q 95 -noalpha -m 6 "001_1_image.png" -o "x265_444p10le.webp"

That'll convert to YUV 4:2:0, because that's the only format lossy WebP can be. I'm not sure why HoneyView would call it RGB, maybe a limitation of the program.

[Jamaika]

You're right. There is something wrong. I thought that colorspace YUV be accompanied by a function -jpeg_like. I was wrong.
Input #0, webp_pipe, from '001_1_image_95%.webp': sq= 0B f=0/0
Duration: N/A, bitrate: N/A
Stream #0:0: Video: webp, yuv420p(tv, bt470bg/unknown/unknown), 1920x1080, 25 tbr, 25 tbn, 25 tbc
4.08 M-V: 0.000 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0
Oddly enough, the codec WebP v0.4.3 has no function -color-space sRGB ie. for VP9 WebM.

[Jamaika]

New version codec BPG 0.9.6. Much faster work.
http://bellard.org/bpg/bpg-0.9.6-win64.zip

Edit: Cancelled function encoder bpgenc.exe -e jctvc. My previous inquiry passed into history. (:
Because the container BPG is based on X265 so I think that soon should be included eg. for ffmpeg and other converters. :idea:

Edit: Problems with conversion:
bpgenc.exe image1_yuv444p(12bit).jpg -q 0 -f 444 -c ycbcr -b 12 -m 9 -v -keepmetadata -o image1_yuv444p(12bit).bpg
cwebp.exe image1_yuv444p(12bit).jpg -q 100 -noalpha -progress -m 6 -v -metadata all -o image1_yuv420p(8bit).webp {VP8X}
bpgenc.exe image1_rgb(12bit).jpg/png/tiff -q 0 -f 444 -c rgb -b 12 -m 9 -v -keepmetadata -o image1_rgb(12bit).bpg
cwebp.exe image1_rgb(12bit).jpg/png/tiff -q 100 -noalpha -progress -m 6 -v -metadata all -o image1_yuv420p(8bit).webp {VP8X}
ffmpeg -i image1_yuv444p(12bit).jpg -f webp -quality 100 -pix_fmt yuv444p12le image1_yuv420p(8bit).webp {VP8X}
ffmpeg -i image1_rgb(12bit).jpg -f webp -quality 100 -pix_fmt rgb48be image1_yuv420p(8bit).webp {VP8X}
https://www.sendspace.com/filegroup/RpQEct3Ja87wNQK5YrZQ3lV7vXx%2FGFcl

[Skarstorm]

The new version can also handle files with a resolution higher then the max resolution HEVC supports
The maximum resolution HEVC supports is 8192x4320.

Very nice

[Jamaika]

New version BPG v0.9.7
http://bellard.org/bpg/libbpg-0.9.7.tar.gz

PS Unfortunately, I don't know what contains new. No information. There isn't also compiled. ):

[smok3]

Acording to changelog in tarball only js part is updated.

[Jamaika]

Who knows how is it with images BPG (X265)? Are they only to a program XnView?
There are plugins with BPG X265 with 2.1 but not on the official site. Strange :o
http://encode.ru/threads/2095-BPG-yet-another-format-to-replace-JPEG?p=50549&viewfull=1#post50549

[CruNcher]

Hi there is a nice compare platform

http://wyohknott.github.io/image-formats-comparison/

it shows exactly :)

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.



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.

But it also shows some other interesting results and it shows indeed the visual superiority of BPG currently in most test cases.

http://wyohknott.github.io/image-formats-comparison/#tennis*3:1&bpg=m&jp2=m
http://wyohknott.github.io/image-formats-comparison/#tennis*3:1&bpg=l&jp2=l
http://wyohknott.github.io/image-formats-comparison/#tennis*3:1&bpg=l&jpg=l

http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*2:1&bpg=l&jpg=l
http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*2:1&bpg=m&jpg=m
http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*2:1&bpg=ll&jpg=ll

At low bitrates you can obviously see it's superior ringing avoidance in a snap,especially on already noisy input it works at those like always since the inloop filter as a pre processor though at higher bitrates it tries to maintain the input as much as possible, exactly what you would want from good content adaptive result imho.

Low Bitrates

Superior Ringing Avoidance without becoming visually unpleasing no matter the input quality

High Bitrates

Exact replication

So it scales pretty nicely overall from 0 to Hero ;)

you can also nicely see how some things of Daala where rethought and more stabilized in AV1 though some unique daala things gone lost obviously in that process as well so far :(

http://wyohknott.github.io/image-formats-comparison/#tennis*3:1&ogv=m&jpg=m
http://wyohknott.github.io/image-formats-comparison/#tennis*3:1&ogv=m&jp2=m


http://wyohknott.github.io/image-formats-comparison/#ballet-exercise*3:1&ogv=m&webm=m
http://wyohknott.github.io/image-formats-comparison/#tennis*3:1&ogv=m&webm=m
http://wyohknott.github.io/image-formats-comparison/#tennis*3:1&bpg=m&webm=m

[Jamaika]

Hi there is a nice compare platform
It's probably everyone knows that such a test was. I wonder what has that got to do with the current theme of BPG. BPG is a new codec X265 v2.1. (I understand that the fee required)
http://forum.doom9.org/showthread.php?p=1784385#post1784385

[benwaggoner]

BPG is more comparable to JPEG-XR, the VC-1-based image format.
FWIW, JPEG-XR wasn't based on VC-1. It is a layered format like JPEG-XR, but the layers alternate between being DCT-like and wavelet-like.

A VC-1 I-frame image codec certainly would have outperformed JPEG, but would have still been 8-bit YUV only. JPEG-XR was designed to be colorspace independent, and support things like 16-bit CMYK, 10-bit RGBA, and IIRC even RAW Bayer patterns. Its target was really the photography industry, to offer all the stuff JPEG didn't and J2K was too slow or too large for. It would have been great for digital filmmaking if it had caught on.

Also AFAIK, it never really got used for anything practical, despite being royalty free and everything. I'm not sure the psychovisual tuning ever got to the point where it offered a meaningful advantage over J2K, which by that point had substantial momentum. Its RAW Bayer support could have been awesome, and addressed a lot of ongoing industry issues in both file size and interoperability. Those >4Kp60 cameras can record a lot of data!

[Gravitator]

Hi there is a nice compare platform

http://wyohknott.github.io/image-formats-comparison/


http://wyohknott.github.io/image-formats-comparison/#cologne-cathedral*3:1&ogv=m&bpg=m
BPG smears trees and brickwork under the bridge! It is necessary to add an additional BPG + Psy.

[dipje]

jpeg-xr is still format for my own photography stuff. lossless, all the image formats I want (16-bit is a bit of a minimum) and it encodes 24+ megapixel images under 4 seconds, and has full exif support with / through exiftool. I happily take a file that is a few MBs more in size compared to other modern lossless image formats.. the convenience just beats it all for me. Nothing of this has anything to do with web-images, end-delivery (like, regular old jpg files) or the video world :).

I'm just dreaming of the day when there is a modern ILC camera that has jpeg-xr as a write option. Either write complete done images (like the old jpg files) but in 16 bit so that they're actually still somewhat gradable and editable after the fact... or use jpeg-xr's floating-point / hdr support to write an image that is debayered and pretty much good to go, but still has all the information 'past 1.0' or under '0.0' that the image sensor captured (no need to throw anything away while still including the tone mapping). Seems perfect to me, but it just never took of :).

What I read from it it isn't even wavelet based, just 'plain old' DCT, just bigger and more of it so to speak. They described it as 'an enhanced DCT for decoders with more memory, and support for 16bit and lossless'. I think the HDR isn't real floating point but just 16-bit integers with a mapping curve or something. Still, it's so fast compared to all the webp / bpg / flif formats.

BPG comes close though now that they're using x265 instead of the reference encoder. Much faster and lossless sizes are good, although 'limited' to 12bit. jpeg-xr is faster, has true 16bit and I don't have to save the metadata in a separate file next to the image. Close, but still a no brainer for me.

[CSMR]

Is this format progressing at all?

I was using JPEG XR which had similar advantages (good ratios on lossless and lossy compression, >8bit) but only reached a small amount of support and lost Photoshop support. It still has Windows Imaging Component support but lack of Photoshop support shows it's dead as a high-end format.

BPG looks even better but doesn't seem to have any software support. None of my applications can open it let alone save to it, and it doesn't have a decoder/encoder for WIC.

What is the next step for this format? Is it waiting for HEVC ubiquity before launching?

[birdie]

You speak of it as if it's a registered/standardized/certified format. Nope. Maybe that's why it's not progressing.

Besides in my own tests I found it inferior to WebP which is based on the ages old VP8 encoder. AV1 shows some promise though and that's what I'll probably use to compress my JPEGs (very high quality so there's no issue of trying to overcome compression artefacts).

[dipje]

(JPEG-XR) ...but lack of Photoshop support...

Just a FYI, reading works fine in Photoshop and reading works fine (out of the box) in Affinity Photo. Metadata (EXIF) support works fine through exiftool.
Makes it my archival format of choice. I can just open a file by dropping it in Photoshop but I can't accidentally overwrite the archive-version :P.

About BPG, isn't the whole HEVC licensing thing still being formulated? I thought BPG had a big question mark about it's openness / ready-to-be-used-status because of this which put the brakes to the adoption.

[CSMR]

I can't open JPEG XRs on the current Windows 10+Photoshop CC.

I found that lossless JPEG XRs gave on average 50% lower filesizes for 16bpc images than TIFF with LZW compression. So yes great for archival purposes - when I could actually open and save them.

I would be interested in lossless performance of BPG.

But overall any modern format that does >8bpc, has a lossless mode, and a Photoshop plugin would be great in my book.

[benwaggoner]

jpeg-xr is still format for my own photography stuff. lossless, all the image formats I want (16-bit is a bit of a minimum) and it encodes 24+ megapixel images under 4 seconds, and has full exif support with / through exiftool. I happily take a file that is a few MBs more in size compared to other modern lossless image formats.. the convenience just beats it all for me. Nothing of this has anything to do with web-images, end-delivery (like, regular old jpg files) or the video world :).

I'm just dreaming of the day when there is a modern ILC camera that has jpeg-xr as a write option. Either write complete done images (like the old jpg files) but in 16 bit so that they're actually still somewhat gradable and editable after the fact... or use jpeg-xr's floating-point / hdr support to write an image that is debayered and pretty much good to go, but still has all the information 'past 1.0' or under '0.0' that the image sensor captured (no need to throw anything away while still including the tone mapping). Seems perfect to me, but it just never took of :).

Well, you certainly understand what the goals were for JPEG-XR! Unfortunately Microsoft cut resources for it due to it not being critical to any one business group willing to fund the entire effort - a common problem in the Massive Microsoft Media Meltdown of 2006-2012.

What I read from it it isn't even wavelet based, just 'plain old' DCT, just bigger and more of it so to speak. They described it as 'an enhanced DCT for decoders with more memory, and support for 16bit and lossless'. I think the HDR isn't real floating point but just 16-bit integers with a mapping curve or something. Still, it's so fast compared to all the webp / bpg / flif formats.
It actually alternated between a DCT-like and wavelet-like transform for each layer.

BPG comes close though now that they're using x265 instead of the reference encoder. Much faster and lossless sizes are good, although 'limited' to 12bit. jpeg-xr is faster, has true 16bit and I don't have to save the metadata in a separate file next to the image. Close, but still a no brainer for me.
There are 16-bit HEVC profiles, particularly Main 4:4:4 16 Still Picture. Which should be great for photography. And certainly HEVC should offer smaller lossless encoding, and much smaller visually lossless encoding, than J2K or JPEG-XR. Intra-frame prediction with lots of block sizes is a good thing!

I don't know how well that profile would encode RAW sensor data, but it certainly would work for anything normalized to gamma, PQ, or similar EOTF.

HEVC v3 includes some color video profiles up to 14-bit (which I don't know that anything supports), but 16-bit remains intra/still encoding only. There are monochrome 16-bit profiles back to v2, oddly.

[Jamaika]

New version encoder BPG image 0.9.8 & HEIF image 1.0.0

https://hevc.hhi.fraunhofer.de/trac/hevc/browser/branches?order=name

Compatible with JPG and PNG.
Library enc/dec:
libBPG 0.9.8 [28 Apr 2018] libHEIF 1.0.0 [27 Apr 2018] libX265 2.7+342 [19 Apr 2018]
jctvc_hm 16.18 [04 Apr 2018] don't work
https://www.sendspace.com/filegroup/Ux7kRlix9FAuIloUolDB2AGE4a6c%2FEKHuJg6R0WAxLg

[FranceBB]

HEVC for motion pictures switches between the Discrete Cosine Transform and the Karhunen–Loève Transform to achieve maximum compression ratio; although the KLT achieves better compression than DCT, it's not always worth the computational effort required (which is greater than the DCT, mostly because the DCT doesn't use imaginary numbers and is constant in 2 phi). I understand that BPG is based on HEVC Still image, but does it use DCT only, KLT only or is it able to switch between these two according to the type of image?

[Jamaika]

In the JCTVC codec is implementation of mode-dependent KLT for intra coding. I don't know how is it in the case of x265?

[foxyshadis]

KLT never made it into HEVC, the proposal was dropped during development; it's a proposed part of JEM/VVC only.

[Jamaika]

I was able to run the latest HM 16.18 codec. I find that the x265 codec has much better quality for 4K photos. Example: 6000kb
bpgenc.exe -v -b 8 -c ycbcr -f 420 -q 38 -m 9 -e jctvc -o yuv420p_jctvc.bpg source.jpg 100kb
bpgenc.exe -v -b 8 -c ycbcr -f 420 -q 41 -m 9 -e x265 -o yuv420p_x265.bpg source.jpg 100kb
http://i63.tinypic.com/jrz66s.jpg
codec jctvc HM 16.18
http://i66.tinypic.com/vryl5i.png
codec x265 2.7+342
http://i66.tinypic.com/2v1w278.png

[smok3]

Any clues why there is no crf like switch with bpgenc?

[ajp_anton]

Any clues why there is no crf like switch with bpgenc?
The "C" in "CRF" stands for "Constant", and it means constant in time. There is no time in BPG, because it's not video.

[smok3]

You are right, I shall refraze: Isn't there some other quality based metrics/stuff that can be used instead of qp?

[Asmodian]

CRF like makes little sense for still images. CRF works by increasing QP during high motion scenes because they take a lot more bit rate and humans notice quality issues less during motion. In a still image there is no motion to hide extra artifacts, it is possible to increase the QP for larger blocks but that would be like AQ, not CRF.

Edit: And CRF isn't really based on a quality metric in that way, it is a rate control method not a quality setting method. QP would be just as good for setting quality if it wasn't for the time based bit rate curve compression.

[benwaggoner]

CRF like makes little sense for still images. CRF works by increasing QP during high motion scenes because they take a lot more bit rate and humans notice quality issues less during motion. In a still image there is no motion to hide extra artifacts, it is possible to increase the QP for larger blocks but that would be like AQ, not CRF.

Edit: And CRF isn't really based on a quality metric in that way, it is a rate control method not a quality setting method. QP would be just as good for setting quality if it wasn't for the time based bit rate curve compression.

Well, x264/5 adaptive quantization is basically QP with some offsets based on visual complexity. In essence, it'll lower QP in smooth regions and increase it in complex regions, improving its results psychovisually versus just QP.

I've had good success using CRF like one would use the JPEG "quality" parameter (although on a very different scale), and have gotten superior results from CRF than QP.

Basically, your options are CRF, QP, bitrate, or lossless. CRF is the best choice for still images for most use cases.

Copying the common parameters from H.264's --tune stillimage can help, although I'm sure a well-optimized x265 --tune stillimage would have some adjustments.

[Asmodian]

For still images, what is the difference between CRF and QP? CRF does not use a quality metric, it is based on complexity (as you know, of course).

Do you mean that when using the same CRF setting you get better results (quality/size) on a wider variety of images because CRF uses a higher QP for more complex images, like a full frame version of AQ?

[MasterNobody]

At least for x264 QP ratecontrol means that AQ is disabled i.e. big "No....no....no.....no..." if you want encode anything not for testing.

[benwaggoner]

Adaptive quantization (psy-rd, aq-mode, aq-strength). Psychovisual tuning is just as important for still images (albeit a simpler subset).

With aq-mode 3, you’ll get a lower QP in smoother and darker areas, allowing for a higher CRF that will apply to parts of the image that are easier to compress. To get the same visual quality with QP would require a significantly lower QP to make sure the harder parts look good. But that results in that QP being used for the easier parts of frame as well, giving THEM a lower QP than using CRF would, thus increasing total bytes used. For real-world content, QP needs a higher bitrates to achieve the same quality.

This is basically how “JPEG Optimizers” deliver better quality than just using the JPEG quality parameter. HEVC has WAY more awesome tools available for efficient image coding, though.

Hoping for a good —tune stillimage someday.

[Jamaika]

Adaptive quantization (psy-rd, aq-mode, aq-strength). Psychovisual tuning is just as important for still images (albeit a simpler subset).

With aq-mode 3, you’ll get a lower QP in smoother and darker areas, allowing for a higher CRF that will apply to parts of the image that are easier to compress. To get the same visual quality with QP would require a significantly lower QP to make sure the harder parts look good. But that results in that QP being used for the easier parts of frame as well, giving THEM a lower QP than using CRF would, thus increasing total bytes used. For real-world content, QP needs a higher bitrates to achieve the same quality.

This is basically how “JPEG Optimizers” deliver better quality than just using the JPEG quality parameter. HEVC has WAY more awesome tools available for efficient image coding, though.

Hoping for a good —tune stillimage someday.

So you have to add the corrections for x265 stillimage:
p->rc.aqMode = 3;
p->rc.aqStrength = 1.0;
p->deblockingFilterTCOffset = -6;
p->deblockingFilterBetaOffset = 6;
p->psyRd = 2.0;
Is that enough?
https://x265.readthedocs.io/en/default/presets.html
PS What is wrong with aq-mode? For values three is always blocked.:D
x265 (build 176) - 3.1+5:[Windows][GCC 9.1.1][64 bit][noasm] 10bit - H.265/HEVC codec - Copyright 2013-2018 (c) Multicoreware, Inc - http://x265.org - options: cpuid=0 frame-threads=2 wpp no-pmode no-pme no-psnr no-ssim log-level=2 bitdepth=10 input-csp=2 fps=25/1 input-res=1568x1560 interlace=0 total-frames=1 level-idc=0 high-tier=1 uhd-bd=0 ref=1 no-allow-non-conformance repeat-headers annexb no-aud no-hrd info hash=0 no-temporal-layers no-open-gop min-keyint=1 keyint=1 gop-lookahead=0 bframes=0 b-adapt=0 no-b-pyramid bframe-bias=0 rc-lookahead=0 lookahead-slices=0 scenecut=0 radl=0 no-splice no-intra-refresh ctu=64 min-cu-size=8 rect amp max-tu-size=32 tu-inter-depth=4 tu-intra-depth=4 limit-tu=0 rdoq-level=2 dynamic-rd=0.00 no-ssim-rd signhide tskip nr-intra=0 nr-inter=0 no-constrained-intra strong-intra-smoothing max-merge=5 limit-refs=0 no-limit-modes me=3 subme=5 merange=92 temporal-mvp no-weightp no-weightb no-analyze-src-pics deblock=-6:6 sao no-sao-non-deblock rd=6 no-early-skip no-rskip no-fast-intra no-tskip-fast no-cu-lossless b-intra no-splitrd-skip rdpenalty=0 psy-rd=2.00 psy-rdoq=0.00 no-rd-refine no-lossless cbqpoffs=0 crqpoffs=0 rc=cqp qp=0 aq-mode=0 aq-strength=0.00 no-cutree zone-count=0 no-strict-cbr qg-size=64 no-rc-grain qpmax=69 qpmin=0 no-const-vbv sar=0 overscan=0 videoformat=5 range=0 colorprim=2 transfer=2 colormatrix=2 chromaloc=0 display-window=0cll=0,0 min-luma=0 max-luma=1023 log2-max-poc-lsb=8 vui-timing-info vui-hrd-info slices=1 no-opt-qp-pps no-opt-ref-list-length-pps no-multi-pass-opt-rps scenecut-bias=0.05 no-opt-cu-delta-qp no-aq-motion no-hdr no-hdr-opt no-dhdr10-opt no-idr-recovery-sei analysis-reuse-level=5 scale-factor=0 refine-intra=0 refine-inter=0 refine-mv=0 refine-ctu-distortion=0 no-limit-sao ctu-info=0 no-lowpass-dct refine-analysis-type=34210312 copy-pic=1 max-ausize-factor=1.0 no-dynamic-refine no-single-sei no-hevc-aq no-svt no-field qp-adaptation-range=1.00
https://www.sendspace.com/file/2w4rnt
Setting for libHEIF (x265)
// BPG uses CQP. It does not seem to be better though.
// param->rc.rateControlMode = X265_RC_CQP;
// param->rc.qp = (100 - encoder->quality)/2;
param->totalFrames = 1;
param->internalCsp = X265_CSP_I420;
api->param_parse(param, "info", "0");
api->param_parse(param, "limit-modes", "0");
api->param_parse(param, "limit-refs", "0");
api->param_parse(param, "wpp", "0");
api->param_parse(param, "rd", "6");
api->param_parse(param, "ctu", "64");
api->param_parse(param, "rskip", "0");
api->param_parse(param, "rect", "1");
api->param_parse(param, "amp", "1");
api->param_parse(param, "cu-lossless", "1");
api->param_parse(param, "aq-mode", "1");
api->param_parse(param, "rd-refine", "1");
api->param_parse(param, "psy-rd", "1.0");
api->param_parse(param, "psy-rdoq", "1.0");

[benwaggoner]

So you have to add the corrections for x265 stillimage:
p->rc.aqMode = 3;
p->rc.aqStrength = 1.0;
p->deblockingFilterTCOffset = -6;
p->deblockingFilterBetaOffset = 6;
p->psyRd = 2.0;
Is that enough?
https://x265.readthedocs.io/en/default/presets.html
PS What is wrong with aq-mode? For values three is always blocked.:D

I don't think there is any need to turn down deblocking so much. It can really help reduce bitrate with natural images. Maybe -1,-1.

I haven't poked at this since my last post a year ago, so I'm not sure if those would still be my recommendations as of 3.1.1, but it's probably in the ballpark.

That said, I think the energy around PBG has really moved towards HEIF. Having a JS HEIF parser/decoder would be tremendous, though. Adding HEIF parsing would be so delightful.