JPEG XL

`git clone https://github.com/msys2/MINGW-packages; cd MINGW-packages/mingw-w64-ffmpeg; MINGW_ARCH=x86_64 makepkg-mingw -s`

done

one can change the `PKGBUILD` in-between to add the desired dependencies and configure flags

(that’s even assuming that one needs to build with different options, otherwise `pacman -S mingw-w64-x86_64-ffmpeg` will get you ffmpeg as well)

Yes, this is suitable for the lighter version, but if someone needs more, and also include for example several AV1 encoders at the same time and also use the latest builds and automatically update them all at once, it is much more complicated and longer than using ready-made scripts

my experience with m-ab-s was that it was just more potential ways for the process to go wrong (and with dozens of questions before you get to it)

Also, not everyone has an in-depth knowledge of this, especially if some changes and patches are needed

Like this (a lot of things can be figured out, but not everyone has time to find solutions, especially not for developers and for people using Windows who are less used to compiling different stuff): <https://github.com/m-ab-s/media-autobuild_suite/commit/fcbc9533c4aa91f61dfe19b1c3d3bd80e75ce7eb> <https://github.com/m-ab-s/media-autobuild_suite/commit/9be06f537787561cd0f665c024f0830c31bf6549> <https://github.com/m-ab-s/media-autobuild_suite/commit/d76c779bc84bc0a76fe7e8981f19bb703dab58e4> <https://github.com/m-ab-s/media-autobuild_suite/commit/60bc4ab6ecd040a919ca5a4d10ff6da66b09ec70>

thanks, this is starting to make a bit more sense to me

are such patches typically upstreamed? or do they maybe come from the upstream in the first place?

As far as I know, some of them are

Btw https://github.com/AOMediaCodec/libavif/issues/528

<https://www.reddit.com/r/jpegxl/comments/lyhsum/large_new_sync_to_jpegxl_gitlab_repo/> Btw, why are commits organized in this way or is it some kind of technical issues that it is more convenient in development at the moment?

it's more convenient for now, migrating to publishing single commits and accepting external contributions is part of the plan but it will likely take a bit of time still

maybe we can migrate the commit history too

I don't want to spend time on improving the version control procedures for the next 2 or 3 weeks

if there is just a flag that we can use to bring the commit history, we could perhaps do that

it’s not harder to have the full history

the question is whether the reasons why we did not publish it in the first place still apply

I think it's ok to have the commit history. The discussions in the code review are probably best kept private though, not sure what stuff I wrote there these past two years but some of it was certainly not meant to be public 😅

It looks like 0.3.4 fails to build on macOS

https://github.com/Homebrew/homebrew-core/runs/2126170861#step:7:842

`lib/extras/codec_exr.cc:93:12: error: virtual function 'tellg' has a different return type ('uint64_t' (aka 'unsigned long long')) than the function it overrides (which has return type 'Imath_2_5::Int64' (aka 'unsigned long'))`

Ugh is this version dependent on macOS now? It's a 64-bit unsigned int, why is this kind of thing still a problem in 2021...

Can you upgrade to latest openexr?

It is the latest master of the jpeg-xl repo. The openexr repo at https://github.com/AcademySoftwareFoundation/openexr doesn't even have a codec_exr.cc file.

I see, codec_exr.cc is apparently the libjxl client code and it extends a base class defined in openexr.

It looks like Homebrew has openexr 2.5.5, which is the latest version.

https://github.com/AcademySoftwareFoundation/openexr/blob/master/src/lib/OpenEXR/ImfInt64.h

``` // Deprecated Int64/SInt64 unsigned 64-bit integer type. // Use int64_t and uint64_t instead. ```

Now I see why it was deprecated: it didn't properly define uint64_t on all platforms as was intended

It looks like openexr changed it from Int64 to uint64_t 14 days ago, but there hasn't been a stable release since then.

https://github.com/AcademySoftwareFoundation/openexr/commit/12df1e60c089ce08083256e3468690f3da0ea642

Int64 was supposed to be uint64_t all the time

(they have SInt64 for the signed one)

But apparently they got it wrong, because on your platform Int64 was an unsigned long which must be uint32 in your case because the compiler complains that it's not equal to unsigned long long / uint64

Int64 is unsigned long and uint64_t is unsigned long long; both are unsigned 64-bit integers but C++ treats long and long long as different even if they are the same size.

Ah really? My compiler didn't complain though. Ugh why can't we just have headache-free int types...

You can have an `unsigned int` that is only uint16 and an `unsigned long` that is uint32, right? In theory...

yes

Int64 should probably just be degined as uint64_t ?

Not sure how we can make our openexr input/output code compile with both the old openexr and the new one

openexr 2.5.5 defines Int64 as long unsigned int if that is 64 bits

https://github.com/AcademySoftwareFoundation/openexr/blob/v2.5.5/IlmBase/Imath/ImathInt64.h#L55

macOS defines uint64_t as `typedef unsigned long long uint64_t;`

I don't see an easy solution. We can't use Int64 in our code because that doesn't exist anymore in the latest openexr

Linux defines uint64_t as unsigned long int if `__WORDSIZE == 64`

and unsigned long long int otherwise

Maybe use Int64 if OPENEXR_VERSION_MAJOR < 3 and uint64_t if OPENEXR_VERSION_MAJOR >= 3 ?

I suppose. Not very elegant to have to do it that way though.

not really many other options though

https://github.com/AcademySoftwareFoundation/Imath/blob/master/docs/PortingGuide2-3.md#finding-and-using-openexr-and-imath-cmake-configs ugh, this looks generally somewhat annoying if we want to support both

it seems `COMBINED_OPENEXR_VERSION >= 20599` is the check we want

