JPEG XL

I dunno what this shows

0 xor 0 is maxval

this problem

it's XR much more original

original

its 1 bpp

Could you use butteraugli or ssimulacra heatmaps instead?

Comparisons in RGB are not very meaningful

orig xr xl

why is that

Also, maybe `--epf=3` would help?

But maybe this is a bug, better to crop this part of the image and compare only it and file an issue

Are that crops of the actual images?

It looks like some kind of false/exaggerated color...

Ah the actual crops are above

The jxl does look pretty bad indeed, would be good to check what block types it is using there...

no

hope for your work<:galaxybrain:821831336372338729>

:prayd:

interesting that JPEG XL does not use small blocks (for red)

`-e 3` is close to a regular Jpeg and it uses less different blocks, if I am not mistaken

original

cjxl -d 0.5

block selection in this region

cjxl -d 0.5 without color profile weirdness

How did you produce that jxl?

>cjxl.exe -e 7 -d 1 --epf=3 20210828_130710.png

in the block selection, things don't look unexpected. Yellow is 8x8, green is larger, red is 8x4 or 4x8

i'll check d 1

check it

d1

yep

block selection

<:banding:804346788982030337>

overlaid for convenience

the question of course is why everything is well smoothed here

is there a function to smooth Contrast blocks

do you have any idea why the original has so much red in the bread at that edge?

sun light

it is also possible that this is a lumen of bread through and through

ok, so far I have deduced that my old JPEG XR photos are compressed at an average of 4 bpp so I think i can easily make the transition to ~3 bbp which is roughly from -d 0.2-0.3

but I did not understand how D differs from Q

-q 98 gives what i need

D and Q dont do anything different

Q gets turned into D

<:Cheems:890866831047417898>

by eye I can say for sure that with a 25% reduction in file size, the quality is slightly better of compare with the original

and yes, it turned out that the "tortoise" Mode will take a lot of time somewhere around a week for all the photos without a break, so I'll get by with a "kitten"

I noticed some manga,anime site start provide avif,webp lossy and stop provide jpg,png, It's really sad😢 , for high quality lossy web use case, I still believe jxl(finish quality improvement) -d 1.0~0.5 is best practice...

Look like current lossy-palette(delta palette) not support YCoCg, both command give same result. > -m -e 9 --lossy-palette --palette=0 -g 3 -E 3 -I 1 > -m -e 9 --lossy-palette --palette=0 -g 3 -E 3 -I 1 -C 1

Yes, the default deltas are made for RGB and there only is an implementation that uses the defaults atm

https://twitter.com/jonsneyers/status/1492903356834226182?t=zvBMQw_lpF4k89b9GQfQ-g&s=19

Very important poll

"image"

computer graphic picture

"Superswinebirdman"

Thank you for testing with this. Would you create a bug in the github repo about the image quality?

I'm sorry but I don't want to reg github

this problem is changed the weights of some algorithms, the problem, is that an insufficient amount of information is distributed into not very noticeable Dark color gradients

Although this is probably a bigger problem if such a distribution comes from an algorithm that determines the subjective quality, I don’t do much testing yet, but within a month I will do the same again because the last time - I ended up being dissatisfied with the fact that after the fact at small compression level jpeg XR algorithms distribute all the information over the image much more evenly, while Jpeg XL has hard blockages and borders between the distribution of information.... The ideal option would be to use BPP compression but this does not suit me.

The ideal way to solve the problem would be to encode parts of the image independently, because no symptoms are observed if you compress the parts and fragments of the image separately by about 256 pixels

But the compression power is down from this.

<:JXL:805850130203934781> It would be nice to have programs for analyzing exactly how much data is encoded in a particular part of the image

our adaptive quantization field is the same for X, Y and B

I have had some adjustements of abs(X) ratio to Y

I suspect we want some more bits for chromacity changes in low intensity areas

do you compile your own jxl -- would you be able to try new parameters?

changing https://github.com/libjxl/libjxl/blob/c8a76d798abca7439f8139d6beb4cc4460748ebe/lib/jxl/enc_adaptive_quantization.cc#L187 to const auto avg_ratio = Min(ratio_r, ratio_g); (or Max) might help

Nice.

Actually, would it be possible to have a separate aq-mode bias parameter? You'd have: `-aq-mode 1/2` with 1 being the default, and 2 with a low-luma bias.

no

I only do tests if anyone compiled cjxl.exe for me

thank you for letting me know

I'll think about this, I have some ideas

Ji i posted sample in benxhmarks

Do you think jxl can encode this font

What is the developer for cjpeg

Is one of three most popular ones in libjxls?

the easiest fix would be to change https://github.com/libjxl/libjxl/blob/254aea0aeccff8983a1a55a459352b29133ffd4f/lib/jxl/enc_frame.cc#L510, to remove 0.65f and then make the next line to default qm value to 2

this would improve red-green chromacity at low distances (below 0.65) by 40 % or so (IIRC)

I'll just change it in the repo, I don't other people are expressing a lot of interest in distances below 0.65, and it is reasonable that very high quality images can be zoomed more

Me would like 0.371 distance

But at that point id go lossless

Why don't you round these numbers, do these hundredths do anything?<:FeelsReadingMan:808827102278451241>

