BPG - JPEG Quality At Half The Size - But Too Little, Too Late?

BPG, Better Portable Graphics, is a new, still image graphics format, based upon HEVC, High Efficiency Video Coding. Interestingly, HEVC is also what the much anticipated H.265 video format is based on.

Provides far better images at the same file size as JPEG, or the same quality at half the file size. The left half of the picture below is JPEG, the right is BPG, with similar file sizes:

Even though 50% is an impressive reduction, it's still not as good as typical H.264 reductions of 75% or more, mainly because it relies on intra-frame compression, like JPEG. And though 5 years ago or so it might have given H.264 a run for its money, at this point it's unlikely to gain traction as surveillance CODEC.

Especially if this is any indication of how superior HEVC is, and thereby foreshadowing the performance of next year's perennial favorite, H.265...


"Even though 50% is an impressive reduction, it's still not as good as typical H.264 reductions of 75% or more, mainly because it relies on intra-frame compression, like JPEG. And though 5 years ago or so it might have given H.264 a run for its money, at this point it's unlikely to gain traction as surveillance CODEC."

A picture with one still frame physically cannot use interframe compression, so I don't really understand your point.

H.264 uses both inter- and intra-frame compression, because it is used to compress video possessing sequential frames (GOP). BPG is limited to single photos only, so gross efficiency is not comparable to motion CODECs.

A picture with one still frame physically cannot use interframe compression, so I don't really understand your point.

Thanks! you are correct, I left out a step. The copy below should replace the first paragraph after the picture.

Before being useful for video surveillance of course, one would have to create a container for these still images, similar to MotionJPEG (M-JPEG) for JPEG. But just like M-JPEG, this new MotionBPG* (M-BPG), would be only a trivial convenience container, as it would merely sequence the display of BPG stills. Since there is no additional processing of these frames, the overall compression amount would remain the same as the stills, 50%.

Even though 50% is an impressive reduction, it's still not as good as typical H.264 reductions of 75% or more, mainly because it only relies on intra-frame compression, like M-JPEG. And though 5 years ago or so it might have given H.264 a run for its money, at this point it's unlikely to gain traction as a surveillance CODEC.

*A quick search for prior art of MotionBPG used as a format returned nothing, so therefore am I claiming it now, in the off chance anyone actually uses it. I'll split the profits with you...

H.265/HEVC = 'motionBPG'

From page 1 of your linked article

"BPG abandons it entirely, instead using a subset of a newer algorithm called High EfficiencyVideo Coding (HEVC), which is an open-source standard designed primarily for video compression. "

According to the article, BPG is a derivative of H.265/HEVC built for still images. There's no need for BPG in video.

Ok, you just talked your way off the M-BPG patent, buddy. ;)

There's no need for BPG in video.

As I stated before, I agree that M-BPG is unlikely to gain traction in surveillance, but that doesn't mean there's no need for M-BPG in surveillance at all. It is twice as efficient as M-JPEG, and therefore would do a superior job in those cases which M-JPEG is still 'needed'.

Which, for various reasons (some more valid than others), it continues to be. Take Mobotix for example. They might have a use for it, right? Perhaps you mean 'need' in the sense of 'need' if they know what they're doing. If so that's quite a bit more subjective, and implies you know better than them what they need. Maybe you do, I don't.

H.265/HEVC = 'MotionBPG'

Hardly. Key words from your quote: subset and derivative. The actual equation is more like H.265/HEVC = MotionBPG + Interframe Compression + ?

And as stated above, even with widespread availability of more efficient inter-frame CODECs, there is still some demand for intra-frame only compression, and may be for some time. Because even if the 'better' choice is usually H.264, it is not 'better' in every sense than M-JPEG.

In fact is better 'only' by the single but overwhelming virtue of it being ~4 times more efficient. It is considered worse in things like decoding cpu overhead, live view latency and corrupted frame sensitivity. So anything that slashes H.264's only advantage in half is noteworthy and possibly useful.

But my original point was not to make a case for BPG or M-BPG, but rather to marvel at the accomplishment, and to see it as an indicator of how powerful the full compliment of HEVC features may be, once widely available in our industry.

So you're asking me to agree that your totally imaginary, redundant codec is better than the real alternatives?

um, err...

Perhaps the voter who found this comment unhelpful would be nice enough to share their knowledge and explain what about the post was "way off topic" or "clearly wrong", so we can learn something at least... :)

Yeah, something like that. You see M-JPEG itself is but the most trivial and banal excuse for a CODEC around, so much so that I left it out of my OP.

It relies on extant JPEG decoders to do the heavy lifting, with its biggest function to indicate the sequence order and frame rate. M-BPG would be exactly the same only using BPG files and extant BPG decoders.

So it's totally something to sneeze at!

But in case you are still doubting, I whipped together this human M-BPG like decoder (beta), to illustrate. Notice how the sequence is enforced by the clip and the frame-rate delivered by the admittedly uneven thumbing:

Eh, maybe on second thought...