BPG Image Format (HEVC subset for browsers)

[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.