JPEG XL

they posted their own JXL encode and it's bigger then yours

Oh wait, I got it. I was using the ECT compressed version instead of the original file, now the results match...

Aah, okay

It's the alpha channel, for lossy it's still compressed losslessly and bloats the filesize even though it's unused

Or at least, adding `-a 1` to the e2 encode got it down to 4.37 MB instead of 18.8 MB

Oh, you lost me there. I do have some loss on my end, though.

There's no issue before I add the faster decoding to the command.

What resolution is the image? So I have an idea what size can eat 16GB of RAM.

6260 x 19252

Well, I don't have pictures of that size.

I guess I will be fine with those up to 30 megapixels.

e2 a1 4.37 MB e6 a1 3.91 MB e2 a1 Faster Decoding 19.9 MB e6 a1 Faster Decoding 5.66 MB So using lossy alpha helps, but ram usage drastically increased too, from around 1 GB to 10 GB

Actually, I didn't understand your message because I don't know what 'channel alpha' is in this context. I thought you were talking about the encoder version.

Transparency, the image was saved with it, but it's not actually used

I thought 'alpha' was indeed transparency, but I wasn't aware that the image had it. Is that the source of the problem, then?

Here's the *actual* file, not ECT optimized and with the alpha that's causing the strange behaviour

Interesting that I still got a smaller file at e9, but the image hashes match so...

Unnecessary alpha channel is a common mistake. It's worth passing every png at least through fast optipng to tidy the file.

Weird, weird...

It seems like it. It also explains the faster decoding becoming so large, since the alpha is stored lossless by default, and faster lossless currently increases filesize massively

It took me an hour of having the wrong filename entered, but I got there in the end :P

Hmm, everything is clearer now.

I suppose jxl encoder could be tuned to compress flat alpha to nearly nothing. Like it does for color channels in grayscale mode.

Hmm, that gives me an idea

```wintime -- cjxl -e 1 pfnoal.png pfnoal1.jxl JPEG XL encoder v0.10.2 4451ce9 [AVX2,SSE2] Encoding [VarDCT, d1.000, effort: 1] Compressed to 19729.2 kB including container (1.310 bpp). 6260 x 19252, 23.837 MP/s [23.84, 23.84], , 1 reps, 16 threads. PageFaultCount: 1990198 PeakWorkingSetSize: 1.179 GiB QuotaPeakPagedPoolUsage: 35.14 KiB QuotaPeakNonPagedPoolUsage: 21.11 KiB PeakPagefileUsage: 1.316 GiB Creation time 2024/06/24 18:55:48.283 Exit time 2024/06/24 18:55:55.014 Wall time: 0 days, 00:00:06.730 (6.73 seconds) User time: 0 days, 00:00:13.984 (13.98 seconds) Kernel time: 0 days, 00:00:16.468 (16.47 seconds)``` As expected, 19 MB ```wintime -- cjxl -e 1 -R 1 pfnoal.png pfnoal1Squeeze.jxl JPEG XL encoder v0.10.2 4451ce9 [AVX2,SSE2] Encoding [VarDCT, d1.000, effort: 1] Compressed to 4586.5 kB including container (0.304 bpp). 6260 x 19252, 22.469 MP/s [22.47, 22.47], , 1 reps, 16 threads. PageFaultCount: 2412380 PeakWorkingSetSize: 5.922 GiB QuotaPeakPagedPoolUsage: 35.14 KiB QuotaPeakNonPagedPoolUsage: 280.5 KiB PeakPagefileUsage: 9.36 GiB Creation time 2024/06/24 18:56:24.931 Exit time 2024/06/24 18:56:31.974 Wall time: 0 days, 00:00:07.043 (7.04 seconds) User time: 0 days, 00:00:08.656 (8.66 seconds) Kernel time: 0 days, 00:00:16.687 (16.69 seconds)``` Enabling Squeeze, 4.37 MB (Although 5x the memory usage)

However, the encoder couldn't detect flat alpha in streaming mode anyway. It would be better if graphics software was better behaved and didn't write unnecessary alpha in the first place.

after 2h05m and 16 GB of RAM usage, `cjxl v0.10.2 e1489592 -e 10 -d 0 --brotli_effort=11 --allow_expert_options -I 100 -g 3 -E 11` gives `17327786` bytes <:KekDog:805390049033191445>

and your -e 9 is smaller ??? <:ReeCat:806087208678588437>

I always have more than both of you. <:PepeHands:808829977608323112>

I'm trying `ECT -9` right now, but it's been 30 minutes and nothing is happening.

I used `ect -9 -strip --mt-deflate` but I don't remember how long it took (under 15min iirc) but yeah, without `--mt-deflate` you're going to wait for some time <:KekDog:805390049033191445>

ECT is trying hard but I found even more pngs previously compressed by Pngout where ECT just couldn't improve anything. And I was considering deprecating Pngout, oh well.

I know about the secret options but if ECT can't compress a png in 24 hours, I consider it a failure 😄

Finally! `Saved 46.42MB out of 79.10MB (58.6809%)`

I'll remember that for next time.

Why the `--allow_expert_options`?

No, you shaved a few kilobytes off https://discord.com/channels/794206087879852103/794206170445119489/1254853312193232896

I forgot to remove it, it doesn't change a thing I know

no, I used the ECT'd one

Ah, wondered if you were trying to do e11 for some unholy reason

Oh

Silly me, I was in energy-saving mode.

Aircraft engines have just started up.

Is it normal that I get the same result with `-a 0` and `-a 1` ?

(Both are lossy.)

Interesting....

Alpha is compressed separately in lossy JXL and it uses different algorithm which is based on lossless. So I suppose lossy alpha could give the same result as lossless if there is no information to remove, like in completely flat alpha.

The algorithm is based on lossless compression, but the final result still contains loss. Or maybe only the alpha part of my image is lossless...?

i think the alpha data is lossless, whereas the RGB data is lossy

So I should do `-e 10 -a 0 -d 0` ?

Lossiness of alpha is independent on RGB data. Alpha is lossless by default.

So set the `-a` argument only if lossy alpha is desired.

