JPEG XL

I hope I can use jxl format like this order, for some legacy platform. > `png RGB24`(adobe icc profile) [encode]-> `jxl XYB,varDCT` [decode]-> `png RGB24`(adobe icc profile) > (decode png preserve original adobe icc profile)

Isn't adobe rgb 1998 representable as an enum space? Maybe we just need to improve our enum detection, then libjxl can produce pixels in the right space without cms.

But also: https://github.com/libjxl/libjxl/pull/2002

Probably can add a flag to preserve original icc profile?, even pixel already apply XYB transform, preserve original icc profile file in jxl file, but don't affect jxl render. > --use_original_profile or --preserve_original_profile

For some special use case, I still hope can preserve original icc profile.

The original icc profile is always recorded, either bit-exactly or by using an equivalent enum representation of the same colorspace.

What is enum?

There are two ways to signal the colorspace of an image: either a (compressed) icc profile, or using the enum. The latter means setting primaries, white point and transfer curve based on header fields. It is very compact (common spaces can often be done in less than one byte) but less expressive than full icc profiles.

Is there a limit to how complicated the transfer function can be before you have to use an ICC profile?

And is it limited the three primaries?

The primaries can be anything not too imaginary, the transfer function is either any gamma (exponential) function, or one of the specific ones: sRGB, rec709, HLG, PQ

Ah, so not an arbitrary function.

Common primaries like the sRGB or bt2000 ones have a short code

Makes sense, given they can't be represented with gamma.

sRGB primaries + tf is represented as just one bit

Nice.

yea, it's D65 white point, RGB would require custom primaries, and I believe it's got a gamma transfer of 563/256, which is almost 2.2 but not quite

here's the Adobe RGB spec:

https://www.adobe.com/digitalimag/pdfs/AdobeRGB1998.pdf

in particular, this ^

animated PNG has a "base image" that may or may not be the first frame of the animation

what does libjxl do when decoding animated JXL to animated PNG?

with regard to the base image

I can see a transparent canvas or a first-frame canvas as both being viable options

That's not really a libjxl question but rather how the apng encoder in djxl works. Should be first frame as base image.

ah good point, but thanks 👍

It would be nice if I could install libjxl as system libjpeg in arch linux

Is this a possibility?

Also is libjxl libjpeg really better than mozjpeg?

that's what jpegli is (iirc), and once someone makes an AUR package you probably could

it's jpeg decoding in libjxl via jpegli? https://github.com/libjxl/libjxl/pull/2026

Maybe this question is controversial or something but... Any particular reason why this is written in C++ and not C? It always kinda stood out to me from the beginning.

Maybe because Google likes writing stuff in trendy C++ like the PIK codebase that libjxl is based on?

I feel like some people (i.e. not me) just prefer C++ over C because of its features. If you want an implementation (albeit incomplete) written in C, see: <https://github.com/lifthrasiir/j40>

That's the problem with C++ though. Too many features.

That's the whole reason to avoid it.

I don’t disagree.

I feel like C projects are always more readable.

I don't find Rust very readable no.

Personally

I feel like we’re quickly getting into “not a subject for this channel”, but I feel like readability comes (among other things) from familiariy. And I’m not the kind of person who is into Rust at all.

Same question when looking at the Stockfish codebase. The code is beautifully organized for a C++ program and well written with the expressed intent of being inviting to new contributors but I feel like it would still make more sense and be more inviting or readable to newcomers if it was written in a simpler language than C++

that's what <#806898911091753051> is for 😉

There is a fork called Cfish which if you compare the code to Stockfish looks way more approachable despite the effort put into making the Stockfish code look so nice and neat

Well the question is specifically related to libjxl in particular but if you don't think this is the right subject to talk about in this channel I will say no more lol.

By the way thank you veluca for your encoder wizardry

You're an excellent engineer

I don’t know, I’m not the one who should decide that! At any rate, it is possible that there are dependencies of libjxl written in C++, so that might have helped make the choice.

I think it's just a Google thing.

There are far less features in C so far less likely to come across something unfamiliar or unexpected.

I don’t disagree!

The libjxl codebase was clearly adapted from the PIK codebase used as a template. That's why it has a lot of dependencies and is written in C++.

Also I am looking at the FUIF list of features and I have to wonder what does JPEGXL add to FUIF? FUIF seems to have all the same capabilities.

in particular the lossless reorganizing of existing JPEG data and the emphasis on progressive loading

Hmm, also, I just tried the HEIC encoder used in Gwenview and I am absolutely blown away by the quality of the lossy compression and the preservation of small detail and subtle variation in color.

Which codec?

I assume Gwenview is using kimageformats which is using libheif which is using x265 for the encoding. It's completely mind-bogglingly amazing how good it looks.

It makes AVIF look ridiculously ugly

I don't know what settings or what encoder Gwenview is using thru kimageformats -> libavif

But the chroma looks completely awful and everything looks like absolute perfection with x265

x265 looks as good as JXL or maybe even a little better at the same filesize needed to achieve flicker-test transparency.

I'm really impressed it looks that good

XYB, ANS, lz77, several predictors (weighed, select, ...), having a predictor per context node, more RCTs (fuif had only YCoCg), variable dct (and everything that comes with it), groups (so parallel/cropped decode), layers, icc compression, ...

Several of those things weren't in pik either btw, and were added during the collaborative phase of the standardization process

Well, default settings, which are certainly suboptimal.

Good answer, thanks. I thought FUIF also has DCT too