I have problems

So im sure lower than 0.371 distance i wont go

I usually use target distance 0.5 and e 8

But i Guess person who works in video engineering can and see good at that distance even lower

And is useful for improving codecs

I called it a bug because the fact that at qualities 97-99 there is an exact pixel-by-pixel correspondence almost lossless, and against this background squares appear, and this is bad

I think can increase `--intensity_target` to fix some error on lower target distance. > cjxl -d 0.5 -e 8 --intensity_target=4000

Jpeg xR sacrifices a lot for pixel-matching, but doesn't make any of those missteps even on many times lower qualities

In previous comment, Jon mention "really non-photographic" non-photo content use non-DCT method(jxl delta-palettization) and colorspace YCoCg(close to RGB) can get better performance. A little curious, libjxl will implement which strategy for "really non-photographic" non-photo content? (like av1 have DCT and Palette prediction, opus have SILK and CELT)

No jxl in my opinion is best

1 encoding neomelodic already compressed destroyed content

2 text

3 photos

I agree with this mentality. I created an internal bug for this, will try to make improvements, and I will track the progress on it. I will expect the community to be giving feedback on the observed quality.

I just wanted it to be clear that 0.3 goes to one or the other bucket

Now that PR actually compiles and does the thing I tried to do 🙂

I did not understand the meaning of the specific -d values, so I just use the quality key

av1 have lossy YCoCg 12bit implement(12,12,12 on YUV plane), probably implement lossy YCoCg 24bit(24,24,24) will provide more benefit for delta palettization?

I test different type "really non-photographic" non-photo picture on current jxl delta palettization, but I think sometime still have some artifacts, current delta palettization can't control quality or distance, I guess if implement YCoCg(24bit) and distance(-d) option for delta palettization, probably can get better result?

I will fix them all, just file bugs for delta palette quality

on github

I think those artifacts not delta palette bug, current delta palette can't control quality, and compressed file size is very small, so I think those error happen on this file size is expectable, I expect those artifacts will clear on higher quality quantizer(like -q 95 or -d 0.5).

Hi everyone. I'm planning to use jpeg-xl to archive a lot of JPEG photos, now reaching about 15TB. For now, thinking of using jpeg-xl lossless compression and maybe, minimal lossy in the future, but not sure yet. Sorry if this is a stupid question, but is libjxl lossless compression algorithm completely safe? Are there any risks of it not producing a mathematically identical photo?

file a bug on not being able to control quality

I'll add better quality settings with happiness there

JPEG recompression mode should be completely lossless. You can satisfy yourself that this is the case by encoding a sample of yout jpegs, then decode them back to jpeg with djxl, and then compare the hashes of the files. The lossless recompression mode doesn't work for CMYK JPEGs, though they are pretty rare.

Hi for now near lossless is

for %i in (C:\Users\Utente\Desktop\setwo\fou*.png) do cjxl -s 7 -d 0.456 --intensity_target=271 -p --patches=0 --epf=2 %i %i.jxl

If you want less aliasing

Then wait

Until JPEG XL can better control the colors

The aliasing is strong with this setting

Very strong

JPEG XL left alien artifacts by default said jon sneyers in a slide presentato in

I had serious bugs like di sicilian rappers becoming black

I already made some conversions and all went fine. My concern is that I have about half million of photos and can't test this on a reasonable amount of files

Yes

how can I check if jpeg file is a CMYK one?

Theoretically there should never be any loss, however that is non-withstanding any unknown bugs.

imagemagick can identify them, but I'd probably just let cjxl fail on them as a decent means of identification.

If your images are photos it is very unlikely they are CMYK.

oh, I see. My first thought was that it would just screw up the files

No camera will produce CMYK, so an active effort to convert them would have to have been made.

cjxl will just fail to read them and spit out a helpful error.

Sorry for if I misread your comment, It's mean will implement a quality control option for delta palette? Is possible combine vardct mode(XYB) and delta palette mode(YCoCg), use heuristic estimate which algorithm is better, and use target distance(-d or -q) control quality? https://discord.com/channels/794206087879852103/794206087879852106/943479678826594364

The photos are taken and than are post-processed by Photoshop editors using basic filters (like blurring, digital makeup) and saved as JPEG

I'm pretty sure they would not be CMYK then.

Oh, thanks for that. My concern is just around libjxl stability. It's an amazing piece of software, but I don't know if I can blindly trust it for lossless compression. I'll follow your advice, make some conversions and checking if all is fine. Thank you guys

The program was formally stabilised back in February last year (it might have been Feb 2020), and if any bugs do exist I'm sure they would be in some really weird edgecase that it is very unlikely you would run into.

You can check if it is CMYK with imagemagick.

Oh, great. I'll do some testing

Here's a script I wrote for converting all of the files in a folder losslessly in place. It does remove the originals however, so make sure you have a backup until you are confident with it.

Actually, that's a private repo, let me post it here. (Consider it BSD 2 Clause if you need.)

great, many thanks

if you want to be absolutely sure, you can write a little script that does the roundtrip (`cjxl orig.jpg compressed.jxl; djxl compressed.jxl reconstructed.jpg`) and then checks if orig.jpg is identical to reconstructed.jpg before removing orig.jpg

