JPEG XL

See also: https://discord.com/channels/794206087879852103/794206087879852106/1256021550864400466

Updated Testing Page (although the design has since changed):

Home Page for reference in this thread:

what is the 2MB SVG that you posted and deleted?

This one.

I didn't realize Discord doesn't actually show the SVG

So everyone knows, these are from Figma, so things have changed a bit when the actual design has been implemented.

something to note about AVIFs is the actual max bit-depth seems to be 12 not 10. the confusion seems to have come up because of AVIF being based on a video codec and inheriting all the confusing stuff about different profile levels and whatever else.

Seeing the footnote about expandability at the bottom instantly made me think of the recent gainmap addition, which could be used as an example

can confirm, chromium can view 12 bit 4:4:4 avif files just fine

ehh, sure gainmaps *could* be an example but I find them to be a bad one considering pretty much any image format that supports metadata could also support gainmaps just fine (AVIF and JPEG already do) and also gainmaps as a concept (or at least how they exist currently) I think are kinda dumb

gainmaps are a hacky solution to a problem that wouldn't be a problem in a more perfect world

My point was less about gainmaps being gainmaps, and more about the relative speed and ease of adding the new feature

Eh, I dunno. Was just a passing thought

Site map we've been working off of:

Updated (in the original)

Both HEIC and AVIF do support larger images, but you will need to use separately encoded tiles then, which can lead to visible seams. Or you could try to go out of profile and hope it decodes — I think most software decoders should be ok with it, but I don't think it's a good idea to promote creating out of profile bitstreams: if someone switches to hardware decoding it will stop working etc...

Also maybe JPEG should be split between "de facto, widely deployed JPEG" and "what you can get out of it with a funky implementation like jpegli" (and then maybe a third column for the full 1992 spec, which includes 12-bit lossy, 16-bit lossless, and other fancy stuff that was just too much ahead of its time for people to bother implementing it at the time)

What's curious that even early versions of Netscape Navigator and Internet Explorer can correctly decode jpegs skipping RGB-YCbCr transform.

Some other jpeg decoders were hardcoded for YCbCr.

Maybe three columns for just JPEG is a bit much though 🙂 But it could make sense to distinguish 'usual JPEG' from 'jpegli JPEG', which can actually do a decent job at HDR photos, and has an effective precision of 10 bit.

As a criteria a JPEG image to be considered an 'usual JPEG' could be ability to be losslessly represented as baseline JPEG.

Progressive JPEG is not baseline but usually carries data compatible with baseline.

losslessly recompressed <:CatSmile:805382488293244929> `17.074% of filesize save` moving this convo to <#805176455658733570>

~~Too bad I'm not home now <:KekDog:884736660376535040>~~

the innate need to compress. lol

took me quite a while to find the best combination/settings lol

What if I can beat it? <a:KittyGiggle:1126529145480945746>

<:PepeGlasses:878298516965982308>

Might try to when I'm back home... Sunday night <:KekDog:884736660376535040>

Posting the site as a JXL was a wise choice, it stopped me from spending an hour encoding it myself haha

Just never sure how annoying it is for people to have to download to see it.

Is there a particular JavaScript thing you can use some help with, <@594623456415449088>?

Yes. Too lazy to type. Here is the home page as it stands:

So for the Visually Lossless JSON it looks like this (in spreadsheet form):

The image slider comparison ones are slightly more complicated. There are 4 files: JPEG_SameQuality.json JPEG_SameSize.json AVIF_SameQuality.json AVIF_SameSize.json and I put the images to compare on a single line. Here is AVIF_SameQuality as a CSV. You can see we did target SSIM scores of 80, 70, 60 & 50 that correlate to High, Med-High, Med & Med-Low for Quality. The closest for each target was found.

JSON if you prefer.

For the SameSize files, we did XL, L, M & S. The actual sizes vary depending on the images – I just picked what worked in each case.

If you're visual:

And to further complicate things, we've been building the site in Webflow and using code snippets to inject the complicated stuff.

That website looks sick af. Great work

Thanks, I really appreciate that. It's been a labour of love. Just taken much longer than I'd hoped!

I take issue with the progressive by design portion specifically "like progressive jpeg but better", JXL can be encoded so it's decoded in a similar scanline fashion. it would be better to emphasize in some way that this is an optional feature of JXL, or at least hint towards it, it would also be far better to include something like webp or avif with no progressive decode features (though there are hacks for avif, so maybe just use webp). that being said, I havent really hit any JXL images that out right can't be progressively decoded (with JXL-oxide at least)

That's all fine, but how do you make it visually interesting? I did one against an AVIF and it just doesn't look like anything.

This was the test: > Like progressive JPEGs, but way better! JPEG XL’s state-of-the-art progressive loading includes saliency progression — face detail sent first, background detail later — and reordering — middle data sent first and the rest later. The 'better' was in reference to the saliency abilities. Maybe that's not clear?

I just mean that JXL can still progressively decode differently depending on both the encode settings and decoder here is an example https://cdn.discordapp.com/attachments/673202643916816384/1233268459312251001/vardct-modular.mp4?ex=66803181&is=667ee001&hm=2cdcd0f8007ebbf506cd8b9a59a5fc3a411c2d647b4ddec083fd2bdfc70ae4db& https://cdn.discordapp.com/attachments/794206087879852106/1243287093845692416/out.mp4?ex=668062d6&is=667f1156&hm=568fa9e15bc4c9489d1d8924e996a2c31085335a6e1bcdca7773756efe5f4212&

I should also mention the information hierarchy we were going for. The home page is a full-out marketing page, so tech details are light, but it's got lots of visual examples. The second level will be the more detailed pages. I've written much of it, Jon has reviewed some, but we haven't built those pages out yet at all. Once we do, there will be "learn more" buttons added to the home page. The 3rd level is access to the white papers and such that dive heavy into the 'how'.

