JPEG XL

<:Thonk:805904896879493180>

Where is that?

https://news.knowledia.com/US/en/articles/jpeg-xl-art-f4054189f0d2b21315589fd44b37670741dc1b16

Q: I've noticed a number of postings (in `#jxl-art` and `#glitch-art`) that look like instructions for the encoder, almost like a shader, e.g., ``` RCT 4 Orientation 1 Bitdepth 10 if W-NW > -1 if NW-N > -1 if N > 1021 if c > 0 - Set 1024 - Set 0 if y > 0 - W + 1 if x > 0 - W + 2 if c > 0 - Set -1024 - Set 0 - NW + 0 - Select + 2 ``` However, perusing the docs and the reference implementation doesn't make it clear to me what these instructions actually are, how I could read more about them, what they're called, or how I'd learn more in order to make my own bonkers creations. Any pointers?

check out https://jxl-art.surma.technology/ and its help page

some of the recent art pieces won't work there since it doesn't support custom orientations and such (yet)

but you can make your own

Besides the web interface, if you've downloaded the JXL reference software you can compile the dev tools (run `ci.sh` or just build with `-DJPEGXL_ENABLE_DEVTOOLS=ON`) which include `jxl_from_tree`.

`-DJPEGXL_ENABLE_DEVTOOLS=ON` is better, `ci.sh` was crashing when I was low on RAM.

https://twitter.com/danlmarmot/status/1381415646286598144

If you find out the syntax, write it up 🙂

there are however 77 other options for jxl-image-golfing that are not part of this

Pretty sure that's JPEG 2000 haha

Okay, so as I understand it, these are direct instructions for the JXL prediction tree using `jxl_from_tree`. My understanding is that JXL's tile size limits would prevent this from continuing indefinitely, but does this imply that the tree language is Turing-complete since it can represent rule-110 cellular automata?