I think it did but only 8x8? (but <@794205442175402004> ought to know)

Yes, it had dct8x8, just for jpeg recompression

And it did it in a very funny way

Turning every channel into 64 channels with 1:8 subsampling, one per coefficient 🙂

It didn't recompress jpegs as densely as current jxl, but it still did get like 15% improvement over jpeg

I am not familiar with libavif but why would the default settings be so awfully poor and unfit for human eyes?

I'm sure AVIF has the theoretical potential to look as good as x265 maybe. But no one would be able to discern that from using it in its current state :)

It's hard for me to find good comparisons but I was under the impression AV1 is supposed to have more potential.

tbf libjxl also has significantly more potential as a JXL encoder

if I recall Jyrki said that there were a number of things they were going to try, but they wanted to prioritize stability first

and a 1.0 release first

I'm aware of that and I'm also aware of how x265 and x264 are optimized to the extreme.

x265 is not as good at encoding HEVC as x264 is at encoding H.264

x264 is legendary

x265 still has room for improvement (more so than x264) but it's sort of stalled at this point since HEVC is sort of intermediate

h.265 never had a lot of widespread interest. The patent situation resulted in widespread unattractiveness that nobody outside of Apple were interested in

So it's no surprise that x265 was not as successful

we don’t currently try to fit a gamma to the transfer function, but we could hardcode a few predefined gamma values to try including the aRGB one

(or actually implement gamma fitting)

But still, x265 produces stunningly good output, at the very least as good as libjxl 0.7

And libavif, whatever encoder or settings its using, looks like a trainwreck

if the gamma transfer function is a pure gamma curve, would you have to "fit" to it? I'm unfamiliar with how ICC profiles implement pure gamma

ah, right, it’s probably encoded as a parametric curve in some cases

but I don’t know if our current code is structured in a way that lets us easily access it as such

notably it doesn't have a linear segment, so it can be represented by the GAMMA enum value

in theory

at some level, we have lcms2 and skcms abstracted away, and the abstraction might be before we verify whether an enum is a suitable approximation

probably a post-1.0 goal though

according to Jon, the DCI transfer is pure gamma 2.6 so I wonder if that one can be auto-detected as well

Because aomenc is a video encoder first, image encoder second. When building avifenc, they didn't think of setting better defaults for it. Also, what aomenc version do you have on your system? That matters a decent bit as well, especially for speed.

Also, an interesting thing about x264 and x265 is that when dealing with 4:4:4 images, they increase the chroma quant by 6.

aom 3.5.0

You would not be crazy to assume that libavif should have sensible defaults for images.

It's pretty shockingly ugly considering how far along AVIF adoption has been pushed already

There is a bug report on Krita about failed to open a certain JXL art: https://bugs.kde.org/show_bug.cgi?id=463914 After further self investigating, apparently it fails to decode as well even on recent libjxl main.

Here's a log from Krita callstack: ```./lib/jxl/splines.cc:637: JXL_FAILURE: Too many pixels covered with splines .\lib\jxl\dec_frame.cc:290: JXL_RETURN_IF_ERROR code=1: shared.image_features.splines.InitializeDrawCache( frame_dim_.xsize_upsampled, frame_dim_.ysize_upsampled, dec_state_->shared->cmap) .\lib\jxl\decode.cc:1182: frame processing failed```

Hm, works in old decoders, but doesn't seem to work in new ones

Yep, I found out that as well, can be opened with GIMP 2.10 but failed at 2.99.14

v0.7.0 198d5f3 (2021-12-20) doesn't work, but v0.7.0 d503419 (17-12-2021) works

At some point we reduced the limit on spline pixels

We might need to bump it up again

``` Deal with over/underflows in spline coordinate calculations. Outrageous spline coordinates / deltas hint that stream is corrupted -> stop decoding. Drive-by: limit total spline area to avoid memory / CPU bomb Drive-by: replace spline_on_first_frame test sample with one that fits new limits Drive-by: fix spline_test: JXL_ASSERT is no-op in Coverage build... ```

``66f363b0a77dc428bb56234825352f3378ed909d`` guess that one broke it

We need to define limits for the total spline area for level 5 and for level 10 in a way that balances expressivity and decode resources.

I would propose something like max 2 spline pixels per frame pixel, with a large additive constant to allow some more for small images.

Seems to be a long regression or saved for a future plans~ Anyway, shall I open a issue tracker on github as well so that I can pass this to Krita's core devs?

can you link the sample?

https://jpegxl.info/art/2021-08_totocaca.jxl

Seems like the same issue I was running into in <https://discord.com/channels/794206087879852103/803574970180829194/1060953757174747327>

I've noticed the effort level 10 was added in cjxl. What does it do in addition to effort 9? Does it include the proposed options -E 3 -I 100 -g 3 ?

From what I have seen (and it’s not like I know much), it tries various different settings and picks the best one. See: <https://discord.com/channels/794206087879852103/803645746661425173/1060222052067450920>

I'll give it a try. Anyway, I couldn't find any overview what settings are different effort levels using. It seems the individual steps are checking the effort level directly.

Yes, they are all just entirely different algorithms being chosen. The number’s value isn’t actually used by a unified algorithm or anything, it’s just meant as a general “this is slower or faster” indication.

But note that `-e 10` is much slower than `-e 9`.

I see, in other software the speed preset is acting like a shortcut for bunch of different options. This is just a different approach.

it does include that

How slow is slow? If I do trials using all filter types in PNGOUT, that's pretty slow.