So I would say things like that could go on the page about the progressive capabilities. I'll be looking to all of you to help buff those out.

So my notes for progressive look like this:

yeah show casing is great, I think it would be best to somehow alude that it's a feature of JXL that can be enabled somehow

How about something like : > JPEG XL’s state-of-the-art progressive encoding and decoding includes saliency progression — face detail sent first, background detail later; and reordering — middle data sent first and the rest later. It means you'll see an image sooner than with other formats.

yeah, that sounds better,

if you wanted to be extra safe you could s/saliency progression/saliency progression support

Why is apple listed if we have iOS and macOS listed? Just wondering

That's just the way it currently is: https://jpegxl.info/why-jxl.html

fair point

I suppose just having 'Apple' would probably suffice now. Being on iOS, macOS and visionOS

what about TVOS?

Based on IOS since the second generation, and they're currently on version 17 so I'd assume they do support JXL. Just need to find someone to test

I have an Apple TV, just wondering how to test it.

Apparently you can put a browser on it https://github.com/jvanakker/tvOSBrowser

Sure — I just put some example test images here: https://sneyers.info/hdrtest/

May I give my opinion about the image examples used to compare JPGXL, WebP, and others on Lossy? I come from the e-com photo industry and hear hundreds of studio experts, photographers, and digitech staff. Your examples make it hard to see any hypersaturated thin line on an unsaturated background. WebP is not good for a fashion e-com product page because the garments might have hyper-saturated threads in neutral cloth. Since e-com images don't have many pixels, the saturation disappears or reduces a lot in these threads in WebP. Suggestions to convince the more "visual" trained people: - add more examples and amplify the problematic areas if it helps ("the devil is always in the details") - I use a 3D color space visualizer to help me "see" what is happening with color (see the image I'm sending - I used https://www.mozusystems.com/products/color-spatioplotter-ex/)

Is there a GitHub for the new website?

I don't think it has one yet. probably going to be mostly done in private then opened up to GitHub I assume

Yes, that's the plan. We're trying to get a version published and then open it up for everyone to take it away. All the comparison images are referenced in JSON files, so it will be easy to add or remove from there. Do keep in mind though this is meant to be a marketing website – we're trying to sell the format. There needs to be another level added beneath that's more technical.

Relating to https://discord.com/channels/794206087879852103/822105409312653333/1278260949249425408 Maybe the website should have a section on best practices / common pitfalls, for people who are new to the format

Things like when to use VarDCT vs Modular

And what distances are considered “web quality” / “camera quality” / etc…

I haven't seen them reference that way. In one of the tool interfaces I have them as zero mathematically lossless and <=1 visually lossless. Is there a further agreed upon set of distances?

0 is mathematical lossless, yes

This is a draft of a table I am proposing in an informative annex of the upcoming AIC-3 standard:

Basically the distance parameter is attempting to represent JND units, so you can interpret the first column as a libjxl distance setting

It's still TBD, this is just a proposal for something to put in a committee draft

Didn't you made once an histogram of jpeg bpp found in the wild web ? Isn't 2JND a point at which avif quality crosses jxl quality?

Is JND distance?

If so, why is the default 1, wouldn’t that mean it’s just noticeably not lossless? Or do I misunderstand how JND units are

The JND scale is defined so that 1 JND means 50% of human observers can see the difference (presumably just barely) and the other 50% cannot see it.

Is it 50% can see a different on flicker test or 50% can guess if an image is compressed or not?

The JND scale depends on the viewing conditions. For AIC-3 we basically assume normal viewing distance, no zoom, and a flip test (manual in-place switching) to define our scale. This should roughly correspond to the distance scale of libjxl and butteraugli.

hey due to the scope of the overhaul for the website can there be a place where the old site lives? something like hosting the whole of the old site at `jpegxl.info/old` maybe?

Or Internet Archive

<@594623456415449088> sent me a first version of the new site, I'm pushing it to github-pages right now

https://jpegxl.info/new

please take a look and report any issues — or make a PR to fix them 🙂

plan is to make this the default page soon and move the old stuff to /old

ok the glitter effect is neat but i don't like it following my mouse around like that. also they make my computer lag so they'd probably be really terrible on a slightly old phone or laptop

cpu goes brr

yeah I also think the glitter thing is a bit over the top, there's already the animated wavy thing and I think that's enough in terms of eye candy

the image comparison thingy doesn't seem to work, it shows the same image on both sides