(Also does the "tree language" have a name or is that just considered part of JXL's Modular mode?)

turing completeness: apparently yes 😛

the trees themselves are called MA trees

the syntax for the trees doesn't have a name that I know of 🙂

We could probably make the syntax more user friendly, e.g. also allow < in if nodes

Unless I'm missing something isn't this where the syntax is from? https://gitlab.com/wg1/jpeg-xl/-/blob/master/tools/jxl_from_tree.cc Or are you saying that you'd prefer an actual lexer/parser specification instead of a hand-tooled one?

It's kind of just a quick hack that is getting out of hand

I mean, it seems like a lot of fun 😄

the "slightly silly but it's easy to create something" use cases are often some of the most interesting imo

Is JXL format a turing complete language or is that a toy tool for generating JXL ??

Not exactly. As I understand it, there is a generation mechanism for JXL called MA trees which encodes decision trees into the bitstream, which can then be used to create an image. The file sizes are small because there is no image; it's being generated during decoding. The decision trees are complex enough that they can represent cellular automata, and in particular the Rule 110 automata, which is known to be Turing-complete. However, Turing-completeness requires unbounded input sizes and the trees don't operate on unbounded inputs but rather on tiles of a maximum fixed size. So it can't compute very much.

also good to know -- no computer realized in our universe is Turing-complete due to finite size

The observable universe is merely a final state machine with a big state.

discord doesn't handle jxl right

like on canary with it enabled

also why doesn't chrome copy jxl?, only image/png

It's true! Turing-completeness is a lie perpetuated by Big CS.

or maybe this is a thing with every image?

hmm apparently it works

or not

the preview showed but not discord ¯\_(ツ)_/¯

Discord probably just doesn't recognize that it is an image

it does, at least client side

I don't think we actually know that xD

(possibly we even know the opposite of that)

Maybe quantum mechanics makes it something somewhat different, but still not Turing complete I think

well, at least not in terms of "infinite memory"

it helps if you think about Turing-completeness as being about the language, not the computer

can you express _ideas_ in the language that are as powerful as any other TC-language? if so, then it's TC

can you actually _realize_ those ideas on a physical computer with that language? that depends 😄

I guess MA trees are as Turing complete as rule 110

they are, yeah

intptr_t and size_t have a finite size, therefore C and C++ are not turing complete

checkmate

Infinite memory is overrated

We don't have infinite time anyway

remember when Zed Shaw said that Python 3 wasn’t turing complete?

(https://eev.ee/blog/2016/11/23/a-rebuttal-for-python-3/)

lol

I mean, as far as actual languages you'd like to use, TC-ness isn't a very strong property anyway — it's like if a restaurant said "our food contains calories and is edible"

In some cases, non-Turing completeness can be desirable, e.g. to have decidable termination

LOL

Obviously. Turing complete languages require access to arbitrarily much memory.

details

Remember when Jon claimed the JXL bitstream wasn't Turing-complete? https://discord.com/channels/794206087879852103/824000991891554375/824164440349212672

I think it’s more common to discover that a language that previously not thought to be Turing-complete actually is, than the other way around

I mean: http://blog.boreas.ro/2008/07/sedtris-tetris-game-written-in-sed.html

It depends on how you define Turing completeness

E.g. you cannot make a jxl bitstream that makes the decoder not terminate

So in that sense, it is not Turing complete. The halting problem for jxl decoding is decidable 😅

it is Turing-enough

Turing-liquid but not Turing-hard

Turing-cat

another (in)famous example in this category: https://arxiv.org/abs/1904.09828

heh, I have to admit I was more familiar with "game is NP-complete" kind of statements than "game is Turing-complete" xD

Even though I admire the creativity of JXL authors, 😊 I'm not sure about your notability for Wikipedia articles (yet). I'd really like to see articles about you and I'd contribute to them. But I've also seen deleted articles about people who I considered notable but the Wikipedia community didn't. And that's what I don't need to see again. 🙂

Anyway, the rules are here: https://en.wikipedia.org/wiki/Wikipedia:Notability_(people)

So anyone here can comment on it.

Maybe we should start with adding the list of (main) authors into the JPEG XL article(s), including links to the respective biographical articles (that don't exist yet). I guess it's "safe" to take the list of authors from your JXL page, <@!794205442175402004> , right?

We'll probably soon add an ACKNOWLEDGEMENTS file to the public repo

If you want to have main authors for the wikipedia article: these 3 I think we consider to be the main authors: - Jyrki Alakuijala - Jon Sneyers - Luca Versari

If you want to add more, you can also add: - Sami Boukortt - Lode Vandevenne - Jan Wassenberg - Zoltan Szabadka

There are more people who made significant contributions, but the above are the main ones

also a few more (e.g. <@!811568887577444363> and <@!795684063032901642> here) but not sure if all of them want to be named explicitly

but at least Moritz seems fine with it :p

There's also Alexander Rhatushnyak, Thomas Fischbacher, Robert Obryk, Alex Deymo

Indirectly (through FLIF), <@799692065771749416> also contributed: e.g. the arbitrary chaining of (modular) transforms was his idea

me too 🙂

It is a bit tricky

We have switched from using avif to jpeg xl for our operations. We manage nearly 20 tb of videos/images, and growing, so a good compression algorithm is important for us.

Nice 😃 What are you doing, if I can ask?

Web and multimedia archival

you are the future. :p But don't abuse on visual quality !

When i get some more free time I will look into seeing what i can do in terms of contriubtions to the projet

Really? I don't remember that specifically.

Yes, you made Transform an abstract factory, making it easier to signal arbitrary chains of transforms (in flif also with the complication of keeping track of how it influences the range of pixel values)

Oh, right!

Jon's description of authorship agrees with mine and our team's opinion of authorship of the format

I wonder if it would be better to start from the national wikipedia pages -- like Jon may be more notable for pages in Flemish?

Could you write about your switch into <https://bugs.chromium.org/p/chromium/issues/detail?id=1178058>?

when writing, consider that the decision makers are in the same org with the AVIF developers -- it may be best to avoid a strong polarization between the formats in the bug by writing like something softer like "while AVIF already brought us big benefits over previous systems, JPEG XL's feature set and image quality guarantees are an overall better fit to our use case"

if you write "JPEG XL gives us 11 % better quality than AVIF or JPEG XL is 3x faster to encode", then it may polarize and the AVIF developers may become defensive and may find reasons why the test setup may be not optimal (for example due to using dav1d/etc instead of libaom)

Consider helping Discord identify that link.

ah, yes, it has trouble with the ending “?”

here you go: https://crbug.com/1178058

I tend to use brackets `<>` mainly because I don't like large embeds, but they can help with formatting too.

fixed 😄

Currently we have 4 groups of contributors: codec architects who made the big decision decisions, format developers who significantly influenced the coded design, libjxl developers who contributed to the implementation, and we have people who helped with the standardization (sat in the ISO meetings or prepared input documents)

Where exactly, if you're allowed to tell?

as in the name of the site?

I guess we could live with just an IP address.

The site is archivesort.org but the portion that uses jpeg xl is closed while we fix crucial security vulnerabilities (unrelated to jxl)

We hope to open it back up later today or tomorrow

just saw this. Will keep this in mind!

Here is what I will write: My site makes use of both AVIF and JPEG XL heavily, especially for the archival of multimedia heavy sites…. As a content provider, we need to be able to balance the ability to have small file sizes while preserve content quality at the same time. While AVIF and JPEG XL produce arguably same content quality, JPEG XL encodes signfiicantly faster while AVIF provides smaller files. The AVIF encoder process (on libaom) is slow enough that we don’t even need to put on rate limiting as the images are transcoded as soon after they are downloaded. Decoding is also pretty fast as well. The only reason I used AVIF in the first place is because I needed someway to reduce the size of the files, but once I found out I could do that while preserving image fidelity, I was immeadately hooked. I believe that AVIF is trying to kill two birds with one stone - which is all fine and good, but most content providers may only want one of those birds to be killed. As an archive, we also care about preserving the quality of the photos. JPEG XL is able to compress losslessly images already in JPEG format. This is important for certain sites that already have low quality images - we don’t want to make their quality even worse. Considering the strengths and balances of each format, we decided for a two pronged approach - while we use mostly JPEG XL, AVIF also has its place for "less important" images. For the software we use its the standard jxl library along with a custom in house multimedia transcoder to dynamically convert to and from JPG and AVIF/JXL. Even though Chrome has native AVIF support, many browsers do not, and a great number of people are still on older versions of Chromium. The ecosystem for jxl is also more developed in my opinion, and me being a busy person, I would rather work with something that's already there. If you want benchmarks and hard numbers about my experience that I can make that avaliable.

Overall, I think jpegxl is a better fit for most organizations because of the fast encoding times and the lossless component. Who doesn't want to save free space if it means no reduction in quality? (Edit: JPEG XL is important for user directled archiving, where people expect the archived pages they submit to be there fairly quickly. In this instance there is no time for avif)

Don't get me wrong; AV1 has its place - however I think that place is in video. We do have an extensive video archive where we try to use as much av1 as possible. But for images, I think JXL takes the cake

jpeg xl is better for web excepting thumbnails afaik

easy to encode, can losslessly compress old jpeg files, good generation loss tolerance

the generation loss thing is really important for social apps like discord or facebook since people often screenshot an image and repost it often to the point of it being copied **several hundred times**

i think jpeg xl is also a lot faster to decode than avif (iirc even faster than jpeg sometimes?)

a lot, yes https://www.youtube.com/watch?v=UphN1_7nP8U

oh progressive for sure i was talking about cpu time

but if cpu decoding is fast enough then network is the bottleneck so progressive decoding is helpful

progressive encode add noise to the photo also file at parity quality are x20 bigger are bigger than a png

also not every person will encode progressive

jon sneyers has said that progressive for him isn't a priority

he wants that it works on browser and on GIMP

with whatever options

honestly if those modular options would work with newer encoder it would be a lot better

https://discord.com/channels/794206087879852103/803645746661425173/832701921352613959

those are very simple

? Progressive is a priority

what is "progressive encode"?

<@794205442175402004> I think <@!416586441058025472> may be referring to a comment you or someone else made recently that it's important that browsers don't just support some subset of features (and that that's more important than having progressive decode work)

Ah

The range for -g is 0 to 3

<@!532010383041363969>

looks good to me

My face while decoding this file:

Artifacts are strange in this picture <:Thonk:805904896879493180> it looks like rainbows

Was AI enhanced to the extreme and source was a jpg to make it worse

<:YEP:808828808127971399>

https://cdn.discordapp.com/emojis/683380703958007852.gif?v=1

https://tenor.com/view/meme-among-us-discord-gif-19878487

Q: I just wanted to double-check something: given an artwork source in <#824000991891554375>, is it correct that I won't be able to use it without the super-secret dev branch of the repository, or can I still do it with the public branch?

as of yesteday also the public branch 🙂

Ooh!

you can't crop the image IIRC though (needs changing the source code by hand :D)

But I can still generate a 1024x1024 tile?

For example (just picking this at random from <#824000991891554375>): ``` Bitdepth 4 Width 1024 Height 1024 Squeeze if c > 1 if |W| > 2 - Set 0 if N-NN > 0 - NW 1 - NW -1 - W 1 ``` what's the canonical way to produce that image with the public repository?

just use jxl_from_tree on this file

it should work

but if you want to have a larger image that is cropped to hide some parts, IIRC you can't

You can't yet, I need to make a merge request for it (it's not hard)

New image codec comparison tests are consistently invalid and overestimate savings <https://encode.su/threads/3615-New-image-codec-comparison-tests-are-consistently-invalid-and-overestimate-savings> 🤔

Wait, is the guy lying or just uninformed?

I just tried using ECT on that Huawei sample he linked, and it's already fully optimized.

It's optimized to 7kb, but still I don't think the article has the right conclusions and that all the comparisons use only unoptimized images

How did it get optimized down to 7kB in the 1st place? What does File Optimizer do that's different vs ECT? Anyway, I agree with your conclusion as well.

> I don't know if these files are used for comparison reporting Okay, then how does this support the point?

It's a bad argument, but the concern is valid. Can the new stuff that hasn't had the decades of optimization squeezing compete with the old stuff and the deeper advances made with it. My assumption is that over time the new stuff would get that same level of attention and eventually have it's own tools and eventually a gauntlet style program and would easily outperform current day state-of-the-art (if it doesn't already).

But, yes, sometimes there are comparisons with non-optimized images, including lossy comparisons with not the best encoders for older formats

The concern is certainly valid. Especially for lossy, actually. In lossy it happens often that claims are made w.r.t. the worst possible JPEG encoding (e.g. default libjpeg-turbo without even huffman optimization), or made by looking at not-very-meaningful metrics that are easy to optimize for (like psnr).

Also, afaik, that test image is not used at all for comparing compression efficiency. It is there as part of the CI software tests to catch bugs, that's the only thing it is used for afaik.

Chrome eng asked us to have at least contacted webkit so I wrote something on this bug: https://bugs.webkit.org/show_bug.cgi?id=208235

Consider getting onto its cc list, or possibly even adding more useful data there

Hi, I recall there being a website where you could upload and compare the compression of various image codecs (including jxl) but I can't find it. Does it sound familiar to anyone?

https://squoosh.app/ ?

That's it. Thank you!

any relevant parameters to add?

<@!264189852617146368> `jxl_from_tree tree_in jxl_out [tree_graph]`

Yup

https://twitter.com/addyosmani/status/1387431906359185408?s=19

Chapter 19 is on <:JXL:805850130203934781>

it has a lot of my work described guetzli, butteraugli, jpeg xl, webp lossless, zopfli, zopflipng :-]

<@!792428046497611796> don't you think that `Developed by` section in enwiki article's infobox requires a little bit of cleanup? It's kinda cluttered atm

I think it's more intended for companies/organizations than for names, like

Me too.

Someone moved the section "Authors" to the infobox. I don't like that edit but I didn't want to start an edit war so I didn't revert it. Good that you mention it here. Shall we revert it?

There are some other things I'd like to either change or remove, but I don't want to start an edit war either... Good that you've brought this issue up. At least I can control Polish article, plwiki (contrary to enwiki) requires reviewing every single edit, so articles are held to a bit higher standard IMHO.

Chances are that someone else will also notice the same things that we want to change and just do it, I don't want to handle it ¯\_(ツ)_/¯

That edit was made from Zurich (based on IP WHOIS). Who could have been that? 🙂

I don't know.

Could make sense to keep it shorter in the infobox, e.g. only mention JPEG, Jyrki (Google), Luca (Google), Jon (Cloudinary)

And in the main text have a larger list

Or something

We could also get some inspiration from Wikidata where the individual fields (that can go to infoboxes and elsewhere) ared described.

Another change: someone removed the `(as of April 2021)` from `Software` section title despite me linking to relevant WP Manual of Style entry in the edit summary and I don't have time to discuss it to be changed back with others. If I had, I'd ask someone else (Redactor, Admin etc.) what to do with it.

Hmm, this isn't very helpful because it mentions both people and organisations: https://www.wikidata.org/wiki/Property:P178

I think both are useful information. Just have to be a bit more concise in an infobox, I don't think there's room there to add a long list of contributors.

Hello, I have some question about generation loss, I plan transform some jpeg image and h264 video to new format(jpeg xl and av1), i understand lossy format transform to lossy format will get some generation loss. Choose near or higher quantizer on jpeg xl and av1 encoder, can reduce generation loss? I hope compressed file can keep good quality(near lossless) and reduce file size, (I using ffmpeg transform h264 crf 21 to h265 crf 20, can reduce half file size and still fine) example: jpeg q99 yuv 444 => jpeg xl -d 0.5 jpeg q90 yuv 444 => jpeg xl -d 1.0 jpeg q80 yuv 444 => jpeg xl -q 80 h264 crf 21 => av1 --end-usage=q --cq-level=20 (Constant Quality) h264 crf 24 => av1 --end-usage=q --cq-level=21 (Constant Quality)

If you worry about generation loss, best is to just losslessly recompress the jpegs

jpeg->jxl can do transform which doesn't do generational loss

(different from usual lossless modular mode)

If you want to compress more, it probably does make sense to not do very high quality encodes of low-quality jpegs, since that can easily end up getting larger than the original

I'd say do lossless jpeg recompression if the jpeg is below quality N (if you know that; can estimate by looking at quant tables), otherwise if it's a very high quality jpeg (at least q90), do -d 1.0

look here if you want to find settings

https://docs.google.com/document/d/1ru-J-6059QHtgYkrE1pB_T97O2sEGZYhDlEoiTYkbbo/edit

if you need like

jpeg xl will get good at -s 9 -d 2.21 will have good performance at -d 0.5 -s 9 -d 2.21 and up to -s 8 -d 4.45 i try to predict the future now the safe value is up to d 1.261 custom settings s9 and -s 6 -d 2.3 stock

....,

ETC

wait for new build/commit

i did a settings one time that causes image to shrink but i had few invalid files

don't know why nobody told him it (NO JPG support in jxl ewout builds)

new commit will be probably out when May will end

so you need to wait in that case

also chrome/FIREFOX will start integrating on august 31th stable chome 93 feature freeze 17 june 2021 or something so at least 2 month to have initial support in browser

I DID ALSO TEST WITH AVIF:

https://discord.com/channels/794206087879852103/794206170445119489/837600695661625354

here you can find the build:

https://ci.appveyor.com/project/louquillio/libavif/builds/38598210/artifacts

https://www.reddit.com/r/AV1/comments/l5drhd/fresh_libwebp_libwebp2_and_libavif_windows/

Where does this information come from?

that i thought

in this case search on discord

spidermario or wb said it

one of the dev

https://discord.com/channels/794206087879852103/822105409312653333/836512826469253130

"in an optimistic scenario" <@794205442175402004> was talking about the earliest possible time; not about when it will actually happen.

I can allow some generation loss, new format can bring much size benefit, (in my test, some non-photographic jpeg yuv 444 q80 to jxl -d 1.0 can reduce size and quality still keep good, butteraugli is very useful) For non-photographic video and image, if i can allow some generation loss but don't want get too much, choose near quantizer should be fine?, (h264 crf 21 to av1 q 19~20) and (jpeg q90~q99 to jxl d1.0~0.5) (choose too higher quantizer will get bigger file)

in my opinion, -d 2.21 is too risk, jxl -d 0.8 and 1.0 will in safe zone

just don't change formats from one to another too often; that's the worst case for generation loss

transcoding jxl to jxl generally doesn't cause much loss (but of course something)

I wonder how jxl behaves w.r.t. generation loss if you alternate between lossy modular and vardct. I'd expect it to be a lot worse than staying within one.

mozjpeg q80 and jxl q75 there's no much difference

the new encoder don't make bigger change

like first thing you notice is red saturation strong pinwheel effect

but the image look good even with galaxy s4 screenshots

at least with the jpg i've tested

if you need d 1.0 use only s9

i didn't get huge saving

it also depends on the encoder

I wonder what would happen in that scenario if we restricted VarDCT to just 8x8 blocks, like JPEG does

I'd expect less variation in encoder choices to be better for generation loss.

butteraugli can constraint vardct quantization process?

I guess so, but I wonder how would it look like visually. The transform is exactly the same as in JPEG, but there's also XYB, EPF, Gaborish, ...is that all?

at some distances i prefer s 8 as i said, s 8 in next build up to d 4.45 i will use maybe

the problem is the user that don't know how to use jxl

how he will do

an automatic heuristic would be better to add on top

how to add png support

how to contact ewout

can i spam in that reddit link some question to him

open an issue in his repo?

appveyor is not a repo

and also i don't use gitlab

do you advice me to contact ewout replying to one of the comment in that reddit post

do you think he will receive notification of an old reddit post

i don't know

ok

I want find a size and quality balance point, compressed file have some generation loss, but still look good and reduce much size, Before i create python script use butteraugli_old and libjpeg to recompression jpeg, butteraugli will make sure compressed file still ok, I plan use jpeg xl -d 1.0 and -d 0.5 to recompression non-photographic image, but i not sure non-photographic video can use same method on av1, In my test, h264 crf 21 to h265 crf 20 can reduce half size and quality still good(crf 18 visually lossless), I just worry choose near quantizer is not a good idea or maybe i made some mistakes?

<@461421345302118401> What kind of generation loss are you worried about? As in what sequence of transcodings would you expect your images to be subject to?

fot non-photographic content, lost some little detail should be fine, I worry artifact and noise, hope compressed file still look good(like original). [lossy]jpeg yuv 444 q80, 90, 99 => [lossy]jpeg xl -d 0.5 and -d 1.0 [lossy]h264 crf 21, 23, 24 => [lossy]av1 --end-usage=q --cq-level=19~20 (Constant Quality)

One re-encode should usually be fine

Generation loss is mostly a problem when repeated re-encoding is happening, like when images go from facebook to twitter to whatsapp to instagram, and each of them does their own pretty lossy transcoding

Mozjpeg 81-87,4 q 79,1 --epf= 2 --dots=0 --noise=1 JPEG -d 1.114 -s 7 Mozjpeg 92 -d 0.921 -q 88.61 -s 6 --noise=0 --patches=1 --dots=0 --epf=2 Mozjpeg 90 -q 90,9 -gaborish=1 -s 8 to -d 1.99 -s 6 Mozjpeg 82 -q 71.9 wp2 -effort 6 + 92,81 cavif rs 0.6.6 -effort 0 Mozjpeg 81 -q 74.4 jpeg xl Mozjpeg 80 -q 61,95 -s 9 -q 65,41 -s 7 (depending) Mozjpeg 70 -q 62,19 -s 8 -q 95,28 -effort 7 wp2b (definitive) Mozjpeg 65 -q 87,95 -effort 8 wp2 Mozjpeg 60 -avif q 38 -effort 9 --sharpness 4 --more color extra chroma compression tune for vmaf noise synthesis 4 libavif d37ef741 https://ci.appveyor.com/project/louquillio/libavif/builds/38598210/artifacts Mozjpeg 55 keep it lossless Mozjpeg 50 keep it lossless

this are totally invented values

mozjpeg 60 you will laugh

vmaf with noise syntesis sharpness and extra extra chroma compression don't exist

do not know

maybe bluesword is more informed of that

of AVIF codec

the problem we can't know if some photos are made with old jpeg encoder

also those values are invented

-q 87.1 with gaborish made a sense

the best thing is evaluating the image and ignore those random values

like you choose any of that or different

actually evaluating the image

seeing the original source

but jpg won't never compress as a png if you encode anime of ex

but that's a problem for who provide that content

maybe i will try also with butteruagli tool if i can download png images

ok, I understand, Hope next jpeg xl release can fixed my vardct issue, <@!794205442175402004> <@!799692065771749416> <@!260412131034267649> <@!416586441058025472> Thank you for your help 🙂

i'm sending reply to ewout

anyway new encoders will come

if you can wait a month

Will those do anything that helps here?

no i'm not a developer

and i can't predict the future

i can ask bluesword and ewout

3 thing i need

Then why do you mention it here?

Yes, of course new encoders will come, but why does <@!461421345302118401> need to wait for them?

i don't know

i made first question

https://www.reddit.com/r/AV1/comments/l5drhd/fresh_libwebp_libwebp2_and_libavif_windows/

bluesword is not online

h265 is a video codec is stores a frame then the some inter prediction, jpeg xl stores only intra, is only intra

I don't use BPG on my still image, i will use jpeg xl

phone or camera files?

or even scans?

??? I think my target image is drawing(non-photographic).

I wait some vardct encoder improvement, Jyrki Alakuijala say need three weeks.

jyri in twitter

said he needs a few weeks

so if you are interested in those distances like those

https://discord.com/channels/794206087879852103/794206087879852106/837724470914318337

i would wait the month

Please provide proof, <@!799692065771749416> always needs proof. 😁

For drawings try both Modular and VarDCT, the former might actually give nice results. But you shouldn't overdo it, because Modular tends to make square-ish artifacts, which is the last artifact you'd want to see on continuous lines (VarDCT makes more natural lines). Go figure.

Would you want to send us some examples with your desired compression level, please? I'd like to tinker with it a bit.

https://discord.com/channels/794206087879852103/794206170445119489/827962210965782559 <@456226577798135808> <@456226577798135808> probably this improvement is already implemented? 🙂

Should be, but you never know what "x amount of time" really means in the end.

0.4 is also quite a bit behind schedule.

indeed, it's not 😛

we're trying to get to 0.4 by the chrome 92 branch cut

it should be possible, but you wouldn't *believe* how many things crop up (for me specifically, particularly busy ISO weeks and PhD defenses don't help)

https://i.imgflip.com/1tdjtd.jpg

☕

https://tenor.com/view/mr-bean-waiting-still-waiting-gif-13052487

That was really really sad... Chrome 92 Beta coming Jun 3 - Jun 10

?

Q: are there any educational materials targeted at technologists explaining the mechanics and modes of JXL?

(other than the official docs, I mean)

Except for some presentations (which are more targeted at the wider audience), and old papers, I don't think

And maybe something can be found about FLIF/FUIF and PIK as JPEG XL ancestors

We have work to do to explain all the stuff in jxl

My slides here are a start, but it's quite superficial and partial: https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit?usp=sharing

I think i need wait another month(chrome 92) until next jpeg xl release 😢

what it was that site where check chrome stats

No, we will likely keep doing regular syncs / releases

Also planning to move development to a public repo so you get changes immediately (and useful commit messages, and others can contribute)

https://www.chromestatus.com/features/schedule

https://youtu.be/sAURUtjBGhg

<@794205442175402004> suggestion: please redo this video, but this time with - MozJPEG - JPEG XL (VarDCT) - JPEG XL (Modular) - AVIF and PSNR together with Butteraugli as metrics. No hurry, of course 🙂

That would be interesting indeed. Do you want that specific image or one with color?

I think it would be interesting to see both photographic and artificial images with clear lines, like art, comics or charts/UI

Can higher quality lossy modular outperform, in subjective quality or size, vardct on things like diagrams, vector illustrations, and cartoons with distinct lines?

Maybe, but it is mostly a question of encoder decisions. I suspect that for a lot of such material, a good delta-palette encoder with a smart palette choice would be better than either vardct or squeeze.

(or even regular modular with just quantized predictor residuals, with quantization amount depending on `WGH`)

At first I wanted to see grayscale line-art (to exploit Kornel's famous mozjpeg patch: https://kornel.ski/deringing), but Scope's got a point. Maybe the first panel of xkcd from your original video (in order to save visual space) and a photo?

I can do multiple comparisons. Just need to find that script somewhere, lol

(also not likely to happen today)

Again: no hurry 🙂

Maybe share it? I'd probably be able to rewrite it in Python (that I feel more comfortable programming in) and run it on my PC...

I think maybe one of the youtube videos has the script in the description or in a comment

It's quite straightforward, just need to manually figure out settings that result in the same bpp for that image

And need to alternate between at least two different q settings because otherwise some codecs like jpeg can converge and stop getting generation loss.

I know. That one should be easy to do in Python: just do it with an RNG with hardcoded seed (for repeatability).

<@456226577798135808> A little curious, you will use which python module to implement concurrent and async?

...not using any currently, haven't learned that yet 🙁

my cjxl python have some issue, I implement concurrent features, but some time when cjxl encode too much big image in same time, 16GB ram is not enough...

Try faster speed settings

I using ryzen 5 1600 16GB

Slower speed also eats more memory

for big image i only can concurrent 4 cjxl instance

small image can concurrent 10~12 cjxl instance

Is possible estimate slower speed roughly ram usege? example: if image large or near 2099x3012(2.27MB), cjxl slower speed have chance use more ram.

There might be encoder memory improvements in the future, so far the decoder has been a bigger priority

Encoder memory is fine, i actually need vardct improvement for drawing 🙂

<https://www.reddit.com/r/linux/comments/n2o9ha/call_to_action_for_developers_in_light_of_the/>

People still keep mentioning ZPNG as a good alternative to new formats <:Thonk:805904896879493180>

Yes, although there may be some other implementations, but people can not understand that this is not a simple migration, it is very little different from the adoption of new formats, in addition will add to the confusion and compatibility hell if the PNG extension remains the same

It is like adding alpha to jpeg. It is straightforward technically: you can make 4-component jpegs (it is quite common for CMYK), all you need is for software to interpret the 4th channel as alpha

But doing that is as tricky as getting a whole new codec adopted

Basically a format is always what it was initially, you cannot really do extensions

APNG is nice but there is still a lot of software that will just show you the first frame

JXL speed 3?

(depending on what png compressor you compare to: png encoding can be as fast as `cp` or as slow as you want)

It all depends how you measure

What is the png encoder he compares against, on what images, etc

I'm sure you can be a lot faster than zopflipng but also denser if you use zstd/brotli instead of deflate, especially for images that do not benefit much from lz77 matching but they do benefit from better entropy coding than just Huffman...

Interesting, I see some anime site start use avif, i think image format war is start, chrome 90 decode speed is fine.

jpeg yuv 444 to avif yuv is fine, but i think png rgb to avif yuv is not a good idea, need use avif ycocg

I think that is english site(not sure), not sure, image avif(drawing type)

talking about fonts, how should be a font to resist re encodings and lossy image compression?

should be the shapes less rigid?

for example i worry that i can't compress graphs because there is my font suduwe in there

for example someone sent this in r/av1 server

Thanks! This looks promising.

It was me 😉

ok

menu 9 nouveaba plate

suduwe icon 12

firefox suduwe 12

text suduwe (myfont) 10

i don't know how they compare

maybe with text only i i can readfd

also using text as such lower sizes without serif

even if the serif they are, there isn't monospace

and they are too small

and i'm noticing i have difficulty to read this font faster than 95 fps

anyway i don't need

so i maybe should revert to the old font i used

guaruja grotesk and google sans aren't bad

why use strange fonts?

also as i said earlier there is a problem with re encoding

even with jxl, dev don't assume responsability if i choose to use the font i forked from others two

https://github.com/VanillaandCream/Palanquin

this is the most looking alike of what i made

this i can legibility 100 fps readable 140 fps

this is latest version

also there isn't a equilibrium between letters.

so that makes reading long messages on discord worse and reading my messages worse, because you have to think about the formattation.

I want to compress dngs to jxl losslessly to save space. What is the right procedure?

There isn't one yet

You could extract the pixel data with dcraw and encode it as a 4-channel image, but we still need something to preserve the metadata

Question is if you want lossless DNG (before debayering) or just lossless (or even high-fidelity lossy) high-bitdepth RGB

Both are in principle possible but the first has no tooling yet while the second could be done right now

I just want to develop dng on Adobe Lightroom classic in future. Which method is good enough for that purpose?

Could you send me your imagemagick pkg?

Yeah I am a Arch user

Or send pkgbuild pls

Thanks <@456226577798135808>

i will test, but it's not clear, dng can be 3 type of picture, (jpeg 8bit in it, tiff compress, or bayer lossless compress, plus LOT of metadata) The magic future is to compress lossy(or lossloss) bayer picture, for reducing size with very small reduce of quality.(debayer picture is way bigger than bayer picture) Some dslr can do that in their raw, but it's not tunable.

The new Apple ProRAW is basically (afaiu) a HDR RGB image (plus some auxiliary images for all kinds of other info the camera has, like depth maps etc, and a bunch of metadata)

For the payload images (main and aux) of that, maybe jxl could be a good codec.

How do I find the type of dng? Identify output from a dng from my phone - https://bpa.st/6NCA

it has a **lot** of metadata

https://www.adobe.com/content/dam/acom/en/products/photoshop/pdfs/dng_spec_1.5.0.0.pdf chapter 4

I would be surprised if there is much at all that one can do with a DNG with the metadata stripped

if it's a dng from android photo it's a bayer picture, you can see the bayer matrix with darktable software :p

Look at the beauty of an classical bayer raw 😄

i don't know what is the best solution for encoding it lossy, like an big 16bits grayscale or 4 layers, because there are big light difference between each color.

I do the test with "adobe dng converter", all theses files are .dng : Original dng 16mpx from my phone: 30.6 Mb (because android phone are so stupid with no lossless compression ...) lossless dng: 11.3 Mb linear dng (debayer): 69.1 Mb lossy dng (crap 8bit jpeg) 8.6 Mb We need a "dng 16bits jxl" bayered an unbayered lossy and lossless 😄 jpeg in dng have an huge advantage, it keep the white balance temperature (kelvin+tint), so i can batch tune a series of photos.

the lossy compression in Adobe DNG Converter is so bad, I couldn’t believe it when I saw the artifacts

it's not about the jpeg artifact it's about the stupid 8bits who destroy the black and white of picture BEFORE retouching and adjust "contrast". At 800% zoom i don't see artifacts for an jpeg in dng.

I don’t really see what you are referring to, why are you mentioning jpeg artifacts?

or 8 bits

You say that lossy dng is bad,right? (lossy dng is only a stupid jpeg 8bit in a dng)

I was referring to this setting myself:

ow, is it?

the artifacts didn’t look very jpeg-like to me

YES i read the dng spec

it's their custom jpeg encoder internal

oh my, it’s true

why

Because they are stupid, it's adobe :/

we need to spam adobe to add jxl in their dng 😄

the main artifact I remember was posterization, especially in blue skies

This is the magic of 8bits picture with sun 😄

Why does it crash when quality is 100 🤔

<@!794205442175402004> for this 😄 (but maybe filing an issue might be a good idea...)

looks like it somehow tries to do modular with at the same time XYB and lossless float, which doesn't really make sense

jxl issue - we should do something different than having an assert fail when we get called in this way

Is there a good literature review on various image coding error functions? (As in MS-SSIM, PSNR, etc)

I'm already pretty familiar with the above, but not particularly familiar with other algorithms, and I'm not *especially* familiar with how they might compare to each other.

And is "just use butteraugli" a sane approach to evaluating error on photographs?

It's a good approach, yes.

For pure image quality, butteraugli is quite accurate from my testing in photographic images.

Butteraugli is good for medium to very high fidelity

For ultra low to low fidelity, it is not worth much

That's perfectly fine with me. Though, if there's no good literature review that would help answer these questions, is there anywhere where these shortcomings of the various functions are well documented?

This is something I think we need to work on in the future

Better metrics and better validation/understanding of existing metrics

Both butteraugli and ssimulacra were created rather pragmatically because we needed something better than what was already out there, just to do the things we wanted to do

The scientific/academic publications around it still need to happen though (usually a low priority thing if there is other stuff to work on, and there always is)

-q 94,6 -X 22.4 -Y 38 -I 0.68 -s 3 -m -q 99,03 --effort 2 -q 78,079 -s 5 -epf=1 --noise=0 --dots=1 --gaborish=0 --patches=0

This was fine with april 22 jxl and wp2 jamaika doom9 builds 01052021

Dont know if it can be considered

Fidwlity

Is there an existing one that performs well at these low bpps?

I think the new AI-based ones are most suitable there

LPIPS and PieAPP, for example

At some point you can just as well use no-reference metrics

Unfortunate but understandable. Thank you!

https://twitter.com/kamedo2/status/1390680189416349700?s=19

Always funny to get tagged in a tweet in Japanese 😅

At least now there are translators and it is possible to understand any language (except some very exotic)

but we don't have jpeg xl chinese wiki page?

You can create one.

<https://encode.su/threads/3615-New-image-codec-comparison-tests-are-consistently-invalid-and-overestimate-savings?p=69632&viewfull=1#post69632>

> **Jyrki Alakuijala** > In JPEG XL lossless we copied over what worked very well (entropy clustering, 2d distance LUT for LZ77, non-byte-based LZ77, delta palette, recursive format definition -- i.e., side channel images, palette etc. use the image format itself in a limited way). We added stuff that needed more attention (patches for text, Alex Rhatushnyak's lossless photo compression predictor, context trees from FLIF/FUIF, larger support for prediction, mixed non-delta/delta palette). We did also remove stuff -- like the color cache and the pixel bundling in the color indexing transform. > > The entropy clustering idea from WebP lossless is also the main idea powering fast context modeling in Brotli, Brunsli, PIK, JPEG XL and WebP2 lossless. By clustering entropies, we combined different contexts and have overall less entropy codes. Having fewer entropy codes means a smaller working set, less pressure on the memory system. Having fewer entropy codes reduces the cost of sending over entropy codes. Having fewer entropy codes reduces entropy in explicit entropy coding control data such as blocks and context maps in Brotli, and the entropy image in WebP lossless. Having fewer entropy codes allows us to have the full, boring, LUT-based, fast and simple entropy codes to be defined for each context instead of the more traditional approach of taking a base entropy code and manipulating the entropy coding depending on the context -- through arithmetic coding, symbol ranking or other approaches.

> The first version of PNG took about 4 months to design and implement. It took me 6.5 months to design WebP lossless, another half a year for the WebP team to productionize (security hardening, integrating WebP lossless as lossy alpha, streaming decoding, converting from C++ to C). JPEG XL (accounting its development trajectory from Butteraugli/Brunsli/FLIF/FUIF/Guetzli/PIK has been about 7 years of "sous vide" design, and now about half a year in the productionizing.

> This is how I can decode now with Ubuntu linux... > wine cjxl.exe INPUT.jpg TEMP.jxl && wine djxl.exe TEMP.jxl OUTPUT.png > Using Windows binarie.

If you use Linux it's super easy to just use cmake

Plus there's instructions on the gitlab for building

Using wine + windows binaries to run cjxl in linux <:kekw:808717074305122316>

Linux users are not what they used to be

Which is a good thing

Yes

Just have to get used to it

We should make `sudo apt install jxl` work

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948862

If someone knows a debian maintainer who can make stuff happen, that would be great

no that sounds absurd

It's good that Linux has become approachable enough that it has not-so-savy users.

Compiling source code is not exactly convenient even if you're familiar with it, and most people are not familiar with it.

it's a blessing and a curse

but yeah if semi-official binary builds are provided then they should be for linux too

I have the option of 2 and 4.

1 x 4 (archlinux aur using aur helper so stuff's effortless to update)

aur isn't official repo so 1

yeah i guess im too sleepy

2a. compile and don't install

(you can just run cjxl and djxl directly)

iirc blue is running maybe openmandriva?

that's definitely reasonable as tracking system binaries without package manager isn't fault-free

This is true for almost all typical open source tools.

It's different of course once you include libraries that other packages rely on. That's also possible without installing, but it gets hairy passing all the paths around.

https://old.reddit.com/r/AV1/comments/mfhkro/openmandriva_linux_now_has_native_jpegxl_packages/ https://postimg.cc/dkRmQdNb

I just asked the devs nicely, and they complied 🙂

In fact, JPEG-XL is on route for being in the next stable release of Openmandriva by default, including QT support and native Gimp support if I recall correctly.

It seems by default cjxl and djxl statically link libjxl, so that's no issue. In other libraries you sometimes see libtool trickery, where the produced "binary" is really a shell script that sets LD loading path correctly to find the libs, and then invokes the real binary.