@takao @Zerglingman @lelouchebag I've used bziped farbfeld a bunch. Imlib and image magic support it so it's easy to work with, not just implement

@roboneko @applejack @Zerglingman @lelouchebag

@roboneko @Zerglingman @lelouchebag @takao PNGs are from 1996. They were literally made to be a competitor to GIFs, that's the level they're at

@applejack @roboneko @Zerglingman @lelouchebag @takao And? Something being newer doesn't make it worthwhile. webp maxes out at a resolution of 16383 x 16383. It is incapable of encoding the attached image. That shiny new format is less capable than something that was designed to compete with GIF. That's the level webp is at.
Bath_from_alexandra_park.jpg

@roboneko @takao @roboneko @lelouchebag @applejack Do you want hellthread? Because that's how you get hellthread.

@takao @roboneko @lelouchebag @applejack @roboneko Also:
yun-wuxin:[wisknort]:~$ sxiv Bath_from_alexandra_park.jpg
sxiv: Bath_from_alexandra_park.jpg: Error opening image

Lol
I might have fucked up by trying to open it in krita.

@Zerglingman @applejack @lelouchebag @takao

> Do you want hellthread? Because that's how you get hellthread.

Here are a few more images that webp is incapable of encoding due to their superior resolution.
Canon_EF_16-35mm_f4L_IS_USM_collage.jpg
Julia-Menge_-0.5142_0.5142.png
CH.VS.Zermatt_2019-12-29_7471b_The-Matterhorn_OrigX+R.jpg

@Zerglingman @applejack @lelouchebag @takao

Yet another gem that webp can't encode. It's odd, we're clearly on the web and these are images so you'd think that webp should be able to handle them.

> I might have fucked up by trying to open it in krita.

feh seems to work quite well. I wouldn't recommend eye of gnome, it allocated ridiculous amounts of memory for large images the last time I tried it.
Menger_4D_OpenCL_23448154_32K.jpg

@Zerglingman @applejack @lelouchebag @takao

sjw posted this one years before I joined fedi it's a mere 32k x 18k
69bcda431c75395e33edb0e4371eedc1646ac7bad7ec479b303cad1ae200e397.jpg

@roboneko @Zerglingman @applejack @lelouchebag @takao over half a gigapixel
b97d5330-8153-4cd5-b51e-4163c86fd2a0.png

@do @roboneko @Zerglingman @applejack @lelouchebag @takao yes
Well no because JXL has a lot of tricks up it's sleeve for things like that

@roboneko @Zerglingman @applejack @lelouchebag thank you, nigger, I was on metered internet

@roboneko @Zerglingman @lelouchebag @takao None of these really work without issues and there's no reason you need to exclusively use one format anyway. This has no effect on 99.999% of images, but I'll agree with you, jpeg/png is better for mega huge images, just still have ugly/bad compression while doing it

@roboneko@bae.st @roboneko@freespeechextremist.com @Zerglingman @lelouchebag @takao Having 90s compression tech does make PNGs worse. Going by insane niches like 16385x16385 images doesn't make PNGs better

I'm not saying webp is the perfect thing for every usecase, but general stuff, like anime girl pics, it's way better

I made an actual showcase for you
https://anonfiles.com/V2gayaO3xa/webp-showcase_zip

