Why nobody seems to get this idea?
H.264 is already time tested, available almost everywhere (some browsers and players need to enable Hi444PP profile though), patents are gonna expire, and it has better than JPEG efficiency if used properly (i.e. -tune stillimage).
and the same question about VP9.
And instead of the gay apple HEIF thing, H.264 or VP9 can already be decoded pretty much anywhere.
Other urls found in this thread:
wyohknott.github.io
bellard.org
flif.info
twitter.com
yes but does it respect the user’s freedom?
You need to show proof of concept.
It's easy:
1: get a big lossless photo (from a camera raw, for example)
2: compress it with mozjpeg (the only state of the art jpeg encoder which also has practical performance) with quality 80 or 90 or something in between
3: compress the same image with latest stable ffmpeg (-c:v libx264 -preset veryslow -tune stillimage), find a crf value which gives the same file size as the jpeg produced in step 2
4: uncompress the "video" frame back with ffmpeg (… -pix_fmt rgb24 *.png)
5: visually compare the amount of distortion introduced by compression in both cases
JPEG will have more "ringing" noise near sharp edges and more visible "blocking" artifacts, H.264 will look okay everywhere while also not losing tiny details.
if you want I may upload some shit in next few days.
There is simply not enough gain to warrant all the tediousness of ditching jpeg. We would already be using webp, otherwise.
Now with AV1, the gains are simply to big.
WEBP is worse than JPEG for lossy coding, actually.
Because of the stupid decision to make chroma subsampling mandatory.
…and yeah, I hope that at least with AV1, it will finally spawn an image format which will finally replace jpeg eventually.
Yeah I meant you need to show a practical example proving it.
You can already make 1-frame VP9 WEBMs compressed better than JPEGs. VP9>>h264
VP9 is about the same efficiency if we are interested in near-transparent quality levels, and it's a LOT slower to encode because there's no free and fast implementation (unlike H.264 which has got x264)
(source: first hand experiments)
Use your eyes, m8. x264 is as good as it is because devs used their eyes instead of PSNR/SSIM.
It's better than jpeg. A lot. It's just not a superset.
VP9 intra is a lot better than x264. VP9 is (was since row-mt landed) slow because of shitty multithreading. Doesn't really matter for intra encoding.
By the way, here's a good comparison:
wyohknott.github.io
As you can see, VP9 is really good.
Why have image formats at all? Why not just asm.js, emscripten, and canvas?
Can't wait for FLIF.
Look at
It's shit for lossy, and I doubt it's better than AV1/H265 in lossless mode.
Because JavaScript is cancer.
FLIF stands for "Free Lossless Image Format". Of course it's shit for lossy.
Well, anyway, just look at the amount of money, time and manpower put into video codecs. I'll put my money on these.
Don't tell me that it needs ffmpeg as hard dependency in order to view image.
this shit site doesn't work without javascript
use your eyes dude.
some pictures already become visibly distorted just because of chroma subsampling. typical example are almost any tiny and sharp details of deep red color. this has been tested a lot of times already, it's trivial to find or repeat for yourself.
but of course if the target quality range is "shit tier" then WEBP's efficiency beats JPEG at it. because JPEG completely falls apart at some level and WEBP still shows something reasonable at that file size.
only the part which does the H.264 decoding
well on my machine it was about 2-3 times slower (with -speed 5) than x264 (-preset veryslow). And with default efficiency setting for VP9, I could not wait for the result of 12MP photo compression and had to kill it.
I was using latest stable build of ffmpeg.
Like jpeg, it's made pretty much for photos. Using it for flat art or screenshots gives visible artifacts.
I were talking about photos obviously.
But if your photos are all defocused, then WEBP is just fine, of course. Although it'd be more efficient to downscale them before encoding in that case.
now, this is some crop from a real photo.
original.png = crop straight from developed raw, without any prior lossy compression.
jpeg:
mozjpeg -q 90
webp:
cwebp -preset photo -sharp_yuv -m 6 -q 100 this is what should give max possible quality by their definition and also hardest compression given the same quality
WEBP file size = 747442 bytes
8ch doesn't allow attaching webp images so I am attaching decoded version ("webp at max quality.png") and you can easily repeat that if you think I made this image from something else.
WEBP obviously blurred the image, while JPEG is completely fine even though the JPEG file is even smaller.
H.264 is still patent encumbered, it's inferior to VP9 and also AV1 which is just around the corner, Google already tried and failed to push webp which works on the same principle, and FLIF already exists and is a superior format in every way.
amerifat detected
Ironically even "near lossless" WEBP mode does better than "regular" WEBP at max quality
(cwebp -near_lossless 10 -z 9)
it produces file size 677332 bytes and the result looks reasonable (not blurred) but it still has more visible difference from the original than the smaller JPEG file
WEBP fails mostly because its lossy mode is unsound (what's the point in having a lossy image codec which doesn't achieve transparency at ANY quality level, when even JPEG doesn't have that problem — if you jack up quality for JPEG, it may come arbitrarily close to the original)
source?
obviously false, if you take a look at the visual comparison
user, i don't disagree tha only allowing 4:2:2 (or 4:2:0, I don't know) is retarded, but you killer sample makes you look a little dumb.
Where you're right with your sample is that a codec that doesn't work on certain image types is indeed worthless.
Also, please don't spread FUD about the size:quality ratio. Webp is a LOT better than jpeg on "normal" pictures.
Which pictures are normal then?
this hardly has a value if, as we saw, it only works sometimes
sage bc. double post
can you tell if this photo, for example, is "normal"?
before you try encoding it with chroma subsampling
if you simply look at it, it looks just like any other, doesn't it? (I mean from technical point of view)
do you always carefully check the output when you compress your photos?
if after a while you suddenly realize that your photos are butchered too much by compression, it really sucks — and even more if you don't have the unmodified image anymore
m8, it's more than "sometimes". Still worthless if the codec is supposed to be general purpose.
buy used 4TB HGST, they're everywhere
But jpeg quality 100 is a lot better than png while being almost the same.
There's lossless jpeg.
hoarding is easier than checking whether images are artificial or photos before choosing a file format and compressing
(heil)
It has been hard enough convincing people to use JPEG2000. Which should be a little similar to the keyframe compression in H.264
It's better to use lossless jp2 at this point.
PNG was introduced at the right time. WebP is great, but it's too little, way too late. The only way to cuck JPEG is to have an open sourced codec with everyone from hardware manufactures to software developers on board. It wont happen any other way.
webp is vp8 like webm. not sure if webp can vp9 now or if wbmp is the same. browsers don't support them though(IIRC) like apng or iccv4 images (literally no image viewer can iccv4 at this point)
H.264 doesn't use wavelets. Also JPEG2000 sucks in practice, as seen on that page posted earlier ITT.
It can't.
It was outdoors, just with unusual lighting.
And is this photo taken in a red light room? I think it's fairly regular (the only irregular things about it is that it's not blurred as fuck, and it actually got some colored details, which is common in real life)
this is a different, incompatible format, at least in practice. (the same way as arithmetic coded JPEGs are standard but no common software can read them, this sucks btw)
also lossless webp is bretty good at lossless compression. but the same problem, most software can't read it, and the gain is not that big (because, unlike with lossy formats, if you later recompress from 1 lossless format to other lossless format, you don't lose data)
therefore popularizing a more efficient lossy image format is more important — because the net damage inflicted by inferior lossy formats is harder to undo.
if you travel/relocate often, then carrying fat drives with you every time kind of sucks. plus as we know, officers at airports might become interested in its contents.
and this makes harder to make distributed backups if your stuff is just too big.
are you implying that if you take a photo, it still might actually be artificial image in disguise? like, a sabotage act by the photo camera? hmmm, really interesting…
...
I stand corrected.
OP's gypsy broken grammar is a strong sign that they don't know software patents render this a non-starter, yes.
Anytime you see video that looks like it had Vaseline smeared over the lens, it's a wavelet codec. It might look good on paper, but it's shit in practice.
Which video codec are you talking about?
americuck spotted
Unless there's some ICC shit happening there, the jpeg one is significantly lighter.
All of them are sRGB. Perhaps you use a buggy JPEG decoder. (some cannot handle progressive jpeg fully correctly) I can upload PNG conversion from JPEG if you need it.
…nope, looks like some ICC shit.
they look different in browser, but the same in image viewer.
let me figure out what the fuck happened…
I figured it out.
JPEG file was without any color profile at all, and for some reason browsers get mad at files without any color profile (apparently not all srgb profiles are created equal).
I could not find the exact sRGB profile which I can attach to it to make it look the same, so instead I am uploading the other two pictures with color profile removed. (`convert … -strip …`)
As you can see, the problem was not in the actual pixel values…
OP here. After testing with some other "regular" images and using dssim for objective quality comparison, I've found that mozjpeg (-q 90,86) actually beats x264 and libvpx-vp9, and only loses to x265, but x265 gets "only" 22.5% size reduction at the same quality (not 50% like claimed)
ffmpeg params for x265 compression were "-r 0.1 -i example.png -c:v libx265 -crf 22.6 -preset veryslow -pix_fmt yuv444p …" (22.6 was the closest match to mozjpeg's q 90 while being strictly better quality)
correct me if there are more efficient settings for single image compression with x265.
so, maybe that was not a good idea after all and we should wait for HEIF mass adoption which AFAIK is basically the same as H.265 for single image compression.
Speaking of image formats, I wish we could ditch PNG and move to FLIF. I've ran a few tests and FLIF gives signifigantly smaller files than even zopflipng-compressed PNG images, while still being lossless and much faster than zopflipng. That's not even trying to get the smallest FLIF that I can, just the default encoding options. It's a shame that the only thing I know that supports it is the viewer that comes with the FLIF converter.
Here's a quick example:
the same can be said about WebP(lossless) as well. and FLIF presses better than it?
anyway, lossless formats are less of a drama because they can be converted one to another without losses, by definition. so if a new cool lossless format is held back for too long, it isn't doing as much damage.
Is that loss?
They have a comparison on their site: flif.info
No, it's lossless.
oh yeah, forgot it, I've seen that page before.
it's cool then. time to think about freezing the bitstream and pushing browser vendors to support it.
Never gonna happen, it's nih, so google will stick to shitty webp and mozilla will follow them as always.