H.264 for Image coding

[sharp81]

Hallo Everybody,

As I was searching for information on H.264 , just the intra prediction mode I came across this informative website. I found it very interesting to figure out how the whole process is done. I am trying to learn and maybe implement a part of the H.264 standard. I am interested only in the intra prediction ie I-frames and I want to use it for still images rather than videos. The idea is to check performance of various predictor modes and to select the best possible predictor. And after that I want to compare the blockwise and pointwise compressions. Since I am beginner in the field of Digital Image Processing, I want to first try to do a very simple implementation on this. I was checking the block prediction algorithm but I dont quite understand it works. Could you give me some ideas how to proceed with a complete system design and maybe some coding help? I am considering starting with only 4x4 block implementation

Also every paper mentions using a reference pixels on top and left to predict the block. But how do I select the reference pixels?

Thanks in advance.

[sauvage78]

Technically I can't help but your post reminds me of this:

http://www.bilsen.com/index.htm?http://www.bilsen.com/aic/

If you don't already know about this, maybe you'll find some interesting info there.

[jmartinr]

Have you read this: http://forum.doom9.org/showthread.php?p=1299497#post1299497?

[sharp81]

yeah, I have read that forum post. But I think just using the intra prediction from H.264 shld give better results than jpeg. Which I dont know yet.

So I want to check if the PSNR and entropy is better.

This page on Advanced Image Coding is very nice and interesting. Thanks for the link. But I would be glad if somebody could explain how I could go abt the implementation.

Thanks.

[Dark Shikari]

yeah, I have read that forum post. But I think just using the intra prediction from H.264 shld give better results than jpeg. Which I dont know yet.Yes you do. It does.

Feel free to use x264 to confirm if you want ;)

[sharp81]

Hi Dark Shikari, Is there a documentation on the source cod of x264? Its very hard to understand a complete code and algorithm without documentation.

[Dark Shikari]

Hi Dark Shikari, Is there a documentation on the source cod of x264? Its very hard to understand a complete code and algorithm without documentation.I didn't say to use the source. Just x264 with --tune psnr --preset placebo --frames 1 --crf X, for some value of X, is sufficient to generate your x264-compressed, psnr-optimized images.

For psy optimization, replace psnr with "stillimage".

[sharp81]

is it possible to obtain some explanation on the source code? So that I know how it is working behind the scenes.

[Dark Shikari]

is it possible to obtain some explanation on the source code? So that I know how it is working behind the scenes.Hop on the x264 IRC on Freenode and ask questions.

[sharp81]

The bilsen project looks interesting. Unfortunately I dont have a delhi to compile it. Is there anything similar available written in C/C++?

[cyberbeing]

yeah, I have read that forum post. But I think just using the intra prediction from H.264 shld give better results than jpeg. Which I dont know yet.Yes you do. It does.

Feel free to use x264 to confirm if you want ;)

http://forum.doom9.org/showthread.php?t=142910
Here was a comparison done between JPEG, JPEG2000, HDPhoto, and x264 back in 2008. It was better than JPEG back then, so it should be even better today.

[sharp81]

i guessed so that it must be definitely better than jpeg. Becoz the prediction algorithm is definitely better. Here the dct is also done on the difference picture rather than on the picture itself like in jpeg.

What I found out about the Intra coding is finding the pixel values from reference is done by intrapolation and extrapolation and taking the weighted average. But I still am not able to get the math here. Is it possible for someone to explain the whole math.

Thanks

[sharp81]

does the Jpeg2000 use the same prediction method as the H.264 and only the part where it differs is it uses DWT instead of DCT. Is that true?

[Dark Shikari]

does the Jpeg2000 use the same prediction method as the H.264 and only the part where it differs is it uses DWT instead of DCT. Is that true?No; the prediction methods in H.264 are mutually incompatible with large wavelet transforms.

[sharp81]

from what i understand in Jpeg there is no prediction and instead DCT is directly done on the picture which is divided into blocks. How exactly does Jpeg2000 work and how is the H.264 intra mode better than Jpeg2000. Is there a reference source code available?

[foxyshadis]