Yes, I could add (some) quality settings to the palette mode, too. The quality settings would be somewhat more discrete than in other modes. It is possible to do both more and less bits, but I think the attractive area is to do more bits and have higher quality options available.

if I remember correctly most of the jxl lossless encoding is bit exact. so the decoded image should be bit exact to its original. so <@!670734665044197376> you should be able to check the roundtrip hash against its original, to ensure its completely lossless.

In previous discuss, Jon mention "really non-photographic" non-photo content use non-DCT method(jxl delta-palettization) and colorspace close to RGB(YCoCg) can get better performance. libjxl `-d disanse` option probably can auto switch vardct(XYB) and delta palette(RGB or YCoCg implement) for non-photo content? > https://discord.com/channels/794206087879852103/805176455658733570/942120326999978024 > _wb_ — 2022/02/13 > XYB is also suitable for non-photo, but perhaps less so than for photo. > A lot of non-photo material does get created in RGB, so there are certainly cases where it's a better idea > (for compression) to stay in RGB or something close to RGB (like YCoCg). > > https://discord.com/channels/794206087879852103/805176455658733570/942129214361047140 > _wb_ — 2022/02/13 > I think (var)DCT is only really suitable for photo and "photo-like" non-photo, > like realistic paintings or renders, fps games, drawings with pencil, charcoal, chalk etc. > For "really non-photographic" non-photo, like screenshots with mostly text and > UI elements, logos, charts, and digital illustrations with hard edges, > I think DCT is not the most effective approach. Lossless compression techniques > (with lossy preprocessing, e.g. (delta)-palettization) will work better for that imo. > We already do that for patches of text (it's encoded losslessly after doing color quantization in XYB, > and subtracted from the DCT image so if the color quantization introduced some error, > there's still a chance for the DCT part to fix it)

Since <https://github.com/libjxl/libjxl/pull/358>, "lossless" JPEG recompression is not even _intended_ to be bit-lossless in all cases. cjxl produces output even when reconstruction data is not preserved. In any case, to be sure your data is recoverable, you must _always_ roundtrip your files and verify.

BTW, if this is purely a storage use-case, <https://github.com/dropbox/lepton> should perform better overall, though there are some files Lepton cannot compress that cjxl can.

In principle if the return code cjxl gives is zero, it succeeded encoding without error and it should be recoverable. But it doesn't hurt to double-check, never know if there's a bug left...

Hello!

Is JXL general purpose, and should it replace most other formats?

JXL is definitely a general purpose image format with the potential to replace most other formats. It has best (or near best) in class performance for both lossy and lossless content, supports high bit depths and HDR, as well as not having any reasonable limitations to things like dimensions. It is also fast enough to not lose out to the existing legacy formats, which is very nice. It has both a lossless mode and a lossy mode, so is a great replacement for both JPEG, and PNG. The lossy (VarDCT) mode is somewhat tuned towards photographic/realistic images, but even then it performs quite well on most illustration content.

<@456226577798135808>

Yeah that's not gonna fly. How can you patent something someone else is using?

Linux

Encode.su

Data compression

Don't the original creators have rights before anyone else?

I don't think the Microsoft patent has much substance w.r.t. jxl. Haven't read it, but it's either one of the kind "we can use ANS for something" or "we have a specific tiny improvement for a specific use case of ANS". It's somewhat annoying that the patent system works like that, but I wouldn't worry about it.

https://forums.theregister.com/forum/all/2021/03/13/microsoft_ans_patent/

Patents are basically a kind of NFTs that companies collect because some people somehow think they have value, and then they periodically let their lawyers negotiate how much they're paying one another based on how high each one's stack of patents is. It's a silly game and it is not helping innovation.

But in case of jxl, I wouldn't worry. Cloudinary and Google have defensive patents, that are basically meant just to discourage trolls from trying to make money by bullying people into paying them license fees "just in case". The Google and Cloudinary patents are granted royalty-free to the whole world, with one terminating condition: if you start making claims that would make jxl non-royalty-free, then you lose the right to use Google's and Cloudinary's IP. It's basically the equivalent of copyleft licenses but for patents instead of copyright. If Microsoft would claim they have non-royalty-free patents that are needed to use jxl, then automatically their right is terminated to use Google's and Cloudinary's IP, and there is nothing saying Google/Cloudinary would even have to license it at all then to Microsoft. So they would end up not being able to use jxl themselves at all. That should be a strong enough deterrent to prevent them from trying anything evil.

It's stupid that we even need such defensive patents in the first place, but I guess that's the world we live in.

Haha that would be hilarious if m$ was the only company not allowed to use it.

Well I don't think it will come to that 😅

So can i shoot in jxl?

If the MS patent covers JXL, then wouldn't JXL itself be prior art to help invalidate it?

AV1/AVIF also have patents, doesn't seem to be much hinderance to them 😛

That's what I'm thinking

So how do videos work?

Does the algorithm extend over all frames of the video, or is each frame a separate jxl?

Especially if a video is treated as many parts of the same image cut up and displayed separately. Like, one really long jxl image.

I think that could work.

Not sure how well it'd work for video *editing*.

