JPEG XL

does JXL's Brotli allow use of the brotli DICT?

Yes. Which is part of the reason why we made it so a decoder does not need Brotli to decode the image itself, only for metadata and jpeg bitstream reconstruction (but not for rendering of recompressed jpegs). Keeps the binary size of a minimal jxl decoder lower.

yes -- it is the same as usual Brotli Brotli is covering about half of all the internet traffic, JS, HTML, JavaScript and the ratio is still increasing

if you're worried about decoder binary size, imagine having to ship an entire AI system (JPEG AI)

when bytes are decoded from the static dictionary -- it is faster than freshly decoded bytes by prefix decoding, and prefix decoding also uses lookup tables that generate some memory system pressure

of course should be relatively rare for jxl metadata

XMP xml?

some xml may be copied from static dict, but I didn't use such metadata originally in synthesis of the static dictionary -- so likely a poor match

if there is human language, that may benefit -- but I suspect most of the metadata will be computer generated numbers

(actually I don't know what is there... never looked :-D)

here's a random xmp produced by Lightroom: ``` <?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?> <x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 7.0-c000 1.000000, 0000/00/00-00:00:00 "> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="" xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/" xmlns:xmp="http://ns.adobe.com/xap/1.0/" xmlns:hdr_metadata="http://ns.adobe.com/hdr-metadata/1.0/" xmpMM:OriginalDocumentID="519CECB836638319867FA7E237E9AAF4" xmpMM:DocumentID="xmp.did:7d7c3a7c-7c47-46d8-8233-0bfa9f82037a" xmpMM:InstanceID="xmp.iid:7d7c3a7c-7c47-46d8-8233-0bfa9f82037a" xmp:MetadataDate="2024-09-13T09:03:03+02:00" hdr_metadata:ccv_primaries_xy="0.7079,0.2920,0.1700,0.7970,0.1310,0.0460" hdr_metadata:ccv_white_xy="0.3127,0.3290" hdr_metadata:ccv_min_luminance_nits="0.417283" hdr_metadata:ccv_max_luminance_nits="1889.639885" hdr_metadata:ccv_avg_luminance_nits="102.881766" hdr_metadata:scene_referred="False"/> </rdf:RDF> </x:xmpmeta> ```

did you make brotli?

at least some of that stuff should probably have some good matches with the brotli static dict

the string `xmlns:` is in the static dictionary

so is the word Document

I did most of the design and Zoltan most of the implementation for Brotli, but to some extent our roles crossed (perhaps 10-25 %)

geez this server has so many people who made impressive algorithms

Thank you!! 😄

not to sound cringy / corny but you guys are the kind of people which i want to become

also it looks like Lightroom is adding a few kilobytes of padding with lines full of spaces to its xmp, and they're using uncompressed xmp, I guess that's just to allow editing metadata without having to rewrite the whole file

yeah, like how FLAC adds padding blocks

it is possible -- I had my idols in youth when I was ~20 I thought that I'd never be able to design something as complex as gzip 😄

most things I use do that

where most people had pop singers as idols, i have data compression algorithm designers

my friend wrote IRC, and I was one of the first five users, and wrote the first chat bot for it (in 1989 or early 1990)

that sounds really cool

i guess being in this server is probably helpful for me to learn about these kinds of technologies

are you in a CS program?

not yet, but am planning to

senior highschool?

yeah

this is good times for learning to program more

i wrote a flac decoder a few days ago in C

do you do music, play an instrument or otherwise have interest for sound?

very simple, and still haven't fixed all the bugs in it, but it decodes most stuff fine

trumpet

nice

I'm planning to make an audio compressor or three 😄

I have new ideas in this space

some of them we can write in the opensource from scratch

with how FLAC uses rice coding, maybe I should make the "Free Lossy Audio Codec" that quantises some of the prediction data like how JXL has that multiply residual thing in the MA tree

we have stronger, better ideas in this space

yeah, i was just thinking of random ideas

hybriduint residual coding?

we explored this space with talented interns and volunteers, and one full time engineer for a few years

Trying a somewhat larger XMP file from a random image: ``` 13428 test.xmp 2999 test.xmp.br1 2316 test.xmp.br10 2271 test.xmp.br11 2827 test.xmp.br2 2770 test.xmp.br3 2673 test.xmp.br4 2518 test.xmp.br5 2512 test.xmp.br6 2515 test.xmp.br7 2513 test.xmp.br8 2507 test.xmp.br9 2997 test.xmp.gz1 2936 test.xmp.gz2 2904 test.xmp.gz3 2791 test.xmp.gz4 2730 test.xmp.gz5 2701 test.xmp.gz6 2688 test.xmp.gz7 2688 test.xmp.gz8 2688 test.xmp.gz9 ```

what company are you from?

brotli has an effort setting?

Google Research

not the chrome codec team?

I have worked with them for WebP lossless for ~1.5 years full time in 2011-2012, but I was never in the Chrome team officially

so here brotli effort 4 is already smaller than any effort gzip, bumping up the effort shaves off 400 more bytes

nice!!

oh yeah, webp lossless is cool

Thank you!!

Brotli is based on many of the ideas I got in WebP lossless

the same for JPEG XL

oh yeah, you're that guy who people keep harassing about how OTHER SOFTWARE doesn't support WebP

Surprised you didn't notice `--brotli_effort=` in some of the cjxl commands haha

surprised as well tbh

the idea of many static entropy codes that are chosen dynamically (instead of the more classic arithmetic coding context modeling) was new in WebP

> static entropy codes that are chosen dynamically Is that when you store the distributions at the beginning of the stream instead of updating them as you are decoding?

have the brotli spec downloaded, haven't read it yet

Which I then reply pointing out how good Lossless WebP actually is if they tick the checkbox

yes -- that is a bit of a design mistake however, since it slows down getting the first bytes -- it would be nicer if the distributions could be delayed more

ends up beating lossless AVIF somehow

<:kekw:808717074305122316>

in AV1 design, they didn't use their absolutely best engineers to think about lossless -- they thought that if they do everything right for lossy, lossless will be automatically efficient -- but it is not so

there may be interesting ideas and people <https://encode.su/threads/4291-ADC-(Adaptive-Differential-Coding)-My-Experimental-Lossy-Audio-Codec> <https://hydrogenaud.io/index.php/topic,125248.0.html>

is it because lossless AV1/AVIF has to turn off a significant amount of coding tools to stay lossless?

lossy and/or lossless?

my usual approach is to ignore everything there is and try to have a fresh start in a domain, that way I can understand every part (at least to some extent)

both, but more effort in psychoacoustically-lossless lossy

we have a proto that can compress 65 % more than opus for psychoacoustically lossless

very nice

is this going to be released under AOM?

we have a new "butteraugli for audio", called zimtohrli

bruv just dropped the knowledge of some a bombs existing here

AOM is a bureaucratic process with experiments taking six weeks or so -- I don't have enough manpower for that, so it will be mostly hacking at this time

is there a GitHub repository for this?

or GitLab

or is it still just internal testing

zimtohrli is here: github.com/google/zimtohrli

i think it's pretty unfortunate that there are lossless audio codecs better than flac already, but they aren't open source (at least the encoder part)

how are they with speed though?

the early experiments of the audio coding are in github.com/google/ringli

zimtohrli -- I think -- can run 30x audio speed (not quite sure about this)

ringli is roughly similar

I'm thinking of starting first the serious work with a 'guetzli' / 'jpegli' kind of approach

where opus coding would be modulated by zimtohrli

Metadata compression is one of those things that I expect will be more and more useful in the future. For web delivery, metadata used to be something you just strip, and that's it. But this is changing: JPEG Trust (C2PA) and new legislation that will make tagging of AI images obligatory, for example, will require metadata also for web delivery. Also for HDR, some metadata beyond just the image colorspace info will likely be useful, e.g. tone mapping recommendations. Same thing with new ways to render images (like 360 images etc) or to do things like annotating clickable regions in an image (basically embedding a html <map> into the image itself, rather than doing it at the html level), etc: all these things will require metadata. With the `brob` box approach I think we made JXL pretty future-proof in that respect. JPEG, WebP and AVIF are stuck with uncompressed metadata only; PNG can apply gzip on metadata but PNG is usually not great for web delivery.

that would likely improve opus 25 % or so

also metadata is just nice to have

http://audiograaf.nl/losslesstest/revision%206/Average%20of%20CDDA%20sources.pdf TAK is a bit slower than FLAC on decode, but faster and more efficient on encode

also see <https://wiki.hydrogenaud.io/index.php?title=TAK>

time to add ringli decoder to symphonia crate lel

too bad symphoinia is ~~dead~~ on life support

in maintenance state?

not really, it's not abandoned, but the only maintainer is looking for other maintainers. it's still "alive" in that sense

Maybe you can tell me - can opus (as a format in general) behave like all other lossy codecs, I mean encode with given 'quality', rather than encode to target bitrate?

there has been about 20~ commits most being minor for the past while

i agree, that would be nice

It is the main reason why I'm using vorbis when I need lossy

but at least these are also interesting ideas or old ideas with better implementation that are worth looking at or comparing and for example HALIC is a very balanced and fast codec for photos or Marcio Pais makes very strong compressors

But as far as I understand Zimtohrli is exactly about it

note that there exist a GPU FLAC encoder (`flaccl` from CUETools), that can reach easily 350x realtime speed <:CatSmile:805382488293244929>

GPU accelerated audio?

i guess but why?

just to encode really fucking fast and compression-wise it is quite good too

It can use effort up to 11, afair, that is too slow on CPU

i gotta try that on my desktop later

windows program, but works nicely with wine for Linux

FLAC?

i thought it went up to 8

9 for experimental

up to 8 for Xiph's flac encoder

flaccl have more presets but cannot beat Xiph's encoder on size (with high compression settings)

oh, you're using a different encode

do not hesitate to look at my lossless audio benchmark https://docs.google.com/spreadsheets/d/1H_icYtkqV0C4L7yRMKIMdwE8dxGyi9wtkB_H2NL4J7o/edit?gid=0#gid=0 many formats tested, as well as encoders unfortunately not representative for flaccl, because for such small files the GPU init code take most of the time

I'm doing another one rn, with actual track (3~5 minutes), with the idea of "reaching smallest file size of each codec" but it takes sooo much time lol

Xiph's encoder has `-8pe` which takes ages

yeah but you can go further `flac -P 0 -8ep -r 15 -l 32 --lax` and even further `flac -P 0 -8ep -r 15 -l 32 --lax --no-seektable -A subdivide_tukey\(50\)`

very nice data

[⠀](https://cdn.discordapp.com/emojis/721833660457943151.webp?size=48&quality=lossless&name=av1_pepeShy)

oh geez

doesn't `--lax` break compatibility ?

With hw decoders? Maybe, but who cares

yeah, only HW decoding isn't guarenteed by `--lax`

i guess these days nothing really uses hw flac

since it's pretty easy to decode in sw

And because hw players has gone

there's also this really nice benchmark https://wiki.hydrogenaud.io/index.php?title=FLAC_decoder_testbench to test which decoders (HW/SW) support which FLAC (subset, non-subset, hires, variable blocksize, ...)

also rust jpegli decoder I think is worth it too or as part of rust jxl for jxl/jpeg decoding, so more companies will switch from libjpeg and use a shared decoder for both jxl and jpeg

~~dropin libjpeg decoder alternative that also does jxl~~

libjxl decoder hooked up to lossless jpeg transcoding

would be nice -- however, we are not prioritizing this right now with our limited resources

Is a Rust JPEG XL encoder in the works?

more or less -- the team is learning Rust, Luca is improving the Rust language itself to be a better fit for our demands on platform-independent SIMD use, we have met with Tirr from jxl-oxide fame

we haven't yet started -- at least not outside of what code is in jxl-rs

rewrite it in rust lol

In all seriousness I should try to rewrite my FLAC thing into Rust

it is possible that encoders are less of an issue to be in Rust, but decoders definitely are helpful to be in Rust

Are you planning JXL-rs to be a direct port or to be separate projects?

I guess, as encoders just take in some pixels, where decoders take in complex bitstreams

yes, maybe after rust-jxl, also brotli decoder like <https://github.com/google/rbrotli-enc> because basically it's all also related to jxl in some way

Full end to end Rust pipeline

Also someone should write littlecms to Rust

especially if brotli decoding and encoding at fast speeds will be more optimized and get a smaller gap to zstd

I read that as "Subdivide Turkey"

yeah for a long time me too <:KekDog:805390049033191445>

I still don't know what's tukey, even tho I saw it in a few encoders already

oh and recently Xiph's FLAC encoder added support for multithreading 💯

I'd assume a decoder only at least to start, keep binary size small for adoption

I guess that’s what happens when you encode political debates

I have a rust jpegli decoder on my backburner. Not sure when I can work on it, busy with school atm.

One problem is, I have next to zero C++ knowledge, so trying to understand the source code is a bit annoying.

We've got cross-channel spam incoming!

Dunno how to ping moderators here

<@794205442175402004> can you take care of them, please?

done <:BanHammer:805396864639565834>

only annoying thing is that all the channels he spammed in now look like they have new messages even though the spam messages are deleted

Yet another joy of Discord

You think cjxl does some mining on -e 11? 😅

JXLcoin

Mining involves compression images to below a certain size

That’s what made me check

Someone Add to the licence: Don’t disable Jon’s personal Monero miner at s 11, it’s how he funds the project

Just as a joke

Crypto if it was actually useful

Opinion on Storj / FileCoin?

Effort now increased.

from which effort setting to which setting did you go?

Looks like they were using effort 4 or lower: https://discord.com/channels/794206087879852103/794206087879852106/1272638277589012573

I hope they're at least using effort 6

Proof of Optimizing Size (which abbreviates to... poos.)

i have a page on my website where i show some (old) scenes i made with blender, and back when i first wrote this page i had the user download 11mB of PNGs

now it's 450kB of JPEG XL thumbnails linking to PNGs, and that's after adding a few new renders

(well, i still have 3 really big GIFs i need to optimize or convert to videos...)

I remember there being a ridiculously tiny frog picture on the JPEG XL community website, but I can't find it anymore. Or am I confusing it with something else

Oh I found it <https://www.jpegxl.io/faq#vast-header>

why is a frog there‽ lol

I know what presentation it's referencing and it does not have that frog image

it claims it's a 117 byte JPEG XL file but that doesn't appear to be the case

It's much larger

Oh it's a transfer size vs resource size thing?

But that doesn't make sense either

this is what/where it's from https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.gde87dfbe27_0_49

notice the lack of frog?

no clue why that frog image is on that site

Hmm I do notice a distinct lack of frog yes <:Thonk:805904896879493180>

It looks like my beloved frog is in fact 29.5 KB, but I don't get how it has a transfer size of like 600 bytes according to Thorium

The transfer size changes every time, probably a bug in thorium. This being HTTP compression is out of the question

I'm noticing other problems on that jpegxl.io site. such as how one of the images isn't loading/rendering because it requires AVIF support with no fallback

Ohh is this the presentation that was given in this discord and Jon recorded? I was watching that but haven't finished it yet

Do you have the MP4?

some of the stuff on that website is also quite outdated (e.g. https://www.jpegxl.io/safari)

I don’t think jpegxl.io has been update for a while

No, it's on their youtube channel

If you look at the bottom it says archived

Link?

revision history - change picture to frog :3

sure, one sec

https://www.youtube.com/watch?v=VtZ9_UmCd5M

that one is in Dutch though

Does YouTube auto captions work with it?

Or are these slides the exact same content?

> In a presentation about JPEG XL, I've found a funny example that displays how efficient JPEG XL is: > > 117-byte AVIF file: "Hi, there! I am an AVIF image, with the brands avif, mif1, miaf, MA1A, encoded with libavif, and you should handle me as a picture, and my dimensions are —" > > 117 byte JPEG XL file: I think it's meant to be a joke but wasn't made obvious

Or they couldn't find the actual JXL file and just used a random one as example

They probably were looking for that JXL X logo

Oh lovely, they even have a 'breakdown' of the ANS patent, which doesn't mention anything about them being different versions... https://www.jpegxl.io/patent

seems interop 2025 is already taking proposals? i see jxl is already up but as usual links only to the ugly page at jpeg.org without any mention in op to jpegxl.info that includes way more useful and impactful intro

it's just going to get declined again. the WPT is meant to make sure things that all browser venders already agree on work properly across said browsers not to push things that *should* be supported across browsers

the Chrome team is just going to say "no" and the result will be the same as last year

... Did they not learn anything?

Even if it gets declined immedeately again, we got a decent bump in news last time around, and now we have Apple making people aware (Vaguely...) along with a good website to point people towards

Plus we have plenty of time to make a case instead of having to rush with 3 days left on a deadline :P

Actually let me post this in <#803574970180829194>

interop is flawed in that anonymous voting is actually counterproductive in the way it is done. instead of enabling free voting, it incentivizes manipulation behind the scenes in ways that cant easily be found out and exposed

ie by say google telling everyone individually to ink certain proposals or boost others. there should be a trackable requirement that all important proposals get read and/or internally commented on. even the most cursory discovery into the hxp proposal would get webdevs and web services interested - has almost noone in interop even clicked on its link despite sitting at the top for months?

voting should be informed, not based on ignorance or instructions to vote on 'only our stuff' and dont bother about anything else. interop is not supposed to be about browsers themselves but websites, web apps, web services, embedded web content - thats what needs 'interoperability'

I'm just going to say it

I think JPEG-XL looks better than JPEG XL

I of course respect our hyphenless format and shall call it by its proper name but I had to get it off my chest

https://tenor.com/view/civil-war-trailer-captain-america-gif-14236920

On Android, is there a gecko based browser which open jxl images ? Waterfox mobile fails to do it, despite the activated flag

no idea, gecko browsers are so bad on android I dropped them all long ago lol

But they are the only ones which allow me to sync bookmarks between all my desktop instances... And Firefox is not so bad at the moment

firefox nightly for android could be the first option to consider (jxl still disabled by default). the about: settings can be accessed using a special url

waterfox has an android release with jxl updated and on by default (based on upstream firefox, not esr)

I use waterfox (mobile) and it doesn't seems to work 😔

odd, theres jxl activity for android. maybe upcoming changes

I'll have a look their issues

Is there?

in a 'future' branch i noticed jxl in recent changes with a gradle folder, assumed the waterfox activity covered that for multiple platforms. could be mistaken but i assumed it had jxl since theyre active patching that

The flag is available, it was promising. But jxl test pages return blank frames

seems waterfox android shows nothing out of box, wether jxl flag is on or off firefox nightly has jxl off by default but shown when enabled in about:config (with the usual issues from old patches - no transparency, animation, hdr)

Firefox allows adblock on android, while chrome does not, afaik

I use Cromite it has it baked in

Brave also has native adblocker, and it has some fancy sync function too

They're pretty descent now, if you mean in terms of performance. Firefox for Android scores higher than Chrome on Speedometer 3.0 even. Or it did not too long ago, at least. Marginally higher, but still. They're basically on par

What about efficiently though?

not sure, I don't need any of them since adblock exists in Cromite and that's all I have cared for

What I also miss in chromium based browsers is the ability to be easily connected to more than one google account. I'll have a look at floorp

thorium supports multiple profiles for that, it's quite convenient

so does chrome, fwiw

ah right, it does

at the same time ? I have chrome at work and once I'm logged in a profile I must explicitly switch (log out from the previous one to log onto the next one)

I have personally adopted the Firefox container workflow but when I was using thorium, yes I could have multiple profiles loaded at once

You go the the profiles menu

I am currently running chrome with both my personal and my work profile

the PNGs openstreetmap.org serves seem to be pretty well compressed

losslessly recompressing them with cjxl on effort 8 or lower often leaves you with bigger file sizes. Effort 10 makes the JXL equivalents smaller, but not by a lot

maybe they're palette

It didn't look like it because there's sub-pixel color blending at the borders of shapes. I also tried the lossy palette option in cjxl but it didn't seem to change much so I'm not sure if it worked

Delta palette only works in 0.6 due to a bug

Although bear in mind it's lossy anyway

what is, png to lossless jxl conversion?

Delta palette reduces the number of colors in a JXL image. I don't think the input type matters. Up to thousands of colors instead of PNG's 256 limit.

but just `cjxl image.png image.jxl -d 0` won't change colors so they conform to a palette right?

`-d 0` is always lossless

unless doing something really weird

Ah right that's what I was thinking, I was confused thinking "Although bear in mind it's lossy anyway" implied that PNG conversion is always lossy even with `-d 0` somehow

Once delta palette gets fixed I hope they use pngquant's algorithms

That was in reference to my message about Delta Palette

Delta palette isn't just reducing the number of colors, it then also mixes the pallete colors to generate new ones to fill in the gaps

So instead of finding the most common or neutral color, it finds what two colors best match when mixed, and when combined with other colors (In an ideal world)

Although this is just my understanding of it, <@532010383041363969> came up with the idea and wrote the code

you can use delta palette in current libjxl, but you cannot adjust the quality. you have to do `-d 0 --modular_lossy_palette --modular_palette_colors=0`, which is rather confusing since the result will actually not be d0

eventaully will it be implemented as a standard coding tool for lossy modular?

and just auto enable when it finds itself helpful?

Using that results in a lossless file larger than any effort setting, so maybe it's using the predictors, ect for delta but not actually using the delta palette encoding? Using the 0.6 version of cjxl correctly uses it, so even though the console output says lossless it's actually lossy like you say (And takes 2 minutes to encode instead of 2 seconds with normal modular)

if jpeg uses dct and jxl too, could it be possible for a jxl encoder to use some parts of existing jpeg hardware optimized instructions ? in order to ease the use of jxl in digital cameras

I would bet not worth it

I guess you could basically use a pre existing JPEG hw encoder and pipe that into lossless jpeg reconstruction

It's too bad there isn't a jxl optimizer like jxltran

If it’s lossless you can always recompress it

compressing uncompressed metadata boxes, reconstructing jbrd boxes, changing orientation, converting huffman to ans, etc.

stitching and cropping would be possible but not as simple as those other things

well, cropping would be simple.

but not necessarily.

``` % cjxl image.png image.jxl -d 0 JPEG XL encoder v0.11.0 0.11.0 [AVX2,SSE4,SSE2] Getting pixel data failed. % file image.png image.png: RIFF (little-endian) data, Web/P image ``` <:WhatThe:806133036059197491>

I keep getting scammed by false extensions

Telegram does that a lot for 'jpg' previews of WebP files (It's actually all WebP)

Oops! All WebP!

I got this particular one off github

I like testing images like these because I feel like the smarts in the encoder will do well for the continuing patters and somewhat limited colors

I had that on my Minecraft map image, where smaller group sizes would do better because of more palette

How good is the encoder at figuring stuff like that out?

Oh I was confusing groups with something else, so it can't dynamically adjust group sizes which is fair

just encode each Chunk as a Group <:wesmart:512506347057840129>

chunks are 16x16 and MC textures are 16x16

That would only work for top down not isometric

That would actually explain why `-g 0` was consistently the best on a map image I tested... Well maybe not but still fun

ofc, still amusing

most likely smaller groups lead to more accurate ANS frequences for each group

Hi, do you have any parameters to share for FLAC optimization?

`flac --best`

Ah, is there nothing more hardcore?

yeah

flaccl is reported to sometimes create slightly smaller files

`flac -8ep -r 15 -l 32 --lax -P 0 --no-seektable`

it hasn’t really been my experience, but the size is similar and it’s certainly fast, at least

I see, thanks for your feedback.

impossible, when using appropriate params with Xiph's `flac` encoder

(http://cue.tools/wiki/FLACCL)

Don't forget about ``-A subdivide_tukey(69)`` <:trolldoge:1200049081880432660>

ofc, how could I forgot about it <:KekDog:805390049033191445>

`--best` : 3.661669 MiB `-8 -r 15 -l 32 --lax -P 0 --no-seektable` : 3.660264 MiB `-8ep -r 15 -l 32 --lax -P 0 --no-seektable` : 3.645565 MiB `-8 -r 15 -l 32 --lax -P 0 --no-seektable -A subdivide_tukey(69)` : 3.668542 MiB I've never understood what `8ep` changes.

is it not too inconvenient not to have a seektable?

F, I really forgot `ep` lol ``` -e, --exhaustive-model-search Do exhaustive model search (expensive!) -p, --qlp-coeff-precision-search Do exhaustive search of LP coefficient quantization (expensive!). Overrides -q; does nothing if using -l 0```so always better to use them

well you can keep it but I tried without it on both PC and Android phone, I could seek the file without any issue

flac’s documentation says seeking will work but might be slower

it also says that there can be an arbitrary number of seek points, each taking up 18 bytes

the right balance probably depends on the file and use case

they give as an example that 1% seek point density would be less than 2 kB

too much for me 💯 <:KekDog:805390049033191445>

can you share the file ?

we'll need to wait a bit for best encodes <:KekDog:805390049033191445>

I've got quite a few files to process, so it needs to stay reasonable time-wise. x)

you have a problem with your `-A subdivide_tukey(69)`, I launched it on my machine and it only did 1% in 18 minutes (which was quite expected)

then go with `-8ep -r 15 -l 32 -P 0` if the speed is ok for you otherwise lower either `r` or `l` values

Keep misreading this as subdivide Turkey 🇹🇷

It might not have been taken into account 'cause of the parentheses.

OK, thanks

And `--lax` was for what?

`--no-seektable` too

I don't understand libFLAC's descriptions.

to be able to use high `r` and `l` values, but therefore not HW decode *guaranteed*

just to not output a seektable typically they are points to say "hey, 30sec from start is at +30k bytes from start" as said spider-mario, removing it you get slower *seek*

so great to use seektable for movies/videos/... but not so useful for short songs of ~5 min imo

Yeah, that's what I was thinking.

What are the max values without `--lax`?

And if I run into any reading issues on other machines in the future, I can always add it later, right?

if you say about seektable, yes

Nah, `--lax`

r = 8 l = (sample_rate > 48kHz) ? 32 : 12

Thanks

yeah, just re-encode the file without `--lax`

`-r 15 -l 32 --lax` : 3.645659 MiB `-r 8 -l 12` : 3.647330 MiB

It’s the little grains of sand that make up the beaches, as they say.

Speed difference?

`-8ep -r 15 -l 32 --lax -P 0` : ~1 min 30 s `-8ep -r 8 -l 12 -P 0` : ~7 s

guess what got an outage of a few seconds, so my best compression command got killed <:KekDog:805390049033191445>

speaking of flaccl: it seems to have an edge case where its output can be wrong (only when using experimental options though), see <https://github.com/gchudov/cuetools.net/issues/315> unfortunately there's no sample file included on that issue, and i couldn't reproduce it with ~randomly generated audio either, so i hope they respond and post the file so i can try to debug it

CUETools encoders are really [⠀](https://cdn.discordapp.com/emojis/862625638238257183.webp?size=48&quality=lossless&name=av1_chad)

I was in energy-saving mode, so my experience is biased.

Watching an artist draw on another server, and they did this just because I mentioned how close to 4096 it was...

DISCORD EMBEDS ANIMATED WEBPS NOW

[av1_woag](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&quality=lossless&name=av1_woag)

It's beautiful 🥲

https://github.com/discord/lilliput/releases/tag/v1.3

note: that release is a rollup of everything they done since like 2018

however the animated WebP support landed it's initial commit 3 weeks ago with it's last batch of fixes 3 or 2 days ago

ICC and HEVC support is also relatively new

massive kekw that no jxl or av1 input video support

Not much point in adding JXL and AV1 to the CDN when the client won't accept it

That's not how it works though. First and foremost for JXL, Discord never shows you the actual picture itself. It only ever shows you its generated thumbnail, which is perfectly adequate. secondly, Discord Client already supports AV1.

it'd be a no brainer to support AVIF

I swear I have gotten Discord to naturally embed full original images without them going through the thumbnailer

I think it depends on screen res and image res or something

I've never seen it happen outside of client mods

I remember it happening when testing out ICC profiles back before the thumbnailer had any kind of support for them

for some people the images displayed with their ICC profile which could only happen if the original image was shown and I vaugely remember resizing the client causing the image to switch

The second image here loads as the original PNG when clicked with the inspector open

Doesn’t work for iOS

Chrome browser supports the animated webp... Bot not discord in the browser <:galaxybrain:821831336372338729>

I saw it on iPadOS once. The preview looked weird due to the ICC profile being stripped, but then clicking on the image to expand it displayed the image correctly.

It probably wouldn't be too hard to make a webextension that renders media formats unsupported by Discord

You could make it so it automatically upgrades any media that has the extension of a format that the browser recognizes from a "file upload" container to an "image embed" container

There are extensions like that, but only client side. Others will not be able to see the "embeds"

Yeah, it would only be useful if you specifically want to use those formats with others, like us here in some cases or apple users that deal with HEIC files

does anyone by chance have an ocio config for xyb?

update: i identified and fixed the bug <https://github.com/gchudov/cuetools.net/pull/353> the issue was that the code assumed that the average size of some slice of residuals would always be ≤ 4 bytes, which is very rarely not true cc <@693503208726986763>

https://cdn.discordapp.com/emojis/852007419474608208.png?quality=lossless&size=48

nice work <:PepeOK:805388754545934396>

I keep forgetting that I wanted to submit a pull request to CUETools to change some of it's default settings

and I uh only remember what one of those settings is, said setting is the resolution limit for downloaded album artwork as it's only like 300x300 or something and the resizing process of the program loses metadata and such

I should do one too for their ALAC encoder <:KekDog:805390049033191445> almost half of the CLI options are not in the help message lol, you can only use them if you read the source code

On the Guardian, the jxl pictures become really blurry at small resolutions with DPR=2. It looks like a distance of 5 to me. https://media.discordapp.net/attachments/794206087879852106/1291243470828077086/comp.gif

Using this image from here: https://www.theguardian.com/world/2024/sep/28/mexico-hurricane-john The jxl here looks super blurry at a resolution of 1240x744 with dpr=2.

I'm assuming efforts 6 or 7 are used but libjxl doesn't perform well at these low bitrates.

Effort 3 does not look worse than effort 8

In my experience. At d=1

What does effort affect then?

At least for larger distances effort changes result a lot. Size "switch" happens on e2->e3, and quality switch (read - adding strong blur and *large* ringing) - on e4->e5. But below e5 large gradients can become "banded" (not real banding, I just don't know how to describe this effect)

So Lower efforts mean doing more of a “quick and dirty” job?

that's the idea

Yes, but I personally prefer e4 look, rather than e5+

Effort 5 just looks horrible imo, worse blurring than efforts 6 & 7 while being much slower than effort 4. The worst of both worlds

I love how on nights with particularly clear skies, if you leave the urban light polluted areas, and look up at the night sky, you can see the JPEG compression artifacts so well <:BlobYay:806132268186861619>

What tools exist for analyzing ICC profiles?

cd-iccdump, displaycal-profile-info, Apple’s thing

(the latter two are probably more useful because they actually let you see the curves)

thanks

Blocky gradients?

In my experience e3 can look worse than e8.

Not blocky, if you mean blockiness like jpeg does

I only tested at d=1

Not at the same bpp? Then it's not a fair comparison.

Yeah, I didn't do a real serious comparison, but I noticed they looked different, but not necessarily better or worse.

I noticed that the way the image looks doesn't change until you go from e=4 to e=5

and between e=7 and e=8

so everything e4 and below looks the same. And everything e5-e7 looks the same

e4 top, e5 bottom. Look at the sky between people

Yeah, the one on the bottom has slightly more smoothing, probably the gaborish filter

e1-e3 are literally identical. I think it's only a lossless change to the ANS coding. e4 is slightly different but not a noticeable improvement imo. e5 starts using more fancy features like gaborish and the like. It suffers from even worse blurring than e6 and e7. e8 reduces the blurring somewhat. The metrics say otherwise but I can't really tell the difference between e8, e9, and e10 tbh.

Source: my eyes 👀

All of these were done on photographic images at the same bbp

No, gaborish was off for both

In case if someone wants to compare. Parameters are in names

Well it looks like some deblocking filter

i use this when i need more detail than displaycal shows https://www.color.org/profileinspector.xalter

Is there a good library for parsing ICCv4 stuff let alone ICCMax? the ones I have used in the past are... not great

iccmax especially, talk about a behemoth of a spec

wow, is it really still compatible with Windows 95? respect

I mean, sure, not the most modern-looking software, but still

for one thing, despite its apparent compatibility constraints, it didn’t break down in a somewhat high-DPI (150% scaling) environment

windows software? oh no

less ideal but still usable

if it works on Windows 95, it should hopefully work in Wine

a shame they don’t make the source code available, though

the sRGB

i don't think it's dpi-aware at all? it just gets scaled by windows, so there's no reason for anything to break

I guess some would consider sRGB _the_ "standard RGB"

Jake Archibald (from AVIF has landed -fame) has been advising Guardian in the past on image quality https://jakearchibald.com/2020/avif-has-landed/ In my experience Guardian has the worst quality of images from all serious sites in the web. This has been to make images load faster. It is not compatible with my perception and I have informed Jake Archibald about my opinion. It seemed to me that he wasn't able to integrate my feedback into his value system of speed/quality/size of images.

there is a special heuristic for 8x8 dcts to add the top left hand corner 2x2 values at finer resolution if the block doesn't have high frequencies -- perhaps this is turned off at e4

larger integral transforms interpolate more appropriately plus there is a 8x8 dct "hack" that uses more precision for quantization if there are no high frequencies, see: https://github.com/libjxl/libjxl/blob/42422b4a12aeaa095bb5d71d7bc330a519cbe1f2/lib/jxl/enc_group.cc#L207

How can it change the quantisation midimage?

What is *quant?

Sounds similar to jpegli

That's a shame, it would be nice to bump up the jxl distance to at least 2-3 instead of 5-6. Also here is a gif comparison if the animated webp doesn't work.

I mean it doesn't help the AVIF is 50% larger

That's what's confusing to me. If the Guardian has the philosophy of "compressing images as much as possible", then why are they bit-starving jpeg xl more than avif? Do they not know that avif performs better than jpeg xl at very low bpp?

if anything it should be the other way round

avif gets really low bitrate and jxl gets slightly higher

as that's each format's strengths

Exactly, jpeg xl's strengh is faithful detail retention at higher bpp, with progressive decoding as a cherry on top

Right now all they are doing is making jxl look bad in comparison to avif (to the layman of course, we know better)

It really is a bad look for jpeg xl. All they will see is a blurrier image and discount the benefits it brings to the table.

is there a way to tell libjxl to target a certain bpp / filesize instead of quality?

argh those pesky extra large jpegs

we had that at some point but it was just doing binary search. Generally it's a bad idea to target bpp and not quality. Some images just have more entropy than others...

if i want to match bpp with another image should i just use a script to binary search?

yeah

usually it makes the most sense to use jxl distance settings and then let the other encoders match bpp 🙂

the other encoders are generally worse than libjxl in encoder consistency — the actual image quality you get with, say, `avifenc -q 80` fluctuates quite heavily from one image to the next

makes sense

If any of you all have a working binary search script please send it my way, it's exhausting having to target file size by hand 🥲 . I'm on Windows btw

I have one for classic JPEG, shouldn’t be too hard to adapt (although it takes the largest under a given limit, not the closest to the target)

it changes it by *quant++; --- by one-upping the quantization number

quant is the number used to change all quantizations (single number for all XYB)

it is the same heuristic in guetzli and jpegli -- some user of guetzli who was warking for specsavers complained about the blockiness, and that caused me to add this heuristic in guetzli -- and later we kept it around in a more advanced form

How does the number work?

Does it just change some value in a sub image?

it is a number that is used in decoding to multiply the coefficients

there is one number per integral transform -- it is a 8x8 sub image but only has values where transforms exist

What is integral transform?

32x32 dct, 8x8 dct, 256x256 dct, AFV, identity, etc.

What isn’t an integral transform? That sounds like pretty much everything in VarDCT

is it possible for an encoder to target a specific ssimulacra score, or at least do one such compare after encoding? like, if chosen parameter results in ssimu score 60 or below, lower distance until its target 80. to me it sounds itd guarantee visual quality whatever params you end chosing

It’s already targeting buttergauli distance , iirc isn’t that better than ssimu?

we don't know if butteraugli or ssimulacra is better for that purpose -- but we have done about 9 iterations of butteraugli so that it works in this use, there is a possibility that ssimulacra would need to be iterated a few times before it would be effective in this use

https://x.com/RandyVazquez/status/1840586664516661496

https://x.com/RandyVazquez/status/1841629879063745019

I was correct: the last one was the HEIF 🙂

twitter/x is one of the worse places to upload comparison images

oh I just saw the post where you mentioned the recompression and the other post

yeah, this person has a weird opinion that boils down to "image quality doesn't matter since social media will ruin it anyway"

who needs high quality images when they're sometimes downsampled

music producers should not mix in float because it's going to be played on crappy bluetooth speakers through youtube

I tried to explain it but I don't think he gets it

ask them to print out their crappy 140 kB jpeg and hang it on a wall

anyway I'm just happy with myself that I managed to see which one was the ex-HEIF even though they all went through twitter recompression 🙂

is their whole world view just social media?

like there is so much more then just current day social media JPEG recompression

Even if you want to post it on social media, you may want to edit it first, and then you're in a better position if you have a higher quality original to work with.

Uploader should have used the transparent pixel trick to avoid recompression

? I swear I've seen twitter turn PNGs with transparency into JPEGs

Did they change that? Used to be as long as you're below 900x900 they won't recompress (if it also has transparency)

I think it might be filesize related

like it seems like twitter only keeps images as PNGs if they are a small enough filesize otherwise they convert to JPEG

a friend of mine uploads high'ish res artwork without transparency (not even a bogus alpha channel) that is put through oxipng and twitter will sometimes decide to keep them as PNG since the artstyle compresses well as PNG

Gwenview does something weird I've noticed. I opened an sRGB image containing just a single color, and at some zoom levels, it looks odd. Here it is, magnified 32x

It looks like it might be some kind of dither-y thing, but I can't figure out what. The differences between adjacent pixels is huge, much bigger than you'd get from linear RGB.

So why does he say no one got it right and the 70MB space savings from JXL is pointless and doesn't matter?

Gwenview is pretty bad, especially when viewing palette images

it must be dithering

is it? it’s not so bad, as far as I recall

you just need to carefully compress them to a JPEG that’s within their limits for not recompressing

I forget exactly what those limits are but I have a perl script somewhere that takes care of it

from what I remember, the slightly annoying part is the size having to be a multiple of 16

can you not just pad with zeros?

as in, a black border?

the approach taken by my script is to slightly stretch (I think it shouldn’t be noticeable for images that are large enough)

I found the conditions again: > Twitter for Web has been updated (Dec 10, 2019) to preserve a JPEG as encoded if: 1) the image is 4096x4096 or smaller, 2) 5MBs or less, 3) doesn’t have an orientation set that would rotate the image and 4) has a compression ratio of at least 1 pixel per byte.

don’t remember where I saw the “multiple of 16” thing

“at least 1 pixel per byte” = “at most 8 bpp”, which is generous enough that it really shouldn’t be a concern in most cases