JPEG XL

If you don't care about density, maybe — cheapest jxl should be cheaper than jpeg

Anyone here uses flatpak gimp? How to install jxl plugin on it?

I don't know if it is possible, I never tried external plug-ins with flatpak builds. But you can try flatpak from GIMP 2.99.x which should have my JXL plugin (it is different to the plug-in for GIMP 2.10): https://flathub.org/beta-repo/appstream/org.gimp.GIMP.flatpakref https://nightly.gnome.org/repo/appstream/org.gimp.GIMP.flatpakref

If someone wish to test GIMP 2.99.9 for Windows, to test JXL import/export and to provide feedback (it is better to get feedback sooner (before release) rather than later (after release)). The installer can be downloaded from Job artifacts (The artifacts will be removed in 6 days): https://gitlab.gnome.org/GNOME/gimp/-/jobs/1694716

https://youtu.be/aVwxzDHniEw that intro animation 😳

😍

It automatically promotes imported JXL images (created with fjxl) to 32 Bit floats despite this option being disabled.

I heard that libjxl uses float internally so 32bit float precision is how the images get decoded. Beside using more memory, I think there is no other problem. And with older versions of libjxl, import with integer precision gave visually different results sometimes. So import in 32bit float was chosen in the past because it worked the best at that time.

It's a bit annoying (and confusing) for lossless images though. There should also be no visual difference between version otherwise it wouldn't really be lossless.

OK, thanks for the feedback!

https://www.reddit.com/r/programming/comments/rrsnbt/study_developers_spend_almost_2_days_a_week_just/

why does jxl have banding? both png and jxl are 16-bits. jxl encoded at -q 93. Is it expected on vardct?

It doesn't currently perform dithering for output, so unless the app uses dithering for display then you'll see banding

New Windows build is available: https://gitlab.gnome.org/GNOME/gimp/-/jobs/1703454 If you want, can you check if it is now as you expected?

I have some already DCT image want apply denoise filter and apply lossy compress, but I have some question about this process, Could somebody can teach me about this? 1. Already DCT image have artifacts, so if apply higher quantizer(q99) on lower quantizer image(q90), higher quantizer will preserve artifacts and increase file size, (jpg q90 444 lossy => jxl d0.5 e8 or jpg q95 444 lossy). but even I apply denoise filter, already denoise and apply higher quantizer image, file size still large than original image, probably I use too weak(strength) denoise filter? or have other reason affect file size? In my test, only use near quantizer can reduce file size, (jpg q90 444 lossy => jxl d1.0 e8 or jpg q91 444 lossy), it's mean previous encoder quantizer will affect next encoder quantizer? 2. About jxl lossy transform, if I lossy recompress jpg, will lost some high frequency detail(generation loss), what else lose in lossy transform process?(jpg lossy vardct to jxl)

You can try better jpeg decoders to reduce dct noise

https://github.com/google/knusperli

https://github.com/victorvde/jpeg2png

Thank you 🙂 So best practices probably like jpeg2png + bilateral filter for non-photo jpeg lossy image?

Look like about my question 1, I must reduce those artifacts, otherwise I only can apply lower quantizer? > Generation loss is the loss of quality between subsequent copies or transcodes of data. > Anything that reduces the quality of the representation when copying, > and would cause further reduction in quality on making a copy of the copy, > can be considered a form of generation loss. File size increases are a common result of generation loss, > as the introduction of artifacts may actually increase the entropy of the data through each generation.

Yes. A casting system would likely benefit from dividing the screen vertically into bands of something like 64 or 256 pixels, and transmitting those immediately when a band is ready.

WHT and DCT -- https://datatracker.ietf.org/doc/html/rfc6386#section-14.3 and https://datatracker.ietf.org/doc/html/rfc6386#section-14.4 WHT is like a cheaper crappier DCT that doesn't use multiplications at all WHT can be ok for some types of content, but for photographs it is far inferior to DCT and modern systems tend not to implement it

I love catmull-rom splines since my late teens and I don't get the beauty of bezier curves -- I like to have the spline to go through the control points and I like it to have uniform curvature properties otherwise

It's working as expected for modular mode but it's bad for VarDCT. So you can't even get 32 Bit floats when first selecting it and then opening the image. Ideally, (lossless) modular JXLs open with their specified bit depth whereas VarDCT always opens as 32 Bit floats. If that's not possible, then I guess it would be better how it was previously.

32.jxl is an image which opens in 32bit float precision in GIMP 2.99.9 libjxl API do not tell whether vardct or modular was used to compress the image.

