JPEG XL

I'm not the best at finding sources, also I believe one of you might know off the top of your head: I assume there is little to none degradation in DCT compression vs the full DFT compression Do any of you know any papers comparing the 2?(besides the extra performance of just doing half the dft for the dct)

dft is unnecessary

dct is closer to a fourer series decomposition than a true fourier transformation

Even the phase information information is useless?

well think of dct as a decomposition into cosines

where fft is a decomposition into complex exponentials

phase information is determined by the leading coefficients

of the cosines

for real signals, the cosines provide that phase info

since these are discrete sampled signals there's no even vs odd component to throw away

you don't need to perfectly reconstruct the original. it just has to agree at the samples

We agreee Phase is the direction of the complex number, and magnitude the absolute value or root of cos^2 + sin^2. I was just wondering if there was any information in there or the idft just throws the phase info away I still never read anything on the idft

Idft throws away phase info ?

phase info isn't needed because a sum of aligned cosines can reconstruct the original

do note that idct is a real value only operation

it inverts the real dct

idft needs that phase info but idct doesn't

So the phase info is indeed completely useless as far as compression is concerned?

it's not useless per se, it's just redundant

DCT decomposes a block into a sum of cosines which have zero phase

so there is no phase info to encode

think of it like a sum of cosines, not like a real fft

I believe we are in agreement, I just want to push that no one has recovered a single extra bit using it correct?

it's N samples in and N samples out

and mathematically invertible

on a fixed size block, DCT is a linear transformation

ie you can write it as say an 8x8 matrix for n=8

because it's linear and maps from R8 to R8

so indeed there's nothing to recover

the loss comes from writing higher frequency coefficients with lower precision

not from the transformation itself

I will take that as a very detailed yes no one has got a single bit from it and even if they did they would need more than 1 bit.

Thank you.

I just knew the info was there and wanted confirmation it was redundant, thanks again.

I mean I guess it would make sense that the phase would spin by the same frequency as as the sine and cosine waves, which we would know regardless when we encoded it.

And since from the frequency of the wave and the current point we could calculate the current phase, and with the current phase and cosine value we could calculate the sine value.

yeah, I tried, but it would be easier to use for me and also if there was non xyb-mode encoding

oh that's painful

at 0.3bpp i think AVIF performs better than JXL, but that is still way too low imo

Avif can beat jxl at 0.3 but it needs slower encoding preset.

Dear Sir/Madam, Thank you for contacting us. We have reviewed your submission for whitelisting of your software and the submitted files have been Whitelisted. Regards, McAfee Data Submission Team

I think this is one of the few cases where lossy webp works well. JPEG at the same BPP would be blocky mess

Still, it doesn’t look particularly nice. Maybe they are optimizing for mobile phone use case with really low bandwidth?

about color spaces, from the video and image compression perspective and also metrics accuracy, will LUV be better than LAB and how much different from XYB (if not considering performance)?

what is LUV in this context?

I think this: <https://en.wikipedia.org/wiki/CIELUV>

the author of “Color Appearance Models” thinks it’s worse: https://www.dpreview.com/forums/post/66160798

It's just that for some metric calculations there is sometimes a choice of LUV or YUV (or for L or Y respectively), I was curious which of these would be more accurate

YUV is very different from LUV

YUV is a common abbreviation for YCbCr

which is just RGB but matrix transformed

found also something <:FeelsReadingMan:808827102278451241> https://gist.github.com/Myndex/47c793f8a054041bd2b52caa7ad5271c

yeah, i understand, i meant that for example i have a choice to compare either Y (from YUV) or L (from LUV) on the video or image, using some metrics (say SSIM or MS-SSIM) and which will theoretically be more accurate (for human perception)

ah, you want to do a grayscale comparison

L* from LAB and LUV are identical btw

at least according to the wikipedia article you linked

something like that, for very fast comparisons by metrics

You could also consider Y from CIEXYZ

if you want a super fast comparison from RGB you could use the BT.709 matrix which is just a linear combination of R, G, and B to produce Y

the fastest one I'm familiar with is YCoCg's Y, which is `0.25 * (R + B) + 0.5 * G`

and it's more relevant than RGB

but less relevant than the other ones

honestly you could probably just straight up extract the green plane if you want superduper fast

fast, but still with good accuracy for human perception, something balanced

that's very hard to give recommendations for without knowing what balance you're looking for

as an example of calculating quality with metrics and when I can choose: compare all Y and U and V, but it will be slower, but I can also compare only Y as the most important or I can also choose L from LUV, and which would theoretically be better for comparison in terms of human perception (Y or L)

eh, I'd do 6/8 MSE-Y + 1/8 (MSE-U + MSE-V) as seems to be a reasonable standard if you're limited to MSE... but SIMDfied, so it's faster 😛

because according to various research, for most metrics, only Y component has almost the same correlation with visual quality as YUV sum with coefficients (and usually something like 10:1:1 is also better), so calculating only Y is reasonable (and faster) but, I thought maybe L would be somewhat better (besides, it's been added to some metrics for some reason)

if you're working with integers then 6/8 and 1/8 are very fast

as they're just `((x << 1) + x) >> 2` and `x >> 3` respectively

(you can also write (x*3)/4 and presumably your compiler will do the right thing)

yea, true, lol

if you have unsigned integers then `x >> 2` and `x / 4` are equivalent

if you have negative integers it's complicated because `x >> 2` for negative `x` is, UB but usually on x86 it behaves `floor(x / 4.0)`

and `x / 4` is `ceil(x / 4.0)` for negative `x`

so the compiler can't necessarily make that optimization unless it knows the integers are positive, e.g. if they are unsigned

if ~1.0 is visually lossless for butteraugli, what's visually lossless for ssimulacra2? 90?

I'd say 92.

1.0 used to be lossless for the original butteraugli

I made a calibration mistake at one stage leading to 0.95 being lossless, I decided not to correct for it later when I noticed it, so that moved the level (this mistake was around 2019 when we were already working towards JPEG XL)

then we changed butteraugli to work better with jpeg xl compression and even more to work better with neural compression

I consider that those changes made butteraugli's previous 1.0 to be available somewhere around 0.7 to 0.8

then finally, the viewing distance is an issue

to benefit from butteraugli's calibration, you need to be 900 pixels away from the image

if you are closer, you will be able to see loss -- especially in yellow-blue colors

if you are further, say 1800 pixels away, a higher value will usually work to indicate visually losslessness, but not always 4x since some of the calculations are related to scale

correct -- 15.6 * 2.5/ (1920*1920+1080*1080)**0.5*900==15.93 cm

or you can zoom the image with 500 % and be ~80 cm away

in modern times the screen resolutions and image resolutions have diverged, especially so in mobile

so, it does not work on anime images or is it depend on encoding process?

it probably works best with images that have one clear focal point like portraits but less successfully with images that don't have one, like images of landscapes

not working well with pikachu <:SadCat:805389277247701002>

pikachu pics matter

it must be encoded with this tool `The flags and arguments for --center_x, --center_y and --group_order are automatically injected.` <https://github.com/google/attention-center>

Oh. yeah. I already guessed it somewhat

Yeah, by default it starts on the top left and goes in scanline order. When you pass `--group_order=1` it starts in the geometric center of the image and spirals out in squares from there. . When you also pass `--center_x` and/or `--center_y` it will start at with the tile that contains the (x, y) coordinate and spirals out in squares from there.

I would hope that the attention center model is able to find something close to the center of the face of pikachu

don't you look at the tail first??!?!? more seriously, feel free to file bugs -- there is a dedicated researcher for this problem and they will be happy to receive counterexamples and they will study them.

ok, this might be a dumb question but how does one calculate image file size from bits per pixel?

if I have a 1920x1080 image at 1 bpp, how large is it gonna be?

The number if pixels will be 1920 times 1080, so 2073600.

well you calculate the number of pixels, and then you do `bits/pixel * pixels = bits`

Therefore 1 bit per pixel will be 2.07 Mb

2.07 Mb, which is 259200 Bytes

or ~259 kB

thank you, got it 👍

For a 1 megapixel image, 0.1 bpp means 12.5 kb. For most images, that is way too small to be usable.

What exactly does Chrome/those in the Chromium team stand to gain by blocking JPEG XL adoption in favor of AVIF? I can't figure out what exactly they're getting other than simply propagating the use of AVIF.

They don't exactly earn more money by people using AVIF instead of JPEG XL.

My hypothesis: 1) some kind of paternalistic concept that web devs will get "confused" if there are two state-of-the-art formats, whatever that means 2) AVIF is "their baby" so they want it to be successful. JXL is likely actually a threat to the success of AVIF, at least for still images. 3) if they can kill JXL, there might be more focus on making encoder improvements and general tooling/support improvement for AVIF.

