JPEG XL

That is weird

What colorspace is your display? Is color management maybe doing its own dithering?

(what OS and viewer are you using?)

Windows 10 - set on sRGB. I used ImageGlass.

I tried in IrfanView with same result but moving the image at 100% caused the banding to "jiggle"

Same result in Windows Photo.

`cxl IMG_20210505_091937_1-sharpened_cmpk_cmpk.jpg cmpk.jxl -d 0.5 -s 8 J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: AVX2,SSE4,Scalar] Read 3456x4608 image, 7.1 MP/s Encoding [Container | VarDCT, d0.500, kitten | 402-byte Exif], 2 threads. /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/bits/atomic_base.h:217: void std::atomic_flag::clear(std::memory_order): Assertion '__b != memory_order_acq_rel' failed. [1] 34292 abort (core dumped) cjxl IMG_20210505_091937_1-sharpened_cmpk_cmpk.jpg cmpk.jxl -d 0.5 -s 8`

Is it failing because of ram shortage?

Nah it's likely that bug that will be fixed at next sync

it works fine with -s7 thou

send me your resume: jyrki@google.com and I will put it into our system -- currently our team is not expanding, we are still learning to scale up structure, roles, clarity and happiness with our current size, but there are always exceptions for compelling cases

Yes, that bug is in the butteraugli-iteration codepath which is only activated at -s 8/9

Here is the original in case you want to try different JXL/JPEG variants.

Oh, that's what you meant. Anyway, it wouldn't happen with dithered resampling.

thanks! although I think that the jpeg you attached to the bug makes for a compelling case already 😄

That one has no banding

I wasn't talking about me. ^^ I was hoping Google could send over some more devs to the libjxl team. 😄

What display are you using?

that'd be a bit problematic right now from what I understand of things

You're not the first one to come up with this idea 😉 https://discord.com/channels/794206087879852103/803663417881395200/830745493368733697 It would be awesome if it happened...

You mean monitor?

Yes. I would guess it cannot fully recreate full 8-bits per channel.

It's a laptop, rather new. No idea what the screen on it is. It is also connected to an ASUS ML238.

New screens are often P3

But only the expensive ones. 😄

Even one that can do 100% of sRGB is not so cheap

The marketing claimed it can do 100% sRGB. Don't know if that's true.

I have a BenQ here that can do most of P3 / Adobe RGB 98 and 100% of sRGB

my laptop can apparently do 132% of sRGB

whatever that means

Irradiated <:kekw:808717074305122316>

means it can do some wider gamut than sRGB

viewing the gradients on the BenQ with brightness cranked up now

It means you should make sure to clamp the gamut when watching sRGB content. ^^

the blue one without dithering has really obvious banding

with dithering the obvious banding is gone. I can still see some banding in the top right quadrant of the image, and a little bit in the bottom left.

in the gray one I still see some banding in both, but it is a lot worse without dithering

in the one without dithering, the bands are clear also when I look closely

in the one with dithering I cannot really see the bands when I look closely, but when I look from a distance then I do see some banding

the difference in banding can even be seen when I make a photo of the screen with my crappy phone camera

(funny how its white balancing is desaturating that blue a lot)

when I zoom in with Preview (which is doing NN upsampling), I can actually see the 4x4 dither patterns in the blue image (and just blocky banding in the non-dithered one)

The dither patterns don't look optimal, there might be room for improvement there

(maybe could do a decoding at bitdepth 4 or so to better see the dithering patterns)

oh, I know that (I even calibrated my monitor, thanks to <@!604964375924834314> :D), but I'm not quite sure what a percentage above 100% means 😄 I guess below 100% it's just a given fraction of the gamut is reachable, but above it's a bit more fuzzy to me...

I'm doing this https://en.wikipedia.org/wiki/Ordered_dithering with a 4x4 matrix, unless I did something wrong xD

The guy from the issue recommended https://discord.com/channels/794206087879852103/804324493420920833/840934339827204136 but no idea how performant that would be.

It's ok but maybe a different matrix would work slightly better

the part of that suggestion that worries me is "This technique is covered by Ulichney’s ​U.S. patent 5535020 and the specific implementation we showed is partly covered by Epson’s ​U.S. patent 6088512."

Ugh

What year are those from?

no clue

changing matrix is cheap anyway

not sure what to try, but...