haven't tried pngout, but I can almost guarantee e10 is slower

e10 is ~3h per megapixel on a single core I believe

So that's really slow.

yep

it's more meant for either that one image you really need to optimize as much as possible, or for benchmarks of theoretical compression performance

it could probably be made faster by being a bit more clever than just brute-force trying a bunch of e9 settings

but making e4-e7 faster and better is imo a bigger priority — this is where the pareto front battle is going on 🙂

Agreed, waiting several minutes or even hours to encode a single picture is not something most users would appreciate.

Pngout with trials is more like 5 minutes per megapixel although the speed is very dependent on the image contents and pixel format.

To be fair the image in question is a very contrived example

I mean in response to this

You cannot get a JXL file like that by normal means right now

I think so.. I mean it can be safely dismissed because it's not a normal usage, right?

I mean I'm dismissing it right now and I feel pretty safe.

:)

But sounds like there are plans to tweak the limits anyways to allow that file to be decoded again in the future

Basically the decoder was given tighter limits recently to reduce the impact of a JXL file that is intentionally crafted to take a long time to decode and lock up the decoder as a sort of DOS attack

That's why this handcrafted JXL file that has an unusual usage of splines now has problems decoding on recent versions of libjxl

Since it's getting attention here and the devs are noticing, it's **likely** that soon there will be another patch that alters the limits again and once again allows the unusual image to be decoded in the future.

if you really need the image data from that image, then jxlatte doesn't have a spline restriction in place

although it's not suitable for use as a krita plugin as krita doesn't target the jvm

Probably we should make some limits dynamic and add something to the decode api to set limits. Not sure if those limits should coincide exactly with profiles/levels or be just something implementation specific...

I like this idea. so highly security-sensitive applications (e.g. browsers) would set the settings to be very strict

but an image editor that takes images from a hard drive could be more permissive

Exactly. I'm thinking you might want to have an option to set stricter limits than even level 5, e.g. to set max image dimensions that will fit in limited memory.

Sane limits make sense, you could enforce allocating a buffer of several gigabytes just by loading an empty file with huge dimensions.

I just want firefox to merge the patches already and fix their broken bugs that have already been fixed. And enable it by default without having to use nightly.

But they don't have enough manpower to click the merge button ;(

All the work is already done but they don't have that last little tidbit of manpower required to click "merge"

libjxl is far from perfect and it's getting improved all the time since there's plenty of room for improvement in all areas including speed, lossy quality, api features and exposed settings, etc... But as it stands in its current condition it's ALREADY better than the rest in all of those areas and it's time to start using it now, in my opinion! It's cool to be able to save space, especially on existing JPEGs.

(One feature I personally would really like is a lossless transformation api and tool a la jpegtran.)

I think that jpegli is a very interesting idea. I think jpegli has a lot of potential for getting libjxl deployed

Because it's an improvement and drop in replacement for something that is already widely used and depended upon.

It's a way to introduce libjxl into already existing and common workflows

A very clever and interesting way to pave the path towards increased adoption

Is there a `man 3 libjxl` somewhere online?

Hello wb, Sorry to bother you, I still can't get correct icc profile on djxl output png. expect djxl decode png icc profile is `Adobe RGB (1998)`, but output png icc profile is `RGB_D65_SRG_Rel_Lin`. > png rgb24(Adobe RGB (1998)) > [cjxl encode]-> jxl XYB,varDCT > [djxl decode]-> png rgb24(RGB_D65_SRG_Rel_Lin) > // expect djxl decode png icc profile is Adobe RGB (1998).

original png rgb24 icc profile(Adobe RGB (1998))

Is there a github issue for this? Looks like a bug if the output looks different.

Gamma/TRC wise, that looks like a viewer issue like I've reported before~ something to do with the viewer cannot display linear correctly

But gamut wise, it got clipped into sRGB if it's integer

And actually, it's one of the issues I got when trying to get XYB profile working correctly on Krita's export~ on ICC profiles that's not specified by libjxl, we had to pass parsed parameters from ICC (color primaries, white balance, and TRC/gamma) as custom parameters.

Eg. for parsed Adobe RGB, the profile looks like this after jxl decoding: `RGB_D65_0.639997;0.329997;0.210006;0.710004;0.149998;0.060004_Per_g0.454707`

What's the status of the libjxl GitLab? https://gitlab.com/wg1/jpeg-xl The latest commit is from 3 months ago, but nothing on the page states that the repository has been moved or anything.

