JPEG XL

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.

Jyrki Alakuijala

2024-09-13 10:43:34

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

CrushedAsian255

2024-09-13 10:44:24

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

Jyrki Alakuijala

2024-09-13 10:55:18	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
2024-09-13 10:55:46	of course should be relatively rare for jxl metadata

CrushedAsian255

2024-09-13 11:03:03

XMP xml?

Jyrki Alakuijala

2024-09-13 11:03:59	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
2024-09-13 11:05:06	if there is human language, that may benefit -- but I suspect most of the metadata will be computer generated numbers
2024-09-13 11:05:23	(actually I don't know what is there... never looked :-D)

_wb_

2024-09-13 11:06:03

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> ```

CrushedAsian255

2024-09-13 11:06:25

did you make brotli?

_wb_

2024-09-13 11:06:34

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

CrushedAsian255

2024-09-13 11:07:59	the string `xmlns:` is in the static dictionary
2024-09-13 11:08:43	so is the word Document

Jyrki Alakuijala

2024-09-13 11:08:47

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

CrushedAsian255

2024-09-13 11:09:18

geez this server has so many people who made impressive algorithms

Jyrki Alakuijala

2024-09-13 11:09:34

Thank you!! 😄

CrushedAsian255

2024-09-13 11:09:58

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

_wb_

2024-09-13 11:10:08

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

CrushedAsian255

2024-09-13 11:10:36

yeah, like how FLAC adds padding blocks

Jyrki Alakuijala

2024-09-13 11:10:42

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 😄

CrushedAsian255

2024-09-13 11:10:45	most things I use do that
2024-09-13 11:11:35	where most people had pop singers as idols, i have data compression algorithm designers

Jyrki Alakuijala

2024-09-13 11:11:35

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)

CrushedAsian255

2024-09-13 11:11:45	that sounds really cool
2024-09-13 11:12:01	i guess being in this server is probably helpful for me to learn about these kinds of technologies

Jyrki Alakuijala

2024-09-13 11:12:21

are you in a CS program?

CrushedAsian255

2024-09-13 11:12:58

not yet, but am planning to

Jyrki Alakuijala

2024-09-13 11:13:39

senior highschool?

CrushedAsian255

2024-09-13 11:13:44

yeah

Jyrki Alakuijala

2024-09-13 11:14:02

this is good times for learning to program more

CrushedAsian255

2024-09-13 11:14:18

i wrote a flac decoder a few days ago in C

Jyrki Alakuijala

2024-09-13 11:14:27

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

CrushedAsian255

2024-09-13 11:14:33	very simple, and still haven't fixed all the bugs in it, but it decodes most stuff fine
2024-09-13 11:14:38	trumpet

Jyrki Alakuijala

2024-09-13 11:14:44	nice
2024-09-13 11:14:57	I'm planning to make an audio compressor or three 😄
2024-09-13 11:15:08	I have new ideas in this space
2024-09-13 11:15:30	some of them we can write in the opensource from scratch

CrushedAsian255

2024-09-13 11:15:58

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

Jyrki Alakuijala

2024-09-13 11:16:20

we have stronger, better ideas in this space

CrushedAsian255

2024-09-13 11:16:32	yeah, i was just thinking of random ideas
2024-09-13 11:16:43	hybriduint residual coding?

Jyrki Alakuijala

2024-09-13 11:17:03

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

_wb_

2024-09-13 11:17:09

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 ```

CrushedAsian255

2024-09-13 11:17:14	what company are you from?
2024-09-13 11:17:26	brotli has an effort setting?

Jyrki Alakuijala

2024-09-13 11:17:30

Google Research

CrushedAsian255

2024-09-13 11:17:47

not the chrome codec team?

Jyrki Alakuijala

2024-09-13 11:18:32

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

_wb_

2024-09-13 11:18:39

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

Jyrki Alakuijala

2024-09-13 11:18:50

nice!!

CrushedAsian255

2024-09-13 11:18:57

oh yeah, webp lossless is cool

Jyrki Alakuijala

2024-09-13 11:19:03	Thank you!!
2024-09-13 11:19:13	Brotli is based on many of the ideas I got in WebP lossless
2024-09-13 11:19:18	the same for JPEG XL

CrushedAsian255

2024-09-13 11:19:19

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

jonnyawsom3

2024-09-13 11:19:21

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

CrushedAsian255

2024-09-13 11:19:51

surprised as well tbh

Jyrki Alakuijala

2024-09-13 11:19:55

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

CrushedAsian255

2024-09-13 11:20:40	> 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?
2024-09-13 11:20:49	have the brotli spec downloaded, haven't read it yet

jonnyawsom3

2024-09-13 11:21:09

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

Jyrki Alakuijala

2024-09-13 11:21:15

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

CrushedAsian255

2024-09-13 11:21:42	ends up beating lossless AVIF somehow
2024-09-13 11:21:44	<:kekw:808717074305122316>

Jyrki Alakuijala

2024-09-13 11:22:24

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

afed

2024-09-13 11:24:20

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>

CrushedAsian255

2024-09-13 11:24:40

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

dogelition

2024-09-13 11:25:00

lossy and/or lossless?

Jyrki Alakuijala

2024-09-13 11:25:26	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)
2024-09-13 11:25:50	both, but more effort in psychoacoustically-lossless lossy
2024-09-13 11:26:10	we have a proto that can compress 65 % more than opus for psychoacoustically lossless

