okay. it is a lot simplified, but mostly correct. ideally image format for drawn out stuff and other flat animated stuff is svg (vector graphics - ie - infinitely scalable yet crisp), but png is usually used because it is defacto lossless standrad. lossless here roughly translates to - sensor produced a matrix of colors - lossless photo preserves all data. lossy discards some data. For irl stuff, usually lossless is overkill for end user, hence you see jpegs (defacto lossy standrad)

jxl can so both. others can do that as well. jpegs can be lossless, but that is usually not the standard we use. you can store lossy data in pngs, but the loss is not created by png. jxl behaves by default like lossless (like png), but due to newer algorithms, size when lossless is closer to jpeg. if you prepare loss jxl - it can be close to half size of jpegs.

there are other benifits to jxl (extreme future proofing (extremely high bit depth, and pixel size limit, large amount of channels), progressive decoding, etc.), but our reality has to suck because of google.

I locally use jxl to store family photos, but this means i can not send them, because they are using stuff which does not support jxl, so have to convert and share.

data harvesting wise, yes, but they still get traffic, which means ads, which is money. I am not blaming you, reddit in some sense is cultural heritage of internet. I was mostly doing a joke bit (mentioning reddit on lemmy)

what would they be?

do you mean in sense of lossy or lossless? if so, in theory both webp and avif could have lossless photos, but i do not think they are designed for that (think in terms of their backrounds, they are kinda like a single frame videos. and usually you only have lossy video).

jpeg xl in theory aims to take job of both jpeg and png (it can handle lossy as well as lossless). In theory, we (as in all of computing and media people) decide to back on jpegxl, we could potentially just have 1 format, and accordingly 1 library which provides support. but that is just a dream i do not see happening. google essentially paralysed jpeg xl by removing it from chromium , and that is the largest userbase.

almost all other big companies want to use jpeg xl. meta, adobe, intel and others. the main benefit to them is reduced bandwidth cost (for exactly same data, jpeg xl can be ~20% smaller than jpeg), and jpeg can be losslessly translated to jxl, and even for backwards compatibility, reverse can be done on client end. but without chrome, no web developer will adopt. if web people do not, the demand for format would be extremely small, no hardware manufacturer will include hardware support (your gpus have “special” stuff for almot all codecs and formats, but that is not the case for jxl for now), so jxl operations currently are slow, so end user might not even be motivated to use (other than space savings).

https://jpegxl.info/

you can check out some training databases on hugging face, and there is 100s of gibs of porn there. it is one of the best ways to understand human antomy for image/video gen

but computers can calculate a 9857408293304297*3729892093829/3809389312893382 in less than 10 ms using microwatts of energy, and humans would need a solid hours (at best minutes i presume)

it is wrong, kinda. It would be correct if brains worked like a electrical conductor, but we are more like batteries (so ions move under electrochemical potential). in short, W = V I does not apply here.

If it did, the amount of heat produced would be humongous.

here is a reddit thread I found about this - https://www.reddit.com/r/askscience/comments/5ijvvd/what_is_the_amperage_of_the_human_nervous_system/

:puke: “using reddit”

yes, because we just have 1 good libwebp library

avif is better than it in almost all ways, and jpex xl is even better than that (but not about gifs i think)

webp is essentially a webm file (which is mkv with codec restrictions(vp8/9 and ogg vorbis or opus))

avif is av1 encoded files in a webp like container (but not webm afaik)

jpeg xl is a format made specifically for images

I can almost guarantee that they would be using different things. usually you have simpler libraries to decode formats (almost 1 for each codec), and separate programs plug these libraries in to generate the output. previews do not have to be accurate and have to be fast, so a simpler program with just linear scaling or something, where as actual image would be complex which has to worry about accuracy.

still not a excuse to not have support for a free 15 year old format