BPG Image Format (HEVC subset for browsers)

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