The discussion of image compression formats based on the H.265 codec

[birdie]

I heard that H.265 is a lot more efficient at coding static images than WebP, JPEG and even JPEG2000.

Is anyone working on a library/format for encoding/decoding images based on this compression standard?

Edit Saturday 06 December 2014: the first implementation has arrived, see http://bellard.org/bpg/.

[hajj_3]

i doubt anyone is. It is very difficult to get an image format used by others, hence why no-one is using webp, jpeg2000 or microsoft's format. Making another new one instead of just using WebP would be pretty pointless really, especially as there might be royalties needed for it unlike webp.

[xooyoozoo]

I think the folks pushing the format are trying to wait until HEVC video has established itself for a bit before moving forward. However, it's also hard to say what an HEVC image format would bring, as space constraints aren't really as imposing for pictures. At the very least, universal compatibility becomes much more important in this situation.

Making another new one instead of just using WebP would be pretty pointless really

I honestly fear WebP has trivialized itself by its insistence on adding new, bitstream-changing features without changing the file extension or product branding. Politics aside, Adobe/Apple/Microsoft/etc have plenty of reasons to refuse to support a pseudo-standard lacking a reference decoder carved in stone, which effectively makes it a perpetually moving target. In contrast, JPEG has remained unchanging for two decades.

Bringing the discussion back to HEVC, I also don't get why they made the HEVC image profile before the release of the range extensions. For now, features may be just as appealing as compression.

[pieter3d]

Bringing the discussion back to HEVC, I also don't get why they made the HEVC image profile before the release of the range extensions. For now, features may be just as appealing as compression.

The idea is to jump start supporting this in cameras etc. It also makes sense if you have a cellphone with a hardware HEVC encoder for videos, you can just reuse that logic for the stills.

[robertcollier4]

Seems is being pushed by Motorola:
PC World: HEVC video compression halves bitrate, keeps quality the same (Apr 8, 2013)
http://www.pcworld.com/article/2033462/hevc-video-compression-halves-bitrate-keeps-quality-the-same.html (http://www.pcworld.com/article/2033462/hevc-video-compression-halves-bitrate-keeps-quality-the-same.html)

>>> “Since it will take half the bit rate for similar quality, HEVC can be used for many different applications that are not feasible today or very expensive,” said Ajay Luthra vice president of advanced technologies for Motorola Mobility at the NAB Show in Las Vegas.
>>> “If you go on the lower side you can do streaming video,” he said. “For example, you can do 720p [video at 30 frames per second] at around 1.5mbps.” That’s half the bit rate that video usually consumes.
>>> At its booth at NAB Motorola Mobility showed two tablets, one with video encoded using H.264 and the other with video encoded using H.265. The very slight difference in quality favored the new standard; it looked clear and less pixilated.
>>> The standard is still being finalized, but HEVC should be in use early next year.

[posdnya]

HEVC used very sophisticated method for Intra-prediction - when blocks are predicted from their neighbours.
This is decoded picture:
http://forum.doom9.org/attachment.php?attachmentid=13400&stc=1&d=1365602501
This is what was prdicted, each block is predicted from four neighbours - left, upper-left, top and top-right:
http://forum.doom9.org/attachment.php?attachmentid=13401&stc=1&d=1365602501
and this is residual - difference between decoded and predicted, which was really compressed:
http://forum.doom9.org/attachment.php?attachmentid=13402&stc=1&d=1365602501

You may see that there is much less data to encode in residual. If you'll compress it by JPEG with the same quality, than file size of decoded and residual will differs more then twice.
There is also much better arithmetic encoding and postprocessing to avoid block and ringing effects.
This is basic idea why still picture compression with HEVC will give approx three times smaller file at the same visual quality than JPEG.

[foxyshadis]

HEVC used very sophisticated method for Intra-prediction - when blocks are predicted from their neighbours.
This is decoded picture:
http://forum.doom9.org/attachment.php?attachmentid=13400&stc=1&d=1365602501
This is what was prdicted, each block is predicted from four neighbours - left, upper-left, top and top-right:
http://forum.doom9.org/attachment.php?attachmentid=13401&stc=1&d=1365602501
and this is residual - difference between decoded and predicted, which was really compressed:
http://forum.doom9.org/attachment.php?attachmentid=13402&stc=1&d=1365602501

You may see that there is much less data to encode in residual. If you'll compress it by JPEG with the same quality, than file size of decoded and residual will differs more then twice.
There is also much better arithmetic encoding and postprocessing to avoid block and ringing effects.
This is basic idea why still picture compression with HEVC will give approx three times smaller file at the same visual quality than JPEG.

Wow, those predicted & residual images are awesome. The predictions are so much better than what AVC Intra could ever do. How did you generate the image? A custom decoder, or stripping residual bits from the bitstream? I've been considering creating a GUI encoder that could create optimal prediction in the base layer, then let the user adjust residual as the "quality" factor, as a fast mode so that encoding goes much more quickly. The prediction would become steadily lower quality as the base blocks become worse, but I think it has promise, if I could separate the two parts.

Can't wait for range extensions to be formalized.