Yes, but if you change one Byte in the JXL header, you can make it 8 bpc and GIMP opens it as (lower quality) 8 Bit image despite the actual image data being exactly the same. OK, I didn't knew that about the API. Is it possible to detect RGB vs XYB? Otherwise, as I said, the previous implementation should be the lesser evil.

There is JXL_BOOL uses_original_profile; parameter, see https://github.com/libjxl/libjxl/blob/main/lib/include/jxl/codestream_header.h#L166 It is usually true for lossless and often (but not always) false for lossy.

But that should be fitting: - RGB: use specified bit depth - XYB: use higher bit depth for conversion to RGB (32 Bit float)

<@!794205442175402004> I'd like to know your opinion regarding JXL import in GIMP 2.99 Shall I always respect bits_per_sample and exponent_bits_per_sample or in case uses_original_profile == 0 to import as 32bit float?

I don't think you can always respect it, since GIMP probably doesn't support arbitrary bit depths and float types

In the XYB case the header info is not related to the pixel data anyway, so might as well use 32-bit float then

`uses_original_profile` is just the same thing as `!xyb_encoded` as far as I'm aware

but yes, if there's an XYB transform then the library downsamples the pixel data before reporting it

but you don't really *have* to do that

🤔 https://twitter.com/Pangaea__/status/1478249696925667328

I ran a bunch of old video game screenshots (Real representative I know) through WebP/JXL, WebP only "won" in a few cases, and not by much I think

But, across my 12 _Dungeons of Dreadmor_ samples, `cwebp -z 9` compressed 30% better than PNG and `cjxl -d 0 -e 9 -E 3 -I 1 -g 1` only 16% better.

Other than that, WebP seems to compete with JXL on images of text and other repetitive images, but not much else.

Jxl is not very good yet at exploiting repetition

The bitstream has lz77 and patches as ways to exploit repetition, but the encoder isn't making very effective use of those yet

<@!886264098298413078> I don't wanna annoy you but the JXL export option could be improved as well. The "lossless" check box is kind of useless as it is the same as moving the slider to 0 (compared to say WebP where this is not equal). Alternatively, the slider could be limited to a minimum of 0.1 since 0.01 to 0.1 also results in the same output. One might also invert the direction of the slider so that it goes from 15 to 0.1 with the highest visual quality being on the right, which should feel more natural. Though in any case, if the lossless option stays, triggering it should gray out the distance slider. Furthermore, I would prefer a slider with numbers for the effort setting instead of the name dropdown.

Setting 0 distance via API without lossless caused encoder to crash (there is a video on YouTube about it). Regarding the GUI: It can be changed in the future. New options will be added after next libjxl release. However about GUI design there are various opinions and preferences, it won't be possible to match everyone's expectations there.

OK! But why does GIMP allow to combine 0 with no lossless then?

Because that dialog is too simple. It is mostly auto-generated.

Why does my firefox (96.0b10 developer edition) not support JXL, even after enabling the about:config setting? Also why is it still behind a flag in both chromium and firefox?

Some political decisions Because some people think it will hurt AVIF's success

Firefox only supports JXL in Nightly.

I copied the pixel-based lz77-like approach from WebP as well as the exact 2d LUT for addressing in lz77 -- I didn't copy the color cache and bit-packing

bit-packing helps with very low color count images (2/4/16 colors)

color cache helps with pixelized images that have many colors but have locally only few -- but a lot of entropy for example due to error diffusion dithering or other reasons

overall the palette construct in JPEG XL has a lot of untapped potential and may be strong enough to shadow the benefits of the color cache

also it should be eventually possible to shadow the benefits of bit-packing by more active use of context modeling and redundant palette entries to assist context modeling

Color cache is kind of hard to combine with the planar approach and arbitrary nb_channels of jxl anyway

I think the main advantage of bit packing is the memory reduction / speed benefit, and maybe some benefits in entropy coding but I think that may be mostly the case for huffman coding, which does not have very precise chance modeling when there are too few symbols. With ANS you can model 70% white, 30% black, while with Huffman when there are only two symbols you cannot do better than 50-50 / one bit per symbol.

Thinking about it a bit, I think we _can_ actually do bit packing in modular mode

Say you have a 1-bit image of dimensions 8W x H. You can apply a horizontal Squeeze step to get two 4W x H channels, and some more Squeeze steps will give you eight WxH channels. Then you can apply Palette on those eight channels to get a single WxH channel. Not sure what exactly its range would be (probably not just 8-bit, due to the nonlinearity in Squeeze), but you would effectively be doing 8 pixels per encoded symbol.