ah, they define that just above, it doesn’t come from the EXR headers

> The Int64 and SInt64 types are deprecated in favor of the now-standard int64_t and uint64_t. if they are only deprecated, maybe we can just keep using them?

let me check again what we said in the MR where the change was made

apparently, it was in response to https://gitlab.com/wg1/jpeg-xl/-/issues/162, which suggests that OpenEXR::Int64 was problematic

feel free to revert that change if that solves it, I was just assuming there was an issue when we kept using it (and changing it to uint64_t worked for me on the old openexr, so I assumed they just wanted to get rid of Int64 and uint64_t would work anywhere)

what if we make it return say `decltype(((base_class*)this)->tellp())` ? 😄

possibly with some `std::decay_t<>` in the mix

<@!111445179587624960> or anyone else, do you know whether the GIMP plugin (from libjxl) Windows binary is available for download somewhere?

I couldn't find it anywhere.

I'm thinking like this: Many people are on Windows. Anyone can download GIMP (binary). If they become interested in JXL, they will probably want the easiest way possible. And that's where the plugin binary comes in handy.

I have not tried and do not know if the GIMP plugin even works in the latest builds

But Windows, yes, for compiled binary this should be the first priority, since this is the largest percentage of users and not many people compile from sources themselves

oh, compiling the gimp plugin on windows used to be broken (so we disabled it), but I just tried again and it works now

it’s dynamically linked, though, so I assume it’s going to be somewhat of a pain to distribute for now

What kind of pain? Any volunteers to resolve it? 🙂

maybe not a huge pain, but one would need to copy all the required dlls with the plugin and put them next to the .exe

maybe I can give it a quick try and someone can test?

I will

I have something that seems to load (appears in gimp’s “procedure list”) and runs but doesn’t actually seem to work: https://x0.at/lGT.zip

it fails to load images

maybe I’m not supposed to provide the libgimp* libraries myself or something like that

(and many of the other dlls are likely transitive dependencies of those)

Wow, it works here! 🆒

It didn't work at first. But I gave it another try with a jxl that doesn't have any special characters in the filename (diacritics in my case) and it works!

There are 2 strange things though:

1) It throws these messages in a separate console window when generating a preview and when opening the file.

2) When finished opening, GIMP shows a dialog asking to convert from "RGB_D65_SRG_Rel_SRG" colour profile to "GIMP built-in sRGB". (The image is CJXLed from an indexed PNG with -s 9 -q 100.)

I suppose GIMP doesn't detect that it is asking you "do you want to convert this sRGB image to sRGB?"

In fact, it doesn't make any difference whether I press "Keep" or "Convert" in that dialog. So the jxl plugin just makes GIMP to show the dialog needlessly. Shall I report it as a bug?

(Not sure what priority the plugin currently is.)

<@!604964375924834314> Good news! All those DLLs you packed to IGT.zip are not needed. Just the "file-jxl.exe" does the magic.

When I deleted them from ".\AppData\Roaming\GIMP\2.10\plug-ins" and kept just the exe there, those error messages are gone. 👍

oh, nice to know

if you ask me, this dialog is pretty much always unneeded :p

but yes, maybe we can do the detection ourselves and somehow assign gimp’s own sRGB profile if it matches

The dialog should appear if there's actually something to convert. But I'm not sure whether cjxl stored something like that into the jxl (nothing like that was in the original png).

if the original PNG had either nothing or an sRGB tag or an sRGB ICC profile, then cjxl stored {colorspace = RGB, whitepoint = D65, primaries = sRGB, rendering_intent = Relative, transfer_function = sRGB}

which is represented as a string by RGB_D65_SRG_Rel_SRG

and then the decoder synthesized a corresponding ICC profile

so I think it will remove the dialog if the jxl gimp plugin does something like `if (colorspace.IsSRGB()) { /* attach GIMP sRGB profile instead of the one we synthesize */ }`

the GIMP API probably allows getting that GIMP sRGB profile

yes, `gimp_color_profile_new_rgb_srgb` should do it

All this makes perfect sense. Thanks, <@!604964375924834314> !

And now that we know that the GIMP plugin works, will it be enabled by default?

we just merged a change in the internal repository that puts the gimp plugin out of the `if (NOT WIN32)` block

and which does the sRGB trick mentioned above

it will still be necessary to pass `-DJPEGXL_ENABLE_PLUGINS=YES` though

(or edit the `CMakeCache.txt` and rebuild)

next sync should have this

oh, and it also removes the console that opened

That sounds wonderfully!

Now the last thing with the plugin is to allow saving (if the rest of the code is ready for it). 😎

Thanks!

oh, true, there’s that :p but the current code for saving does not allow changing any setting, this is still to be implemented

we also wanted to migrate the plugin away from the internal C++ API and to the public C API

and from what I understand, there was also external interest in having it use the new GIMP 3.0 plug-in API instead of 2.10

not yet sure what that entails

the changelog for 2.99.4 suggests that presenting settings for saving might become easier:

> New generic dialog generation and metadata support API for export plug-ins

https://www.gimp.org/news/2020/12/25/gimp-2-99-4-released/#dialog-generation-for-plug-ins

Is it OK that cjxl does lossy by default with PNGs? 😮 PNG is lossless, JXL supports lossless, so I would guess it would do lossless by default…

You can do good lossy only from lossless

from lossy format do lossy conversion is not good

Absolutely. But lossless from lossless is also charming.

but in this way, with lossless as default in all situation you kill the exceptional jxl Vardct e perception model

I don't think so. It's definitely great for photos so it should be used heavily.

only from who know it exist, for who know a flag is not a problem