[mariush]

The only way I see a new still image format become popular would be if it's the only one available in digital cameras besides raw formats.

If a new DSLR camera comes with hardware HEVC encoder chip, it would be a no-brainer to reuse the functionality, provided the chip would be capable of encoding more than 1920x1080 (afaik HEVC supports up to 8,192×4,320) and it's not so optimized as to only handle motion video at some crappy encoding settings.

[posdnya]

How did you generate the image?

It were screenshots from Elecard HEVC Analyzer. Free evaluarion available here:
http://www.elecard.com/en/products/professional/analysis/hevc-analyzer.html

[Parabola]

It looks like posdnya's screenshots were from a bitstream encoded using tiles. You have three grey blocks top, left and centre where prediction is unavailable. So I think HEVC intra prediction can be even better than we see here. It really is impressive.

For best HEVC compression performance, don't use tiles unless you have to... they're designed to make parallel encodes easier at some small quality penalty. I appreciate that this is just a sample and it is probably a sequence to demonstrate the analyzer's capabilities.

[pieter3d]

It looks like posdnya's screenshots were from a bitstream encoded using tiles. You have three grey blocks top, left and centre where prediction is unavailable. So I think HEVC intra prediction can be even better than we see here. It really is impressive.

For best HEVC compression performance, don't use tiles unless you have to... they're designed to make parallel encodes easier at some small quality penalty. I appreciate that this is just a sample and it is probably a sequence to demonstrate the analyzer's capabilities.

Instead, wavefront should be used for parallel encode/decode without the coding penalty.

posdnya, do you have the compressed image available somewhere? I have access to a nice analysis tool that I can report some stats from.

[pieter3d]

The only way I see a new still image format become popular would be if it's the only one available in digital cameras besides raw formats.

If a new DSLR camera comes with hardware HEVC encoder chip, it would be a no-brainer to reuse the functionality, provided the chip would be capable of encoding more than 1920x1080 (afaik HEVC supports up to 8,192×4,320) and it's not so optimized as to only handle motion video at some crappy encoding settings.

The spec has levels defined for 8k pictures, but there isn't really an actual limit. It is all about what you design your hardware for. For example, using 64x64 CTBs, you will need at least a 7-bit X/Y CTB counter to handle 8k.

[Parabola]

Instead, wavefront should be used for parallel encode/decode without the coding penalty.

HEVC's WPP (Wavefront Parallel Processing) tools also come with a small performance downside - the CABAC encoder only "learns" probabilities from a narrow strip of CTBs on the left-hand side of the picture. Without WPP, CABAC adapts over the whole picture.

[pieter3d]

HEVC's WPP (Wavefront Parallel Processing) tools also come with a small performance downside - the CABAC encoder only "learns" probabilities from a narrow strip of CTBs on the left-hand side of the picture. Without WPP, CABAC adapts over the whole picture.

Not quite. Think of it this way: When jumping to a new row, normally you are using probabilities left over from the far side of the picture, which will typically have different characteristics. With wavefront, each row starts with spatially local probabilities, so it learns in a 2D fashion.

[Parabola]

You're right. With WPP, you learn in an 'L' shape to current CTB. Without WPP you learn in a raster 'Z' over whole picture up to current CTB. I guess merits of each approach depend on the "half-life" of the CABAC probabilities which I have not studied.

I can't find the document now (can you?) but I do seem to remember reading about a small BD rate penalty due to WPP. Perhaps only 2% or so but when you're trying to squeeze every last drop out of an encoder, that's a pretty big deal.

[pieter3d]

Try this link (http://phenix.int-evry.fr/jct/doc_end_user/documents/5_Geneva/wg11/JCTVC-E196-v4.zip). Of course that is with really early HM software, so it is kind of stale data. Really the only entropy coding hit introduced by WPP is the bits spent on coding the entry points. Might be interesting to run some WPP on/off experiments with HM-10.0

[Cheungxin]

i doubt anyone is. It is very difficult to get an image (http://www.rasteredge.com/solutions/image-compressing/) format used by others, hence why no-one is using webp, jpeg2000 or microsoft's format. Making another new one instead of just using WebP would be pretty pointless really, especially as there might be royalties needed for it unlike webp.

I'm with you. I'm using JPEG image compression (http://www.rasteredge.com/dotnet-imaging/image-compression/).
Not familiar with High Efficiency Video Coding (HEVC), a video compression standard.

[birdie]

Actually it has arrived:

http://bellard.org/bpg/

It sounds nice in theory, however take for instance Bellard's own example at http://bellard.org/bpg/lena.html :

The first three compression ratios clearly favour H.265.

However the very last image has more details in JPEG than in H.265 (look closely at the woman's shoulder and back - JPEG resolves more details here than H.265 which makes this part of the image blurry).

[mandarinka]

That could probably be averted by proper rate-control, though (psychovisual RDO etc). The format itself should definitely be more capable, so there isn't really a reason why JPEG would have inherent advantage at higher rates.

BPG has its own thread (http://forum.doom9.org/showthread.php?t=171505) in the HEVC subforum already btw (where this this thread should probably belong to as well).