> 6.4 Multiple frames > A codestream may contain multiple frames. These can constitute an animation, a burst (arbitrary > images with identical dimensions), or a composite still image with one or more frames rendered > on top of the first frame. > NOTE The frame that is being decoded is referred to as the current frame.

Unless you're doing all intra for digital cinema work, a video codec is better than GIF, APNG, or animated JXL for most use cases

Gotcha.

Wait, why is that?

The secret sauce of video codecs is that they can encode motion as well as just differences between frames

So JXL/APNG/GIF can say a pixel has changed by a certain amount between frames, but video codecs can also encode where it's moved to

JPEG XL is pretty bad at storing parts that stay the same between frames, which is a major optimization that all video codecs do. All-intra is a mode that stores all the frames, rather than just the differences between frames, and is typically used in cinema and editing

GIF is also just a really bad codec

What about repeating portions of the same image? You could solve this by having each frame be one part of the whole image so that the encoding happens over everything.

Like, a really tall image. Every *frame-height* pixels is a frame.

you can use blend modes in jxl

and encode delta frames

But can the process of extracting those portions losslessly be automated?

why not

each frame in jxl has a blend mode

It depends on how the blending works.

yeah so you can write an encoder that does it

i just mean that the format supports it

ok... And blending is part of the spec?

yes

Wait, so organic portions of the jxl spec can be reused to do things that video codecs are designed to do?

that sounds pretty dope

And it's *just* the encoder, eh?

The only format change would be adding sound, then.

yeah and i dont see a reason why one can't just make an extension to jxl to add more features like sound

or even motion encoding

obviously you'll need the supported decoder

but underlying format would conform to spec and you'd still get an image

since that's the idea as i understand it

How would extensions work? Does the spec have a way of doing that already?

presumably even better than previous jpeg

How's that work?

The spec has quite a few things that could be used for video (in particular, cropped frames, blending, patches). The current libjxl encoder isn't really doing anything to optimize video though, it just encodes frames completely independently.

Video codecs will still be better, jxl has patches but motion vector fields like video codecs have are likely significantly more effective.

Utilizing an existing multimedia container would make more sense than extending JXL.

Sticking individual JXL frames in something like MKV feels better than trying to turn JXL into an A/V container format

Yes, but then you can only use intra. Jxl is not a video codec but it does have some inter tools, like cropped frames, subtracting the previous frame (kAdd blend mode), and patches which in principle is a very versatile coding tool that can be used as poor man's motion compensation.

But I guess there is little incentive to make an encoder that fully uses what is available in jxl for video, since it will never beat real video codecs.

In an authoring tool for something like sprite-based animations with parallax layers, it could however make sense to have a custom jxl encoder that uses the info that is known to the authoring tool to make perfect patches. That _could_ be very effective for that specific kind of content.

I'm also thinking of emulators of old game consoles like snes that had hardware sprites - in principle it would be possible to compress something like a screen capture of a super mario speedrun very effectively and pixel-perfect when mapping the hardware sprite rendering to jxl patches.

Well, an encoder can do both, ffmpeg can do APNG but also supports individual PNG frames in something like MKV

One of the things I'd eventually like to see is something like FJXL in ffmpeg to use for lossless video recording in place of e.g. FFV1

Because I can then always do a second pass to convert it to a normal JXL animation, or convert it to a video to upload to sites

That's a good question. They were saying video codecs are better than still codecs, but i wonder if the different usecase changes that.

I like to know whether lossy jxl frames at d1 - d3 with fast presets & least compressible image could send fhd at 60fps through 2.4Ghz wifi.

Ok but with all that said, is someone working on a MANIAC-based video codec?

Yes, but it already exists in the form of FFV1.

Isn't it VI?

ffv1 is basically a fixed MA tree

Haven't heard about that issue in jpeg

Well the number of passes per frame is limited to 11, so that particular issue cannot happen

But you could have other small bitstreams that take a lot of resources to decode

<#824000991891554375> is one example

cwebp have experiment feature `-delta_palettization`, cjxl have `--lossy-palette` `--palette=0`(delta palettization), what's different for libjxl delta palettization implement? And just little curious, libjxl delta palettization will get more improvement in near future?<:BlobYay:806132268186861619>

Current `delta palettization` use RGB colorspace, so sometime compression rate worse than varDCT and XYB, probably use YCoCg or YCoCg-R will get better compression rate?

I don't think it makes much difference, doing an RCT or using different delta entries boils down to the same thing I think

Current jxl delta palette also happen file size inflate issue for specific type non-photo picture, similar DCT worst case issue. I think this issue also happen on Modular lossless. > Modular lossless,manga > > original 962,047 > Modular lossless e3 1,812,312 > Modular lossless e7 612,280 > Modular lossless e8 584,272 > > original 4,050,574 > Modular lossless e3 7,917,770 > Modular lossless e7 4,728,379 > Modular lossless e8 3,340,568

> JPEG XL encoder v0.7.0 36ece47 [AVX2,SSE4,SSSE3] > cjxl -m -d 0 -e 3 --num_threads=12

Hello <@!794205442175402004>, Sorry to bother you, Could you teach me what reason let YCoCg(lossy) worse than YCbCr(lossy)? I read some article say YCoCg have better transform precision and have YCoCg-R variation, but I still don't understand what reason let YCoCg (lossy) worse than YCbCr.