dogelition

2024-09-13 11:26:19

very nice

CrushedAsian255

2024-09-13 11:26:47

is this going to be released under AOM?

Jyrki Alakuijala

2024-09-13 11:26:50

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

Quackdoc

2024-09-13 11:27:15

bruv just dropped the knowledge of some a bombs existing here

Jyrki Alakuijala

2024-09-13 11:27:21

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

CrushedAsian255

2024-09-13 11:27:38	is there a GitHub repository for this?
2024-09-13 11:27:43	or GitLab
2024-09-13 11:27:49	or is it still just internal testing

Jyrki Alakuijala

2024-09-13 11:28:05

zimtohrli is here: github.com/google/zimtohrli

dogelition

2024-09-13 11:28:07

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)

CrushedAsian255

2024-09-13 11:28:22

how are they with speed though?

Jyrki Alakuijala

2024-09-13 11:28:25	the early experiments of the audio coding are in github.com/google/ringli
2024-09-13 11:28:47	zimtohrli -- I think -- can run 30x audio speed (not quite sure about this)
2024-09-13 11:28:57	ringli is roughly similar
2024-09-13 11:29:15	I'm thinking of starting first the serious work with a 'guetzli' / 'jpegli' kind of approach
2024-09-13 11:29:23	where opus coding would be modulated by zimtohrli

_wb_

2024-09-13 11:30:04

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.

Jyrki Alakuijala

2024-09-13 11:30:08

that would likely improve opus 25 % or so

CrushedAsian255

2024-09-13 11:30:23

also metadata is just nice to have

dogelition

2024-09-13 11:31:27	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
2024-09-13 11:31:32	also see <https://wiki.hydrogenaud.io/index.php?title=TAK>

Quackdoc

2024-09-13 11:32:25	time to add ringli decoder to symphonia crate lel
2024-09-13 11:33:15	too bad symphoinia is ~~dead~~ on life support

CrushedAsian255

2024-09-13 11:33:30

in maintenance state?

Quackdoc

2024-09-13 11:34:04

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

Oleksii Matiash

2024-09-13 11:34:11

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?

Quackdoc

2024-09-13 11:34:43

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

CrushedAsian255

2024-09-13 11:42:25

i agree, that would be nice

Oleksii Matiash

2024-09-13 11:44:12

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

afed

2024-09-13 11:44:58

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

Oleksii Matiash

2024-09-13 11:45:02

But as far as I understand Zimtohrli is exactly about it

TheBigBadBoy - 𝙸𝚛

2024-09-13 11:45:16

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

CrushedAsian255

2024-09-13 11:45:38	GPU accelerated audio?
2024-09-13 11:45:40	i guess but why?

TheBigBadBoy - 𝙸𝚛

2024-09-13 11:46:13

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

Oleksii Matiash

2024-09-13 11:46:19

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

dogelition

2024-09-13 11:47:01

i gotta try that on my desktop later

TheBigBadBoy - 𝙸𝚛

2024-09-13 11:47:20

windows program, but works nicely with wine for Linux

CrushedAsian255

2024-09-13 11:47:47	FLAC?
2024-09-13 11:47:49	i thought it went up to 8
2024-09-13 11:47:52	9 for experimental

TheBigBadBoy - 𝙸𝚛

2024-09-13 11:48:32	up to 8 for Xiph's flac encoder
2024-09-13 11:48:44	flaccl have more presets but cannot beat Xiph's encoder on size (with high compression settings)

Oleksii Matiash

2024-09-13 11:48:45

CrushedAsian255

2024-09-13 11:49:10

oh, you're using a different encode

TheBigBadBoy - 𝙸𝚛

2024-09-13 11:50:07	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
2024-09-13 11:51:56	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

CrushedAsian255

2024-09-13 11:52:44

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

TheBigBadBoy - 𝙸𝚛