(of course, to actually have it in djxl/the API, there's more work involved - perhaps we could add a new output format, UINT8_DITHERED?)

Both are expired

One is from 1992, the other from 1997

Any reason to do anything else than Floyd-Steinberg?

Is there any reason not to dither? It's not like undithered is more correct

10-bit lossless would be rounded in a weird way to 8-bit 😄

Dithering on material with sharp edges and text may be undesirable.

it's an error diffusion based method, not quite SIMD/parallelization friendly

ordered dithering is just biasing the rounding in a location-dependant way, basically

Ok, fair, but it's also computationally very cheap I think, compared to decoding jxl?

well, ordered dithering is a lot cheaper 😄

I have no doubt about that.l :D

also I think less likely to cause problems at sharp edges

Hmm, perhaps.

and I don't think one needs very fancy dithering to get stuff to work well for 8-bit output...

It just improves the effective display bitdepth in slow gradients, and since it only introduces off-by-one diffs w.r.t. no dithering, I don't think sharp edges or text will look any different.

I think it is basically a no-brainer to just always do it

Well a no-brainer that does require some reflection and verification maybe

We have the luxury (at least in vardct mode) to work in high precision anyway, so we have the actual signal at whatever bitdepth. So the dither is accurate and not just some noise that hides banding.

(in that respect I think we have an advantage compared to avif, which works at the signalled bitdepth afaik)

is jxl decoding specified at the pixel value level?

No

It is specified using real numbers

Which is of course something that doesn't really exist 🤣

(real numbers are very inaccurately named)

Conformance for lossless will have pixel exact requirements, but for lossy there will be tolerances that allow implementations using float or fixed point.

Those tolerances still have to be defined but I think dithering will not be the biggest concern there.

That's a good reason for dithering by default though, even if it's a relatively simple one.

vardct has real numbers, and without dithering you're throwing that precision unconditionally away

none of this really affects browsers, though 😄

Chrome apparently uses 16-bit half-floats for HDR. Not 10-bit ints with PQ or HLG. I wonder where that final conversion to display space is happening, and if it does dithering.

I suppose it does for an image displayed 1:1, no?

(even when rescaling, there is in a way more information preserved in the dithered image)

The issue is that we apparently need more than 8-bit for SDR already but displaying more than 8-bit isn't really common.

browsers would convert on the fly from floats to the display colorspace in u8 though, so it's not the jpeg xl API that would have to take care of dithering

(for jpeg xl)

Oh we only give the float buffer to chrome?

well, not now

but we will for 92 I believe

Dithering is the task for whoever does the final conversion to display space integers

I thought we were going to have an api where basically chrome says to libjxl "please give me an uint8 rgba buffer in my display space", and libjxl either returns that (if it can), or it returns a uint8 rgba buffer and an icc profile and tells chrome "you take care of this please"

But maybe that doesn't work after all?

(because display space could change and stuff?)

it's better if we tell chrome "here is a chunk of 200 pixels, they're RGBA floats, in X colorspace, please take care of the rest"

But it doesn't hurt if djxl supports dithering just in case, right? ;)

It doesn't hurt, no, and will help for simpler applications that are not as tightly integrated.

Ah ok. Then I suppose we could at some point try to get dithering in the "take care of the rest" part, but that's completely orthogonal to jxl integration then.

yep

Will `--allow_more_progressive_steps` produce output similar to how browsers will decode JXL? Or is it better to leave it off?

Good question. It's in djxl mostly to show what _could_ be done with a partial bitstream (and even at that it's not really being exhaustive in trying to show as much as is possible, since it still does not show partial squeeze refinement steps, only full steps).

How many repaints browsers will actually do is a different thing, and there are several considerations there to take into account.

First there's the impact on decode speed and memory usage; likely it makes sense to avoid multiple repaints when the file is locally cached or the network is fast enough.

Secondly some people don't like progressive loading at all.