I don't think there's a big difference for lossy between YCbCr and YCoCg, they are quite similar. But the Y of YCbCr is a bit closer to actual luma — the Y of YCoCg is 0.5 G + 0.25 R + 0.25 B which is a bit of a rougher approximation. XYB is significantly better than YCbCr though.

So it's mean jxl delta palettization use YCoCg-R or XYB probably a better choose? and not recommend use YCoCg(lossy) for "really non-photographic" non-photo content?

For delta palette, I don't think it makes a big difference if you do encode(delta(rct(original))) or encode(rct(delta(original))), the difference is basically if you do the RCT on the pixel values or on the delta entries

at least for YCoCg/YCbCr that's the case

for XYB it's a bit more complicated due to it not being a linear transform

Current Modular lossy(squeeze) will use YCoCg-R? or use YCoCg(lossy)? I think probably YCoCg transform can Increase delta palette compression ratio?

And other jxl feature `--patches` `--epf` `--noise` `--dots` probably can let delta palette work better?

Little off topic, Current aomenc av1 have YCoCg(lossy) 8,10,12 bit depth implement, if source is screen content or "really non-photographic" non-photo content, YCoCg(lossy) will have some advantage for YCbCr? I don't really understand which is better, Could you share your opinion?

lossy modular uses XYB by default, it gives better results than YCoCg or YCbCr

we don't have lossy YCoCg in jxl, only YCoCg-R

(well I guess you could in theory implement lossy YCoCg by means of an ICC profile or by doing YCoCg-R and then removing the lsb of Co and Cg)

I think the only advantage of lossy YCoCg over YCbCr is that it's slightly faster to decode, but that difference is probably quite irrelevant, especially if the GPU accepts YCbCr natively

I understand, Thanks for your guidance 🙂

I update my Issue, hope we can get varDCT and delta palette combine mode in near future.<:BlobYay:806132268186861619> > https://github.com/libjxl/libjxl/issues/1188

original 962,047 lossy-palette e7 1,170,146 original 4,050,574 lossy-palette e7 17,566,749 > JPEG XL encoder v0.7.0 36ece47 [AVX2,SSE4,SSSE3] > cjxl -m -e 7 --lossy-palette --palette=0 --num_threads=12 > "really non-photographic" non-photo, manga, Grayscale, palette > encoding time very very slow, some picture spend over 3 minute.

I try to apply other predictor mode(`--predictor=K`) for delta palette, but I get some issue on encoding...

I guess current delta palette only have RGB implement, so some grayscale png,jpg and palette png will have file size inflate issue?

yes, for grayscale and palette png files, delta palette will not be a good idea at all

For "photo-like" non-photo color,grayscale content use varDCT, For "really non-photographic" color non-photo content use delta palette, For "really non-photographic" grayscale,palette non-photo content, I should use which lossy method in libjxl? (similar av1 lossy palette prediction method)

original 962,047 av1-aomenc-q10-s4 399,229 original 4,050,574 av1-aomenc-q10-s4 1,277,190

> Version: 0.9.3 aom [enc/dec]:3.2.0-143-gf20d487e3 > simple setting: > avifenc --min 0 --max 63 --minalpha 0 --maxalpha 0 -d 10 -s 4 -j 12 -a end-usage=q -a cq-level=10

<@!179701849576833024> Can 8-bit XYB be lossless converted to 8-bit RGB?

Nope

Oh, so you always need a higher bit-depth to convert a perceptual color space like XYB to RGB losslessly?

I somehow thought XYB was fully lossless at the same bit-depth.

Nope :) I don't know of any colorspace that does that

Unless you count things like SubtractGreen with wraparound logic

I find this issue at 2021 October 08, I guess jxl probably can implement more non-DCT feature for "really non-photographic" color,grayscale,palette non-photo content?

Photographic i hope they fix in 4 weeks

I believe I understand the concerns that Lee has and can work on them, but I don't yet understand the concerns you have

original png: 15MB

I used a distance of ``0.1``

Interesting. I am noticing that jpegxl loses quite a bit of quality with green colors

(but in order for me to notice that, I have to zoom in like, 500% on the image)

download original PNG here: https://library.amd.com/share/12122FAA-0E17-45A3-B76FE7C4EFC0FB58/?mediaId=C15E5BFC-7884-4C4C-A2CE9A9C219E1EB9

What are the advantage for jxl(webp) delta palette? If compare other png lossy method? > lossy Median-Cut posterized, lossy PNG8 palette(256color), lossy Averaging filter(predictors).

Mostly that it can do smooth gradients without dithering

I read some delta palette detail from Jyrki Alakuijala, look like I misread something for delta palette and webp near-lossless detail before, I guess jxl delta palette will be a future and more advanced near-lossless mode, hope we can use complete version delta palette in near future(combine varDCT and target distance). 🙂 > Jyrki Alakuijala: > In JPEG XL we haven't yet invested into this, > but WebP v. 1.0 near-lossless heuristics were developed by JPEG XL team members. > I'm considering that the next attempt I'll give on the near-lossless effort > in JPEG XL is likely through custom palettes (combined with the hybrid delta palette). > This is already in the format, only needs an encoder that prepares palettes particularly for this use case.

