JPEG XL

I hope we can get the Working Draft of 18181-1-Ed.2 out as a result of it

So we finally have a decent publicly available spec

I will also be arguing in favor of hosting the draft on a public git repo (github or gitlab), so we can allow anyone to report spec bugs and even propose fixes or editorial improvements there

We are working in TeX+git now, thanks to <@179701849576833024>'s hard work

oh, so it’s confirmed?

What's *not* confirmed is what it is ISO will want from us

But writing that conversion is likely by far less work, and more fun and more useful, than working in word

ah, so even assuming that they still want a word doc, we still prefer converting one way and then back?

I certainly do

So do I

We will try to get them to accept an XML version instead, which is what they need anyway (they just happen to have software to convert Word to XML)

In the end, the only difference between the draft and the thing ISO publishes will be the boilerplate stuff

And it doesn't matter much in practice how long ISO will take to publish the 2nd edition

(everyone will use the draft anyway)

Especially as no one can see the ISO publication, due to the paywall...

Update lossy modular result, nonphoto_separation branch. > denoise-png 414,581 => jxl 1,750,254 > denoise-png 962,047 => jxl 2,119,818 > denoise-png 4,050,574 => jxl 3,756,559 > cjxl -m -Q 90 -e 8 --num_threads=12

Does this mean denoised png to jxl, or denoised png compared to jxl

denoised png compress to(=>) jxl

🤔

Seems strange that the jxl is larger than the png

Update mozjpeg and webp-lossy result, look like only avif and jxl --separate(have some issue) can correct process those image. (denoised png compress to(=>) <lossy-format>) > denoise-png 414,581 => jpg 6,269,979 > denoise-png 962,047 => jpg 6,749,052 > denoise-png 4,050,574 => jpg 7,381,455 > mozjpeg-cjpeg -optimize -progressive -quality 90 -sample 1x1 > denoise-png 414,581 => webp-lossy 4,296,090 > denoise-png 962,047 => webp-lossy 4,533,530 > denoise-png 4,050,574 => webp-lossy 5,006,958 > cwebp -mt -m 6 -q 90 -sharp_yuv -pre 4 -af

What sources are you using?

manga,comic content(black and white or grayscale). > https://discord.com/channels/794206087879852103/794206170445119489/895950366837981234 > https://discord.com/channels/794206087879852103/794206087879852106/889546375208005653

Could you provide the source image?

I find it very strange that none of them would beat png

Especially lossy webp <:Thonk:805904896879493180>

> https://discord.com/channels/794206087879852103/794206087879852106/885516651657822219 // and new test page.

nonphoto_separation branch cjxl-windows-AVX2-mingw64

this requires libgcc

or try with this

https://artifacts.lucaversari.it/libjxl/libjxl/2021-10-10T22%3A46%3A20Z_8e0e89a1072731c6b3dea4d11dd9bf58f20912fa/

input

for %i in (C:\Users\Utente\Documents\88we8\*.jpg) do cjxloctober9 -j -s 9 -d 1 %i %i.jxl for %i in (C:\Users\Utente\Documents\322\*.jpg) do cjxloctober9 -j -d 0.538 --faster_decoding=6 -I 0.768 -s 8 --use_new_heuristics %i %i.jxl

the second will be far better for high bitrate re encoding

no it output 6,5 mb

Try Just to increase distance try 2.81

I'll try to report some bench

Look like my build don't have libgcc static link... I don't want increase distance to 2.81, that distance is too risk for keep quality.

for %i in (C:\Users\Utente\Documents\test\*.png) do cjxloctober9 -s 7 --epf=3 -q 28.99 -I 0.283 --use_new_heuristics --faster_decoding=5 %i %i.jxl

or just use lossless

to me it looks like 45.6 jpeg

it looks like bad the image

how it looks in avif with more effort?

total bytes 1,21 MB (1.275.581 byte)