H.264 JM Reference Source Code (http://iphome.hhi.de/suehring/tml/)
JPEG2000 Reference Source Code (http://www.ece.uvic.ca/~mdadams/jasper/)

JPEG2000 has no block or pixel prediction. It's a direct wavelet transform of the source, same as JPEG is a direct DCT transform. The primary gain at low bitrates comes from the LL band of the wavelet transform being recursively transformed, and selectively throwing away higher resolution information.

H.264 can predict a block based on DC, up, left, up-left, up-right, and even down-left. Here's a very good h.264 intra primer (http://www.vcodex.com/files/h264_intrapred.pdf) (pdf) you could look at.

[sharp81]

Thanks a lot for the info. Can you tell me which are the C files, that would be interesting just to consider the intra prediction from the JM software. What's the major difference between this JM software and x264?

[Underground78]

What's the major difference between this JM software and x264?

JM is more something like a proof of concept than an encoder you can use for real daily encoding ... In fact, it is slow as hell and x264 probably has some black magic quality optimizations JM does not have ... But JM source code is probably easier to understand.

[Dark Shikari]

But JM source code is probably easier to understand.I doubt it. It's practically commentless and has no IRC channel where one can easily talk to the people who wrote it.

[foxyshadis]

I found ffmpeg clear and reasonably concise when I was implementing h.264 parsing in python, trying to minimize outside dependencies. I just used x264 directly for encoding, no way I could compete with that.

[nakTT]

Hi,

Can x264 be used with MeGUI for this purpose?

[Blue_MiSfit]

Sure, just make an AviSynth script that loads your image somehow, and make a custom x264 preset using --tune stillimage and add --frames 1 to the custom CLI options. Should work fine..

Derek

[sharp81]

I tried compiling the JM software to check the results , but I dont quite understand it .... any documentation on this will be of great help. I am interested in trying to use only the intra prediction part of the JM software since i am trying to work only on images

[sharp81]

is there any very simple available intra prediction source code? it doesnt have to do all the functions just the basic ones. All i want is to check the different modes on a picture

[iwod]

Last time we checked, ( Two years ago ) the orders goes like this

Jpeg HD ( Jpeg XR, HD Photo , or what ever name its has previously )
x264
Snow
Jpeg 2000

Of coz now x264 has improved a lot since then, x264 should be the best.

Unless Flash get open sourced and implemented in every browsers, there is no way to use x264 for images.

[nakTT]

Sure, just make an AviSynth script that loads your image somehow, and make a custom x264 preset using --tune stillimage and add --frames 1 to the custom CLI options. Should work fine..

Derek
Thanks for the reply. But I'm a noob, can I do it using MeGUI instead?

:thanks:

[AlekseiV]

Thanks for the reply. But I'm a noob, can I do it using MeGUI instead?

:thanks:That is using MeGUI.

[nakTT]

That is using MeGUI.
Thanks for the reply. But as a noob, I would like to use GUI instead.

:thanks:

[iwod]

Continuing on this Topic. Are there anything we could do for x264 to specifically improve quality for image coding.

[J_Darnley]

--tune stillimage

[knutinh]

i guessed so that it must be definitely better than jpeg. Becoz the prediction algorithm is definitely better. Here the dct is also done on the difference picture rather than on the picture itself like in jpeg.

When you are doing intra-only, surely there are no difference picture?

-k

[iwod]

Are there any reason why h.264 High Profile images are not used widely. When Flash and Silverlight literally cover more then 90% of the world's Internet connected PC.

[iwod]

No one?

[Blue_MiSfit]

Probably overhead... I'd bet resource utilization to display a 1024x768 jpg is a lot lower than displaying a same sized image coded in h.264 HP and displayed in Flash or Silverlight. Plus those players don't work everywhere :(

DP

[iwod]

Google just released their image format based on WebM ( VP8 )

Pretty sad to see it since H.264 could had a head start.

http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html

[Dark Shikari]

Google just released their image format based on WebM ( VP8 )

Pretty sad to see it since H.264 could had a head start.

http://blog.chromium.org/2010/09/webp-new-image-format-for-web.htmlConsidering it seems to be worse than JPEG (http://x264dev.multimedia.cx/?p=541), I doubt it's going much of anywhere.

[royia]

Just use JPEG XR.

[iwod]

Just use JPEG XR.

Which isn't supported anywhere??:confused::confused:

[royia]

IE9, Windows Vista, Windows 7.
In few months it will be over 50% of the market.

[kidjan]

Considering it seems to be worse than JPEG (http://x264dev.multimedia.cx/?p=541), I doubt it's going much of anywhere.

Maybe in your comparison, but you tested a single image that lacks gradients entirely. Consider this (http://ubermotive.com/index.php?option=com_content&view=article&id=3&Itemid=3) and this (http://englishhard.com/2010/10/01/real-world-analysis-of-googles-webp-versus-jpg/). In particular, I find the first example to be dramatically better, especially around the powerlines where the JPEG artifacting is particularly noisy.

Not saying you're wrong, but...I think your analysis could have been more rigorous.

[Dark Shikari]

Maybe in your comparison, but you tested a single image that lacks gradients entirely. Consider this (http://ubermotive.com/index.php?option=com_content&view=article&id=3&Itemid=3) and this (http://englishhard.com/2010/10/01/real-world-analysis-of-googles-webp-versus-jpg/). In particular, I find the first example to be dramatically better, especially around the powerlines where the JPEG artifacting is particularly noisy.

Not saying you're wrong, but...I think your analysis could have been more rigorous.You can easily apply a deblocking postfilter to JPEG if the only problem is blocking. This is far easier than switching image formats.

[J_Darnley]

IE9, Windows Vista, Windows 7.
In few months it will be over 50% of the market.

The last estimate I heard is that this will be another year away: http://www.conceivablytech.com/3227/business/66-of-all-windows-users-still-use-windows-xp/

[royia]

Let's talk about the "Home" segment.
Those big businesses doesn't care about "Images".

I think among the Home Users / Internet Users Windows 7 / Vista is close to 50%.
IE9 will get a major market share (More than 20%) in no more than 3-4 Months after its release.

JPEG XR will have enough users.
All needed is Web Sites to use it.

I hope it will happen.
It looks like a good format and free.

[Midzuki]

Microsoft themselves could start by creating and distributing a free (AND open-source) JPEG-XR "Netscapy" plugin for FireFox, Seamonkey, K-Meleon, and Opera of course. :)

[iwod]

If Jpeg XR is opened up without patents problem around it, Microsoft has promised to do so for 2 years but we are not yet heard anything

I bet H.264 stilled image will still look better then Jpeg XR. And It is already supported by 90+% of the web, ( Flash ).

[royia]

I think that if you take no x264 encoder for the stills image JPEG XR will be at least on par.
Since it is an open standard, I don't see a problem that the psy optimizations applied on it as well.

The big thing about it is "Open Standard".
No need to worry about paying anyone etc...

[Midzuki]

"Open-standard" doesn't mean that a "sufficient" quantity of capable developers will be ever interested in JPEG XR, unfortunately. For example, the PDF specifications have been an "open standard" for ages, however I still haven't seen any non-Adobe application that seriously rivals Adobe Acrobat itself [and no, I am not talking about eye-candies (QuickTime support) nor bloated annoyances (Javascript, forms, WebBuy, whatever)].

[Episodio1]

MIDZUKI, well, PDF has been really opened couple years ago: "...was first published by Adobe Systems in 1993, and it turned into an open standard through ISO 320001:2008 only two years ago (PDF 1.7)."

And Office 2007 might beat ADobe suite, according to review at: http://www.tomshardware.com/reviews/adobe (http://www.tomshardware.com/reviews/adobe-acrobat-pdf-microsoft-office,2702-2.html)

[Midzuki]

^@ Episodio1:

www d0t adobe d0t com/pdf/release_pdf_faq.html says:

The PDF specification has been publicly available since 1993.

besides,

Ever since Adobe first published the PDF specification in 1993, it has been provided without licensing fees. This continues with the PDF version 1.7 specification.

[lithoc]

I think that if you take no x264 encoder for the stills image JPEG XR will be at least on par.
Since it is an open standard, I don't see a problem that the psy optimizations applied on it as well.


Now with x264 supporting 10bit color , there's more reason to use it, we can get better quality picture with higher compression or loseless mode.

I hope x264 will support 4:2:2 and 4:4:4 then it will become serious JPG replacement.

I do agree psy optimizations should be use wisely. The psy optimizations can easily trick our mind in moving pictures but not still picture.