I think it's a combination of 2 and 3. Possibly also 4) Google is reviewing many projects and looking for returns

(btw 1 is not something I invented, this is what Chrome people have recently said in a private meeting with Cloudinary people as being one of the reasons for removing jxl)

I see 1 as one of the those misguided ever-changing reasons that are used when you have no good excuse for something. It started as "this format is not good these other people have aspirations to use it for other things in the future." Then it morphed into "we don't need an all-in-one image format" (as if a video and image codec isn't the same thing). Then it became "well the web doesn't need all these web features that have been used for decades." Then it came back around to "we don't need 20 image formats" (even though there are fewer modern formats than originals). This also includes the "people will get confused" argument. It's just scrambling for anything to try to squash a competitor by throwing one argument after another even when they keep getting debunked one after another.

You are probably right. It seems to be mostly an already-made conclusion in search for a justification

There might be some genuine feeling amongst avif proponents that jxl really does not bring sufficient improvement, or that they will be able to improve avif to "bridge the gap", e.g. by making faster and better encoders.

oh, so there are also private discussions about this? i mean, i don't know why i am surprised, but good to know google isn't completely silent on this front

They weren't very useful so far, but yes.

Mostly they wanted to know what we were missing in avif so they can put it in avif2...

so instead of webp2, we get avif2...

Since somehow they want to reduce the confusion of too many formats but having an avif2 is not an issue

¯\_(ツ)_/¯

Wow, that's even worse... "We're going to kill your format but let us know what we can do down the road to not get so much hate for being authoritarian, monopolistic, and anti-competitive."

<:PepeGlasses:878298516965982308>

Suddenly the antitrust lawsuits going after AOM are starting to make sense.

WebP and WebP2 JPEG and JPEG XL AVIF and AVIF2 well that's just great

WebP2 is likely not going to happen afaiu

oh right, forgot about that

WebP2 is already dead. From what I heard some of them went into AVIF and are likely working on AVIF2.

well, i guess of the three "successor" formats Chrome wants only one to survive 🙂

Yeah I guess they want everyone to work on av2/avif2

Or on av1/avif improvements, I dunno

I know there are issues taken out for adding some of the jxl features to avif but most of the discussion ended last year. Seems they punted to avif2.

Though who knows when avif2 would even see the light of day.

So instead of adopting a format with the improvements people want now, they want to create a new format that'll probably be ready a few years in the future, probably with less features? I really cannot understand it, but hey, Google can do what they want.

Pretty much

Google did drop their "Do no evil" slogan recently (not that it did much good prior).

From the tracking bug for the Merge Request fixing decode speed in M109: https://bugs.chromium.org/p/chromium/issues/detail?id=1392656#c14 > <@795684063032901642>, out of curiosity, why work on improving JPEG-XL if Chrome is going to remove it? I want to make sure that the decoding of JPEG XL files in chrome works as intended, which includes fixing bugs concerning decoding speed. This way users will have the best experience trying it out while it is still in chrome behind a flag.

It's a little annoying to see a fix come in that will only be active for one, just ***ONE*** version (M109) before it is due to be removed (M110).

I understand if the flag was only to be *deprecated* in M110, as the original coverage told us: https://www.phoronix.com/news/Chrome-Deprecating-JPEG-XL However, as of now they plan to *remove* it outright: https://chromium.googlesource.com/chromium/src/+/ec4bd43806b882b9faf155e413814aa0f809edcb

So the impact of this fix is quite minimal, although I appreciate it trying to give us the best experience while it still can.

We have no idea what exactly they will do in M110

They can just expire the flag at M110 instead of M115 — that would mean you can still use it in M110-111 (I think), but first you need to enable the flag to unexpire flags that have expired.

They can also actually remove the flag and/or code.

They could theoretically also just do nothing and have a note in the flag description that doesn't correspond to reality

Nah. That lawsuits are by -LA patent trolls.

it produces quite nice output but of course it has no idea what it means. Lossless with target quality < 90, what?

What is this? Ai based wiki?

https://chat.openai.com/

FWIW, ChatGPT hasn't been trained on data after 2021.

maybe

XYB JPEGs <:PepeGlasses:878298516965982308> `Firefox now supports properly color correcting images tagged with ICCv4 profiles.` https://www.mozilla.org/en-US/firefox/108.0/releasenotes/

Bro, they should really support JPEG-XL at this point if they support ICCv4.

<@288069412857315328> Reddit doesn't seem to like the PNG fallback generated by embed.moe, i.e. Reddit doesn't generate a larger thumbnail in the comments page. Is there a way around this? https://old.reddit.com/r/touhoutest/comments/zlep03/jpegxl_test_png_fallback/

Compare to https://old.reddit.com/r/polandball/comments/s7wr0a/forward_kinking/ which is also a PNG outside of Reddit

if you can figure out the headers that Reddit sends when displaying/generating the image

I'm away for a couple of weeks so I can't test it

About darn time...

I think that article you linked just deals with the small thumbnail that is beside the title to the left (which is generated correctly in my case), what I need is the larger thumbnail below the title of the post but above the comments

Also oEmbed seems to be meant for generating thumbnails for link posts that lead to webpages, my case deals with direct links to images themselves

i guess mozjpeg's djpeg doesn't yet work with jpegli from git master... or maybe i'm doing something wrong, probably that one because i know nothing about this

I suppose it doesn't have ABI compatibility yet? only partial API compatibility?

it *should* have ABI compatibility AFAIU

interesting, the same thing works for me, I think the issue might be that the system jconfig.h that was used to compile jpegli is different from mozjpeg's jconfig.h, specifically the JPEG_LIB_VERSION macro, which can change the size of the jpeg_decompress_struct, so I will have to make sure that at jpegli-compile time we set JPEG_LIB_VERSION to 62

Image not loading on Firefox

<@794205442175402004>

hm, are you using non-nightly firefox with jxl enabled maybe?

I think the cloudinary blog will send jxl images to browsers which say they can decode jxl — like firefox does when you enable the flag, even if it doesn't actually have a jxl decoder if you're not on nightly...

Oh. I'm using Firefox beta

just disable the jxl flag on firefoxes that are not nightly

okay, so slight wrinkle: i *do* have mozjpeg installed via the AUR, but it compiles with -DWITH_JPEG8=TRUE see ldd output even with LD_PRELOAD: ``` ❯ LD_PRELOAD="$HOME/dev/libjxl/build/lib/jpegli/libjpeg.so.62" ldd $(which djpeg) linux-vdso.so.1 (0x00007ffc96d9f000) /home/louie/dev/libjxl/build/lib/jpegli/libjpeg.so.62 (0x00007fbd34e75000) libjpeg.so.8 => /usr/lib/libjpeg.so.8 (0x00007fbd34da0000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fbd34bb9000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fbd34982000) libm.so.6 => /usr/lib/libm.so.6 (0x00007fbd3489a000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fbd3487a000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fbd34e9b000) ``` what exactly is the difference between jpeg8 and jpeg62 that the AUR package compiles mozjpeg with that?

https://www.macrumors.com/2022/12/14/apple-considering-non-webkit-iphone-browsers/

There are some new API functions in jpeg8 and some new fields in the compressor and decompressor objects that some applications might use. Versions 6.2, 7 and 8 are mutually ABI-incompatible, so probably jpegli will have to provide all 3 versions, or 1 depending on some compile-time flag.

Right now it uses the system jpeglib.h without any modification so it will be fundamentally compatible with whatever version is installed, but note that not even all of the 6.2 library functions/features are implemented yet.

later today, I'll be doing this: https://www.headlesscreator.com/upcoming-live-streams

https://www.headlesscreator.com/an-overview-to-image-compression

Here are my slides from the previous one I did in that series: https://docs.google.com/presentation/d/1ZEXaI7Hy6jRn94VMdxAOS1sKSWfC5qHr-6ihHc9N_mY/edit?usp=sharing

New AI image-based 3D object creation uses progressive image loading to generate objects that get finer detail as the images are downloaded & rendered: https://youtu.be/aQctoORQwLE Would JXL be a good fit?

Thank you, enjoyed the presentation! Two qs regarding this slide: 1. I didn’t know that at higher qualities, mozjpeg will produce bigger size for the same quality as libjpeg! (am I reading the graph correctly?) 2. [similarly to how I was surprised to read AVIF encoding is faster than JXL in Google’s paper] I’m surprised the graph is not showing commonly agreed benefit of AVIF over JXL at lower qualities. Is it that you omitted those qualities from the graph or…?

1. Yes, at some point mozjpeg seems to start getting worse than libjpeg. This happens around q87 or so. Could be that its default quant tables are tuned for the 'web quality' range and start to get worse at the higher end, I dunno. 2. As you may have guessed, the vertical axis here is ssimulacra2. Note that I'm only showing results here for ssimulacra2 above 40, and I'm using the avifenc default regarding chroma subsampling (which is 4:4:4 when using png input), while at the low end, avif with 4:2:0 does a little better.

https://storage.googleapis.com/avif-comparison/images/subset1/rateplots/subset1_avif-jxl_t-8_avif-s7_jxl-s6_ssimulacra2__bpp-0.1-3.0.png

the avif team comparison plot was made with a version of libjxl that doesn't have the fix yet for the discontinuity around 0.5 bpp

current libjxl is in blue, the one they tested is in red

By current do you mean the release build 0.7.0 or the current development build?

that basically pushes down the crossover point between avif and jxl into the very silly low bitrates

Current means what is on git now

oh ok

or more exactly: after this was merged: https://github.com/libjxl/libjxl/pull/1825

here are the slides I used, by the way: https://docs.google.com/presentation/d/1w6HA4WrPU9JlFokABtwKYNnb-H6Ydk9VHjLfn2ybwSQ/edit?usp=sharing

So not available at https://storage.googleapis.com/demos.webmproject.org/webp/cmp/index.html 😢. (yeah, I still find these comparisons useful when I quickly explain stuff to people. and to myself)

As things are now, I would estimate the crossover between avif and jxl to happen below 0.2 bpp / ssimulacra2=20 at the 'useful' speed settings, and around 0.35 bpp / ssimulacra2=50 when allowing extremely slow avif encoding.

libjpeg-turbo q40 gets an average ssimulacra2 score of 58.7, to give you an indication of what that means

libjpeg-turbo q16 gets an average ssimulacra2 score of 24.2

so I don't think this crossover point is still worth mentioning — who cares about qualities lower than libjpeg-turbo q20?

this crossover point used to be significantly higher 2 years ago, but it changed over time as avif encoders got faster (default speed is now a lot faster in libaom but also somewhat worse) and libjxl got better

not yet, but I hope they'll at some point do a new one with updated version of everything.

I also find that comparison page useful, even though they're doing slowest avif against default jxl which is not quite fair, it makes the point even better when the jxl has better fidelity 🙂

OK. So, a) allowing for maximum of good will on G part (I’m tad too old for all conspiracy theories and righteous anger) and b) forgetting all “operational” reasons (we already have one, choice between one is easier than between two, smaller attack surface, spec is paid etc; which I agree do play a role! some role at least), what do you think G thinks are **real-world, tangible** benefits of AVIF over JXL? Because I’m bad at reading graphs and, try as I might, I haven’t seen a human-readable description of those by Google… 1. the fact that at insanely slow speed and at insanely low qualities (and this is coming from someone who thinks only those qualities matter on the web; to him, anyway), AVIF produces more pleasing artifacts? 2. weird encoding speed differences which nullify pt. 1? Like, really, what?