Update avif result for this image. > test02-denoise-pin-s9 > https://discord.com/channels/794206087879852103/794206170445119489/897813687962845204 > avif-q7-s4 962,047 => 328,772 > > avifenc --min 0 --max 63 --minalpha 0 --maxalpha 0 -d 10 -s 4 -j 12 -a end-usage=q -a cq-level=7 > -a color:enable-dnl-denoising=0 -a color:denoise-noise-level=5 -a color:enable-chroma-deltaq=1 > -a color:sharpness=3 -a color:qm-min=0 -a color:enable-qm=1

really quality 7 avif?

what are the command

ah cq level 7

can you send the avif file?

avif

lee

for %i in (C:\Users\Utente\Documents\test2\*.png) do cjxloctober9 -s 7 --epf=3 -q 21.59 -I 0.283 --use_new_heuristics --faster_decoding=6 --dots=0 --patches=0 %i %i.jxl

if you s0mething like this

you can't recover detail

jxl isn't meant to recover detail

only here i find jxl disturbing

the rest they are on par

that's the current file i have

it's all disabled and speed 7 so i'm breaking the rules

and also faster decoding 6

maybe if i remove i will try

`-q 21.59` I only use d 0.5 ~ 1.0 and d 1.45 ~ 2.5.

My 4 GB RAM PC can't execute this command

Does it's better with photon noise Just for curiosity

Without it at same quality is 5 mb

How the separate jxl weight

jxl weight? you mean file size?🤔

Yes

How is the weight of the jxl separate fole

> https://discord.com/channels/794206087879852103/794206170445119489/896840028024631346

Lossless is smaller than vardct.... 🤔

May be these images dont like dct at all

Heif is also big with that 4bit grayscale manga

dct is designed for continuous-tone images

not for bi-level or halftone images

in fact such halftone patterns are kind of a worst-case scenario for dct

I hope in the future we can make an encoder that detects cases like that, and switches automatically to a different approach

libjxl is best lossy photo encoder for now, 🙂 a little curious, libjxl have plan improve graphics quality and feature in this year? (quality: contrast sharp edges or line ringing, ​red color gradient tiny artifacts) (feature: no-dct lossy mode for graphics, like av1 automatically local palette feature)

This year, I dunno, but it is something I want to work on, just need to get green light from cloudinary to start working on it on company time. I'm convinced the bitstream can do a lot better than what current cjxl produces, but it's a little research project to actually find out how to do better and in particular how to effectively mix dct and non-dct automatically

I understand, thank you very much, 🙂 I believe libjxl will be a best still image encoder.

are there any stats of how much libjxl has improved since its introduction

What do you call 'introduction'?

some could say it's not "introduced" yet

When we compared FDIS cjxl (Oct 2020) to DIS cjxl (Jan 2020), it had improved quite nicely - of course that also involved bitstream changes