Why this assessment choose MS-SSIM? haven't choose DSSIM? > Multi-bitrate compression perceptual evaluation dataset 2022 > https://github.com/google-research/google-research/tree/master/mucped22

That's a great question.

If I were to guess, it's because MS-SSIM is very fast.

If I were to guess, it's because of the DSSIM license

Is it really?

It uses AGPL and a commercial license <:Thonk:805904896879493180>

I don't know why that would be a problem for research like that, as long as it is not used in any production environment, but I think Google lawyers for simplicity just say "don't touch it"

I see.

I am trying to add metadata support in KDE https://invent.kde.org/frameworks/kfilemetadata/-/merge_requests/56 The code is trivial. They said, they need test files. When I added them, they said that the tests fail on their system. The reason for failure is obvious, they do not have image/jxl mime type registered.

Woah, that would be amazing when implemented.

Surprised they didn't even think of installing the necessary packages before testing them 😛

You can find many raw files from various canon cameras here: https://www.dkamera.de/testbericht/beispielaufnahmen/ (though the site is German) Or I can provide more from my Canon M6 Mark II.

exiv2 is one of the many extractors used by kfilemetadata. You may try to ask if exiv2 can parse dimensions from codestream header but I am not sure about if/when it will be implemented.

I do not have image/x-canon-cr3 registered on my system. What package (beside future shared-mime-info) provides the .xml for .CR3 files?

https://stackoverflow.com/questions/71615956/jpeg-xl-does-lossless-mode-supports-32bits-float

Answered

Technically, 'jpeg' is not inaccurate since jxl is made by the jpeg

`.xl.jpg`

`.jpg.jxl` makes sense (for recompressed jpeg-1 files), `.xl.jpg` not so much

Next version of shared-mime-info will contain image/jxl registration. But they have som trouble to make release. Maybe someone could help: https://gitlab.freedesktop.org/xdg/shared-mime-info/-/issues/176#note_1313888

I consider DSSIM likely a good solution (based on TID2013 correlations). The license stops me from using the AGPL version and I wasn't able to convince my leaders to finance the commercial version.

VarDCT and Delta Palette are mutually exclusive, either the image is encoded with delta palette or vardct

Delta palette is still relatively experimental in JPEG XL and hasn't been optimized much

I understand, Thank you for your reply. 🙂

Yes, I hope libjxl can use heuristic to auto switch VarDCT and Modular(Delta Palette) on target butteraugli distance for different content(photo-like and really non-photographic). > https://github.com/libjxl/libjxl/issues/1188

Heh, lossless jxl looks slightly different in browser than PNG

Where should I report bugs related to gtk jxl pixbuf ?

If the bug is in the plugin that's in the libjxl repo, then there

Is the browser not doing color management? They look the same to me.

I don't know. It's Chrome

1 looks a little lighter than the other

Seems to be chrome then. In ImageGlass they look the same

Is there a data destination manager concept or API? Like libjpeg, the data destination manager can set next_output_byte, check free_in_buffer and execute callback when buffer has filled.

does anyone know a place where I can get some lossless anime test images?

Pixiv, zerochan

i mean manga

torrent ha ha (nyaa si)

realistic best bet is scans or rips often uploaded to the usual public tracker or e-hentai

some authors do very quality stuff on pixiv tbh

pixiv is the same as deviantart

there exists high quality but there's also a lot of garbage

i mean its like that everywhere

and i think right now deviantart's filtering is better

well for free

i just follow authors manually

in that case danbooru may be a good filter

What kind of filters are you guys talking about?

content filter

Lossless vs lossy image filter?

like garbage vs not garbage

<https://www.pixiv.net/en/users/1092517> quality artist

i'm looking for pngs, looks like pixiv has jpegs

It has pngs too. Depends on artists

i think one needs to log in for full images

i mean original ones

sites like danbooru/yande.re may be an option in case logging in is not desired

<https://www.pixiv.net/en/users/22733898> :>

actually some of this guy's stuff is jpeg, yeah

https://static.zerochan.net/Pixiv.full.3611712.png

Does it count as anime?

<https://danbooru.donmai.us/posts?page=1&tags=comic+rating%3Asafe> is a start it says the format under information when viewing an image

https://static.zerochan.net/Pixiv.full.3611717.png

https://static.zerochan.net/Pixiv.full.3611719.png

<https://danbooru.donmai.us/posts?tags=rating%3Asafe+highres&z=5>

https://static.zerochan.net/Minami.Otone.full.3611707.png

<https://www.pixiv.net/en/users/30837811> prob more of art stuff than represantive of "anime"

<https://www.pixiv.net/en/users/13594959> pngs

though very undetailed style

raw means lossless or un translated?

untranslated

I'm going to ask anime discord groups lossless manga <:CatSmile:805382488293244929>

just like everything else, there's no guarantee for "lossless"

kinda curious how good jxl is at something like

https://f4.bcbits.com/img/a0144817839_0

might aswell try

What is this <:monkaMega:809252622900789269>

cover art of https://mahoukichi.bandcamp.com/track/abnormality

