JPEG XL

That's a good improvement looking at pnorm, not sure to what extent pnorm is reliable for that kind of image.

Btw it might also be good to use delta palette for lossless, atm in lossless delta entries aren't used at all but presumably in some cases it could be beneficial to use them

Just one image though, so doesn't say that much

(but I am quite sure that kind of change is unlikely to be harmful, and can basically only help)

Also, why exactly 1%? But when I have time, it would be interesting to compare these changes in other images, and <@!461421345302118401> might also be interested

Yeah I think probably with 0.1% it works even better

But need a large corpus to test then

(also would be fun to make a heuristic to add custom deltas, instead of relying on the default ones...)

Yep

New lossy-palette build

yay

it only adds colors that have constant 4-connected neighbours

for some images it is a great strategy, but it is nothing universal

luckily I have more ideas than that 😄

i.e., if there is a huge slab of constant color in a pic, then add that exact color into the palette

Source

New LP (156 396)

Old LP (183 274)

did you like it?

VarDCT = New LP Size

I believe I can make is still 17 % better for images with slight gradients like this one

The Old LP has dithering artefacts in the middle gray area -- I hypothesized that they will go away with the new change and that seems to be confirmed -- working as intended

Yep (New - Old)

big improvement 😄

I'm so thankful for you showing this, made my evening!

I created the dithering algorithm 'blind', didn't look at many of the images

But these are only the images where I found a difference (otherwise everything is almost the same including the size as in the old LP), although I'll look for more examples

now that I see the results I'm less happy with it :----D

yes, it should only trigger on special images

the next change I plan is to deal with exotic or slow gradients with low noise

that would likely be a more universal win

New LP

Old LP

Also size (New - 76,707, Old - 202,954)

to me this one still looks better than the LP image though

Yes, currently in other images this is also the same (VarDCT better/same), but perhaps I can find counterexamples It is also all -s 8 (perhaps -s 9 and other options could be better)

-s 9 likely yes

-E changes nothing

you want -I 0 -P (0? probably?)

Yep, that might help, but for now I'm testing with something relatively universal for all kinds of images and not very slow

`--lossy-palette -s 9 -I 0 -P 0` is much faster than the usual `-s 9`s

and should be reasonably universal

On lossless comparisons it wasn't always better on photos, I test on those too (although LP would be more useful on artificial images)

it should always be better after LP

<@!179701849576833024><@!794205442175402004> Then maybe enable `-I 0 -P 0 --palette=0` by default when the `--lossy-palette` option is selected and change them only if they are specified?

probably a good idea yes 😛

Never seen that one, sounds like a weird icc profile?

<@604964375924834314> ?

interesting, could you please share the icc profile or the image so that we can take a look?

I suppose it might be a LUT profile

thanks, it seems the red and green primaries have negative Z, and the blue primary has negative Y

profile

I think

not 100% sure

One thing that may be relevant to progressive analysis is the resolution ratios. Progression is not important for small images of say 500x500 -- they already load fast enough and Chrome will not show progressive stages. It becomes much more important for full screen or near full screen content

the 8x8 subsampled overview image is a much better approximate for a near full screen photograph than for a thumbnail of the same photograph -- i.e., more utility in that use case

