[–]▶ No.825988>>826011 >>826069 >>826147 >>826235 >>826368 [Watch Thread][Show All Posts]
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.
▶ No.826006
yes but does it respect the user’s freedom?
▶ No.826011>>826017
>>825988 (OP)
You need to show proof of concept.
▶ No.826017>>826032
>>826011
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.
▶ No.826023>>826026 >>826027
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.
▶ No.826026>>826056
>>826023
>We would already be using webp, otherwise
WEBP is worse than JPEG for lossy coding, actually.
Because of the stupid decision to make chroma subsampling mandatory.
▶ No.826027
>>826023
…and yeah, I hope that at least with AV1, it will finally spawn an image format which will finally replace jpeg eventually.
▶ No.826032
>>826017
>if you want I may upload some shit in next few days.
Yeah I meant you need to show a practical example proving it.
▶ No.826035>>826039
You can already make 1-frame VP9 WEBMs compressed better than JPEGs. VP9>>h264
▶ No.826039>>826057
>>826035
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)
▶ No.826056>>826183
>>826026
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.
▶ No.826057>>826187
>>826039
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.
▶ No.826058>>826080 >>826170
By the way, here's a good comparison:
https://wyohknott.github.io/image-formats-comparison
As you can see, VP9 is really good.
▶ No.826061>>826089
Why have image formats at all? Why not just asm.js, emscripten, and canvas?
▶ No.826069>>826080
>>825988 (OP)
Can't wait for FLIF.
▶ No.826080>>826095
>>826069
Look at
>>826058
It's shit for lossy, and I doubt it's better than AV1/H265 in lossless mode.
▶ No.826089
>>826061
Because JavaScript is cancer.
▶ No.826095>>826132
>>826080
FLIF stands for "Free Lossless Image Format". Of course it's shit for lossy.
▶ No.826132
>>826095
Well, anyway, just look at the amount of money, time and manpower put into video codecs. I'll put my money on these.
▶ No.826147>>826187
>>825988 (OP)
Don't tell me that it needs ffmpeg as hard dependency in order to view image.
▶ No.826155
▶ No.826170
>>826058
this shit site doesn't work without javascript
▶ No.826183>>826192
>>826056
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.
▶ No.826187
>>826147
only the part which does the H.264 decoding
>>826057
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.
▶ No.826192>>826213 >>826228
>>826183
Like jpeg, it's made pretty much for photos. Using it for flat art or screenshots gives visible artifacts.
▶ No.826213>>826228
>>826192
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.
▶ No.826228>>826237 >>826281 >>827085
>>826213
>>826192
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.
▶ No.826235>>826236 >>826237 >>826242
>>825988 (OP)
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.
▶ No.826236>>826985
>>826235
>patents
amerifat detected
▶ No.826237
>>826228
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
>>826235
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)
▶ No.826242
>>826235
>AV1 is just around the corner
source?
>FLIF is a superior format in every way
obviously false, if you take a look at the visual comparison
▶ No.826281>>826288 >>826291 >>826303
>>826228
ANon, 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.
▶ No.826288
>>826281
Which pictures are normal then?
▶ No.826291>>826338
>>826281
>Webp is a LOT better than jpeg on "normal" pictures.
this hardly has a value if, as we saw, it only works sometimes
sage bc. double post
▶ No.826303>>826350 >>826553
>>826281
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
▶ No.826338>>826553
>>826291
>all photos are taken in a red light room
m8, it's more than "sometimes". Still worthless if the codec is supposed to be general purpose.
▶ No.826350>>826351 >>826558 >>826683
>>826303
>compressing your photos
buy used 4TB HGST, they're everywhere
▶ No.826351>>826362 >>826364
>>826350
But jpeg quality 100 is a lot better than png while being almost the same.
▶ No.826362>>826369 >>826555
>>826351
>almost
There's lossless jpeg.
▶ No.826364>>826559
>>826351
hoarding is easier than checking whether images are artificial or photos before choosing a file format and compressing
▶ No.826368>>826553
>>825988 (OP) (heil)
It has been hard enough convincing people to use JPEG2000. Which should be a little similar to the keyframe compression in H.264
> muh wavelets.
▶ No.826369
>>826362
It's better to use lossless jp2 at this point.
▶ No.826380
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.
▶ No.826392
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)
▶ No.826553>>826752
>>826368
H.264 doesn't use wavelets. Also JPEG2000 sucks in practice, as seen on that page posted earlier ITT.
>not sure if webp can vp9 now
It can't.
>>826338
It was outdoors, just with unusual lighting.
And is this >>826303 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)
▶ No.826555
>>826362
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.
▶ No.826558
>>826350
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.
▶ No.826559
>>826364
>hoarding is easier than checking whether images are artificial or photos before choosing a file format and compressing
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…
▶ No.826683
>>826350
<buy used 4TB HGST, they're everywhere
>implying I will ever buy big heavy loud 3.5" drive
>implying there is no need to care about efficiency because MUH JUST BUY 40TB
>implying the only thing that I store at my PC are photos
>implying those lossless huge images will fit on small backup drives
>implying I will be uploading that 4TB to internets to have internet backup
▶ No.826752
>>826553
>H.264 doesn't use wavelets
I stand corrected.
▶ No.826985>>827040
>>826236
OP's gypsy broken grammar is a strong sign that they don't know software patents render this a non-starter, yes.
▶ No.827000>>827023
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.
▶ No.827023
>>827000
Which video codec are you talking about?
▶ No.827040
>>826985
>lets cripple ourselves because muh patents
americuck spotted
▶ No.827085>>827142 >>827148
>>826228
Unless there's some ICC shit happening there, the jpeg one is significantly lighter.
▶ No.827142>>827148
>>827085
>>827117
…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…
▶ No.827148
>>827085
>>827142
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…
▶ No.835106
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.
▶ No.835128>>835157 >>835159 >>835173
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:
>bigass image.png: 6.5 MB
>bigass image.flif: 4.2 MB
▶ No.835157>>835208
>>835128
>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
the same can be said about WebP(lossless) as well. and FLIF presses better than it?
▶ No.835159
>>835128
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.
▶ No.835173>>835289
▶ No.835208>>835528
>>835157
>the same can be said about WebP(lossless) as well. and FLIF presses better than it?
They have a comparison on their site: http://flif.info/
>14% smaller than lossless WebP
>22% smaller than lossless BPG
>33% smaller than brute-force crushed PNG files (using ZopfliPNG)
>43% smaller than typical PNG files
>46% smaller than optimized Adam7-interlaced PNG files
>53% smaller than lossless JPEG 2000 compression
>74% smaller than lossless JPEG XR compression
>Even if the best image format was picked out of PNG, JPEG 2000, WebP or BPG for a given image corpus, depending on the type of images (photograph, line art, 8 bit or higher bit depth, etc), then FLIF still beats that by 12% on a median corpus (or 19% on average, including 16-bit images which are not supported by WebP and BPG).
▶ No.835289
>>835173
No, it's lossless.
▶ No.835528>>835557
>>835208
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.
▶ No.835557
>>835528
Never gonna happen, it's nih, so google will stick to shitty webp and mozilla will follow them as always.