JPEG XL

Might be better to detect this case in the encoder itself, not in the input loader. PNG input will eventually not be the main entry point to encoding anymore.

Quickly counting colors up to a small N of colors could be done on the input pixels - you only scan the whole image if it actually is a palette image

> nano You really can't run a graphical text editor? gedit uses about 10x as much RAM as nano on my system, but that's not much.

https://cudatext.github.io/

i used to use kate for all my coding back when my computer was weak

its pretty good

I use vim all the time and it's the best editor ever. Change my mind 🤣

vim is pretty great too

i just find gui stuff more fitting for project/multifile editing, because proper file lists, tabs, etc

I’ve used kate too

I used it with its vi mode

vim has tabs 😉

raspberry pi 4 is out of stock everywhere 😭

rip

https://twitter.com/chigbarg/status/1448817993329250334

does it accept *all* possible answers? 😄

I've consulted the Vim manual and the relevant regexp would be: ||`/^:(c?q(u(it?)?)?|q(u(it?)?)?!|wq!?|x(it?)?!?|exit?!?|(q(uit)?|wq|x)a(ll?)?!?)|Z[ZQ]/`||

lmfao

wait that accepts `:wq`

it says quit without saving

oh, it does say "without saving"

that would simplify it into ||`/^:c?q(u(it?)?)?!|ZQ/`||

that simplified it a lot lmao

uh $?

ah yeah, that would be needed

anyway

another possibility is of course `:exe "!kill -9 " . getpid()`

https://github.com/hakluke/how-to-exit-vim ...and I'm waay late about that joke

ooh apparently | has higher precedence than ^ or $ so you need some more parens

I haven't found a vim mode that is not buggy or incomplete in some fundamental way yet :P

from what I recall, IdeaVim uses an actual vim behind the scenes

so at least it comes close

even supports macros

All my prophoto icc JXL's thumbnails look dark and weird on windows 10. 😔

what generates those thumbnails?

jxl_winthumb.dll. I got it from someone on jxl sub reddit.

Yeah I've noticed some issues with that as well, Windows is pretty spotty with colour management

in windows 11 colour management is completely broken

for the thumbnails it's not windows, it would be <https://github.com/saschanaz/jxl-winthumb> not applying the icc profile

I can't, I'm on WSL 2 in Win10. I need to edit those files inside Linux. Graphical text editor wouldn't help me either, I need code hints which only IDEs have.

You can try micro, at least it has syntax highlighting https://github.com/zyedidia/micro

> - If you have to use Windows, then consider adding more RAM Zero budget. I already have 8 GB, that should be enough! It's pathological that it isn't! I can compile x264 from source and it's a no big deal, while compiling libjxl is a big event that takes so much RAM I have to close some apps sometimes so WSL doesn't get killed! Maybe it's time someone rewrites libjxl to Rust + assembly, like rav1e? > - Or just dual boot to Linux, preferably using a lightweight distro and desktop environment if you have little RAM I already have WSL 2. > - Or get a SBC like Raspberry Pi 4 with 8GB RAM for coding. On the plus side, you can also do ARM development on Pi Like above, zero budget. If I buy one, I'll use it for seeding torrents.

I can't use anything that uses GUIs, I'm limited to CLI because I'm on WSL 2.

`micro` is terminal-based editor

nano has syntax highlighting, too, but that's not enough. I need code hints in a CLI.