(yeah, I've never understood why, tbh)

Ok, I'll go without `--allow_more_progressive_steps`, assuming it might be _less_ representative of what the browser will do

I think that's a safe bet

Any update on the state of progressive jxl decoding in chromium, <@795684063032901642> ? I suppose it is less urgent than making animation work (since it does not have impact on the final result), but is someone working on it?

working on animation right now..

<@!794205442175402004> djxl wouldn't spit out a file until it had more than 50k of input. Does that seem correct?

depends on the total size 🙂

Here's the full file

seems a bit excessive

how did you create it?

https://squoosh.app

I mean with what flags?

depending on flags and the image itself, the DC preview will be available anywhere between 5-25% of the total size

Quality 40, effort 4, progressive rendering on

Edge filter on

mhh, yeah, quality 40 will not be too good for getting DC early (effort 4 shouldn't change *too* much, but I believe progressive rendering mostly just increases file size if you're mostly interested in the DC)

Ohh, so what would you recommend?

I don't remember what squoosh's effort corresponds to in terms of cjxl speed

Give me the JXL settings and I'll translate it

try something like -q 70 to 90, -s 7

and nothing else

What about epf?

default is good

cool

`-s 7` is the maximum speed, right?

no

maximum is -s 9

well, -s 9 the *slowest*

(yeah, those numeric values are weird)

whoa, I think we've got these backwards on Squoosh

I wonder if that explains why increasing effort sometime increases filesize

-s 3 is the fastest, -s 9 is the slowest

it absolutely would 😄

-s 3 for lossless/delta palette in particular can be a huuuge blowup in size

we have a very confusing --speed where higher means slower

Higher should be always slower

Wp2 is in this Way

for _speed_?

Yes

it's like the very confusing --cpu_used where lower number means more cpu used

we should just rename --speed to --effort

Yeah, we call it effort in Squoosh

Yes i fully agree

maybe let's start by adding --effort and keeping --speed as a deprecated synonym

Wp2 is -effort

Not --effort

And without =

gzip-style?

to me that looks a bit weird

single letter `-e 3` or long-form `--effort 3` (with or without an `=`) feels most 'conventional' to me, but of course that's all a matter of preference and habit

`-s 7` seems to produce a bigger file than `-s 6` and `-s 8`

I'll double check it's not just Squoosh

that can happen - more effort does not necessarily mean smaller file, it should mostly mean "better size/quality trade-off"

(though the only thing it is really guaranteed to mean is "slower")

for lossless of course it should be the case that more effort means smaller file (though even that isn't always true)

I don't think even that is *fully* guaranteed xD

Unrelated directly, but sometimes higher Effort in sqoosh gives me errors on both Firefox and Chrome (OSX&Win):

I think we need to take a close look at our implementation. I'm getting different results between squoosh & the cli

<@!179701849576833024> problem is, if I go for the higher quality settings, it's going to be much bigger than a jpeg of decent quality

mhhh, perhaps our definition of "decent quality" differs then 😛

hm maybe

what happens if you recompress the JPEG?

i.e. `cjxl image.jpeg image.jxl`

(for that matter, where do you get the DC render for JPEG?)

JPEG 302kB, JXL 270kB

Here's the JPG

But here's a JXL that looks good to me too

you're right, it looks surprisingly good for being quality 40

I think there's a lot of grass and dirt that can take the noise

yeah

the only dodgy bit is the around the bottom of the chiminea, but that _kills_ AVIF

goes flat in a really ugly way

given the quality etc, I'd expect that you get a decent preview at ~40 kB here

I suppose it also depends on whether you have a separate DC frame or not

It doesn't seem to produce a seperate DC frame

without the separate DC frame there's also the AC metadata in the DC groups which might postpone the point where DC is complete

50kB frame

Which looks like DC plus some AC in the top left

with `cjxl --progressive_dc=1` you force a separate DC frame (that itself happens to be progressive, but you need djxl --allow_more_progression to see that)

did you create this image with --progressive / --progressive_ac?

the part with AC looks a bit bad to me

`--progressive`

it looks like the first scan of progressive ac

the first scan looks worse than the fancy-upsampled DC because it doesn't do any fancy upsampling anymore

(might be better to treat it as 1:4 and do fancy 4x upsampling to it)

try without, it should be a bit smaller 😄

also try --progressive_dc=0, it can have some *weird* effects on file size (usually it makes it better, but not always...)

best to get DC fast and no extra AC scans should be `--progressive_dc=1 --progressive_ac=0`

but default should not get DC that much later. It's a somewhat different image you get with progressive DC or not though

``` ----progressive_ac=0 didn't expect any argument passed to it. Error parsing flag --progressive_ac=0 ```

I believe you can skip the flag and it's equivalent

yeah, that worked, and it looks like DC then full squares

That's the progression I like most, tbh

Clear when you have the full image, still good preview and indication of progress (because groups are popping in)

I'll run with that then

Hello, i have a problème with squoosh options, why you don't use the same "effort" than cjxl encoder? You use 0 to 6 numbers althought cjxl use 3 to 9. It's not good at all for future user when they switch to cjxl. 😕 And you use -s 6 as default againt the real defaut -s 7. (I understand because it's too slow) But i think you need to write what is the real default param. In cjxl patch are enable at -s 7 and no at -s 6, for screenshot size is very different without patches. The epf param an gaborish param vary with quality, maybe it's why you have differences in squoosh?

The 3 to 9 thing in cjxl is a bit weird, but the reasoning is that maybe one day we'll have a 1 to 11 scale

https://c.tenor.com/KzQ1LFMZMlQAAAAM/spinal-tap-clever-and-stupid.gif

https://c.tenor.com/hLVZC4qxNBUAAAAM/these-go-to11-spinal-tap.gif

Yes but we need to have the same "number" for the same effort between squooth and cjxl. The world no need more complexity than it is 😆

<@231086792315633664> see the discussion above

https://github.com/GoogleChromeLabs/squoosh/compare/jxl-fix

Ah sorry, i don't understand exactly the discussion but i read it before posting ^^, so it's a great comit 💙

going to 11 is a tradition by now: brotli goes to 11 and guetzli goes to --quality 110

do all the scans have x/y resolution asymmetry? Do we need a special 4x2 upsampler?

I don't think that is really needed. In VarDCT scans you would normally use a resolution-symmetric scan script. In Squeeze scans you alternate between symmetric information available and 1:2 or 2:1 asymmetric information available, but there I would just skip the asymmetric intermediate results.

wow <@!811568887577444363> , that "SIMDify upsampling" merge request does look impressive! 🙂

> 4x / 8x upsampling got 18-19 times faster (on 16-x float vector CPU). > 2x upsampling got just 5.6x faster -> it seems there is still place for optimization.

(it was quite slow to begin with, of course, but still)

this should make the fancy DC upsampling in progressive rendering cheap enough, right?

Thank you for clarifying

I really like our 8x upsampling a lot -- I spent about a month tweaking it for pik possibly around 2017 and I believe that it is somewhat difficult to do better than that without using a priori info or very large supports

adding a gentle amount of noise on it would improve the results further

now one of the major differences is from going from "glossy" to "non-glossy" between the interpolated and the final image

there is also some shift of brightness or contrast in some areas -- it might be possible to do better if we understand better what and why it is happening

possibly it is the 3rd power vs. real gamma should be around 2.6 causing some averaging not to work that well

my work back then was for a 4x4 upsampler that Moritz then resampled to be 2x2 and 8x8 by first applying my code twice into 16x16 resolution and then averaging down to 8x8 (and 2x2)

the idea I explored with was to move pik's 8x8 DC into a 4x4 DC with great upsampling (for even higher quality of previews) and then codify the rest with a DCT

it wasn't easy to get it working in a way that was competitive with the pik's current approach so I dropped the idea, but the upsampler survived into JPEG XL 😄

our 1:8 is effectively downsampled in a colorspace a gamma of ~3, while to avoid color shift you need to downsample in linear color (gamma 1). Not much can be done about that, the only way to avoid it is to do the DCTs in linear color but that would be a very bad idea.

that would be horrible of course

also, linear gamma downsampling is not what you always want

it's not always what you want, but it is the only 'correct' thing to do, physically speaking

if we could estimate the variance of each 8x8 pixel based on the neighbourhood and do a pseudo gamma correction at around gamma 2, we'd have likely significantly better results

I do get customer complaints about linear downsampling, usually because it makes black text on a white background thinner than the too-bold-because-of-sRGB-downsampling they are used too (which is wrong but better for legibility)

I think it depends on the resulting angular pixel size

if pixels are smaller or larger than receptors

anyway, browsers also downscale in nonlinear color, just with the display transfer curve instead of the gamma ~3 we have

if pixels are smaller than receptors, then they should work with photon-based physical modeling to produce the same experience

if pixels are bigger than receptors, then they are already observed through compressed gamma and signals could be better averaged in the compressed space

I believe that it is complicated, I think there is no one correct way there

yes, it is. for progressive previews I think what we have now is good enough though

for the 1:8 preview at least

if we want to go into 1:16 previews and other more blurhashy stuff, that's something else

and the intermediate progressive passes for 1:4 or 1:2 - equivalent info, that's something else too

currently the first progressive AC pass looks worse than the DC alone, which is an annoying nonmonotonicity of experience...

(the same is true in the case of old JPEGs, btw. Once the DC goes from "fancy upsampled" to "blocky old DC" mode, things get worse before they get better again)

Btw, Squoosh doesn't have the "effort" setting backwards, since we map to the "speed tier" enum, where higher numbers are faster (less effort), rather than cjxl's backwards speed 😀

If cjxl renames to "effort", I'm happy to match the numbers up, but I definitely don't want to put a backwards speed setting on there

It was certainly interesting reading the code and seeing that, along with the fact speeds are referred to by their animal analogues.

anyone else getting ``` error while loading shared libraries: libIlmImf-2_5.so.25: cannot open shared object file: No such file or directory ``` when running either cjxl or djxl compiled from the AUR `libjpeg-xl` package (latest v0.3.7-1)? it doesn't seem like any package (official or AUR) provides that library, idk if it's supposed to be compiled along with libjxl or if i should get it somewhere else for now

i use AUR libjpeg-xl package, in what operation give this error?

any invocation of either of those binaries, even getting help or printing version doesn't work

no, i use libjpeg-xl-git sorry

hmm i'll try building that

i _think_ i have libjpeg-xl on my laptop too and it works <:Thonk:805904896879493180>

I disabled test

diff

``` diff --git a/PKGBUILD b/PKGBUILD index 4dcb98c..37c19e5 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -2,7 +2,7 @@ pkgbase=libjpeg-xl-git pkgname=('libjpeg-xl-git' 'libjpeg-xl-doc-git') -pkgver=0.3.7.r3.gab7c5e9 +pkgver=0.3.7.r5.g040eae8 pkgrel=1 pkgdesc='JPEG XL image format reference implementation (git version)' arch=('x86_64') @@ -58,15 +58,16 @@ build() { export CC='clang' export CXX='clang++' cmake -B build -S jpeg-xl \ - -DCMAKE_BUILD_TYPE:STRING='None' \ + -DCMAKE_BUILD_TYPE:STRING='Relase' \ -DCMAKE_INSTALL_PREFIX:PATH='/usr' \ + -DBUILD_TESTING=OFF \ -DJPEGXL_ENABLE_BENCHMARK:BOOL='false' \ -DJPEGXL_ENABLE_FUZZERS:BOOL='false' \ -DJPEGXL_ENABLE_PLUGINS:BOOL='true' \ - -DJPEGXL_ENABLE_VIEWERS:BOOL='false' \ + -DJPEGXL_ENABLE_VIEWERS:BOOL='true' \ -DJPEGXL_ENABLE_GIMP_SAVING:BOOL='ON' \ -DJPEGXL_FORCE_SYSTEM_BROTLI:BOOL='true' \ - -DJPEGXL_FORCE_SYSTEM_GTEST:BOOL='true' \ + -DJPEGXL_FORCE_SYSTEM_GTEST:BOOL='false' \ -DJPEGXL_FORCE_SYSTEM_HWY:BOOL='true' \ -DJPEGXL_WARNINGS_AS_ERRORS:BOOL='false' \ -Wno-dev ```

ok it works now ¯\_(ツ)_/¯

gg

tyty no idea why the other one didn't work tho

well the old one linked against libIlmImf and this one doesn't

dunno what changed tho

underlying lib changed soname

so when you rebuilt it and relinked to new soname it just worked

p usual issue, when you get these just rebuild relevant aur package

ah that makes sense

tbh maintainer should b making bumps for pkgrel when this happens but it's aur and if they arent aware it wont happen

yeah, Ilm = Industrial Light & Magic, those originally behind EXR

I got that error after updating Arch. Rebuilding the package fixed it.

Yay repo sync!

With fixed patches?

Also, is it 0.3.8 or 0.4.0 <:Thonk:805904896879493180>

<https://encode.su/threads/3564-JXL-version-0-3-released?p=69684&viewfull=1#post69684>

Patches should be fixed, yes

I don't know what we are doing with the version numbering, you can consider this to be a 0.4.0rc1, I suppose

It _should_ be a complete decoder now, that can handle all exotic corners of the spec

Are you working on a set of test vector images or so, to test compliance?

I have put a few examples here to test some common problems: https://github.com/libjxl/conformance

We'll have to add a bunch more to cover everything that an alternative decoder could get wrong, but to test applications it's a start

I demand nested patches inside the DC component.

😂

And an image with a MA tree leaf for every pixel.

Creating those exotic bitstreams will be fun

"fun"

Generalizing jxl_from_tree to also do VarDCT, patches, splines etc, will be tricky but Good For Art 😂

What does MA mean?

meta-adaptive

Manga set ```305 168 792 - previous build 305 419 668 - new build``` 🤔

Better only on a few images with text (by 1-4%), on the rest worse or the same

I suspect that for lossless the heuristics are not as well tuned as they should be

i assume that even though what was there is fixed, it's still not really usable in many images

For lossless the situation is much trickier than for lossy: for lossy it is likely going to be a win because you're using modular to encode something that likely encodes better with modular than with dct.

For lossless, the question is if the signalling cost of patches is worth the saving, and it isn't always

you could have a flag to test savings in the meanwhile

which would do two or more encodes but it would at least tell you if it was worth it

Yes, or take a corpus with images from Scope's test where it helps and where it doesn't, and try to improve the heuristics to make it help more and not-help less

What's the use case for decode_oneshot and encode_oneshot? Does anyone use it in practice?

the use case is giving an example of how to use the API

😛

ah, ok 🙂

Hello, I get some build problem on windows-msys2-mingw64 ```cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DJPEGXL_ENABLE_BENCHMARK=OFF -DCMAKE_C_COMPILER=clang.exe -DCMAKE_CXX_COMPILER=clang++.exe -G Ninja ..``` I think this probably a path problem, but i can't fix this, Could anyone can teach me how to fix this? ```Change Dir: C:/msys64/home/lee/Project/jpeg-xl/build/CMakeFiles/CMakeTmp Run Build Command(s):C:/msys64/usr/bin/ninja.exe cmTC_1013d && [1/2] Building C object CMakeFiles/cmTC_1013d.dir/testCCompiler.c.obj FAILED: CMakeFiles/cmTC_1013d.dir/testCCompiler.c.obj C:\msys64\mingw64\bin\clang.exe -o CMakeFiles/cmTC_1013d.dir/testCCompiler.c.obj -c testCCompiler.c /bin/sh: C:msys64mingw64binclang.exe：Command not found ninja: build stopped: subcommand failed.```

ok, fixed

The Japanese national body of ISO is discovering some minor inconsistencies between the spec and the reference software, which we will have to resolve but which is also a very good sign because it likely means that camera manufacturers are working on a hardware encoder.

No, we will fix the spec if fixing the code would break things.

PreviewHeader is something I don't think cjxl uses at all atm

Yes we need to fix it before declaring a 0.4 release

I don't think any existing bitstreams would break by fixing things

National bodies have already reviewed the committee draft and the DIS. Now they are reviewing the FDIS but in principle it's just a binary "approved" or "not approved" at this ballot (the previous two ballots had the option of making comments, which we then had to reply to)

Most comments in the past came from ANSI and DIN (the US and German national bodies).

I hope the ballot results for Part 1 will be there by the July JPEG meeting, but I am not sure. When the FDIS ballot gets approved, it then takes a couple more weeks for ISO to do its thing and publish the actual IS.

The big milestone was in January when JPEG approved the FDIS for submission to ISO, after that it should be OK since it was already approved by all relevant experts.

So it is unlikely that at this point, the national bodies will vote "no" and block the standardization. It is more of a formality at this stage in the process, afaiu.

hello everyone, oss-fuzz has found a jxl which locks up git master jxlinfo http://www.rollthepotato.net/~john/clusterfuzz-testcase-minimized-thumbnail_fuzzer-6181430527918080 with git master jpeg-xl I see: ``` john@banana ~/pics/fuzz $ ~/GIT/jpeg-xl/build/examples/jxlinfo clusterfuzz-testcase-minimized-thumbnail_fuzzer-6181430527918080 xsize: 6008 ysize: 4807 have_container: 0 uses_original_profile: 0 bits_per_sample: 24 exponent_bits_per_sample: 7 intensity_target: 255.000000 min_nits: 0.000000 relative_to_max_display: 0 linear_below: 0.000000 have_preview: 0 have_animation: 0 orientation: 1 num_extra_channels: 0 alpha_bits: 0 alpha_exponent_bits: 0 alpha_premultiplied: 0 ``` and the prompt never comes back. djxl fails quickly, I suppose it sees the nonsense values in basic_info and gives up vips sees basic-info, tries to get the next chunk, then (after >5s of cpu in JxlDecoderProcessInput()) sees an error looking at the read()s it's doing, each 4kb read after basic_info gets slower and slower, it looks like on a quadratic scale so perhaps there's some O(N^2) hole it's fallen into in the parser?

that's absolutely possible, if perhaps a bit unlikely - can you open a bug?

sure would someone be able to very quickly test it before I open the bug? I don't want to make extra work

issue opened

I mean, I could verify it either before or after you make the issue 😛

it's never a bad idea to file issues for such things

hehe OK, well the issue is there now

yup, I assigned it to a couple of people that I think are the best to figure it out 🙂

Are those examples all free to use? Probably good to add some license?

They should be free to use, but I should add the exact licenses I guess

Yes, I need to check that

Alpha triangles and sunset logo I made myself. They are CC0.

Yes, see <#824000991891554375> 😁

Well cwebp just silently ignores/strips ICC profiles, doesn't it? So if there is a performance bug in ICC handling, cwebp wouldn't trigger it because it doesn't even look at the ICC...

cwebp always silently strips icc profiles afaik

Yes, you have to use webpmux to explicitly add it

And then dwebp will silently strip it again when you convert back to png 😖

It's not exactly the greatest tooling in that respect if you ask me

And the libwebp API is not much better: it's very convenient to get the decoded pixels, but to also get the color space they're in, you have to jump through some hoops

Then again, with the 7.5-bit limitation of lossy webp, it's not really suitable for anything else than sRGB. Even P3 is already a bit of a stretch imo.

Lossy webp uses TV range YCbCr, not full range like jpeg, so it's basically 7.5-bit and not 8-bit YCbCr, which means effectively in RGB it's 6.5 bits of R and B, 7.5 bits of G (plus chroma subsampling on top of that)

Plus the minimum quantization (highest quality, what you get at q100 lossy) is not 1 like in jpeg but 4, iirc.

(maybe that's only for chroma, I don't remember exactly)

Must be some worst-case behavior of the icc compression

In jxl we have a custom compression for icc profiles, yes

Yes

Annex B of the spec is just about icc compression

the profile is that large?

interesting

by "that large" I mean large enough to care about designing a custom algo just for it

They can be quite huge in the case of CMYK. Typical profiles there are between 500 KB and 1 MB.

For RGB the typical ones are not huge, usually a few kb

Still large enough to care about compressing them though

Lossless mode (including jpeg recompression) preserves the exact icc profile. In lossy mode we are a bit more free and replace known icc profiles with an equivalent shorter representation (equivalent in the color space it represents, not the exact icc profile bitstream)

Yes, P3, Adobe RGB, sRGB etc can be expressed in the enum and use only a couple of bits

The thing is, there is not just 1 sRGB profile. There are multiple variants, which are very slightly different (numbers are rounded differently, etc)

In lossy mode we say "close enough" and use the enum anyway

In lossless mode we don't do that

You are not including the bt2020 like P3? Seem to be the future color reference format.

Both DCI P3 and Display P3 can be done in the enum, also rec2020/rec2100 with PQ and HLG

You think to all 😉

About icc, i do no not take time to do test but as i understand with 32bits fload internal jxl, record jxl in rec 2020 will not reduce precision in color for our 8 and 10bits display? It's only a bit slower decoding for display on srgb? (I know it's bad i can test it :D)

In lossy/XYB, the internal color space is always the same absolute space, and the color space signaled in the header is just a suggestion for a target space to convert to after decoding (but you can also just directly convert to display space and ignore the header space)

Only in non-XYB mode (lossless or lossless jpeg) does the header space actually matter to interpret the pixel data

oss-fuzz has found a buffer overflow in git master libjxl, shall I open an issue? (though it appears as Conditional jump or move depends on uninitialised value(s) in valgrind, mysteriously)

Better safe than sorry, better open an issue

ok, issue opened, good luck!

probably 'cause it reads a value-past-the-end which is of course not initialized

yes, though you'd think valgrind would report that as a read beyond end of buffer, wouldn't you?

maybe valgrind's malloc slightly overallocates it

also, even if Rec. 2020 hadn't been included specifically, it still doesn't require that many more bytes to use custom primaries

it's especially LUT profiles that would be troublesome

and for images, they're not that common

(unlike display profiles)

I suppose LUT is used mostly when modeling real things like actual displays and printers

Not sure, I would expect most scanners to do their own conversion and produce results in an idealized color space, but I don't know

`cxl 1653x379.png 1653x379.jxl J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: AVX2,SSE4,Scalar] Read 2400x1080 image, 31.6 MP/s Encoding [Container | VarDCT, d1.000, squirrel | 245-byte Exif], 2 threads. /usr/src/packages/BUILD/libjpeg-xl/src/jpeg-xl/lib/jxl/fields.h:52: JXL_FAILURE: Value 4294967295 too large for 3 bits /usr/src/packages/BUILD/libjpeg-xl/src/jpeg-xl/lib/jxl/fields.cc:563: JXL_RETURN_IF_ERROR code=1: ok_ /usr/src/packages/BUILD/libjpeg-xl/src/jpeg-xl/lib/jxl/fields.cc:720: JXL_RETURN_IF_ERROR code=1: CanEncode(fields, &extension_bits, &total_bits) /usr/src/packages/BUILD/libjpeg-xl/src/jpeg-xl/lib/jxl/enc_file.cc:186: JXL_RETURN_IF_ERROR code=1: WriteImageMetadata(metadata->m, writer, kLayerHeader, aux_out) /usr/src/packages/BUILD/libjpeg-xl/src/jpeg-xl/lib/jxl/enc_file.cc:203: JXL_RETURN_IF_ERROR code=1: WriteHeaders(metadata.get(), &writer, aux_out) Failed to compress to VarDCT.`

eh, sounds like a problem 😛 can you share the file in an issue?

does it fail if you strip exif too?

(could be that there's an invalid exif orientation)

I will check. It is a screenshot from the phone.

It works fine after strip

is it on the latest version of jxl?

The screenshot is in landscape

ah, might be that we didn't fix it for *png* input...

<@!794205442175402004> might know

No. I am running an aosp custom rom.

0.3.7 . 1 month old I think

portraits screenshots work fine though

The screenshot looks funny. I will send you in dm.

Should be fixed for all inputs, the exif is parsed later

That should be the only place that looks at exif

Does anyone else get a 'failed to read image' with this jpeg?

``` $ cjxl kX1HrJw.jpg kX1HrJw.jpg.jxl J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: SSE4,Scalar] /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/jxl/jpeg/enc_jpeg_data.cc:311: JXL_FAILURE: Cannot recompress JPEGs with neither 1 nor 3 channels /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/extras/codec_exr.cc:155: JXL_FAILURE: OpenEXR failed to parse input /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/extras/codec.cc:133: JXL_FAILURE: Codecs failed to decode /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/extras/codec.cc:146: JXL_RETURN_IF_ERROR code=1: SetFromBytes(Span<const uint8_t>(encoded), io, pool, orig_codec) Failed to read image kX1HrJw.jpg. /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/tools/cjxl_main.cc:68: JXL_RETURN_IF_ERROR code=1: LoadAll(args, &pool, &io, &decode_mps) ``` indeed

``` $ file kX1HrJw.jpg kX1HrJw.jpg: JPEG image data, Exif standard: [TIFF image data, big-endian, direntries=0], baseline, precision 8, 2941x2469, components 4 ``` interesting

CMYK is not supported for jpeg recompression

Weird, I didn't even know it was in that colorspace, so you have to convert to png then jxl even when not doing lossless recompression?

Because it's not loading even if I specify -j for lossy conversion

there's many ways you can do lz77

slower and faster ones 🙂

Hi all, apologies if this is a dumb question, but I'm looking to maybe add jpeg xl support to MuPDF. I can't find any docs for driving libjxl as a simple decoder. Can anyone point me at a FM to R please? 🙂

doc/api.txt had me excited for a bit, but it's basically empty. Other stuff seems to want to talk about how the coding works, but I don't want that. I want "here's how you call the lib". And yes, if I'm being blind, please feel free to abuse me for that, but only after you tell me where to look 🙂

This is absolutely not a dumb question. However, I am not competent enough to respond to your question 😄 You will better be served by the devs here 🙂

you can start looking at `examples/decode_oneshot.cc`

Thanks.

OK, so I need to call this from C. I can make a C -> C++ veneer I guess.

I also need to ensure that all memory accesses go through my own callbacks, not to malloc/free. Presumably there is a mechanism for that too ?

Ah, decode.h looks like a C api.

Ooh, with a lovely mem_mgr thingy.

to be honest - it won't be used everywhere

From what I've seen, `djxl` with `--display_nits=X` and `--tone_map` options performs very crude tone-mapping by simply clamping values. Maybe use something just a little bit more advanced, like Reinhard operator used in JPEG XT for generating backwards-compatible LDR previews (I suggest applying it to the XYB channels instead of RGB for less washed-out look)?

I thought we did some tonemapping in PQ that is more than just clamping

<@!604964375924834314>

yes, it’s not just clamping

it’s https://www.itu.int/pub/R-REP-BT.2390-8-2020 pages 23-25

Probably not for .PFM files as an input

it should if the .pfm is normalized to at most 1 and --intensity_target set appropriately

it’s global tone mapping, though

(same curve applied to all pixels)

<@799692065771749416> we are going to relicense libjxl from Apache 2.0 to BSD 3-clause + separate Apache-style patent grant. Is that ok for you?

Haha, is there any code authored by me still in there?

Go ahead.

I'm not sure actually, but maybe there are some FLIF remnants somewhere

Probably everything has been edited or rewritten at some point by now, but I am not sure, and copyright-wise I guess it might still count as a derived work

So to be sure I'm asking :)

Is this a good thing or not?

It doesn't change much

Slightly more permissive license

Depending on which lawyer you ask. Could also be just exactly the same license.

We are moving from Apache to BSD, which supposedly makes it compatible with GPLv2

And with MPL, which might be relevant for firefox?

FOSS license technicalities get complicated quickly, tl;dr we just want to make sure there are no license issues if you want to use libjxl in anything.

i dont think it matters with non-invasive licenses

as in, yes apache2 has patent protection stuff gpl2 doesn't but if you were integrating with gpl2 then that stuff wouldn't be incompatible

but i don't dislike the move

Yes, likely Apache2 was OK already, but some consider it problematic with gpl2/mpl, so just to be sure we are changing to BSD-3 which is uncontroversially compatible with any other FOSS license

When will the change of the license happen?

Soon (tm)

big merge request, lol

same as before, irrevocable royalty-free with defensive clause (if you start patent trolling, you lose the grant)

Yes. Currently you can point to the Apache 2.0 license file, which says the same thing, so no need to wait for the explicit PATENTS file...

well, technically that only applies to the *code*, not to the format - I guess you can point them to the Type 1 declaration from ISO?

<@!794205442175402004> I guess

ISOBMFF was never patented and it is in any case old enough to have all unknown patents expired (JPEG 2000 uses it, so it is at least 21 years old, probably older)

a gif encoder is kind of out of the scope of the project, no?

sure, feel free to quote me

honestly you should close the discussion

you aren't a developer

or a jxl developer

why go in devs websites?

who should close what discussion?

users can open or discuss issues, why not? there's no "dev certificate" needed to participate in FOSS projects 🙂

i'm joking

yes

sorry i said wrong thing

one thing we should add (isn't there yet) is APNG output, so there is at least one animated output format

at the moment djxl will just produce multiple outputs, one for every frame

I don't think that's it

but you can look say here: http://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf

The complete JPEG XL reference software is available under a free and open source, royalty-free license. The contributors have also declared to ISO/IEC that according to the Common Patent Policy they are offering a Type 1 Free of Charge patent grant.

<@!794205442175402004>

Nokia is not involved in BMFF

they are involved in HEIF

and no, I wouldn't count ISOBMFF as a significant part of JXL, it's just a container convention that part 2 of the spec happens to follow

AVIF is based on an AV1 codestream in a HEIF container which is based on MIAF which is based on ISOBMFF JXL is a JXL codestream, optionally wrapped in an ISOBMFF container.

Has anyone got a test suite of jxl images?

(Or rather, is there a publicly accessible test suite anywhere)

https://github.com/libjxl/conformance ?

Looks perfect! Thanks. Maybe add that link to the <#822120855449894942> ?

It's far from complete, but it's a start

heh, I just replied

tbh normalized images to use as reference would be nice

as in, srgb, prerotated, maybe dithered 8bit

not reference to mechanically compare to but for human viewers to see how stuff is somewhat intended to look

input.jxl is the input, ref.* is the reference for humans

the reference for machine comparison will be in a different format since we need something that can do 32-bit float, any number of channels, and animation, and such a thing does not exist in a widely-supported human-friendly file format.

If it doesn't exist then jxl is the king and doesn't need to compare to anything… 😜

png rotation is p fucked in my experience, i think i tried that stuff some time ago but support was.. not good

by default, libjxl handles orientation for you

so if it's wrong, it's either because you are explicitly asking libjxl _not_ to handle orientation and failing to do it yourself, or it's because you are doing orientation _again_ after libjxl already did it

looks like in the digiKam case, it's asking libjxl to not handle orientation and then also not doing it itself

(if it was done twice, you'd see an upside-down bench)

(unless they messed up the "doing it twice" thing and do the orientation in the opposite direction)

orientation and color profile handling are things that always tend to cause trouble, so that test image should help to find applications that don't do it correctly

nah

I could make one but there's no software that will correctly render it, not even djxl 🙂

Level 5 does not allow CMYK

(djxl does not implement color management for 4-channel color profiles, so it will decode the CMY correctly and have the K as an extra channel, but then doesn't really know what to do with those to convert it to an RGB png, for example)

a lot of viewers also display CMYK JPEGs incorrectly

e.g. all browsers except Safari, IIRC

how exactly incorrectly?

Hello all, oss-fuzz has found an out of bounds write in libjxl github master I've opened an issue

Re. CMYK JPG viewing, there are some annoying problems around D50 / D65 white with CMYK JPGs many viewers even ignore embedded profiles (!) the whole business of visually matching an emissive display to ink on reflective paper is a nightmare, and it's very hard to set up a good viewing environment (I spent years on that nonsense, sigh)

Not doing proper color management, or ignoring K and just rendering CMY as if it were sRGB

I wonder how relevant CMYK will remain the future, now printers are starting to move to more-than-4-color processes...

Likely just wide-gamut high-precision RGB, plus maybe some vector stuff in black, is a better approach than using CMYK workflows

more-than-CMYK has been around since at least the 90s, I'd be surprised if CMYK went away soon

friends tell me that sometimes you have to work in CMYK for control over actual ink on paper -- eg. I want no ink here, and I want 100% ink there especially if you use spot colours as well

the offset press market is a difficult business when I started out I was full of enthusiasm for calibrating everything and getting perfect colour I went on a factory visit to see the press we were working with and there was a man with a bucket of ink and a trowel walking along the top of the machine dropping ink on to rollers where he felt they looked a bit dry calibration goals were scaled back after that field trip hehe

Lol

Yes, I can see how controlling ink directly can be useful (especially for text, where you want to avoid using multiple inks if possible).