for pf in r/* ; set p (basename $pf) ; convert $pf $p.png && optipng $p.png ; end

for pf in r/* ; set p (basename $pf) ; convert -define webp:lossless=true $pf $p.webp ; end

for pf in r/* ; set p (basename $pf) ; convert $pf farbfeld:- | bzip2 > $p.farbfeld.bz2 ; end

@roboneko@bae.st @roboneko@freespeechextremist.com @Zerglingman @lelouchebag @takao Enjoying my 10,000x10,000 anime girls at 60% of the filesize

These are probably going to be fairly representative btw. jewgle itself reported like 30% overall reduction for lossless images and here I get 40%

eila.png is a high quality vector
spider.jpg is a photograph
sanya.jpg is a very textured painting
pting.png is a largely single colour cropped photograph
erika.webp is a cropped screenshot from an anime so it has some slight noise

@roboneko@bae.st @roboneko@freespeechextremist.com @Zerglingman @lelouchebag @takao Also example of the C api. Here's how easy it is to read an image in Lua

@applejack @roboneko @Zerglingman @lelouchebag @takao

not sure what a library api has to do with anything, that's a software question not a format one

I was never contesting that webp achieves better compression. I don't think it's enough better to justify the new format on its own, and certainly not in light of the shortcomings. New formats shouldn't be added to the mix without good reason. I don't see webp as compelling for the trouble of adding support to everything out there.

I like jxl. It's admittedly a monstrously complicated format but it's not as though jpg is particularly simple to begin with. It improves compression while increasing maximum resolution (jpg 2^16, png 2^31) and maintaining backwards compatibility (jpg can be converted to jxl without losing quality and you can convert them back to jpg later if you change your mind). It also increases the number of supported layers and adds tiling. Other stuff I'm forgetting. I'm not sure how it compares to tiff but I'm guessing it's favorable. Basically I'm happy with png for the most part but jxl seems worth the trouble to me.

@roboneko@bae.st @roboneko@freespeechextremist.com @Zerglingman @lelouchebag @takao

>software question not a format one
Only in abstract. The actual libs are what's used, not specs. I've used libjpeg and it's not fun, and I'll imagine whatever implements jxl is probably less so

I feel like you're in a weird all or nothing mindset. I'll accept there are places where it's not the best but I was responding to people saying it sucked inherently

>without good reason
30-40% lossless reduction with an open standard that's easy to implement with a cross-platform FOSS library

Anything that uses images implements multiple formats already, generally much less useful ones too. There just literally is no downside in not supporting it, and again, it's not all or nothing, you're thinking too abstractly

There's not a single program on my computer that supports jxl and none of those I've ever needed. You can have different priorities, that's fine, but I'll take lossless 40% reduction over 2^31 images and tiling that work with almost nothing. I don't really want to use lossy encodings to begin with, quality is more important to me than storage or bandwidth

@applejack @roboneko @Zerglingman @lelouchebag @takao doesn't jxl also net you lossless 40% reductions? I was under the impression that it did everything webp does, everything jpg does, everything png does, and at least some of what tiff does

my mindset isn't all or nothing I just don't think the effort of adopting webp was worthwhile. it's a simple value estimate. you say you don't like libjpeg. I'd argue the webp effort would have been better spent reimplementing it so that you did like it.

@roboneko@bae.st @roboneko@freespeechextremist.com @Zerglingman @lelouchebag @takao I have no idea, I've never heard of it, but nothing supports it as is anyway so I have little reason to use it

Tbf, there isn't much effort. Mainly stuff will (and generally should) use something like imlib that already supports webp and jpeg with a simple interface, but more low level stuff like browsers sometimes implement it using the reference libs

@applejack @roboneko @roboneko @Zerglingman @lelouchebag it's ongoing. https://caniuse.com/jpegxl

@takao @roboneko@bae.st @roboneko@freespeechextremist.com @Zerglingman @lelouchebag >A modern image format optimized for web environments. JPEG XL generally has better compression than WebP, JPEG, PNG and GIF and is designed to supersede them. JPEG XL competes with AVIF which has similar compression quality but fewer features overall.

Sounds good. If it gets support I'll probably use it then

@applejack @roboneko @roboneko @Zerglingman @lelouchebag you could describe it as a combination of (unfortunately) goolag's PIK and FLIF (via FUIF). It's undergoing standardisation right now as ISO/IEC 18181 but only Part 2 (describing file format) has been published so far. The most relevant Part 1 (describing core coding system) is slated to be published early this year, the remaining parts are conformance testing and reference implementation.

@applejack @Zerglingman @lelouchebag @roboneko @roboneko gist is that unlike webp or AVIF, this thing is designed for raster graphics and not derived from a fucking video encoder.

@takao @roboneko@bae.st @roboneko@freespeechextremist.com @Zerglingman @lelouchebag installed libjxl and imagemagic likes it now

Weebit of niggering and I can open them regularly now. I guess writing a thumbnailer entry would be easy too

@takao @roboneko@bae.st @roboneko@freespeechextremist.com @Zerglingman @lelouchebag No, okay, libjxl ships with one, so I'll just need to restart the FM. Epic

@applejack @roboneko @roboneko @Zerglingman @lelouchebag I rigged a quick SlackBuild and installed libjxl, it also comes with a GIMP plugin which works.

Q=50, progressive. JFIF is created by libjpeg-turbo's cjpeg.

@applejack @roboneko @roboneko @Zerglingman @lelouchebag afair ImageMagick has a defined delegate to use {c,d}jxl for handling these files (in other words it's not native)

@applejack @roboneko @roboneko @Zerglingman @lelouchebag

@takao @roboneko@bae.st @roboneko@freespeechextremist.com @Zerglingman @lelouchebag Nothing I have opens this. Not even gimp or imagemagic

@applejack @roboneko @roboneko @Zerglingman @lelouchebag https://jpegxl.io/tutorials/gimp/