2024-09-13 11:54:27

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\)`

dogelition

2024-09-13 11:54:28

very nice data

TheBigBadBoy - 𝙸𝚛

2024-09-13 11:54:35

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

CrushedAsian255

2024-09-13 11:55:19	oh geez
2024-09-13 11:55:28	doesn't `--lax` break compatibility ?

Oleksii Matiash

2024-09-13 11:56:11

With hw decoders? Maybe, but who cares

TheBigBadBoy - 𝙸𝚛

2024-09-13 11:56:35

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

CrushedAsian255

2024-09-13 11:56:50	i guess these days nothing really uses hw flac
2024-09-13 11:56:55	since it's pretty easy to decode in sw

Oleksii Matiash

2024-09-13 11:57:30

And because hw players has gone

TheBigBadBoy - 𝙸𝚛

2024-09-13 11:58:04

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, ...)

afed

2024-09-13 11:58:12

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

Quackdoc

2024-09-13 12:02:16

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

CrushedAsian255

2024-09-13 12:02:46

libjxl decoder hooked up to lossless jpeg transcoding

Jyrki Alakuijala

2024-09-13 12:36:57

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

CrushedAsian255

2024-09-13 12:37:25

Is a Rust JPEG XL encoder in the works?

Jyrki Alakuijala

2024-09-13 12:38:44	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
2024-09-13 12:39:02	we haven't yet started -- at least not outside of what code is in jxl-rs

CrushedAsian255

2024-09-13 12:39:30	rewrite it in rust lol
2024-09-13 12:39:52	In all seriousness I should try to rewrite my FLAC thing into Rust

Jyrki Alakuijala

2024-09-13 12:40:42

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

CrushedAsian255

2024-09-13 12:40:48	Are you planning JXL-rs to be a direct port or to be separate projects?
2024-09-13 12:41:22	I guess, as encoders just take in some pixels, where decoders take in complex bitstreams

afed

2024-09-13 12:42:54

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

CrushedAsian255

2024-09-13 12:43:28	Full end to end Rust pipeline
2024-09-13 12:43:58	Also someone should write littlecms to Rust

afed

2024-09-13 12:49:26

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

jonnyawsom3

2024-09-13 01:05:28

I read that as "Subdivide Turkey"

TheBigBadBoy - 𝙸𝚛

2024-09-13 01:05:59	yeah for a long time me too <:KekDog:805390049033191445>
2024-09-13 01:06:19	I still don't know what's tukey, even tho I saw it in a few encoders already
2024-09-13 01:07:09	oh and recently Xiph's FLAC encoder added support for multithreading 💯

jonnyawsom3

2024-09-13 01:10:25

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

CrushedAsian255

2024-09-13 01:12:33

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

lonjil

2024-09-13 01:23:01	I have a rust jpegli decoder on my backburner. Not sure when I can work on it, busy with school atm.
2024-09-13 01:27:42	One problem is, I have next to zero C++ knowledge, so trying to understand the source code is a bit annoying.

BabylonAS

2024-09-15 11:40:13	We've got cross-channel spam incoming!
2024-09-15 11:40:36	Dunno how to ping moderators here
2024-09-15 11:41:04	<@794205442175402004> can you take care of them, please?

_wb_

2024-09-15 11:41:54	done <:BanHammer:805396864639565834>
2024-09-15 11:43:05	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

jonnyawsom3

2024-09-15 11:43:29

Yet another joy of Discord

Oleksii Matiash

2024-09-15 12:41:37

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

CrushedAsian255

2024-09-15 12:44:07	JXLcoin
2024-09-15 12:44:22	Mining involves compression images to below a certain size
2024-09-15 12:46:01	That’s what made me check
2024-09-15 12:47:20	Someone Add to the licence: Don’t disable Jon’s personal Monero miner at s 11, it’s how he funds the project
2024-09-15 12:47:24	Just as a joke

jonnyawsom3

2024-09-15 12:51:39

Crypto if it was actually useful

CrushedAsian255

2024-09-17 12:39:57

Opinion on Storj / FileCoin?

paperboyo

2024-09-17 07:46:33

Effort now increased.

_wb_

2024-09-17 08:17:36

from which effort setting to which setting did you go?

A homosapien

2024-09-17 08:56:26	Looks like they were using effort 4 or lower: https://discord.com/channels/794206087879852103/794206087879852106/1272638277589012573
2024-09-17 08:56:53	I hope they're at least using effort 6

frep

2024-09-17 10:11:08	Proof of Optimizing Size (which abbreviates to... poos.)
2024-09-17 10:26:28	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
2024-09-17 10:27:17	now it's 450kB of JPEG XL thumbnails linking to PNGs, and that's after adding a few new renders
2024-09-17 10:29:28	(well, i still have 3 really big GIFs i need to optimize or convert to videos...)

AccessViolation_

2024-09-18 11:08:20	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
2024-09-18 11:13:06	Oh I found it <https://www.jpegxl.io/faq#vast-header>

username

2024-09-18 11:14:17	why is a frog there‽ lol
2024-09-18 11:14:43	I know what presentation it's referencing and it does not have that frog image

AccessViolation_

2024-09-18 11:15:04	it claims it's a 117 byte JPEG XL file but that doesn't appear to be the case
2024-09-18 11:15:14	It's much larger
2024-09-18 11:15:50	Oh it's a transfer size vs resource size thing?
2024-09-18 11:16:36	But that doesn't make sense either

username

2024-09-18 11:16:41	this is what/where it's from https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.gde87dfbe27_0_49
2024-09-18 11:16:46	notice the lack of frog?
2024-09-18 11:16:57	no clue why that frog image is on that site

AccessViolation_

2024-09-18 11:17:29	Hmm I do notice a distinct lack of frog yes <:Thonk:805904896879493180>
2024-09-18 11:18:07	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
2024-09-18 11:19:42	The transfer size changes every time, probably a bug in thorium. This being HTTP compression is out of the question

username

2024-09-18 11:20:43

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

AccessViolation_

2024-09-18 11:21:20

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

CrushedAsian255

2024-09-18 11:32:18

Do you have the MP4?

_wb_

2024-09-18 11:32:31

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

CrushedAsian255

2024-09-18 11:32:56

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

AccessViolation_

2024-09-18 11:32:57

No, it's on their youtube channel

CrushedAsian255

2024-09-18 11:33:03	If you look at the bottom it says archived
2024-09-18 11:33:10	Link?

AccessViolation_

2024-09-18 11:33:27	revision history - change picture to frog :3
2024-09-18 11:33:37	sure, one sec
2024-09-18 11:35:24	https://www.youtube.com/watch?v=VtZ9_UmCd5M

_wb_

2024-09-18 11:36:04

that one is in Dutch though

CrushedAsian255

2024-09-18 11:36:30	Does YouTube auto captions work with it?
2024-09-18 11:37:23	Or are these slides the exact same content?

jonnyawsom3

2024-09-18 11:54:23	> 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
2024-09-18 11:55:17	Or they couldn't find the actual JXL file and just used a random one as example

CrushedAsian255

2024-09-18 11:55:48

They probably were looking for that JXL X logo

jonnyawsom3

2024-09-18 11:59:13

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

HCrikki

2024-09-18 02:38:57

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

username

2024-09-18 03:11:55	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
2024-09-18 03:12:15	the Chrome team is just going to say "no" and the result will be the same as last year

jonnyawsom3

2024-09-18 03:12:38	... Did they not learn anything?
2024-09-18 03:14:42	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
2024-09-18 03:16:21	Plus we have plenty of time to make a case instead of having to rush with 3 days left on a deadline :P
2024-09-18 03:26:41	Actually let me post this in <#803574970180829194>

HCrikki

2024-09-19 03:10:32	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
2024-09-19 03:12:19	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?
2024-09-19 03:14:07	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'

AccessViolation_

2024-09-19 06:07:07	I'm just going to say it
2024-09-19 06:07:20	I think JPEG-XL looks better than JPEG XL
2024-09-19 06:08:59	I of course respect our hyphenless format and shall call it by its proper name but I had to get it off my chest

Quackdoc

2024-09-19 06:11:42

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

yoochan

2024-09-19 06:12:13

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

Quackdoc

2024-09-19 06:14:53

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

yoochan

2024-09-19 06:17:04

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

HCrikki

2024-09-19 06:28:16	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
2024-09-19 06:33:44	waterfox has an android release with jxl updated and on by default (based on upstream firefox, not esr)

yoochan

2024-09-19 06:34:48

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

HCrikki

2024-09-19 06:35:36

odd, theres jxl activity for android. maybe upcoming changes

yoochan

2024-09-19 06:36:07

I'll have a look their issues

Quackdoc

2024-09-19 06:36:55

Is there?

HCrikki

2024-09-19 06:38:49

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

yoochan

2024-09-19 06:40:05

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

HCrikki

2024-09-19 06:40:46

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)

Oleksii Matiash

2024-09-19 08:20:37

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

Quackdoc

2024-09-19 08:21:35

I use Cromite it has it baked in

Kremzli

2024-09-19 09:34:02

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

AccessViolation_

2024-09-19 09:45:42

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

CrushedAsian255

2024-09-19 11:57:41

What about efficiently though?

Quackdoc

2024-09-20 01:36:10

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

yoochan

2024-09-20 06:27:01

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

_wb_

2024-09-20 07:04:01

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

veluca

2024-09-20 07:16:57

so does chrome, fwiw

_wb_

2024-09-20 07:19:59

ah right, it does

yoochan

2024-09-20 08:54:38

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)

CrushedAsian255

2024-09-20 09:10:30	I have personally adopted the Firefox container workflow but when I was using thorium, yes I could have multiple profiles loaded at once
2024-09-20 09:10:38	You go the the profiles menu

veluca

2024-09-20 11:26:00

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

AccessViolation_

2024-09-20 11:33:37	the PNGs openstreetmap.org serves seem to be pretty well compressed
2024-09-20 11:34:57	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

CrushedAsian255

2024-09-20 11:41:01

maybe they're palette

AccessViolation_

2024-09-20 11:42:01

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

jonnyawsom3

2024-09-20 11:58:13	Delta palette only works in 0.6 due to a bug
2024-09-20 11:58:39	Although bear in mind it's lossy anyway

AccessViolation_

2024-09-20 11:59:07

what is, png to lossless jxl conversion?

A homosapien

2024-09-20 12:05:01

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.

AccessViolation_

2024-09-20 12:07:32

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

CrushedAsian255

2024-09-20 12:10:11	`-d 0` is always lossless
2024-09-20 12:10:15	unless doing something really weird

AccessViolation_

2024-09-20 12:11:28

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

A homosapien

2024-09-20 12:25:20

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

jonnyawsom3

2024-09-20 12:50:44	That was in reference to my message about Delta Palette
2024-09-20 12:51:51	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
2024-09-20 12:53:01	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)
2024-09-20 12:53:38	Although this is just my understanding of it, <@532010383041363969> came up with the idea and wrote the code

_wb_

2024-09-20 01:55:33

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

CrushedAsian255

2024-09-20 01:56:34	eventaully will it be implemented as a standard coding tool for lossy modular?
2024-09-20 01:56:43	and just auto enable when it finds itself helpful?

jonnyawsom3

2024-09-20 03:40:07

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)

yoochan

2024-09-21 05:11:18

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

veluca

2024-09-21 09:01:49

I would bet not worth it

CrushedAsian255

2024-09-21 10:28:23

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

Demiurge

2024-09-22 06:06:18

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

CrushedAsian255

2024-09-22 06:20:18

If it’s lossless you can always recompress it

Demiurge

2024-09-22 06:54:29	compressing uncompressed metadata boxes, reconstructing jbrd boxes, changing orientation, converting huffman to ans, etc.
2024-09-22 06:55:17	stitching and cropping would be possible but not as simple as those other things
2024-09-22 06:55:32	well, cropping would be simple.
2024-09-22 06:56:25	but not necessarily.

AccessViolation_

2024-09-22 06:21:17	``` % 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>
2024-09-22 06:21:28	I keep getting scammed by false extensions