(If it's possible to achieve that at all...)

For example: if I see a function call, I could Ctrl+click it and Dev-C++ would "teleport" me to its definition. Same with Ctrl+clicking header files.

If memory is an issue, try compiling with fewer threads

There is always `neovim`, but it requires the conversion to vim <:CatSmile:805382488293244929>

I use this command: ```bash cd libjxl mkdir build cd build cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF .. cmake --build . -- -j$(nproc) ```

NO VIM

Try `-j 2` or so there

I've got some suspicions how it got its name...

Like if compilation wasn't already kinda slow...

Well you kind of only need to do full compile once

Even partial compile takes hundreds of MB of RAM

I usually build with `./ci.sh opt` the first time, then do `ninja cjxl djxl benchmark_xl` in the build dir while I'm making changes, then at the end do another `./ci.sh opt` just to check that the tests pass

I think `ninja` works slightly better. ``` cmake -G Ninja ninja ```

The first (and only) time I used `./ci.sh` my RAM went out of the window, making `cmake` the only available option on my machine.

To prove my point I've just compiled x264. From start (`git clone`) to finish the whole thing took 2 minutes, 400 MB RAM and 50% CPU. libjxl would take over 5 minutes, over 1 GB RAM and 80% CPU.

Is that clang or gcc?

Testing myself I topped out at 1.3 GB of RAM used in compiling. I'm on native debian (x86_64) compiling with gcc with `-j 4`.

you can use graphical applications with WSL, however you need to install an X11 server separately such as https://sourceforge.net/projects/vcxsrv/

once installed and running, you can run graphical WSL apps by giving them the appropriate “DISPLAY” environment variable

(the tray icon will tell you what the value for DISPLAY should be)

I don't remember exactly what libjxl used, but x264 used gcc.

I wouldn't be surprised about 1.3 GB RAM, unfortunately it's an achievable number.

I compile libjxl on 4gb ram. Why can't you?

I compile libjxl on my phone

Phone does have 6 GB ram though

https://twitter.com/mags_mclaugh/status/1449502561548087301?t=v5_XjU_FGRZ8D1VmSZPJOQ&s=19

The generation loss on that

Retested with `-j 1` and sampling memory usage every 0.1 seconds and the peak usage I got was 405 MB. So not too bad.

Clang or gcc?

How do you get so much RAM usage from building libjxl?

Native debian unstable (x86_64) compiling with gcc 11.2

Hi, I am writing to aquire about size of compresed image. Can we define a final size of jpeg-xl file? For instance, we have an image of size A and we want to achieve a file of size B. Of course B < A. Thank you in advance!

`cjxl --target_size=B` does exactly that

this is not a recommended way to compress images for anything other than testing purposes, imo

Thank you a lot for an answer!

<@!604964375924834314> any chances for doing something with https://github.com/libjxl/libjxl/issues/665 ?

oh, right, I suspect that this might only really be feasible when using XYB

as the noise addition assumes this

It's for Squoosh, IIRC it has no reason not to use XYB by default with lossy Modular.

oh 🙂

Cjxl does xyb by default for lossy modular

And for lossless modular noise probably doesn't make much sense, except maybe for <#824000991891554375> purposes

Anyone know of a way of viewing jxl on android?

djxl in termux <:kekw:808717074305122316>

Tachiyomi (manga reader), Firefox (Nightly?) or Chrome No image galleries supporting jxl yet afaik

Chrome should be the easiest one since <:JXL:805850130203934781> works in a "usual" stock version, just go to `chrome://flags#enable-jxl`, enable the flag and restart the browser. Firefox will be trickier, you'll have to download special Nightly version for testing. Then search for `jxl` in the search bar, switch `image.jxl.enabled` to `true` and restart the browser.

https://jpegxl.io/ Heyo, finally just released a beta. 🙂 Peace!

Thanks!

No option for lossless encoding?

q100 should be lossless

Currently it's q100, but I could include a checkbox to tick if that's more convenient? Or just call it "lossless" instead of "100%".

So no vardct encoding?

No jpeg recompression mode?

Not yet! It wasn't bug-free. The converter crashed occasionally. I'm expecting this to be solved in the next weeks.

Eh.. fuck it. It's a beta for a reason. 😛 It's implemented now. Modular Mode + JPEG Recompression. You may have to ctrl+f5 to clear cache. Keep in mind it may crash, and if it does, let me know!

Ha ha . I was just asking. Not going to use it btw.

All cool, I guess it might be helpful for debugging. 🙂

wild style. looks really good

Does jpeg suffers generation loss even if always saved at 100 quality?

That will converge to a fixedpoint quickly, I think

In jpeg, most generation loss comes from cbcr up/downsampling and from dct coeff requantization

At q100, assuming 444, the dct quant table is all 1s so the only loss is from the color transform and dct itself, but that should be minor and not cumulate easily

(dct coeffs are 12-bit in jpeg, which is not enough to be reversible, but it's quite accurate; rgb to ycbcr is lossy but I think ycbcr to rgb to ycbcr is lossless or close enough)

If someone picked *exactly* the same lossy encoding settings (incl. quant tables), would generation loss be as small as at q100?

In 444 JPEG, maybe

In codecs that do more fancy stuff, no

Hi Guys. What is the status of jxl implementation in the browsers? Any good news or will politics win?

I expect something to maybe start seriously happening in 2022 once IS gets published, and non-browser software support will be improved by then, and libjxl will be more bug-free aswell

perhaps IS publication will be the trigger to re-evaluate situation of "ecosystem acceptance" of format

just proceed as if it'll be fine, don't let bitter thoughts get you

That is a good advice 🙂

just start using it everywhere and make more people complain that their browsers dont support it

now all the people around me have it enabled in their browsers

AVIF support is kinda a good thing but honestly it's way too problematic in the ways it works to be serious contender

though.. honestly I still don't really think that's it's even a good thing, it's got pretty bad decoding speed and for encoding its even worse

maybe for browser vendors it kinda made sense because codebase increase wasn't big but idk idk

please update to a supported browser <:kekw:808717074305122316>

should have banner which uses picture element to either show "compatible with jxl" or "please update to supported browser"

would b sorta funny

kinda "best viewed in IE9" style

Pressing the thumbs up on mozilla's request for standards position and starring the chrome bug are the ways to show interest right now

here support the request by thumbs up: https://github.com/mozilla/standards-positions/issues/522

here by starring: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058

That sad moment when for some reason using photon noise increases the file size from 285KB (no photon noise) to 474KB (with photon noise) <:Cheems:884736660707901470>

Wonder if that's a bug, because it happens with e9, but not e7 (e7 both were 299KB)

Hm, I hope e9 is not trying to counteract the noise or something like that

``cjxl -e 9 -q 90 test.png "e9 NoNoise.jxl"``

``cjxl -e 9 -q 90 --photon_noise=ISO1500 test.png "e9 Noise.jxl"``

Not really sure what happened, but it looks noticeably different from e7 with noise

``cjxl -e 9 -q 90 test.png "e7 NoNoise.jxl"``

cjxl -e 7 -q 90 --photon_noise=ISO1500 test.png "e9 Noise.jxl"

At least e7 works in this case

looks like -e9 will be trying to ramp up adaptive quantization to reduce the effects of the noise

this is not an effective strategy in -e9

Does photon noise look good if I print photos? I'm going to print them @ 600dpi.

noise + `-e 8` or `-e 9` is generally not a good idea 😉

That's an artistic question and matter of personal taste, I'd say

TRY https://artifacts.lucaversari.it/libjxl/libjxl/2021-10-20T15%3A49%3A34Z_f4eb5cb216e9005729a71748b94a3f5a8f3f5f1e/

with for %i in (C:\Users\Utente\Pictures\o\*.png) do cjxloctober12 -d 0.597 -s 9 --use_new_heuristics --faster_decoding=6 -I 0.59 %i %i.jxl

it will compress very well

where there is black and pink it will retain all the noise

Doesn't faster decoding make the quality worse though?

yes

and also if you change the i to another value you'll get banding

also new heuristics has problem of banding

for example where there are phones in a image

where there are small object

so is unusable for person like lee

that cares only about it

Wonder if there's a parameter list somewhere with an explanation of all cjxl parameters. It should make things easier for people who haven't compared many images with different parameters

though it compress same or better

that new heuristics with d1 s 7

i got 498 kb png to 39 kb

is still experimental but for the speed you can't do better

i don't know if it can be used for animation

but jyrki said there is much to improve for animation

patches 0 don't work

To be honest, speed doesn't really matter for me. Only care about static images and max. efficiency which is why I usually use -e 9 (usually lossless)

sign that maybe new heuristics may be disabling patches generation

or just you can use only patches 1

don't know how it works

No idea what all those things do tbh

Wonder if someday we'll get something like this for jxl: https://www.reddit.com/r/AV1/comments/lfheh9/encoder_tuning_part_2_making_aomencav1libaomav1/

if you have for example a raw from Photon camera github and three exposure

and you want to share a near lossless file that has same artifacts.

like today digital broadcast changed in italy on some channels

;an user on discord/av1 tried 2 kb placeholder comparison

the old parameter i think that was MATHEMATICALLY efficient was

-q 47.74 -s 7 -I 0.6 --use_new_heuristics --patches=0 https://artifacts.lucaversari.it/libjxl/libjxl/2021-10-18T21%3A45%3A05Z_a2cba9fe1828bfa3782df090ec8407c9a96aea88/

the build is different it doesn't have the new ac deadzone quantization commit

av1 is becoming better like if you try tomorrow it will be 16% more efficient than h264

like an av1 8 bit cpu 6 is 16% more efficient of h264 if it was in 10 bit

22102021 version

Shouldn't it be like... way more efficient than just 16% <:KekDog:884736660376535040>

that's because h264 isn't 10 bit

h264 hasn't 10 bit

av1 in 8 bit i think it should look similar

don't know there aren't honest comparisons

they just say vvc is better

I hope we won't have to do that (because smart encoder will hopefully do it in its own).

There is no need really.

For photographic images, cjxl is already very strong and fast for photographic images, and is tuned quite well. aomenc with AVIF by default currently doesn't have that, and I really think they should change that.

Would still be kinda nice to at least know what certain parameters to to be honest

Like, in the past I saw discussions whether to use or not use new heuristics

Fabian will tune jxl encoder. Don't worry 😊

<a:DogeScared:821038589201612820>

The philosophy in libjxl is that default settings are the best (general-purpose) settings, and options hidden behind cjxl -v (-v) -h are intended for experimentation. For a specific image, of course specific custom settings might always work better, but defaults should be the most sensible thing to do in general.

The only thing I'd personally modify would be: `--intensity_target=XXX` depending on your display's brightness.

Didn't even know that's a thing

--intensity_target=XXX should ideally depend on viewers display, but the parameter is needed at compression time

sometimes the encoding happens on a displayless server

if one creates a new gimp painting, it might be a good idea to set intensity target automatically to the displays current max intensity

I doubt there's a way to know what that is

Also there might be multiple displays

yes, the only feasible approach is to have intensity target to be related to intent in psychovisual response

and leave it up to the receiver to get as close as possible to that psychovisual response with whatever device is attempting to show the image

https://gitlab.com/wg1/jpeg-xl/-/blob/main/tools/cjxl.cc + CTRL +F = "AddOption"

Often, there's 2 lines of description to the parameter/option. But yes, many points lack a good description tbh. At least for people not that deep inside the topic

Hm, at least it helps a little, thanks

Hi there - I'm planning to create jpeg-xl versions of images on my website. I just want to confirm that, as JPEG-XL can be progressively downloaded, I only need to create a single version on the image at the maximum resolution I'll need. Browsers *should* be able to download just enough of the image to render at any target size. So - if I display the full image, the full Jpeg-xl will be downloaded - but for thumbnails, the browser should just download some of the image, or use the cached version. Is that correct?

I don't think there's any or will be any implementation which actively gets *enough* data for a specific resolution

and as for the actual resolutions, there's a fixed number of progressive steps

i think thumbnails in browsers would have to be something in the fundamentals of web standards

something like designating an img tag as a thumbnail

interesting idea though

maybe that can be done by baking in the decoder into your website

It doesn't bother me if the downloaded resolution isn't an exact match for the exact page resolution. But I was hoping that a img with size 100x100 could just download up-to the closest progressive step to render completely ( including the x1.5 x2 x3 versions ). I wanted to avoid storing and serving multiple resolutions of the same file.

That's intended utility designed into the codec, but AFAIK there's no standard mechanism for that behavior in web browsers.

hmm unless you find out the minimum data to get for example the 64x64 dc and only send that much from the server

I thought i'd be implemented with the browser requesting byte-ranges - but maybe the round-trip time slows it down too much to bother.

it definitely wouldnt be something that browsers would implement

Bummer. So I still need to generate multiple resolutions. Thanks for the help!

I was thinking maybe the server can have a parameter for the range/size and then only deliver that much

i will experiment with this

something like this https://test.grass.moe/jxl/https://raw.githubusercontent.com/libjxl/conformance/master/testcases/bike/input.jxl?only=104167

The jxl bitstream does have features for this, but it would require significant browser changes and maybe some changes in the html and/or http specs to actually make it work. It's a pretty hard thing to do.

Range requests are already something that exists in http, a browser can ask for bytes X to X+N and servers and CDNs should already understand that.

Iirc, chrome uses that for images marked with `lazyload`: it fetches only the first 2kb for such images, which should be enough to get the image header to know the dimensions for layout. It fetches the rest only when you scroll close enough to the image.

It is an unknown if the single-file approach is going to be effective for visual quality -- my hunch is that VarDCT designed for appropriate quality is going to be more effective in the end

It is an unknown if many levels of progression visualized is a good idea in general, or to rather limit the progression to an early (10-15 %) version and then the perceived final version (~50-60 %), or something else

same. question is whether storage cost savings will offset the cost of a bit lesser visual quality. one could also use one progressive step up but that'll shift cost to bandwidth

i believe at first one should experiment with something like ?only= param, and later that could easily be shifted to CDNs (eg u request ?only= when querying CDN, and CDN translates that to byte range request)

this would increase caching efficiency for CDNs. for browsers, that could come later, if efficiency gains are proved to be worth it

btw, how does jxl's jpg mode mix with progression?

as in, does original jpg need to be progressive to allow for jxl progression?

No

The jxl can use any progression, and the original jpeg can use any progression - the coefficients are what matter for the reconstruction, and the `jbrd` will have the original jpeg progression order

handy

oh right jpegtran can do that for jpegs too

shouldve expected it to b supported i guess

is there any tool to print current available progression steps of .jxl?

in bytes

and resolutions

or fractions

something one could use to prepare relevant srcset

https://cdn.discordapp.com/attachments/869655213315878983/902665260656394300/done.jxl <@!321486891079696385> i found some pretty good jxl test material

<@!416586441058025472> what u think?

<@!794205442175402004>what exactly does ``-I`` do? Tried it on a few images and it made lossless slightly smaller (-I 5 had the biggest impact on the few test images)

Oh lol, now I have an image where ``1`` was smaller than ``5`` <:KekDog:884736660376535040>

this you need an high effort use q 80.87 -i 0.89 -s 9 --gaborish 0 dots 0 and a newer build than the one i tried yesterday

you can experiment with gaborish 1 though i would use gaborish 0

it depends how the build look

also don't forget to test also fr screenshots

Strange... -I should be clamped to 1

It's the fraction of samples it looks at for doing MA tree training

Default is 0.5

You can't look at more than all the samples

Hm, I went from 0 to 9 and the sizes varied

0 was noticeably bigger and 1 - 9 were similar with 5 the smallest in most cases

``cjxl -e 9 -q 100 -I <X> -E 3 -g 3``

And nice, about 2% smaller than ``-e 9 -q 100`` <:Poggers:805392625934663710>

<@179701849576833024> any idea what causes that? I assumed I > 1 would just do exactly the same as I == 1

Oh wait, I misread some stuff

Still different results, but -I 1 is the smallest

~~I should stop reading stuff when I'm barely awake~~

ahhh possibly because 0.1*I is used for property quantization

(as in, 0.1*I fraction of the samples)

Hm, 2.700 bytes

2.703 bytes

Guess this time -I 5 is actually smaller :p

Hm, ``I 10``+ gives the same results, so guess that can be the case

I didn't even know it let you do above 1 🤔

Same, but got bored and decided to use random values

Is there a way to ask skcms developers to make a release or tag? Many Linux distros don't like bundled dependencies and they wish skcms as individual package/system dependency. It will help also for libjxl to get into distros more easily. Many maintainers refuse to run deps.sh, they wish things to be done in harmony with their distro policy standards.

for distros, lcms2 is an alternative

I think sjpeg and LodePNG have a similar problem. sjpeg can be disabled with `-DJPEGXL_ENABLE_SJPEG=0` but for LodePNG there is no way to disable that or to use an alternative dependency.

But perhaps that is not a problem since LodePNG is a header-only library (IIRC, Fedora does not have this release/tag requirement for header-only libs).

for that matter skcms is pretty close to lodepng in terms of structure (basically 1 file)

maybe just bake tarballs with submodules pre-downloaded on releases

Might make sense to do that

```dssim data/\[r16\]raptor_v2_5_clean\|0\|.png 79.919984.png -79.919984 79.919984.png``` Is that good or bad?

Uh, negative dssim? Looks like bug :)

Looks like unintended usage to me. A succinct "What's wrong with you?" should suffice for output in such cases.

Finally managed to get hold of the standards through my University library.

Fine, I'll do it myself.

huh

you can do that?

can't you get the FDIS of part 1 and the IS of part 2?

Not as far as I could tell. My Uni doesn't subscribe to the ISO, but it does to the British Standards Institute, which has this copy.

ah so there might be some lag

makes sense

FDIS of part 1 isn't approved yet, so they will not sell it yet

IS of part 2 was published two weeks ago or so, so obviously it will take time until the ISO certified carrier pigeons have transmitted its contents using their special Morse code wing flapping technique.

the ww bot don't work more

guess he disabled the server

it was only a test

don't know if he will readd final version

and how much storage he has, he didn't go into detail

the bot turns on and off on its own based on the activity

just run the command again

and it doesn't use any storage

I did go into detail on how it is hosted

actually that's wrong, it's just that image

Was the image becoming larger than 8 MB, and thus not able to be uploaded? I just encoded it with `cjxl -d 2 in.jpg out.jxl`

it's not uploading that is the issue

transmitted over IPoAC?

https://embed.moe/https://cdn.discordapp.com/attachments/794206087879852106/904768652149157948/jxl_standards.jxl

problem was lodepng

https://pagepipe.com/dont-use-webp-image-format/ spotted this from HN. uh-oh.

While reading it, I thought it was a very old article, but... > November 2021

The article is not telling the truth. For example: "If you upload a webP file to Facebook you’ll get an error message." Few hours ago one of my family members uploaded a webp image to Facebook and it worked. And it worked also several month before.

i think the date is fake

like for instance it says that safari completely lacks webp support

my screenshot

they’re also anti-https https://pagepipe.com/httpsssl-and-its-negative-impact-on-mobile-speed/

probably not a site worth reading

their screenshot

ah the date on the screenshot says June 2020

so <:monkaMega:809252622900789269>

they recommend using mozjpeg over webp which isn't really terrible advice compared to recommending another jpeg encoder

¯\_(ツ)_/¯

Yep, some thoughts are not so wrong, but many other reasons not to use WebP are very strange, like > Photoshop doesn’t natively support WebP, but you can add a plugin to add WebP support. That’s a clue. Adobe thinks it’s lame or > That saves 3.1k. In big letters, they tell us that is a 32-percent savings. > Is that significant? No. > Is it worth bothering with? No. > Why? > Images load in parallel. All at the same time. Boom! like that 32% saving is nothing because images are loaded in parallel, assuming that only formats other than WebP can be loaded in parallel

their arguments are terrible, though, so to me it doesn’t matter much whether they accidentally happen to be right

they would be right for the wrong reasons

well there are official adobe instructions that specifically tell you how to install the webp plugin which counteracts that point

and afaik lossless webp isn't related to vp8 at all?

their anti http sentiment seems to be more of an anti lets encrypt sentiment at points which is not a terribly unpopular opinion afaik

correct, it’s a separate codec

Lossless webp is almost a perfect improvement over png

(if not for the limitation to 8-bit and image dimensions that it inherits from the lossy webp design decisions)

Lossy webp was a quick hack to make an image format with low browser binary size overhead (if it has a vp8 decoder already) and with better-than-no deblocking so it can be somewhat better than jpeg at the low fidelity operating points that are loved by devops people who want to save on bandwidth and improve web perf without caring much about image quality.

lol wtf, their latency complaint is valid but that's what HTTP/3 is trying to solve and arguably such a penalty is worth it for security

> HTTPS can’t be cached. [citation needed]

lol even _that page_ is served over cached https

> You can get an SSL certificate for free. Blog posts debate the value of a free SSL Certificate. But, the costs can shoot up to $1,499 per year if you opt for an SSL certificate from a provider like Symantec. You don’t have to provide corporate documentation to get SSL Certification. The authorization may be a simple email. Confirm the email inquiry, and you’re accepted as the authorized domain holder. Can free TLS certificates provided by Let’s Encrypt still be hacked? Absolutely. Anyone can get an SSL certificate – including hackers. They can set up a site to harvest information. good technology is available to bad actors, the horror <:NotLikeThis:805132742819053610>

> Labeling a site as *secure* because it has SSL is wrong. In error, users think they’re using a secure site when in reality it’s not better than before. this is a good point

Chrome already tells you instead that the *connection* is secure, not the page itself.

validating site security is impossible anyway, if you have high enough standards for what validation means

I informed colleagues from my company about JPEG XL existence. I showed them 32bytes JXL art images + info how they can be viewed in Google Chrome. Few of the colleagues replied they were impressed and one wrote me that he made thesis about fractal compression of images.

Fractal compression, I remember that

🤔 > With JPEG XL image encoding performance using the de facto libjxl library, here was an example of Alder Lake performing very poorly and stemming from finding itself running on the E cores rather than performance P cores. With limited deviation between runs, this behavior was reliably happening. https://www.phoronix.com/scan.php?page=article&item=intel-12600k-12900k&num=4

yeah it says that the linux scheduler needs some work

sounds like we should turn off topology detection 😛

JXL, even without PDF features, can also be relatively useful in this use case 🤔 https://news.ycombinator.com/item?id=29124994

Any changes since that time?

it is a know issue that cjxl crashes with some pictures?

mine choked and died trying to encode manga

was it a jpeg?

yes

i think i found the reason tho

something with the metadata

which i stripped

and its working as far as im testing

but its weird

because some pages work and some dont

and i guess any original jpg encode was in a batch with similar settings and subsequent metadata

there have been a couple issues on github about some grayscale images failing too <https://github.com/libjxl/libjxl/issues/764> <https://github.com/libjxl/libjxl/issues/720>

the metadata thing was also mentioned in an issue before 🤔

i know nothing of tecnicals of codecs but its like theres some sort of tags ppl put on greyscale pics that trips cjxl

but not all my greyscale pictures tripped it up tho

maybe those didnt had it for some reason

Metadata is the biggest problem with transcoding JPEGs.

lol really?

Yeah, it's been a small thorn for months.

"We" have fixed most of the issues, but some are still present.

thats funny, i would have expected that was the littlest of concerns

after 27000 pages i only ran into 1 bad jpg which was because it was cmyk

I losslessly transcoded about 150k jpg files and had no problems, but I cleared the metadata with `jpegtran` before that. 😛

One of the latest issues on metadata https://github.com/libjxl/libjxl/issues/803

Try building cjxl with ./ci.sh opt

That way you get more informative error messages

https://security.googleblog.com/2021/11/clusterfuzzlite-continuous-fuzzing-for.html

hello

i would like to add libjxl to our toolkit

so i'm playing with the API

i've looked at the jxlinfo.c example and i have a question about the infinite loop

afaiu, the infinite loop is to load more image data to get basic info (because fread() is used)

but if i have the whole file which is already mmap'ed in memory, there is no infinite loop to do, right ?

i think that calling successsively some API calls is enough

hmm, maybe not the correct chan

I believe you are correct

if it is unclear from the API docs, consider filing an issue against it

https://arxiv.org/abs/2111.09219

> The JPEG compression format has been the standard for lossy image compression for over multiple decades, offering high compression rates at minor perceptual loss in image quality. For GPU-accelerated computer vision and deep learning tasks, such as the training of image classification models, efficient JPEG decoding is essential due to limitations in memory bandwidth. As many decoder implementations are CPU-based, decoded image data has to be transferred to accelerators like GPUs via interconnects such as PCI-E, implying decreased throughput rates. JPEG decoding therefore represents a considerable bottleneck in these pipelines. In contrast, efficiency could be vastly increased by utilizing a GPU-accelerated decoder. In this case, only compressed data needs to be transferred, as decoding will be handled by the accelerators. In order to design such a GPU-based decoder, the respective algorithms must be parallelized on a fine-grained level. However, parallel decoding of individual JPEG files represents a complex task. In this paper, we present an efficient method for JPEG image decompression on GPUs, which implements an important subset of the JPEG standard. The proposed algorithm evaluates codeword locations at arbitrary positions in the bitstream, thereby enabling parallel decompression of independent chunks. Our performance evaluation shows that on an A100 (V100) GPU our implementation can outperform the state-of-the-art implementations libjpeg-turbo (CPU) and nvJPEG (GPU) by a factor of up to 51 (34) and 8.0 (5.7). Furthermore, it achieves a speedup of up to 3.4 over nvJPEG accelerated with the dedicated hardware JPEG decoder on an A100.

https://github.com/weissenberger/multians

good times for compression!

brunsli still better

Define 'better'

Brunsli is sometimes slightly denser, in particular for 420 jpegs, but it has some disadvantages: - no parallel decode - no progressive decode - not always denser - always have to convert back to jpeg to see the image (unlikely that anything will natively display brunsli) - cannot do things like adding an alpha channel or an overlay to a jpeg, which is in principle possible with jxl (though no tool implements it atm)

Also jxl should decode slightly faster (even in the single-core case), and the jxl jpeg recompression still has some (small) margin for encoder improvements, while in brunsli I don't think there are many degrees of freedom left to optimize in the encoder

Also jxl has the option to apply gaborish/epf/noise to improve the appearance of a recompressed jpeg

So in my opinion, TL;DR: no.

look like some non-photo website and CDN start use webp lossy...😢 It's really sad, even medium quality 444 jpeg lossy still better than webp 420, use 420 on still image always a bad idea... For now avif lossy is strong on medium quality, but I think we still need a high quality lossy and high fidelity still image encoder for non-photo content, I understand lossless is better for non-photo content, but I guess for web use high quality lossy also a important choose.

Anyone with an AUR account? I can't flag FLIF package as out-of-date... https://aur.archlinux.org/packages/flif

I flagging out of date really important?

For that package?

Ok. I flagged it.

Thanks! 🙂

It looks like it is the same issue.

anything I can do to move along https://github.com/libjxl/libjxl/pull/864 and https://github.com/libjxl/libjxl/pull/855 ?

been working on https://github.com/WebKitForWindows/WebKitRequirements/pull/70 which would add libjxl for the Windows port of WebKit

<@!794205442175402004> ☝️ anything i can do to get those landed?

uh

have a few other patches around building `libjxl` using `vcpkg` which is how we build out our requirements for WebKit on Windows

i'm not very good at building/portability stuff so I'm a bit hesitant to just go ahead and merge them myself

we recently landed support of JPEG XL for non Apple ports in WebKit

is there anyone in particular whod be good to involve?

<@!604964375924834314> maybe?

maybe not right now but I would be happy to have a look tomorrow

thatd be great i have a few more patches around `find_package` which would do more than just a pkgconfig search for a library since that's typically not around on Windows

Could someone can teach me how to create a debug(half) decode image for jxl separate option image file?

ok, I found that. 🙂 > https://github.com/libjxl/libjxl/pull/466

It's very interesting for those decode image.

I guess separate option not create patch for some manga case, but still better than pure DCT.

I think for some manga case, jxl separate option can avoid DCT worst case, but for now, av1 palette prediction(lossy) compression rate still better, jxl separate option also use something like palette method for non-DCT area?

yes, it can use any modular transform, including palette

there's room for improvement not just for manga but in general when there are hard edges with more or less smooth surfaces on both sides. Selectively using modular in those regions and vardct in the other regions could help a lot; I'll probably try to investigate how to make a good detection for that somewhere in the first half of 2022...

wdyt about adding this server there? https://github.com/discord/discord-open-source

Huh. It needs 1000 members :(

Or 1000 GitHub stars.

Oh. I forgot to star libjxl 🤣

https://github.com/NVIDIAGameWorks/NVIDIAImageScaling/releases/tag/v1.0.0

Isn't this just a green ripoff of FFX CAS & FSR? 😄

you cant just say ripoff

Interesting, piexl art png and jxl separate option, Those debug decode image give me transparent png. > cjxl -d 0.5 -e 8 --separate=1 --epf=3 --num_threads=12 > djxl --bits_per_sample=16 --num_threads=12 -s 8

sample

I expect whole image will use modular encoding, but look like in this case some part use vardct.

original

Build with -s? 🤔🤔🤔

I usually use djxl, and some djxl -s information from jon PR. > https://github.com/libjxl/libjxl/pull/466 > Here is an example of an image decoded with djxl -s 8 so you can > see the nonphoto parts sharply (since they are encoded first, as a patch) > and the photo parts blurred (since you see the upsampled DC): > > -s 1,2,4,8,16, --downsampling=1,2,4,8,16 > maximum permissible downsampling factor (values greater than 16 will return the LQIP if available)

Could someone add kimageformats to jpegxl.info?

It's going to support jxl now 😌😌😌

Done https://github.com/jxl-community/jxl-community.github.io/pull/2

This could be a list with some major apps such as mainstream browsers and Qt, WIC, and then the details disclosure element with others. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details

What is this?

Maui gallery app. Works on Android too

Ping me when it gets released.

I'll do a post on r/JPEG-XL, and r/android.

Upload a interesting manga sample, use vardct and jxl separate option. > cjxl -d 1.0 -e 8 --separate=1 --epf=3 --num_threads=12 > djxl --num_threads=12 -s 8

Can jxl thumbnail plugins in linux and windows decode large images >20 mp quickly in low resolution for thumbnails?

theoretically, yes, at least for VarDCT and lossy/progressive Modular

but libjxl doesn't really have a good mechanism for it yet - you could stop decoding at the first progression event, and take the image you get from that, but that'll unnecessarily upsample the 1:8 image to 1:1 only for the thumbnailer to downsample it again

I have some question about jxl separate option, theoretically if we have strong heuristic to separate photo and non-photo block, this process can reduce sharp edge and line error(tiny artifacts) and avoid DCT-worst case for pure non-photo content? (not like av1 use heavy filter on quantization process) I read some av1 encoder filter discuss from av1 sever, I think for still image use less filter probably a better choose on quantization process?

Yes, no problem in fact 😄

I plan write some simple tech detail for introduce(chinese) jxl high quality lossy advantage, I think I can write jxl separate option in my article? > example: > For high quality lossy non-photo content, if you use avif, > your image probably lost some subtle grain, detail, and avif use ycbcr colorspace, > probably have some color error on your image. > > Just wait a few months, you can get better lossy quality on jxl format for non-photo content, > jxl have some more advanced featrue(separate), can separate photo and non-photo block, > reduce quantization error, and work better on preserve grain, detail, > and jxl have a new colorspace XYB, this colorspace is better than ycbcr on preserve colors.

it will probably be a somewhat different approach - not really separating the image into two parts, but generalizing patches and dot detection into something that doesn't just try to detect text (repeated letters) and small ellipses (dot detection), but more generally image features that are better not DCT-encoded.

I understand, I will rewrite this part, If people ask me about jxl separate option implement state, I guess I can reply like this? > This features probably will implement on after February 2022.

yes, maybe i'll start working on it in January/February, I dunno how long it will take

https://developer.nvidia.com/blog/rendering-in-real-time-with-spatiotemporal-blue-noise-textures-part-1/

how is nvidias version better 🤔

https://github.com/NVIDIAGameWorks/SpatiotemporalBlueNoiseSDK/blob/main/LICENSE.docx

<:kekw:808717074305122316>

LICENSE.docx

https://developer-blogs.nvidia.com/wp-content/uploads/2021/12/Stochastic-transparency.png

with this test image the nvidia version does seem more pleasing though

An efficient lossy cartoon image compression method 🤔 > https://link.springer.com/article/10.1007/s11042-019-08126-7

Is there any encoder for this?

I not sure, I guess they don't have encoder implement for this compression method?

Hello, I have some question for bit depth and transform precision, Could somebody can teach me about this? For webp,jpeg, lossy already DCT content, I need output 16 bit depth png to make sure transform precision, For bmp(24,32 bit depth),webp lossless(8 bit depth), lossless and no DCT, I also need output 16 bit depth png? If I want use denoise filter on png(8 bit depth), I also need output 16 bit depth png? (work on ffmpeg and imagemagick) And I notice ImageMagick have Q16(16 bits-per-pixel component) precision calculations version, I think if when I use ffmpeg denoise filter, I need specify 16bit on ffmpeg? > https://stackoverflow.com/questions/48937738/imagemagick-what-does-q8-vs-q16-actually-mean

I tried my best to answer. > For webp,jpeg, lossy already DCT content, > I need output 16 bit depth png to make sure transform precision, Yes, it's recommended to avoid additional banding 🚫 <:banding:804346788982030337>, both for input and output. > For bmp(24,32 bit depth),webp lossless(8 bit depth), lossless and no DCT, > I also need output 16 bit depth png? 24 (RGB) and 32 (RGBA) bits in BMP are for **all** channels, so it's 8 bits per channel. If you're decoding from BMP, lossless WebP or lossless <:JXL:805850130203934781> and you know there are only 8 bits, you don't need to force decoding to 16 bits. But for encoding? It depends. If you're generating a PNG file yourself (for example from a graphics program), you can export to 16 bits for better quality if you will next encode to lossless <:JXL:805850130203934781> (BMP and WebP don't support 16 bits per channel). But if you found a PNG file on the internet and it doesn't have more than 8 bits, then you can't do anything with that, encode without changes. > If I want use denoise filter on png(8 bit depth), I also need output 16 bit depth png? > (work on ffmpeg and imagemagick) Probably yes, to avoid banding artifacts in your denoised PNG file and you want to encode to a better image format (like <:JXL:805850130203934781> 😉), but that's unnecessary if you want to share them on the internet in original quality, because 16 bit PNGs are *huge* and might cause problems. > And I notice ImageMagick have Q16(16 bits-per-pixel component) precision calculations version, > I think if when I use ffmpeg denoise filter, I need specify 16bit on ffmpeg? I'm not using IM or ffmpeg for 16 bit PNGs, but you probably can specify 16 bit output, to be sure. But *please* check them afterwards with TweakPNG, if you're on Windows!

I understand, Thank you very much for your help 🙂 I try to transform my all image(bmp,png,jpg,webp) to jxl, so I try to figure out this part.

<@!794205442175402004> is my message above correct or did I make a mistake?

looks ok

Thanks! 🙂

<@!794205442175402004> sorry for ping, I write a simple guideline, Could you check my guideline is correct and didn't make any mistake? To avoid banding, artifacts and make sure transform precision some transform need use 16 bit depth png to reduce precision loss. ## Necessary output 16 bit depth png * Color space transform(YUV to RGB, jpg,webp lossy decode). * Inverse discrete cosine transform(IDCT to pixel, jpg,webp lossy decode). * Pixel edit(Internal 16 bit depth, denoise,crop,resize). ## Unnecessary output 16 bit depth png * Decode 8 bit depth lossless image format to pixel(RGB to RGB), include png(8 bit depth), webp lossless(8 bit depth), bmp lossless(8 bit depth). ## Reduce bit depth If need reduce bit depth(16 to 8), must use 4x4 ordered dither.

sounds ok, of course there's always a trade-off between speed/memory and precision

I understand, Thank you very much 🙂

Cropping doesn't "edit pixels" so you can keep the original bit depth. Also, does WebP really use DCTs?

lossy webp does, lossless doesn't

Hello Matt Gore Could you teach me, which convert method need output 16 bit depth png in imagemagick or ffmpeg? and which convert method can keep original bit depth. I read your dither method comment on jxl issue, about imagemagick ordered-dither o4x4,<value> , could you teach me, I should set which value to reach high quality dither? > magick convert -depth 8 -ordered-dither o4x4,256 input.png output.png > https://gitlab.com/wg1/jpeg-xl/-/issues/136 > https://github.com/libjxl/libjxl/issues/541

I think IM matches the output depth to the input depth, even if internally it operates at a higher bit depth

But you can override it with `+depth` which resets it to the IM internal value, or using one of the PNG format modifiers, e.g. `PNG48:output.png` will output a 16bit RGB PNG

If in doubt, just dither. If you crop at 16 Bit and apply dither, then it should just round back to the initial values across areas of solid color. So no harm done by always dithering.

you mean by dithering to 16 bits?

I mean dithering at 16 Bits.

or what do you mean with dithering to sth.

the same thing as you do, I think

dithering with an amount of noise that is appropriate for quantization to 16 bits

ok, I meant doing `-ordered-dither o4x4,256` at 16 Bits.

ah, I am not very familiar with `-ordered-dither` but it looks potentially like more dither noise than that

apparently not

Sorry I still have some question about bit depth and dither, Could somebody can teach me? 1. Why imagemagick ```-ordered-dither o4x4,256``` use level 256? What's this level value mean? > -ordered-dither threshold_map{,level...} > Dither the image using a pre-defined ordered dither threshold map specified, > and a uniform color map with the given number of levels per color channel. 2. apply dither process always a lossless process? so it's mean if I apply dither twice, still don't worry have any loss? and I see Matt Gore mention error diffusion, If I mind quality use error diffusion will better than ordered dither? 3. imagemagick have (16 bit depth)Q16 version, but I can't find too much bit depth detail for ffmpeg, only find some comment say ffmpeg will use input bit depth, I should worry ffmpeg transform precision for still image? 4. Input image(original 8 bit depth) to imagemagick convert(internal 16 bit depth), I should use -ordered-dither o4x4,256 and back to 8 bit depth for output image?, or I should use 16 bit depth png for output image? what's best practices? (I understand for original 16 bit depth image, always need use 16 bit depth)

1. A level of 256 means 256 values per channel which is exacly how many there are in 8 Bit images. 2. I guess you should reach a fixpoint with ordered dithering. Error diffusion is probably overkill for 8 Bit SDR but it might be easy to use with ffmpeg. 3. Just try it with a smooth gradient and see what happens. 4. I would store whatever is smaller (and that depends on the image content).

I understand, Matt Gore, The_Decryptor Thank you very much 🙂 I will test ffmpeg later.

Is fast jxl fast enough to do screen cast? Lossless 1080p, 8bit @60fps with minimal latency

that's about 120MP/s so yes

... on one core

but the decoder is not fast enough xD

It's going to be a heavy stream though, and decode will atm require lots of cores :)

Doing cropped frames should make both encode and decode cheaper though

Assuming your screen is not something like a 3d game where the whole screen changes (but then you should really use an actual video codec with motion compensation)

Ah. I was thinking about streaming / screen casting 3d games from handheld console like steam deck to TV :(

Then just use a video codec. Lossless <:JXL:805850130203934781> would be helpful only with windows that can be effectively coded as patches and then applied to every frame at different positions to recreate their original movement across the screen.

Yes, this would be a very bad use case, it would be easier to stream in any common lossy video format, especially those that support hardware encoding/decoding, when using a high enough bitrate - artifacts and losses will be unnoticeable to the eye and the bitrate will still be noticeably lower than in lossless encoding

fjxl might be a good output codec for dosbox video recording

currently, they use: https://wiki.multimedia.cx/index.php/DosBox_Capture_Codec

Could be a fun project to convert that to jxl

I suppose we can use kAdd instead of xor, not quite the same thing but probably close enough

https://discord.com/channels/794206087879852103/803645746661425173/923688644307460117 <@!794205442175402004> nice to see some live brainstorming :D

Is possible to make jxl vardct or lossy modular faster for screen casting with lower latency than video formats?

That's not what it is designed for