Why is it still Nightly-only? Is there anything that still needs work? And <@!111445179587624960> so? If it is a better image format it *should* hurt AVIF's success because its better

No, everything important works, but patches are no longer accepted, although in fact there is no technical reason not to enable it by default, it's just a political decision For AVIF apparently some people think that only very low bitrates are important for the Web and also the heads and companies from the Alliance for Open Media don't want any other formats except their own

:(

Thanks for digging into it more. It's really annoying that this technology exists but isn't being adopted

hey all, my favourite kanban board, gitkraken is being sunset in 2023. What do you fine folks use??

bonus points for dark theme.

No support for WMF/EMF? What about all those cliparts?

Anyone here using gthumb? Does jxl work fine on that?

Says full support here: https://jpegxl.io/tutorials/gthumb/#gthumbsupportsjpegxl

I'm using it. It opens jxl files but they look pixelated.

Forgot to ask, do you have a screenshot? Does it only happen when you zoom in?

Might also try gwenview or geeqie (not sure the spelling is right)

https://gitlab.gnome.org/GNOME/gthumb/uploads/24000735fb2b142ee2cfd1144da5e3aa/post.webp

right one is gthumb.

https://gitlab.gnome.org/GNOME/gthumb/uploads/45fb543706c3f9b8e09deb1d963550b4/post.webp

hi! has anyone tested the **experimental/fast_lossless** codec? how does it compare to other codecs: on photo images? on other images?

https://discord.com/channels/794206087879852103/803645746661425173/930838234550923294

And (but without recent changes): https://twitter.com/jonsneyers/status/1472959101416226823

Also, it would be interesting to see an updated comparison with the latest changes in all encoders and FPNGE (P2/P4)

<@!794205442175402004> 😉

thank you!

<@!810102077895344159> do you know anyone at IPTC?

No, but have had a substantive reply from office@iptc.org (via https://iptc.org/about-iptc/contact-us/).

thanks - I asked because JPEG is exploring to establish a liaison with them

How much is progressive jpeg actually used in production?

I was talking with my professor, who had never actually used the jpeg spec version. They just loaded two different versions of the same image, one low quality, one high. And this (https://cloudinary.com/blog/image_loading_reloaded) cloudinary blog post recommends the same.

<@223161712092774402> why not use actual video codecs?

Cloudinary serves mostly progressive jpegs, it's the default. It's also the default of mozjpeg. If you see sequential jpeg and progressive jpeg as two separate formats, then progressive jpeg has been the fastest growing image format of the past couple of years, growing faster than webp and avif combined.

The 'progressive' display of first some placeholder, then the actual image serves a somewhat different purpose I think: there the lqip is often very, very low quality, not enough to actually see what's in the image, just enough to know "an image will come here" and to avoid layout shifts.

Oh I did exported it as an MP4 from AE and then uploaded the file to Imgur. But now that you mentioned it the animation seems too long for an animated image and too short for a short video haha

I think anything that is more than a few frames and can use interframe is long enough to justify using a video codec

For the master copy you do want something lossless though, and then probably video codecs are not that useful (though for CGI maybe it's more useful)

Yea I do have the original sequence as a huge PNG sequence

For that, probably fjxl would be a good alternative

Noted, will check it out

https://online2pdf.com/convert-jpg-to-excel

Perhaps someone heard "JPEG XL" and misunderstood 😅

ahah

it better be a spreadsheet of pixels with the background color set

https://youtu.be/UBX2QQHlQ_I

Not sure what packjpg does exactly, but at a high level the concept is similar: take the quantized dct coefficients and recompress them with better entropy coding

Archivers like packjpg and lepton don't need to make it so that you can decode the file directly to pixels, they can assume you first decompress to jpg and then use a regular jpg viewer

So they don't need to worry about progressive decode, parallel decode, etc

Does djxl provide knusperli like deblocking output for jpeg-recompressed jxls?

no

Not knusperli, but you _could_ add gaborish and/or epf deblocking filters to a recompressed jpeg if you wanted to (though I don't think we have an option for that atm)

Also if I'm not mistaken, the dc adaptive reconstruction also does apply to ex-jpegs, so there should be a little less banding in slow gradients (unless I am wrong, I don't remember how exactly we ended up defining things)

Nah, Knusperli is still unbeatable in that regard. Here's a MozJPEG...

...here it's the same file, but losslessly JXL-compressed and decoded to PNG via `djxl` (still the same blocky mess)...

...and here's glorious Knusperli decode of a MozJPEG file.

Yes, there is less banding, but as far as I remember it is due to higher precision in decoding

I think that Knusperli would allow <:JXL:805850130203934781> to cheap out a bit on LF coefficients (since they'd be smoothed out anyway).

Knusperli'd MozJPEG is actually... kinda *competitive* with JPEG XL, at least on that particular image and compression ratio where Knusperli can show off because of lots of background bokeh. Here's a brand new JXL encode, same bitrate, decoded to PNG.

Yes, if you go _that_ low quality in jpeg, you need some creative dequant to avoid getting a blocky mess

Which knusperli will be better at than jxl

Since jxl doesn't do anything to make the low freq hf smoother

<@179701849576833024> do we creatively dequant the dc in jxl when decoding a recompressed jpeg, or is it just the multiply and that's it?

There are limits, though. Here's a JPEG of a different image (🐸 from jpegxl.io).

Knusperli didn't help much because the quantization was too severe and the image is too big.

just the multiply unless you explicitly ask otherwise

and you can't explicitly ask otherwise for a 420 img anyway...

"explicitly asking otherwise" is setting a flag in the frameheader or what is it?

kSkipAdaptiveLFSmoothing

We currently don't ever tell it to not skip lf smoothing when recompressing jpegs, right?

But that dc debanding should work just as well for ycbcr as for xyb, right?

As long as it's 444, obviously. It needs corresponding samples from 3 channels

I wonder if we should expose some jpeg recompression encode settings, like setting that flag, and also signaling gaborish and/or epf

Gaborish and epf can be done even with 420, right? Upsampling gets done before the filters...

I think with adaptive dc smoothing, gaborish and epf, you can probably make an ugly jpeg look a bit less ugly

still looks rubbish though IMHO. I would rather delete this JPG to contaminate the ugliness or just reuse it scaled down to 1/3 or 1/4 of the original size.

yeah you can gaborish and EPF with 420

With such low detail already, jpeg2png can perhaps yield more appealing results. (30 iteration example)

Now it looks like an AVIF minus banding.

Better for low BPP jxl decoding.

damn those artifacts

Hello guys (just introduced myself in the chat section), i'm compressing 16 bit single channel images with jxl, and i wanted to assess the losslessness of JXL, but as far as i managed to adjust my data, i cannot find totaly lossless parameters

maximum error is 32 gray level, which is really low, but i thought that jxl was able to achieve real lossless => also i've seen the fast_lossless in the experimental section from <@!179701849576833024>, but going through the code showed that it is currently 12bit, can we expect true lossless 16bit with jxl (and if the fast_lossless is adjustable to my need i'd be happy to help give feedback, (also if working i'll add a contribution to opencv for loading jxl files)

Greylevel color coded input

and corresponding residual image

Input image as a range from 0 to 43000, and the residuals have 32 max absolute error, which is very good, but true lossless is a topic in this context

That's weird, jxl ought to be able to do 16 bit lossless without any problems

How are you encoding the image?

custom c++ code (tif file loaded through opencv)

JxlPixelFormat pixel_format = { 1, JXL_TYPE_UINT16, JXL_NATIVE_ENDIAN, 0 }; JxlBasicInfo basic_info; JxlEncoderInitBasicInfo(&basic_info);

basic_info.xsize = im.cols; basic_info.ysize = im.rows; basic_info.bits_per_sample = 16;

basic_info.num_color_channels = 1;

if (JXL_ENC_SUCCESS != JxlEncoderSetFrameLossless(frame_settings, true)) std::cerr << "Warning Lossless mode not set!" << std::endl;

then adding the frame

decompressing & computing the image differences

can you try using `cjxl` and seeing if you have the same problem?

<@!931493879801348106> how are you extracting the tif data?

that and it would appear the processed image, has some heavy noise.

also it would appear its not truly one channel.

The tif comes from libtif (opencv (cv::imread(, ANY_DEPTH)) but nevermind this i need lossless

the data is clearly single channel

the provided image is just a screenshot, not the real content

with pseudo coloring

the issue would be that cjxl is not handling tif

otherwise i would have directly tries

d

you could convert the tif to PNG just to try

giving a try, but cjxl has no output for max error & or residual visualisation

Well, do `cjxl -d 0.0`, and then you can check for errors by decoding it back to PNG with djxl and then compare with with `butteraugli_main source.png encode.png`.

ok, apply the transformations (losslessly)

and error is 0

what is the difference of -d 0.0 and the c++ jxl JxlEncoderSetFrameLossless

in theory none...

could you file a bug?

Are you setting use_original_colorspace to true?

Otherwise it does xyb...

This is really confusing api design btw

doesn't setlossless do that?

setlossless is just setting lossless parameter (from my code reading)

<@!794205442175402004> : did not change touch this one, as i thought that single chanel would not (should not?) go through this

what are the paremeters related to [Modular, lossless, squirrel] ?

i thought that setting : JxlEncoderSetFrameLossless && JxlEncoderFrameSettingsSetOption(frame_settings, JXL_ENC_FRAME_SETTING_MODULAR, 1); would be identifcal

sorry guy's just joined in with my question but i'll be off for 1week, i'll come back with new tests & comments, do not hesitate to send me PM i you know the difference in settings from the jxlE,coderSetFrameLossless & cjxl parameters

<@!794205442175402004> : how do you set this parameter properly with jxl lib options

if you could file a github issue it would be best

Set uses_original_profile = JXL_TRUE when setting the basicinfo

The thing is that xyb or not is a per-image decision

And lossless is a per-frame decision

But the default is to do xyb, which is not compatible with lossless

<@!794205442175402004> :trying this one, sorry i'll be off for a few days, i'll get back in touch after my days

ok with uses_original_profile = JXL_TRUE we are totally lossless

compression ratio is way higher (first try is worse that 7z compression of the tif file)

(effort was 6)

If you get worse results with the api than with cjxl, please file a report

I hope animated webp will work. It could be useful for short videos inside presentations. It will be visually better than videos converted to 256-colors GIF.

Are videos not supported?

I've had issues getting videos to work, especially when you create a presentation with libreoffice, and present it with PowerPoint.

You could create a fully compliant odt with a jxl image in it, even if nothing could read it.

when will the jxl standard be frozen?

isn't it already frozen?

the bitstream is, idk if the full standard is

If I start compressing the archives now, will they be 100% decode in the same way in 5 years? Of course, I mean the current state of encodecs and decodecs

yes

100% will only be true for lossless encodes. Lossy does allow for conformance tolerances in order to allow efficient implementations on various platforms. The tolerances are quite small though — let's say things have to decode 99.99% in the same way. This is also true for other codecs btw: the old JPEG has quite generous tolerances so different decoders can produce pretty different pixels while all being conformant.

I mean more global changes, like the fact that the current encoded photos in the future can be read as broken

that's not going to happen

spec was frozen in that respect in December 2020

anything encoded with a cjxl from after December 2020 is guaranteed to remain decodeable

oh well, then I can safely convert all my archives, without stopping at the current Decodec version, and updating it without worrying about the future

Thank you

it’s a pity that I don’t have a few years to wait for the transcode of all 2000+ 4k photos

doing a quick mini-benchmark on a large jpeg: ``` $ time for i in $(seq 1 10); do djpeg big_building.ppm.jpg >/dev/null; done real 0m1.641s user 0m1.583s $ time ../build/tools/djxl big_building.ppm.jpg.jxl --num_reps 10 --num_threads 0 7216 x 5412, geomean: 70.20 MP/s [57.81, 78.68], 10 reps, 0 threads. real 0m5.708s user 0m4.936s $ time ../build/tools/djxl big_building.ppm.jpg.jxl --num_reps 10 7216 x 5412, geomean: 165.09 MP/s [132.90, 177.63], 10 reps, 4 threads. real 0m2.450s user 0m7.563s ```

it is much more profitable for me to reduce the size by 4 times and use compression to the maximum

so let's say libjpeg-turbo is about 3-4 times faster to decode, or with 4 threads 1.5x as fast as libjxl decode of the same jpg recompressed to jxl — some of that difference is because libjxl needs to do fancier entropy decode, some of it is because libjxl is doing more accurate decode

Is there any option for libjxl to make it more accurate but decode slower?

Comparing original image to decoded jpeg, you can see that the libjxl decode is slightly more accurate: ``` $ compare -verbose -metric mae big_building.ppm big_building.ppm.jpg.ppm null: big_building.ppm PPM 7216x5412 7216x5412+0+0 16-bit sRGB 223.463MiB 0.140u 0:00.147 big_building.ppm.jpg.ppm PPM 7216x5412 7216x5412+0+0 8-bit sRGB 111.732MiB 0.180u 0:00.181 Image: big_building.ppm Channel distortion: MAE red: 799.99 (0.0122071) green: 526.031 (0.00802672) blue: 1025.9 (0.0156542) all: 783.974 (0.0119627) $ compare -verbose -metric mae big_building.ppm big_building.ppm.jpg.jxl.ppm null: big_building.ppm PPM 7216x5412 7216x5412+0+0 16-bit sRGB 223.463MiB 0.160u 0:00.163 big_building.ppm.jpg.jxl.ppm PPM 7216x5412 7216x5412+0+0 16-bit sRGB 223.463MiB 0.150u 0:00.155 Image: big_building.ppm Channel distortion: MAE red: 786.918 (0.0120076) green: 503.873 (0.0076886) blue: 1000.86 (0.0152722) all: 763.885 (0.0116561) ```

for me using one thread at speed 9 - waiting 5 minutes for 1 megapixel

less accurate and faster: yes, there are compile options for that (`-DJXL_HIGH_PRECISION=0`)

speed 9 is probably not really worth it — are you encoding from pixels or recompressing existing jpg?

I'm downsizing photos from 8k to 2k or less

more accurate and slower: not really — we do have experimental code that does things in `double` precision arithmetic, but that's not really meant to be used in practice because it's very slow for very little improvement in precision. But it's what we use to produce reference decoded images for conformance testing, for example.

so from pixels then. Doing lossy compression on them?

yes

to a size of same 30% of lossless compression

I care about the information in pixels, not their amount

but am really mining jxl haha

probably default speed (-e 7) is a better trade-off between speed and density

i need maximum compression for centuries

Try Emma encoder XD

Emma does lossless, no?

Emma??

"very slow experimental compressors LEA and EMMA"

wow

<:Cheems:890866831047417898> but lossless only

https://twitter.com/jonsneyers/status/1346389917816008704

it would be interesting to use this on a color palette like 16 bit for all color

is it possible?

in PNG and GIF you can create a palette of 256 colors from the most common colors in the picture

Jxl can do palettes of unlimited size

It can also do delta palette

Can I set the palette for normal image compression?

I don't understand why I need so many gradient details of the same shades

6+6+6 bit

You can try lossless 6-bit if you want, that would be cjxl -m --override_bitdepth 6

Iirc

but, by what principle is the palette created in this case?

just a color limit? or image color analysis

Just reducing the input values to 6-bit, nothing fancy

Definitely make sure to decode lossy 8 bit JXLs to higher bit depths and manually apply dithering if you display them at 8 Bit. The uint8 output produces bad rounding errors that will cause ugly banding on gradients.

See this issue: https://github.com/libjxl/libjxl/issues/541

so dithering adds entropy

there is no point in using 8 bits if dithering is also used

Oh. This is why I had banding on jxl even though source doesn't have banding 🤔

well, I have photos, they have noise

And I don't care about dynamic range

but

this was 2 years ago, I'm sure it works better now

my original photo

Yes, lossy JXL will mostly remove dithering during compression because it's of too small importance for butteraugli. But gradients aren't an issue for libjxl internally where 32 Bit floating point precision is used. The only issue arises when simply truncating back to 8 Bit instead of doing better rounding with dither.

looks interesting, but not very effective, it is better to use normal compression methods. cjxl -m --override_bitdepth 6 -q 100 -e 9 -P 15 image 407 Kb optipng with bitdepth 6 image 764 Kb WEBP with bitdepth 6 image 512 Kb

wow, it started working but then gave an error, huh?....

if not use -P 15 then everything works fine

maybe a bug? -P 15 is work in lossless only? cjxl -m -q 90 -e 9 -P 15

enc_encoding.cc:361: JXL_ASSERT: residual % res.multiplier == 0

And I didn't understand How yuv444

And the --palette parametr is just not work

--palette doesn't do anything lossy, it just sets the limit of how large the palette can be _if_ the image happens to have fewer than that number of colors

it doesn't work at all

Yuv444: you can do it by giving it yuv data in an (invalid) ppm, then adding -c 2

What doesn't work? Default is --palette 512 iirc

but it is signed there that this is only for modular encoding

the setting just doesn't apply

It does: that setting just means "do palette IF the image has fewer than 256 colors"

need the separate parameter for decrease colors and create palette

wow <#805007255061790730>

that's not currently in the scope of libjxl — you can use pngquant or something

ok, but now I need to solve the problem, I have small pictures and colors should not decrease by 2 times like yuv420

did you try delta palette?

??

`cjxl -m --lossy-palette --palette 0 -P 0`

what exactly are you trying to do? you want to do something lossy but not just default lossy like `cjxl -d 1` ?

i use -d 0.5

but there are noticeable 2x2 blocks for color

I don't know what it looks like... but it size More than just lossless

let's stop experimenting with palettes, I already realized that they are not very effective for what I compress

that's strange, since jxl doesn't do chroma subsampling

<:Thonk:805904896879493180>

then how do I get rid of this? Is it just need the more quality?

<@!794205442175402004>this is a really noticeable problem that is completely absent on the JPEG XR at the identical size

if you're going to zoom in that much, -d 0.5 is not enough

what should I use in such cases?

does -d 0.1 look OK?

I can't UP the Size because then there is no point in using Jpeg XL instead of Jpeg XR which just works

it is possible for varDCT to have poorly tuned scales

there could be an encoder bug, maybe

can you share the original image?

oh

I find in a more presentable image

found

ok it's just a gardint of cooked chicken the original

top is JPEG XR

fo me it looks like ebalancement of pesets

for %i in (C:\Users\Utente\Videos\pi\a\*.png) do cjxl -s 6 -d 0.669 -I 0.761 --use_new_heuristics %i %i.jxl

s 6 needs to be usedv bette

this command don't wok withcueent cjxl

-I is fobidden with new heusitics

300 kb

you ae the peson who does compaisons i n encode.su

analyze this

for %i in (C:\Users\Utente\Documents\eew\*.png) do cjxl -s 6 -d 0.669 -I 0.761 --use_new_heuristics %i %i.jxl

i doesn't wok so is default 0.5 maybe

it is strange that jpeg xr does not have such a problem even when it Size 3 times less

what

is this the jxl i posted?

xl yes

a bit bette

but moe aggessive filteing

it looks really bad

because it isn't exact i

but what eve neew heuistics is using

so 0.5

iteations

what is parameter i? does not work

0.1-0.9 does not even affect the size in bytes

is -d 0.3

yes is disabled in this build

so is only -s 6 -d 0.669

why 669

i'll ty the jamaika build if it changes

-s 6 -d 0.4 --use_new_heuristics

big no

doom nine build is same

iter ations don't change

i have 0.7.0-d4e2f39

these blocks ruin my precious pixels

how use cjxlng

I've always used Jpeg XR -q95 and it's perfect of course

i have msytwo

I have no idea why

maybe it isn't the exact vesion

how vesai luca build jxlng

do he uses clang

yep No modules matched<:YEP:808828808127971399>

stat fom the beginning

wtf open the CMD

and going in folder

So jxr performs better? Time to test on synthetic / anime images.

i want to show cjxlng

the folde is this

i expect it to eecognize

jpeg xr not animated but work very Fast

meh

By anime, I mean anime art images. not anime video.

use the AVIF

Hmm. but it doesn't look on complex anime art. wipes many textures.

there is nothing better for "art"

only avif

stop

i'm not english

to me those aent' latin wods

it also means i still can't use jpeg xl

modular mode doesn't have these problems with blocks, but it's not usable

goodbye

quality does not match the size

Is the source image lossless? developed from raw/dng?

the source

oh

bruh

webp ? !!!!!!!!!!!!!!!!

discord moment

I don't think discord converts images to webp

I think your source image is webp

He has been doing this since recently.

I notice this when I repost pictures in telegram

sha256sum 26565e6c5571ee4bc893222153fc4cdfcf333ad4c745cd7cb72df00cf4ed3513 20210828_130710.png

<:HaDog:805390049033191445>

I don't see any critical differences <https://slow.pics/c/qqHaYZub>

this size is too big

I planned to lower it by 40% relative to Jpeg XR

jpeg xr is 348 Kb

I don't think it's possible, for a like almost lossless quality, especially if the source is not very good quality, for regular Jpeg - maybe

jxl doesn't work well on low quality sources. Did you downscale it for removing jpeg artifacts?

what the did you say

jpeg XL works as it should, but this problem with color blocks ruined everything

even jpeg xr 5 times lower size has no such problems

recomend use Jpeg in 2022 bruh

I mean I don't think Jpeg XL is 40% more efficient than Jpeg XR (with the same quality), it may be 40-60% better than regular Jpeg, but Jpeg XR is a more modern and efficient format

it is certainly not that effective, but it would be the most effective investment for the future

could be

Now it seems I understand that from the point of view of the encoder, JPEG XR is more suitable for my specific images

because all these block problems would be completely invisible on images like 4k or 8k

and at the same time jpeg xr is extremely fast

Without having access to uncompressed / non artifact-y images, it is difficult to compare codecs.

Does your camera outputs bmp image?

Yes, the higher quality source, the better and more efficient is Jpeg XL compared to other formats, although I also noticed some artifacts and problems with JXL, sadly it seems that Jyrki is pretty busy with something else, he mainly works on improving lossy VarDCT

this is the source with which you need to work, everything that happened before is unimportant

No

Artifacts from previous codecs ruin encoding process.

my situation with archiving is specific. for everything else, of course, the codec works for all 100

<@!263309374775230465> its

https://cdn.discordapp.com/attachments/794206087879852106/940600784909893692/unknown.png

I think you didn;t understand. Probably jpegxr alogrithm is more similar to jpg than jxl. Similar encoding process, so fewer artifacts.

DCT is DCT

Also, some smaller size

some problem

butteraugli works in different way

jpeg xr same size

no blocks

what's the original?

or where in the original is this?

you zoom in so much that it's a bit hard to tell

orig

ah yes

I noticed that this is a problem on dark gradients that are close to flesh-colored

ah found it

`convert 20210828_130710.bmp.ppm -gravity center -crop 100x50+-120+-80 -sample 1600% 20210828_130710.bmp.ppm-crop.ppm`

looking forward to learning about this made and information about it

nearly

I think it's just smaller blocks because Jpeg only has 8x8, but JXL can make blocks even smaller and also much larger And the encoding is usually not tuned for such zooming, but for normal viewing distance when the difference is almost not noticeable

<:FeelsAmazingMan:808826295768449054> I just need to completely disable the use of large blocks

how

the thing is, if you zoom in that much, anything lossy will be visually lossy — just some codecs will look more blurry, others more blocky

at such extreme zoom levels, I can easily see big differences between the original and a q98 jpeg

if your use case requires that much zooming, I would recommend either using higher resolution originals, or use lossless

i need 3-4 times compression from lossless png

For archiving purpose, you should be using transcode mode and don't worry about file sizes.

jpeg xr does completely imperceptible compression at 2.5 times compression

there is noticible quality loss in xr from the zoom amount you show

actual jxr

there would be for pretty much any lossy encoding too

losses should not be noticeable

if you are encoding lossy then there is loss

if you are going to look so close at it you will see that loss

if you don't want any of that, don't use lossy

Look this XOR

is 350 xr and 200 xl

and:

ok

`83M d.bmp 7.5M dim-gunger-3emffQOvHxA-unsplash.jpg 17M d.jxr` Why am I getting big jxr files.

?

trying to recompress jpg to jxr.

I used quality 90

xr and xl same size

wait, doesn't that mean that jpeg xr is better on BPP 3+

I get very bad quality on jxr

??

Probably I am using worst implementation of jxr

<@!226977230121598977> which software are you using to convert to jxr?

XnConvert

Jpeg XR wih all block overlap mode

i will make tests with different sizes

Even with overlapping I get bad results

microsoft's encoder. It should be good I guess.

wow what a simple codec hehe

Okay. used xnconvert this time. with quality 80 and overlapping all. I get big files lol

my q is 0-100

why are you doing this with jpg

Well, you said dct is dct

<:ReeCat:806087208678588437>

Having tested with lossless source, i get smaller file sizes than png but noise and textures get lost on jxr.

left jxl - 246 kb . right - jxr - 685kb

lot of mosquito noise on jxr even at 680kb 😦

yuv444?

yes

i use q 95

even at 80, the file size is 680

what will happen at q 95

some strange transition of algorithms from 94 to 95

at 95, it gets bigger than png. 3.8mb jxr. source png 2.4mb

JXR also has a lossless mode and is usually better than PNG (for photos)

photo?

real photo

I used q100 ( lossless mode) now. it's 100kb less than png

yes

Parody

<:Cheems:890866831047417898> <:Thonk:805904896879493180>

well, an interesting note is that XR share data much more evenly

It's expected.

https://discuss.pixls.us/t/jpeg-xl-file-format/25925

What colorspace are you doing the comparison in?

I didn't really go saince it, but it seems that jpeg XR makes the image so that the maximum quality is first made and then elements are removed from it, as in the original JPEG, while Jpeg XR generates an image from low to high

here everything is XOR, and an indicator of what was removed from the original image, then what is not in the compressed version

on the right side of the image, the lighter the more the pixels differ

Xor of RGB values? That's probably not really the best way to make a heatmap...

yes

but this very clearly shows that in JPEG XL the image does not match the original at all, and many shifts were made, while JPEG XR removed mostly noise, all pixels