Amazing! Very small quirks at the resolution of my smartphone (which don't support hdr as I could check 😅)

Images comparison work flawlessly for me. I love the new tone

works for me so far too

is this really accurate? I don't recall the graph of jxl being that vertically flat

I think this is adapted from this plot: https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#high_quality

ah, that plot is very misleading though

it's a bit misleading if you don't label the axes though — the origin is not zero here

That tiling is not very nice. And also the tiled image is either overcompressed, or idk. Not smooth

Also all images in section "up to 55% smaller than jpeg" are too overcompressed, and much blurry than jpegs. Also there is an image with terrible artifacts, that are much worse than banding and usual jpeg artifacts for perception. Honestly, I'd choose jpeg in this comparison. It's artifacts is much more consistent over the image

"When comparing image size versus encoding speed, JPEG XL wins hands down at all levels." Just not true, especially under that lossless graph. I get that it's marketing an maybe lies are worthwhile in that context, but I think the truth is more powerful.

All avif images with default sliders position are better than jxl. If we are going to advertise jxl by this page, approach (of a least default slider positions) should be different, and it should not go to the ultralow quality range, where avif wins

I am noticing that too, even the first jpeg looks better than jxl preserving more detail in the area of interest

Exactly

Idk who would choose first over second

I don't think it's actually displaying any JXLs though

click "compare quality" and you get the exact same image on both sides...

I think it's diaplaying low quality JPEGs even though it says "JPEG XL"

ssimulacra2 hates blocky backgrounds but humans are looking mostly at the high-contrast salient bits where jpeg's blockiness is not much of an issue

unsplash.png.d11.3.7.jxl.webp whaat? Where is the .avif?

Exactly

Maybe better to let that comparison with jpeg default to the "compare quality" (at the same size) tab, rather than at the "compare size" tab

Jokes aside, images looks to be webp actually, at least if open it in another tab it appears to be webp

maybe the site just doesn't work on Firefox

oh, yep

relying on the objective metrics for quality assesment is just outright failing here

when comparing at the same size, the improvement over jpeg is obvious. When comparing at the same ssimu2 score, it will depend a lot on where in the image you look which will be best, because overall they are similar (at least according to ssimu2) but of course locally there can be big differences

the jxl could use more sane distance and more likely look better than competition at lower size

probably shouldn't give more bytes to the jxl in the quality comparison

equal or less

what effort settings were the images encoded with?

ssimulacra2 does not take saliency into account, and that's kind of important in this type of comparison. Instead of starting at the "compare size" tab at "med-low" quality, I think it would be better to start it at the "compare quality" tab at "medium" sizes.

i just found the site

the nice thing is the comparisons at least touch on truth, even if they happen to be unfavorable

there is a slight visual bug when displaying on Waterfox

applying this patch fixed it, however i can't test whether this breaks on other browsers ```diff .headline-s-semibold { font-family: barlow, sans-serif; font-weight: 600; font-size: 2rem; letter-spacing: -0.02em; - line-height: 1.25rem; + line-height: 1em; color: #fff; margin: 0; } ```

also fixes it on Thorium, I'll fix it

is there a github repo?

edit: found it

also some weird text on https://jpegxl.info/new/resources/distance-vs-effort-visualizer.html

goes away if i zoom out

it seems pretty inefficient sending a request per image every time you move the slider, maybe the images can be packed into a tar-like format and picked out on the fly when displaying?

It works, at least seems to

I think adding an alpha demo would be nice, a lot of deliverable formats don't support associated alpha, so that could be a neat selling point, and possibly even the greater then 0.0..1.0 encoding

works fine on Waterfox as well, although waterfox support JXL natively

those are fallback lossless webp versions for browsers that don't support jxl

feel free to add something like that

link to git repo?

Hmm, I'm on ff with jxl addon, it is not enough?

I'd also like to add a page on jxl art — and a link to the github repo 🙂

https://github.com/jxl-community/jxl-community.github.io/

definitely jxl art

One thing we'll need to figure out I guess is how we want to do the menus — currently it's just static html with duplication of the navigation stuff, which is obviously not convenient if we want to make changes to the menu

it uses picture elements with a source with a jxl and a fallback. either the jxl addon doesn't work with picture elements, or you are actually getting the jxl without realizing it.

could do simple PHP includes use github actions to compile to raw html

``` <picture id="JPEGCompare_JXLImage" class="image1-after slider-image"> <source type="image/jxl" srcset="ComparisonImages/mohamed-nohassi-_U8RyuBtvQU-unsplash.png.d11.3.7.jxl"> <img src="ComparisonImages/mohamed-nohassi-_U8RyuBtvQU-unsplash.png.d11.3.7.jxl.webp" alt="Beach Silhouettes"> </picture> ```

oh man, im terrible at making sites lol, I'll figure it out lol

Hmm. I'd rather prefer effort 3 over 10 here.

if someone knows how to factor out the common menu parts and setup the github actions to make it work, feel free to make a pull request along those lines

would you ever use d15 at all?

ssimu2 agrees with you. Generally speaking, efforts > 6 are probably often making poor choices at distances > 10, since butteraugli is not really designed for that kind of low quality

I checked all images in that comparison, every picture is better with -e 3 or 4 than higher at the highest distance. -e 5+ just blurs everything

you could use Jinja and statically compile in a Github Action, i don't know how to use GitHub actions though, so I can't really help

I'm just curious. And also I don't know what distance is used for 'med-low' images in size comparison on the first page, but it seems to be quite high, so probably lower efforts will create less blurred and more blocked image, like jpeg does.

https://github.com/marketplace/actions/jinja2-templating

And then I found (i) button 🤦‍♂️ So if we are showing images with such distance, effort also shoud be lower to create more competitive images, I believe

Btw, it could be that special 'high distance' code path, that was discussed somewhere few days ago

Distance 11, as on the comparison page. First (e4) is clear winner over second (e10) for me

it is more transparent to use the default effort for the quality/size comparisons

if lower effort is better at higher distance, it seems a bug

Can originals from the comparison page be downloaded somewhere?

https://jpegxl.info/new/about/photo-credits.html

Well, not *so* originals 😅 But it is also ok, thank you

so i'm terrible at websites so before I dump a wackload of time, here's the exposure demo

something like "Keep high dynamic range images without loosing out of range data"

I cheated to make this since I don't know any tools that can actually edit JXL with float output yet, but it can at least *store* it lol

Well, checked that 'jump' photo with -d 11.3, as on comparison page. e8-e10 range is obvious loser, it is worse than e5-e7. But for such distances I'd use -e4, even despite it produces such banding (?) artifacts on smooth areas. e3 is worse than e4, so e4 is my choice for such distances, if I once would want to use it.

My favorite effort setting is 6 🙂

For such distances it blurs too much, and produces huge ringing artifacts, like all efforts > 4

the higher block sizes kinda screw JXL over at high distances

hmmm, I can't think of any good demos for showcasing associated alpha, so maybe there isn't much point in that, I do think this is a good demo to showcase however

> While best-in-class for compressing photographic images, JPEG XL is even better at efficiently compressing and storing non-photographic (synthetic) images such as graphics, illustrations, and digital art. Has anyone demonstrated that JXL's performance on non-photo is better than its performance on photo? Talking about lossy obviously, as the reverse is true for lossless.

If true, this statement should qualify that it is talking about lossy.

It kind of depends what you compare to. If you compare to earlier JPEG standards (in particular JPEG 1 and JPEG 2000), jxl is better for photo but a _lot_ better for nonphoto (both for lossy and lossless). If you compare to lossless webp, the biggest improvement is in photo.

true, it's way better than jpeg, but what about avif?

maybe relative measurements against jpeg are all users care about here, I would accept that

If you compare to avif, with the current state of encoders, I would say for photo jxl wins across the board, and for nonphoto avif wins for lossy and jxl for lossless.

Comparing with the old jpeg is the most important for the general public, I think. Many people don't even know avif exists.

Many people who are making choices about image codecs?

Most people don't even know jpeg exists. But this site seems to be targeted to technical users who would be aware of avif as perhaps jxl's biggest competition, hence all the direct comparisons.

I think most people who go to websites know about jpeg. But yeah, there are various target audiences we have to consider, from laypeople to experts, webdevs to photographers, etc.

If Apple is indeed going to announce iPhone capture support for jxl, I think we can expect incoming traffic from "curious iPhone users". For them, the relevant comparison would actually be to jpeg and to heic...

i would say pretty much everyone at least know what a JPEG is

unless they really just need an image of a hotdog

It's a photo, right?

something like that

I will have to disagree just based on personal experience, with even the claim that most web users know what it is.

people are at least increasingly familiar with practical storage limitations through mobile phone use, but that doesn't imply any intuition about file formats

I guess it depends on some combination of age and general computer literacy — my kids probably don't know what a jpeg is even though they're pretty fluent with their phones and tablets, while people of my parents' generation probably do know what a jpeg is (or perhaps "a .JPG") even when they're not that technically savvy

I guess you could say "xx% smaller than HEIC - the standard format for iPhone"

...and xx (not %) faster

i would not put as much effort on speed, as the phone can continue encoding the image in the background

I meant decoding. I have bunch of heics from one of phototours, shot by iPhone owner. And it is really sluggish compared to jpeg\jxl of the same size. 500 ms vs 50 for heic vs jxl

oh, that makes sense

I believe that there are faster heic decoders, but I use the one availabled for IrfanView, because IV also supports jxls

HEICs load pretty much instantly on my Mac but that’s probably because it’s utilising the hardware decoder

HEICs (at least those generated by iPhone) are tiled 512x512 so maybe something’s going weird with threads

Or it uses fast sw decoder, don't know

apple uses hw enc/dec for heic as far as I know

it also means it tends to fail decoding heics that its hardware cannot handle, since I don't think they properly fall back to sw decode

current issues I have: - Background image is noticeably artifacted and ugly (working on a fix for this myself). - Main SVG has missing transparency on my end for some reason even though the file seems to render fine on it's own? - discovery of other parts/pages of the site is practically hidden away, I think there should be a better way for people to find the other parts of the site then everything being stuffed away in a hamburger menu.

regarding point 3, does it really need to be a hidden hamburger menu, there's 4 main parts

im not great at design so it looks bad, but this should work fine

extracting the background image <https://jpegxl.info/new/images/kamran-abdullayev-black-background-unsplash.jxl> there is definitely noticable artifacting

given the dark mode theme, maybe the [Battle of the Codecs](<https://jpegxl.info/new/resources/battle-of-codecs.html>) image should be darker?

it's because Unsplash (where a bunch of images on the site are from) has awful reencoding servers and it seems like there's no way to get the original images, the most close I can get is PNGs with slight JPEG blocking from their servers

the download "Original Size" option on their site sucks

That's what was done. Default on all encoders. And these were done quite a few months ago now.

I compressed the shit out of that one. I can recompress. Was trying to make the backgrounds images super small

I agree that at least on desktop, it would be better to replace the hamburger menu with something that always shows the first-level menu titles

use this as a base (the one Unsplash gives by default is ugly) https://images.unsplash.com/photo-1624139283078-74a0492f2ee3?fm=png&q=100&ixlib=rb-4.0.3&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D

Maybe it could also be considered to include an expanded menu in the footer of the page...

do yall think d 2.5 is gonna be fine?

<@794205442175402004> how do you do that embed thing

with the JXLs

you upload a jxl and then right click on that message and go to the Apps > menu

I got this with `-d 2.5 -e 10`, it looks fine to me but I have very bad vision

https://embed.moe/https://cdn.discordapp.com/attachments/1256302117379903498/1281984357069750282/output.jxl?ex=66ddb478&is=66dc62f8&hm=9384e58bbc3e9f4d4ec6e225b853d9ba1ef6be52eea23c6a60678bb8222b67ad&

There are lots more sections to come which is why we went with the hmbuger menu.

Don't worry about the logo transparency for now. When we have some time, we're going to rebuild it, as some SVG rasterizers didn't like it.

is anyone familiar with Jekyll? Looks like github-pages more or less natively supports that to do html generation, so maybe we can use that to factor out the navigation stuff from the html, which is necessary if we don't want to have to edit all files each time some subpage gets added

i personally think the battle of the codecs image looks better in dark mode, but that's just me (ignore the broken half-stars, my editing software broke the svg)

it seems that Jekyll is more focused on Markdown blogs, I'm not sure if it supports advanced HTML/JS functionality

Still it's not great for discoverability to have all the navigation hidden in the hamburger, imo. I think it would make sense to have the expanded menu also at the bottom, just above the footer, maybe in a somewhat smaller font than if you click the hamburger. Basically if you're done reading the landing page, you shouldn't have to scroll back up to find a subpage and get more info...

should or shouldn't?

The codecs page is meant to be HTML eventually. We just ran out of time. So if someone wants to take it on… We were going to move JPEG XL to the left against the menu column and then let the rest slide left to right to compare against

We can make do something more obivous than the hamburger menu, but still keep everything in there.

I would only use it to do an "include" for the top navigation and another "include" for the footer stuff, and the rest is just passthrough HTML/JS, assuming it allows doing that.

shouldn't, oops 🙂

When I have some time I'll document the processes and add it somewhere to the site. People will want to know…

looks like it should https://jekyllrb.com/docs/step-by-step/02-liquid/ https://jekyllrb.com/docs/step-by-step/05-includes/

ive never used it before though

so i can't comment on how well it works

Also if anyone can get the jxl WASM working on the Distance vs Effort page and it's not too crappy on the performance front… Those images currently don't have fallbacks (for obvious reasons)

are the links deliberately bigger?

there's also this delay when closing sections in the FAQ, it seems to be intentional but im not sure what it's for

New less compressed versions of the backgrounds.

Look way better, ship those

The page name and metadata need to be updated. Those are still our testing names.

<@386612331288723469> would the tool you used to show progressive create a better version of the video than the one I did? It was a struggle…

It might, but it assumes a repaint every 400 or so bytes, where a normal system would repaint every second of 2

Also my “tool” is just truncating a file and giving it to JXL-oxide

I built a webpage, throttled the network, used Thorium, recorded the screen…

Doing it the realistic way (browser with throttled network) is probably the more "honest" way of doing it, but doing it the "frequent repaint" way does help to show off what's actually in the bitstream.

The Chromium/Thorium integration is not doing things as progressively as it can, in order to avoid the perf overhead associated with frequent repaints. Basically it only paints the 8x8 downsampled image and then each group once it is complete.

uh sorry if this is a bit much of an ask but could all of the Unsplash sourced images and image comparisons be redone on the site with their higher quality versions? like pretty much all of the images suffer from low quality JPEG artifacts brought on by Unsplash's reencoding servers. actually I would be willing to redo all the results if no one else is willing to I just need the encoding options and tools used then I can reencode and regenerate the SSIMULACRA 2 results and such (with the same images of course). the current images on the site had the following trip: `user image uploaded image on Unsplash's servers > decoded to pixels > reencoded as a quality 60 or so JPEG > decoded to pixels > reencoded as whatever for the website's comparisons` I can cut out the "reencoded as a quality 60 or so JPEG" part by passing custom parameters to their servers/CDN.

I know it's sorta a low priority higher effort thing which is why I would be willing to do it on my own time and then get the go ahead and push it to the site

this could take awhile so it should probably not block the release of the new site

Except that the images were huge to begin with. I sampled them down to their current size and saved them as PNGs. This gets rid of most of the JPEG artifacts — I assume.

The image data is all hosted in the JSON files, so you can see what's required.

New images can be added at will…

This post shows the data in the JSON files: https://discord.com/channels/794206087879852103/1256302117379903498/1281987731374739538

For now, one thing I would like to have is some way to de-duplicate the navigation and footer stuff so we can edit menus in one place when adding new stuff. Tweaking the existing stuff and adding new pages is something we can do any time, goal is to keep it a living website.

If we want to add new images to the comparisons, I would suggest to add some where jxl is a lot better than the other codec: - for jpeg, try something like a screenshot with text, icons, some diagram or something like that - for avif, try something with clouds, a lake, a close-up human face, subtle textures like marble/concrete/wood/etc.

This was added to Oxide yesterday https://github.com/tirr-c/jxl-oxide/pull/339 which might help. A key point is getting the lqip to render, since that's currently disabled in libjxl, and I was going to suggest encoding with the centre-first order, since you make a point of talking about it directly under the image where it's not currently used

Error Resilience in the FAQ could be changed, a few weeks ago wb was talking about changing libjxl to skip corrupted chunks/passes. So broken HF data falls back to the LF, ect

In the Wide Gamut test, jpeg gets a SSIMU2 score of 8, but the also 8-bit WebP got a score of 100. Something wrong with the page or SSIMULACRA2 itself?

the `100` for WebP is correct (it's lossless) although the JPEG should be `84.66` not `8`

Yeah, the rest of the numbers got deleted somehow. 84.66 is right.

The 16-bit to 8-bit would still make a difference though right?

You could take a 16-bit source image in some very wide gamut space like ProPhoto or Rec2100, and then you would have lossless webp not able to be actually lossless and have a ssimu2 score below 100

In this case, the P3 source image was just 8 bit

maybe a little more details about progressive decoding features, like <https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html> <https://opensource.googleblog.com/2022/12/open-sourcing-attention-center-model.html> also use less of a marketing and hype tone as much as possible, because in my opinion right now it feels like something with less credibility to any statements and information in general and more like some products to attract investors for that reason I even like the old page better

https://jpegxl.info/new/resources/battle-of-codecs.html was updated with a more fitting color scheme, thanks <@594623456415449088>

Light theme will not be there, right?

yeah I think the marketing/hype tone is OK for the landing page, which is addressing a broad, mostly not-very-technical audience. All the other pages that we add and that go into more detail should use a more humble and scientific tone, imo. And yes, I'm all for adding more technical details.

readability is not very good, perhaps need a different font or larger size

the transparency test images on the new site always have a light theme background now compared to the old site

old:

new:

Could put the JXL artists to work ;P

It seems to be single svg with too small scale, if I'm not wrong

Later next week I can release all the detailed technical pages we were hoping to get up eventually too. There is a whole lot more content to come.

For the FAQs, I would appreciate an "unfold all" button. Sometimes you have a specific question and want to unfold just that answer, but another way to use a FAQ is just to read it all, kind of like an interview-style way to learn about something.

Eventually I guess that chart should become html so it can be made to work well on mobile too, maybe even have foldable details etc

https://discord.com/channels/794206087879852103/1256302117379903498/1281987349164720189

Anyone have thoughts on the HDR image? It's an h.265 one frame video with a AVIF fallback image. Flickers in Safari, but that's the only way to get HDR there.

It's a bit awkward but I guess it's the best we can do for now. I hope Safari gets its still image HDR shit together quickly so we can replace that with just a jxl image with an avif fallback.

The mail icon, do we have anything useful to link that to, or should it just be removed?

Yes, that's great, I was disagreeing with the suggestion to tune jxl effort differently.

still, it is a bit surprising to have so many example where jxl looks worse than the alternative

Why is the logo spelt "JPEGXL" on the new site?

It's more like JPEG**XL**

Changing the font kind of replaces the need for a space, so for me it works. But yeah I can see how it could cause some confusion.

The text uses the space though. Though not yet the non-breaking-space, I notice

Where there tweaks to this? looks like a regression maybe? Only happens on the iPhone. Can't reproduce on desktop

We can do an option where there is the same space between JPEG & XL as the thickness of the stem of the L and see what it looks like.

I kind of like how the G fits into the X, and it's a logo, not plain text, so I think it's fine to not have the space there. But yeah, maybe with a thin space it still looks nice and it becomes less likely that people will start writing JPEGXL

This font is too small, a lot too small...

We can go a bit bigger, but it's really just meant as a placeholder under it's HTML-ized

Is it just me or have some of the SVG elements been rasterised?

iPhone btw

Question about the "supported software" section. Since Tachiyomi is no longer receiving updates, shouldn't we replace it with Mihon? And I think there should be a platform icons next to the apps (Windows, Android, etc.)

fossify gallery merged jxl support so keep an eye our for it's next stable update

Is the title really "JPEG XL-Code Model"?

the CSS seems to have a lot of duplication of rules, was it written by a human or by an automatic buid system?

it's probably a WIP from whatever design software was used

https://jpegxl.info/new/resources/supported-software.html That "MacOS" should be macOS

And I'm not sure if it's still necessary to recommend a plugin

Tachiyomi is discontinued and its repo is removed

Yeah there was a soft drop shadow on those elements in Figma and it rasterized. Removed in the latest version

Is there a info@jpegxl.info?

Not sure if I can make that work, will have to check DNS settings. Question is who will get those mails and reply to them 🙂

I mentioned up above that we didn't have time to do our normal round of metadata final edits, so will definitely need to be done across the site. We were testing out several sites and that was just an internal name

Instead of making some new email address, I think it is probably better to point interested people to discord/reddit/twitter (and possibly some more open variants of those, though I think unfortunately it is hard to really get a critical mass to move to IRC/Lemmy/mastodon or whatever)

I feel like this discord is probably a good pick as it’s an easy way to get questions answered

Is that IRC / Matrix bridge still alive?

Hmm I use Element for Matrix too

Yeah, and we did have a contact page in the works.

I think it is broken somehow, but I don't really feel like fixing it because it was a rather big source of cryptospammers that couldn't be easily banned (not on discord because for discord they're the bridge bot, not on matrix because they just make new accounts and matrix doesn't have much protection against that it seems)

General Inquiries: Contact form for general questions and feedback Business Partnerships: Information for potential business collaborations and partnerships Media and Press: Press kit and media contact details for journalists and press inquiries

> General Inquiries: Contact form for general questions and feedback I feel like this Discord or the Reddit is perfectly fine for general questions and feedback

Business partnerships: not sure what kind of things could go under that... afaik all software implementations of jxl are FOSS and "pro bono" (no business model related to it). The only commercial implementation I know about is a WIP hardware implementation, but they cater to a rather specific audience...

I just noticed that the new page makes no mention of GIF at all, that should probably be added

We should probably always update the github page that we pulled them from first, then make sure it happens here. Would be great to dynamically pull the content from there some day…

is there no section talking about JXL animation?

It's human, but we originally designed the site in Webflow, because there was so much responsive to build out. We injected the custom code into the Webflow pages. To get it out before Apple's event Monday, we didn't have time to clean things up like we normally do.

Wait this is related to the Apple event?

Well it would be nice to get the revamped site up before potentially a lot of people are going to google jpeg xl ...

Then we have 25 hours left

let's make a checklist of everything that needs to be done before it can be set as the main site

How many sources have backed up Apple JXL? I thought it was just 1 leak?

Apple Insider exclusive

I'm traveling today with very limited web access. This issue on mobile is fixed in the following code. The changes need to be teased out of the HTML and CSS if someone has the time. It required some new styles and a removal of an old one.

Who?

https://appleinsider.com/articles/24/08/22/exclusive-every-iphone-16-iphone-16-pro-camera-spec-capture-button-detail-revealed from "sources"

Does Apple insider source mean confirmed?

I 💅🏻✨😩 take leaks with a grain of salt

usually* wtf lol

How tf did autocorrect get emojis from usually

Just highly possible to see

I've had it confirmed through a (decent) third source, but who knows if they'll actually talk about it even if it is an option. Fingers crossed though

Could be on the conclusion slide of iPhone 16

Anyone know if it’s going to come down to older models or going to be iPhone 16 exclusive ?

Other than Apple being Apple, there shouldn’t be any reason why it can’t?

We'll see if it's available for all devices supported by iOS 18

Fingers crossed it is

Also due to Timezones, I will probably be asleep during iPhone event, so I give everyone in the server explicit permission to dm spam me about JXL on iPhone tomorrow

I'll watch it even at 1 am

I will try to stay up but it’s at 3 am for me

I should go to bed now

What am I doing, I have important work to do later today and I’m taking about image formats at 2:54 am

https://tenor.com/view/off-batter-severe-neurodivergent-moment-look-at-him-go-gif-24056107

if this new site is gearing up to release in less then 24 hours for a expected bump in visitors then I hope what I brought up about discoverability of other parts of the site is addressed before then because I truly believe that most people are going to leave the site before they even realize there are other pages/sections besides the landing/home page

I've watched how people interact with websites and interfaces and I'm pretty sure a large amount of people aren't going to open that hamburger menu

I’m still for this idea

Even though there may/ will be more content later, right now there isn’t, and we’re launching pretty much now

So we should make the design based on what we have now, and then re add the hamburger menu if necessary down the line

the hamburger menu can exist it just shouldn't be the main way of finding other parts of the site

So have the direct links *and* the hamburger ?

It should depend on the width

uhh I'm not sure what the best layout/design would exactly be but I just know what the site has currently isn't good

Yeh

On mobile, hamburger makes more sense

But on desktop there is plenty of room to just lay each entry out

Would be too crowded if they are on the top bar

I meant just the top level ones

And then there can be a dropdown arrow maybe?

Even so, just the Resources tab on a top bar would be way better imo

It's supposed to give very important information to the layman

One word one link, or it looks too crowded

Maybe FAQs can go in the top as well

About, Resources, Tools, Media, FAQs

FAQ should be first on the list but yeah I agree

For the short term you could replace the hamburger with the word Menu

And a disclosure triangle

I'm one of them 😅 found the menu only on my second visit ! But the site is so beautiful I visited twice 😆

One thing I'll mention is that at first I thought these were sliders I could interact with, maybe just having the values with "Higher/Lower = Better" would work better

Actually... Why is the background image so large if only the upper half is displayed? And then the poor tiling has already been mentioned before

Might even be able to just remove that image entirely, we already have the waves flowing across the top

Logo has no glow on the top side with gaps at the corners

With the glow disappearing and the lines immediately changing color from green to blue when zooming or with the inspector open for me

Not too bad, especially with the header blending into the background

swapped the old and new pages

i hope I didn't mess it up

Only wonder if "Code Model" has to stay

People may wonder if it's a slogan

> JPEG XL is visually lossless at less than half the bitrate of JPEG.

it feels weird to say bitrate for a static image codec [⠀](https://cdn.discordapp.com/emojis/654081052108652544.webp?size=48&quality=lossless&name=av1_Hmmm)

May also confuse the average user

yeah imo this should be changed

Were they ever uploaded to the site? Still seeing the low quality version even with it moved to the main domain now, but don't want to make a PR if you already were (The PNG file on the Github also has jpeg banding in the dark areas which is odd...)

this is why https://discord.com/channels/794206087879852103/1256302117379903498/1282004878495060069 I'm currently working on a fixed up version of the encodes for the background image

Ahh, nice

what do ya think of these?

steps I took where to get the highest quality version I could get from Unsplash's servers (which is a source JPEG decoded to pixels as a PNG) then I converted the image to grayscale since it's supposed to be black and white and then I ran it through oxipng and used the resulting file to generate the WebP and JXL with higher effort settings for both formats

wait I think something might have gone wrong along the way....

wait no everything is fine I was just getting tricked by Windows Photo Viewer visually ruining images (I forgot it did that..)

What , what does it do?

when ever I open something in the classic Win32 Windows Photo Viewer it absolutely ruins dark areas

I tried running it through jpeg2png and jpegquantsmooth but nothing manages to fix the banding

I couldn't find a way to get original files from Unsplash's servers, the most close I could get was PNG reencodes. this is what their servers use btw: https://docs.imgix.com/apis/url

created a pull request I guess https://github.com/jxl-community/jxl-community.github.io/pull/28

Blue glow should have been removed everywhere. Not sure why it's back. It's only the desktop right now

The images shouldn't be repeating. I can't reproduce that. Should be set to cover, top center, and no repeat on tile…

Yeah, there shouldn't be a glow anywhere and we needed two different files for the wave. One has a higher amplitude, but it starts at a different point in the color shift, which is why it changes when changing screen sizes.

Ahh, right

Some smarty could probably change the SVG file so it changes amplitude depending on the screen size… but that smarty wasn't me

Is there a demo to play around with these values across different formats?

<https://squoosh.app/> was good, but it has outdated libjxl

Let's build one for jpegxl.info!

good idea

I dunno how best would be to showcase this demo, unfortunately, im also bad at webdev lol

I did think of adding the progressive slider Google had for their saliency demo, but wasn't sure if it would be out of place

https://google.github.io/attention-center/

Yeah, that's why I was asking if we could get it working on Safari

I guess we could have an all in one demo page with the progressive slider, compression comparisons, ect

Ah, right... Always annoying when there's one lacking support

Actually, it'd take some work, but I wonder if the WASM decoder and the recent Oxide progressive developer tool could be used instead of the strange HTML based truncation it currently uses

I also usually get better progressive decoding from oxide than the Lib JXL decoder

libjxl only decodes full passes currently

I just realized that the new website has no mention of any of the other implementations besides libjxl. jxl-oxide and jxlatte are not mentioned anywhere

Does it actually mention libjxl? Or is it just "JPEG XL"

Ahh yeah

Now some people on X use "JPEGXL". The logo of the new site may promote it firther

Don't underestimate the ignorance

the old logo is just a big X anyway <:logo:829708783336816671>

I made a pull request https://github.com/jxl-community/jxl-community.github.io/pull/31

Unfortunately it was forced to be dead

maybe I can build a progressive decoding demo using jxl-oxide-wasm

We're working on some tweaks.

Yeah I noticed the title is revised

Missing an &nbsp;

<@594623456415449088> continuing from voice chat. others and I found that the issue on the FAQ page with nested lists is not because of the markdown parser/library but is instead an issue in `JPEG-XL_FAQ.js` with the code that handles switching the display styles for the FAQ's elements for showing and hiding parts. it's setting the display style to `none` for all `p` and `ul` elements which includes the nested `ul` created by markdown library but when it comes time to change the display style away from `none` the code that does so in `JPEG-XL_FAQ.js` doesn't remove/change `none` for the nested `ul` element, it only does so for the top level ones.

hope this info helps you fix the issue because I don't know how to write JavaScript

Is the top logo meant to be in the center of off to the side?

Temp Fix Pull Request https://github.com/jxl-community/jxl-community.github.io/pull/32

Is there some proper unit to use so unexpected fonts don't wrap?

I'm assuming we get traffic data for the site, so we can see the impact of the event later today? (Assuming we're in it)

hoping someone can fix the layout collapsing when these comparisons auto rotate: <https://jpegxl.info/#:~:text=Visually%20Lossless%20Compression>

Easier to search without the space 😆

but JPEG&nbsp;XL is pretty easy to search, and readable

there are some formatting mistakes in the supported software page

also why does the menu use javascript instead of css

also the mail icon doesnt do anything?

the menu state is so busted

honestly shouldnt even be a collapsible menu

i was confused where everything was when I first saw the page

the elements that require javascript shouldnt be in the dom by default it also breaks reader mode

Is a generator used to make the website?

it was designed in figma, but I think we now want to just edit the html files directly, not regenerate them from some source

except maybe some simple thing to factor out the navigation stuff and the footer and do them with includes instead of duplication

that's generally what the generator is used for

can be as simple as to split it up

just need to figure out how to do this nicely in github-pages, which does not support the usual stuff like php

some people do a seperate repo with the source then just generate and push to the pages repo

I do that

I think there should be a way to do it on the same repo and have github actions do the generation somehow

I think there's a trick of using a separate branch for the sources, and using github actions to push the built version to the main branch on each push to that separate branch

How many builds is expected? I could possibly host the build system on a VPS if required

you dont need a server

it should be a static web page

I meant for building

Or is GitHub actions fine?

github actions should be able to do that

Is it more just finding the right tooling?

whole thing seems kind of unfortunate

I figured out the FAQ bug. The code was adding the answer css class to "ul" elements without regard for depth, causing the unordered list under the third answer being labeled as an "answer", thus hidden by default. When clicking a question title, it goes to its next sibling elements (i.e. the elements making up the answers), hides them and stops when it meets a question element. It doesn't go through the siblings' trees, so a mistakenly-created "answer" element inside would remain hidden.

The reason changing it to a number list fixed it was because it didn't check for a numbered list.

<@207980494892040194> thanks for looking into it! i fixed the bug and will send a PR after lunch

The fix amounts to only labeling the direct child elements of the sections as "answers". The "display:none;" cascades to deeper nodes fine.

looks like there is no built-in basic traffic analysis in github-pages, at least that's what I got from reading https://github.com/orgs/community/discussions/31474

good

well, I dunno. I don't want to have tracking stuff, but just some plots of number of hits, visitors, popular subpages would be nice

it would be nice to have some clue as to how many visitors we are getting

meh. if there's activity, it'll manifest in other ways

is there something like Google Analytics but without all the tracking stuff, something that just counts hits and let's you get a csv with the numbers so you can plot it?

there's probably a cloudflare app for that

I could also just make one of the images on the front page served from my own home page or by cloudinary, and count visitors that way. Just feels silly that github-pages does not let you access some very basic aggregated info from their server logs.

They have this thing: https://github.com/jxl-community/jxl-community.github.io/graphs/traffic but that's showing the visitors to the _repo_, not to the website

if you're gonna add a traffic-counting pixel, it could be nice to disclose it at the bottom of the pages

i'm for the idea of having traffic data btw, i just think people might wanna be made aware of it.

"you've been counted"

just add an actual visit counter on the page, they are always fun

You are the 1,000,000th Visitor of this Page!

https://tenor.com/view/war-vietnam-ptsd-shell-shock-moment-gif-3022747568394546158

adding an old-fashioned visit counter to the page may actually be nice. any suggestions for which counter thing to use? I'd prefer to have something that is 1) free (duh), 2) doesn't do dodgy stuff privacy-wise, 3) allows getting some simple plots out of it (not just the current count but also something like a plot of traffic per day)

i don't know of any, i haven't had the use for one so didn't research

if i had to make one from scratch i'd actually make it PHP-based, using PHP to add to the visit count in a database of the site's directories

you'd have a "total hits" database for displaying the count to the visitor

and for plotting, you could have a separate database for every period just containing the hits of that period

No PHP on Github Pages

external PHP as iframe? :3

Hmmmm

you can use cloudflare workers for a counter

i use <https://github.com/dsrkafuu/moe-counter-cf> for my website

now this makes me think, are tracking pixels just PHP scripts that serve an image? that would be simple

oh that's a classic

Usually, or something along those lines

Effectively just a grabify