For lossless, not much has changed since then (there is still room for encoder improvements there, it just hasn't been a big priority). For lossy, I think there have been quite some further encoder improvements in the past year, maybe overall 7-8% better now than half a year ago?

though s 4 new heuristics changed from 0.3.7 to 0.6.0

it hasn't got no changes in many time it output same file for me in most builds

now it got the third change (maybe) i did not test it other than s 7 and no animation

avif got some changes on 29 september than libaom 3.1.3 i think

i see some improvements at d 6 s 6 now with current test

though quality goes worse on other lower distances

very much macroblocking

and also s 6 hasn't patches so for animations is useless

Maybe someone want to help reviewing PR for darktable: https://github.com/darktable-org/darktable/pull/10044

Commented a bit there

<@768090355546587137> or <@604964375924834314> maybe you want to take a look at the code of that darktable plugin to check if it is using the libjxl api correctly?

If you have high quality JPEGs (say, quality 99) as sources, is it fair to compare lossy compression between JXL and WebP?

Not really

You might want to do some downsampling to get rid of the JPEG weirdnesses

for %i in (C:\Users\Utente\Documents\w832\*.jpg) do cjxloctober9 -j --faster_decoding=1 --dots=0 -d 1.623 -s 7 %i %i.jxl

does well

though i will wait for better encoders

jxl is weak in some things dev care

bug free

animation sizes

album arts

<:thinkraging:427900399027093506>

though i'm thinking of an use where 30 kb images are important

and is there

it was something related to games

is a type of image where 24 mpx of fake resolution is important

and matters more than getting pixels working

i think i care about new heuristics when i can get a photo smaller like from 69 kb to 59000

i think -d 4.364 -s 8 --gaborish=0 should be the minimum to use for a photo shoot with a phone

if you're aiming with space saving in mind

phone camera usually are not good

i have samsung gn1 from xiaomi

bad

even motion cam 5.0.4 at iso 600 1/5 aperture unless i can do iso 600 isn't gonna save the photos

you have photon camera from github that can do multi hdr but the image are noisy overrall and the processing lacks even if there is good noise reduction

freedcam can shoot full resolution in jpg but it hasn't hdr

THIS IS NOT ABOUT CODEC

or monad you can try this

for %i in (C:\Users\Utente\Documents\322*.jpg) do cjxloctober9 -j -d 0.538 --faster_decoding=6 -I 0.768 -s 8 --use_new_heuristics %i %i.jxl the second will be far better for high bitrate re encoding https://artifacts.lucaversari.it/libjxl/libjxl/2021-10-10T22%3A46%3A20Z_8e0e89a1072731c6b3dea4d11dd9bf58f20912fa/

but it will be far worse quality in printing

i recommend lossless jpg transcode

i think youtube thumbnails you can start to re encode at s 7 d 1 if you have the cpu

problem no application recognize images as i am so i need to put them in folders and they are 695 pngs only in one folder

wb

i'll express my opinion

this is good enough quality for me

https://jon.lucaversari.it/comparison3/after_adjusted2/index.jxl_d2.html

though i like the lines better here

https://jon.lucaversari.it/comparison3/after_adjusted3/index.jxl_d3.html

best quality photographic like microsoft photos seems this

https://jon.lucaversari.it/comparison3/after_adjusted2/index.jxl_d1.html

though the lines aren't sharp

i think they are all 3 good

this bad

https://jon.lucaversari.it/comparison3/after_adjusted2/index.jxl_d1.html

though at d2 it looks better

this good

https://jon.lucaversari.it/comparison3/after_adjusted3/index.jxl_d2.html

looks like a new heuristics

https://jon.lucaversari.it/comparison3/after_adjusted3/index.jxl_d1.html

horrible

just the smearing of cottage

interesting this at d4 https://jon.lucaversari.it/comparison3/after_adjusted3/index.jxl_d4.html

https://jon.lucaversari.it/comparison2/before/wollerau.png.jxl_d2.5.png

i like this image

i like also this

https://jon.lucaversari.it/comparison2/before/index.jxl_d2.html

only that part of that distance, other distance not

though d4 is decent

honestly At kAcQuant=0.84 with d 1.369 -s 6 --faster_decoding=4 could be good

if someone can compile it with sse4 like scope i can look

in general it seems more realistic in the flowers

try with -q 83.174 --epf=1 --gaborish=0 -s 7 --use_new_heuristics --faster_decoding=1

and see which look better

no unfair

in this way i think the second gonna win

after adjusted 4 is horrible

is looks like denoised and micro granularing in the pink flowerr

https://jon.lucaversari.it/comparison3/after_adjusted2/red-flowers.png.jxl_d1.png

this look like stretched

ok

need to see original

this is afteradjusted3

this is where afteradjusted2 appears sharper to me

https://jon.lucaversari.it/comparison3/after_adjusted2/index.jxl_d2.html

i would use it at -q 70.579 -s 2 --faster_decoding=1 --photon_noise=ISO360 --epf=0

not sure if i can use photon noise at s 2 wasn't only for SPEED 8

93rd JPEG meeting has started, fun times

"fun"

Tomorrow we'll discuss in depth if we can do the spec drafting in TeX on public git, but so far it looks like it's still on the table

Anything interesting come out of the JPEG meeting <:Thonk:805904896879493180>

Final plenary is on Friday

So nothing I can share already I think

But we had good discussions today

Ok, keep being awesome 😎

3 more days to go

this is submitted now

anyone have some JPEG XL animations I can use for testing?

trying to cjxl this one fails: `https://upload.wikimedia.org/wikipedia/commons/1/14/Animated_PNG_example_bouncing_beach_ball.png`

https://github.com/libjxl/conformance/tree/master/testcases/animation_icos4d

any particular reason for this tho?

``` $ cjxl -d 0 Animated_PNG_example_bouncing_beach_ball.png Animated_PNG_example_bouncing_beach_ball.jxl JPEG XL encoder v0.7.0 116326a [AVX2] Failed to read image Animated_PNG_example_bouncing_beach_ball.png. ```

no clue... pls file an issue? 😄

ah, okay, it's not supposed to do that

renaming to `.apng` didn't help

nah, we ignore extensions on the input anyway IIRC

<@!179701849576833024> https://github.com/libjxl/libjxl/issues/756

Thx

It's probably the dispose mode thing

We don't implement everything there out of laziness

We should probably make the apng input accept all valid apngs, and also add an apng output option

yea, it should just not implement what it can't

rather than fail

anyyway <@!794205442175402004> so the `0xFF0A` magic on a JXL codestream file is apparently not sufficient for FFmpeg to autodetect. Well, it works, but the maintainers don't like it since it's only 16 bits. Is there some sort of data validation that comes after `0xFF0A`

like, say, not "these bits are identical"

but

you know, a way to check if it's actually in that format

I'm aware the library provides a function but I'd prefer if the demuxer doesn't have a libjxl dependency, just the decoder

Mhhh so decoding the first few headers and seeing if they make sense may be an option

i've had a few people complain about the 2-byte magic not being enough

haven't seen a single false positive yet though

(and at least two magic-db maintainers have been looking for false positives in their corpuses already)

so as far as I know, yes, it's short, but it's also long enough to be unique given the set of file formats that currently exists in the world

```Oct 20 14:54:54 <michaelni> "tools/probetest 256 4096" fails with Failure of jpegxl_pipe probing code with score=51 type=2 p=5A3 size=2``` <@!794205442175402004>

what does that mean?

it means it gets a false positive

ok, that's interesting

what is the false positive?

what kind of file is it?

or is that test just going through random bitstreams and fails when that causes a match?

I think maybe that

and FFmpeg does not want to match streams if the decoder is likely to throw an error

two bytes not being enough does make sense

should a bit more validation be done?

and is that possible

well there are only 65536 combinations of 2 bytes so yes, random files will have a 1/65536 chance of matching

how other jpeg formats handle that

Does `JxlDecoderReset` purge the parallel runners

forcing me to re-add them

well the old jpeg starts with `0xFFD8`, but that marker always gets followed by another marker so you can match with `0xFFD8FF`

and you can match against the type

like PNG has a magic but you can check to see if the next one starts with IHDR for example

the point of the "compact header" layout of jxl is not too waste bytes on things that are redundant, and a long signature is part of that

but I suppose you could try to do some parsing of the headers and reject most invalid ones

that's fine, but I need to be able to scan the file past the first two bytes to determine if it's actually a JXL codestream

that'd be helpful

even a primitive way of doing this is okay

but I don't now the format of the JXL codestream

the first thing after the 0xFF0A is the size header, which unfortunately is a bit tricky to parse and has a variable length so you cannot just skip over it

what's the format of it?

tbh libjxl should have some sort of function to validate given small buffer of bytes

is it bitpacked

or is Bool() equivalent to u(1)

everything in the headers is bitpacked

little-endian?

bool is u(1)

is oh `u` is unsigned bits?

u(n) is n unsigned bits

U32() is u(2) to select which of the four options it is

so little-endian bitpacked? `small == header[0] & 0x01` or `small == header[0] & 0x80`

wait how default values work

defaults you can ignore here since this bundle cannot be default

things are only signalled if the condition holds though

also id think more than just SizeHeader should be read, because it looks pretty hard to validate that given how well packed it is

anyway, libjxl does have an event for "basicinfo decoded" or something like that

so `U32(u(9), u(13), u(18), u(30)` means ```c switch(u(2)){ case 0: u(9) case 1: u(13) case 2: u(18) case 3: u(30) } ```

is that correct?

that is correct

I don't want to incur a libjxl dependency in the demuxer, only the decoder

since it's optional and I'd like ffmpeg to still be able to understand jpegxl and copy the stream even if you don't have the decoder built

right

that's the whole issue

libjxl *had* a validate function

dig it up in history\

and copy :--DDD

anyway the size header doesn't help much because pretty much anything is a valid size

yuh id think rest of stuff would make more sense

so.. what comes after that could be used to validate it?

that's the next thing that comes after

what is the size header the size of?

the size of the image

the entire codestream, except itself and the 0xFF0A?

was it really hard to have some sort of 1 or 2 byte checksum :<

it's the width and height of the image in pixels

oh

and `height == (height_div8_minus_1 + 1) * 8`

I take it?

hm I don't see much in the imagemetadata either that could be used to disqualify bitstreams

what does ratio start at if `small == 1`

oh, wait, I see, the condition doesn't go over

thanks

I must admit that the size header is a somewhat overengineered thing that adds quite some complication in order to save one or two bytes at best

considering that you have `uint32_t` for the container sequence number

yea

the container is optional though

if you go minimal, you don't use the container 🙂

its kinda fine as it doesn't have too many fields

it also looks like the size header does not necessarily end on a byte boundary

so any complexity is kinda self-contained and isolated

everything in the image header is not byte aligned

so the next header just starts immediately

only after the image header do you get a byte alignment before the frame header starts

are there *any* invalid image headers lmao

so that's one first opportunity to check for invalid bitstreams: the padding bits have to be zero

(but if you're unlucky, there are no padding bits or they are accidentally zero)

oh, btw, I had a question earlier, does `JxlDecoderReset()` also reset the parallel runners? If I don't destroy them, do I have to re-assign them?

I think the only way to be relatively sure that the bitstream is really a jxl and not a random file, is to decode all the way to the end of the TOC of the first frame, wdyt <@!179701849576833024> ?

no idea, I'm not that familiar with the API. <@!768090355546587137> probably knows

is that likely to fall within the first few thousand bytes? i think in most cases (http, local files) that's reasonably cheap

currently ffmpeg still returns "unsure" about jpeg without file extension up until EOI

yes that is likely to fall within the first hundred bytes

perhaps, but if I'm trying to parse it, I'd like to at least, know the format

it's just a bit painful to have to include a parser for all that stuff

I don't need to parse it all, just parse the length tbh

You could also decode the first whatever headers, up to size header say, and check if image dimensions make any sense

yea, that's the plan

question is how likely it is that image dimensions don't make sense

probably likely enough

if first bit is 1 they will make sense

how so?

will they? we have an all_default for sizeheader?

if first bits are 00 they will also make sense

they'll be *parseable*

but will they be sane

no but any small size is sane

ah because that's "small"

right

also 9-bit heights are always sane

how well can you digest Rust?

13-bit heights probably are sane too

it sounds like the strategy here is to parse the headers as much as i need to determine how big they are and nothing else

and then check the next few bytes for a frame header chunk ID

the first few bytes of a frame header are probably much less permissive

our image headers have *very* few ways they can fail (unfortunately?)

In FLIF I considered it a density bug if any bit was redundant, i.e. if random bitstreams didn't decode

Jxl luckily doesn't go that extreme

is there a standard frame header?

Frame header will also not likely fail, except if padding bits before it are nonzero

like, I'm just looking for some heuristic to check if a file is a valid Jxl file without incurring a dependency on libjxl

I think in practice, 0xFF0A should not be the first two bytes of any actual non-jxl file

yes

I don't know how often people try to decode /dev/random and if the 1/65536 chance that it gets mistaken for jxl is a problem

if you want more, I really don't know how you'd do that without some significant effort

where "significant effort" might even require you to implement ANS, because there are files that are not too unlikely where you can't tell unless you decode the whole ICC profile, I think...

(ANS+Huffman+LZ77)

this might be true but the goal is adoption, and ffmpeg's rejecting the decoder patch for this exact reason

if you want like 2x extra accuracy for small effort, you can implement reading the sizeheader (https://github.com/libjxl/jxl-rs/blob/main/src/headers/size.rs#L28) and I think that there's at least a 50% chance that random garbage will be detectable as such

maybe 25%

it *may* be less effort to point them towards the analysis that some people did on a large database related to mimetypes... <@!794205442175402004> do you still have a link to that?

the size header still has to exist tho

what's the smallest size header there is?

1 byte?

on a separate topic, how much space could be saved by a theoretical "jpeg pixel-identical recompression" mode, as opposed to byte-identical? i guess the primary difference in this mode compared to first stripping metadata with exiftool or similar would be that the quantization tables and JFIF headers would not be stored. how much does that work out to?

You can try with cjxl --strip, which strips also the jbrd

are you able to put garbage after a JXL file?

ah, i didn't see that option. will it work around https://github.com/libjxl/libjxl/pull/359?

Yup, although we may want to disallow it

the issue I'm experiencing is that if you conatenate two JXL files together it just looks like the first one

I think it's a good idea to disallow it cause it creates issues where you can have a JXL file that is also a valid MP3 file

I believe you can get away with 1 + 5 bits + 3 non-000 bits

How?

MP3 allows crap *at the beginning*

I've done it with jpeg and mp3

another issue is that concatenating two JXL files together should be something that the library can work with

i.e. it should only consume up until the end of the file

so like, if I concatenate a JXL file with something else, `JxlDecoderReleaseInput` should always tell me that it did not consume the remaining after emitting `JxLDecSuccess`

and sometimes this is legal, butsometimes it's extra info

attempting to set it again should produce an error other than `JXL_DEC_ERROR`

like `JXL_DEC_INVALID_TAIL`

which you would have to subscribe to. alternatively, it could just return JXL_DEC_ERROR and you could add a function `JxlDecoderGetLastError()` wihich would return something like `enum JxlError {}`

different from JxlDecoderStatus since that's a bitwise thing

this would just be a table

<@!853026420792360980> minor nit, i think you don't need to heap allocate LibJxlDecodeContext.{manager,jxl_pixfmt}. they are documented to be copied internally. it's only 44 bytes though

I asked about that but I was told "just make it a nonpointer member of your context"

so I did

hm, ok.

wow, and are *all* of these headers varlength? so does that mean I need to parse *all* of them to parse the codestream before I can start getting to the size?

https://github.com/exiftool/exiftool/blob/master/lib/Image/ExifTool/Jpeg2000.pm#L1093 seems enough to get width and height. roughly 50 LOC including the GetBits function. so it's pretty annoying but it doesn't look *that* bad

also i guess this code is needed if ffmpeg wants to have a native decoder, so it's not exclusively for validating file contents

50 LOC moderately dense perl, but it's mostly bit twiddling so i think 70 LOC C should be sufficient

luckily the size is the first thing at all, so not *too* bad

isn't that the image size, not the header size?

Yes, it's the image size

You can exclude images larger than 2^20 pixels in either dimension, for example

ah actually 2^18 is the max dimension allowed for a naked codestream

since naked codestream has to conform to level 5 of the Main profile

images larger than that should be using the container format (since at that point who cares about minimal headers)

width and height both smaller than 2^18, width * height smaller than 2^28

and padding is required to be zero, right?

yes but the first padding is only after the whole image header

not after the size header

but I mean, if `b` is the first image byte, then `(b & 0x01) && (b != 0x01)` is an illegal state, for example

(and parsing a whole image header to figure out where it ends is not worth it)

it lets me immediately rule out some garbage tho

since I'm thinking that there's only one legal header with the first bit set

and that's `0x01`

uh why?

er, wait

I'm thinking `all_default == true` would zero out the whole hader

but I forgot that there's still `default_transform`

what is `F16()` btw?

is that just, a 16-bit float?

are `NaN` permitted for the `up_weight` headers?

it does look like the shortest possible header tho is `0x03`

one byte <:laugh:501235422479908864>

what's the default size, btw?

either way <@!794205442175402004> I'm running into some issues with jxl files concatenated together, since libjxl apparently allows garbage after the file and it not only permits it with no error but it consumes it as part of the file

at the very least if the decoder is going to allow crap, then it should not consume it, and instead report the crap as unconsumed when you do `JxlDecoderReleaseInput()`

or at the very least, after basic info is ready, there should be a function `JxlDecoderGetStreamSize()`

or something like that, to tell you how much it's going to try to read

(which may be larger than the buffer you feed it)

perhaps it won't be possible, but IMO once `JXL_DEC_SUCCESS` is emitted, the next call to `JxlDecoderReleaseInput` should tell you how much input in the buffer you provided that it did not read

currently it reports zero, even if you concat garbage at the end of the jxl file

since it reads it to see if there's anything of note there

Agreed

A function to get info from the toc would be useful to know not just how much is needed to decode the frame, but also for just the dc and other progressive steps

It only has info about the first frame though

In the multiframe case, there is no way to know the full size unless you parse all frame headers

The releaseinput reporting tail bytes left, does it already have a github issue?

also, do you think it might be worth it to wait until friday to learn if the spec is going to be a bit more public than it is today 🙂

I don't know, I discovered it by accident

release input is supposed to report tail bytes that it did not consume

but in the case of jxl_dec_success it appears to report 0 no matter what

Likely we will make a private spec repo to work on the draft, and I will try to make sure that people like you will be allowed access because you can help us with the drafting

ah, okay. this is a draft of the TeX version of the spec?

The CD of the 2nd edition can be made public but it will take time until we reach that stage

or is this 2nd edition right here

The 2nd edition is tex, yes

At least in the drafting stages

good thing my profession is mathematics <:kek:857018203640561677>

The first header is not ImageMetadata, the first header is SizeHeader - I suggest you give a look at the Rust code

(or the C++ one, but that's not exactly readable...)

I'm trying to parse the size header of a JXL that starts like this

```00000000 ff 0a ba 21 e8 df 81 95 0c 28 a9 9c 12 00 aa d8 |...!.....(......|```

ff 0a -> skip

BA gives you, in little endian order, `0 1 0 1 1 1 0 1`

so you have all_default -> false extra_fields -> true orientation_minus_1 -> `0 1 1` so orientation=7 have_intr_size -> true

and now we have `0 1` and the next bits carrying over

`21 ea df 81` -> `1 0 0 0 0 1 0 0 0 1 0 1 0 1 1 1 1 1 1 1 1 0 1 1 1 0 0 0 0 0 0 1`

so the bitstream now looks like

`0 1` `1 0 0 0 0 1 0 0` `0 1 0 1 0 1 1 1` `1 1 1 1 1 0 1 1` `1 0 0 0 0 0 0 1`

so now we look at the size header

small -> false

`U32(u(9), u(13), u(18), u(30)` -> 11 -> u30

`0 0 0 0 1 0 0 0 1 0 1 0 1 1 1 1 1 1 1 1 0 1 1 1 0 0 0 0 0 0 1` this is not the height.

the first header is not ImageMetadata

oh

what's the first header

signature first, then SizeHeader, then ImageMetadata

SizeHeader is part of Imagemetadata tho, isn't it?

nope

why is there a sizeheader inside

`have_intr_size`

what's that

that's "intrinsic size", i.e. size in screen pixels

ah, okay

aka how viewers should rescale it

signature being just `0xFF0a` right?

yup

https://tenor.com/view/matric-matrix-i-dont-see-the-code-gif-8390287

What is even in Part 4 of the Spec? I thought the reference implementation was libjxl, but in that case what is the £45, 4 page PDF on the ISO website? https://www.iso.org/standard/80619.html

🤔🤔🤔

Part 4 is basically a one-page document that says "here is a zip version of the libjxl repo"

Why does lossless modular JXL with XYB colorspace take up significantly more space than lossless in RGB? (e.g. when `uses_original_profile = false;`)

Because XYB is at higher bit depth

Would near lossless work better with XYB than RGB?

Well squeeze based lossy modular does that by default. The delta palette based lossy palette modular is atm working in RGB (the default deltas are designed for RGB). Possibly an XYB version could be better, but it would require custom deltas.

what bit depth is XYB at by default?

and if you used RGB at that depth, would you get similar results?

XYB in modular is effectively around 11 bit per component, roughly speaking (it's not really a nice power of two because the range is a bit weird)

If you would use RGB at that _actual_ bit depth, it would likely compress about the same, yes

(but just taking an 8 bit image, scaling everything to a higher bit depth, and encoding that will not result in a much larger file - the encoder will notice that only a fraction of the values are actually used, and it will use channel palette to effectively reduce things back to 8-bit)

<@!794205442175402004> looks like I got the prober working, it only fails the fuzzer on 32-byte sizes

I suspect those might actually just be valid JXL files though

when you have 27-byte beauties like these, I think it's decently possible that these fuzzing false positives are not actually false positives but true positives https://0x0.st/-dBq.jxl

Nice!!

how much are you parsing for that?

Yes

the size header in full, but without info on what the rest of the file looks like it's mostly just `all_default` and `extra_field` bits

knowing what the bitstream would look like too would be nice

in this particular failure, it parses 16 bits from the signature, 25 bits from the size header, (all zero), and another 10 bits, which is the minimum size metadata header with `all_default == false`

which yields a 6-byte (48 bit) header with padding

looks like this is what causes it to fail tho

`ff0ae5dd62a2feb0fb7047ef2fa5f8fd70b17ee7d30c0aae0`

it is not a JXL file, since djxl just says failed

that's 49 characters, did you miss some?

Yes

`ff0ae5dd62a2feb0fb7047ef2fa5f8fd70b17ee7d30c0aae00000000`

``` Signature 11111111 ff = 255 00001010 type = 10 SizeHeader 1 small = true 10010 height_div8_minus_1 = 18 height = (18 + 1) * 8 = 152 11 1 ratio = 7 width = floor(height * 2) = 304 ImageMetadata 0 all_default = false 1 extra_fields = true 011 orientation_minus_1 = 3 orientation = 4 1 have_intr_size = true intrinsic_size (SizeHeader) 1 small = true 00010 height_div8_minus_1 = 2 height = (2 + 1) * 8 = 24 011 ratio = 3 width = floor(height * 4 / 3) = 32 0 have_preview = false 1 have_animation = true animation (AnimationHeader) 00 tps_numerator = 100 1010 111110 tps_denominator = 251 11 10110000 11111011 01110000 01000111 num_loops = 1198586800 1 have_timecodes = true bit_depth (BitDepth) 1 float_sample = true 111011 11 bits_per_sample = 63 1011 exp_bits_minus_one = 11 exp_bits = 12 0 modular_16bit_buffers = false 0 00101 num_extra_channels = 4 extra_channel_info[0] (ExtraChannelInfo) 1 all_default = true type = kAlpha (etc...) extra_channel_info[1] (ExtraChannelInfo) 0 all_default = false 1 0 type = kDepth bit_depth (BitDepth) 0 float_sample = false 10 bits_per_sample = 12 1111 1 dim_shift = 8 1111110 name_len = 47 01110000 10110001 01111110 11100111 11010011 00001100 00001010 10101110 00000000 00000000 00000000 00000000 name = (truncated) ```

I've tried to parse it by hand, it fails at the extra channel name

A hand parsed <#824000991891554375> bitstream would make a nice infographic

Like that, but with bits instead of bytes

Could also put the MA tree in jxl_from_tree syntax and as a tree on it, and what the image decodes to

I don't know the format of those various metadata headers