BPG Image Format (HEVC subset for browsers)

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