But if a non-photo converted from PNG becomes much bigger lossy than lossless, something isn't right.

why? Vardct is good in a lot of non-photo

This inevitably leads me to the following question: What is the status of implementation of fully automatic encoding mentioned here? https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.g9b4791a110_0_389 The thing is to choose lossless from lossless *automatically* if the resulting file is smaller than lossy from the same lossless. Just a suggestion. No intention to offend anyone.

there is a small set of image that make lossless smaller than Vardct (pixelart), but the most off all image is good in Vardct example:

lossless is cool but the main focus jxl I think is perceptually lossless

``` PNG 42 KB jxl 8 KB jxl-lossless 21 KB ```

My example: original screenshot in indexed PNG: 37 kB cjxl default (lossy): 75 kB cjxl -q 100: 45 kB

cool, is not pixelart?

Screenshot of icons on my desktop (not to be shared here… but I will test it on other images too).

a smarter encoder that test also lossless can be perfect if not much slower

also lossless faster mode have some problems whit a small set of images

original screenshot in indexed PNG: 40 kB cjxl default (lossy): 59 kB cjxl -q 100: 34 kB

Screenshot seam a good case for an app to set -q 100 as default

Currently the cjxl help says: -q QUALITY, --quality=QUALITY Quality setting (is remapped to --distance). Range: -inf .. 100. 100 = mathematically lossless. Default for already-lossy input (JPEG/GIF). But it sounds weird to me. First, why is GIF considered lossy? Is it because the 256 colours limit? Second, why PNG and GIF (both lossless) aren't treated in the same way?

If it's intended then my questions are good candidates for FAQ. 🙂

Basically, when I first spotted the JPEG XL project, I was fascinated by the fully automatic encoding (mentioned above). So I wonder how real it is now or will be in the future…

<@!792428046497611796> I also had some concerns about lossy (`-d 1`) being default for lossless input. I think that discussion may be interesting.

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

I never ear gif as a lossless format

The compression is lossless indeed.

the output is not the same as the input, I'm wrong? I not know a lot about gif

Also you think all lossless is better?

BlueSwordM convinced me otherwise in the link just below the message you've just mentioned.

GIF is lossless if your happen to have an image with less than 256 colors, like JPEG is lossless if you happen to have a bunch of quantized DCT coefficients 🙂

so... ALL codecs are lossless u.u

fully automatic encoding: what we have right now is a perceptual lossy encoder that gives visually pretty consistent results

I agree that it would also be useful to detect cases where lossy is just not a good idea, and do lossless there

I mean, doing it in a better way than brute force

if you now pick the smallest output file between `cjxl` and `cjxl -q 100`, you basically already have something that does the right thing

(except that it will be very slow to always do a lossless encode just to see that it is indeed larger than the lossy one for 99% of the images)

Maybe some simple (or not) heuristics?

example large same color areas

I was talking about something like this: https://jmvalin.ca/opus/opus-1.3/

Chapter: ***Speech/music detection***

I was previously talking on this server about similarities between Opus and JPEG XL... maybe could we borrow some ideas from them (at least in areas of similarity)?

Opus also has two modes working in tandem (SILK and CELT) and has to switch between them in a clever way depending on the type of input

Oh, there it is: https://discord.com/channels/794206087879852103/794206170445119489/804425778057183322

yes, simple heuristic would be best, but to do something really interesting, it could segment the image in photo parts and nonphoto parts, and use lossy for the photo part and lossless for the nonphoto part

I have ideas on how to do that, just haven't had the time yet to implement it

Having an original input with up to 256 colours is quite usual. Having a bunch of quantized DCT coefficients is usual only in already lossy stuff. 🙂 When I was a kid, there were usually computers displaying 16 colours maximum. Lossless made perfect sense for it. That's why I might be a *little* biased for lossless and will always be its advocate, even for JXL. 🙂

In any case, if 256 colors was actually lossless, it's likely to be a non-photo image for which lossless will be better than VarDCT. And if the original was photographic but reduced to 256 colors to turn it into a GIF, then it's lossy, and doing lossless is prudent to avoid further loss.