Ah, OK, now I understand. And if I want to remove the alpha channel (since it doesn't seem to be used in this image)?

It seems cjxl doesn't have any option to discard alpha completely. So you will have to remove alpha in the png first.

`oxipng` should do the trick. It has both slow and fast options.

Thanks!

oxipng automatically performs these reductions: - remove alpha channel if it's all non transparent - convert the image to grayscale if all colors in the image are shades of gray - convert the image to paletted png if it uses 256 or less unique colors (this one doesn't matter for jxl)

ECT which we were using before also does all that, although usually with less memory and smaller results

So, ECT compression removed the alpha channel?

I should be able to check myself, but I don't know which tools to use yet.

Yes, it's why I kept getting small results

Perfect

Both ECT and oxipng are using zopfli compression. ECT can do very strong and exhaustive compression. Oxipng provides better control and more options like keeping or removing specific metadata. Each of the tools have its use.

i'm trying to use Adobe DNG Converter

discord why did you send that i hadn't finished typing

I'm trying to use Adobe DNG Converter's CLI to convert some DNG files to JXL, to see how that works. However, the syntax is very confusing. If I use `-dng1.7 -losslessJXL` it gives me a 50mb file, however if I use `-dng1.7 -jxl_distance 4.9` it gives me the exact same 104mb file as if I just pass in `-c`

Prepare yourself, for Adobe's command line is the devil's plaything

I forget every time, but you probably need to use -lossy too

shouldn't that be implied by me giving a distance?

I'm not actually sure if distance will work though, since effort does nothing even when using their given example

bruh

💀

If it was sane software, yes, but only god knows what goes on inside that unholy file

this is making me want to write a wrapper script

🤔

Case sensitive, order dependant, sometimes non-functional commands with no warnings or error output

like you'd think it would be like ``` Ignoring `-jxl_distance` as `-lossy` was never specified ```or something?

but no

When I tried to get it working last week, I think that was the case

I just had to try every option until it gave me a new output, but I never got something other than standard lossy or standard lossless JXL

also does it have any kind of `-info` thing, so I can check it's doing what i want it to, or is it just "look at the file size and make an educated guess"

This is everything we get https://community.adobe.com/havfw69955/attachments/havfw69955/camera-raw/23452/1/DNG%20Converter%20Command%20Line.pdf

not even the courtasy of `-help`?

There's also `-lossyMosaicJXL` which might trigger that to work

i'm using iphone RAWs, which are linearised

it's probably just trying to encode `-help` to `-help.dng`

wait does `-lossy` imply `-jxl`?

But yeah, no help menu, no command line output at all, just that PDF and whatever it spits out, assuming it outputs anything at all

i think either my JXL isn't working or `-lossy` implies `-jxl`

ok and passing in `-jxl` by itself does nothign

JXL probably isn't working

i worked out a way to see if jxl is working

my imagemagick doesn't support dng 1.7 so it gives error

otherwise if jxl didn't work imagemagick can read it

this is the dumbest crap ever but at least it works

after testing i think `-lossy` defaults to JXL unless you set a dng compatibility target

as forcing `-lossy -dng1.4` outputs 14mb where as `-lossy` by itself gives 10mb

and passing `-jxl` by itself does not do anything for me

maybe we should make a thread

I was using (forgive me) the default Windows photos app to check the same way, if it loads then it failed, if it fails to load then it worked

adobe dng converter is a pile of crap

Dropping trivial alpha is not really something we can do in libjxl, since in multi-frame / multi-layer images it is quite common that the first frame has trivial alpha but then the next frame do actually use alpha. Since we have to write the image header in the very beginning (which says if the image has alpha or not), there's a problem there (unless we'd only do it when the header hasn't been written yet and we know for sure that no more frames will follow).

I guess modular would be pretty good at saying “the whole channel is 255”

There's also the philosophical question of whether an RGB image is really the same thing as an RGBA image with trivial alpha

Single leaf node saying Set 255?

Yes, it will compress very well, but it will still make decoding a bit slower and maybe cause some applications to use slower rendering paths

