JPEG XL

yeah that's weird

could just be the swapped channels though

which messed with CfL

in fact this is *after* correcting the swapped channel in DC 😉

otherwise all DC coefficients would have been off

let me explain what the right (trace from jxsml, sorry I was confused 🙂 actually means:

this is a particular DCT8x8 varblock before and after the HF dequantization (but before CfL)

jxsml did the LF dequantization much earlier and pasted resulting coefficients directly to the same place that HF coefficients are eventually decoded into

the only divergence from the spec right now is that the LF dequantization factors for channel 0 and 1 are swapped

on the left (libjxl) I've matched the format by printing the same thing before and after DequantBlock, where LF and HF coefficients in the former are combined manually

for the apparent CfL, I realized that I can just print the state after CfL in jxsml and HF coefficients seem to totally match libjxl!

so I guess channels are not exactly swapped but just factors are off?

after some hours of headache, swapping LF channels worked and it turns out that CfL for LF and HF happen in different places; the apparently incorrect LF channel 2 was actually post-CfL.

this is no longer false-colored, the general hue is now correct, but there are some strong block artifacts

most likely bug(s) in IDCT

fixed block artifacts, I somehow put 1/sqrt(2) in place of sqrt(2) (why????), now it's quite smooth

remaining blocky artifacts disappear when I disable LF smoothing, so there's another place to find bugs

great, LF smoothing bug was a rather simple one. after fixing an off-by-one error in PNG writer and the final linear-to-sRGB conversion, this is the first ever correct VarDCT image produced by jxsml!

(sans epf)

nice!

Very cool, now the two main things are done (vardct and modular) and there's only the optional coding tools left.

(optional for an encoder I mean)

well not exactly done, for example I have this hot mess 🙂

Partially done let's say :)

I should also write all the issue I have been ignoring so far (I have taken notes though)

originally this was the goal, we have slipped from it a bit when focusing more on less embarrassing performance at d3 to d8 and on encoding speed -- I think we need to go back to optimizing d1 robustness at some later stage

we have ideas on how to improve lossless decoding speed to similar levels of PNG and WebP lossless, we just haven't been able to prioritize implementing/exploring them -- we are focusing on the ABI/API (libjxl 1.0), security, bug fixing, progressive, and HDR

There were some changes in the main jxl decoder loop recently, and as a result there are some guarantees now for the return values of JxlDecoderReleaseInput, meaning that one can infer the file positions of certain codestream elements from it. I documented these here: https://github.com/libjxl/libjxl/pull/1546 Any suggestions for further improving the input handling are welcome.

<:This:805404376658739230> <@853026420792360980> <@886264098298413078>

noice

today in jxsml: implemented all the transforms except for Hornuss (which is not used in this particular example), and the result is this patchwork

https://gist.github.com/lifthrasiir/137a3bf550f5a8408d4d9450d026101f#file-jxsml-c-L3999-L4119 featuring not yet verified "optimized" AFV4x4 implementation

not very sure which transform(s) are at fault, probably larger ones are not working at all

These are nice for the <#805007255061790730> channel

posted (https://discord.com/channels/794206087879852103/805007255061790730/992107107342102689), the full image is about 20 MB in png so I had to downscale though

today in jxsml: turned out that I've implemented initial transposition incorrectly in larger DCTs, here's a bit better patchwork

oh not bad at all 😄

it's not *too* hard to convince the encoder to skip emitting some blocks

but it's also not hard to visualize the choices

so figuring out which transforms are wrong shouldn't be *too* hard

I do have some sort of map, but I think many transforms are _not_ entirely buggy so that I can't pinpoint particular transforms easily; the map for instance shows that at lest DCT8x16 and DCT16x8 have that sort of problem

and my code organization is too crappy that I can't easily tell the code is correct or not, I should set up some naming convention to ease my verification first

and I should play Satisfactory less lol (in case you haven't realized from my Discord profile)

i haven't been doing pmuch anything valuable lately it feels kinda good to be unproductive & weather is nice out too

uhhh, the tutorials on caniuse, github, and jpegxl.info don't match up with how Edge Canary works on Windows 11. Been hunting for Local State, but it doesn't exist in the same location where it used to. Got it working with Chrome Canary and Firefox Nightly on Win11 at least.

Maybe Msft is still salty about XR not being widely adopted, lol. XL isn't in the flags/experimental features page in Edge anymore.

It isn't? Wonder what happened there...

Someone requested JXL support at Samsung forum ( https://us.community.samsung.com/t5/Galaxy-S21/Saving-images-as-JPEG-XL/m-p/2305032 ). Many people don't know what JXL is yet.

I don't remember the details, but in MS Edge, it was necessary to manually edit some config file and it had to be done from a different OS because otherwise Windows just reverted the file back. But I'm not using MS Edge anymore, it got very slow and laggy few versions ago.

Time to spam miui forums.

No

Don't you want jxl support in miui cam app?

~~RAW or bust~~ <:BanHammer:805396864639565834>

There is already an option for dng on many OEM camera apps.

What does the [Emu128] option mean? I've just noticed it showing up recently.

Ah, so its an compile target for non SSE CPU's then?

Thanks.

Yeah, I am using the S21 and thought of leaving it there in case someone from the team saw

I hope it gets implemented soon enough, as I see no reason for delays

jpeg XL can use modular and vardct in one image? technical?

With patches, yeah.

Or using layers

<:Thonk:805904896879493180>

today in jxsml: before and after

varblock boundary is artificially added; the main difference was to fix the natural order, which was incorrectly written as if C <= R due to the wrong reading and I forgot to fix it later

ah nice progress

So now dct8x8, 8x16 and 16x8 work?

DCT8x8 and above share the same code, so I should say the majority but not entirety of them work

varblocks with red borders here are DCT16x16, which seems to be more fragile

8x16 and 16x8 has become definitely more stable

I wrote that GitHub tutorial, haven't looked into it for a while. Yeah, I've also had some problems enabling JXL in later editions of Edge, I couldn't find that flag either. Fortunately if you set it up in an older version, it also works in later ones. Just checked in my Edge 103, it works.

Does ImageGlass support flicker test comparison of images?

Or any other image viewer that supports JXL for that matter?

It'd be really convenient because right now I just use tiling to do side-by-side comparisons

qimgv has an option to keep zoom level when switching images (`lockZoom` shortcut in settings)

What I often end up doing is just opening two images in two browser tabs and switching rapidly between those with keyboard shortcuts.

I believe the one that is in the libjxl codebase supports it

build with `cmake -DJPEGXL_ENABLE_VIEWERS=ON` and then `tools/comparison_viewer/compare_images a.jxl b.jxl`

(needs Qt5, and currently only ported to Windows and Linux, not macOS)

it can optionally take a third image which will be shown in the middle (or with the up/down arrow key)

I don't use the 8x8 DCT blocks much, since there is no implicit low-frequency spatial interpolation there, and they induce blockiness -- in pik we had beautiful interpolation, but we removed that in jpeg xl when we added variable size dcts

that's why there is a lot of 16x8s

(I have some ideas on how to improve on that)

https://thebombzen.com/Orange-Diff/

this is a thing I wrote a bit ago to compare images

you give it two URLs and it makes it easy with just mousing in and out

it just puts it in the query string too

https://thebombzen.com/Orange-Diff/?imagea=https%3A%2F%2F0x0.st%2FzokR.png&imageb=https%3A%2F%2F0x0.st%2Fo1Jy.jxl

working on jxsml public interface, which was never a concern until now

what made it a concern?

ah, I meant that I never really thought about that, so the entire architecture was oblivious of the API

<@179701849576833024>was it on purpose that the 2 newest cjxl versions on your artifacts thing don't work on their own anymore? :p

I certainly didn't do it on purpose :P also it's a GitHub issue not mine, I just download the artefacts from there :P

They now require jxl.dll and jxl_threads.dll

Ah, yes

It may make sense to link them statically on windows

And the executable is like... 10% the size. Guess it's cjxl_ng and not cjxl

The total size should be smaller, I hope

cjxl is now much smaller, but djxl isn't

Like 600KB vs. 5MB

Interesting, I'm testing the fresh, new cjxl and I see this: JPEG XL encoder v0.7.0 66afb51 [SSE4,SSSE3,Emu128] Read 640x400 image, 4226 bytes, 452.2 MP/s Encoding [VarDCT, lossless, effort: 7], Compressed to 6717 bytes (0.210 bpp). 640 x 400, 1.64 MP/s [1.64, 1.64], 1 reps, 4 threads.

Didn't know that VarDCT can do lossless. Looks like an oversight.

it can't, that's a bug

how did you trigger it?

I've got a png file and encoded did using just -d 0

cause if I run `cjxl -d 0 foo.png foo.jxl` it uses modular

lemme update to master and try agin

I will try one more thing.

I've tried another PNG and it's the same thing. The output is actually lossless though.

like bit-exact lossless?

interesting

what happens if you run`jxlinfo` on the file?

https://github.com/libjxl/libjxl/blob/66afb51bb4f132f205ba16d236993ebf8fdba89f/tools/cjxl_main.cc#L488-L492 < It doesn't take distance into account

JPEG XL image, 3784x2664, (possibly) lossless, 8-bit RGB num_color_channels: 3 num_extra_channels: 0 have_preview: 0 have_animation: 0 Intrinsic dimensions: 3784x2664 Orientation: 1 (Normal) Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Perceptual

It still has a discontinuity at quality=30...

looks like it's just a bug in the printing

<@688076786525143117> <@268637846355574786> https://github.com/libjxl/libjxl/issues/1627

it's pretty annoying (not _difficult_) to make the existing source code even vaguely stream-aware

so I don't want to make jxsml to be able to fully pause and resume, which will definitely make it much more complex

but I do have to ensure that a partial reading doesn't cause a fatal error

and so far jxsml has assumed that everything is in the (consecutive) memory

so some hard error conditions now have to be soft, which doesn't fit well within the current architecture

*yes*

it's one of the reasons why I really like coroutine-based control flow, it makes such things *almost* trivial

time to take a look at libjxl to see how it did 😉

yeah, if coroutines are available that's generally a way to go, but sadly C doesn't have one

in short: for headers it generally tells you "nope, too little data", "error" or "success"

for most other things, it works on group-level granularity

i.e. either you decode an entire new group, or you decode nothing

the main exception is the ICC stream, which doesn't have a length, so it has some resuming logic

yeah, that looked like a good middle ground to me as well but there is some complication specifically in jxsml

jxsml so far didn't distinguish (let's call) soft errors from hard errors, any non-zero `jxsml_err` terminates the decoding and propagates to the caller

the "too little data" condition is now a soft error, so it looked like that the existing `shrt` (for "short") error can be repurposed for this

and then I realized that I never guaranteed that jxsml error codes are distinct!

I mean, the error string `"shrt"` *is* unique in the source code, but it gets translated to `jxsml_err` type and that can coincide with other error strings

so that made me reconsider the whole error code system

but I realized that, while describing all those problems, I can make the softness of the error code independent from the error code itself

I should note that this is a bit contrived concern, since this can't happen when `CHAR_BIT <= 8`

and I like how the error code is rendered in the source code (almost every string literal is an error code, increasing the visibility)

pretty sure standard C requires CHAR_BIT >= 8

yeah, just in case though 😉

I even thought about translating all characters into ASCII in such cases

```c #if CHAR_BIT <= 8 #define JXSML__1(c) (uint32_t) (c) #else #define JXSML__1(c) (uint32_t) ('0' <= (c) && (c) <= '9' ? (c) - '0' + 0x30 : \ (c) == 'a' ? 0x61 : (c) == 'b' ? 0x62 : (c) == 'c' ? 0x63 : (c) == 'd' ? 0x64 : \ (c) == 'e' ? 0x65 : (c) == 'f' ? 0x66 : (c) == 'g' ? 0x67 : (c) == 'h' ? 0x68 : \ (c) == 'i' ? 0x69 : (c) == 'j' ? 0x6a : (c) == 'k' ? 0x6b : (c) == 'l' ? 0x6c : \ (c) == 'm' ? 0x6d : (c) == 'n' ? 0x6e : (c) == 'o' ? 0x6f : (c) == 'p' ? 0x70 : \ (c) == 'q' ? 0x71 : (c) == 'r' ? 0x72 : (c) == 's' ? 0x73 : (c) == 't' ? 0x74 : \ (c) == 'u' ? 0x75 : (c) == 'v' ? 0x76 : (c) == 'w' ? 0x77 : (c) == 'x' ? 0x78 : \ (c) == 'y' ? 0x79 : (c) == 'z' ? 0x7a : (c) == '!' ? 0x21 : (c) == '?' ? 0x3f : 0) #endif #define JXSML__4(s) (jxsml_err) ((JXSML__1(s[0]) << 24) | (JXSML__1(s[1]) << 16) | (JXSML__1(s[2]) << 8) | JXSML__1(s[3])) ```

I find the easiest way to do it is to have an encode thread that simply blocks if input is not available

<@268284145820631040> `sizeof(char)` is by definition 1

so provided that there's exactly 8 bits in a byte, then this macro is unnecessary

I don't see any reason to attempt to run on hardware that doesn't follow that standard

I thought that the code's intention to support `CHAR_BIT > 8` case is clear enough

.... why?

there's no hardware where there's more than 8 bits in a byte

`CHAR_BIT` is a compiler contract, not necessarily an architecture contract

so there _do_ exist some platforms where `CHAR_BIT` is larger than 8, regardless of architectures (and there also do exist some architectures where `CHAR_BIT > 8` is necessary, but they are much rarer)

I know they are very rare and not practical to ensure the proper support, but given that the code is supposed to be a portable C code I don't see the reason to check about that kind of technicalities

I will never actively test on those platforms though

I don't see the point in supporting anything other than exactly 8 bits in a byte

since you can't test on those weird scenarios, saying you support them has security implications

it's better to refuse to support code you cannot test

cause I can immediately see that you #define JXSML__4 with an 8-bit assumption

`(JXSML__1(s[0]) << 24)` should probably say `(JXSML__1(s[0]) << (3 * CHAR_BIT))`

you have a good point, though "support" can mean a multitude of things and it seemed like a low level of support is achievable without too much cost

and I'm sure the code is riddled with that implicit assumption that `CHAR_BIT == 8`

I thought I'm aware of all such assumptions (mostly bit readers), but I realized that I'm not sure about file handling on those platforms

yeah, that alone is enough to revisit my position

oh btw yurume, how buggy is the latest version of the spec?

when it comes to VarDCT or Modular

Lynne is busy so I might just write my own jxl decoder but I'm not really interested in doing so if the spec is still quite buggy

I'm relatively certain that I've found most Modular bugs, but VarDCT implementation is still on the way and it will take a lot to check if the supposed "bug" is actually a bug or just my mistake

hm

in order to decode modular, I already have a working entropy decoder, I wonder how much extra needs to be done

one quick way is to grep "spec" in the current jxsml code

I mean I wonder how much extra needs to be implemented

to decode Modular you will need entropy decoder (you've done this), MA tree parser and evaluator, predictor, and some transformation support (not all of them is required, you can for example skip Squeeze for now)

If you target fjxl output, you can skip squeeze and the weighted predictor, which are probably the two hairiest ingredients of modular...

the approximate number of LoC in jxsml is as follows: entropy decoder takes ~800 LoC, predictor takes ~350 LoC, two out of three inverse transforms take ~250 LoC, and the remainder including MA tree parser and evaluator takes ~400 LoC

Those 350 lines for prediction is mostly the weighed predictor, no? The others are basically oneliners...

ah, I have groupped them wrong, yes, 350 lines include predictor and MA tree evaluator and most of prediction is for wp.

more accurately, predictor takes ~150 lines and evaluator takes ~200 lines

wp was designed by Alexander Rhatushnyak

Select (developed originally for webp lossless) and the last added predictor (developed for delta palette) were by me

update: https://github.com/libjxl/libjxl/pull/1637

hm, that sounds like a solid amount to implement

how buggy is the spec with regard to this? I feel like I could always cross-reference jxsml to see what's wrong but I'd prefer to not have to do that

weighted predictor is pretty buggy and I think you can't develop it without a reference to at least libjxl or jxsml

hmmmm

I wonder if there's a newer version of the spec that has most of your modular mode findings fixed

jxsml is much more readable than libjxl so I referenced it when working on my entropy decoder

(for Modular) I think there is no major bug besides from wp, if you already went through image headers, ICC and entropy decoder

image header, frame header, ICC, and entropy decoders have been done, yea

I'll have to work on the weighted preditor then

or rather, have to cross-referece

I'll probably do that one last then

I can make an updated spec draft with the WP fixed

today in jxsml: writing a design document can help from time to time

What font is it

Nanum Gothic Coding https://github.com/naver/nanumfont (because I need those fonts to have a proper Hangul support)

g look weird on that font at small sizes.

https://cbloomrants.blogspot.com/2015/09/library-writing-realizations.html

this rings much true especially because I'm designing the very API of jxsml

my current design should allow the following to work without any modification: ```c jxsml image; jxsml_from_file(&image, "path/to/image.jxl"); jxsml_frame *frame; while ((frame = jxsml_next_frame(&image))) { int32_t width, height, stride; uint8_t *ptr = jxsml_frame_u8(frame, JXSML_RGBA, &width, &height, &stride); // ptr[4 * (y * stride + x) + channel] is the pixel data } jxsml_free(&image); ```

note the missing error check; every API call will check for the last error and would not continue, so there should be no frame returned by `jxsml_next_frame` at all if the file can't be read

`jxsml_frame_u8/u16/f32` etc. accepts a channel argument which can be a "pseudo" channel like `JXSML_RGBA` (in which case the result will be an interleaved data)

since `jxsml_frame_u8` etc. should not fail once you are given `jxsml_frame*`, I think it would need some sort of contortion like in-place conversion from separate channels to interleaved channels, but if that's possible I like this design a lot more than alternatives

today in jxsml: provisional documentation (or rather, its table of contents)

what actually *is* XYB

I figure Y is xyY luminance but what about X and B

Y is actually not the same as in XYZ/xyY

if (r', g', b') = cbrt(opsin absorbance matrix × (r, g, b) + opsin absorbance bias) then X is (r' − g')/2, Y is (r' + g')/2 and B is b'

(if I got things right)

It's basically L-M,L+M,S with a cube root + bias transfer function

Color blind people (protanopia or deuteranopia) can just drop the X and it will be fine

https://pillow.readthedocs.io/en/stable/handbook/image-file-formats.html#:~:text=This%20is%20currently%20supported%20for,scaling%20down%20the%20main%20image. Does anyone know any alternative or fork which support jxl?

nvm. found one. https://github.com/olokelo/jxlpy

LMS was meant to address the non-constant luminance of YCbCr, right?

But then what is YcCbcCrc that I have also seen references to?

Or am I confusing it with ICtCp?

LMS models the response of the three types of cone cells

Then what transfer curve to apply is another thing

`(r', g', b') = cbrt(opsin absorbance matrix × (r, g, b) + opsin absorbance bias)` so so if you have an `(r, g, b)` vector you take an affine transformation on it, and then cube-root it component-wise to get `(r', g', b')` but what color space is the initial rgb vector in?

in my understanding that affine transformation (with suitable parameters) should be enough for sRGB

according to the spec: "The resulting RGB samples correspond to sRGB primaries and a D65 white point, and the transfer function is linear. [...] The decoder can choose different primaries or white point by first multiplying inv_mat by a matrix converting from sRGB to the desired primaries and/or from D65 to the desired white point."

oh, so `(r, g, b)` is linear sRGB

how does that work with wide gamut, are r, g, and b just float values with out of gamut (i.e. `< 0 or > 1`) permitted?

I assume it gets just extrapolated

Yes, just out of range values for wide gamut

Which is not an issue when working with float

today in jxsml: finally got the pseudo-streaming code compiled, fixing all sort of fallouts...

and I really need to write a proper test

Can also use a different matrix to convert xyb to rgb with wider gamut primaries

how does grayscale work then?

if `r = g = b` that doesn't necessarily imply that `r' = g'` and that `b' = 0`

so how can you drop the X/B channels in that case

What is typically encoded is X,Y, B - 1.0*Y (the default chroma from luma factor for B is -1.0)

In grayscale, X is 0 and Y=B.

ah mb

Y=B makes more sense than B=0

XYB is something that I fitted to my eyes, and later tested that it works better than traditional colorspace for other humans, too

'colors as seen by Jyrki' 😛

Luca normalized it a bit differently for JPEG XL so that it was easier to model grayscale

I didn't use Lab, XYZ or other classically approved approaches to derive XYB

I just went for whatever works best

I used several monitors for it, photography processing monitors from EIZO and NEC as well as a google pixelbook and a simple old Dell monitor

all experiments used pixels that were roughly 900 pixels away from the eye

in the original XYB there are two colorspaces and a logarithmic compression function

one colorspace is for low frequency colors, involving a lot more blue (S receptor) sensitivity

another colorspace for high frequency colors (roughly wavelength 8 pixels and shorter)

this one has less blue impact in it

(and even that is just ignored at even shorter spatial wavelengths)

... now a question -- how do we generate colors with spatial wavelengths

one can do it with for example having some background color, let's take gray (0.5, 0.5, 0.5) for simplicity

let's add a color (0.0, 0.1, -0.1) to it -- we add it to some number of consequent pixels, I'd usually use 8 pixels

then the next neighboring eight pixels I'd use the opposing color (0.0, -0.1, 0.1)

repeat a few times, and you have a spatial high frequency color experiment

I usually repeated this 4 or 8 times

sometimes I'd use text with dilation shadow to experiment this in a more complex setting

the original XYB has a biased logarithmic compression function

in JPEG XL we still have it, but we approximate part of it with a biased cubic root

the other part we put explicitly in the adaptive quantization matrix (which is just wrong, because the quantization affects more than just one pixel) -- but it turns out to be helpful in any case and makes a better balance of bright and dark areas

biasing the logarithm makes the compression to be linear at the lowest intensity (like the sRGB linear segment) then roughtly gamma=2.6 and logarithmic at very high values

today in jxsml: fixed an unbelievably stupid bug ```diff JXSML_ALWAYS_INLINE int jxsml__(ceil_lg,N)(jxsml__uintN_t x) { - return x > 2 ? JXSML__N - JXSML__CLZN(x - 1) : 0; + return x > 1 ? JXSML__N - JXSML__CLZN(x - 1) : 0; } ```

I have almost finished a restructuring and am now writing some initial tests, and that test caught this bug

i bet you meant >= 2 hehe

well the code operates on `x - 1` so I must have simplified `x - 1 > 0` wrongly

today in jxsml: I now have a fully tested inverse transformation (including Hornuss) and coefficient order code and something is still wrong

those glitches only appear in _some_ AFV varblocks and _some_ DCT16x16 varblocks or larger

That's intriguing

All or none is more expected

Something about the adaptive quant weights maybe?

yeah, that's probably the next target to test

I think there is something with strong horizontal stripes seen in glitched DCT16x16+ varblocks

Did you compare dequanted coeffs before idct between jxsml and libjxl?

I have a code for doing that, but there are too many varblocks there and it will take some time to see the actual culprit (in fact, this is why I switched to a much smaller image)

alternatively: I think libjxl does have some sort of debugging dump code, is it documented somewhere?

okay, fixed AFV; this is yet another incorrect default parameters, this time in DCT4x4 (AFV also refers to this)

```diff #define JXSML__DCT4X4_DCT_PARAMS \ - {843.649426659137152f, 289.6948005482115584f, 137.04727932185712576f}, \ - {0.0f, 0.0f, -0.25f}, {0.0f, 0.0f, -0.25f}, {0.0f, 0.0f, -0.5f} // (4) + {2200.0f, 392.0f, 112.0f}, {0.0f, 0.0f, -0.25f}, {0.0f, 0.0f, -0.25f}, {0.0f, 0.0f, -0.5f} // (4) ```

since errors are only in the first channel, glitches appeared only for some varblocks where that channel is not all zeroes

I sometimes wonder why we bother making a spec instead of some minimalistic unoptimized readable reference decoder implementation. Specs are not executable and that makes it super easy to get unnoticed bugs in them...

When jxsml is done, we should probably declare it an alternative reference decoder at some point. I have a feeling it will be more useful than libjxl to be an "executable spec" for other implementers to use as a starting point / reference.

okay, I think I'll refactor things a bit more

I'm fed up with doing manual 2D offset calculations by now

there would be `jxsml__view2d` type or similar instead

I originally didn't plan to make such types because I wasn't sure which operation would be needed for them and I thought the complexity can be probably confined (libjxl also seemed fine without such types, only lightly typed), but oh my, ever-transposing matrices make everything confusing

for a long time I already had comments like `/*RxC*/` to make sure that I haven't mixed dimensions, but by now it feels inadequate

and I think I have a good list of all operations I would actually need

```c // current: JXSML_STATIC void jxsml__inverse_dct32(jxsml__st *st, float *buf) { float scratch[64], tmp; int32_t x, y; tmp = buf[000] + buf[010]; buf[010] = buf[000] - buf[010]; buf[000] = tmp; jxsml__inverse_dct(st, scratch, buf, 2, 16); jxsml__transpose2d(st, buf, scratch, 8, 8); jxsml__inverse_dct(st, scratch, buf, 3, 8); for (y = 0; y < 8; ++y) for (x = 0; x < 8; ++x) buf[y * 8 + (x % 2 * 4 + x / 2)] = scratch[y * 8 + x]; } // hopefully: JXSML_STATIC void jxsml__inverse_dct32(jxsml__st *st, float *buf0) { float scratch0[64]; jxsml__view buf = jxsml__make_view(8, 8, buf0); jxsml__view scratch = jxsml__make_view(16, 4, scratch0); int32_t x, y; { float *p00 = jxsml__view_xy(buf, 0, 0), *p10 = jxsml__view_xy(buf, 1, 0); float pp00 = *p00 + *p10, pp10 = *p00 - *p10; *p00 = pp00; *p10 = pp10; } jxsml__reshape_view(&buf, 16, 4); jxsml__inverse_dct_view(st, &scratch, buf); jxsml__transpose_view(&buf, scratch); jxsml__inverse_dct_view(st, &scratch, buf); jxsml__view_vshuffle_oddeven_to_halves(buf, scratch); } ```

what I needed was to identify operations like "shuffle_oddeven_to_halves" so that they can be individually verified

I wonder what is more intellectually challenging -- coming up with the new formats or trying to implement the first decoder from the spec

in any case, highest respect to you yurume

today in jxsml: a prototype of the "Quick Start" section of the documentation

you may notice minor changes from the previous example codes, and that's a result of me pondering about various failure modes

for example `jxsml_frame_u8x4` (now `jxsml_frame_pixels_u8x4`) used to return the frame's width, height and stride into the out pointers, but I switched to a dedicated struct because out pointers can be pretty tricky to use

for example jxsml always uses `int32_t` for typical integers, including conceptually unsigned integers like width and height; this means that those out parameters have a type of `int32_t*`.

aaaand I think many people especially more proficient in C will assume `size_t*` instead 🙂

using structs seems more robust in this kind of type mistakes

today in jxsml: yet another facepalm, this time in DCT4X8 dequantization matrix... ```diff jxsml__dct_quant_weights(4, 8, bands, n, scratch); for (c = 0; c < 3; ++c) { for (y = 0; y < 8; ++y) for (x = 0; x < 8; ++x) { - raw[y * 8 + x][c] = scratch[(y / 2) * 4 + x][c]; + raw[y * 8 + x][c] = scratch[(y / 2) * 8 + x][c]; } raw[001][c] /= params[0][c]; } ```

it (hopefully) looks like the last major bug from dequantization matrix handling

(difference)

I'm now sure that the remaining artifact is very likely from LLF reconstruction, which explains weird strips; those values are relatively large (say, 5) and overwhelm IDCT and subsequent processes

That makes sense

x

ah firefox fixed it

still it crashes one page too times on windows 7

i would like a better font

i' m using that

https://github.com/niklas-ekholm/Bookish-Variable

but i need a 3.0 version.

he is at 2.012

look it isn't updated in 5 years

before I used iosevnya and was useful for github

i did also webp2

cwp2 C:\Users\Use\Music\d\a.png -o C:\Users\Use\Music\d\as.wp2 dwp2 C:\Users\Use\Music\d\as.wp2 -o C:\Users\Use\Music\d\e.png webp2 makes the orange where there is red more saturated but has good quality don't know if we need them if there is jpeg xl for %i in (C:\Users\Use\Music\dd\*.png) do cjxl -d 1 -e 7 "%i" "%i.jxl"

svt 1.2.1-7 is the first in a month with no encoder improvements; same as svt 1.2.1-6

look he has also this project

https://github.com/Heptazhou/Saranya/releases/tag/v15.5.2-1

yesterday also I did a lot of changes for jxl and av1 italian wiki

look like on jpeg xl the contributions of other users are inexistent

and last was 24 june 2022

av1 was 12 august 2022, 18,27 july and 10 july 2022

3 july and 15 april

> <#794206087879852106>

I've found a quite substantial spec bug in LF-to-LLF transformation, but that was somehow unrelated to this glitch... how?

will have a dinner and revisit this

anyone know the color temperature of D65 off the top of their head?

isn't that supposed to be 6500 K?

is it? that's the question

I looked it up on wikipedia, it appears that is the intent yea

D50 is 5000K, D65 is 6500K, etc.

> The CCTs of the canonical illuminants, D50, D55, D65, and D75, differ slightly from what their names suggest. For example, D50 has a CCT of 5003 K ("horizon" light), while D65 has a CCT of 6504 K (noon light).

> As explained in a previous section, this is because the value of the constants in Planck's law have been slightly changed since the definition of these canonical illuminants, whose SPDs are based on the original values in Planck's law. In order to match all significant digits of the published data of the canonical illuminants the values of M1 and M2 have to be rounded to three decimal places before calculation of SD.

yes, it is *supposed* but not exactly AFAIK

yay, after hours of debugging it boiled down to the layout of LLF coefficients, again (hah)

let's imagine DCT16X16 varblock for example, its LLF coefficients (4 of them) logically precede all remaining HF coefficients (252 of them), but in the coefficient order they are actually interleaved, especially if you want to reuse a coefficient array as a matrix after simple reshaping (LLF coeffs will be then at indices 0, 1, 16 and 17)

and I seemed to keep forgetting that LLF coefficients are not necessarily first coefficients, mixing conventions here and there

so the stripe glitch happened because, well, basically *unquantized* LLF coeffs (large) overwrote *quantized* HF coeffs (small)

at the root of all this struggle is my original design to keep LLF coeffs and HF coeffs in the same array

I think this is still possible, but won't be any clearer than the alternative

that is to split LLF coeffs and HF coeffs, dequantize separately and only combine them right before IDCT (as libjxl does)

aaargh.

That would be a CCT of 6500K.

um akshually it's xyY 0.3127 0.329 which is closer to 6504

hahaha

much better. (I accidentally deleted all HF coefficients for B)

almost! (fixed incorrect argument ordering to `jxsml__forward_dct2d_scaled_for_llf`, causing most LLF coefficients to be NaN)

aaaand yes

the last bug fixed was to correctly transpose LLF coefficients during the final merger

a larger sample also works, differences exist solely because of postfilters

to celebrate this moment I've updated a long-neglected gist: https://gist.github.com/lifthrasiir/137a3bf550f5a8408d4d9450d026101f

👏💪👍🎉

Does this mean both Modular and VarDCT are now working? Except probably multi-pass?

That's great! The things left now should be relatively easy since they're mostly independent and not that complicated things.

Gaborish should be very simple. EPF is a bit more stuff but still only a (fancy) filter. Patches are easy, just work to implement all the blend modes and saving reference frames correctly (but most of that work is overlaps with what is needed for frame blending). Splines and noise can be tested pretty much in isolation from everything else so should also be relatively easy.

Getting Modular and VarDCT right is the hard part, because they both consist of quite a few interdependent components so when there are spec bugs or implementation bugs, it's tricky to figure out what exactly is going wrong...

yes, no multipass and JPEG yet.

What's missing for jpeg?

YCbCr conversion and JPEG-specific upsampling I think?

YCbCr is easy enough to add

For 4:4:4 jpegs

basically everything not triggered by typical images encoded with `cjpeg`

yeah, color space conversion should not be that hard, upsampling is probably a next big task

The upsampling is maybe a bit trickier, or rather not the upsampling itself but knowing where the coeffs of the downsampled channels are. Spec might be a vague or wrong about that...

by the way: https://gist.github.com/lifthrasiir/137a3bf550f5a8408d4d9450d026101f

I've picked the name.

J40? What does it mean?

4 does kind of contain an X and an L, with some imagination and depending on font I guess

Hint: Roman numerals.

Ah lol

XL is indeed 50-10=40

Now we need a j2k implementation called JMM 🙂

Oh that's lovely

Anyway, XL being equal to 40 occurred to me suddenly and I knew this is it

I like it

The old JPEG we often call JPEG 1. JPEG 2000 is also known as JPEG 2 (e.g. .jp2), but you could also say it's JPEG 10 (X) since they use .jpx for the extended file format of part 2. Then I suppose you could say JPEG XR is a kind of JPEG 20 (XX), JPEG XT is JPEG 30 (XXX), which brings us to JPEG XL which is JPEG 40. 😅

JPEG XR (aka JPEG 2010), JPEG XT (aka JPEG 2015), JPEG XL (aka JPEG 2020)? :-p

I agree with this name. https://discord.com/channels/794206087879852103/794206170445119489/827096470590193674

today in j40 (formerly jxsml): after some refactoring...

I'm in process of refactoring most if not all 2D array operations into more defined system, and fortunately everything seems to work except for this

okay, this is just a PNG writer bug, which didn't honor strides

What's this jxsml/j40? Is is some sort of jxl art?

J40 is an independent self-contained reimplementation of JXL decoder, currently in development

JEI forty sounds pretty nice but does it refer to something?

just curious

40 from a Roman numeral, I like stupid names :p

XL is a roman number, unlike XR, XS and XT we can actually pretend to be JPEG version 40 🙂

it seems that I'm pretty good at coming up with stupid names 😉

roadroller (JS code packer), cursive script object notation (JSON superset), walrus (web authentication library), unison (pan-Unicode bitmap font), kailua (type checker for Lua), esotope (esoteric programming language implementation collection), ...

the stupidest name I ever came up with was APOPCALEAPS: https://sneyers.info/jon_old/apopcaleaps/

I would have named it Popcorn (for POP COMposer), as rn and m is not really distinguishable

basically I like a name that is i) short enough, ii) possibly provoking what it does (but not required) and iii) when one realizes why it's named so, one would facepalm

can someone upload latest win binary? main site is dead

https://github.com/libjxl/libjxl/actions/workflows/release.yaml < I grab them from here

<@268637846355574786>Thanx bud

yeah trying to figure out what's up with my home internet...

well whatever was the issue they fixed it, artefacts repo should be up again

I love it

https://twitter.com/jyzg/status/1562403716468297728 oh, you posted a link to that gist 😉

I kinda expected to see this link in the wild much earlier, but okay

today in j40: realized that, for example, `(J40_RGB, J40_U8X3)` output pair might result in a fractional stride in terms of elements as opposed to bytes

`J40_U8X3` "pixel" format is supposed to return `uint8_t[3]` for each pixel, but I may have to change that to `uint8_t` and let users do the necessary calculation (e.g. `pixels[y * stride + x * 3]` as opposed to `pixels[y * stride + x]`)

but `y * stride + x * 3` is really unappealing, even more prone to error than `(y * stride + x) * 3`

probably I will instead make sure that for u8x3 formats and likes there is no padding at all

uh, actually, thinking about that, *all* pixel formats are more usable when there is no padding, so I probably should drop the possibility of padding at all??

yes, that sounds much better plan

problem is that a bunch of other programs *need* that padding

it can be quite convenient for various reasons to have arbitrary strides

i.e. I think gdk will allocate buffers with a certain stride and it's up to you to make sure you fill it right

hmm!

e.g. encoding a crop or decoding to a rect inside an image buffer can be easily done when padding is allowed

I've looked up gdk-pixbuf documentation and it seems that you can actually create a buffer with rowstride at your choice (`gdk_pixbuf_new_from_data`), as I would expect from pretty much every pixel buffer library

fair

but in general a few things have odd requirements on strides

possibly HW motivated?

yeah, 4-byte boundary seems more common especially in older formats

(e.g. I think BMP has one)

the third solution is to discourage the direct access to `pixels` and give a dedicated function/macro/whatever for accessing each row

I'm already doing this internally (`J40__U8_PIXELS` etc.), so probably I should do that in the public API as well

```diff - fwrite(pixels.ptr + y * pixels.stride, 4, pixels.width, out); + fwrite(j40_row_u8x4(pixels, y), 4, pixels.width, out); ```

hmm

I can actually do some crazy C macro to shorten that into `J40_ROW(pixels, y)`, but well...

<@604964375924834314> do you have any recommendations for a HDR monitor? I still need to let Cloudinary buy me one

I haven’t tried it but on paper, https://www.asus.com/ch-en/Displays-Desktops/Monitors/ProArt/ProArt-Display-PA32UCX-PK/ looks good if within budget

Is it better than apple pro display xdr?

cheaper, more dimming zones, hardware calibration (including uniformity), works with non-mac machines

You want the Samsung Odyssey Neo G7 1440p/4k if you want something top notch in that regard if you cab calibrate it.

odyssey neo is va 💀

Yeah, good VA.

Not mid range VA.

all va is mid range va if it has to be curved

today in j40: I'm reading EPF and oh corresponding libjxl code was much more complex than I thought

https://discord.com/channels/794206087879852103/803574970180829194/1012784002509312010 regarding this btw: is there a small enough CMS out there? Is lcms2 the best choice? Skcms seems to implement a good chunk, but I don't know much about tradeoffs and problems with skcms.

I know of ArgyllCMS, and Mozilla has qcms but I think that's focused more on speed than functionality

ah, I should mention the context: so J40 as it stands can't handle ICC profiles, so my current plan is to reject any file that requires them by default, but that can be overriden by a macro like `J40_USE_LCMS2` which would require lcms2. but if I have a small enough (in terms of LoC) CMS then it may make sense to bundle it alongside with J40.

I agree that having a defined color profile is one of the strengths of JPEG XL and don't want for J40 to ruin that

As far as I understand, skcms cannot convert TO lookup-table profiles (like e.g. cmyk profiles), but for jxl purposes I think it is feature-complete.

yeah, that shouldn't be a problem (ideally J40 should be able to convert to sRGB without a special library and can optionally utilize lcms2 or similar for other profiles)

If the jxl file has some weird icc profile (non-enum rgb, or cmyk), and is not using xyb, then a cms library will be needed

But for the case of xyb or for enum rgb, it should be possible to do things without cms library

does libjxl detect "conventional" profiles and use compact metadata? I think it does regenerate profiles for those compact metadata, but not sure about the opposite direction.

It does, but iirc it only does that when doing lossy

When doing lossless, it will store the icc profile as is even if it is just an enum space, just to be sure

maybe I should detect those cases myself then

(for lossless jpeg recompression this is necessary to reproduce bit-exact jpeg files, for lossless pixels it is not necessary but iirc we do it anyway just because there are subtle variants of e.g. sRGB that have slightly differently rounded constants so technically it's not lossless to replace that with the Enum version of it)

yeah, I've seen multiple different approximations to sRGB in terms of ICCv2 profiles

<@268284145820631040>

https://en.m.wikipedia.org/wiki/JPEG_XL

I uniformed the style of writing between English and Italian

There was an advice that was a list

Now you can make the racist you're Italian you aren't supposed to fix this article

Or actually fix the wrong declaration

Because every two language contains information copied by Jon Sneyers

please refrain from claiming what I have never said

Ok

So you won't do

what?

honestly speaking I had & have a hard time understanding what you really meant, both in the previous conversation and this time

(especially the "racist" bit)

I tried to give my best effort advice for contributing to Wikipedia for the first time, but that doesn't mean you have to agree to me all the time; you can always ignore my advice and maybe that's a way to go

but if you don't want to care about my advice, please do not ping me about that

Sorry

There are errors in my writing

Modular (lossless,near lossless/palette delta) based from FUIF – responsible, among others, for efficient lossless content encoding

It makes think im saying fuif is responsible and is a tool of the JXl

Think alone will get my edits removed

Because English can know I'm not English

Also few bits about Jon Sneyers

Without the context on GitHub isnt a problem but i repeat adaptive quantization weights like without explaining what fuc is that

Like if you go to the aac page is explained what is LFE

a reconstruction of frequencies to the 120hz and can be max 16 channels and the audio is stereo

The JPEG XL article Is orphan

It doesn't explain nothing about vardct

I did all this

The mpeg part looks like is wrote from a non native

The prepositions are strange

I tried to make less awful as possible

No Is originally wrote on English

I'm Italian but i wrote on English

I used sura and vani fonts

The question is i'm not English

Like this

Hope they don't revert

I finished editing jpeg xl at 15:06

The italian at 15:05

But don't Watch the time

Time is not important

It doesn't say rhe the quality

https://en.m.wikipedia.org/wiki/Special:MobileDiff/1107152458

Also this I did

I added details about YouTube

Only one source

Too few

This probably will be cancelled

epf requiring at most *three* previous and next rows makes my brain exploding

why? 😄

well it's easy to do in a naive way, but an optimized version would have to juggle lots of temporary buffers :S

don't I know that...

I think libjxl already does the same thing in stage_epf.cc?

yep, lots of magic to optimize that stuff

today in j40: Hayasaka helpfully reported that every image from JPEG transcoding will crash j40, and it all boils down to the fact that I didn't think u(32) was that frequently used 😉

to answer other question: july.jxl depends on patches which j40 doesn't support yet.

yes, unfortunately

I think every image produced by fjxl works at the moment