(plus it's silly to let VarDCT spend a lot of effort on replicating the dithering)

Doing lossless by default on _all_ input, including PNG: yes, there is something to be said for that.

Some *really* simple yet quite effective heuristics can be used even now. For example: use lossless modular by default if there's encoded palette in input PNG file, and use that palette directly (no need to calculate it twice). If there's no palette, try automatically detecting it (just like `optipng` does) and if there's one, use it and do the rest as above.

The problem is there are many use cases. We try to let defaults do "what most people would want most of the time", and then -d 1 lossy seems OK.

Yes, the really simple heuristic thing could be added quite easily

I'm just more interested in the not so simple heuristic thing 🙂

Me too! But just like I said before, putting such simple mechanisms (e.g. palette = modular) would be a no-brainer for me during development.

I'm trying to exploit **every possible property** of both the input and output and remove as much redundancy as possible.

Using modular when there's a palette (either already encoded in the input PNG or detected by JXL encoder) should be a piece of cake.

While using cjxl on a big png I got this error `Command terminated by signal 11`

This is with `-d 0`

it works with default parameters

How big?

3.4GB

Oh, I think you may be running out of RAM...

128GB of ram ?

Ye. On a 233MP PNG image(125MB), the encoder consumes 19GB of RAM already...

69536x22230 pixels

Oof, that doesn't surprise me then. 19GB * 6,6 = 125GB if it rises linearly.

Of course, you can just check how much RAM is used for such a large image.

``` J P E G \/ | /\ |_ e n c o d e r [v0.3.4 | SIMD supported: AVX2,SSE4,Scalar] /home/pedr0/libjpeg-xl-git/src/jpeg-xl/lib/extras/codec_png.cc:726: JXL_FAILURE: PNG decode failed: invalid ADLER32 encountered (checking ADLER32 can be disabled) Command terminated by signal 11 40.24user 7.88system 0:52.47elapsed 91%CPU (0avgtext+0avgdata 14830980maxresident)k 27800inputs+16outputs (9major+7335983minor)pagefaults 0swaps ``` I have no idea how to read this

Png decode failed? Interesting

with `-d 1` ``` J P E G \/ | /\ |_ e n c o d e r [v0.3.4 | SIMD supported: AVX2,SSE4,Scalar] /home/pedr0/libjpeg-xl-git/src/jpeg-xl/lib/extras/codec_png.cc:726: JXL_FAILURE: PNG decode failed: invalid ADLER32 encountered (checking ADLER32 can be disabled) Read 69536x22230 image, 16.1 MP/s Encoding [VarDCT, d1.000, squirrel], 32 threads. Compressed to 290998414 bytes (1.506 bpp). 69536 x 22230, 1.31 MP/s [1.31, 1.31], 1 reps, 32 threads. 839.76user 483.07system 21:29.28elapsed 102%CPU (0avgtext+0avgdata 73100520maxresident)k 56448520inputs+568456outputs (5984878major+79547645minor)pagefaults 0swaps ```

Looks like a bug in something

What does -d 0 -s 3 do?

It might be something related to tree learning not expecting that much data, or something

`-d 0 -s 3 ` ``` J P E G \/ | /\ |_ e n c o d e r [v0.3.4 | SIMD supported: AVX2,SSE4,Scalar] /home/pedr0/libjpeg-xl-git/src/jpeg-xl/lib/extras/codec_png.cc:726: JXL_FAILURE: PNG decode failed: invalid ADLER32 encountered (checking ADLER32 can be disabled) Command terminated by signal 11 40.15user 9.23system 0:53.08elapsed 93%CPU (0avgtext+0avgdata 14831192maxresident)k 64inputs+16outputs (0major+7336001minor)pagefaults 0swaps ```

<:Thonk:805904896879493180>

It doesn't look like it runs out of memory, must be something else

Maybe run it in gdb to get a backtrace?

This is beyond my skills

it *should* work even on an image that big.. lossless uses a lot of memory, but...

you could do `gdb --args <command>`, or maybe share the PNG in an issue on the repo 🙂 it might be that some place is assuming that something like #pixels will fit in 32 bits

``` [6 days since last crash.]$ gdb --args cjxl -d 0 -s 3 heic1502a.png heic1502a_ll.cjxl GNU gdb (GDB) 10.1 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from cjxl... (No debugging symbols found in cjxl) (gdb) ```

Type `run -d 0 -s 3 ` and the other args

``` Thread 1 "cjxl" received signal SIGSEGV, Segmentation fault. 0x00007ffff755078c in __memmove_avx_unaligned_erms () from /usr/lib/libc.so.6 ```

I guess a cjxl with debug symbols would be more helpful 😅

What would I have to change in the build process to keep debug symbols

I'm assuming it would be something with cmake

Compile with `ci.sh opt` (or even `ci.sh debug`)

oh this is easy

for once

well, I get the same result from gdb with a build done using `ci.sh debug`

Can you print a backtrace?

`bt`

too long for discord

Looks like it crashes while loading the png, hm

That apng loading code is likely very buggy, I quickly hacked that just to have something to try animation

The regular png loading code has already failed because the checksums are wrong or something

Maybe try converting the png to ppm before encoding, maybe the ppm loading code is less buggy :)

if I do that how would I keep the srgb data ?

What color profile does the image have?

cjxl will assume ppm to be sRGB, but you can tell it it's something else

`sRGB IEC61966-2.1`

It worked with the ppm

Cool

We should get rid of the apng loader and improve the regular png loader to also do apng (and to not care about wrong checksums)

Cool with `cjxl -d 0 -s 3 -x icc_pathname=heic1502a.icc heic1502a.ppm heic1502a.jxl` I can get my unreadable jxl file with proper srgb

I mean I think

How is compression compared to png with that one?

I can't actually check

png 3.2GB jxl 2.8GB

But I have no idea as to how much compressed the png actually is

All I know is that the ppm is the same size as the source psb which is weird

You don't need to add that icc, it should be equal to the default cjxl will choose when getting ppm input

PSD/PSB can be just uncompressed

It probably is, if that's a photo

its this https://esahubble.org/images/heic1502a/

The compression in PSD is just simple RLE, which is only useful for nonphoto

Oh, you're trying that one at full res? Courageous 😅

At slower speed settings you might be able to trim off some more bytes, but it will likely take quite a while and lots of memory

For lossy, just the DC of that image is a 8692x2779 image, i.e. cannot fit it on an 8K screen 😅

Definitely a case where progressive DC is useful :)

Just made an issue #188 about that. https://gitlab.com/wg1/jpeg-xl/-/issues/188

So, is it actually possible for an image to become undecodable?

I seem to have a few lossless image that I can't decode anymore with JXL 0.3.5 🤔

It's specifically this one.

I can't also decode this image: https://cdn.discordapp.com/attachments/565354601449127957/824508390457344002/SNCE8P_2021-03-13_21-45-41_s9.jxl Both were encoded with JXL 0.3.4 modular lossless -s 9 -I 1.0 -E 3.

> Read 9124493 compressed bytes [v0.3.0 | SIMD supported: AVX2] > Done. > 6668 x 3840, 11.80 MP/s [11.80, 11.80], 1 reps, 4 threads. > Allocations: 4099 (max bytes in use: 9.642420E+08)