jonnyawsom3

2024-09-22 07:10:06

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

AccessViolation_

2024-09-22 07:20:43	Oops! All WebP!
2024-09-22 07:20:58	I got this particular one off github
2024-09-22 07:22:52	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

jonnyawsom3

2024-09-22 07:24:01

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

AccessViolation_

2024-09-22 07:42:48	How good is the encoder at figuring stuff like that out?
2024-09-22 07:46:41	Oh I was confusing groups with something else, so it can't dynamically adjust group sizes which is fair

Traneptora

2024-09-24 03:26:34	just encode each Chunk as a Group <:wesmart:512506347057840129>
2024-09-24 03:26:40	chunks are 16x16 and MC textures are 16x16

CrushedAsian255

2024-09-24 03:29:35

That would only work for top down not isometric

jonnyawsom3

2024-09-24 03:33:07

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

Traneptora

2024-09-24 03:42:07	ofc, still amusing
2024-09-24 03:42:20	most likely smaller groups lead to more accurate ANS frequences for each group

Naksu

2024-09-25 02:27:05

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

spider-mario

2024-09-25 02:30:50

`flac --best`

Naksu

2024-09-25 02:32:27

Ah, is there nothing more hardcore?

TheBigBadBoy - 𝙸𝚛

2024-09-25 02:32:33

