JPEG XL

this is the first lossless image I've stumbled upon which doesn't get compressed using lossy methods (probably well encoded to begin with)

lossy compression doesn't work well on hard lines and dots. It's a worst-case behavior for DCT.

ooh

AVIF made it 119KiB at q=0 and e=9 so yay?

is that lossy or lossless?

(is it the lowest quality setting or the highest? I don't know what "q" means here)

lowest setting; lossy

major artifacting

maybe it would be useful to have an extra option something like `patches identifying strength`, for lossy and lossless, because it can make encoding slower or doesn't always look good for progressive lossy

part of what makes the png compress well here is that it's using exactly 16 shades of gray, which means it fits 2 pixels per byte, which is quite effective. We can do something similar in jxl but it's a bit complicated and libjxl currently doesn't do that

Perhaps something for higher efforts down the road

I'm very interested in the conversion of mangas too ! I'll try on your image ! (when I'm back home)

I'm struggling to figure out how to set up a Hybrid Integer Config so I could, say, have 8bits of an ANS token and 6bits raw

for 14-bit uint32_t values

I figure I want `lsb_in_token` to be zero, but I also want `msb_in_token` to be 8

but that means I always want `n = 6`, so `((token - split) >> (config.msbInToken + config.lsbInToken))` must always equal 14

so what I'm gathering is that `config.lsbInToken` tells you how many bits in the token contribute to the lower portion

`config.msbInToken` tells you how many bits in the token contribute to the upper portion

and `config.splitExponent` tells you where to split the token into mantissa and exponent

is this correct?

No, not completely. Splitexponent k means that tokens 0 to 2^k -1 encode themselves as a symbol, without any raw bits. Starting with token 2^k, the token signals the exponent and possibly also some msb and lsb from the mantissa

So e.g. in the config 4-0-0 (splitexp-msb_in_token-lsb_in_token), you would have the following: Tokens 0..15 represent symbols 0..15 Token 16 means the symbol is 1xxxx where xxxx are 4 raw bits. Token 17 means the symbol is 1xxxxx (with 5 raw bits). Token 18 means the symbol is 1xxxxxx (6 raw bits). And so on.

Hybriduintconfig 3-2-1 would work something like this: Tokens 0..7 are symbols 0..7 Token 8 means 100x0 Token 9 means 100x1 Token 10 means 101x0 Token 11 means 101x1 Token 12 means 110x0 Token 15 means 111x1 Token 16 means 100xx0 Token 23 means 111xx1 Token 24 means 100xxx0 etc

(maybe I got the details wrong, didn't check spec or code, just going by memory)

slightly lossy, but visually almost the same, especially bitdepth 3 `--override_bitdepth 2` (bd2) `--override_bitdepth 3` (bd3)

https://www.reddit.com/r/jpegxl/comments/11p0edq/comment/jc3mdot/

I came up with another way to do bitpacking in jxl, not by using squeeze+palette but by using palette+MA tree

Could be easier to detect as a special case in the decoder and do without actually explicitly going through the transforms and MA tree stuff, just directly reading only one symbol per set of packed pixels, and expanding palette indices directly into n pixel values

what were the options used exactly ? I can't reproduce the result... with `-e 9 -d 0.0 -I 1 -E 3` I get 674257 bytes... worse than 589559 bytes for a simple `-e 9 -d 0.0`

Try with -g 3 too

`-e 9 -d 0.0 -I 1 -E 3 -g 3` -> 680280 bytes

From the sounds of it, different packing could automatically be applied depending on the bit depth if it's either manually set or low enough in the source

I couldn't stript the container though... even with `--container=0`

Time to go to bed ! I'll try again tomorrow !

Huh... I'm surprised the larger group actually made it worse

I used benchmark_xl for some bruteforcing for various options, it's like `--codec jxl:d0:E3:I1:9` + `--override_bitdepth 3`/`--override_bitdepth 2` (for second encoding)

WDYT, <@179701849576833024> ? So basically the scheme is like this: To pack n pixels with k possible colors each, make a palette of \sum_{i=0..n-1} k^(n-i) colors. The first pixel of a pack uses one of the first k^n indices, and completely determines the remaining pixels of the pack. The second pixel uses one of the next k^(n-1) indices, which also completely determines itself and the remaining pixels. The palette is just mapping index i to value i%k (so it should compress well even if it gets large), and the MA tree is just explicitly mapping how values for W fully determine the current pixel, except for the first column and the case where W is one of the last k indices (last pixel of a pack). Could be a largish tree but hopefully still compresses quite well since it's very structured — and maybe something clever can be done to make it shorter than the naive thing with one leaf per palette index.

I am not sure how good we are at encoding the tree

Otherwise this could make sense

Maybe using nk^n colors so every pixel of the pack 'knows' the full contents of the pack is easier. Then the tree can be just something like this: ``` if x > 0 if W > (n-1) k^n -1 - [actual tree for the entropy coded bitpacked pixels goes here, can look at bitpacks around it] - W + k^n /* zero entropy ctx */ - [subtree for first column] ```

Maybe with a - but yeah that could work out

well, what do you do if w > k?

ah no nvm that works out too

The first column is special because there you cannot use W. In all other cases, this scheme would work

Cycling through buckets of indices

yep

you don't even need k^n

for things like qr codes, where you have x \* x squares of constant color, you just need something like 2n

I wonder if we can do something like group4 (basically RLE of 0/1s but with the run lengths delta coded wrt runs in the above row)

also encoding the palette is easy, it's something like W in the tree + 0 / -k^n (k-1 1s followed by -k^n) repeated enough many times

if this is the case, in general how would one generate the right hybrid uint config?

what does "right" mean?

well the particular issue I have is I'm encoding LF coefficients and the particular LF quant values make them range between 0 and 2^14 - 1

since these are LF Quant values (after prediction) then there will be lots of entropy in the lower order bits

but much less entropy in the higher order bits

so what I'd like to do, ideally is have the token represent the higher order bits and the lower order bits, which are mostly random, be signalled raw

but I'm not sure which hybrid uint config accomplishes this the best way

eh, pretty much any

go with 400, it's kinda a safe bet

can also do 440 but that almost never helps with DC IME

wouldn't msb in token = lsb in token = 0 make any value greater than `1 << split` encoded almost raw

the way I choose these things usually: * last value is 0 unless you know all the values are even/odd or similar * pick the second value based on how many high bits you'd like to entropy code * pick the first value such that it's >= sum of the others, = by default and > if you have reason to think small values are particularly likely

Makes sense, thanks

is there any simple way to convert xyb jpegs encoded with jpegli to sRGB PNGs that ssimu2 understands?

Wonder if the benchmark would let you do that as input and output

if I'm comparing to a standard PNG that's RGB encoded though

``` convert input-xyb.jpg -depth 16 xyb.tiff tificc -w16 xyb.tiff srgb.tiff convert temp2.tiff -depth 16 input-sRGB.png ```

if you want a CLI option

if you want a GUI option, open it with chrome, right click the image and click "copy"

and then paste it in an image editor like GIMP and export

the sRGB PNG won't be tagged as sRGB but it will be sRGB

unfortunately libplacebo ignores the xyb-jpeg ICC

I just realized that "mux" is short for "multiplex"

<@238552565619359744> I have plans to compress about q50 in quality and in fact the only problem is what to do with it. For some reason I can't find any algorithms or neural networks that could smooth out the manga grid and make a color guardian out of it

<@794205442175402004> it is realistic to change several values of the CJXL code so that it stops creating a DCT grid at all?

it's not always easy, to smooth out these pattern as sometime they shouldn't be smoothed, like the sweat shirt of this invisible man : https://i0.wp.com/www.gohanblog.fr/www/wp-content/uploads/2019/04/My-hero-scan-1.png?ssl=1

and in this picture, the motion lines are also patterns by the way

in this image there is no grid at all that I am talking about

what ?

don't you see?

I see "grids" everywhere

the floor, the hairs, and the sweatshirt

e7 e5

Halftoning patterns are tricky for the DCT, it's basically a worst-case kind of image. Changing them into continuous-tone grayscale gradients would help a lot for compression, but of course then it becomes a different image.

nice transform ! how did you ?

indeed, mangas without the pattern... is it still manga 😄 ?

I would agree to just smooth them out if there are some parameters in the code that are responsible for the probability with which they should be used

even a bilateral filter choke on this kind of smmothing

If the halftoning is basically done because the actual image is grayscale but to get it printed, halftoning needed to be done, then you could argue that it's only a printing artifact, but then you should be encoding the grayscale originals, not scans of the halftoned prints.

for mangas, the half toning is not done to print from the greyscale image, but is made by the author for artistic purposes

But I would assume that the halftone patterns are part of the actual art and turning them into grayscale gradients is ruining things.

interestingly, WEBP just stops using the DCT at all, when compressing q 0

I think it discard too much HF coefficients, hence the result

And in that case, basically you just shouldn't be trying to smooth them out or using DCT. Lossless is the only good approach (possibly with some bit depth reduction since presumably the actual content is 1-bit, so maybe 2-4 bit encoding is good so you can keep some antialiasing, but no need to go 8-bit or higher)

Well that. this is exactly the goal I have.

I was looking for the exact word : screentones. Before the computers, you bought them in sheets and you cut them to put the pattern on your drawing

Well. no, this solution does not suit me

I don't know what the best way is to try to go back from halftoning to grayscale, but I would imagine there are tools for that. Something like blurring enough to kill the patterns and then sharpening again might work.

I don't think image codecs are the best tools for ~~ruining~~'enhancing' images

I have already done multi-day experiments in this area. and the results are just disgusting. this is only suitable if you plan to compress very much. I did it for AVIF qp 45-50

median filter, Gaussian smoothing, 5x5 squared average, and everything like that is not a solution, it ruined the contours

It does sound like trying to convert the Mona Lisa into a photograph, trying to find ways to hide the brush strokes that make it obvious that it's a painting

this is even assuming that the scans of the manga, or even its originals, are already recompressed images with not the clearest contours, which also, as a result of interpolation and image reduction, acquire this entire grid

yep, the filter wouldn't be trivial... couldn't the predictors of jpegXL do a better job here ?

(I don't understand exactly what MA trees should be able to do 😄 )

for good scans or digital manga I don't see the point of using lossy at all (source in lossless webp btw)

That's indeed what I do most of the time (and the reason why I'm such a fan of jpegXL :D)

I think the scan/translation people could be very very intersted in jxl

and for the kind of galleries they publish, downloading once a 300kb wasm shouldn't be an issue

and they wouldn't need thumbnail neither... 😄 a win-win-win situation

except that the decoding speed in lossless is quite slow, especially if using a wasm decoder

we can still that the situation improve 🙂 I was just think it could be a good way to increase the user base

slow neural can

(very very slow)

what is this code ?

upresnet10

works bad

well... the grey areas are now grey 😄

I'd post a close-up cropped image of the invisible girl but Clyde apparently thinks it's explicit

either way, you can see that Hagakure isn't actual gray

should it be ? the dot are too spaced

<:Thonk:805904896879493180> https://github.com/natethegreate/Screentone-Remover

The main thing I learned is that - no one on the Internet calls it either Manga grid or Manga dotted

well. its work very fast

neat ! yes screentones 🙂

how use jpeg xl 🙂

Okay I'll try in 1 thread

Work 👍

It appears that libavcodec can't handle RGB jpegs. If I wanted to add support to libavcodec for that, I'd want to be able to read up on where that's tagged in a JPEG file. ideas?

This is done using an Adobe marker: https://exiftool.org/TagNames/JPEG.html#Adobe

at least I think that's how it's done

the JPEG spec surprisingly doesn't say anything about how to interpret the components, they intended to put that in a later part of the spec

is there a way to get jpegli to output an RGB jpeg that doesn't have an XYB profile attached?

for test purposes

then JFIF came as an ad-hoc file format for JPEG to fill the gap, and it just specifies that 3 components are to be interpreted as YCbCr

then Adobe came and added their own marker to do RGB, CMYK, and YCCK

it's all pretty messy

one thing I never understood is why nobody just added a marker to do RGBA or YCbCrA in JPEG, it wouldn't be hard to do that and it would be pretty useful

looks like somehow the lavc decoder supports the adobe transform

but it's not working for pixel format id 0x22221100

it is? I don't see the 0xEE marker anywhere in the file

I believe `cjpeg_hdr` should come close to that

if I produce an rgb jpeg with `cjpeg -rgb`, I do see that marker. Maybe there are other ways to do it, I dunno...

I'm referring to `lenna-xyb.jpg` produced by jpegli

this image doesn't have 0xEE marker

it goes D8, E2, DB, C2 followed by various alternating C4/DAs

ah right, it uses the Exif file format, not the JFIF one

then I suppose this elegant thing is what is used to signal the info: https://github.com/libjxl/libjxl/blob/627bad401cc205243314abad7d651467042d08aa/lib/jxl/jpeg/jpeg_data.cc#L146

I don't think so either

basically if the component identifiers are 1,2,3 (as in, bytes with that value), then it's YCbCr

if they are 'R', 'G', 'B' (as in, bytes with those ascii values), then it's RGB

it looks like it's only subsampled in the B channel?

that's a little strange ngl

yes, a choice I think we should undo because it causes these jpegs to not be recompressible to jxl 😱

(link to relevant earlier discussion about this)

d4 for manga works very well, so well that I even decided to use d5

The quality is less than d4 transparent in normal viewing (pixel on pixel) - but must understand that this is an opinion based on images that have been smoothed and processed by the neural network.

Color quantization may be a better option than trying to smooth out the screentone of manga

E.g. using pngquant: ```bash pngquant -o $out -f --nofs $ncolors -- $in ``` with $ncolors in [4, 8,12,...] maybe add the `--posterize 4` for lower-precision pngs

Or using gmic with fixed palette: ```bash # ncolor == 4 gmic i $in "to_gray" i "(0,64,192,255)" "index[-2]" "[-1],0,1" "o" -.png \> $out # ncolor == 8 gmic i $in "to_gray" i "(0,32,64,96,128,192,224,255)" "index[-2]" "[-1],0,1" "o" -.png \> $out ```

And then encode resulting png with modular jxl

no... you missed everything talk, I have already found the best and fastest (of the existing) methods https://github.com/natethegreate/Screentone-Remover

I was using bilateral blur, like your example do, for some time. It's a good hack for images with destroyed low-res screentone, but not so for good-quality manga scans

it suits me.

Could you post a few examples, if it's reasonable? Being able to use this in manga-like settings would definitely help with adoption. (<@736666062879195236>)

updated stats on my manga (lossless jxl) 38847 jxl files Filesize: 20 GB Original filesize: 31.4 GB Total compression ratio: 157.03% Per chapter Mean: 167.82%, Median: 151.05%, Min: 109.44%, Max: 1775.88%, 10th %ile: 121.23%, 90th %ile: 232.41%, sd: 68.75% Per page Mean: 200.36%, Median: 151.53%, Min: 69.3%, Max: 57858.86%, 10th %ile: 119.84%, 90th %ile: 227.94%, sd: 797.98%

378K image.png 356K image.cwebp_z9.webp 299K image.cjxl_lI1E3e9.jxl 194K image.pngq_16.png 145K image.pngq_16.cjxl_lI1E3e9.jxl 127K image.cjxl_d4.jxl Previews: original, quantized, cjxl_d4

Where pngq_16 in filename -- `pngquant -o $out -f --nofs 16 -- $in`

i tried both -I 1 and -I 100 and they are both different from your 299K <:thenk:349311010584395788>

`cjxl image.png --num_threads=0 -j 0 -m 1 -e 9 -I 1 -E 3 -d 0 out.jxl` on latest main (1af035f) 🤷‍♂️

the -I1 turns out to be 299K (counting). -I100 is 273K

Thanks. So, the last one is the one using bilateral blur? (<@736666062879195236>)

Nope, just `cjxl -d 4`

jxl dct is doing surprisingly well for this kind of image. Of course it still has a lot of wavy low-freq ringing artifacts and blurring.

I think if there was a way to "trade" LF blurring artifacts with higher-frequency noise/grain, it could improve the appearance and the visual fidelity of lossy JXL

Since large low-freq wavy artifacts and loss of large details is worse than grainy noise that is easier for the brain to filter out and see through

currently libjxl is awfully blurry, and I feel like it would be possible to make the DCT coefficients more compressible with noise rather than blurring/zeroing

When I say "noise," think easily-compressible pseudorandomness

I think x264 probably does something like that.

It has very good psy tuning that's very good at "preserving" noise and texture and fine detail

By the way, I hope you will enjoy this comparison. avifenc aom default settings vs libjxl d=2

JXL is smaller and very slightly more detailed.

Would anyone like to see a .png that's larger when .jxl lossless? Or is that a well known thing already?

The original png is 1.3 mb and -d 0 -e 9 .jxl is 1.4 mb

[Edit](https://discord.com/channels/794206087879852103/794206170445119489/1085532183432790118): Would anyone like to see a .png that's larger when .jxl lossless? Or is that a well known non-curiosity already?

I'd imagine it might be because of the bit packing we've discussed before

in my past old experience, pngquant is able to generate files that are hard for other tools to crush further...

It's always nice to have examples where png is beating libjxl, so we can improve libjxl. Don't forget that even e10 is far from exhaustive, there is still plenty of room for encoder improvements, enough to keep 100 PhD students busy for at least 10 years.

I just hope that the interest and passion in improving image compression and lossy coding techniques stays aflame long enough to try implementing some really unique techniques to increase coding efficiency.

Like borrowing ideas from pngquant, djvu, and maybe other new and creative noise-shaping techniques to help preserve detail and fidelity in ways that have the greatest impact.

Maybe even some foreground/background recognition and separation, spending more bits on areas of the image that the eye is most likely to focus on

the palette selection (the static internal palette that includes delta coding) in jpeg xl should be pretty good for palette encoding photographs (if that is an interest)

I'd be interested about the process that was used to generate that PNG rather than the fact that it exists

Google already made a program to arrange JXL's progressive blocks in order of what draws attention first, I'd imagine it could be adapted especially since mixing modular and VarDCT blocks is already an idea

[uploading from discord because my matrix client doesn't let me upload pictures for some reason]

Almost all of the difference is very close to 0, so I thought you'd be able to compress is very well. LZMA compresses them with a 2.55 ratio.

I converted an image to OKLab colour space, did DCT+Quantisation on it, converted back to RGB, and subtracted the result from the original image, and made the difference into a png But you'd get a very similar image if you subtract a .jxl image from an original .png

Try e8 d1

Here's the best I could get by lowering the bit depth, hard to tell if it kept all the colors properly or not though -d 0 -g 3 -I 100 -E 3 -e 9 --override_bitdepth=6

B-2x-subsampling gives about 1 % compression density improvement -- it is ok to undo

wow, you are exploring cool things

0.02 db better PSNR https://github.com/libjxl/libjxl/pull/2298 😄

Perhaps most of it can be recovered by quantizing high freq B more aggressively, and possibly by cheating the DC for B to be more predictable? (either w.r.t. jpeg's very basic predictor, so it helps in jpeg syntax, or w.r.t. a more useful predictor like ClampedGradient, with gains only when recompressing as jxl)

that's where we started

compression within jxl is of course something we didn't optimize much for -- just the jpeg1 compression

In general I think it would be cool to do DC in jpegli with a higher precision than usual, but requantizing the coefficients w.r.t. a modular predictor (keeping only residuals near zero intact, and e.g. keeping only 5 msb of the residual intact).

I don't understand

That way you can get great slow gradients, while also getting magically great jxl recompression

human vision is super adaptive for Y but not very adaptive for X

so decoding could rework the Y to be off in low frequency as long as it is not surprisingly discontinuous

then again low frequency is not a lot of info

decoding could rework the dc values, too -- within their quantization buckets

Eugene had something like that in brunsli at a stage but it is probably not currently in

Say you use quant factor 1 for DC, so you have 12-bit precision for the DC. That's quite costly if you just keep it like that, both in jpeg and in jxl. But then you could make it near-lossless by computing the residual w.r.t. a predictor (e.g. Gradient) and adjusting the values so the residuals in [-3,3] are preserved but residuals with higher amplitude get requantized. In JPEG itself, that doesn't buy you anything (since it doesn't have any predictor besides Left, which is not good enough for this kind of thing), but when recompressing in JXL, you can use the predictor and get histograms with lots of holes in them, so effectively it becomes much cheaper to encode the values...

predictor is always backward looking -- you need ideally here other approaches that use larger support

both forward and backward, like Eugene did for brunsli

Just backward looking already works quite well, at least for 1:1 images. I suspect for 1:8 images it also works.

how does alias mapping work with regard to JXL ANS on the encode side?

and the general writing of symbols? I figure the setup code is just the same thing, but I'm wondering how you actually go about writing the symbols and dealing with the alias mapping of them

Annex O says `k is chosen so AliasMapping(D, k) = (symbol, state Umod D[symbol])` but doesn't provide any ideas on how to invert AliasMapping

I must confess I still don't quite fully understand alias mapping. <@179701849576833024> perhaps it would be useful to document it somewhere, because it's a rather funky thing and there isn't really any clear description of it (in particular of the encoder side of it, but even the decode side in the spec is just some rather obscure code without much hints at why things are done the way they are)

We need more informal descriptions with some design rationale and examples. At some point I still want to co-write a book on jxl with all of that, before we all forget why we did things. Just hard to find time for such a thing...

Ehhh It is a bit tricky

I'd like to learn how to do it without just taking code from libjxl

AliasMapping is a function that takes two parameters, D and k. D is a dictionary where keys are the symbols (e.g., items, events, or categories) and values are their corresponding probabilities. k is an integer that is chosen so that the function returns a pair (symbol, state), where the state is calculated as U % D[symbol]. Here's a step-by-step explanation of this function: First, we find the total probability mass M by summing all the probabilities in D. Next, we normalize the probabilities by multiplying each probability by k and dividing it by M. This normalization step is important because it ensures that the sum of the probabilities is equal to k. We store the normalized probabilities in a new dictionary called nD. Now, we need to find the pair (symbol, state) such that AliasMapping(D, k) = (symbol, state U % D[symbol]). To do this, we iterate over the normalized probabilities dictionary nD and check if U % nD[symbol] is less than or equal to the original probability D[symbol]. If it is, we return (symbol, state), where the state is U % D[symbol]. This function is designed to find the appropriate k value, which ensures that the sampling can be done efficiently. In the context of the alias method, this function would be used during the setup phase to preprocess the probabilities and create the alias mapping. ```python def AliasMapping(D, k): M = sum(D.values()) nD = {key: (value * k) / M for key, value in D.items()} U = random.uniform(0, k) for symbol, prob in nD.items(): if U % prob <= D[symbol]: state = U % prob return symbol, state return None ```

If you are looking to invert the AliasMapping function as described in Annex O, then the goal is to find k such that AliasMapping(D, k) = (symbol, state Umod D[symbol]). To achieve this, you would need to modify the AliasMapping function as follows: ```python def AliasMapping(D, k): M = sum(D.values()) nD = {key: (value * k) / M for key, value in D.items()} U = random.uniform(0, k) for symbol, prob in nD.items(): if U % prob <= D[symbol]: state = U % D[symbol] return symbol, state return None ``` To invert this function, you would need to find a way to calculate k and U given a (symbol, state) pair. Since U is generated from a uniform distribution, it would be challenging to determine the exact value of U from the output. Inverting the function might not be feasible or practical due to the nature of random sampling.

why is there a random U here? alias mapping as defined in the JXL decoder is deterministic, entirely from the frequencies

Where did you get this from?

question: is aliasmapping aliastable in libjxl ? https://github.com/libjxl/libjxl/search?q=alias+mapping

I don't know. I know it from section C.2.6 in the spec

the specification is to broken. I saw this when i wanted develop a port from scratch. I watched then your jxlatte code to understand the source code. xD it is a better documentation. 🙂 The random.uniform(0, k) part was a misunderstanding on my part, and it should not be included in the context of the JPEG XL decoder.

is your aliasmapping in jxlatte not true too? https://github.com/thebombzen/jxlatte/blob/main/java/com/thebombzen/jxlatte/entropy/ANSSymbolDistribution.java#L148

it's based on the spec

in the past it was so that the webm team put the vp8 source code written in c into a document and the source code was then the specification 😄 https://datatracker.ietf.org/doc/rfc6386/ maybe is this solution for jxl a better way to make specification readable

what

no

another question I'm wondering is how do you write the hybrid integer residues in all of this?

if it was *just* an ANS stream then I could see how you just write the tokens in reverse order and then write the 4-byte state at the end

but now you have the hybrid integers interleaved

how do you make that work?

The full stream is basically a mix of u(16) for ANS state updates and lots of small u(n) for raw bits

That part is easy (ish), you just need to go through symbols in reverse, figure out where state flushes happen, and then go through symbols forwards and insert the bits between state updates

unfortunately banding often happens very slowly -- think 10 8x8 blocks having the same value, then switching to the next value -- local filtering is not going to be effective, you need to analyze it more globally

Slowness of gradients is not an issue in what I am proposing, on slow gradients the residuals will have low amplitude (if they're really slow, only -1/0/+1), so you get full 12-bit precision.

ugh, this is actually a huge pain

it's so memory greedy

you can do some creative memory reusing

I meant more like, I need yet another buffer to hold the state flushes

well, maybe

a suffix of N encoded symbols can only use I believe (12 bits + raw bits) * number of symbols

presumably the struct you use to hold the symbols is bigger than that

😛

I wonder if I could do it in the same for loop

like, every time I hit a state flush, I write the hybrid integer residues first

and then flush the state

<@226977230121598977>, possibly time to check out your images again after https://github.com/libjxl/libjxl/pull/2298

👀

would the state flushes on decode happen in same places as they would on encode? or in reverse order?

The encoder should write the bitstream from end to start, just like it encodes the symbols from last to first. And then the decoder can read bitstream start to end and get symbols from first to last.

I meant with regard to the hybrid uints. for example the decoder flushes twice at the beginning and the encoder flushes twice at the end

but does the third to last flush on encode correspond to the third flush on decode?

ie on the same token?

ah, I figured it out

you have to write the symbols in the opposite order, but then you have to reverse all the state flushes

so those are in forwards order

no. the new latest build looks just as disgusting on the newly images. much worse than the old version. But the very first 4 test images look good

Can you run tests with this image? it really work on any old JPEG XL version, even by 0.6.0, on any quality q90 q80 q70 q60 q50 - it looks as it should. but on the last build it starts to break even starting with the quality of q95

I'm trying to figure out how to cluster all 7425 or however many HF coefficient clusters there are

is there a simple way to do that?

define simple

"sane default"

like how 4-0-0 and 4-4-0 are "sane default" options for hybrid uint configs

I mean, if you just want some clustering that works, map all #nonzeros to 0-1-2, and all coefficient contexts to 3-4-5

for my initial implementation I want to pick something that usually will work well for photographic images

oh, does that work well?

it works OK

0-1-2 being according to channel

YXB order?

does it matter? 😉

I suppose not

cause I can cluster them however I want

if the clusters are reordered it doesn't change anything

yup

if you want something fancier, you can do kmeans++ with "how much does it cost more to merge these two clusters" as a distance metric (that's what libjxl does)

in the future I'd like to improve the clustering so I can have better ratios with minimal extra computation overhead, but for now I want something that Just Works OK™️ to get this library to produce compliant codestreams

so far it produces complaint LF Groups but libjxl won't decode them even with --decode_partial_files

which is somewhat annoying

I'd like to make sure the LF Coefficients are working correctly and so if the HF Pass and HF Coefficient metadata is missing, ideally then libjxl will still produce the LF downsampled version

but libjxl rejects this file as not-partial

it just goes "there is no preview available yet"

that's slightly odd

maybe you also need AC global

I actually have AC Global, but its' one bit

even weirder: djxl --allow_partial_files fails

but libjxl actually says ok

ugh why

but libjxl also reports all black, idk if that's because I'm writing garbo or if it's because it won't fill teh buffer

fwiw, getting an all-0-ac is not *too* hard

so just for testing purposes I could write an all-0 AC?

not a bad idea

I just need to write non_zeroes = 0 for every varblock and I'm basically done

yep

that's how I went for fmjxl

well, looks like this wasn't supposed to happen

but it's compliant!

probably an issue with quant

probably

well, at least an issue with DC 😛

actually, probably not quantization but prediction, if I had to guess

supposed to be locked to gradiant predictor

so what really matters is the upper left value

for quant

well that certainly looks a lot better than a random white square

original

still a little bit confused about how much I should quant B by, but hey it's working

~~just use the default tables~~

Progress in jxl-oxide: binaries are being built at GitHub, so you can try jxl-oxide decoder using those <https://github.com/tirr-c/jxl-oxide/actions/workflows/build.yml>

it should be able to decode and render "simple" images (it's slow though)

progress!

original:

clearly I'm doing something wrong with quantizing but I can't quite figure out what

(decoded with libjxl for discord)

You progress quickly!

https://github.com/cssobral2013/Argentum-Sans

probably makes sense to debug LF coefficients before HF coefficients

I'm doing that, but it's a little confusing as I'm internally representing my values as int16

ohhh

yeah that's rough

according to the default quant tables, B is divided by 256 and Y by 512

but if I quantize B by half as much as Y, I get way too much B

this is assuming B is actually B-Y, because Y is added later using CFL.

wdym way too much B?

look at the color of the shirt

it's supposed to be purplish blue but it's yellowish

ah yeah that could be a problem indeed

weirdly enough, the hair and face are the right color

but maybe that's cause B samples are close to zero there

it's possible that I have the wrong sign for B

very possible

also possible that you sent the wrong CfL values

I sent the default ones

which iirc just adds Y to B on decode

mhhh yeah that should be right

and how do you encode? quantize+dequantize Y, subtract that from B, quantize residual?

no, I subtract B from Y when I do the XYB transform

er, I subtract Y from B

that's not *as* accurate, but close enough 🙂

I guess you just have the b quant factor wrong somehow

that's what I thought, but tweaking it didn't fix it

I'm considering writing a 0 value for CFL at this point so I can test other parts of the process

alright, disabling CFL didn't fix the issue

it's exactly the same problem as before

I wonder if my XYB transform is not going well

indeed, I tried it using floats

my integer approximation was messing up somehow

<#806898911091753051>

and we've got a working image!

quality needs improvement, and it's decoded with libjxl

but it looks like the original

what was the issue with the B channel?

is it just 8x8s?

a typo of `g * 0.551` instead of `b * 0.551` 😅

Ah that would do it 😛

so far hydrium doesn't beat libjxl at anything atm because highway

but it works!

second working jpeg xl encoder ever

I suppose it *does* beat libjxl at binary size and memory usage

libhydrium is 101k, which is smaller than lodepng

and that's before I optimized anything

second encoder if not counting the official ones <:FeelsReadingMan:808827102278451241> there is also <https://github.com/libjxl/libjxl-tiny> also with less memory consumption and binary size than libjxl **cjxl.exe -d 1 -e 4 --num_threads 0** `Cpu 44 mb/s (0.202 sec), real 44 mb/s (0.203 sec) = 99%. ram 165724 KB, vmem 229988 KB` **cjxl_tiny -d 1** `Cpu 210 mb/s (0.171 sec), real 210 mb/s (0.171 sec) = 100%. ram 77624 KB, vmem 75280 KB`

you mean fmjxl and fjxl? 😛

I mean among supporting all basic features in some future, but simplified in some way <:YEP:808828808127971399> though, fmjxl + fjxl together is also lossy (with animation) and lossless 🤔

actually fjxl also does animation now (although the main interface doesn't)

an exe please

https://github.com/thebombzen/hydrium

no avx2

77M?

libhydrium uses <2 MB ram

it's not optimized yet ofc

I'm not planning on using intrinsic extensions or multithreading: the goal is for it to be portable easily to small systems like digital cameras

yeah, but still less than libjxl

yea, but 77 MB is still a lot of memory

libhydrium has a *very* low memory footprint by encoding one Frame at a time as a 256x256 tile

so it only needs to buffer that, and nothing else

naturally, this sacrifices ratio

but coding efficiency is not the primary concern

probably because it hasn't been the main goal yet

yea. I could improve the efficiency a lot if I buffered one LF Group at a time rather than one Group

but I don't want to sacrifice fidelity, yet

hydrium `Cpu 1034 kb/s (5.514 sec), real 1028 kb/s (5.548 sec) = 99%. ram 32828 KB, vmem 35096 KB` also jxl is broken?

most of that RAM is consumed by lodepng

ppm is not supported yet?

not atm

the library just takes a buffer

the frontend takes png

mighta fixed a bug, try recompiling

as this one builds fine

I could possibly quant the HF coeffs more, tbh

for photographic images they work fine

It's from this build

interesting, wonder if something happens on windows

interesting, something weird happens on windows that isn't happening on linux

<:Thonk:805904896879493180>

oh, that's what it is

on windows when I write `0xFF 0x0A` it replaces each instance of `0x0A` with a `0x0D 0x0A`

it's inserting a carriage return

I have an `fopen("w")` not `"wb"` cause I forget that they're actually different on windows

btw fjxl has a small pam-input.h for pam/ppm support <https://github.com/libjxl/libjxl/tree/main/experimental/fast_lossless>

yea, though fjxl is a different type of tool

try this

yeah, it works, but weirdly slow decoding compared to regular libjxl

hydrium jxl djxl: `1534 x 2048, 1.90 MP/s [1.90, 1.90]` tiny jxl djxl: `1534 x 2048, 114.13 MP/s [114.13, 114.13]`

and it seems like the colors are a slightly different `-d 0.01` for jibjxl(-tiny) because I thought size might affect decoding speed

I think the colors being slightly different is because of my sRGB to Linear approximation

that's probably due to how it tiles, there's a lot of ANS overhead

if I enabled gaborish then I might be able to get away with more quant

oh so hydrium encodes tiles into separate frames

maybe frame composition is slow then

I wouldn't be surprised if frame composition is not exactly optimized for this

gaborish crosses group boundaries but not frame boundaries, so you might get some seams if you do gaborish while encoding one frame per group

same with epf

Maybe we could let libjxl decode files where the `jxlp` boxes are out of order, with a warning or something, or only if a certain option is enabled (it does mean it needs to buffer all of the bitstream until it finds the first `jxlp` box). It's technically not conforming according to 18181-2 to do that, but then again, we do have an index counter field in `jxlp` so we may as well use it. Then you can write all the data sections in a single frame, with the TOC at the end. It would be easy to make a tool to put the `jxlp` boxes in the right order.

13MB

ah, that's right. I'm still trying to figure out how to avoid seams on varblock boundaries without setting HFMul to be too high though

ah you're encoding one frame per group? yeah djxl won't like that

as in, I am 99% sure the current code will just pay O(wh) in memory copies for each group

probably not too hard to fix though

~~but for sure I will not do it~~

Could you compress this photo with latest hydrium

Send me latest hybrid I'll tell you how it should perform

you *can* compile it yourself, you know

Try

it's als still very WIP

Also try with this photo

Difficult one

Send jxl and I will review

Fab, sus

in theory you should do

cjxl C:\Users\Use\Pictures\vu\vu.jpeg -e 8 -q 52.2 --photon_noise_iso=21 --lossless_jpeg=0 C:\Users\Use\Pictures\vu\vu.jxl

but with better quality than original libjxl

are you able to achieve that?

<@853026420792360980>

i know is a png

jon will be angry about this

he hates jpeg

especially re encoding of them

Another photo you can test

Xiaomi android 13 denoising

Ok I'll make a review of the current encoder

It don't decode with xnview

More than one minute already passsed

1365

Done

you need to build it again

previous version had a bug

A zoom

Great job/

I'm curious this hydrium vs libjxl

it looks like higher HF Multipliers are needed where there's smooth gradients

since those are more noticeable

I'm currently operating on a constant hfmultof 8

or rather, when I have a smooth gradient, the varblock boundaries are more noticeable

<@794205442175402004> idea w/r/t jpegli subsampling B channel: why not create a new XYB icc profile, whose matrix is the standard Opsin matrix times the YCbCr inverse matrix

New difficult image

so the opsin inverse matrix is the YCbCr forward matrix, times the standard opsin inverse matrix

then you tag the image as YCbCr

Very difficult

perhaps the other way around

but either way you conjugate the encode-decode process with the YCbCr conversion matrix

that way, decoders will decode the JPEG, then apply YCbCr -> RGB, then apply the ICC Profile

nothing changes on decode except decoders apply inverse YCbCr, which is then inverted by the ICC Profile application

so it still decodes to what you want

the primary purpose of doing this would be that you can mark the image as YCbCr instead of RGB, which allows you to subsample the third channel, and have it be JPEG-Recompressable using cjxl

you'd just fake the YCbCr as RGB with the ICC profile, essentially

Because the point is to quantize the XYB components differently. Doing YCbCr on XYB will give something weird where luma has been mixed with chroma again

Well on encode youd still just encode XYB

but the ICC profile youd attach would have YCbCr matrix multiplied on the right of the opsin inverse matrix

Ah, I see. That could work, yes.

Not sure if existing decoders will work with 'YCbCr' where only Cr is subsampled, not Cb. I suspect they won't expect that...

Jxl can represent that though.

If they can handle RGB with only B subsampled then probably they can handle only Cr subsampled

atm avcodec cant handle jpegli files but ive got a patch to fix that

and now take this file and place it in the Releases On github tab

https://github.com/tirr-c/jxl-oxide <:Thonk:805904896879493180> <:Thonk:805904896879493180> <:Thonk:805904896879493180> <:Thonk:805904896879493180> <:Thonk:805904896879493180> <:Thonk:805904896879493180>