Also, from the AV1 Discord (https://discord.com/channels/587033243702788123/673202643916816384/1061578319209975858): https://github.com/google/skia/blob/main/DEPS ``` "third_party/externals/libjxl" : "https://chromium.googlesource.com/external/gitlab.com/wg1/jpeg-xl.git@a205468bc5d3a353fb15dae2398a101dff52f2d3", ``` Skia seems to be using the wg1 libjxl as source

Oh, is the gitlab mirroring broken? That's not good...

Can libjxl be given YUV image data? What happens? Does it handle it well if the chroma channels are at a smaller scale than the luma?

currently we don't have an api for anything other than RGB. It could be done in principle, and at some point (before it used the api) cjxl could take y4m input, but it's currently not implemented and tbh I don't think it's a very big use case

Of course it is? Lots of images are in YUV formats. Like for instance ALL lossy webp sources.

Is there a theoretically ideal way to translate those color formats into XYB?

YUV is probably even more common than RGB data... Of course it's a very big use case...

Lossy webp uses tv range yuv, while jxl/jpeg use full range yuv.

But in any case the only thing you can really do with a lossy webp is keep it as is

If you can avoid needless lossy conversion to RGB, that could result in better quality transcodes

Well, we could be talking about very high quality lossy webp, or other high quality YUV sources like for example taking JXL screenshots from MPV is apparently becoming a popular use case now

If you're going to do lossy transcode, I suppose you could decode to yuv and then to 32-bit float rgb and use that as input, but I doubt this will make much of a difference compared to just using the decoded 8-bit rgb

'high quality yuv' is a bit of a contradiction in terms, imo. In the best case (full-range 444), it is basically rgb 787

In the worst case, it is basically rgb 676 with r and b at half resolution

Is there, theoretically, an "elegant" way, for that kind of YUV data to be translated into the XYB color space without some sort of resampling?

Can it be quantized without actually resampling it I mean

I'm just wondering how efficiently can lossy JXL be used on that sort of data, with minimum unnecessary degradation of quality (since YUV data is already such bad quality already)

converting yuv to rgb (especially high-bitdepth rgb) is not introducing any degradation, really

it's the other way around that is lossy

There isn't something more efficient or ideal that could be done, compared to converting it to RGB (and resampling the chroma channels)?

It seems kind of wasteful to needlessly transform the data like that, before the data even gets seen by libjxl

There isn't a more fitting, more 1:1 transformation that could be done?

Well if it's a jpeg, then it can be recompressed losslessly. Also if it's lossless yuv data (has to be full-range and with the jpeg sample alignment though), that can be compressed losslessly in principle. But if you're going to do lossy transcoding of already-lossy data, preserving the colorspace is not going to make a significant difference and you're kind of screwed anyway imo: if you want to improve density, you'll have to use a quality setting that is sufficiently worse than the quality setting in the original format or otherwise you'll end up wasting bits on preserving compression artifacts; if you want to preserve quality, you'll likely have to use a quality setting that is quite high and that will quite likely result in a larger file than what you started from.

at least for lossless screenshots it would be useful (and probably a little faster), as already discussed https://discord.com/channels/794206087879852103/794206170445119489/1060617474128748554

provided the screenshotting application can somehow access the yuv data — i.e. it would have to be integrated into a video player or something like that

one issue is the sample positioning (cosited vs interstitial)

in JPEG and JPEG XL, subsampled samples are sited interstitially (midway between the luma samples)

while in MPEG-2 and h264 and I suppose many other video codecs, they do something weird where vertically the samples are interstitial, but horizontally they are cosited

Yes, mpv recently added JXL screenshot ability and it's a hot new feature.

Yes, that is what a library like yuvxyb does.

https://github.com/rust-av/yuvxyb

oh wow, that's exactly what I was wondering about

another issue is full-range vs tv-range: in JPEG and JPEG XL, the range for YCbCr is 0..255 for all components, while in BT.601 the range for Y is 16..235 and that for CbCr is 16..240

Anyway, in the case of ffmpeg, that conversion would be done by the libjxl integration.

Yes, which is why integrating proper color metadata information is sooo important. Otherwise, you get garbage. An example of this is when SD DVD sources are converted to HD without including the proper metadata(BT601).

the only yuv we have in jxl is full-range YCbCr with the same conversion matrix as in JPEG, with only 1:1 or 1:2 subsampling in either direction for any component (so you can do 4:4:4, 4:2:2, 4:4:0 and 4:2:0 but not 4:1:1)

yuv of the above kind can be represented losslessly in jxl (and will be rendered correctly)

other kinds of yuv (like tv-range, different matrix, or different sample positions) can possibly still be represented losslessly in terms of preserving the samples, but not at the metadata level so it will not be rendered correctly when decoded

Rust code is not easy for me to read...

basically we only did the minimum needed to do lossless jpeg recompression (covering what is actually encountered in the wild; jpeg in principle allows some more exotic subsamplings but they are not used in practice and often won't work either)

Can subsampled chroma be represented in XYB JXL? Or do you have to use YUV?

you have to use yuv

xyb is always 444

even if jxl would support xyb 420 (which it doesn't), it wouldn't help at all since you can't just map yuv420 to xyb with subsampled x and b

In terms of compression density does it make more sense to keep it YUV with downsampled chroma, do you think? Or would it still be better to store it as XYB?

Even though you would be increasing the size by resampling without actually adding any more detail

Sounds like there's no nice way to map it...

a lot of the chroma blur introduced by yuv420 will translate to blurry X and B which should compress better because there's not a lot of high frequency signal left

some of the Y from YCbCr will still end up in X and B though

so I suppose it depends on the quality: at high enough quality where the 'bleeding' of Y (from YCbCr) into X and B ends up getting costly, it might be better to stay in YUV — just like when doing lossless, it will be better to store it as lossless yuv420 than converting to rgb and storing that losslessly.

at a lower quality though (say recompressing libjpeg-turbo -quality 95 to jxl d2.5), using XYB will be better

Interesting... Naive question but why would there be bleeding?

Hmm, thinking about how these two things map to one another makes my brain hurt. :)

One has a blue channel and a red-green channel, the other has a blue-projection and a red-projection channel...

I guess there would have to be bleeding since in YUV chroma is more dependent on luma?

I wonder if there are any transformations that can be applied to chroma-downsampled YUV content to help make it more efficient to compress...

Chroma subsampling is basically exactly the same thing as zeroing 3/4th of the dct coefficients (the ones not in the top-left quadrant).

In any codec with decent entropy coding, subsampling doesn't give you any compression benefit

In the original JPEG it helps for compression because DC entropy coding is quite bad (fixed West predictor, simple huffman coding, no context modeling), and also AC entropy coding is not that great (no prediction or ctx modeling at all, while for low-freq coeffs, even just simple ctx modeling like one ctx per coeff position does help quite a bit).

Yeah, that makes perfect sense to me, I'm just having trouble thinking about how that maps into XYB coordinates...

I meant to reply to this here or both but ah well

Also if you are encoding a JXL with noise generation, is the encoder smart enough not to waste bits on anything below the noise floor?

That's another question that's been floating through my mind about JXL

Currently not, it just encodes the image like it always does and signals that the decoder has to add noise

It would be better to estimate the noise in the image and carefully denoise it before encoding, but that's a tricky thing to get right.

Well it should just be able to estimate what the "noise floor" is based on the amount of generated noise and then... I dunno, maybe truncate the least significant bits or something?

Or make some sort of informed decisions based on the perceptual "noise floor" of the image.

since that noise will mask some subtle details in the image, it would be prudent for the encoder to not attempt to waste any bits on information that will get masked underneath the added noise

It would be very similar to quantization and dithering.

YUV -> RGB is not a lossy operation

Well 8-bit yuv to 8-bit rgb may be slightly lossy due to rounding, but it's kind of like converting a 7-bit image to an 8-bit one... You cannot do it exactly (e.g. 63/127 is not exactly the same as 127/255), but it's not a big loss either

Well, it is if there is resampling involved...

Upscaling is not a straightforward operation

But I don't know that much about how chroma upscaling is done in practice.

other than the fact it usually looks really ugly

really really ugly

is RGB and LMS any different?

The 'simple' upscaling is just sample duplication which is very bad: A B C -> A A B B C C. The 'correct' upscaling for interstitial subsampling like in JPEG is triangular: A B C -> A (0.75A + 0.25B) (0.75B + 0.25C) (0.75C + 0.25B) C

LMS models cone cell responses, RGB models light emittors.

Well light only matters after our photoreceptors (rod and cone cells) sense them.

Hm, tried ``benchmark_xl --input="D:\Pictures\AI foxes\000007.43688240.png" --codec=jpeg:libjxl:d1.0 --save_compressed --output_dir=./out`` on another device and it doesn't seem to give an output either :/

It only creates an "out" folder

`--output_dir=out`

That gives the same result :p

works for me or `--output_dir=.` same folder

None work for me for some reason

On both W10 and W11

It only creates an empty folder

maybe try a different input file/name? I also use the old Command promt, maybe Terminal or PowerShell works differently

could be that it is confused by the backslashes or spaces in that input file name

try using an input filename that doesn't include the full path

This seems to have been the problem

``benchmark_xl --input=1.png --codec=jpeg:libjxl:d1.0 --save_compressed --output_dir=./out`` worked

Windows using backslashes as a dir separator is very confusing when C uses it as an escape character

Windows just sucks... Always has.

I find it tolerable nowadays

mostly thanks to msys2

WSL is kinda nice but you need a linux filesystem image.

and most distros don't distribute those, you have to make one yourself, they just distribute install/live ISOs

Does libjxl still need to depend on sjpeg if it's going to provide its own libjpeg api?

you could grab an image used for vms

or containers

https://us.lxd.images.canonical.com/

Well it's pretty easy to find one for debian...

But debian sucks.

It's convenient to have (simply because so many people use it for some reason) but that's not what I primarily want to use.

I don't think libjxl depends on sjpeg at all, does it?

It's in the 3rd party folder

Isn't that only for djxl to have jpeg as an output format?

(for non-reconstructed jpegs)

I think libjxl only depends on brotli and optionally on lcms2, and libjxl-dec doesn't have any real dependencies (unless I am missing something)

Well it should not need it even for that, should it?

Also, it would be nice if there was an option to skip encoding/decoding JBRD and losslessly reconstruct JPEG without being too pedantic.

Most of the time it's more important for the image data and metadata to be lossless, not care about the exact huffman tables or whatever are used

Yes, recompressing and reconstructing jpeg without jbrd would be nice - it's possible in principle, though a bit tricky since we also kind of use jbrd as a marker to indicate that the data does come from a jpeg...

Perhaps djxl could try to reconstruct jpeg by default and offer lossy recompression only if the reconstruction is not possible.

we'd need to change libjxl to have an option to try jpeg reconstruction without jbrd — which would then of course only be image-lossless, not file-lossless reconstruction.

After all, djxl is decoder, not image converter. In PNG, the transcoding is also only image lossless.

Did ``e 10`` get removed?

No, just hidden behind a flag

Exif and xmp are separate, and icc is part of the codestream

The jbrd only contains the remaining stuff needed to reconstruct the actual jpeg file: the Huffman tables, the progressive scan script, the values of padding bits, any other app markers besides icc/exif/xmp/jumbf, any trailing bytes after the end of the jpeg image, etc.

The only cases where there might be something 'important' in the jbrd, is when the tail bytes actually contain something substantial. E.g. I think sometimes the tail bytes contain another jpeg which is the actual image before blur filters were applied, and the first jpeg is one where fake bokeh was done on the background pixels, based on depth data the camera had.

pass --allow_expert_options 🙂

Generally speaking, all the actual image data is in the codestream (including colorspace and orientation), and all the 'real' metadata (exif/xmp/jumbf) is put in separate boxes, so jbrd is some rather small amount of data that can be stripped without losing anything except the option to reconstruct the exact same jpeg file again.

It's probably generally not really worth it to strip it though, considering that it's typically only 100-200 bytes or so, and if it is larger, that could be a sign that it actually does contain something substantial like tail bytes that actually have something you may want to preserve.

Huffman tables and stuff are not set in stone, those can be regenerated any time by common tools. I always optimize Huffmnan tables, it makes the jbrd smaller.

Well they are 'set in stone' if you want to reconstruct the exact same jpeg file. If that's not a requirement, then indeed you can just use default tables or generate some based on the data - but it won't produce the exact same file. We could replicate the behavior of default libjpeg-turbo or libjpeg-turbo with huffman optimization (which is default in imagemagick iirc), and do something that will often still lead to the same file, but we can only mimick one jpeg encoder when there is no jbrd.

JPEG files are really flexible, they can be also converted between progressive and non-progressive.

Same with jxl btw.

Hmmm, even -e 10 can still fail to reduce 1 bit gray PNG.

not entirely surprising, 1 bit images usually require very special tricks

png and webp do well because they do bitpacking

To be fair, the PNG was also brute-force optimized.

I think we technically could do bitpacking too in jxl, but it would have to be in a rather contrived way: doing horizontal squeeze steps until you have 8 channels at horizontally 1:8 resolution, then doing an 8-channel palette on that.

Maybe more interestingly, this could also e.g. be done on 2x2 input pixels, which may be a better way to pack multiple pixels

I wonder how important 1-bit images still are today. Generally even when you want to represent something like a mask, it's better to do it in full grayscale so you get nice anti-aliased edges.

I mean, they exist, so obviously it would be nice to be able to compress them well. But I wonder if many 1-bit images are still being produced, and why.

I can still use PNG for that manner. PNG is excellent for low color images. In complex truecolor images PNG fails miserably.

PNG is good for 2, 4, 16 and 256 color images, specifically. For any other number of colors, it's less good since you still need to use a (palette index) bitdepth that is one of those four.

I guess QR codes may be one such thing?

As long as you don't use filters, you can still do e.g. 50 colors effectively in png since you just won't have huffman codes for byte values that don't exist. But with filtering, you end up getting all kinds of values.

what happens when you squeeze a 1-bit image?

QR codes are probably best compressed by using general-purpose compression on their payload and regenerating the QR code 🙂

1, 1 and 0, 0 clearly go in 1, 0 and 0, 0 (I think), but I am unsure about 1, 0 and 0, 1

and also about what happens at image borders, for that matter

Yeah it's a bit messy and it might end up creating slightly more combinations than just 2^n for n input pixels, but that may not be a problematic thing compared to the gain you get by having macropixels to entropy code...

So that's why filtering is usually not used for indexed color. Also the palette can be shortened if not all color indices are used.

The palette can be shortened but you still feed full bytes to deflate even when there are only 17 colors.

That's true. Anyway, mostly flat colored truecolor images also better compress without filtering.

Prediction can in principle be quite useful for palette images so it's a bit of a pity that in png prediction doesn't mix well with palette.

At least png still has lz77 so when prediction from W or N has a run of zero residuals, lz77 comes to the rescue

In PNG, it's sometimes hit and miss. Some images can compress better in 8bit palette even if using less than 16 colors.

I suppose bitpacking is not always a good idea - it does reduce lz77 matching options, though it does shorten the distances.

1bit gray can be used for scanned graphs, lineart and similar documents, although I'm not fan of 1 bit scans because readability is often pretty poor.

I'm getting lots of "maybe uninitialized" warnings for a variable named `__Y` when compiling latest libjxl-git on Arch.

Is there a way to have `make test` use all of my CPU cores? It seems to only be running 1 test at a time even though `make build` is multi core.

``` The following tests FAILED: 3069 - JxlTest.RoundtripLossless8LightningGradient (Subprocess aborted) 3094 - JxlTest.LosslessPNMRoundtrip (Subprocess aborted) ```

Huh, weird, I never heard of "high bit depth JPEG" before

use ninja 😛

can you open an issue about those? ideally with the stack trace

Ah damn, didn't realize the AUR pkgbuild is using cmake when ninja is available...

One of the things I hate about linux in general and especially arch is that packagers are idiots...

Do I have to create a github account to open an issue?

probably

if that's not an option you can also copypaste the stack traces here and/or DM me but it will be easier for me to lose track of it 😛

Hmm, I don't see any information about using ninja as the build system for libjxl.

cmake -G Ninja [...]

Oh. Truthfully I'm not that familiar with cmake or ninja or anything more over-engineered than standard makefiles tbf

So thanks for telling me about that

I heard that ninja is faster than most of these other fragile and over-engineered build systems

Also this is weird: Why is a CLA required for contributing to a BSD-licensed work?

Doesn't the BSD license make a CLA completely pointless?

Seems like an unnecessary barrier to submitting patches that doesn't actually achieve anything

I am not a lawyer and I don't even want to begin to think about what the answer to that question might be 😛

Well all I know is the BSD license basically says "do whatever you want, so long as you give credit" (oversimplified but that's the gist of it, there is a specific way to give credit to be in compliance with the license.)

It's a very simple and short, very permissive license that essentially lets anyone do whatever they want.

With very little stipulations

Including, ANYONE can make derivatives that are re-licensed under different license terms. So there doesn't seem to be any point in having a CLA, since a CLA is used in case someone wants to relicense it under a different license, and the BSD license ALREADY allows for this.

So the BSD license makes a CLA seemingly redundant and unnecessary.

And yet it's required to sign one in order to participate in libjxl development. So it looks to me like an unnecessary hurdle.

I guess the proper thing to do would be to create an issue on the issue tracker.

There would possibly be more contributors to libjxl if needless barriers were removed from participating in development.

Like signing a contract with Google :P

yea just call cmake with `-GNinja` and it will generate build.ninja files instead of Makefiles

it's really that simple

I take back everything I said earlier about HEIC being really impressive and good looking

rav1e looks way better

But it also takes an extremely long time to encode anything

So yeah rav1e looks way better than x265 I guess. If you're okay with taking about literally 20 times longer to encode

Also it's still tuned for low-fidelity

I still to this day never understood why people are unhappy with makefiles and why people are incapable of writing very simple and straightforward BSD-style makefiles without a whole bunch of unneccesary logic in them.

`make` perfectly supports parallel builds too.

because Make is very slow

and ninja is much faster

Makefile syntax is designed to be written by hand and not auto-generated so even if it's auto-generated it has to have a complex robust parser that can handle all the syntactic sugar that Makefiles can have even if they are not used

makefiles are supposed to contain absolutely the minimum information necessary to describe dependencies and how to update the files that are made from those dependencies.

this isn't true

you can't re-license derivatives. the way code is licensed, will remain

The CLA as far as I'm aware prevents contributers who contribute code from blocking the project based on the license of the code they write

that's basically all it does

it prevents you from being "that guy"

you can slap whatever license on the new code, but no you can't just change up license without owner's permission of existing code

If you make a derivative, you can license your derivative any way you like, so long as you retain the copyright notice (which essentially amounts to giving attribution).

only the code you add, not the original code

Yes, but that's how copyright works anyways.

and you don't own the copyright to the original

otherwise you could essentially just add some dummy pointless stub code and then relicense a library however you wanted

Once you waive your rights you can never undo.

you don't waive these rights unless it's 0-clause BSD

or some other public-domain-type license, but yea

Once you license something under BSD license, you can never retroactively "take back" the rights you waived.

with CLA you do waive these rights

depending on CLA conditions

in order to copyright something in most jurisdictions you have to actually have created it. You cannot take shakespeare's plays and copyright it, since you didn't write it.

just because you use them in something you *did* write doesn't change the license or copyright status of the original

likewise, you can't incorporate GPLed code in your library, add to that GPLed code, and then relicense that GPLed code as somethign else. The code you didn't write has its original copyright owner preserved and the original license preserved.

The CLA accomplishes nothing that isn't already accomplished by the BSD license. Since libjxl is already released under BSD license terms, that version will ALWAYS be available under BSD license. ANYONE can create a new derivative work of libjxl or new version and release the new version under a different license. All of the code that was already released under BSD licence will always and forever be BSD licensed (unless even more rights are waived later).

> ANYONE can create a new derivative work of libjxl or new version and release the new version under a different license.

No, you can't do this.

You cannot relicense code you did not write.

I guess the one thing that the CLA accomplishes is that it gives Google the ability to waive even more rights to relicense it under an even more permissive license like CC0

Now that I think about it

yeah, that, and also legalese blabbery about how you are sure you aren't putting out stolen code and it's your responsibility if you get caught doing that, not google's

they have already done license change, btw, from apache2

Like I said, I can't do that. All of the code that the derivative is based on will still retain the same license obviously. Only the derivative work would be re-licensed. NO ONE can re-claim the rights over released code after those rights have already been waived

You can't relicense the derivative work, only the *new code* in the derivative work that isn't in the old work.

You keep using "derivative work" as though it only counts the delta, this isn't what that term means. A derivative work is the entire derived work. Blink is a derivative work of Webkit, not just the code that's in blink that isn't in webkit. The whole thing.

Where's the distinction?

the distinction is that a derivative work includes code you did not write

If it only contained brand new code, it wouldn't be a derivative work, it would just be a brand new work.

I am obviously not saying that anyone has the power to alter the license of something they don't own the rights to.

You are saying that when you misuse the term "derivative work"

Just because I make a derivative work of libjxl doesn't mean I can alter the license of the libjxl itself, but yes I can make 1 tiny change and release the whole thing under a different license so long as I abide by my license terms I received.

No, you can't.

You can't just relicense code you didn't write, otherwise you'd see "GPL-free" versions of GPLed libraries which are forks that changed one line of code.

That's what the license terms allow me to do. That's why corporations that are super protective of their "proprietary licensed secret source code" love the BSD license.

No they don't

You cannot release the whole thing under a different license. Only the code you personally wrote.

Because they can incorporate BSD licensed code into their super-special proprietary product

and they will STILL need to abide to its terms

Except those proprietary products have open source licenses available to view.

and indicate license in readme or manual or somethiong

Take your phone and view open source licenses in the settings

You can view the license because that's required as part of the terms they licensed the BSD-licensed code under

But they are not required to do anything else other than show you the license terms they received.

They don't have to show you what changes they made.

in case of BSD, yeah. in case of GPL, no

And they can forbid you from redistributing their super special version under a new separate license

but, like, that's not the same as "the code is licensed different now"

They don't need to make substantial changes to do this either.

your point being?

I can literally just compile libjxl and release my binary under the "up-yours" license, which says you're forbidden from distributing it to anyone unless you pay me 50 dollars.

that BSD is not that effective at pushing opensource-ness? yeah.....?

And say I used special secret compiler flags or something

You can't do that legally

nah you actually can produce app incorporating libjxl

question is who gonna buy it lol

and yes you can sell it

does the BSD license allow for that? huh, interesting.

you can actually sell libjxl code too in floppies or something

But that's not a new license

or paid downloads

That's an example of how anyone indeed can take libjxl and release it under a different license, because that's what the BSD license allows anyone to do

nothing in license forbids that

the BSD license doesn't allow anyone to just relicense it, as far as I'm aware

but it doesn't have a clause against selling it

you just gotta note that u took code from libjxl by these authors blahblah in readme

the GPL doesn't actually have any clause that prevents selling GPLed code either

yep

but it doesn't let you just *change the license*

that's not the same thing as just *changing the license*

The BSD license allows anyone to do anything as long as they retain a copyright notice that essentially says something like "using work obtained under BSD license from libjxl project website"

That's not changing the license

it explicitly notes things you are allowed to do, not "anything"

Including releasing it under a more restrictive license

can you just read damn license with sober non-tired mind and let it sink in

it doesn't list that in the list of the things you may do

BSD 2-clause is literally just this:

> Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: > > 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. > 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. followed by a generic waiver of implied warranty law

It permits redistribution, and use, in source and binary forms

"redistribution and use"

it doesn't permit relicensing

not "relicense"

please just read these licenses before you make claims about what they say

I am reading it again at https://github.com/libjxl/libjxl/blob/main/LICENSE

3-clause is almost the same as 2-clause

But this is not the first time I have read about this commonly-used license

In particular: > Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

there are 4 variants of it

It permits redistribution and use

it doesn't permit relicensing

When you make a derivative work of a BSD licensed product, you still have to comply with the original license (which is easy, it's BSD) but on top of that you can put any copyright you want on your derivative.

no, you can't.

Only on the code that you *wrote*

Again, you're misusing the term "derivative"

a derivative work includes *all of the code* including the code that you did not write.

Yes, you can, and yes, that's why it's used so often by corporations.

You can't relicense the code that is part of your derivative that you didn't write.

Because the BSD license doesn't permit that.

you can license new code you wrote in your "derivative" work but honestly this term is too loaded to talk with clearly

If you used a BSD licensed work in your software, your entire software does not become BSD.

It is not a "viral" license like that.

your work virally must now carry notice about the code you used and the whole copyright license

if you incorporated gpl then yeah that's kinda more cursed though i wouldn't think that's grounds for relicensing your own code either

Yes, to comply with the terms I received the work under, I must have that notice but I don't have to do anything else

maybe only integration with gpl code parts

i may be quite wrong here though

Basically what I'm saying is that when I think about it a little more, the CLA could theoretically allow Google to waive even more rights in the future, for any code that gets contributed.

waiving the rights isn't the sole reason of CLA, but yes this is correct

The BSD license is already pretty liberal and widely accepted by corporations so I doubt there would ever be a need to make it even more allowing

when you want to understand why someone does something one way or another, you gotta look from their point of view, not yours

The whole reason I brought it up is because signing a CLA is another hurdle to jump through before anyone can contribute and if the CLA is not there for a really important reason maybe it should be removed

It seems odd to me for a BSD-licensed work to require a CLA to contribute, since the BSD license is already such a carefree license

the people you are talking to are not the ones who handed it down the way it is. iirc all google's open-source projects are like that, and i doubt this is easy to change, kinda swimming against the current

& i think they have enough of stuff to worry about already

It would seem to me on the surface that there is very little a CLA brings for a BSD-licensed work.

from your point of view and values, yes

I haven't revealed to anyone yet what my values are.

Good news: we are planning to make a v0.8.0 release soon! I'm on my way to the ISO meeting in Sydney

Good news, any chance for stable 1.0 this year? I see https://github.com/libjxl/libjxl/milestone/1 is nearly frozen

As far as I understand (but IANAL), the CLA serves two main purposes: - copyright: your contribution is not just BSD-3 licensed, we also can relicense it under another (even more permissive) license should the need arise. We already did that once when relicensing from Apache 2.0 to BSD-3. Relicensing without CLAs means we need to track all contributors and get their permission, which tends to be problematic when some contributors are no longer reachable. Since BSD-3 is already about as permissive as it gets (and seems to be acceptable to e.g. Adobe and Serif), I don't think there will be a need to relicense, but you never know. - patents: by signing the CLA, you also grant a patent license under the same conditions as Google and Cloudinary granted their patents (royalty-free, with a defensive clause). Should your contribution contain anything you don't just have copyright on but also patents, this is important, since the BSD-3 license is only a copyright license that does not say anything about patents. We need to ensure that no contribution accidentally or intentionally injects patent-encumbered things into libjxl. The CLA helps prevent that. I agree that the CLA is a bit of an annoying obstacle for new contributors, but I think it's there for good reasons.

it does

https://en.wikipedia.org/wiki/Permissive_software_license

“Grants use rights, including right to relicense (allows proprietization, license compatibility)”

it allows placing further restrictions in future distributions as long as the original ones are respected

the way that the GPL prevents this is essentially by saying “these restrictions shall be preserved”

> as long as the original ones are respected this is not relicensing though

arguably, the copy is effectively under a new license for all intents and purposes

of course, if it’s unmodified, it’s rather pointless since the original is still available under just the BSD license’s restrictions (i.e. not much)

as far as I am concerned, the CLA does something very useful: it reduces the number of conversations we need to have with our opensource lawyers 😛