yeah

spider-mario

2024-09-25 02:33:04

flaccl is reported to sometimes create slightly smaller files

TheBigBadBoy - 𝙸𝚛

2024-09-25 02:33:12

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

spider-mario

2024-09-25 02:33:21

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

Naksu

2024-09-25 02:33:56

I see, thanks for your feedback.

TheBigBadBoy - 𝙸𝚛

2024-09-25 02:34:00

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

spider-mario

2024-09-25 02:34:03

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

Fox Wizard

2024-09-25 02:41:46

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

TheBigBadBoy - 𝙸𝚛

2024-09-25 02:44:45

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

Naksu

2024-09-25 02:46:31

`--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.

spider-mario

2024-09-25 02:48:24

is it not too inconvenient not to have a seektable?

TheBigBadBoy - 𝙸𝚛

2024-09-25 03:36:02	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
2024-09-25 03:36:46	well you can keep it but I tried without it on both PC and Android phone, I could seek the file without any issue

spider-mario

2024-09-25 03:37:16	flac’s documentation says seeking will work but might be slower
2024-09-25 03:37:34	it also says that there can be an arbitrary number of seek points, each taking up 18 bytes
2024-09-25 03:37:48	the right balance probably depends on the file and use case
2024-09-25 03:39:34	they give as an example that 1% seek point density would be less than 2 kB

TheBigBadBoy - 𝙸𝚛

2024-09-25 03:39:51	too much for me 💯 <:KekDog:805390049033191445>
2024-09-25 03:41:06	can you share the file ?

Naksu

2024-09-25 03:47:39

TheBigBadBoy - 𝙸𝚛

2024-09-25 03:53:41

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

Naksu

2024-09-25 04:03:46

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

TheBigBadBoy - 𝙸𝚛

2024-09-25 04:11:31	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)
2024-09-25 04:12:39	then go with `-8ep -r 15 -l 32 -P 0` if the speed is ok for you otherwise lower either `r` or `l` values

CrushedAsian255

2024-09-25 04:12:55

Keep misreading this as subdivide Turkey 🇹🇷

Naksu

2024-09-25 04:15:02	It might not have been taken into account 'cause of the parentheses.
2024-09-25 04:15:25	OK, thanks
2024-09-25 04:15:55	And `--lax` was for what?
2024-09-25 04:16:09	`--no-seektable` too
2024-09-25 04:16:36	I don't understand libFLAC's descriptions.

TheBigBadBoy - 𝙸𝚛

2024-09-25 04:17:03	to be able to use high `r` and `l` values, but therefore not HW decode guaranteed
2024-09-25 04:18:30	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
2024-09-25 04:21:18	so great to use seektable for movies/videos/... but not so useful for short songs of ~5 min imo

Naksu

2024-09-25 04:22:17	Yeah, that's what I was thinking.
2024-09-25 04:26:05	What are the max values without `--lax`?
2024-09-25 04:28:09	And if I run into any reading issues on other machines in the future, I can always add it later, right?

TheBigBadBoy - 𝙸𝚛

2024-09-25 04:29:08

if you say about seektable, yes

Naksu

2024-09-25 04:29:29

Nah, `--lax`

TheBigBadBoy - 𝙸𝚛

2024-09-25 04:29:54

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

Naksu

2024-09-25 04:30:12

Thanks

TheBigBadBoy - 𝙸𝚛

2024-09-25 04:30:43

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

Naksu

2024-09-25 04:34:47	`-r 15 -l 32 --lax` : 3.645659 MiB `-r 8 -l 12` : 3.647330 MiB
2024-09-25 04:36:47	It’s the little grains of sand that make up the beaches, as they say.

CrushedAsian255

2024-09-25 05:08:48

Speed difference?

Naksu

2024-09-25 05:32:01

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

TheBigBadBoy - 𝙸𝚛

2024-09-25 05:34:43

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

dogelition

2024-09-25 06:26:27

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

TheBigBadBoy - 𝙸𝚛

2024-09-25 06:27:27

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

Naksu

2024-09-25 06:42:32

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

jonnyawsom3

2024-09-27 05:45:40

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

username

2024-09-28 04:27:11

DISCORD EMBEDS ANIMATED WEBPS NOW

Quackdoc

2024-09-28 04:49:04

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

A homosapien

2024-09-28 04:52:07

It's beautiful 🥲

afed

2024-09-28 05:28:06

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

username

2024-09-28 05:30:11	note: that release is a rollup of everything they done since like 2018
2024-09-28 05:31:06	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

afed

2024-09-28 05:37:00

ICC and HEVC support is also relatively new

Quackdoc

2024-09-28 05:51:37

massive kekw that no jxl or av1 input video support

jonnyawsom3

2024-09-28 06:01:21

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

Quackdoc

2024-09-28 06:18:16

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.

gb82

2024-09-28 06:23:57

it'd be a no brainer to support AVIF

username

2024-09-28 06:24:42	I swear I have gotten Discord to naturally embed full original images without them going through the thumbnailer
2024-09-28 06:25:12	I think it depends on screen res and image res or something

Quackdoc

2024-09-28 06:26:16

I've never seen it happen outside of client mods

username

2024-09-28 06:27:02	I remember it happening when testing out ICC profiles back before the thumbnailer had any kind of support for them
2024-09-28 06:28:08	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

jonnyawsom3

2024-09-28 07:12:06

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

CrushedAsian255

2024-09-28 07:21:12

Doesn’t work for iOS

DZgas Ж

2024-09-28 11:45:19

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

lonjil

2024-09-28 11:52:04

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.

AccessViolation_

2024-09-28 07:40:35	It probably wouldn't be too hard to make a webextension that renders media formats unsupported by Discord
2024-09-28 07:44:39	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

RaveSteel

2024-09-28 07:59:38

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

AccessViolation_

2024-09-28 08:00:32

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

Quackdoc

2024-09-28 10:31:31

does anyone by chance have an ocio config for xyb?

dogelition

2024-09-28 11:37:20

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>

TheBigBadBoy - 𝙸𝚛

2024-09-29 07:17:11	https://cdn.discordapp.com/emojis/852007419474608208.png?quality=lossless&size=48
2024-09-29 07:17:36	nice work <:PepeOK:805388754545934396>

username

2024-09-29 07:18:56	I keep forgetting that I wanted to submit a pull request to CUETools to change some of it's default settings
2024-09-29 07:20:26	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

TheBigBadBoy - 𝙸𝚛

2024-09-29 09:40:26

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

A homosapien

2024-10-01 12:26:49	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
2024-10-01 12:28:33	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.
2024-10-01 12:30:52	I'm assuming efforts 6 or 7 are used but libjxl doesn't perform well at these low bitrates.

Demiurge

2024-10-01 01:06:27	Effort 3 does not look worse than effort 8
2024-10-01 01:07:04	In my experience. At d=1

CrushedAsian255

2024-10-01 04:13:34

What does effort affect then?

Oleksii Matiash

2024-10-01 04:56:09

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)

CrushedAsian255

2024-10-01 05:03:26

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

A homosapien

2024-10-01 05:03:34

that's the idea

Oleksii Matiash

2024-10-01 05:04:16

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

A homosapien

2024-10-01 05:05:43

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

AccessViolation_

2024-10-01 10:24:03

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>

lonjil

2024-10-01 11:27:36

What tools exist for analyzing ICC profiles?

spider-mario

2024-10-01 11:43:31	cd-iccdump, displaycal-profile-info, Apple’s thing
2024-10-01 11:46:03	(the latter two are probably more useful because they actually let you see the curves)

lonjil

2024-10-01 11:47:08

thanks

Demiurge

2024-10-01 03:07:06

Blocky gradients?

Smegas

2024-10-01 03:15:02

In my experience e3 can look worse than e8.

Oleksii Matiash

2024-10-01 04:11:14

Not blocky, if you mean blockiness like jpeg does

Demiurge

2024-10-01 04:16:49

I only tested at d=1

A homosapien

2024-10-01 04:20:09

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

Demiurge

2024-10-01 04:23:09	Yeah, I didn't do a real serious comparison, but I noticed they looked different, but not necessarily better or worse.
2024-10-01 04:24:21	I noticed that the way the image looks doesn't change until you go from e=4 to e=5
2024-10-01 04:24:33	and between e=7 and e=8
2024-10-01 04:24:59	so everything e4 and below looks the same. And everything e5-e7 looks the same

Oleksii Matiash

2024-10-01 04:26:18

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

Demiurge

2024-10-01 04:31:16

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

A homosapien

2024-10-01 04:32:10	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.
2024-10-01 04:32:23	Source: my eyes 👀
2024-10-01 04:34:27	All of these were done on photographic images at the same bbp

Oleksii Matiash

2024-10-01 04:34:43	No, gaborish was off for both
2024-10-01 04:38:44	In case if someone wants to compare. Parameters are in names

Demiurge

2024-10-01 05:30:06

Well it looks like some deblocking filter

dogelition

2024-10-01 08:11:34

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

Quackdoc

2024-10-01 08:12:31	Is there a good library for parsing ICCv4 stuff let alone ICCMax? the ones I have used in the past are... not great
2024-10-01 08:12:52	iccmax especially, talk about a behemoth of a spec

spider-mario

2024-10-01 08:21:16	wow, is it really still compatible with Windows 95? respect
2024-10-01 08:21:45	I mean, sure, not the most modern-looking software, but still
2024-10-01 08:22:40	for one thing, despite its apparent compatibility constraints, it didn’t break down in a somewhat high-DPI (150% scaling) environment

lonjil

2024-10-01 08:22:52

windows software? oh no

spider-mario

2024-10-01 08:23:43	less ideal but still usable
2024-10-01 08:24:01	if it works on Windows 95, it should hopefully work in Wine
2024-10-01 08:24:28	a shame they don’t make the source code available, though
2024-10-01 08:25:08	the sRGB

dogelition

2024-10-01 08:30:10

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

_wb_

2024-10-01 08:37:47

I guess some would consider sRGB _the_ "standard RGB"

Jyrki Alakuijala

2024-10-02 02:43:23	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.
2024-10-02 02:45:22	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
2024-10-02 02:47:57	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

CrushedAsian255

2024-10-02 02:49:36	How can it change the quantisation midimage?
2024-10-02 02:49:46	What is *quant?

Demiurge

2024-10-02 06:47:59

Sounds similar to jpegli

A homosapien

2024-10-03 03:40:33

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.

jonnyawsom3

2024-10-03 06:06:26

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

A homosapien

2024-10-03 06:49:57

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?

CrushedAsian255

2024-10-03 06:50:36	if anything it should be the other way round
2024-10-03 06:50:46	avif gets really low bitrate and jxl gets slightly higher
2024-10-03 06:50:51	as that's each format's strengths

A homosapien

2024-10-03 06:51:34	Exactly, jpeg xl's strengh is faithful detail retention at higher bpp, with progressive decoding as a cherry on top
2024-10-03 06:53:55	Right now all they are doing is making jxl look bad in comparison to avif (to the layman of course, we know better)
2024-10-03 06:58:00	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.

CrushedAsian255

2024-10-03 06:59:51	is there a way to tell libjxl to target a certain bpp / filesize instead of quality?
2024-10-03 07:01:24	argh those pesky extra large jpegs

_wb_

2024-10-03 07:04:42

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...

CrushedAsian255

2024-10-03 07:05:32

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

_wb_

2024-10-03 07:05:49	yeah
2024-10-03 07:06:13	usually it makes the most sense to use jxl distance settings and then let the other encoders match bpp 🙂
2024-10-03 07:08:09	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

CrushedAsian255

2024-10-03 07:08:22

makes sense

A homosapien

2024-10-03 07:18:38

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

spider-mario

2024-10-03 11:57:47

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)

Jyrki Alakuijala

2024-10-03 01:25:32	it changes it by *quant++; --- by one-upping the quantization number
2024-10-03 01:26:13	quant is the number used to change all quantizations (single number for all XYB)
2024-10-03 01:28:03	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

CrushedAsian255

2024-10-03 01:38:36	How does the number work?
2024-10-03 01:41:46	Does it just change some value in a sub image?

Jyrki Alakuijala

2024-10-03 01:44:13	it is a number that is used in decoding to multiply the coefficients
2024-10-03 01:44:46	there is one number per integral transform -- it is a 8x8 sub image but only has values where transforms exist

CrushedAsian255

2024-10-03 01:45:07

What is integral transform?

Jyrki Alakuijala

2024-10-03 01:46:25

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

CrushedAsian255

2024-10-03 01:49:03

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

HCrikki

2024-10-03 02:09:24

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

CrushedAsian255

2024-10-03 02:12:39

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

Jyrki Alakuijala

2024-10-03 02:36:02

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

_wb_

2024-10-03 03:20:27	https://x.com/RandyVazquez/status/1840586664516661496
2024-10-03 03:20:48
2024-10-03 03:21:08	https://x.com/RandyVazquez/status/1841629879063745019
2024-10-03 03:21:53	I was correct: the last one was the HEIF 🙂

username

2024-10-03 03:22:13	twitter/x is one of the worse places to upload comparison images
2024-10-03 03:23:14	oh I just saw the post where you mentioned the recompression and the other post

_wb_

2024-10-03 03:23:20

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

CrushedAsian255

2024-10-03 03:23:51	who needs high quality images when they're sometimes downsampled
2024-10-03 03:24:25	music producers should not mix in float because it's going to be played on crappy bluetooth speakers through youtube

_wb_

2024-10-03 03:24:36

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

CrushedAsian255

2024-10-03 03:25:21

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

_wb_

2024-10-03 03:26:08

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 🙂

username

2024-10-03 03:33:14	is their whole world view just social media?
2024-10-03 03:34:15	like there is so much more then just current day social media JPEG recompression

lonjil

2024-10-03 03:34:52

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.

a goat

2024-10-03 03:37:23

Uploader should have used the transparent pixel trick to avoid recompression

username

2024-10-03 03:38:42

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

a goat

2024-10-03 03:39:34

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

username

2024-10-03 03:44:12	I think it might be filesize related
2024-10-03 03:45:14	like it seems like twitter only keeps images as PNGs if they are a small enough filesize otherwise they convert to JPEG
2024-10-03 03:46:49	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

lonjil

2024-10-03 04:57:08	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
2024-10-03 09:05:51	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.

Demiurge

2024-10-03 11:27:46	So why does he say no one got it right and the 70MB space savings from JXL is pointless and doesn't matter?
2024-10-03 11:28:31	Gwenview is pretty bad, especially when viewing palette images

CrushedAsian255

2024-10-03 11:29:49

it must be dithering

spider-mario

2024-10-04 09:55:34	is it? it’s not so bad, as far as I recall
2024-10-04 09:55:54	you just need to carefully compress them to a JPEG that’s within their limits for not recompressing
2024-10-04 09:56:18	I forget exactly what those limits are but I have a perl script somewhere that takes care of it
2024-10-04 09:56:44	from what I remember, the slightly annoying part is the size having to be a multiple of 16

CrushedAsian255

2024-10-04 09:57:47

can you not just pad with zeros?

spider-mario

2024-10-04 09:58:54	as in, a black border?
2024-10-04 09:59:21	the approach taken by my script is to slightly stretch (I think it shouldn’t be noticeable for images that are large enough)
2024-10-04 09:59:37	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.
2024-10-04 09:59:46	don’t remember where I saw the “multiple of 16” thing
2024-10-04 10:00:30	“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

Info

JPEG XL

General chat

Voice Channels

Archived

on-topic

Whatever else