also, Chrome would be much more likely to actually show progressive stages for a large image (more bits, longer transfer) than for a a smaller image -- Chrome seems to decide it by timing a few updates (actually I don't know what is happening, just fuzzy observations) during the load if the load is taking a significant amount of time.

the 'spiraling' middle-out/center-first progression is relatively calm when observed from Chrome (by Chrome giving it a small number like five of updates during the load), but looks like a bumble bee with attention seeking disorder if every 256x256 square is painted separately (like possibly in some videos demonstrating progressive loading)

That image was 1920x1080 fwiw

that's 8x5 groups, 7x4 full ones

yep: “Tristimulus values must be non-negative.” (ICC spec)

something might be off about the measurements

(but I don’t think I would be able to tell)

yours is an ICCv2 profile

also, I’m not sure that skmcs supports ICCv4 anyway

it might be that we have an overzealous check somewhere, actually

in fact the line numbers don’t seem to match in the current version, so we might have changed it already

which JXL version are you using?

... a better comparison of how different progressive modes, blurry-preview and fully non-progressive fare against each other would be to record full screen experience on Chrome rather than small images

sorry yes, the check is ours, nothing to do with skcms

when showing thing side-by-side it would be best if the side by side level images are not crops of the big image, but for example full screen captures or even including the monitor showing the whole setup -- then users can relate (likely) most effectively and authentically to how they would feel with different progression experiences

seems that it’s our fault after all, I think we can maybe remove the check

thanks for finding this out

Thank you spider-mario for bringing clarity to this

done, should be in the next release

if this is what I think it is, we are battling an internal compiler error in gcc 7

the rest of the pipeline, with different compilers, is fine

can we do a 0.3.8 release? or what's the plan?

we haven't bumped the version number in a while, and we are in this weird situation where the main branch says it is 0.3.7, the 0.4.x branch is missing some of the new stuff, and the 0.3.x branch is even more outdated

wouldn't it be better to call 0.3.x and 0.4.x what they really are (I think) : the versions that are in M91 and M92 ?

I want to update the jxl in Cloudinary but with the current version tagging it's kind of a mess

chrome milestones

(which is a fancy word for version numbers)

yes, that's the current stable chrome

https://chromiumdash.appspot.com/schedule

Are you saying there is a jxl support on chrome stable?

behind a flag, yes

and only on desktop, not mobile

https://chromium-review.googlesource.com/c/chromium/src/+/2932498

mobile and animated jxl (still behind a flag) will be for the next stable chrome version, M92

Waiting for Firefox mobile ( beta ) jxl support

<@&803357352664891472> WDYT?

libjxl 0.3.8 release will include some verdct improve?, I'm very look forward to see this🙂

Hmm, yes on a large variety set `--lossy-palette` with `-I 0 -P 0` is less effective in general <@!532010383041363969><@!179701849576833024><@!794205442175402004> Also, enabling `--lossy-palette` discards alpha

*less* effective?

Yes, only `-s 9` is more effective

But, it's on a random set of images, I didn't choose which might be better with `--lossy-palette`

at s < 9, I think -I 0 is a bad idea since there's no or weak lz77 search then

Also, is it possible to make `--lossy-palette` mode very effective for almost black and white or almost grayscale images? Like sometimes there are comics, manga or document scans, but with slightly different pixels in other colors, theoretically it is possible to reduce palette to true black and white or limited grayscale without noticeable visual differences Like, yes, such an image can be converted manually, but I'm more about something like automatic detection when the user does not know what kind of image, but, it would require some clever detectors like that, say when it is 99.9% black and white or grayscale image and color pixels are more like random digital noise or little difference visually (say on the edges)

probably for actual grayscale, it will either not be effective or will require custom deltas to make it effective (defaults are kind of designed for 3 color channels)

yes, that is by design

more context modeling will help there

next planned step for improvements to delta palettization is to cluster deltas

I anticipate a 15-20 % improvement for images with gradients (and low noise)

graphics mostly

So transparency is not possible with `--lossy-palette`, or is it just not implemented now? Theoretically, it might be possible to get more improvements with more efficient lossy encoding methods for transparency

possible, it is

implemented, no way xD

Also, more precisely what I meant was that `-s 9 -I 0 -P 0` with `--lossy-palette` is less efficient than just `-s 9`, but mostly better and faster than just `-s 8`, so `-I 0 -P 0` is not very suitable as the default option

weird, that

I wonder what predictor it ends up using...

Also, does it differ from WebP only in that there is no automatic predictor selection and limited group size or is the LZ77 implementation at this point also less efficient?

it should be basically equivalent

although *probably* webp has the advantage of LZ77-ing all the channels at the same time

in my experience LZ77ing per channel is more efficient in density

I chose WebP lossless' approach because the loss is not big and it allows faster coding

I had a very capable intern who looked into different LZ77 strategies (like brotlifying per channel with WebP lossless' predictors)

Interesting recent commit from WebP2 🤔 (as far as I know they want to significantly improve alpha compression compared to WebP, not in this particular commit, but in general)

Alpha-from-luma?

Reminds me that we should take a look at using RCTs involving alpha. It might sometimes make sense. E.g. use a permutation RCT to move alpha to the first channel, so the other channels can use it as context - e.g. often semitransparent pixels are all the same color (black or a dark gray, for a shadow effect), and that could be exploited by basically starting the MA tree for luma with something like ``` if Prev < 255 - Set 10 ```

So you'd get a kind of luma-from-alpha from that

it seems like a context modeling thing would be appropriate, not a prediction thing

Well we can do either and both, since MA trees work both as ctx model and as predictor

I've seen something that seems to contradict each other in cjxl...

From `cjxl -h -v`: ``` -P K, --predictor=K [modular encoding] predictor(s) to use: 0=zero, 1=left, 2=top, 3=avg0, 4=select, 5=gradient, 6=weighted, 7=topright, 8=topleft, 9=leftleft, 10=avg1, 11=avg2, 12=avg3, 13=toptop predictive average 14=mix 5 and 6, 15=mix everything. Default 14, at slowest speed default 15```

But at the same time...

```./cjxl image.png -P 14 Invalid predictor value 14, must be less than 14. Error parsing flag -P Use './cjxl -h' for more information```

Could you explain it to me?

Because I don't understand this...

Looks like we document the internal default values but don't actually allow setting them manually. Open an issue maybe? Or a PR to just fix the bounds check in cjxl.

https://tenor.com/view/captcha-thug-robot-i-see-what-you-did-there-thuglife-gif-7721399

Which build are you using and on which platform?

You mean `v0.3.x` branch from GitHub?

Ah, ok. Could you recompile from the `main` GitHub branch? It's got a couple of improvements and it should be stable. I've (correctly, it seems) suspected that you've got an older version because of lack of line break after `[...] less than 14.` string. I fixed that in `tools/args.h` in https://github.com/libjxl/libjxl/pull/80/commits/e8915c56bc1082d0ab6b17cf8afb4e21022c57bd.

I don't think it will happen, we'll rather have a v0.4.0

You don't have to, just like I said before: current git version is stable enough.

https://gitlab.com/wg1/jpeg-xl/-/issues/228#note_593247388 😉

Also, can checks by some static analyzers be useful for vulnerabilities, bugs, etc.? For example, PVS reports on zlib-ng code

could be, we already do some linting but maybe fancier analyzers can find more

I often find clang-tidy to find way more false positives than actual bugs xD

Oh yes. It's often "maybe you meant to do something else?" and the answer is "nope"

or "X could be null!" "no, it can't"

So, for faster encoding purposes on limited hardware, would it be possible to limit the computational bit depth to 16-bit instead of 32-bit?

in theory yes

but I wouldn't enjoy writing that

Current jxl implementation does everything with 32-bit float (for lossy) and 32-bit int (for lossless)

The main impact of that is memory usage

For speed it probably doesn't matter much, maybe using 16-bit ints would be slightly faster but I don't think it would make a huge difference

Modular transforms can increase the integer width needed, so using 8-bit buffers for 8-bit images would only work if the transforms are not used

Theoretically you could make an encoder that uses only constant memory (if you can give it the image in tiles instead of in one big buffer), and a decoder that for images encoded in that way also uses constant memory

But for now we have the whole image in memory in the encoder, and in the decoder we are working on avoiding to have the full image in memory, returning the decoded image in tiles instead

Encoder memory needs can still be inproved a lot, we are focusing more on the decoder atm

it was x4 times bigger in speed 9

the version before 0.3.7-65

jpeg xl needs ram

if you want jxl, buy a good computer even if you're planning to encode 16 mpx imags

decoder is light

Lossy default speed should be ok-ish in memory needs

So `uint16_t` should be enough for Modular transforms for 8-bit inputs, I guess? How many additional bits do those transforms require?

well we use signed int so `int16_t`, but yes, that should be enough for up to 12-bit inputs

maybe 14-bit if you don't do both squeeze and RCTs

Ah, I forgot that you have to use signed int since transforms can result in negative values... Does lossless use any RCTs by default?

yes

it selects one per group, using some heuristic to determine which one will likely work best

at faster speeds it just always does YCoCg

Squeeze and RCT can result in negative values, also delta palette uses < 0 values for implicit deltas.

Any updates on https://github.com/libjxl/libjxl/issues/99 ?

here you go 🙂 https://github.com/libjxl/libjxl/pull/166

Does libjxl do HDR, yet? Does it do it well? I took this HDR source image https://xn--g08h.img.rodeo/raw/upload/v1623700809/LuxoDoubleChecker.exr and did a simple `cjxl LuxoDoubleChecker.exr luxo.jxl ` The result had visible banding. Then I tried `cjxl LuxoDoubleChecker.exr luxo.jxl -q 100`. The result looked smooth/good. My display can do very limited HDR (looking at the OpenEXR original in Preview.app, brighter whites and lighter highlights are visible, especially if I dim my screen slightly), but I assume Chrome (my JXL viewer...) cannot, so I wasn't able to "see" whether values >1.0 are preserved in the output JXLs. Are they?

(this experimentation was inspired by this excellent WWDC session on how Apple does HDR https://developer.apple.com/videos/play/wwdc2021/10161/)

Current stable chrome does not do hdr jxl, current dev/canary chrome does, iirc

No idea if that's true on macos though, haven't been able to try yet (need a hdr screen)

In Windows it should work

btw does current canary chrome do progressive loading

No, not yet

What Mac do you have? I have a 2017 Macbook Pro and it can do SDR*2 when I reduce brightness a tad...

that's sorta cheating tbh lol

How did you view the result? If it's decoding to 8-bit then banding is inevitable, need to decode to 16-bit (float or int)

`djxl --bits_per_sample 16` when decoding to png, or use .exr as output

Compare: https://xn--g08h.img.rodeo/image/upload/v1623707935/luxo.jxl in Canary https://xn--g08h.img.rodeo/raw/upload/v1623700809/LuxoDoubleChecker.exr in Preview.app Preview.app looks way brighter and shows more highlight detail with display brightness at around 80%, even on my old mac.

I'll try dxling...

I have a 2019 macbook pro, afaik its builtin screen is natively 8-bit display P3 but I have no idea how to actually check that

you gotta take into account additional dimming though

as in that's probably implemented by turning pixels on and off real fast

What do you see when you run this thing I cobbled together this afternoon to check my own screen? (you can trust me...) I'm assuming you'll see something like % ./screengetter Hello, World! Optional(2.0) Optional(2.0) 0.87890625 And your screen, just like mine, can do just a little bit of HDR (SDR x 2)

I usually set brightness to max hoping to avoid that (also to see more)

Will try tomorrow, it's bedtime for me :)

I'm Jon btw :)

Update: taking the original OpenEXR and roundtripping through cjxl + djxl back to EXR appears to preserve all HDR data (for the small sliver of HDR contained within the file that my screen can actually display). Huzzah.

Too bad you can't see it in Canary...

Like this: https://github.com/eeeps/screengetter/blob/main/screengetter/main.swift#L29 Just reads/prints the "Extended Dynamic Range" values from here https://developer.apple.com/documentation/appkit/nsscreen#topics which I learned about in the WWDC session video, above. (third value is the display brightness, via some complicated-seeming code I copied and pasted from stack overflow)

Weirdly, it displays different values when I have an HDR image open in Preview, vs when I don't... ha

Maybe the true answer to "how does it work" is "I don't know" (;

“screengetter” can’t be opened because Apple cannot check it for malicious software.

ok found how to get around that — default dialog box doesn't give the option to say "run it anyway"

``` Hello, World! Optional(1.0) Optional(2.0) 0.74316406 ```

So you, like me, should be able to see just a little bit of HDR. Second value (2.0) is https://developer.apple.com/documentation/appkit/nsscreen/3180381-maximumpotentialextendeddynamicr

Interesting

when I open that EXR in preview, and dim the screen, then basically the brightest parts in the image remain at the brightest the screen can do, even though it's dimmed

so they become brighter than what is nominally white

but when I set the screen to max brightness, nominal white and the brightest parts of the EXR look the same

I do see some funky artifacts when Preview is not showing the image 1:1 btw. Smells like its downscaler is doing things not quite right

Chrome Canary does indeed not display the image in 'HDR' like Preview does

the jxl does decode to an exr that Preview does show in 'HDR' though

https://prolost.com/blog/edr

ugh the screenshot tool is conspiring too

photo of my screen isn't that clear either, but the point is: the .exr files are brighter-than-white in Preview, the .png isn't

well it's the built-in macbook pro screen, just using default calibration

it looks the "brighter than white" thing is something Preview does with .exr files but not with .png files

yes I need to buy a colorimeter, I have a fancy BenQ monitor that is calibrated very well out of the box but it's time to check its calibration

(I don't care hugely about absolute accuracy though, I only need relative accuracy)

Yes and I still could never know what it really represented without documentation (even the documentation isn't that clear; the WWDC video is really what taught me I suppose)

yeah, an i1Display Studio or Pro or a used ColorMunki Display is likely the best quality/affordability compromise in this range

(one can also get a https://www.kleininstruments.com/k10-a for $7000, but it’s more targeted at manufacturers who calibrate many displays)

And i can say, event 300€ spectro like xrite i1 display pro, having a good visually relative accuracy is pretty hard. ICC default profile for macbook pro is excellent.

the X-Rite naming scheme is a bit confusing but the i1Display Pro is not a spectrometer, the i1Pro is

the i1Display Pro is a colorimeter

a spectrometer measures each wavelength separately and then the software can compute the integral of the product with the color matching functions to get the X, Y, Z measurements

a colorimeter has three filters that approximate the color matching functions and measures the whole filtered spectrum at once to get a tristimulus value directly

a colorimeter may need a correction matrix if the filters are not quite those desired, but on the plus side it gives better dark measurements and is also generally more thermally stable

so the best approach, if possible, is to use both: first a spectrometer to create a correction matrix for the colorimeter being used, and then the colorimeter for all the remaining measurements

if one wants to use only one measuring device, then it should likely be a colorimeter by default, or a spectrometer if one plans to profile a printer as well

(this is less needed with recent colorimeters with more accurate filters)

Yes you wright i speek about the i1Studio, it's a spectro. Software seem to be not smart and report after calibration is not good, really it's hard to have a good visual result on good ips 6bit+frc display even with 1 million patches. i use my display now only with hardware rgb calibration in display menu. ( i hate banding and bad gradient) For me absolute color deviation is not a big problem. (Only in certain colors like purple, orange)

Also with old macbook pro retina (8bits display) color profile do ugly banding in some color, and grey is not perfectly grey.

yeah, Argyll CMS and its GUI DisplayCAL have a reputation of being better than OEM software

and they are indeed very good

DisplayCAL’s 3D LUT generator has been quite useful in helping us experiment a bit with HDR on non-HDR monitors

seeing that it implemented tone mapping using the technique described in BT.2390, we implemented that in `djxl` too (https://github.com/libjxl/libjxl/blob/13649d2b29ca7c4e96795c1ec5ccfeb19524236c/lib/extras/tone_mapping.cc)

and so, here is the checker image from above, encoded to jxl assuming that `1` in the EXR should have a brightness of ~30 cd/m², and then tone-mapped by `djxl` for displays with a peak brightness of 80 cd/m² :

(er, one second, something seems to have gone wrong when converting the png to jpg for discord)

yeah, something strange seems to happen when converting to sRGB

it should probably not look like that.

this is with lossless jxl, so most likely it’s the tone mapping that is behaving strangely here

the shadows are quite hard to get right, with everything approaching zero

yeah, those shadows are a bit bad xD

ah, it could be that part of the problem is in how I prepared the EXR for compression by JXL using `exrnormalize`

there is a very bright spot in the image (1847), and dividing all the rest by that may have been a bit problematic

it may also put more stress on the tone mapping to map such a wide range

let me try when normalizing a little less

I would say that the problem-free area does look a bit larger, doesn’t it?

still trying to map from up to 800× the original `1` value which is probably not really necessary

50: finally, seemingly artifact-free shadows, although we are not retaining quite as much highlight detail anymore

this makes me want to investigate what could be improved in the tone mapping to prevent this sort of thing

but not right now, it’s getting late.

(or early depending on the point of view, but you get what I mean.)

out of curiosity, why not DisplayCAL for both steps?

with

hm, so it seems the problem may not be in the tonemapping after all

possibly instead in color conversions

I get similar artifacts if I just ask djxl to decode to a Rec. 2020 EXR

and converting to linear Rec. 2020 is the first step of the tonemapping

How do I make the alpha channel lossy?

it is done by default if the color image is lossy

that only does a mild amount of lossy to alpha though, to keep things safe

since alpha is modular-encoded, you can adjust alpha quality by using `-Q`

there's currently no way to set different modular quality for alpha than for color though, if you do color with modular too

Getting a nice decode speedup for the fast lossless modes like thunder, by just skipping the unnecessary copying from group to full modular image and going directly to the decoded float buffer instead

<@768090355546587137>

Makes -m -e 2 decoding go from 50 MP/s to 60 MP/s

Also reduces decode memory by 30% or so

Can only be done in RCT-only cases though, atm

(could add channel and no-delta palette later, but for delta palette and squeeze it's not going to work)

Is there a parameter to automatically drop alpha if it's completely opaque? (maybe this should also be the default for loosy)

ah, no, and I actually don't see any reason not to just do that always

even for lossless I think it's pretty much clear that no alpha channel is the same thing as full-opaque alpha

Do I need to open a GitHub issue?

Why? Does it save space?

i suspect it would. also complexity

A little, also less RAM but mainly decode (probably also encode) time.

<@!794205442175402004>

yes pls 🙂

I will.

Could someone explain what is going (wr)on(g) with noise=1 here?

white background: way too much noise black background: a bit much noise both together: no visible noise ???

I think there's a reason noise is disabled by default 🙂

encoder decisions regarding noise are currently likely not very good

I guess it would be nice being able to specify a maximum noise intensity or something then.

it works fine if the image contains a dithered gradient

can current djxl decode jpg to pixels or do i need to first cjxl it to make it do that

kinda curious whether ill be able to notice any difference between how libjpeg and libjxl do decoding

Djxl only takes jxl as input atm

So have to do the `cjxl bla.jpg tmp.jxl; djxl tmp.jxl decoded.png` thing

<@!260412131034267649> please upvote: https://gitlab.com/wg1/jpeg-xl/-/issues/232

Difference should be small with libjpeg, but we do have more accurate processing and maybe slightly nicer dequantization

Nothing will beat Knusperli though

<@!604964375924834314> more noise issues

This is partially related that we have accidentally reversed the intensity of the noise model -- often there is more noise in white areas than dark areas, and the physics are the opposite (not in linear space, but after the gamma compression)

we are aware of this, we just were not able to prioritize it when we had a lot of work with Chrome integration

At the time when we developed Knusperli, I also had a Knusperli 2.0 that also used Gaborish and other tricks 😄

non-surprisingly, Gaborish makes low quality jpegs look better even if the opposite transform was not run at encoding time -- the opposite transform can be approximated by changing the quantization matrix weights (by increasing the highest frequency weights by about 30 % in the experiment I had)

Knusperli's main idea comes from my context modeling idea in brunsli -- extrapolation of the dct values all the way to the border of the border pixels

if you extrapolate dct all the way to the edge, the other edge is a 1d idct of the sum of all coefficients row or columnwise, and the other edge is an alternating sum of all coefficients row or columnwise

it makes many things fun and simple, and a bit weird, too

in knusperli we don't do much nicer dequantization of dc for very low quality jpegs -- that is something we developed for brunsli (but didn't make it into jpeg xl in the end)

that combined with knusperli 2.0 would make a great jpeg decoder

Don't let the bastards grind you down.

When something goes wrong in life, just shout "plot twist!" and carry on.

How can we use JxlEncoderSetColorEncoding to make no color transformation? So when using fp values they are not transformed in encoding / decoding ?

When you set it to do lossless it should automatically do that iirc. <@768090355546587137> ?

Using JxlColorEncodingSetToLinearSRGB appears to work

Issue 299 "GIMP plugin fails to open JXLs which were transcoded from JPEG" Sometimes gimp return blank canvas / error even for non-transcoded images Some examples for this issue (jxl&orig) https://drive.google.com/file/d/1T5X-Cp02JaC50jdKrGhUSIrAJIdHGj8X/view

I think the TOC structure could be abused to create ambiguously parseable files. i.e. if the offsets in the TOC don't actually correspond to the real offsets in the bitstream. To mitigate this, when the bitstream is being parsed sequentially (i.e. not using the TOC to skip ahead), checks could/should be added after each section has been parsed, to check that it actually corresponds to the size/offset declared in the TOC.

(It's possible that there are already sufficient checks in place, I haven't explored the codebase enough yet tbh)

I think we already do that, not sure though. I think we do allow sections to have padding at the end, but we don't allow them to be longer than what the TOC says. Not sure though.

any chances that CodecInOut and related APIs would become public? These APIs feel like a good "advanced mode" API where greater control over the codec metadata is possible but they are currently internal only...

not sure if that's a good idea, we're not trying to be a substitute for imagemagick, libvips and co

fair, some of the CodecIO APIs do something similar to libvips so those would be redundant to expose. probably the current API would work well with some additional metadata supported (like the frame one I proposed before)

I think we need an api option to return zero duration frames separately and without blending, with the info about crop coords and blendmode returned too somehow

Not needed for viewers or browsers, but necessary for things like gimp or imagemagick integration if we want to properly do layers there

sigh

for some ridiculous reason, when using floats, apparently lcms2 uses the range 0..100 for CMYK, where 100 means max-ink (which is not the convention in CMYK, usually 0 means max-ink there)

for RGB it's 0..1 which is the conventional thing to do

but for CMYK they don't

skcms just does the sensible thing, which is also how we store it in the bitstream: 0..1 where 0 means max-ink in the case of CMYK (and 1 means max-light in the case of RGB)

it would have been less annoying if this was mentioned anywhere in the documentation or something

I just had to guess - 0..1 was way too faint, scaling to 0..255 was inverted, 255 * (1 - val) was too dark, 100 * (1 - val) looked perfect

In all the tools I know, 100 is max ink in CMYK.

yes, in a UI that makes sense

not so much in a bitstream

Clear!

the number 100 is not a very round number for binary arithmetic

PSD also has some instances where it uses a 0..100 scale, it is very confusing. For things like transparency, it sometimes does 0 = transparent, 255 = opaque, sometimes 0 = opaque, 255 = transparent, and sometimes 0 = transparent, 100 = opaque

PSD spec is madness

do you smell the elegance of it all?

https://github.com/gco/xee/blob/master/XeePhotoshopLoader.m#L108 (and I just ventured there once, to figure out if I can sniff easily when layered images contain fancy stuff that will prevent me from merging them via ImageMagick… still waking up in the middle of the night…)

So I strongly recommend not looking into supporting Photoshop and/or TIFF layers in JXL until anno domini 2177…

Even just figuring out when it’s safe to treat a composite layer as a 1:1 proxy for the flattened file is far from straightforward (probs that’s why not even Adobe’s own InDesign does that…): https://github.com/guardian/grid/issues/2395#issuecomment-569743194

TIFF layers are basically a regular TIFF for the "compatibility" merged image, and then a huge "metadata" blob that contains a PSD file

I discovered that the hard way because libtiff assumes metadata is small so loads it into memory even when you just want to know the basic image info

PSD is an ugly beast that changes every year

I hope for the basic purpose of multi-layer images (without fancy blend modes and layer effects, just alpha-blended layers), jxl can fill a gap so we finally have a standardized interchange format for that

> regular TIFF for the "compatibility" merged image Worth knowing that **by default** this composite layer doesn’t contain transparency for transparent image. So it’s basically useless… (https://feedback.photoshop.com/conversations/photoshop/photoshop-default-tiff-save-options-to-be-save-transparency-on/5f5f46104b561a3d42719a47). PSD by default has this composite correct, one needs to actively change the preference to no save it.

the confusion about transparency in Photoshop land is enormous

doesn't help that they have about 5 different notions of it

alpha, opacity, masks, selections, clipping paths

> for the basic purpose of multi-layer images For an converter/encoder sitting outside Photoshop guts (even as a plugin probably), distinguishing those safe _basic_ ones from ones that won’t work may be a major pain (if possible at all).

6th: clipping group 😉

I think it's possible to come up with a criterion of what would work: - no layer masks - no layer fx - blendmode has to be default (I suppose we could also support Add and Multiply technically, but meh) - no text layers (have to rasterize them) - no vector layers or whatever other weird stuff they have - layer groups get lost (I suppose we could support it in the same way they are implemented in PSD: empty layers with a naming convention for "start group" and "end group", but we'd have to signal it a bit differently, 0x0 is not a valid layer dimension in jxl) - image has to be RGB, Grayscale or CMYK (I suppose we could also do Lab via a trivial ICC profile, but not stuff like DuoTone and whatever)

Hmm… This list can never be fully exhaustive (what about future features). I’m not sure effort here is worth it. I can see two potential uses for saving/converting layered content to JXL: 1. full “lossless” replacement that can be turned back into a PSD 2. a “lossy” subset of layered image Even forgetting problems with automatically distinguishing between the two, 1 is not possible most of the time: I don’t think many working layered files are using such a subset of features that they could be saved in JXL with full interoperability in mind. 2 can be useful for specific **export** to web tasks: a lossless “txt” layer over lossy background etc. JXL properly integrated into Photoshop’s Export for Screens can be useful, but would be niche, I think. And I would count on Adobe doing it (since they already signalled interest). Hopefully will be done better than bundling outdated pngquant without proper colour support…

1. I think is technically possible, basically have the merged image as a jxl, then in the container have a box (`psdr`, for psd reconstruction data) with another jxl containing all the layer pixel data, plus a brotli-compressed chunk that contains all the 8BIM blobs (it doesn't need to know what they mean). This could then be reconstructed to the exact same PSD in a conceptually similar way as what we do with JPEG bitstreams. 2. This is probably more useful, it's not aiming to replace PSD but can be useful for the web (modular text over a vardct photo is one example), and also for having a way to interchange basic multi-layer images in an interoperable way without having to merge the layers. It's not as complete as PSD (or XCF), but it's a lot more editable than a merged image, and for some use cases you don't really need more than this — e.g. a typical example I often see are product images consisting of a background layer, a shadows layer, a layer for the product itself and maybe a few text overlays, and this one asset is then used as a source in multiple contexts using different selections of layers.

I'm trying to write a JXL screenshot function in a game, but I'm having some issues with the color encoding. The image data is taken from OpenGL buffers, and when I use JXL's `JxlColorEncodingSetToSRGB` with `JxlEncoderSetColorEncoding`, the image comes out very dark. I'm fairly out of my depth here as far as "color encoding" and that kind of stuff goes, as neither libpng nor libjpeg require me to worry about it. Any advice?

it could be that the data that you are getting from OpenGL is in linear light, without the sRGB transfer function applied

I thought it might be something like that, but libjxl only has `JxlColorEncodingSetToSRGB` and `JxlColorEncodingSetToLinearSRGB`, both of which are sRGB and produce a dark image

so I'm unsure where to go from here

both use the sRGB primaries but `JxlColorEncodingSetToLinearSRGB` does not use the sRGB transfer function

I think it’s worth a try

“full” sRGB has both parts

primaries = “(1, 0, 0) is specifically this red, (0, 1, 0) is that green, and (0, 0, 1) is this particular blue” sRGB transfer function = “(0.46, 0.46, 0.46) actually represents 18% of the maximum light output, not 46%”

“linear sRGB” = sRGB primaries (red, green, blue), but linear transfer function ((0.18, 0.18, 0.18) = 18% of maximum output)

another curious possibly related issue is that `djxl` errors out trying to decode the produced JXL, but the Qt JXL plugin I'm using to load it in image viewers and thumbnails has no issues

would you perhaps happen to have such a jxl file at hand?

same JXL for both issues, too dark and doesn't work in `djxl`

ah wait, silly me, I write the entire buffer instead of just the consumed buffer, so the file has lots of extraneous data at the end

I guess that breaks `djxl`

does `JxlColorEncodingSetToLinearSRGB` seem to fix the darkness issue?

actually, I guess I can check whether it should do so by decoding (after relaxing the decoder) and assigning a different profile

it did not for me

the two encodings seemed to produce largely identical images

my test suggests that it should have made it look more like this:

oh actually, now that extraneous data was removed, `JxlColorEncodingSetToSRGB` produces a correct image, so maybe it was just the buffer issue on my end

and yeah about that, it's upside down because of the way OpenGL buffers are oriented, so I tried setting JxlBasicInfo's orientation to `JXL_ORIENT_FLIP_VERTICAL` but nothing changed, that's another thing I'm unsure about

I could of course just flip the lines as I do with libjpeg and libpng, but thought that was worth mentioning

opengl buffers are flipped? didn't knew that

BMP does that too

I wonder why, it seems inconvenient

hate to be such a bother, but in addition to the `JXL_ORIENT_FLIP_VERTICAL` issue above, there seems to be another discrepancy...

the JXL produced by `libjxl` is almost twice as big as the one produced by `cjxl` with identical distance and effort settings

that doesn't seem right

I took the one produced by `libjxl` (`JxlEncoderOptionsSetDistance(m_opt, 0)` and `JxlEncoderOptionsSetEffort(m_opt, 3)`), decoded it to a png, and re-encoded with with `cjxl -d 0 -e 3`

4.7 MiB vs 2.6 MiB

uh

probably different bitdepth?

they should both be 8 unless I messed something up, `m_info.bits_per_sample = 8;`

I'll just post this: ```CPP m_enc = JxlEncoderCreate(nullptr); assert(m_enc); m_opt = JxlEncoderOptionsCreate(m_enc, nullptr); if (quality < 0) quality = 0; JXLEE(JxlEncoderOptionsSetDistance(m_opt, quality)); JXLEE(JxlEncoderOptionsSetLossless(m_opt, quality == 0 ? JXL_TRUE : JXL_FALSE)); JXLEE(JxlEncoderOptionsSetEffort(m_opt, 3)); static constexpr JxlPixelFormat PFMT { .num_channels = 3, .data_type = JXL_TYPE_UINT8, .endianness = JXL_NATIVE_ENDIAN, .align = 0 }; m_info.xsize = width; m_info.ysize = height; m_info.bits_per_sample = 8; m_info.num_color_channels = 3; m_info.intensity_target = 255; m_info.orientation = JXL_ORIENT_IDENTITY; JXLEE(JxlEncoderSetBasicInfo(m_enc, &m_info)); JxlColorEncoding color_profile; JxlColorEncodingSetToSRGB(&color_profile, JXL_FALSE); JXLEE(JxlEncoderSetColorEncoding(m_enc, &color_profile)); JXLEE(JxlEncoderAddImageFrame(m_opt, &PFMT, buf, width * height * 3)); JxlEncoderCloseInput(m_enc); ```

🤔

<@!768090355546587137> any idea what this could be? I haven't tried the encode api yet but something seems weird here

<@!78807526392475648> could you share your output files?

```diff - xyb_encoded = True, + xyb_encoded = False, ```

only difference I can see

looking at the headers, that is

yeah unfortunately I don't know what "xyb" means here, and "xyb" doesn't appear anywhere in `encode.h` so I'm not sure if it's something I even have control over from my end

It's a colourspace - as for how to control it, or why its resulting in such different file sizes, idk

(I'm not a libjxl dev, hopefully someone knows)

if it is indeed related to colorspaces, and resulting in the drastic file size issues, then perhaps it might be some sort of bug with `JxlColorEncodingSetToSRGB`?

just a shot in the dark of course

btw, it's the libjxl one that's using xyb

fwiw, they both have identical FrameHeaders

another thing perhaps worth mentioning is that both `cjxl` and `libjxl` take roughly the same amount of time on their respective effort settings

and also just to clarify, I also tried effort 5 and 7, and this issue of the libjxl file being larger persisted on every effort setting

Why is it using xyb when doing lossless? That doesn't make sense

Can you open an issue? It's an api bug

Xyb will not be lossless, but it will have a lot of precision so it will also not be far from lossless and use way too many bits

Basically in modular it would convert 8-bit rgb to something like 14-bit xyb

That should normally only happen if you're going to do lossy modular and the xyb will get quantized anyway

that must be it, because the cjxl output is roughly 8/14 the size of the libjxl output

For lossless it doesn't make sense because even with that precision, it's not perfectly reversible, the result of rgb -> xyb -> rgb will have some rounding errors

Even with 14 bits of XYB precision?

For 8 bit source?

I would expect that when you SetLossless it also changes the encoding to rgb instead of xyb

Yes, after the gamma changes and all, it's not reversible

Not that you will see any difference

Main errors will be where RGB is a bit redundant, I assume

It's quite impossible to do color conversions that are not extremely simple like YCoCg in a reversible way

In integer arithmetic I mean

Everything is reversible with mathematical real numbers, but of course that is a very imaginary concept

I have never seen a real number implemented in practice that isn't a relatively simple rational number (say something of the form a/b where a and b are smaller than 2^2^100)

I hope I did the issue right

It's time the encode api gets some attention, we have been focusing a lot on decode (for browsers)

Thanks for finding bugs!

are you actually sure it wouldn't be reversible with floats and std::round? it seems like it should be precise enough...

with 32-bit floats? yes then it's probably precise enough for 8-bit ints

32-bit floats have 24 bits of precision, so I would think that integers up to 2^24 can be represented exactly in it

after investigating the libjxl code, I figured out that I can explicitly set `uses_original_profile = JXL_TRUE;` to force it to use RGB encoding because of `enc->metadata.m.xyb_encoded = !info->uses_original_profile;`, is this intended behavior?

Correct. I was talking about 8-bit sRGB, convert to float linear RGB, then matrix multiply to get something like LMS, then cube root, to get XYB, and then doing all that in reverse. Do you get the same 8-bit sRGB values out? I said probably but I am not sure.

Right, I see.

Probably best to make -j implicit when target_bpp is used

https://github.com/libjxl/libjxl/blob/9d50ae080734/lib/jxl/enc_frame.cc#L1370 > lies **closet** to Maybe make a list of typos in comments and when enough of them accumulates, make a single commit that fixes them?

I may be wrong, but I don't think that codespell would detect *that* particular typo because "closet" is actually a valid English word, e.g. used in the famous phrase "come out of the closet".

something like LanguageTool might detect it if we somehow pre-digest the data appropriately for its consumption

(removing `//`, this sort of thing)

https://github.com/libjxl/libjxl/blob/fc564718416da689629/deps.sh#L62 Isn't that supposed to be a comment?

looks like informational message explaining what is happening and what command is getting ran

So why is there no `echo`?

Is that even allowed?

it’s a heredoc

the relevant feature here is actually from the shell

Damn, I didn't know you can do such things

cat echoes stdin, and stdin in this case comes from bash using special syntax

I mean the very syntax to pass a big string as stdin

or not experienced one

https://stackoverflow.com/questions/2500436/how-does-cat-eof-work-in-bash explanation incase you're interested

<@456226577798135808> > You are clearly a non-Linux user then I use Linux, just not that often (I'm on WSL2 on Win10)

doesn't count so on-point comment :v)

tbh it's more of shell wizardy than linux thing im sure many linux users who aint into that probably won't know all its tricks

Meh, I've been using Linux nearly exclusively for over 10 years and only used a heredoc once.

I think I’ve used them once or twice, but actually more often in perl than in *sh

Big thanks for that tool, it's awesome! My PR has just gone live 😃

I've been adding a lot of test cases to https://github.com/libjxl/conformance

it's JPEG meeting next week

we need to work on Part 3 - conformance

> ```cpp > // TODO(deymo): Remove "gradient" once all clients stop setting this value. > // This flag is already deprecated and is unused in the encoder. > Override gradient = Override::kOff; > ``` Can it be removed now? https://github.com/libjxl/libjxl/blob/f9bab66674d270fd6a0e73759f9887a668c6d287/lib/jxl/enc_params.h#L156-L158

I think so

This is something ancient now

What was it even supposed to do?

it was a banding mitigation system, there's a different one now

Is there a new release planned for 2021?

No more temp files, I've already checked <:FeelsAmazingMan:808826295768449054> https://github.com/libjxl/libjxl/pull/300

The `tools/cmakelist.txt` file has a flag `JPEGXL_VERSION`. But if you try to set `-DJPEGXL_VERSION` to some value when building `libjxl`, it will be ignored.

In `build.ninja` this flag is always set to `(unknown)`. So I started replacing it with the last commit, using `sed` after `cmake` before `ninja`. Now my binaries can show which commit it is.

``` PS > cjxl -V cjxl v0.3.7 8119fe5 [SSE4] Copyright (c) the JPEG XL Project ```

The question is, can the devs make it so that building doesn't ignore the `-DJPEGXL_VERSION` flag? Or is this flag used for something else? 😄

What's your exact command?

Nice! Would it be possible to change the commit hash to an 8 char long one?

```Bash #!/bin/bash export CC=clang CXX=clang++ cd libjxl git pull git submodule update --init --recursive version=$(git describe --always) rm -rf build cmake -B build -G Ninja -S ./ \ -DCMAKE_BUILD_TYPE=Release \ -DBUILD_TESTING=OFF \ -DJPEGXL_ENABLE_DEVTOOLS=ON \ -DJPEGXL_ENABLE_OPENEXR=OFF \ -DJPEGXL_ENABLE_SKCMS=OFF \ -DJPEGXL_ENABLE_BENCHMARK=ON \ -DJPEGXL_WARNINGS_AS_ERRORS=OFF \ -DJPEGXL_STATIC=ON \ -DCMAKE_C_FLAGS='-O3 -march=native' \ -DCMAKE_CXX_FLAGS='-ffunction-sections -fdata-sections -O3 -march=native' \ -DCMAKE_EXE_LINKER_FLAGS='-Wl,--gc-sections -Wl,--no-export-dynamic' sed -i -e 's#(unknown)#'"$version"'#' build/build.ninja ninja -C build strip -s build/tools/{cjxl.exe,djxl.exe,butteraugli_main.exe,ssimulacra_main.exe} ```

To get the commit hash, I just use `version=$(git describe --always)` without any modifications.

In fact, you can write anything you want: 😄 ``` $ libjxl/build/tools/cjxl -V cjxl v0.3.7 8119fe5_super_puper_duper_build [SSE4] Copyright (c) the JPEG XL Project ```

To use the `-DJPEGXL_VERSION` flag when building, simply define the `JPEGXL_VERSION` variable in `CMakeLists.txt`. Something like this: ``` set(JPEGXL_VERSION "" CACHE STRING "JPEGXL version.") ``` Then use it in your building script: ```Bash version=$(git describe --always) cmake -DJPEGXL_VERSION="$version" ```

This looks like a bug. The flag is used in `ci.sh`, but will be ignored because the variable isn't present in `CMakeList.txt`.

<@!179701849576833024> What percentual decoding cost does noise currently have?

after my PR that enables SIMD, I think it makes things about 30% slower or so

(as opposed to ~2x from before)

but there's still improvements to be done

👍

So, from what I've seen in the recent patches that Jyrki has introduced, I'm guessing the main improvements are being done toward anything related to edges, correct?

So, why not force split to smaller blocks where the current analyzed partition contains at least one sub block with very low variance and at least one that has much higher variance to actually prevent ringing propagation?

I did want to try something like that, haven't had time yet

IIUC libjxl doesn't directly expose any interface to retrieve TOC, right? (I was thinking of calculating the prefix size required for given downsampled images and/or LQIP.)

not yet but it should have something like that imo

Will there be more noise types other than photon_noise? I took a somewhat closer look and noticed that the setting produces a bit too little noise in dark and a bit too much noise in bright areas than I would like.

you may want to increase `kInputReferredReadNoise` and decrease `kPhotoResponseNonUniformity`

the noise modeled by `enc_photon_noise.cc` is a quadrature sum of three noise regimes: read noise (constant standard deviation, so most notable in the shadows), photon shot noise (square root, dominant over a large range) and photo response non uniformity (linear, dominant in the bright tones)

I decided that 3 electrons rms of read noise and 0.5% PRNU were reasonable defaults but they are not the only possibility

(although PRNU in most cameras is more often higher than that rather than lower)

(over more pixels than typical internet images, though, so it averages out)

the read noise for a given camera at a given ISO setting can be found here: https://www.photonstophotos.net/Charts/RN_e.htm

and PRNU here: https://www.photonstophotos.net/Charts/PTC.htm

in fact, that last link also illustrates the model with its three regimes (the three grey lines)

Can I simply do a pull request with my preferred values? 😁

Is it better ?