I have 0.3.2 I think? **OH WOW I'm dumb it shows my version right there (0.3.0)**

and it worked for me

If you can, update to 0.3.5.

That might have either been an encoder bug(rather low), or perhaps a decoder bug introduced with 0.3.5? I am not sure. I will check tomorrow.

Recompiled from the latest git, now it fails: > ❯ djxl SNCE8P_2021-03-13_21-45-41_s9.jxl decode.png > Read 9124493 compressed bytes [v0.3.5 | SIMD supported: AVX2,SSE4,Scalar] > Failed to decompress to pixels.

You can create weirdly undecodable images with jxl_from_tree. ```if y > -1 - Set 0 if y > 0 - Set 0 - Set 0```

Hmm, why is that undecodable?

Good question.

Also fails for other fairly arbitrary values with the same basic structure: ``` if y > 25 - Set 0 if y > 100 - Set 128 - Set 255 ``` fails, ``` if y > -999 - Set 255 if y > 999 - Set 128 - Set 0 ``` fails, ``` if y > 0 - Set 0 if y > 1 - Set 0 - Set 0 ``` fails, etc.

Not exactly arbitrary, since they all cause illogical branches.

I only picked the values I did because in this case the illogical branch shouldn't actually need considered.

Oh I guess it detects the tree has unreachable branches, and assumes the bitstream is corrupt (a normal encoder would not produce branches that are logically unreachable)

How are there unreachable branches?

Oh, negative y.

I guess assuming corruption is sensible behavior. But it's ironic that jxl_from_tree encodes the file just fine (or at least doesn't complain).

I think it only does not complain in release builds. In debug builds it does complain.

Iirc

Waking up, need coffee first

You could also complain about inner nodes in the tree with two identical subtrees.

Or inner nodes which have all identical leaves.

They could still have different histograms though, even if they have same predictor/offset

Right, only when the leaves are exactly identical.

It shouldn't be. I will investigate later

OK the illogical tree thing is indeed djxl assuming corruption: ```../lib/jxl/modular/encoding/ma.cc:1064: JXL_FAILURE: Invalid tree ../lib/jxl/modular/encoding/ma.cc:1136: JXL_RETURN_IF_ERROR code=1: DecodeTree(br, &reader, tree_context_map, tree, std::min(tree_size_limit, kMaxTreeSize)) ../lib/jxl/dec_modular.cc:169: JXL_RETURN_IF_ERROR code=1: DecodeTree(reader, &tree, tree_size_limit) ../lib/jxl/dec_frame.cc:223: JXL_RETURN_IF_ERROR code=1: frame_decoder.ProcessSections( section_info.data(), section_info.size(), section_status.data()) ../lib/jxl/dec_file.cc:159: JXL_RETURN_IF_ERROR code=1: dec_ok Failed to decompress to pixels. ```

jxl_from_tree is not really a serious tool, making it complain could be done but it's not a priority imo

ok looks like we have a regression in 0.3.5

a decoder bug

getting a bunch of ```./lib/jxl/modular/encoding/encoding.cc:463: JXL_FAILURE: Truncated input ../lib/jxl/modular/encoding/encoding.cc:490: JXL_RETURN_IF_ERROR code=1: dec_status ../lib/jxl/dec_modular.cc:284: JXL_FAILURE: Failed to decode modular group ../lib/jxl/dec_frame.cc:575: JXL_RETURN_IF_ERROR code=1: modular_frame_decoder_.DecodeGroup( mrect, br[i - decoded_passes_per_ac_group_[ac_group_id]], minShift, maxShift, ModularStreamId::ModularAC(ac_group_id, i), false) ```

ok I found the problem, for now don't use 0.3.5 because both encoder and decoder have the bug

it's a specialized code path (for faster decode) that appears to be not quite exactly equivalent to the generic code path, causing trouble (which went undetected by roundtrip tests because encoder and decoder both use the same buggy code)

Is everyone affected or just those using "fast decode" path?

me that i encoded 86 instagram images with modular

it potentially affects everyone

so don't use 0.3.5 for now

Quick fix is to let TreeToLookupTable in lib/jxl/modular/encode.h just immediately return false

Sorry everyone, this is the 'bleeding' that sometimes happens at the bleeding edge

I reviewed that code and didn't spot any problem, still don't see it.

maybe we should announce this more widely, should we put a warning at the top of the description of the 0.3.5 release or something like that?

yes

it should be a simple fix once the bug is found

so let's also do a 0.3.6 with the fix today

luca found the bug

https://tenor.com/view/cute-little-find-cute-discovery-mantis-wildlife-exploration-gif-19052417

added a warning to https://gitlab.com/wg1/jpeg-xl/-/releases/v0.3.5

bug is fixed in the private repo

tbh that's not very good testing if it doesn't include all of implementations (not only optimized ones)

but, well, i guess even in all of impl cases bug could be in some encoding/decoding routines if used symmetrically

yes, well we're adding a test to use the slow path on encode to check that the fast decode path also works there, that would have caught this one

but the more fundamental way to test such regressions is to have a corpus of jxl bitstreams and reference decodes and check that they still decode to something close to the reference decode

For anybody who wants to download the 0.3.4 release, here's how to do it: `git clone --branch v0.3.4 https://gitlab.com/wg1/jpeg-xl --recursive`

Shouldn't it be `lib/jxl/modular/encoding/encoding.h`?

yes, I was going by memory there

When is next sync?

<@!604964375924834314> could we do a sync today? the bug in 0.3.5 is severe enough to get a fix out quickly imo (bad bitstreams might get produced otherwise)

yep, SG

is the new version gonna be called 0.3.5.1 🤔

