Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

H.264 is Magic (2016)

sidbala.com

Post reply on HN
Print view View original

71–80 of 229 posts

Re: H.264 is Magic (2016)

#71

Post by dlp211 »

tmp65535 wrote: post #10

Fabrice Bellard's BPG image format uses H.265's keyframe compressor: https://bellard.org/bpg/ Here is a side-by-side visual comparison: http://xooyoozoo.github.io/yolo-octo-bugfixes/#ballet-exerci... Amazing. I ported his BPG decoder to Android ARM for a pornographic app. See my comment history for details. It reduced data transfer by more than 60%.

This was fascinating. I changed to JPEG large vs BPG small and they are almost indistinguishable. JPEG small vs BPG small wasn't even close (JPEG being much worst).

Re: H.264 is Magic (2016)

#72

Post by FrenchAmerican »

Cthulhu_ wrote: post #67
yboris wrote: post #49

PSA: For images, there's a finally successor to jpeg: JPEG XL (.jxl) - has lossy and lossless mode; is progressive (you can download just the first parts of the bitstream to get a lower resolution image; and other benefits!) https://jpegxl.info/

"Your browser does not support JPEG XL"; I'm sure it's cool technology but whoever is behind it needs to hire developers and advocates to push code to Webkit / Blink to add support for it, else it won't get mainstream adoption.

I have read that both Chrome and Firefox now support it if one enable the proper option in the about:config page (and its Chrome equivalent, but I avoid Chrome by principle).

It's in my to do-list in the coming weeks, I have not verified this yet.

Re: H.264 is Magic (2016)

#73

Post by memco »

One thing I was curious about is how the PNG would compare after running it through an optimizer since that would be a more fair comparison since the H.264 encoding does optimize. Even so, I bet the H.264 would fare well. I did an experiment with using single-frame H.264 instead of images on a site: I think it’s a viable technique but didn’t have time to flesh it out in full. If you have some kind of asset pipeline for a site it’s not really more work to encode and the HTML is now a video tag with no player controls so isn’t a ton of work client side either. Would love to explore that more at some point.

Re: H.264 is Magic (2016)

#74

Post by Aachen »

FrenchAmerican wrote: post #72
Cthulhu_ wrote: post #67

Earlier quoted context omitted.

"Your browser does not support JPEG XL"; I'm sure it's cool technology but whoever is behind it needs to hire developers and advocates to push code to Webkit / Blink to add support for it, else it won't get mainstream adoption.

I have read that both Chrome and Firefox now support it if one enable the proper option in the about:config page (and its Chrome equivalent, but I avoid Chrome by principle). It's in my to do-list in the coming weeks, I have not verified this yet.

for those that want to try: set image.jxl.enabled and restart the browser (via https://jpegxl.io/tutorials/firefox/#firefoxjpegxltutorial)

Re: H.264 is Magic (2016)

#75

Post by oefrha »

Cthulhu_ wrote: post #65
criddell wrote: post #56

Earlier quoted context omitted.

> We should all be meticulous about compartmentalizing our online identity. I disagree and I believe the HN guidelines do as well: > Throwaway accounts are ok for sensitive information, but please don't create accounts routinely. HN is a community—users should have an identity that others can relate to.

Do you believe the person posting is guilty of "creating accounts routinely"? Or just one for this app and one 'main' account? I don't see an issue with creating multiple accounts as long as they're not used for abuse, e.g. spam or trolling, or cause technical issues, e.g. creating millions of accounts. I mean if done right you'd never know or care.

This person is totally guilty of violating the rule on self promotion:

> Please don't use HN primarily for promotion. It's ok to post your own stuff occasionally, but the primary use of the site should be for curiosity.

Promoting your app in every single otherwise okay comment is certainly distasteful.

Re: H.264 is Magic (2016)

#76

Post by aembleton »

pbronez wrote: post #29
tmp65535 wrote: post #10

Fabrice Bellard's BPG image format uses H.265's keyframe compressor: https://bellard.org/bpg/ Here is a side-by-side visual comparison: http://xooyoozoo.github.io/yolo-octo-bugfixes/#ballet-exerci... Amazing. I ported his BPG decoder to Android ARM for a pornographic app. See my comment history for details. It reduced data transfer by more than 60%.

Wow that comparison is really cool. Looking at BPG vs original, you can see some loss of fine detail as the file size cranks down, but you can get an excellent reproduction with an order of magnitude less storage. Seems like BPG is smoothing the image a bit. For example, the space shuttle image has film grain in the sky, but BPG smooths this away. Significantly better than JPEG at small file sizes... BPG eliminates t…

If you set BPG to a large file size, you still get some of the noise in the sky of the Endeavor photo. But this is 1/20 the size of the original image which is incredible.

Re: H.264 is Magic (2016)

#77

Post by ollybee »

There was once a blog titled "Diary Of An x264 Developer" that gave some interesting detail of how h264 worked and the and the x264 implementation. It's still available on via the internet archive.

Re: H.264 is Magic (2016)

#78

Post by sxg »

jstanley wrote: post #21

Does anything interesting happen if you take the frequency domain representation of an image, represent the frequency domain as an image itself, and compress that with some sort of image compression? For example, encode the frequency domain representation as a low quality JPEG, and then undo the steps to turn it back into the "original". How do the JPEG artifacts on the frequency domain manifest in the resulting imag…

Your idea is analogous to what’s done in MRI image reconstruction. “Images” are actually obtained in the frequency domain, but there are various undersampling strategies to accelerate the frequency domain data acquisition. These are then reconstructed into actual images with the inverse FFT.

Re: H.264 is Magic (2016)

#79

Post by tmp65535 »

oefrha wrote: post #75
Cthulhu_ wrote: post #65

Earlier quoted context omitted.

Do you believe the person posting is guilty of "creating accounts routinely"? Or just one for this app and one 'main' account? I don't see an issue with creating multiple accounts as long as they're not used for abuse, e.g. spam or trolling, or cause technical issues, e.g. creating millions of accounts. I mean if done right you'd never know or care.

This person is totally guilty of violating the rule on self promotion: > Please don't use HN primarily for promotion. It's ok to post your own stuff occasionally, but the primary use of the site should be for curiosity. Promoting your app in every single otherwise okay comment is certainly distasteful.

Listen friend, I'm using it as a concrete example of a technology in every case.

Today I'm using it as a concrete example of H.265 (BPG) as an astonishingly good alternative to JPEG in applications where you control the encoder and decoder.

Re: H.264 is Magic (2016)

#80

Post by bob1029 »

isaak wrote: post #17

Almost all of those encoding concepts mentioned are not introduced with H.264, but much earlier with MPEG-2 in the early 90's https://en.wikipedia.org/wiki/MPEG-2

MPEG-2 and JPEG are very similar in philosophy as well.

JPEG in particular is still my favorite image encoding technique. Mostly because of how fast it is relative to the competition.

Post reply on HN