Animation?

Well for animation av1 is clearly better than any 'animated' intra-only still image format (though I would have done that by just allowing video formats in the img tag)

If you look at the main page of the avif team comparison, they do seem to think that 1) avif decode is faster than jxl, 2) avif encoding is fast, 3) lossy avif compression is better than jxl. And if that's the case, and jxl is only better in lossless (and you ignore things like progressive and jpeg recompressions), then sure, it would make sense to conclude that jxl does not bring enough advantages to justify adding it to the web platform.

In the 'maximum of good will' interpretation, they actually believe points 1-3 based on the numbers they obtained, and it was just an honest mistake to compute those numbers the way they did.

In that case, I hope my blog post will help to improve the way they do comparisons so they will look at more relevant metrics and quality ranges, see the value jxl brings, and reconsider their assessment and decision.

The alternative explanation, which I very much hope is wrong, is that they did the comparison in bad faith to make avif look better than it really is, and in that case they'll likely just ignore my blog post completely.

Only time will tell. I very much hope for the interpretation where they just made honest mistakes in their evaluation methodology. Mistakes can be learned from and corrected, so that could lead to a good outcome.

The ball is now in their court, I think. Chrome's reaction to my blogpost will be revealing, one way or the other. They have a chance now to show that they're actually data-driven decision makers who try to do the right thing based on the info they have, or they can essentially admit that they're not interested in doing the right thing. I am extremely curious what will happen next.