Nah just 0.3.6 is ok I think

"0.3.5 Hotfix version"?

sounds more rather than less confusing if there is a 0.3.5 that can be used and one that cannot

Just override the old release silently? <:ugly:805106754668068868>

0.3.6 is out with the fix

Thanks for the quick action!

Better not to silently fix things when there was an encoder bug that could lead to bad bitstreams.

Building for Windows on AppVeyor already finished. 🆒

The AppVeyor link in the <#822120855449894942> could actually be shortened to https://ci.appveyor.com/project/EwoutH/jpeg-xl

Yep (that was my initial suggestion, because the link to Artifacts is not universal)

*Et voilà.* It's a bash script that relies on OptiPNG's palettization (if it's not installed, it fails silently and falls back to VarDCT). That's a band-aid, but it should kinda work. `cjxl_auto.sh` ```bash #!/usr/bin/env bash for file in "$@"; do if [ ! -f "$(dirname -- $0)/cjxl" ]; then echo "ERROR: cjxl not found in directory." exit 1 fi read -p "Enter VarDCT parameters [default: none]:" params if [ ${file##*.} != "png" ]; then echo "ERROR: $file is not a PNG file." else if [ ! -f "$file" ]; then echo "ERROR: $file doesn't exist." else if file "$file" | grep -q colormap; then for i in {9..3}; do $(dirname -- "$0")/cjxl "$file" "${file%.*}.jxl" -m -s $i -g 3 -E 3 --palette=1024 if [ -f "${file%.*}.jxl" ]; then break fi done else cp "$file" "${file%.*}.tmp.png" if [ -f "${file%.*}.tmp.png" ]; then if command -v optipng &> /dev/null; then optipng -o1 -silent "${file%.*}.tmp.png" fi if file "${file%.*}.tmp.png" | grep -q colormap; then for i in {9..3}; do $(dirname -- "$0")/cjxl "$file" "${file%.*}.jxl" -m -s $i -g 3 -E 3 --palette=1024 if [ -f "${file%.*}.jxl" ]; then break fi done else $(dirname -- "$0")/cjxl "$file" "${file%.*}.jxl" $params fi rm "${file%.*}.tmp.png" else $(dirname -- "$0")/cjxl "$file" "${file%.*}.jxl" $params fi fi fi fi done ``` *(**note:** I normally use tabs in my code but I had to convert to spaces because stupid Discord can't change tab width)*

I'm not sure I understand what it does exactly

what is this palettization thing?

Does it create pallets for image that don't have ones ?

Yep

then it test every speed ? `-s $i`

that's got to be slow

No, it's actually for weaker PCs

If `-s 9` fails due to lack of RAM, lower effort is chosen

oh

The loop breaks when it detects a JXL file

oh right yeah ```sh if [ -f "${file%.*}.jxl" ]; then break fi ```

Just a suggestion. With a flag or something cjxl could write output file automatically with jxl extension. I think it will save sometime on typing. like if I type `cjxl -w image.png` , it should encode to image.jxl .

I guess it could make sense to do that by default, and have an option for benchmarking if you really want to encode without writing anything

What if I wanted to do something like `cjxl a.png b.jxl` for whatever reason?

If the output file is specified, it should be used IMHO.

yes, this would be just for the case when the output file is omitted

I wonder what to do if the output file already exists btw

currently we just silently overwrite

which is probably ok (a lot of tools do that)

Just silently overwrite like imagemagick?. I think it's harmless

but if we also do implicit output files, it might be a bit more problematic because we're possibly overwriting a file whose filename wasn't even mentioned

in particular, what if we also let `djxl a.jxl` automatically save the result to `a.png`

then `cjxl a.png` followed by `djxl a.jxl` would replace a.png with a lossy copy of itself

Or do something like this ?

nhw encoder bad

Hmmm. I'm thinking about possibilities like adding suffix to the decoded image

why, i dn't want it.

Only if output file was not specified

Is that a problem?

to me yes

How?

and for software makers

Two days ago we discussed that it might be important for users to find out whether (frames of) jxl files are stored losslesly or lossily. Shall I submit an issue not to forget to implement it in libjxl (and jxlinfo), or will it happen "itself"? 😄

itself = one of core devs takes care of it, based on the discussion here

We don't know if a frame is lossless or lossy, only if it's vardct or modular

Even Modular frames can be lossy

<@!794205442175402004> if the encoder uses lossy modular (`-m -Q`) or lossy palette, does the decoder know about that? Is that indicated at all in the bitstream?

I know. But you mentioned that it's possible to guess that it's lossless if it fulfils certain conditions. So showing at least vardct/modular would be cool and showing a good guess of being lossless would be even cooler. 🙂 With current formats, advanced users know what's lossless and what's lossy. So the goal here would be to give them this piece of info as well, not to deprive them of something they're used to.

The modular bitstream signals what transforms where used. There are only 3 transforms, but they have parameters and you can potentially do them multiple times (with different parameters). The 3 transforms are RCT, Squeeze, and Palette.

Squeeze and Palette can be used in a lossless or in a lossy way.

From the decoder's point of view, there is no difference though.

Default lossy modular does a default Squeeze transform, and then quantizes the residuals (it does that by dividing them by a constant per zoomlevel/channel, and by setting that constant as the multiplier in the MA tree, with the zero predictor). You could investigate the tree to see if there are leaf nodes with multipliers, since that could indicate lossy compression (but technically you could also do lossless compression using multipliers).

Default lossy modular also uses XYB instead of RGB, which is a non-reversible color transform so an indication that it's lossy

(but you could do non-default lossy modular in RGB too)

In short: forensically, knowing what the current encoder does, you could make an educated guess about whether something is lossy or lossless. But you cannot know for sure.

It's the same in other formats btw.

If I give you a PNG8, how can you tell if this is a lossless image that just happens to use only 256 different colors, or the result of e.g. pngquant on what was an image with many thousands of colors?

The difference is WHEN the lossy transform happens: Either before, or during encoding. Experienced users use lossless formats for lossless content and lossy for lossy.

If someone uses pngquant (I love this tool BTW) then the compressibility improves, no nasty DCT-like artifacts are introduced and everyone is happy. The result is perfect for storing losslessly. And I wouldn't hesitate to call it a lossless content.

Converting it to jxl losslessly makes perfect sense. Lossily… doesn't.

Pngquant doesn't introduce dct artifacts, but try it on an image with many color gradients and it will not look so great...

Lossy format for lossy content not make much sense

default pngquant output...

I would hesitate to call that lossless content

default cjxl

Try pingo -pngcolor or -pngfilter ?,can keep RGB24 or RGBA32

I know, most optimizers will do that, just saying color quantization is a lossy operation

without the dithering it can be even ridiculously lossy

artistically lossy, in a way

My mistake in formulation, sorry. I mean lossy for photos.

In case of quantisation, it depends on type of input. Many images are very suitable for pngquant.

Some people believe pngquant(pal8) can get visual lossless <:FeelsSadMan:808221433243107338>

I saw some anime content site using webp lossy and png pal8, break every drawing content...

It depends on the input. My point was: given a png8, you cannot really know if it is lossy or lossless.

Even given a png24, you cannot really know. You can do "near-lossless" techniques with png24, and you can crank them up to visibly lossy...

Just hope we can get jpeg xl fixed vardct to convert every drawing content 🙂

Of course, all operations including quantisation should be used when they make sense.

Avif like Vardct on anime on d 4 and for me jxl is the definitive format

Or lossy palette generation with on-canvas color mixing

Yes, a jxlquant would be quite great. Make a palette of the most common colors, use delta palette entries and implicit palette colors to do the remaining colors. That will likely be very good for high-fidelity lossy anime-like images.

``` /home/pw/git/jpeg-xl/lib/profiler/profiler.cc: In constructor ‘jxl::Results::Results()’: /home/pw/git/jpeg-xl/lib/profiler/profiler.cc:151:42: error: ‘void* memset(void*, int, size_t)’ clearing an object of non-trivial type ‘struct jxl::{anonymous}::Accumulator’; use assignment or value-initialization instead [-Werror=class-memaccess] 151 | memset(zones_, 0, sizeof(Accumulator)); ```

Hmm, checked out again and built again, and now it works.

Nvm, I guess.

How do I build jxl_from_tree ?

https://discord.com/channels/794206087879852103/824000991891554375/825331280236380180

Dank.

That's Dutch for "thanks", by the way.

I guessed from my (very limited) knowledge of German 😛

Me too, it's really similar word "core" among many Indo-European languages, who wouldn't guess 🙂

Somehow I never actually heard a Dutch person use it though <a:Sadd:821038588346892368>

It's more common to say "bedankt" (thanked), or "dank u"/"dank je" ("thank you"), or "dankuwel"/"dankjewel".

But that's less funny to use in an international chat.

Ja stroopwafel

My favorite ridiculous Dutch word is probably klokhuis (the center part of an apple, literally "clock house") or boterham (a slice of bread, literally "butter ham").

Hagelslag ;)

You win.

Smeerkaas

Keukenrol <:kekw:808717074305122316>

Hmm, what's funny about smeerkaas?

It just sounds weird

Ok!

Also, pik zwart <a:ThinkingSphere:821038590091329557>

Dat was denk ik oorspronkelijk pekzwart

Zo zwart als pek dus

Pikfuif en fuifpik klinken allebei even slecht. Ik ben blij dat het JPEG XL is geworden 😅

How difficult would it be to add a version (and possibly other metadata) to Windows binaries of cjxl, djxl and others? Of course it's not the most important thing in the world. I'm just curious.

example:

I guess we could also add an icon. Someone who knows how to do that should update the build script for windows

ResourceHacker can do that, but I don't know about automating it

An icon with 16x16, 32x32 and 48x48 images inside.

To add version information, icon or other resources, an *.rc file should be created and compiled using rc compiler, and the result should be passed to a linker with other object files.

What toolkit is used for building jxl tools for Windows?

Seems like it is worth to play a bit with alpha channel to make 16x16 version a bit better.

Sorry, but you used the old icon design. The new libjxl icon was changed a few weeks back. The official one is now: <:Xjxl:822166843313225758>

`XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX` ` XXXX\\\\\\\\\\XXXX XXXX//////////XXXX` ` XXXX\\\\\\\\\\XXXX XXXX//////////XXXX` ` XXXX\\\\\\\\\\XXXX XXXX//////////XXXX` ` XXXX\\\\\\\\\\XXXXXXXX//////////XXXX` ` XXXX\\\\\\\\\\XXXX//////////XXXX` ` XXXX\\\\\\\\\XX/////////XXXX` ` XXXX\\\\\\\XX///////XXXX` ` XXXX\\\\\XX/////XXXX` ` XXXX/////XX\\\\\XXXX` ` ///////////XX\\\\\\\XXXX` ` /////////////XX\\\\\\\\\XXXX` ` //////////////XXXX\\\\\\\\\\XXXX` ` XXXXXXXXXXXXXXXXXXXXXX\\\\\\\\\\XXXX` ` XXXX//////////XXXX XXXXXXXXXXXXXXXXXXX` ` XXXX//////////XXXX XXXX\\\\\\\\\\XXXX` ` XXXX//////////XXXX XXXX\\\\\\\\\\XXXX` `XXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX`

Where is a huge version of this icon?

Should be in the dev repo, but here you can also get it: https://res.cloudinary.com/mattgore/image/upload/v1617230369/jxl_bi_black_cyan.svg

Yes, that's probably not necessaryy for the smallest versions.

Luckily .ico supports different images for each size.

OK, I'll make a small icon from it tomorrow 🙂

👍

Here's my attempts to make some icon files from that SVG. I've made two versions: one with anti aliasing, and one without. The anti aliased version is larger in file size.

Contains 16x16, 32x32 and 48x48 icons.

Is this some April fool joke? Where was it discussed?

Oh, I forgot that it 1st of April and believed it 😆

yup, I started looking into this recently but it’s not yet ready (I think we would like not to have to update the version number in 500 different places when we bump it, so the build files should pass it to the .rc as a preprocessor argument)

having this .ico there would be great, not sure of the legal implications regarding copyright

That's up to <@404585766799278081>. The base image is CC0 so that's no issue.

No worries, I keep forgetting that the CC0 license doesn’t apply to derivatives automatically! I’d like them to be under the CC0, as the original image was.

I heard JPEG XL version 2034 was released today with the most notable feature being that is creates your image from thought. Just just open a directory and think of the image you want and it creates it and saves it in that directory.

I heard that JPEG XXL decided to borrow some ideas from Brotli - the decompressor now includes a database of some of the most popular images on the web, so the .jxxl file just needs to specify which of these images it should decode to.

Yes, the decoder is 5 TB and contains an initialization dictionary consisting of mostly cats but also some celebrities

as a result the movie cats (2019) is actually more efficient to represent as an animated jxxl than av1 or vvc

Btw, this is not far from reality (except it uses a ~1 GB trained model required for decoding, if I am not mistaken): <https://hific.github.io/>

Don't worry, if 5 TB is too much there is also a version that can determine which emoji is closest to your image and output your image as unicode.

I have forgotten how to count that low.

Googler, I assume?

👍

are you / have you been, too?

I was an SRE 2012-2014.

oh, cool

SRE?

site reliability engineer

devops in google-speak, i guess

we have an internal joke around serving 5TB and my quote on forgetting to count that low

https://www.quora.com/What-s-an-inside-joke-among-Google-employees/answer/David-Seidman

Does borgmon still exist?

as far as I know, it does

https://cloud.google.com/blog/products/devops-sre/welcome-to-the-museum-of-modern-borgmon-art has rather interesting images, by the way

<@604964375924834314> Pretty sure I've seen most of those already. Maybe it wasn't public until recently, but I do recall a museum of borgmon history from 2014.

Good news everyone! The latest build of Chrome Canary has the JPEG XL library!

Cool!

https://tenor.com/view/futurama-professor-new-goodnews-gif-5110959

Imagine if you wrote Firefox instead <:kekw:808717074305122316>

And coming to firefox in the summer... of someday™️

*downloads firefox nightly*

Firefox hasn't even started work on it, so I wouldn't hold my breath

Yeah. Unless I become a good Rust/C web dev overnight, you won't see JXL support for a bit.

Is the expired flag thing no longer an issue?

No, the expired flag is still needed for 92.0.4475.2

https://chromium-review.googlesource.com/c/chromium/src/+/2818169 > *Extend expiry_milestone for flag enable-jxl.* > **Merged** as __bb58f59__

I think that Mozilla will start to work on it when JPEG XL is released and reference implementation reaches version 1.0.

It is understandable why Google jumped in so early, because it is involved into JPEG XL development.

Well, let's skip straight from 0.5 to 1.0 then <:megapog:816773962884972565>

For example, APNG support was added to Chromium in 2017, 9 years after it was created and supported by Mozilla (in 2008).

Seems like it was one of the reasons (in addition to "WebP isn't actually always better") why Mozilla didn't support WebP for long time.

Google adds APNG support in 2017, and Mozilla adds WebP support not so long after.

According to JPEG XL, I think that Mozilla won't have anything against, and will support it after it is considered to be "ready".

there is no valid reason that they don't enable it in their to do list.

is there any timeline on when the development repository will be fully public (instead of being synced now and then)?

We need to get Alex on the discord again so he can update us on that...

Why did he leave?

I don't think he ever really joined

Yeah he never came in the 1st place 😛

First place has always been Jon

i guess i just want to play with the new jxl_from_tree :P

why is the repo private anyway?

ISO rules when the spec is not ready yet

So waiting for IS in June?

We needed to allow the possibility of contributors making closed source contributions (even though nobody wanted that, but ISO rules say you have to allow it)

No, we can do it now, I think

Just some practical things to arrange, like setting up the CLA bot and stuff

I think that improving the code itself is more important right now

ouch 😄

Hello everyone, I've been having a quick stab at adding libjxl support to libvips https://github.com/libvips/libvips/pull/2181 I was wondering about chunk read and write, ie. reading and writing images in a series of small chunks of pixels, rather than all at once I don't see the API for this, is it possible or planned with libjxl? I'm probably just being dumb

It is possible with the bitstream, but not so easy, and not yet implemented, let alone exposed via the API

ah ok, thanks I'll leave that on the TODO for now then

AC tiles are 256x256, DC tiles are also 256x256 which corresponds to 2048x2048 in the image

that sounds promising, so at least 2kx2k tiles should be supported at some point?

Making an encoder that encodes a 2048x2048 at a time should be doable, if you don't care about global optimization of the entropy coding

libvips is used with huge images (>200,000 x 200,000 pixels), so chunkwise read and write would be a very useful feature for us, yes