In my opinion, I guess a lot of `manga` content(digital raw) is already transform to `jpeg` (444,420 8bit q92,q96,q99,q100), but still have chance find some `png` `manga`(digital raw) on some gallery site. You can find some `manga` content(scan raw) still keep on `png`, but those raw picture is from scanner, so probably have some gaussian noise on this type raw picture. PIXIV and other gallery site have a lot of `drawing`, `art` content(really non-photographic and photo like), some `drawing` is transform to `jpeg`, but still have high chance find `png` raw version picture (PIXIV need a account to access raw version picture).

I guess `manga` `jpeg` 444 q99 grayscale or RGB (digital raw) also a acceptable source?

Yes, let me send you Scope's testing material.

oh, I forgot that, Scope have a lot of good test material.🙂

https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/

yes please

DM sent 🙂

Wait, why did I send a DM? It's public test material <:kekw:808717074305122316>

https://drive.google.com/drive/folders/1X_F_vhNwJFhPWSW3EeSa-gGhhikkOoYd

At least it'll be much easier to track that way.

libjxl non-photo content(anime,drawing,manga) improvement start.<:Hypers:808826266060193874>

Gnome session becomes unusable and crashes if I set jpeg -> jxl files as wallpaper. Should I report that to gnome or jxl? Works fine with vardct and modular jxl though.

Gnome, because it works fine in my end on Openmandriva(KDE).

I don't think you can't compare it to KDE because they use different plugins

what was url for debian jxl builds?

there used to be url i could just throw in apt sources list

there still are

https://artifacts.lucaversari.it/info.txt

ah yes these. should be mentioned in libjxl's readme or something like that tbh

it's not *exactly* official

"unofficial but works okay" by core dev is kinda semi-official tbh

at least it's linked from jpegxl.info

without any mention of debian though

Now to obtain an illegal copy...

official release is prob worse than v2 draft stuff which was posted somewhere in here sometime earlier

👀

we're aiming to get the committee draft of the 2nd edition done at the upcoming JPEG meeting in April.

committee drafts can be made public

i'm not sure if drafts of committee drafts can be made public

here's the current draft of the 2nd edition

ty

heh, just the fact that this is a properly typeset LaTeX document already makes it much much better than the FDIS pdf I found elsewhere.

yeah, I just hope we can keep using tex. ISO _really_ wants us to use Microsoft Word, which is probably the worst possible tool for this job.

Bruh WTF.

Is that why so much stuff is in poorly formatted word documents?

Yes. They are insisting really hard on Word.

For the first edition, we did it their way, mostly to avoid more delays than the usual ISO slowness

But for the second edition I intend to resist more...

yes, and maybe it should also be added here: https://en.wikipedia.org/wiki/List_of_International_Organization_for_Standardization_standards,_18000-19999

we should also ping the mimetype ppl

you mean IANA?

yes we should get out of that provisional list and in the real list

can you figure out who to ping for that?

maybe there's action required on our end, like maybe we need to put something about the media type in the spec

`pandoc spec.tex -o spec.docx` :)

.... why?

they should know better

People outside of compsci, math, and a few of the sciences, don't use TeX at all.

this is an international standard relating literally to compsci and applied math tho

yeah but ISO aren't compsci or math people

they're bureaucrats

the whole organisation is probably built 100% on Microsoft Office and Exchange

I'm confused about this

specifically

> The decoder then reads the HybridUintConfig for each clustered distribution

how does one read HybridUintConfig for each clustered distribution, when this is a function that takes in one argument, which is `log_alphabet_size`?

is a clustered distribution just a number?

what is the format of a clustered distribution?

does the decoder read `use_prefix_code` as a `Bool()` for *each* distribution, and set the corresponding `log_alphabet_size` accordingly?

if so, this is not clear from the spec

or does it do it once, and then use the *same* `log_alphabet_size` for each one, and if so, how does that not return the same HybridUintConfig each time?

> use the same log_alphabet_size for each one yep > how does that not return the same HybridUintConfig each time it is read from the bitstream (there are some `u()` calls)

<@!794205442175402004> maybe could use some clarifications...

Yes, could be worded better

The thing is, ISO has the same procedures for all standards, whether it is a technical one or one about pointy-haired boss stuff like company management best practices.

And it's the pointy-haired boss people who make the rules

> The decoder then reads the clustering of the `num_dist` distributions (if `lz77.enabled`, then `num_dist + 1`) as specified in C.2.5, unless only one distribution is to be decoded, in which case C.2.5 is skipped.

This says "unless only one distribution is to be decoded"

does that include the LZ77 distribution, so in the case where `lz77.enabled && num_dist > 0` then C2.5 is always read?

or does it not include the LZ77 distribution, i.e. `num_dist > 1` is the only test

If lz77.enabled you always C.2.5

... could use some clarification too

(num_dist is never 0)

what's the maximum value for `num_dist`?

also, in C2.4 you have this

``` if (Bool()) { ns = u(1) + 1; if (ns == 1) foo; else bar; return 0; } ``` with no other reference to `ns` in that block

what I'm wondering is why you read a bool, add 1, and then use it for nothing but an if statement

why not `if (Bool())`

what am I missing here

another thing:

```c table_size = 1 << log_alphabet_size; /* initialize D as array with table_size entries with value 0 */ if (Bool()) { ns = u(1) + 1; if (ns == 1) { x = U8(); D[x] = 1 << 12; } else { v1 = U8(); v2 = U8(); /* v1 != v2 */ D[v1] = u(12); D[v2] = (1 << 1) - D[v1]; } return; } ```