Max group size of 1024x1024, I used squeeze on the image yesterday to make it almost negligible, but for some reason that increased memory usage drastically (And I don't know if the alpha actually remained lossless)

Is there no way to say “trivial alpha” in the individual frame header?

A job of the application rather than the library, but someday cjxl might be able to go "Oh it's a png, there can't be layers or frames"

The entire image must be loaded in memory to tell if the alpha is completely flat so automatic alpha removal in streaming mode is not possible.

yeah, maybe running a quick pass of optipng on the input first should be the solution

after all, if it’s so important for the jxl file to drop the alpha, one wonders why it’s not already dropped in the input png (or why it was ever written to it in the first place)

However, cjxl has some options that are lossy when `-d 0` , for example `--modular_lossy_palette` or `--keep_invisible=0` or `--override_bitdepth` so there could be an option to forcibly discard alpha channel.

`cwebp`, for example, has `-noalpha` option for this exact purpose.

And of course, if used inappropriately, the result may look kinda funky.

except APNG and PNG kind of looks the same to cjxl 🙂

Ah right, not sure how that slipped my mind haha

we could add something to cjxl to strip trivial alpha (and other things, like converting gray-only RGB to grayscale, 10-bit-encoded-in-16-bits to 10-bit, etc), but it wouldn't be _that_ useful since presumably most people will use libjxl through some application (an image editor or whatever else), not through cjxl directly.

[Update] Original PNG file: 78.0628 MiB After `ect -9` compression: 31.4756 MiB `-e 2 -d 1` Size: 4.32036 MiB `-e 6 -d 1` Size: 3.99667 MiB `-e 10 -d 1` Size: 3.75707 MiB `-e 2 -d 1 --faster_decoding 4` Size: 4.61448 MiB `-e 6 -d 1 --faster_decoding 4` Size: 4.9829 MiB `-e 10 -d 1 --faster_decoding 4` Size: 4.7028 MiB `-e 2 -d 0` Size: 32.8732 MiB `-e 6 -d 0` Size: 21.632 MiB `-e 10 -d 0` Size: 16.5365 MiB `-e 2 -d 0 --faster_decoding 4` Size: 32.8784 MiB `-e 6 -d 0 --faster_decoding 4` Size: 34.6443 MiB `-e 10 -d 0 --faster_decoding 4` Size: 31.7738 MiB

these numbers look normal to me

There is another quirk so cjxl always creates alpha channel if the source is GIF.

It makes sense the application should be responsible to choose the appropriate pixel format. Unfortunately, applications often make poor choices. As long as JXL will be able to compress completely flat channels to few bytes, it's not that big issue.

I agree. So, it was an alpha channel issue.

Thanks to everyone who helped; it was funny to take such a serious approach to a porn image.

There's a lot of it on the internet, so it makes sense to make sure they encode properly too

that's a lot of savings between e 2 and e 10 <:Thonk:805904896879493180>

e 10 being ~half the size of e 2 is unusual

e 9 is also smaller than e 10, based on my file

I don't know what's going on with lossless jpeg transcoding but it got noticeably worse during past few months. For example a file transcoded using a build from the end of January is 128748 bytes. After reconstructing to jpeg and transcoding again using the current build, it is 129154 bytes.

did you use the original jpg when you tested both, or did you go jpg -> jxl -> jpg -> jxl?

It *shouldn't* have mattered since transcoding should be bit-identical, if it's not then there's much bigger issues

I was going back and forth but that doesn't matter because losslessly transcoded jpegs are being reconstructed exactly. Actually I always do a check after compression.

AFAIK it's only bit-identical for the image data, *not* any metadata

I'm sure the lossless transcoding is bit-identical for the entire file. If the encoder couldn't perform perfect preservation for some reason, the encoder would give an error.

That's normal lossless, then it turns ICC tags into enums if possible or skips them entirely

there's a non-normal lossless?

Jpeg transcoding stores a jbrd box to allow bit-identical reconstruction

There is also an option to do lossless transcoding without keeping the reconstruction data. But such JXL files appear just like ordinary JXL files and can't be decoded back to jpeg.

weird

this is by far the hungriest image codec library in term of dependecy needs

You can trigger the normal lossless by adding `-j 0` to the command, it rarely reduces the size at all yet alone the 20%+ transcoding gets

I thought -j 0 forced a decode and then reencode?

i.e. you're either going to make it larger (when doing lossless, unless the source was a lossless jpeg) or lose some more information

That's correct.

so that's not really a "lossless transcode", or at least, not one with any practical value

There's also `--allow_jpeg_reconstruction=0` That will disable creation of the jbrd box and only transcodes the bare image data. The resulting file can't be reconstructed back to jpeg because libjxl can't tell it was originally jpeg.

Yeah, that's what I meant by 'normal lossless'

ah, now that makes sense

Okay, so the current build performs worse in lossless jpeg transcoding than few months ago. Is it a bug or am I missing something?

did you check that you got the same image when transcoding back to jpeg?

I'm using `-j 1 -e 10 --brotli_effort=11` and yes, I can still get the exact original jpeg.

🤷 then likely some change to the entropy encoding that makes it worse for that particular image

The regression is consistent among multiple jpegs.

What's nice the jpeg transcoding is fast but I wouldn't mind having `-e 11` for lossless transcoding and giving it a minute to perform better. At the moment, `-e 11` is equivalent to `-e 10`

anyway, speaking of testing, why are there no good, freely available & usable testing corpora for images (jpeg or otherwise)?

I know QOI has a tar of images, but a lot of them are pretty awful (e.g. many of the photographs have this weird border around them)

For photo, you can take pictures from wikimedia or e.g. pexels and downscale them by at least 2x to make them more or less pristine.

For nonphoto, I think it is really hard to construct a representative test set...

I'm guessing wikimedia would not appreciate me downloading thousands of images with a script

a lot of those dependencies are not strict dependencies and are only used for the command-line tools

is libjpeg-turbo neccesary? (for decoding)

There are jpegs in existence that jpegli can't decode.

but libjpeg-turbo can

Mostly due to bugs that are already fixed but not in a release yet

Hi. I strongly believe progressive decoding is one of the most important, if not the most important, feature that makes JPEG XL worth considering for web delivery context (the context which may well make or brake a format nowadays…?). I have some questions about progressive, super-newbie, but haven’t found answers anywhere… 1. jxlinfo doesn’t print any information about how progressively image was encoded, is that true (tried `-v` and can’t see more verbose) (I am comparing two CDNs here, one is “more”, the other “not enough” progressive in my opinion) 2. I heard “all lossy JXLs” are somewhat progressive. What is the control over making them more or less progressive? Is there a detailed writeup somewhere? (something like the martians for JXL: https://cloudinary.com/blog/progressive_jpegs_and_green_martians#how_about_another_scan_script_) 3. Going into sci-fi, I could imagine encoder to be driven differently when it comes to “scans” for thumbnail images of which there are 50 on a page versus for hero images one per page. So: basically by resolution. But forgetting sci-fi, what would be the sensible default for **all images** when it comes to progressive encoding options for JXL (like when eg. useful MozJPEG got rid of ugly black and white scan…), that would work well in all contexts? 4. Is there a downside to filesize by making the image more progressive? Or any other downside? I am doing some baby playing. It doesn’t help the only browser that (almost) matters “forgot” to support progressive JXL 🤦‍♂️ (this is the only place I know when one could voice opinion on this: https://bugs.webkit.org/show_bug.cgi?id=272350). Sorry for the length. Any ideas super-welcome.

not for decoding .jxl files, and not even for losslessly recompressing .jpeg files as .jxl

nor decoding such .jxl files either

do you know the macros to disable usage of libjpeg-trubo headers

IIRC there was an idea libjxl could decode jpegs on its own.

It already can, just with a silly detour: you can pass it a jpeg and tell it to losslessly compress it to jxl, and you can then pass it that jxl and tell it to decode it to pixels.

it will automatically not use them if it can’t find them; there shouldn’t be any need to tell it explicitly, unless you have them and you _still_ don’t want it to use them (I don’t think we currently have a switch for that)

but jxl can't represent all (de-facto standard) jpegs, so libjxl can't decode all (de-facto standard) jpegs

Can lossy jxl be reprocessed into being "more progressive" (AC/DC) without adding any further loss?

Yes, in principle. No such tool exists atm though.

Depends on how exactly you define what is the de facto standard 🙂

It cannot do CMYK, but then again there's a lot of software that doesn't properly handle CMYK jpegs so arguably it's not really part of the de facto standard.

is there any reason it doesn't support cmyk or it just not worth development time

JXL is hardcoded in the spec to 3 components for VarDCT.

CMYK JPEG, how it is implemented, is a very ugly hack IMO.

libjxl can generate patches but it has hard time finding opportunities for efficient use of patches. Is there any API allowing applications to create patches directly?

Not at the moment. We could in principle add that, but if we do, I'd do it after 1.0 — it should be doable without breaking the basic API.

is 1.0 releasing soon ?

I am traitor

The only crime I see here is that q40 jpeg

true lmao

Idk why discord did that

If you look on the right, the screenshot has been compressed on top of the server icons which probably doesn't help

I wish jxl had some kind of debug analysis thing like “flac -a” which prints out information about the file

The latest build still fails to decode the file I've posted here some time ago. Unfortunately, djpegli doesn't have verbose flag and gives very non descriptive error..

by any chance, do you know something like `flac -a` but for JPEGs ?

`djpeg -d -v` prints out lots of derails

<:FeelsReadingMan:808827102278451241>

best you can do so far is `jxlatte --info=trace input.jxl`

`jxlinfo -v input.jxl` prints some info but not a ton

or you can compile libjxl with verbosity at some higher value than 0

jxl-oxide also has trace mode (`-vv`) but it's quite noisy

Is jxlatte compiled or is it just a .jar

`jxlinfo` isn't enough?

a jar

<@794205442175402004> just wondering what would be the best settings to compress some really small PNG images into JXL? These kind of files

they're from a dataset and im trying to shrink them

lossy or lossless?

lossless

i should probably throw through a png optimiser to remove alpha channels and convert to grayscale when possible

yes, that's probably a good idea

and then it depends on how much cpu time you have available to encode it to jxl 🙂

i guess i can afford -e 10

i was wondering if there were optimal modular settings or something

can you check if this file is valid?

it doesn't open on my mac for some reason

in Thorium it works, in Preview it shows something broken, in Safari it doesn't load

grayscale+alpha is one of those things that are often broken

do you really need the border of transparent pixels around it?

probably not

it's a dataset i downloaded

i can probably just set them to gray 255

idk why but MacOS seems to not have implemented everything in JXL, namely animated JXL doesn't really work at all

(It displays correctly in Firefox. I mention this because it's usually with them that the format is only partially supported.)

firefox doesn't have JXL support tho?

Probably the broken nightly flag

These images have white pixels under the alpha, so just deleting the alpha will do the trick.

`pngcrush` can delete alpha without touching the color of the pixels.

how do you do that?

nvm i just used imagemagick

Now that Apple has added support to all devices, and in light of the continued and increasing support from Adobe, Samsung, and all the other corporate representatives that mentioned their excitement and anticipation for the feature before it was unilaterally removed by the former on2 technologies tech lead, is mozilla or Chromium going to update their position on this? I have a feeling that their choice would be to refuse to add support regardless of how popular jpegxl becomes

It's a very transparent strategy of the webp/avif tech lead Jim Bankowski trying to sabotage the adoption or success of the format by removing it from Chrome with zero opportunity to appeal. And not even taking ownership of his own decisions and actions by using vague and undefined weasel words like "we" and "our partners." And having a fake email address for feedback that just goes to a black hole.

I just wonder how something so ridiculous could happen and remain standing for years without anyone calling out the ridiculousness of it all

As the head of the chrome codec team it's his responsibility to make decisions over what codecs are included with Chrome and its pretty juvenile for him to use weasel words instead of outright saying it was his decision because that's his job and responsibility. Instead of pretending like he justified it by consulting with unspecified "partners" he should just say that he didn't like it and no amount of corporate support will change his mind.

And instead of lying about wanting feedback and encouraging people to waste their time sending emails to a null inbox, he should have been honest and had the decency to say it's not up for appeals or debate and no one should even bother

I wish I had the time and resources to work on getting JXL working in Android, it wouldn't be *too* hard, I generally know how adding image codecs kinda works

all the media stuff for android is located here https://cs.android.com/android/platform/superproject/main/+/main:frameworks/av/media/

Would be cool if the grapheneos camera took photos in jxl format

And if there was an app to convert the camera roll to lossless jbrd

what's jbrd?

jpeg reconstruction?

oh the jpeg bitstream reconstruction data box

This I don't think would be too hard to do.

Wouldn't it be better to lossily convert raw into jxl?

not everyone takes photos in RAW

barely any phone camera app takes a photo in raw

i guess iPhone proraw?

almost all of them same jpeg directly from the camera framework, some of them now save webp or heif from it now, but mostly its still just jpeg

opencam for instance just encodes the jpg to png or webp last I checked

but yeah, excluding iPhone Pro or enthusiast phones, most just use JPEG or HEIC (if Apple)

ofc *some* apps do actually process the photo and decide what to save it as

I think photoncam does that

Does jpeg xl support 1 bit color, and if so is there a way to use it with cjxl when compressing an already 1 bit color image?

1bit like black and white?

Or like 8 colors

It is little hidden. pngcrush allows selection of the color type (0, 2, 4, 6) using `-c` argument.

<@625718249262284800> in reference to <#848189884614705192> , it depends on if you're using lossy or lossless. Lossless the default group size is 256x256, but can be changed to 128, 512 or 1024 Lossy uses variable block sizes, so probably best to just go with 256x256 to cover both lossless and lossy

yea

`cjxl` can convert PNG in 1 bit grayscale format to 1 bit lossless JXL. ECT optimizer can convert black and white PNG to the correct format. Another option is converting the image to PGM and using `cjxl` with `--override_bitdepth=1`

is <:JXL:805850130203934781> significantly better than JBIG2 for 1bpp images? has someone done testing?

Thank you. I’ll try 256 if I still use manually splitting.

Probably not. JBIG2 is designed specifically for just 1-bit images. JXL is way more generic, so it can do 1-bit but e.g. current libjxl will still use 32-bit internally...

The difference is that JXL does 1 bit in lossless but JBIG2 is lossy.

JBIG2 can be lossless too

I see, it can be lossless by disabling that funky character replacement. Anyway, JBIG2 looks too obscure to me, it wouldn't be my first choice. I'd rather use PNG.

JBIG2 in a PDF is quite standard

And quite old, JBIG2 is allowed starting from version 1.4

Well, like I said, if there was a way to take photos in JXL that would be nice... Like from the grapheneos camera...

jbig2 probably can't do anything patches can't do in jxl

theoretically, I mean

djvu also has a codec similar to jbig2

along with a DCT codec and a wavelet codec. It's very similar to <:JXL:805850130203934781> actually

There are too many codecs designed for 1 bit. TIFF itself supports a whole bunch of different 1 bit codecs with funny names. Why are people obsessed with scanning in 1 bit? It looks terrible and the text is often illegible.

> Since JB2 (also called DjVuBitonal) is a variation on JBIG2, working on the same principles,[18] both compression methods have the same problems when performing lossy compression.

so it seems to be a direct relative, not just similar

JBIG2 was also banned by some authorities.

Anyway, I didn't mean 1 bit is completely useless. It can be used for example in art.

It was banned because the lossy mode would alter certain glyphs which could change a 5 into a 6 for example and potentially result in financial consequences if used for financial documents.

Which is honestly really stupid design of lossy compression.

Lossy should mean the image looks worse, not silent modifications to the source file

1 bit was mostly just something that was done when memory was very limited and you wanted to get as much resolution as possible

I think the word "bitmap" dates back to the early days when basically all images were 1-bit

If images and text are created specifically for 1 bit, it works pretty well. It can also look quite nice. But converting analog media to 1 bit is not that easy and requires some effort so the result would be actually usable.

I think ordered dithering patterns used in early GUIs look neat.

So I like 1 bit if it is used right.

https://m.youtube.com/watch?v=DlgWsFJScU8

<@688076786525143117> your comments on 1 bit graphics reminded me of this recently released video

TLDR 1 bit graphics were basically ideal for business documents getting scanned/faxed over the slow modems of >40 years ago

Also you could barely fit an 8bit grayscale document in your entire available RAM back then

So it makes sense they would do 1 bit for documents and then develop a buncha algorithms to compress it further so that you didnt have to wait tens of minutes for a document to get faxed

I remember having one of these graphics cards: https://en.m.wikipedia.org/wiki/Hercules_Graphics_Card

It could do 720x348 which was considered very nice high resolution back then

It was 1-bit though

That all makes sense but I have seen too many scans that nobody reviewed if they're are any good, resulting in unreadable mess. So that's why I don't like them.

yeah they can suck if not done properly

These are interesting and the screens used with these cards usually have colored phosphors. HGC can indeed do only 1 bit graphics but text can use 4 levels of luminance.

4 levels? Yeah I do remember brighter text when in text mode. Don't remember 4 levels though, just the two. Maybe also fg/bg inverted versions?

And yes the monitors were usually orange, sometimes green.

Mine was orange

On one of my first computers, a second hand 8088 with a whopping 20 MB hard disk

Which was enough for DOS and WordPerfect 5.1 and a couple of games

The monitor can do 4 levels. The interface is 2 bit. Not sure if the card can output all 4 levels. There were particular rules how the text attributes translated to the output because the same attributes were used for color text in color graphics cards.

Programs usually had a special setting for "monochrome" because the translation wasn't perfect.

The high resolution was ideal for text processing as it allows crisp text rendering. The native resolution of text mode is 720x350. CGA, in comparison, is in color but low resolution, only 640x200, resulting in poor text quality. EGA text is 640x350 and VGA text is 720x400.

Mine first was Spectrum with tiny bw monitor and without even floppy, only compact cassette 🥲 These specific sounds when the apps (well, be honest, games) were loaded from cassette. And only much later upgrade to floppies and CGA with 16 colors. I remember my cultural shock when I saw win 3.1 on VGA monitor for the first time

I'm trying to read Annex A to understand the JXL header structure, and it's just talking about bundles and conditions and whatever without actually explaining the header structure at all...

My eyes glaze over as I try to find the place where it actually starts revealing actionable information

Also the JPEGXL Short Headers Google doc is Access Denied

...It references tables and conditions without so far actually defining the data structure for them or how to read them...

So it's just confusing for it to be referring to these abstract things before they are even defined in real material terms

It should probably define low level data types first before explaining abstract ones.

Instead of just defining the on disk data structure, it uses pseudocode to explain how to read it? This seems needlessly less straightforward than it could be...

How much complex logic do I need exactly in order to get something as basic as the image resolution or number of channels? This document makes it sound like the image header can potentially be an infinitely complex tree with conditionals

This might help slightly https://discord.com/channels/794206087879852103/824000991891554375/901846809654198273

Ah okay, the section that actually explains the header structure is a.4.2

That was a really hella confusing preamble that I think could be shortened and simplified a lot...

The spec is probably not designed for most people to read

This project exists but is still not complete

https://discord.com/channels/794206087879852103/1254012901816274956

Maybe <@794205442175402004> could help with it

for some uses -- like Switzerland and Germany may have some clauses against fuzzy matching if the document is used for official archiving

thank you 🙂

In any case, I wouldn't use 1 bit encoding for documents because it often decreases readability.

just dither and increase resolution 😉

Or just use jpeg 😉

boooring

Alrigh alright, so grayscale VarDCT jxl then.

too efficient

I've seen also scans in GIF using 16 levels of gray.

These were okay.

The spec describes... how to read the header, rather than just describing the header layout itself. It really slowly describes how to read it, with pseudocode, instead of just describing the binary layout as quickly and directly as possible.

the layout is dynamic due to things being variable length

and idk this seems like a pretty direct description, not "code"

They probably mean the “condition” field of something

I didn’t find it particularly difficult to understand, although some stuff in the JPEG bitstream reconstruction confuse me (although it’s most likely just a skill issue)

can I just ignore the jbrd box if I’m planning to decode to pixels?

Yes

You can strip it and the image data is identical

Or my reading code is bugged

The jbrd box only contains whatever else is needed to reconstruct the jpeg file, besides image data, color profile, and exif/xmp/jumbf metadata. Usually it only contains some details on the layout of the jpeg bitstream (baseline or progressive, what Huffman codes are used, etc). Though it can also contain (unrecognized) APP markers and tail data, which can be information that might be meaningful, like a whole second image...

I think I was trying to parse the APP markers and failing miserably

What are APP markers again though?

I’m not too familiar with how JFIF works

They're the way to add any kind of metadata to a jpeg file. ICC profiles, Exif, XMP: those are embedded using APP markers (which are treated in a special way in jxl, since their contents is not stored in the jbrd box but elsewhere). All kinds of other stuff can be in app markers too, though usually only supported in specific applications.

Are they the 0xFFEx segments?

Yes

So JPEG XL raw code stream starts with 0xFF0A which could be interpreted as a JIF segment, could you have a JPEG XL and JPEG 1 polyglot file ?

That does but it takes a long time to get there, and I don't think it explicitly states whether or not these bundles must be in a certain order after the magic signature.

No, 0xFF0A looks like a JPEG marker but it was chosen because it was still available. So there cannot be ambiguity, the marker means "start of jxl codestream" and is reserved across all JPEG codecs. J2K also has markers specific to J2K, for example.

I’m saying could you have a JXL code stream then a JPEG code stream concatenation and the JPEG decoded would ignore the JXL?

It's not a marker a JPEG decoder would understand, and we don't put the segment size in it like typical JPEG markers do (which also limits the segment size to 2^16 bytes)

``` let is_multiple_of_8 = read!(Bool); pub let height = if is_multiple_of_8 { let height_div8 = 1 + read!(u(5)); height_div8 * 8 } else { 1 + read!(U32(u(9), u(13), u(18), u(30))) }; ``` just wondering is there a specific design reason that the `is_multiple_of_8` thing is only usable up to a height of `256`?

i guess would it have diminishing returns for bigger images?

also with using a ratio to get the width, does it round the width down/up or is it just invalid to have an image with a ratio stating a fractional width?

it's normal integer division, so truncate (or round down because it's positive)

so if i have a 384 height and using 6/5 i get 460.8 which becomes 460?

also im guessing if the image is 5/6 it's just flipped and the orientation is set to say so?

It's meant for small images like icons. For an image larger than 512x256, using one or two more bytes in the header is not going to be significant.

That makes sense, it’s another optimisation specifically for small images

We wanted small images to have as little overhead as possible, so you can do things like icons with one file per image instead of having to do annoying things like making a sprite sheet containing multiple icons to reduce header overhead

I feel like at that point you start hitting filesystem overhead anyway, namely block size

As far as I know, at least NTFS can pack such files directly to MFT

On file creation it can, modifying the file moves it into a standard block, such as editing/stripping metadata, ect

Why do people always say 10/12 instead of 5/6

It's weird since people say 3/4 and 4/5

When referring to screen aspect ratio

Never heard that, I only heard about 16:10 (8/5). The reason is understandable (16:9 exists, so comparing it is easier)

Well in the JXL spec for example, they reference 12:10

maybe in reference to 16:10 😁 (nah, I don’t know)

what format should i use interally for representing image data during the decode process? is a u32 good enough to fit everything or do I need to use some kind of float?

also are u32s big enough to store image dimensions?

for jxl images, u32 is enough because jxl cannot represent dimension larger than u32 range

it's around 30 bits or so

what about the actual pixel data?

i32 is safe for Modular buffers, f32 for VarDCT and filters

ill make it a generic then

f32 can also be needed to store the result of Modular images if they use a float representation (e.g. if you do lossless compression of a pfm or exr)

internally the buffers are i32 but they may not semantically be integers, the sample values could e.g. be half-float or float bitcasted into i32

modular predictions are done in integer, after that those values may be interpreted as floats

(spec requires bit-exact decoding of lossless 32-bit float image)

so treating them as int32_t / i32 is fiine?

yeah, until you need floats to process those buffer

is there any way to give libjxl a yuv420p / yuv422p10le / yuv anything stream to libjxl?

For the purposes of screenshot?

im trying to encode from a ProRes video source

like a y4m stream or something

cjxl used to support y4m, but not anymore

That exact use case has been done before a few times with a patched ffmpeg

Are you trying to do lossy or lossless?

It would be nice if libjxl could encode directly without needing to convert to RGB first. But oh well.

Anyone know a good way to convert from yuv to RGB with dither and minimal artifacts?

i'm trying to do lossless but d0.2 lossy should be fine

it's for like archiving and stuff

but i don't want it to be in prores

as it's proprietary

also yes new account old one got suspended somehow im not sure why, contacting discord

We're not really keen on adding an API to libjxl to have pixel formats that are not one sample value per component per pixel, since that tends to complicate things quite a lot. Also, we see chroma subsampling as a (blunt) coding tool for doing lossy compression, but conceptually images are still RGB pixels. That is, the encoder takes RGB input and the decoder produces RGB output — internally it might convert to yuv420, but that would be an encoder choice (we don't really think that's the best thing to do) and we don't really want to expose such internals. JXL does support yuv420 and yuv422 (it needs to, for JPEG recompression) and with some code plumbing you could take yuv420 input and store it losslessly; at some point cjxl did support that but that was before it used the libjxl api. However, we only support it the way it is used in JPEG: the full-range yuv matrix (video content is often using limited-range), and centered sampling positions (a chroma sample is in the middle of the 2x2 or 2x1 luma samples) — video content typically uses the weird asymmetric thing where the chroma sample is cosited with the left luma sample in case of 422, and centered vertically but not horizontally in the case of 420 (so it's centered between the top-left and bottom-left pixel of the 2x2 block). So if you would decode such a jxl file, the yuv420 would be converted to rgb the JPEG way, which would be wrong if the yuv material you have uses a different matrix or sample positions.

It would technically be possible to have a decode option to skip the conversion to rgb and to return the yuv420/yuv422 as is, and then as long as the metadata about what kind of yuv it actually is is available somehow (e.g. by convention), that would work. But it's not very elegant, since the jxl would decode incorrectly unless it's full-range yuv with centered sampling positions like in JPEG.

If lossy is fine, then I wouldn't bother trying to pass data as yuv, and just convert it to rgb before encoding. Most of the jxl coding tools don't work together with chroma subsampling (e.g. you cannot use variable block sizes and adaptive quantization, since the block types and quant weights are shared between components), so whatever you could win by having less chroma data to encode, you'd lose by being restricted to basically jpeg.

For lossless, obviously storing less chroma data will help for compression, and storing it as yuv will also help since conversion to rgb will cause the artifacts of one component to creep into the others and the overall entropy of the r,g,b will be worse than that of the y,u,v.

So just split it and have 3 seperate files, img.y.jxl img.u.jxl img.v.jxl?

yeah that would work, though of course you then still need to have some mechanism to make it viewable

I don't know what variants of yuv ProRes uses, but I would assume it's limited-range with left-aligned sample positions (like it typically is in video codecs)

so jxl cannot represent that directly — the only yuv flavor we can store directly is full-range center-aligned

Does “tv” in ffmpeg mean limited range?

yep

tv range, studio range, limited range, it's all the same thing

ProRes uses yuv422

And yuv444

No 420

limited range has Y values in 16..235 (in the 8-bit case), leaving some 'footroom' and 'headroom' for probably mostly historical/legacy reasons that have to do with analog systems

If I upsample it to 4444 could I apply some kind of icc to store yuv444 in JXL?

yuv444 can be done in jxl directly too, that's also needed for jpeg recompression

but only with full-range

yeah, I guess it should be possible to construct an ICC profile that effectively implements whatever yuv444 variant you want

I think given I don’t need exact lossless (I’m just trying to extract good looking frame grabs) is the yuv to rgb16 insignificant enough to be insignificant

And if I need mathematical lossless I can do the weird split file thing

looking at that picture btw, the 4:2:2 there is indeed cosited with the left pixel of each 2x1 pair, which is the video way, while the JPEG way is to have it centered

yuv to 16-bit rgb is insignificant enough, yes

even to 8-bit rgb it's not very significant tbh

the other way around is more problematic

8-bit RGB are 16.7m different colors, 8-bit full-range yuv are only ~4m different colors and with limited-range yuv it's even fewer.

so converting 8-bit yuv to 8-bit rgb introduces some rounding errors but it doesn't really throw away information, while converting rgb to yuv removes at least 2 bits per pixel of information

My source data is 10 bit yuv so might as well give jxl 16 bit RGB data , jxl is gonna do whatever with its VarDCT

yeah give it 16-bit or even float data

Not sure how to do that in ffmpeg but I’ll work it out

(The float data )

make sure to properly tell libjxl what colorspace it is in, in particular if that 10-bit data is HDR (say, PQ where maxval is 10000 nits), libjxl needs to know that

(otherwise it will probably compress the darks too much since it will assume it is sRGB at 100 max nits or something like that)

Ffmpeg passes it to libjxl with HLG data attached

It tags it with the hlg transfer function

``` JPEG XL image, 2160x3840, lossy, 16-bit RGB intensity_target: 1000.000000 nits min_nits: 0.000000 relative_to_max_display: 0 linear_below: 0.000000 Color space: RGB, D65, Rec.2100 primaries, HLG transfer function, rendering intent: Relative ```

When converting sample formats, don' t you need to dither also?

Dither?

No I just used ffmpeg

I’m not on computer rn

I’ll send my command some time later

always better when bit depth is reduced

or some transformation happens between the formats

as then the intermediate is 32-bit float...

I think 16 bit rgb should be fine

yes

(at least if it's not stored in linear light)

even linear should be ok in 16-bit, at least for HLG at 1000 nits. For PQ at 10k nits it might be a little tight.

Hi guys, How can I improve encoding quality for a 12bit image? The 12bit image will finally be scaled up to 16bit and then get displayed on the screen. So the result of doing JXL encoding for 12bit in the 16bit mode is not good enough. Is it possible to tell the encoder the highest level is just 4096? I tried adjusting intensity_target, but the quality increase was considerably less than scaling up to 16bit first then do encoding. I also tried setting `bits_per_sample` in `basic_info`, which leads to a weird result: much smaller file size and much worse dark area quality.

`cjxl` should do that for 12-bit PPMs, so the way that it passes those to libjxl should be a way to do that

No, I've tried a 14bit grayscale PGM. The cjxl just treated it like a 16bit grayscale image.

12bit ranges from 0 - 4095 and 16bit ranges from 0 - 65535, so if a 12bit image which packed in 16bit stream is sent to libjxl, the encoder will think these pixels are quite dark so they can be heavily compressed.

have you tried `--override_bitdepth=12` ?

that doesn’t match what I’m seeing

```shell $ identify 507.ppm && tools/cjxl -x color_space=RGB_D65_202_Rel_PeQ 507.ppm test.jxl && tools/djxl test.jxl out.png && identify -verbose out.png 507.ppm PPM 944x1080 944x1080+0+0 12-bit sRGB 5.83376MiB 0.014u 0:00.013 JPEG XL encoder v0.10.2 7b9701eb3 [AVX2,SSE4,SSE2] Encoding [VarDCT, d1.000, effort: 7] Compressed to 177.0 kB (1.389 bpp). 944 x 1080, 7.703 MP/s [7.70, 7.70], , 1 reps, 32 threads. JPEG XL decoder v0.10.2 7b9701eb3 [AVX2,SSE4,SSE2] Decoded to pixels. 944 x 1080, 61.894 MP/s [61.89, 61.89], , 1 reps, 32 threads. Image: Filename: out.png Permissions: rw-rw-rw- Format: PNG (Portable Network Graphics) Mime type: image/png Class: DirectClass Geometry: 944x1080+0+0 Units: Undefined Colorspace: sRGB Type: TrueColor Endianness: Undefined Depth: 16-bit Channels: 3.0 Channel depth: Red: 16-bit Green: 16-bit Blue: 16-bit Channel statistics: Pixels: 1019520 Red: min: 0 (0) max: 59162 (0.902754) mean: 32772.4 (0.500075) median: 32739 (0.499565) standard deviation: 11124 (0.169742) kurtosis: -0.464595 skewness: 0.0675413 entropy: 0.976761 ```

if it was treating this 12-bit input as 16-bit, the 16-bit output png wouldn’t reach such high values

No, there is no `override_bitdepth` in libjxl... Only `bits_per_sample` in `basic_info`

Thanks for the info. Let me have a check again on my test.

<@604964375924834314> You are right. It does know the bits of ppm if the thrid value in ppm is correct. (It was wrong in my previous test)

I need to check how cjxl use the API

I suspect the relevant information will be in `lib/extras/dec/pnm.cc`

it seems `basic_info.bits_per_sample = params.override_bitdepth;` in `enc/jxl.cc`

that weird, me setting `bits_per_sample` cause a different result than cjxl

does it behave as expected if you set `bits_per_sample` to 12, but `format.data_type` to `JXL_TYPE_UINT16` with the values scaled to 65535? (or alternatively, JXL_TYPE_FLOAT and scaled to 0-1)

Oh, thanks, i can set the bits correctly now. But the problem still exists: setting bps won't effect the compression quality. With or Without `bits_per_sample`, the encoding quality is still worse than `upscaling to 16bit first then do encoding`.

upscaling to 16 bits is what I meant

I think you’re meant to do that if using `format.data_type=JXL_TYPE_UINT16`, regardless of `bits_per_sample`

which indeed is just informative metadata for the decoder

if you don’t do that, and then decode your jxls to (12-bit) PPMs using `djxl`, I suspect you’ll find that they’re not using even that range anymore

or are they?

I always use data_type=uint16 in my code because the input array is always uint16[] . But whether the bits_per_sample is 16 or 12, the output files quality are the same when they all scale up to 16bits to be displayed. And the compressed file sizes are the same too. Upscaling to 16bits first, can produce a larger file size with the same distance.

right, and I think using `data_type=uint16` means that libjxl expects 0-65535 data, regardless of `bits_per_sample`

the `bits_per_sample` are only there to say “the data in this jxl were originally 12-bit”

nothing more

using only the range 0-4095 would be pretty much like using `data_type=float` and only using the 0-0.25 range

there is a way to use uint16 with non-padded 12-bit (or 14-bit) data like how ppm does it. You need to use `JXL_BIT_DEPTH_FROM_CODESTREAM` instead of the default `JXL_BIT_DEPTH_FROM_PIXEL_FORMAT` when setting the bit depth `type`.

basically the default for uint16 is the PNG way, but switching the `type` allows you to do it the PPM/PGM way.

I was going to post this for some rough guidance https://github.com/libjxl/libjxl/issues/1763

Thank you for the advice. I’ll have a try

The issue post is very helpful.

I've tried setting `JxlEncoderSetFrameBitDepth` and my program's output is exact like the cjxl output now. But for a 12bit source with same distance: **Method 1**: Set up `JxlEncoderSetFrameBitDepth` and `bits_per_sample` to 12, then do the jxl encoding. **Method 2**. Manually scale up 12bit to 16bit by value shifting, then do the jxl encoding in `bits_per_sample = 16` Why 2 produce better quality and larger file size than 1 (almost 3 - 4 times larger)?

Method 1 will encode a very dark image since you are only using a very small fraction of the 16-bit range. You need to also set JXL_BIT_DEPTH_FROM_CODESTREAM if you want to pass 12-bit values using the 12 least significant bits, the default is to pass them using the 12 msb

Yeah, I already setup the JXL_BIT_DEPTH_FROM_CODESTREAM. I'm doing more tests on this.

I had another test: ``` original-14bit.pgm(48.7MB) scaledup-16bit.pgm = (values in original-14bit.pgm) * 4 DO cjxl -d0.2 -e7 ON original-14bit.pgm -> lossy-14bit.jxl(3.1MB) DO cjxl -d0.2 -e7 ON scaledup-16bit.pgm -> lossy-16bit.jxl(3.1MB) DO cjxl -d0 -e3 ON original-14bit.pgm -> lossless-14bit.jxl(17.3MB) DO cjxl -d0 -e3 ON scaledup-16bit.pgm -> lossless-16bit.jxl(23.5MB) ``` (all of them with `-x color_space=Gra_D65_Rel_Lin`) For lossy compression, they are the same, so there is no problem for this now. But why for lossless, the result are different? The information they contained should be the same.

Not quite, especially at e3 which does not do channel palette nor good hybriduint selection. The values of everything are 4x as large which makes entropy coding require more bits (at least at low effort where the obvious pattern that all lsb are zeroes is not exploited)

Also technically the proper scaling from 14-bit to 16-bit is to do *65535/16383 and round that to the nearest integer. That's not quite the same as doing *4 which makes the two lsb zero (so e.g. white maps to something slightly darker than white this way)

Thanks for the explaination. After trying with a `-d 0 -e 6` , the 16bit pgm can be compressed to 17.3MB.

Which is a good size?

Mention of palette reminded me of this yet again, 60bpp causing over double the uncompressed input size <https://github.com/libjxl/libjxl/issues/3511>

Now in production (Safari, Thorium etc only, obviously) 😜 https://www.theguardian.com/world/2023/dec/12/donald-tusk-second-coming-can-returning-pm-remake-poland (throttling Thorium down to Slow 3G doesn’t make this progressive very… impressive 😿 ).

I set Waterfox to Good 2G and the progressive was pretty good

Now in production (Safari, Thorium etc

I have a question about the `intensity_target`. Let's say we have a Linear Gray 16bit lossy JXL image with `distance 1.0` and the default `intensity_target`(I guess is 255). If I double all the values(increase brightness by 1 stop) in the image in post-processing, then the image we seen should have worse quality than `distance 1.0`, right? So what `intensity_target` should I set, to keep the `distance 1.0` quality after the brightness increase by 1 stop?

Should I just set the `intensity_traget = 255 * 2`?

Basically: yes. Unless I am missing something, <@604964375924834314> ?

as far as I understand the statement, yes, because then the compression will effectively get the same thing as the brightened-in-post image

Is everything in the VarDCT Step divided by the intensity target?

during encoding, multiplied

intensity_target = 510 implies brighter values than intensity_target = 255, so the input values (in the 0-1 range) are scaled accordingly

when decoding, they are divided by it to fit in the 0-1 range again

So input, wherever it’s from is converted to 0-1 then multiplied by intensity target?

<@794205442175402004> <@604964375924834314> Thank you guys.

Then in decode, the vardct data is divided by intensity target then scaled from 0-1 to whatever output format ?

So shouldn't it follow this formula: `2^(8 + stops) - 1` ? And why 65535 cannot be set to intensity_target?

It seems 65504 is the top value allowed. Going above 65505 will cause the error.

Oh, I did the research, HDR uses FP16 so the max is 65504