https://youtu.be/0NBjObx13rs

<:Agree:805404376658608138> Youtube recording in case you missed the live one

why would they react, they gave their data -- their data is clear to them (even when it uses old versions of JPEG XL)

they can just observe the blog post as your interpretation without reaction

I think they wrote only one of the 300 responses in the bug, they are not exactly chatty about JPEG XL

if they wanted to get it right, they would have included someone from JPEG XL devs to get the tests done properly -- they did it alone by themselves

You may very well be right, but my point remains: their reaction (or lack thereof) will be revealing. Not reacting (just ignoring it) is certainly one option, but it will be widely seen as an admission of guilt. They claim the decision was based on data, and they claim they're open to feedback and suggestions on how to improve the data. They can keep silent for a few days, maybe even more by blaming the holidays, but at some point they will have to reveal whether those claims are true or not.

I tend to agree that even if it shows no immediate effect it is good to continue to apply pressure on every fronts 😄

For most people, the admission of guilt was when they acted to remove jxl in the first place, waited until late on a Sunday to respond using clearly inaccurate data, then doubled down by moving faster than they ever seem to move on getting rid of the code even as many, including large companies, put their support behind it. All the other stuff is just pouring excess icing on a cake. It's now smothered.

I don't think the data was "clearly inaccurate". From the point of view of a non-expert (and why would high-level decision makers in a browser organization be experts in image compression?), the data the avif team produced can very well look like they thoroughly and objectively examined several aspects and concluded that jxl only brings slightly better lossless compression, so it is not really worth keeping around in Chrome.

It's indeed suspicious that they want to remove it so quickly just now others like Adobe and Serif start supporting it, but it is still a possibility that they acted in good faith in the best interest of the web platform, if they really thought avif is better than jxl on all fronts relevant to the web.

> From the point of view of a non-expert (and why would high-level decision makers in a browser organization be experts in image compression?), the data the avif team... Because it wasn't, you said it in your own statement. It wasn't done by the Chrome team, but the AVIF team - who should be experts. At the very least highly knowledgeable. Which means they are either incompetent or designed the data so that non-experts would simply gloss over it as acceptable. I remember years ago when people would be laughed off the internet for posting biased or questionable data and benchmarks. Today it seems to happen fairly often and in some cases done in order to trick the average person into believing it was done well.

> examined several aspects and concluded that jxl only brings slightly better lossless compression I wouldn't accept that even if it were lossy compression. Lossy is closer than lossless when it comes to jxl vs avif. However, they need to be comparing jxl vs jpg and jxl vs png and jxl vs gif. Not jxl vs avif. I'm sure they didn't compare avif to a new format.

Their reasoning is that new formats need to be compared to everything that is already in the browser, which makes sense.

AVIF is there now, so JXL has to beat it. I don't entirely agree with that reasoning but it mostly makes sense.

Exactly. That reason means JXL is already obsolete and they will never accept it. Except AVIF was designed for an entirely different purpose and they are ignoring that.