`log_alphabet_size` is can be less than 8 here since it's equal to `5 + u(2)`

which means that it's possible that `x = U8()` yields a value out of bounds

it says that attempting to read from the distribution out of bounds yields 0, but it doesn't say what happens when you attempt to *assign* to it

if `x = U8()` is out of bounds, is this considered an illegal codestream?

or is there something missing?

cause reading `(1 << 1)` in parentheses is weird as well

like, whawt?

I assume that's supposed to say `(1 << 12)`

same with the next part, there's no guarantee that `alphabet_size` is going to be less than `table_size`

I'm also confused about this part

```c for (; i < ((1 << 12) Umod alphabet_size); i++) D[i] = floor((1 << 12) / alphabet_size); for (; i < alphabet_size; i++) D[i] = floor((1 << 12) / alphabet_size); ``` how is this not equivalent to something like ```c m = max((1 << 12) % alphabet_size, alphabet_size); for (i = 0; i < m; i++) D[i] = floor((1 << 12) / alphabet_size); ```

there's certain things here in the spec that are, well very verbose

in a way that doesn't make sense

like "why did you write it this way?"

that is almost certainly true

it can probably be written that way, it should be equivalent... I think the current code tries to match the corresponding C++ code: https://github.com/libjxl/libjxl/blob/main/lib/jxl/dec_ans.cc#L58

that's a very very good question and I think we should say what happens in that case... as well as check what libjxl does, I wouldn't be surprised to find something unexpected there

sigh, that's incorrect indeed, the first set of values should get floor(...) + 1

<@!794205442175402004> do you think you can fix that?

There's a +1 missing?

Sure

How did that happen, and why didn't anyone notice before? Lol

Anyway, great feedback, and nicely in time to fix stuff for the CD of 2nd edition.

I wish ISO would allow us to make the spec repo a public repo so these things could be discussed in issues and pull requests

preparing a spec PR to fix those bugs and try to clarify things

the out-of-bounds cases of simple distributions should be checked, maybe there's a bug there that fuzzing somehow didn't find

here's the updated draft with my proposed fixes/clarifications

<@!853026420792360980> feel free to check if it is now better and suggest further things that can be improved

<@!179701849576833024> https://github.com/jpegxl-spec/jxl-spec-draft/pull/20 PTAL

Will do

it looks like Lynne is going to be writing a native Jpeg XL decoder for FFmpeg

based on the public draft spec

it's going to take some effort, yea

also some infrastructure

since what's likely going to happen is XYB will be added as a colorspace to FFmpeg and then the decoder will simply output XYB

and libswscale will be required to convert it

the idea is not *instead of* my patch but in addition to it

that's (a) good news and (b) a very big project 😄 (although perhaps not so much if you don't need it to be super fast)

Dont worry too much: Lynne is an absolute monster.

She absolutely knows what she is doing.

I don't doubt that, but it's still a very significant endeavour 😄

Indeed <:kekw:808717074305122316>

This is the best way to find spec bugs, so this is great!

I appreciate a notation change from U32(whatever) to U32(1, 2 + u(3), etc), which reads much more naturally

Yes, I like that notational improvement too (and also that it's now a TeX macro so easy to change)

fingers crossed 🤞

Done 🙂

can I make some feedbacks (possibly wrong ones though) based on this proposed version?

that may end up being helpful so id say yes

my notes were: I think `offset + u(n)` notation outside of U32() arguments is undefined. Its meaning is obvious by its own of course, but for the completeness I think it should be noted in B.2.1. (Also B.2.2 has broken TeX commands.) I think the table D.2 is probably the very first thing people would have to understand in order to parse a JXL bitstream, and yet it has two exceptional cases that I believe should be noted: - The domain of field types may not contain the default value for that field. `h/w_div8` has a type of `1 + u(5)` which domain should be [1, 33) (this might not be that obvious however, hence the preceding remark) but a default value of 0. - The default values of h_div8 and height etc. are in my opinion hard to understand. It is a roundabout way to say height is `div8 ? 8 × (1 + u(5)) : U32(...)`, which is the real reason why h_div8 has a default value of 0 as it gets unused anyway. The table also has a typo `!div` which should be `!div8`.

let's delay the 2nd edition until there is a lesser frequency of these findings

The public CD of the 2nd edition will allow more eyes to spot bugs/unclear parts. Delaying the CD will not help that much imo. We will have time after CD to fix more of these, since there's still the DIS, FDIS and final IS stages.

That said, what can be fixed before CD should be fixed before CD, because starting with DIS we can no longer avoid ISO's paywall

(if there's something significant enough popping up after 2nd edition CD, we can always choose to postpone fixing it until a 3rd edition so it ends up in the CD of that)

You can't release multiple commitee drafts?

Nearly no applications support actual lossless jpeg, so I assume they just mean something like very high quality regular jpeg (q98 or maybe even q100).

Yes, DNG

The file size is about 10 times as much compared to the JPEG output

maybe it’s even still chroma-subsampled

Hm, for me DNG is usually 5 times as big as jpeg unless it's an easy to compress video

video?