It is a problem that they completely rely on their own codec team to provide the data to make decisions. They made mistakes when evaluating WebP (grossly overestimating how much gains it brought, claiming it was 41% better than JPEG, see https://developers.google.com/speed/webp/docs/c_study?csw=1), they made the same mistakes when evaluating AVIF (see e.g. https://web.dev/compress-images-avif/ where they claim "50% better than JPEG", based on how things look at ultra low bitrates), and they simply ignore others (e.g. http://muizelaar.blogspot.com/2011/04/webp.html) and get their way anyway.

It's one thing to use bad data to push your own thing even though the gains are not that big — at least there are some gains, and you're not really forcing any web dev to actually use your thing. It's another thing though to use bad data to block others' new things — that does mean you're forcing web devs to use inferior solutions.

I don't agree with doing either one of those, but that they did it twice is even worse. They complained about a single format doing everything, but are pushing a format that was meant for one thing as if it should be used for everything.

When people complain about it the response is: just use WebP.

Has anyone already mentioned that libheif/libaom is much larger than libjxl? For example, on the draft PR in wasm-vips I see this: ``` $ ls -lh lib/*.wasm | awk '{print $5,$9}' 4.9M lib/vips-heif.wasm 2.0M lib/vips-jxl.wasm 5.2M lib/vips.wasm ``` 😅

That is with `-O3`, both dynamic modules have full support (decode/encode).

for decoder-only, I suspect the difference is even larger. A lot of the libjxl code complexity is in the perceptual encoding...

google literally does force developers to use webp or avif. if you use the pagespeed insights tool, it will complain if you don't use one of those formats

I suspect that the size of `vips-jxl.wasm` would also decrease when building from <https://github.com/libjxl/libjxl/commit/1d2225c252ce5fd906d3a12ee0dbed92e577076d>.

Forgot to mention, the `vips-jxl.wasm` also contains a static build of brotli and highway. lcms2 resides in `vips.wasm`.

the pagespeed score is a meaningless number anyway, but web site owners are still encouraged to follow whatever it spits out to "make number go up"

yeah it is actually a big problem, since these are not just meaningless numbers, they can affect your pagerank...

so your website literally becomes harder to find if you don't respect the perf metrics Google/Chrome come up with

I think the pagespeed score is based entirely on "lab data" and not not affect ranking. the "Core Web Vitals Assessment" is what contributes to the ranking. if you have enough traffic it's actually based on real RUM traffic from chrome users using something called "CRUX"

By how much is the question. Annoying ads/popups/popovers were supposed to lower you rank. Care to guess how many sites are in the top 5 that have an ever increasing amount of annoying ads, popovers, and in some cases popups? I bet it's fairly high considering what I've seen. It's either not very strong of a signal or it's bs considering their only metric for this is people backtracking to the search engine within a a certain amount of time (likely just a few seconds).

yeah, I don't know exactly which metric is used for what, but I do now that LCP plays a role in pagerank, and LCP currently ignores progressive loading and just looks at the time for the final image, which makes avif look better than it actually is compared to jpeg or even webp

e.g. as far as LCP is concerned, in this cat example: https://cloudinary.com/blog/contemplating-codec-comparisons#progressive_rendering, it will say the avif is slightly better than the jxl in terms of the user experience of loading the page — which is nonsense of course

They started having a discussion about how progressive rendering was going to work with LCP but last I saw, talks stopped. Likely because they didn't want it negatively affecting AVIF. Web.dev still incorrectly states that AVIF supports progressive rendering when it doesn't.

It does have an option to add embedded previews, which I guess is a kind of progressive rendering

Not sure if it already works though, haven't seen a demo of it yet

The encoder doesn't actually even support it. It was meant for cameras to add a preview so it wouldn't have to regenerate it each time for display.

You could claim WebP supports progressive too, since it can contain Exif and Exif can contain a thumbnail

I think it does, but only the top-down rendering that really isn't used anymore.

Top-down rendering I usually call incremental or sequential decode.

'Progressive' I prefer to reserve for rendering that gives full-image previews

I call it progressive since everyone did back in the 90s when the actual progressive added too many extra bytes.

And yes, WebP does support top-down rendering and this is one of the reasons why libwebp is not just a wrapper for libvpx (the lossless codec is of course another reason).

It was a significant pain to make libvpx do incremental decoding, since video codec libraries rarely need that (ultra-low-latency codecs being the exception). I wonder if they will do this with dav1d too, or if they will just define it to be not an issue.

I highly doubt for the current spec. Devs have said that it supports it, but there is little interest in making it reality. Possibly for AVIF2, but no word.

In principle avif could be decoded incrementally too, but not really if the reasoning is "we get it for free with the video codec"

Right now they are of the mindset that everyone should just lower the quality of the images to the point where it loads quickly just because the file size is so small you wouldn't notice a difference if it had progressive rendering.

Yeah, it's a strange mindset. If you care that little about images, you can also just give people the advice to make text-only websites. That will be even faster!

I get the mentality since a few years back there was this mass push to make the web usable in developing nations where internet is shaky at best... but it shouldn't be at the expense of everywhere else. If you have a CDN that can lower the quality of images for slow connections, fine. But doing so in the browser is just not practical.

or txt2img, like txt2vid https://youtu.be/9fU5SN_OR2M

I think progressive rendering is a better solution to that than just lowering quality. Maybe combined with a browser option to only load the first N kb of every image until you explicitly ask to fully load it.

Isn’t JPEG progressive both? First it’s top-down and then progressive (with increasing resolution)? I know (at least?) Firefox (not sure about Chrome) decided to throw away some default mozjpeg scans, but would they not – it would be both, right?

No, it's one or the other. You pick. Technically the non-progressive version is top-down.

That is using AI to generate a your face. There is a lot of research going into that but is still a while away and will likely be questionable given people already trying to pretend to be present. However, that will only work for presentations, not any video.

Well every scan is top-down in jpeg, and either you have just a single scan, or you have more (at least 4 then)

So a randomly truncated progressive jpeg has more detail in the top than in the bottom

yeah, this is just an example, there are a lot of more advanced researches

lol someone has already created what you are talking about https://towardsai.net/p/l/stable-diffusion-based-image-compresssion

I think it's not a such good idea tbh

I mean, who needs to able to read text, anyway? https://cdn-images-1.medium.com/max/512/1*RCG7lcPNGAUnpkeSsYGGbg.png

If they improve it more, they will produce readable text

It will just not be the same text as in the input 🙂

Who doesn’t want sunnier weather?

Or it will make it's own alien language.

18 kb jpeg guetzli and jxl

you should add xyb jpeg too just because

What? What for?

to the comparison

if you accept to have a decoder of a few Gb 😅

I just now heard about Ladybird and SerenityOS. Quite an ambitious project!

https://github.com/SerenityOS/serenity/tree/master/Userland/Libraries/LibGfx

Maybe we should get jxl in there — one concern though is they don't want third party libraries, they want to do everything from scratch

they do implement brotli (decompression only)

on jxl on serenity: I think you should wait for (or convince) someone to implement it for that reason.

Core Web Vitals does not reward progressive or even streaming decoding. Streaming decoding feels 2x faster than static. Progressive feels still 2-3x faster than streaming.

let's aim at 2.0-3.0 bpp for comparison -- those look like 0.53 or something -- you cannot make poor quality compression and then learn about high quality about it

there can be a need for such things -- however, methods that make things look plausible and more average are not great for verification and validation, legal use, photo for insurance claims, medical imaging, prints, art, body positivity, etc. Also, no one has found out how to properly create value (that would justify the massive codec sizes and decoding costs) with these while delivering relatively high quality images

simple to say that Jpeg XL is just 2 times better

yes, that is expected at 0.5 BPP

I'm expecting jpegli to perform better than AVIF in the 3-5 BPP range, roughly same in 2-3 BPP

jpegli will always be slightly worse than jpeg xl -- possibly 15 % worse at highest quality

I don't think it makes sense to compare photos by BPP, as for me this is an outdated practice that no longer has anything to do with the real state of things. why should compare jpeg XL 3 bpp and jpeg 3 bpp if 1 bpp jpeg xl looks exactly the same as jpeg 3 bpp

despite all the math and entropy, sometimes something just works much better. for example, LZMA compresses better than ZIP and ZSTD - and there's nothing you can do about itand there's nothing you can do about it, it's just power so why not show the inability of JPEG to compress low-quality images well, moreover, when the same problem is inherent in Jpeg XL in comparison with AVIF one can only wonder how many unnecessary things were in the photo that can be simplified by another 2-3 times and absolutely not notice it in any way no, I do not think that JPEG is worthy of being compared with any quality between JPEG XL on a serious basis, well, he is also ridiculous, JPEG XL can compression every pixel without loss if use modular at the moment when JPEG will demonstrate same file size use lossy q95-q100

yes, I meant Deflate, I just always forget this name, ZIP was created with this algorithm

Deflate can be better than lzma for the shortest files I think

similarly jpegli can be better than avif for reasonable quality files (say q93) even if it is worse in q75 or q85

because the new encoder wasn't built to do any of that -- it was built for the normal use case -- it doesn't perform well for low quality

the same like LZMA usually compresses 0.6 % better than Brotli for very long data, but can be 100 % more for the very short data

you cannot extrapolate much, it is better to measure measure measure

🧐

Jpegli is . jpg?

speaking about lower quality, it would be nice to adopt some MozJpeg tricks to make Jpegli better without exception https://cdn.discordapp.com/attachments/1020724883241574472/1020755005315235970/Screen_Shot_2022-09-17_at_7.55.26_PM.png

jpegli is like mozjpeg, libjpeg, libjpeg-turbo or guetzli -- jpegli will contain both encoder and decoder in libjpeg(-turbo) compatible ABI, but also include an incompatible extension for 16 bits per component frame buffers (you'll only see 8 bits per component if you use the compatible version)

I need a main file to can execute jpegli

Here is an improved visualization of all the sRGB colors mapped into XYB (where each macroblock is one Y value, increasing in scanline order, and within each macroblock the horizontal axis is X and the vertical one is B)

(and the ranges are stretched linearly with global constants to maximally use the available space without exceeding it)

nice

I have an improvement for anime

line drawings etc.

about 2x-3x less artefacts

Here's a video version of the XYB visualization: https://youtu.be/GrhFJzX1DV4

actually here's what I uploaded to YouTube, probably better quality

it has a rather interesting shape

it feels like the bouncing DVD logo

<@461421345302118401>

🥳

https://github.com/libjxl/libjxl/pull/1987

<@794205442175402004> benchmark_xl has no option for encode to exact size? it would be useful to compare changes and in addition to d1, d2, d3, also encode to the sizes of the old encodings and maybe even encode in metric score, something like --target_ssimulacra2=88.72

I am not interested in same bpp per image, but in same bpp per corpus. That's a bit hard to implement without doing lots of encodes though

This reminds me: we should add stdev of ssimulacra2 and butteraugli to benchmark_xl, since improving encoder consistency (lowering variance) is valuable too.

but it would still be usable for a more accurate single images (and different formats) comparison or like: d1, d2, d3, then manually specified size352560, size253077, size206726 (after changes) ```Encoding kPixels Bytes BPP E MP/s D MP/s Max norm pnorm BPP*pnorm Bugs ------------------------------------------------------------------------------------------------------------ jxl:d1 4945 352560 0.5703479 1.127 10.134 1.71980071 0.40719574 0.232243242920 0 jxl:d2 4945 253077 0.4094110 1.208 8.889 2.89177322 0.74157528 0.303609077277 0 jxl:d3 4945 206726 0.3344275 1.251 8.815 3.95514226 0.93876976 0.313950384872 0 Aggregate: 4945 264217 0.4274321 1.194 9.260 2.69940567 0.65690997 0.280784385535 0```

https://youtu.be/rvhf6feXw7w

I was using an older version of the XYB transform, this is what jxl actually uses (also I subtracted Y from B to mimick what default Chroma-from-Luma does)

<https://github.com/libjxl/libjxl/pull/1987> ```Before: Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 pnorm PSNR --------------------------------------------------------------------------------------------------------- Aggregate: 18611 1719389 0.7390519 1.723 15.180 4.71785347 75.65518621 1.17961303 35.82``` ```After: Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 pnorm PSNR --------------------------------------------------------------------------------------------------------- Aggregate: 18611 1737532 0.7468500 1.724 15.293 4.16149002 59.43491435 1.17162667 36.04``` SSIMULACRA2 59.43491435 <:Thonk:805904896879493180>

those scores are calculated with a geometric average

If any value in the data set is zero, the geometric mean is zero

there is a near zero in ssimulacra2 scores, so geometric mean is meaningless

ssimulacra2 scores are not derived from error or first principles but have their own scale and it is not applicable to geometric averaging

look at the individual scores instead

We should probably just use arithmetic averaging for ssimulacra2, geomean indeed does not make sense

it would be great to have a more invariant score * BPP

like in butteraugli we get a somewhat invariant norm * BPP across a range of qualities

that way it is easy to use automated optimization on the score * BPP instead of searching for exactly same BPP within the automated optimization (20x faster)

yeah, score * BPP for ssimulacra2 would be nice

ssimulacra2/(1+bpp)² or something like that could work, maybe

I have conflicting opinions on using ssimulacra2 to optimize for — it might lead to better compression, but it will also make ssimulacra2 less useful as a metric...

if it's not cheating, like preprocessing for vmaf for some video encoders (which gives ~200% better results, without visual improvements), then there's nothing wrong with it if there are actual visual improvements, and not blindly following only metrics scores besides, now there will be at least two good metrics

Vmaf is messed up by having this concept that changing an image can make it better than the original. Conflating reference-based fidelity metrics with no-reference image quality assessment leads to weird situations where things like smoothing away fine texture is considered to be an 'enhancement' (noise removal) that makes the compressed image better than the original.

Human test subjects do behave like that, especially in side-by-side comparisons without a reference image and given vague instructions like 'which one looks better' rather than 'which is closest to the original'. And of course there are cases where the smoothing of the compression happens to reduce some capturing artifacts — but trying to do two things in one metric is a bad idea.

some decisions are difficult to optimize on BPP*pnorm with butteraugli

like ac_strategy is really difficult, and masking, too

they easily lead to poor performance a high distances

Patches is a dangerous feature to have for this reason. A similar problem happened before with another image codec that caused the codec to get banned from use in legal documents.

https://en.wikipedia.org/wiki/JBIG2#Disadvantages

patches can be used without fuzzy matching, too

for example only matching the number 7 to other numbers of 7, and not to number 3

(sorry for making it a caricature, but it can be made)

also note that the Xerox controversy is an isolated incident; it was never repeated.

generally it's well known that lossy compression can create a non-existent information out of the thin air, patches are no different---their failure modes just happen to be less understood by laypersons.

say, if the image was scanned with a high enough dpi, bad patches couldn't possibly happen (if you assume a good enough encoder), they are sufficiently different

but as you lower dpi, your chance to meet bad patches also increases, probably exponentially

so people should be trained to scan images with high enough dpi to avoid that failure mode, which should be trained in some way

either by accident or word of mouth

this could still happen again when ai codecs become common (for now only audio/voice are really used, but there are big plans for images and video as well)

For legal or medical images, I would either avoid lossy compression or use it only at 'safe' settings (e.g. d0.5 for jxl)

in case of JBIG2 the problem typically occurred at 200 dpi but there was also some occurrence at 300 dpi (which _should_ be safe, barring from bugs)

Well a codec like JXL is probably not going to be used for scanned documents anyways... at least, not at first. Technically JXL seems to have most of the features of DJVU... (aside from multi-page support of course.)

There's no reason JXL couldn't be used as an efficient lossy bi-level image codec.

But lossy bi-level image codecs with patches is a risky idea.

lossy bi-level codecs being used for legal documents is a bad idea in general.

I imagine it will be fairly uncommon at first but there is no technical reason why JXL would not be a good codec for document scans. Especially converting existing JPEG scans to JXL.

Hello <@532010383041363969> Thank you for your work, I really appreciate all your effort 🙂 1.This PR reduce those smooth area tiny ringing, and let those area look better, but I think red smooth area still have some tiny ringing. I really like allocates more bits in the proximity of smooth areas, I mean if I input d 1.0~0.5 e 8~9 this target distance and effort, I would expect better quality, maybe can depend effort to decide lossy strategy? * effort e8~9 quality first and enabled another lossy algorithm for DCT worst case. * effort e7~ lower bpp and encoder faster. > For make sure input image is pure png and don't have generation loss, > I unpack those sample image from game asset package. 2. I think if libjxl have heuristic to switch different method for different input, that will be very useful. like pingo will detect if output file size larger than input file size, maybe can do some fast DCT test and fast palette sort test to decide which method is near best? > varDCT, lossy palette, jpeg_lossless 3. Look like djxl embed a wrong icc profile on output png, original png use Adobe RGB (1998), but djxl embed RGB_D65_SRG_Rel_Lin, Is this expected behavior? > Adobe RGB (1998)-Copyright 1999 Adobe Systems Incorporated > RGB_D65_SRG_Rel_Lin 4. A little curious, different non-photo type(2d-art, 3d-game-screenshot) will need different artifacts reduce strategy? or all non-photo type can use the same artifacts reduce strategy?

2d-art

3d-game-screenshot

https://github.com/saschanaz/jxl-winthumb Is there any updated fork exist?

Thank you for your kind words and continued guidance. Your previous advice and examples are still helping me in being motivated to find and debug such improvements 🙂

DJVU was a very good design for its time

> different method for different input It is always possible to create an image with half the other input and half the other kind of input (half anime, half photograph) -- because of it things should just work robustly in any case For optimal size, of course we would explore a combination, too, but all these quickly start to contribute to the encoding (and possibly also decoding) times

> * effort e8~9 quality first and enabled another lossy algorithm for DCT worst case. > * effort e7~ lower bpp and encoder faster. I'm still optimizing e7 only, e8-e9 go with butteraugli (which is not so great with anime)

In more than one way! Both JB2 and IW44 look very much like precursors to JBIG2 and JPEG2000, and the text block compression uses the burrows-wheeler transform. Shame about the patent issues that prevented it from taking hold. And the ideas of segmenting into layers still exists today, there are tools around that create PDF files with the same basic structure: JPEG/JPEG2000 encoded background and foreground color images with a JBIG2/G4-fax monochrome selector mask.

djvu had patent issues? I thought it was a free format.

There just weren't any free encoders that could create good multi-layer djvu files that take maximum advantage of all its features.

And a single-layer djvu file from a basic-bitch free encoder is hardly any better than plain JPEG

Are such tools free to use?

I am sure DJVU would have been used more often for scanned images, if there was any software or hardware tools for people to actually take advantage of it.

But the free tools for djvu are no better than a JPEG encoder.

That's the true reason why the format did not take off.

Yeah, the arithmetic coding was under patent and prevented free software implementations for the longest time.

I believe (but don't quote me) that the original DjVu compressors used neural networks to do the segmenting into layers (AI before it was hot).

if I understood correctly, DjVu was inherently 300 dpi, connected 1:1 to the best printing tech in its time -- when 600 dpi printing came, it was immediately and completely outdated

I thought it had several layers that could be at different DPI layers and the most common scheme was 100 for the background layer and 300 for the foreground bilevel image. Also 300dpi scans are not "immediately and completely outdated," it's a pretty good sweet spot where small details are nice and sharp and you aren't wasting bits saving anything smaller than you can see.

For practical purposes when it comes to human eyes reading a document and looking at manga, you don't need to save details that are smaller than 1/300th of an inch.

Really...

I would be really surprised if DJVU has a DPI limitation considering how flexible it seems to be. But even if it did have a 300dpi limitation, it's absolutely laughable to think that's the reason it didn't gain popularity...

Tooling is the most important thing when it comes to formats.

If JXL is to become popular it needs good tooling too. Good authoring tools, which seems to be effortlessly happening already, but also good tooling for viewing them as well, which is also happening pretty naturally too, aside from the strange Chrome exception, which didn't seem very natural at all...

But another thing that would help with tooling, is a conversion tool so people can convert existing images. Ideally it will support lossless mode, lossless-JPEG mode, image preview, and batch/mass-conversion. If it supports lossless transformations like jpegtran, that's even better.

I haven't used a Mac in a long time so I'm not sure how convenient it is to view JXL images on a Mac... But right now it's pretty inconvenient on Windows, the most-used PC OS.

You have to really go out of your way, a lot, in order to use JXL if you're on Windows. It's a real pain in the neck inconvenience.

The winthumb software seems to completely stop working on it's own after a while, like it has an expiration date or something.

That's even assuming the user is tech savvy enough to install it in the first place, which is another laughable concept.

JXL would start to catch on a lot faster if it was easier for Windows users to experience the utility and genuine usefulness of libjxl

Most users will only interact with libjxl via its integrations in gimp, krita, darktable etc.

Yep, because winthumb and the WIC codec are not ready for prime time.

Ideally there should be an .exe or .msi package that enables thumbnail integration, and ideally added support to the built in photo viewer tooling on Windows too.

Especially if there aren't any performance or API limitations with libjxl being used in such a context.

Which would probably involve a lot of short-lived processes calling libJXL rapidly as a user scrolls through a folder filled with images.

And if there was a converter that could losslessly convert back and forth between JXL and PNG as well as lossless JPEG conversion, automatically transfer exif tags and other metadata as well, then it would be very easy to demonstrate the usefulness of JXL to Windows users.

I would expect a large boon to adoption after that, but that would be a lot of work.

And worst of all it would be Windows work :(

I don't have the patience to read Microsoft documentation

microsoft documentation is good

the problem is that jpeg xl is still something you need to know of to care about

nobody knows what jpeg xl is so nobody cares

Well, their documentation is better than their design and implementation, that is for sure.

But their documentation is not as good as, say, the Open Group Base Specifications, or the OpenBSD manual

But yeah, much worse than their documentation is their bad ideas

Their documentation is not bad compared to the atrocity it's documenting

i'd argue their "bad ideas" are not their fault

https://github.com/yllan/JXLook this app makes is it pretty easy to preview and view jxl files on a mac even if it’s not been updated in a while

Yeah, that does look cool. I wonder if that means it works in Preview.app too if it works with quicklook...

I think the original tooling would make fonts render at 300 dpi -- there would be no 600/1200 dpi rendering of them that we are already used to, and reading 300 dpi binary text on paper would be an unusual experience for a modern person of course if it would have taken on, the tooling would have sifted to 2x and 4x resolutions or something like that

I’m pretty sure it does not. But if you double click a jxl file, the app will open it in its own window

oh yeah quicklook for windows supports jxl

the bulk of the code in jxlook is in https://github.com/yllan/JXLook/blob/main/JXLook/JXL.swift if someone has interest how it looks like

What's quicklook for windows?

<https://github.com/QL-Win/QuickLook>

<:Poggers:805392625934663710> <:Stonks:806137886726553651> https://github.com/libjxl/libjxl/pull/1999

is the api for group size change not added yet?

seems that 16-bit png is also sometimes needed (and for some reason only fpng is mentioned, there is a fast decoder, but still pretty limited) https://github.com/AuburnSounds/gamut/issues/33

fpnge sure can 😉

<@179701849576833024> maybe also add a small README.md for fast_lossless and for supported features? <https://github.com/libjxl/libjxl/tree/main/experimental/fast_lossless>

maybe I should...

https://github.com/libjxl/libjxl/pull/2003

for fpnge it would also be nice to clarify that it supports 8/16 bit, hdr encoding, etc.

It supports 8 and 16 bit content, 1 to 4 channels; it can also emit [cICP chunks](https://www.w3.org/TR/png/#cICP-chunk) for signaling that the content should be interpreted as HDR.

how about this?

done, thanks 🙂

The PNG file format specification is surprisingly easy to follow... it's enjoyable writing a decoder (except for the actual image data, that's a bit painful) I wonder if someone could do the same for JPEG XL, a standards document or explanation that explains at least the file format if not the compression methods (because that's *really* complicated) in a simpler way that doesn't need to conform to "standard terminology", because that's really a bit difficult and overcomplicated at times.

should I try this?

The more info available, the better. Feel free to start a repo for this, perhaps using asciidoc/metanorma like the spec itself. I will review and maybe contribute too. This is a good way to have an unofficial but good and freely available spec.

Yeah it's pretty good! OTOH PNG is about as simple as it gets for an image format, so there's that

PNG as a format made a few strange mistakes: filter bytes are mixed with the image data, low bytes and high bytes are coded with the same entropy code, RGBA channels are all coded with the same entropy code, LZ77 is used as byte indexed, not pixel indexed -- these are pretty severe mistakes from a format design viewpoint and having had them right would have given another 20 % in density without adverse effects

Well, as the saying goes, hindsight is 20/20

Though that does make me a bit sad thinking about how PNG could have been 20% better...

I like to think that PNG is an attempt to make an extensible format with stock algorithms, not necessarily good ones

there is a good argument that this was necessary, as they didn't want to risk patent concerns from novel algorithms

at that time DEFLATE was considered patent-free (or more accurately speaking, there was a widespread strategy to produce a patent-free DEFLATE implementation) so that's where the stock algorithm came from

and many forms of arithmetic coding are considered to have patent issues (the same reason JPEG with AC didn't catch on)

corollary: you can change this history significantly by travelling back in time and spread the knowledge of ANS 😉

to be fair, they could *at least* have specified predictor arithmetic to happen on 16 bits instead of 8 if you have a 16-bit PNG...

everything else I could see reason to, but this one is... eh

(well, ok, there is a reason - it's simpler to implement - but still...)

another thing I wouldn't have minded is if they specified it so that IDAT chunks wouldn't need a checksum, we already have the adler deflate checksum...

Checksums on all chunks is kind of silly overhead

Predictor arithmetic also doesn't make sense for 1/2/4 bit images

more accurately, *double* checksums are silly overhead

(IDAT requires a chunk checksum AND zlib checksum)

yes, Paeth can predict the high byte from a different pixel than the low byte, it is almost funny

Yes, but also checksums on header chunks and the end marker chunk etc is just not very useful. It's not a file format's task to catch transfer errors / bit rot. That's a confusion of application layer...

then again, at those times it feels like the idea was that more checksums are always better looking at the wire formats that got designed then xD

I guess the N in PNG means it can detect bad transfer

Thank you for your reply 🙂 Probably can add a new parameter to control heuristic and strategy? > --preprocessing_level=0~6 similar cwebp -m, if specify large value, the encoder will spend more time inspecting additional encoding possibilities, > -m int > Specify the compression method to use. > This parameter controls the trade off between encoding speed and the compressed file size and quality. > Possible values range from 0 to 6. Default value is 4. When higher values are used, > the encoder will spend more time inspecting additional encoding possibilities and decide on the quality gain. > Lower value can result in faster processing time at the expense of larger file size and lower compression quality. * fast DCT:true, palette sort:true * fast DCT:true, palette sort:False > apply varDCT. * fast DCT:False, palette sort:true > apply lossy palette or apply Jon patches PR. * fast DCT:False, palette sort:False > apply Modular lossless. * fast DCT:False, palette sort:False, and input format is jpeg > apply jpeg lossless.

there is a jxl overview page in the libjxl repo

format_overview.md or something

this is more related to video than photos but does anyone know what's the difference between 60 fps video and 59.94 fps video in practice, when talking about digital? I know the 59.94 fps comes from some weird analog quirk but you still see this in many digital video files, same with 29.97 fps and 23.98 when compared to 30 fps and 24 fps respectively.

What I'm mostly interested in is that what happens if you play back a 59.94 fps video on a 60 fps screen. does the video player drop a frame every 16.66 seconds. or can you just play back the video at 60 frames, making it 0.1% faster (presumably this would cause the audio to go eventually out of sync if it's not taken into account)

when talking about a TV, you could presumably run the panel at 59.94 hz or 60 hz refresh rate depending on the content but it's a bit more involved if you play back a file on a computer because if the operating system runs at 60, the video will have to play back in a 60 fps "container"

I am familiar with conversions between 60 and 50 when talking about PAL and NTSC and 24 to 60 when converting from film to video but the fractional frame rates confuse me because how can you play back a partial frame 🤔

depends on the player. for example you can configure mpv w `--speed=1.001` to correct framerate. at the expense of some tiny pitch chance of the sound

(if u dont disable pitch correction which u tbh should)

there are also some monitors with VRR (variable refresh rate) support (marketing names like freesync)

which when things are configured correctly will adjust panel's framerate to match content

i personally use wayland w swaywm and freesync monitor and have enabled sway's VRR support & enabled frame doubling mpv filter because my monitor can do freesync only down to 40fps

yeah, the VRR thing is interesting but I don't know how well it works with desktop apps, I think games mostly run in exclusive full screen or borderless full screen where the content takes up the whole screen

or is there some kind of API that allows different parts of the screen update at different frame rate?

there is also something called interpolation, a class of algorithms that can smooth out transitions and kinda convert content to higher framerate that way (eg 23.94 to 60 fps or more)

afaik VRR support works for fullscreen applications

but that matches how i watch content with mpv at least

if you wanna windowed the best you could do is manually adjusting monitor's mode oldschool way (if its supported) or use interpolation

so is the default behavior to drop frames every so often?

in my experience something like mpv's oversample is pretty good, though one may find more fitting ones depending on viewer's taste and content type

usually yes

u dont drop frames

u miss frames

as in showing some one frame as 2 frames once in a while

ah

https://github.com/mpv-player/mpv/wiki/Display-synchronization

reading this atm

personally very noticeable w 23.94/24 fps to 60 fps content, especially with smooth screen/scenery scrolls

i dont think the frame duplication would happen often enough w 59.98 to 60fps conversion for many to notice

yeah, I agree. if I want to watch a movie from my laptop on my TV, I will go to the laptop display settings and force the operating system to output 24 fps which will make the motion much smoother

what would a proper png in jxl format look like? i mean something fast but more properly used, would it be something like e4? judging by this description, it would be great to have fast lossless up to e4, at least for 8-bit or maybe make something simpler but with similar efficiency? <https://www.reddit.com/r/jpegxl/comments/10157np/analysis_of_effort_settings/> ```Modular (lossless): e1: fast-lossless, fixed YCoCg RCT, fixed ClampedGradient predictor, simple palette detection, no MA tree (one context for everything), Huffman, simple rle-only lz77 e2+: try global channel palette e2: fixed YCoCg RCT, fixed ClampedGradient predictor, fixed MA tree (context based on Gradient-error), ANS e3: fixed YCoCg RCT, fixed Weighed predictor, fixed MA tree (context based on WP-error), ANS e4+: try both ClampedGradient and Weighted predictor, try global palette e5+: detect patches, try local palette / local channel palette e5-9: try more and more local RCTs e8-9: try more Weighted predictor parameters e6-9: use more properties when learning MA trees e9: try all predictors```

weighted predictor is *really hard* to make fast

but I do agree that one could make a much faster e4-level encoder

and ClampedGradient is better than a brute force (like in fpnge) of simpler (and faster) filters or maybe ClampedGradient + simple filters will be faster and not much worse than using weighted predictor after some optimizations?

or different filters are not something that gives any noticeable gain on fast modes?

Select is probably a good predictor for nonphoto

ClampedGradient is the best general-purpose predictor imo

Weighed is the best for photo

what about `e2: fixed YCoCg RCT, fixed ClampedGradient predictor, fixed MA tree (context based on Gradient-error), ANS` + `try global palette` or maybe even + `try local palette / local channel palette` or is it slow stuff?