JPEG XL

I think it would be good practice to track this on GitHub. Should I make a new issue? Or should I edit the existing one I made? https://github.com/libjxl/libjxl/issues/3530

why compare at the same distance instead of the same BPP?

e3 has bad edge-cases in non-photographic: [text](https://loathra.com/jxl/bench/20240506.html#multi-12), [pixel_art_scaled](https://loathra.com/jxl/bench/20240506.html#multi-25)

so e4 is safer, but also has bad cases in some circumstances: [algorithmic](https://loathra.com/jxl/bench/20240506.html#multi-28)

0.6.1 definitely looks much better, but it still doesn't look that great.

I would test earlier versions if I could

Maybe I should

That abandoned factory image is just a real problem case with the leaves getting washed out colors

let's make a new one as this is clearly for photographic images?

for me -- the factory vs. sky has decreasing artefacts as versions progress, but saturation of colorful (yellow) details is reduced as we have progressed in version numbers

looking at all of these I think we improved in pretty much all version...

I tend to agree 🙂 <@532010383041363969> could you publish a short list of commits (half a dozen) containing very meaningful for lossy quality improvement steps ? I'll be glad to make some chronological comparison (if I can sucessfully compile them)

recent 2024 commits or commits from the far past (0.6 era to now) ?

I'm not sure 😄 I found the work I did on commit 4d2bc14 interesting and was trying to extend this... While thinking again, I wonder if I couldn't start with "released" version. I'll build something with what was published as pre-compiled on the git. And I'll comeback for more specific requests on commits I think

Unfortunately I see no significant difference... Perhaps a more complex image would be better, like Mercado

Idk if this is the best resize... I made this, but there's ringing artifacts. https://cdn.discordapp.com/attachments/794206087879852106/1235398636498714634/mercado.png

I used `vipsthumbnail --linear`

I did a few experiments and I could not get simple image quality gains. The images where AVIF looks sharper have AVIF to disregard middle frequency band. It can be nice for video to fill in missing fine frequencies later, but possibly weird for photos.

We could add more control for slightly favoring saturation, sharpness, less aftefacts (and more blurring) etc.

I think there is a minute increase in sharpness in the head when compared to releases (theoretically thinking about it, didn't look at evidence)

What do the content type presets in webp actually do? Could jxl encoder have similar presets as well?

Looks like different levels of smoothing, basically.

should be doable with a prefilter then, no?

I toyed with calling specific cjxl commands based on content

but I do not really know how to make such a thing very practical

but that is lossless

I suppose the webp presets take effect only in lossy compression.

I don't think a lossy encoder should ever create blurry smudges if it can create higher-frequency artifacts instead

In lossy audio compression they call it noise-shaping

It works well, in psychoacoustics as well as psychovisuals

I don't like the philosophy of more encoding control. Some image will be a hybrid — someone will put a logo and text on a photograph, etc. each area should understand it's characteristics separately. If it is done it should be done in my opinion in a way that is easy to understand.

That's fair. I haven't used those webp presets either because I was not sure if they improve anything.

That's why I like the idea of some kind of edge detection algorithm that separates an image into a DCT "texture" layer and a modular "splines/gradients/solids" layer

Ideally an encoder should be smart enough to detect image content that will be inefficient to compress with dct mode

A lot of images are smaller file size with lossless compression and currently the user has to guess or double check and compare the two

Would this cause issues with encode and decode speeds, or with possible hw codecs?

Multiple layers would decrease decode speed (increase the time it takes to decode) and hw encoders would probably not ever do that, or anything much more sophisticated than standard JPEG.

Hello, I would like to know if the decoding speed of animated JPEG XL has improved compared to AVIF, or if it is better to favor WebP for now.

there is performance issues ?

when I encode somehing with cjxl, what criteria would make it skip the container ? no meta data in the original file ?

animated avif is an av1 video, same as webp with vp8, not real animations. videos will always run 'better' than any animation based on those videos

animated webp is not a vp8 video, it's a sequence of still frames, that can be vp8 or vp8l (aka webp lossless)

Yeah, you can use `--strip=all` in cjxl if I recall along with `--container=0` or something similar

isn't it `-x strip=all` ?

Yeah, that's it. Only used it months ago so forgor

no worries, it isn't even in the output of `cjxl -v -v -v -v -v -v -v -v -v -v -v -h` <:KekDog:805390049033191445>

well it actually is (with `exif`), but doesn't say we can use `all`

Thanks! My question was not very clear. I meant : if you don't force the presence or the absence of container (with - - container) how cjxl choose to make a raw codestream or a containerised one

probably needs like 12 more `-v`s

Not really. Compression techniques are maintained, but the images remain independent. I have no issues decoding AV1, VP9, or VP8, but I encounter significant image loss with AVIF. WebP performs better but is still not as good as video.

I wanted to know if JPEG XL decoding was more efficient than its counterparts.

Decoding of jxl is roughly similar in speed to decoding avif or webp, though generally avif/webp are faster at lower quality than at higher quality, while jxl is more constant in decode speed regardless of quality. For animations, inter frames are typically less work than intra frames, and avif is the only one that really has inter frames (since you can just use arbitrary av1 payloads).

So for animation (at least of natural content and at "web quality"), I think avif is a better choice than jxl.

Not just for decode speed but mostly because of the compression an actual video codec can bring.

No intra only codec can compete with video codecs (at least when doing web quality lossy)

Thank you for this detailed feedback. However, as my use is not web-oriented, I prioritize lossless quality. Although the animated images I manipulate aren't of very high resolution, I aim for them to be displayed as smoothly as possible. I have determined that maintaining 40 frames per second provides the ideal balance for stable decoding with the WebP format. Unfortunately, while AVIF offers inter-frames and superior compression of 35%, it struggles to display even 10 frames per second due to slow decoding, rendering it unusable in my situation. Given that JPEG XL also offers significant compression, I was concerned about encountering similar decoding issues.

How about high quality h.264? Should decode quite quickly.

I need an infinite loop and the support of transparency.

ah

maybe the faster lossless speeds are fast enough? how big are the frames?

Input frames or output file frames?

can JXL store subpixel data? (so many screenshots burn our eyes due to subpixel mismatch)

does it make a difference for lossless?

I've read that lossless is decoded faster.

avif is just av1 track inside of a mp4 container, if you are having issues decoding avif and not av1, it's either an issue with the file itself or the implementation of the decoding

converting a video to avif is pretty much as simple as `mv file.mp4 file.avif; mp4box -ab avis file.avif` this isn't totally spec compliant, but most decoders will probably wind up working with this

I'm finally getting around to doing this https://discord.com/channels/794206087879852103/803574970180829194/1204264884016123954

before:

after:

I've tried lossy encoding and it works better—at least on Firefox, not Chromium. So it's the lossless version that seems to have difficulties being decoded (the opposite of WebP).

AV1 just isn't optimized for lossless. The same goes for VP8 or VP9, but at least it doesn't compromise playback. I wonder if HEIF supports animated images?

well, without getting to indepth since this is the wrong channel for av1/avif, there isn't anything wrong with the AV1 spec itself for lossless it's just no one cares about it enough to invest substantial effort into making it good, to begin with, of the three major sw encoders, only aomenc can even do lossless.

also it offers no "fast decode" settings like svtav1 does which hurts a lot

Do you mean ClearType font antialiasing in Windows and scrolling in Ice Book Reader?

They generally don't "burn eyes" on mismatch, they just result in colorful edges. Maybe you mean color profile?

You mean the physical subpixel layout? I don't know of any existing ways to represent that information (as, say, some Exif metadata or something), and I also wouldn't know what a viewer could do with that information — I suppose it could do _something_ when rendering the image more zoomed in than 1:1, but I'm not aware of any image viewing software that actually tries to take subpixel layout into account.

I think it only supports intra-only in its multi-image variants, but there might be some flavor of HEIF that allows arbitrary HEVC payloads. If it works, I would expect it to not actually work with alpha, even 4:4:4 might be an issue.

I disagree. Sure, there is probably room for enc/dec improvements for lossless avif, especially regarding speed. But I do think that there are inherent limitations at the spec level that prevents lossless avif from being very good. In particular: 1. AV1 follows the video codec philosophy that color spaces / color transforms are not in the scope of the core codec, but they are just metadata to be handled at the application layer and the codec itself only gets numbers to be encoded with or without loss (where loss is measured just as numerical error, e.g. using PSNR). So they do not implement any color transforms as part of the codec itself. For lossless, this means they are forced to use RGB without any channel decorrelation, which is not effective. They want to add YCoCg as an option, but it has to be done at the metadata level (i.e. as a new H.273 CICP code point), for which they have to rely on external standardization, and application support is not guaranteed, so it is not easy to do and leads to interop issues. Long story short: they're stuck with RGB in practice, and that means a lot of correlated entropy has to be encoded multiple times. For images with alpha it's even worse: the RGB and A data is inherently encoded independently in AVIF, which means it is impossible to do things like RGBA palettes where a full pixel is encoded only once. 2. While AV1 has some non-DCT coding tools like palette blocks, they are designed for lossy encoding (e.g. palettes are limited to 8 colors per channel). Tools like directional prediction are useful if you can mostly quantize away the residuals, but they don't help much if all the residuals have to be preserved. 3. The entropy coding in AV1 is relatively simple and designed to be hardware-friendly. For lossy, this is fine, since most of the entropy is quantized away anyway. For lossless and high-quality lossy, entropy coding plays a bigger role though in getting good compression density.

You can try what happens when encoding an APNG with `cjxl -d 0 -e 2` or something like that. Note that libjxl encodes all frames as they are provided to it, it does not automatically crop the frames to cover only the region that changes, which can make a big difference. JPEG XL is not particularly designed for animation, but it should be able to beat other animated still image formats (apng, webp). We have not spent much effort on making a good encoder or decoder for the case of animation though. For example, if the dimensions are small, probably it would be beneficial to process frames in parallel, but libjxl does not do that at the moment.

ah my bad, I meant in comparison to h264/h265/vp9

AV1 is designed for use on the web at very low bitrates. For various reasons, it is therefore very difficult to achieve complete fidelity with this codec, even at high bitrates. I don't think this necessarily stems from a lack of effort on the part of the developers. There is no benefit in mastering it since the H.264, H.265, and H.266 codecs already excel in this area. This is why I was interested in HEIF because I know it will be much more suitable for my needs, but support for its animated version seems to be nonexistent.

Honestly, I have no idea. It needs to be tested.

That's why I'm here in the first place, because it's not working. I get this: ```Getting pixel data failed.``` However, thank you for all this information.

this is a fairly common misconception that I don't really understand why it is spread. the current implementations do not represent the totality of av1. but even disregarding that aomenc when you spend days tweaking it (if you don't mind the slow speed) can compete quite with with libx265 at high qualities (I even used it for "master exports" for a while when I was still working on video). rav1e is actually fairly decent at high fidelity encoding too. the issue is entirely that there is very little optimization here, which is really understandable because who wants to fund it? as you said h264 and h265 implementations are very capable at higher quality so there is next to no incentive to hire/sponsor a developer to work on high fidelity encoding, *very few* people actually want that.

I wouldn't say very few people want high fidelity video encoding, but typically different technologies are used anyway in production workflows and professional use cases (things like ProRes, DCP, FFV1, JPEG XS), with the "real video codecs" being used only for the final delivery to consumer devices. While h264/h265/h266 are perhaps still somewhat useful for other things than the end delivery (they do have profiles that are aiming at production workflows, like HEVC's "Main 4:4:4 16 Intra" or "High Throughput 4:4:4 14"), AV1 seems to be designed specifically for web streaming / broadcast, with its highest profile only going up to 12-bit (compared to 14-bit for h264 and 16-bit for hevc and vvc).

Right, I guess our animated PNG input in cjxl is broken in the current released version. Does it help to use the current git version of libjxl? I think this issue was solved in the mean time, see https://github.com/libjxl/libjxl/issues/3430

yeah, generally I would say that 12bit is probably enough for a lot of production workflows, (av1 even calls it the "professional" profile for 12b444 and 12b422) but generally, av1 doesn't fit in well because what benefits it does have aren't actually really that beneficial, it does ofc have bandwidth savings over h264/h265, but they wouldn't be so great that it would be a massive improvement, since this target audience generally isn't massively bandwidth limited anyways. generally what market there is for it, would be using asics anyways, things like VDI/streaming, sets that deal with many cameras etc. where all these usecases are adequately, and ideally served with hardware encdoing

There are very large investors behind AV1, so I doubt it's a funding issue. I think it's just not the developers' intention to focus on this usage, and I doubt its current structure lends itself to that. As for achieving fidelity with AV1 similar to HEVC... yes, with encoders like `aom-av1-psy`, transparency can be achieved without lossless mode, but the generated files are just as large, if not larger, than those for HEVC. The codec wasn't originally designed for this, so it deserves its reputation.

Hmm, I'll try it.

but *who* is investing in what project is important, svtav1 development has slowed down considerably, "very high quality" isn't even a goal for for svtav1. It doesn't even support 4:2:2 or greater which immediately kills it's prospects there. Rav1e is well, it's pretty much dead, we can pretend it's not, but it's more or less in maintenance mode. so really we *only* have AOM for high fidelity encoding. when using aom, or back then aom-psy it needs *loads* of tuning but you can produce high quality files that are in the same weight class as libx265 when encoding. it is loads slower, and it's reliability is mediocre at best (rav1e my beloved). but often times you can get results that beat out libx265, I encountered this most reliably when encoding netflix's sample media, as well as ofc my own footage that I sadly no longer have as I no longer do any real work with video

though back to JXL related, has anyone tried encoding netflix's TIFF/EXR images into JXL to compare size? http://download.opencontent.netflix.com.s3.amazonaws.com/index.html?prefix=CosmosLaundromat/

The codec's position on fidelity remains quite delicate, so its reputation is still justified. I'll probably inquire more about AOM, but x266 will likely quickly overshadow it.

if rav1e didn't die, it would probably be excellent for fidelity, rav1e is still... fine if you dont mind contibuting to global warming, but it isn't as efficient as aomenc can be, it is however very reliable still making it a decent option for a very specific niche

for starters we'd make the screenshot tool store unmasked colors as pixel values

for example, black on white text would store black or white pixels

then a shape layer (8 bits per pixel, as if a 3x3 subpixel with the center missing) can be applied to regenerate the subpixel data

this would make the screenshots legible to viewers that don't support subpixel rendering

I would recommend removing that "Beta" after Safari 17

It makes readers think Safari is still testing

alrighty I have changed this now in my local copy that I will eventually submit \👍

Interesting, how exactly does that shape layer work?

You can certainly just store a grayscale or RGB image in jxl with some additional channel for a subpixel shape layer — there's nothing in the spec for that, but you could use a `kOptional` extra channel, give it some name like "SubpixelShape" or whatever so your application knows what to look for, and you can make it work. Of course normal jxl viewers would just ignore that extra channel, but you can make a special viewer that understands the extra channel.

If this is something common and desirable enough, we could think about standardizing it in one way or another, but I suspect subpixel rendering is kind of a legacy thing that no modern software still does, it brings more trouble than it solves when displays are getting more dense and many of them can be rotated...

"Global Warming" C'mon, it's a common talking point in PR slides for marketing, but there's no need to use it here.

its a joke

rav1e is super slow to encode for even a base line encode

sadly ClearType is still all over the place on Windows...

unless desktops are legacy now

I keep forgetting about Windows. Also I didn't know it was still using ClearType.

The error is still present.

What does it say, if you build with `./ci.sh opt` ?

I wouldn't be surprised if many Linux installations still use subpixel rendering.

My bad, the command was calling the wrong `cjxl`. It works fine now.

Fixed by these https://github.com/libjxl/libjxl/pull/3491 https://github.com/libjxl/libjxl/pull/3525

I think

there's also the newer DirectWrite API, which, unlike the GDI APIs, properly supports grayscale rendering. applications that don't use it (i.e. most of them, including windows explorer) can't be configured to do non-broken grayscale rendering though. so even if you have a display with a non-standard subpixel layout, you have to use ClearType configured as RGB or BGR for text to look acceptable

my workaround is MacType

JPEG XL is currently the most stable format I've tested along with WebP. Playback is still a bit slower compared to video, but it is far from the significant image drops of AVIF. That said, the rendering is not lossless; this may be due to the conversion to APNG.

Not lossless? That's weird. Colorspace shenanigans in your player maybe?

I have no idea. I created a new APNG file which I then converted to JPEG XL, and after a good hour of encoding, I got a true lossless file (not at the right FPS, but that’s something I need to adjust).

But speaking of color space, isn't there a way to adjust it with the `cjxl` encoder, or does it rely solely on the input file specifications?

I see that it doesn't accept AVIF files as input, and APNG doesn't support 10-bit...

apng should support 16bit which should cover you

And the encoder rejects 10-bit profiles.

when encoding it, if you have a 10bit if you encode to 16, it will just add some 0s, cjxl should be able to just handle that

It increases the bitrate by 20,000 Mb/s. That's not great.

Try --override_bitdepth 10

`Unrecognized option 'override_bitdepth'.`

They meant on cjxl, if you want smaller intermediate APNGs then the only real option is to increase the compression setting, assuming the tool you're using has one

Same on cjxl : `Unknown argument: -override_bitdepth`. The compression rate is already set to the maximum for each of my conversions.

hmm it works for me `cjxl --override_bitdepth 10 foo.png foo.jxl`. Which version are you on? `cjxl --version` I am on v0.10.2

v0.10.2 too

Maybe I need to remove my quality settings?

Yep, it looks like that's the issue. It's working now.

that's weird

what was the whole command line?

```cjxl input.apng -override_bitdepth 10 -q 100 -e 9 output.jxl cjxl input.apng --override_bitdepth 10 --q 100 --e 9 output.jxl```

short arguments (single letter) should have 1 dash, long arguments (full word or multiple words) should have two dashes

`cjxl input.apng --override_bitdepth 10 -q 100 -e 9 output.jxl`

That's right, thank you.

I think I found the source of the issue: When I use low effort for more speed, I get lossy quality even in lossless mode.

that really shouldn’t happen

The encoder clearly indicates that I am in lossless mode, so I am certain it's not my fault.

using `-q` <:SadOrange:806131742636507177>

sorry, I didn’t mean to imply that it was

what are your exact commands to encode & decode that give you lossy encoding in lossless mode?

No problem, I didn't misinterpret it. It's just that I often make mistakes.

```cjxl input.apng --override_bitdepth 10 -q 100 -e 1 output.jxl``` But it was the same without the `--override_bitdepth`.

so it's a 10-bit png as input?

errr.... apng?

16-bit, I guess.

what does `identify` say?

I add it to my command?

It’s part of image magick

$ identify <filename>

On phone can’t code block

Ah, I never use ImageMagick.

might be a good time to start <:Hypers:808826266060193874>

I’m trying to learn it

Okay, I see what you're asking me to do. Just wait for the encoding to finish.

My current way to manipulate images is ||ffmpeg||

oh god...

I use identify all the time though

Ikr

ffmpeg -i source.png -s:v 640x480 out.jpg

Is cjxl still currently the best highest quality encoder?

depends--are we talking about for high BPP lossy?

then pretty much yes

What about that chroma that everyone was talking about a few days ago

link?

https://discord.com/channels/794206087879852103/804324493420920833/1245906480192946256

oh god, the furry image...

yeah, the yellow is slightly off

I've noticed some color shift in some of my images as well, though that was with old libjxls so I would have to test again to see if it's still an issue

you ever notice that other than some common test photographs, all the images people who are image encoding fanatics test with seem to be furry, porn, or both

Slightly more seriously, is thể a way to pass y4m to cjxl and if not what’s the best intermediary , as I am trying to convert bt.2020 image frames into jxl

okay, so there are still slight color shift issues in cjxl

but I still think in terms of lossy, there aren't better options

on the one image I have with the most trouble, it shifts away from green and toward magenta (at `-d 1`)

there are also issues with dark areas losing detail but those can be mitigated with a high intensity target

This should not happen. Can you give an example input file and command line for which this happens? How did you check that it's not lossless?

I meant on the APNG input

```input.apng PNG 508x649 508x649+0+0 16-bit sRGB 294.244MiB 0.001u 0:00.000```

perhaps encoding as 16 itself is an issue?

well, yeah, encoding a 16-bit PNG to 10-bit *anything* is going to be lossy

that's not true

PNG has a header for indicating how many of the bits are actually real

no its 10bit to 16 bit

so the extra data should just be garbage

It was visually degraded.

doesn't identify show that though?

10bit -> 16bit png -> 10bit jxl, this should be fine

idk!

i can only guess either encoding the apng is broken, or decoding it.

But with an effort at 9, I have a real lossless file now.

0.0

we have a real uh oh moment on our hands lol

quite strange. Can you show an example of the kind of degradation you are seeing?

any effort distance 0 not being lossless is a bug — can you simplify things to a single problem frame and see if you can still get the buggy behavior to happen?

could be some shenanigans with the combination of e1 and animation, I suppose. Does the problem happen only at e1 or also at e2?

Maybe try `identify -verbose`

My first thought is something acting up with pallete and the 10 bit override with extra 16 bit garbage data

https://slow.pics/s/815wX69z

I'll test for `-e 2`.

Same, still lots of compression artifacts.

Wait... I think I was at 90 in quality.

I thought I had seen 'lossless', but it must have been another command...

Yeah, I had to run two encodings at the same time with different quality criteria, then I got mixed up.

Low-effort lossy encoding can indeed be less reliable than high-effort lossy encoding in the sense that there might be images or regions of images where low effort lossy is worse than the target quality. I wouldn't recommend using lossy below e4, and I would recommend using e6.

I intended to do lossless compression, that was a mistake on my part. To optimize the file size, I had chosen values around -e 9 or 10, but that seems to significantly slow down decoding. So, what is the recommended value for lossless?

If you want something that encodes/decodes quickly, I'd use e1/e2/e3

e3 for photographic, e1 or e2 for non-photo

🤔 is that still true if you're using `--faster_decoding=4` or whatever?

e1/e2/e3 are automatically decoding faster because they have specialized decode paths. --faster_decoding is mostly useful for lossy, though it should also help for higher-effort lossless — but generally I wouldn't really use that option tbh, for lossy the default decode speed is fast enough in practice and for lossless you'll get a bigger difference by switching to lower effort encoding. Something like -e 9 --faster_decoding=4 will probably still be slower than just -e 2

And `-e 2` + `--faster_decoding 4`?

Feel free to benchmark it, don't think it will make a big difference but I can be wrong

I don't think so, there's always a lag compared to a video.

Hi, I have 2 questions A): Can 'jpeg xl' be losslessly cropped? As in pixel perfect, not bit perfect. I am able to do this with current baseline 'jpegs' without the file size increasing using jpegtran, will the jxl format allow this? B): How can I losslessly re-compress a .jxl without the file size increasing? Currently I can run cjxl in.jpg out.jxl at default settings. But when I take that same output and re-run it again at say cjxl -d 0 -e9 in.jxl out.jxl it always seems to end up bigger than the original file

thanks

for question 2, it's because the first file is going through a special process that is specifically designed for making JPEGs smaller, where as the second time you're just using the normal lossless process, which does not know the input was a JPEG

so it's trying to also transcode the JPEG artifacts

ie. why would you do that?

if you specifically wanted to use a different effort, decode the JXL back into JPG and then cjxl again

for the first question, i think there is a way to define a display window frame to losslessly crop it, but not 100% Sure

Original jpegs used blocks of 8x8 pixels, JXL uses variable blocks in lossy or 128x128 minimum in modular mode (used for lossless, but can do lossy too). JXL has built in cropping, so the files can be made smaller losslessly, but they'll also be bigger than a jpeg crop due to the larger block sizes For the second question, as said above, you want to decode back to the jpeg and then use the higher effort/different settings

A) In principle, yes, but with VarDCT it is not possible to crop at arbitrary 8x8-aligned offsets. The current encoder does not allow blocks to cross the 64x64 grid, so in principle images could be cropped losslessly at those offsets, though the bitstream itself only guarantees that for a 256x256 grid. In any case, this is for now only academic, there is no jpegtran-like tool that does jxl transcoding at the coefficient level. It is also possible in principle to do a reversible cropping in jxl, keeping all the image data but simply adjusting the headers so the image canvas only includes the crop. There is no tool at the moment that can do that, but in principle it can be done by updating the image header to change the dimensions to the crop size and updating the frame header to make it have a crop offset and the original dimensions, without having to change the actual image data. B) If you use jxl as an input format in cjxl, it is always decoded to pixels. Possibly we could/should change that behavior in the case that it is a recompressed jpeg and the encode settings are lossless. The main use case we had in mind was to use lossless jxl (lossless from pixels, not from a jpeg) as input to do a lossy encoding of it, I don't think we had considered the option of re-encoding a recompressed jpeg losslessly. In any case, if the input is a lossy jxl (that is not an ex-jpeg), for now we have no other option than to decode it to pixels; making a jpegtran-like tool that can losslessly transcode lossy jxl is quite nontrivial and not within the scope of what we currently want to have in libjxl.

I'm mostly interested in using it for lossy though, and it did help decode speed

fairly small hit to efficiency as well

Yes, for lossy it should help quite a bit.

Hi CrushedAsian255 thanks for your reply. Why would I want to losslessly re-compress a .jxl file? Because I may not of been the person who created the files in the first place, or know what the inputs were for those any of those files in the beginning. If have a 20,000 various .jxl files gathered from random places of the net, how do I know that they as optimised as they could be? I don't, so of course I would simple run them through optimisation processes to see *if* they could be shrunk some more. I've been do this for years with all my file formats with a lot of success.

I’m not sure if such optimisation exists for VarDCT JXL. For lossless you can just convert jxl to jxl as it’s lossless. For JPEG transcoded JXL, you would want to convert back to JPEG. Not sure about VarDCT JXL, you could just try jxl->jxl using a higher effort but there will be some generation loss.

Also “as optimised as they can be” depends on how many years you want transcoding to take, Ie you probably wouldn’t want to use “ultraslow” av1 just to squeeze out 5% storage space

cjxl can take a long time at higher effort levels

Thanks. I have tested quite a bit .jxl to jxl back an forth to see the effects, and for the first time now reading the comments I have a much better idea of why some of my files (the jpeg ones) where getting larger and not smaller. Yes of course "optimised" can be a vague term I agree. However, that highlights things even more about re-compressing jxl files. Some people work in situations where power is not always constant or cheap, wouldn't it be nice to quickly save a bunch of .jxl (less optimised, but less energy/time used) and then at a later date come back to that same set of files when contacted to more stable power or cheaper energy and re-optimise again? 🙂

Thank you _wb_ for your answer. I understand it might not be possible to crop to arbitrary dimensions based on the file structure. However, having the ability to Losslessly crop *even just a little* off an image can make a huge difference to file sizes. I have a lot of astronomical images of large star fields such as 6000x6000 pixels, often I just want to focus on a small section of stars, square crop the image from say 20MB down to 50 kb and insert that smaller image into science document without lossing any of the image quality.

For default lossy (vardct), the jxl bitstream in principle allows cropping on a 256x256 grid (the AC group size) though it requires re-encoding DC groups, and relatively easily (i.e. with only header updates and selective bitstream copying) allows cropping on a 2048x2048 grid (the DC group size). For default lossless (modular with independent groups), in principle cropping on a 256x256 grid can be done with only header updates + selective bitstream copying. Currently there are no tools to do this kind of bitstream chopping. Maybe an interesting project for one of the independent implementers around here who wrote jxl decoders? After all, once you have a decoder that can parse the headers and interpret the TOC, you're halfway there: it's then a matter of making a new TOC and re-concatenating the relevant bitstream segments. <@853026420792360980> maybe you feel like writing such a tool?

don't ask me lol i'm still trying to parse the header 💀

Thank you _wb_ may I also ask in a similar fashion would there also be the ability in the future to *losslessly join* 2 or more images which I do with jpegtran. There are some scenarios where I have received 2 images of say an old star field map that was split in half or multiple tiles, for reasons of bandwidth in the past, a webmaster took a decision to split them up and years later I’ve had to rejoin files via command line tools back to the original image so I could study them properly. If both lossless *crop* and lossless *join* could be achieved in the JXL format, it would be nice to move away from PNGs. JPEGS or GIFs and finally simplifying to one universal image format.

I mean, as long as you are using lossless (like PNG), you can just use standard image editing tools like imagemagick to crop or join images, and just re-encode them. For lossy, things are way more complicated since standard tools operate on pixels, not internal representations used in lossy codecs, which for JPEG is still doable (just DCT coefficients) but for JXL gets much trickier (because there are more coding tools / block sizes / auxiliary internal images / etc).

for joining arbitrary JXL images, could you store each of them as reference frames and then use patches to assemble the final image? 🙂

I should say specifically joining basline JPEGS as those are my most problematic files due to trying to keep them lossless.

Sure, or just as two frames directly (using the offset in the frame header to position them)

But things get tricky in the general case, e.g. what if you're joining two jxl images that are themselves already multi-layer? Need to recompute offsets, etc.

Things can be done but someone has to write tools to do these tricks 🙂

I was considering doing something like this a bit ago and it's still on my mind, but time is the biggest issue

found out someone made a thumbnail thingy that allows explorer to preview JXL files... amazing! It seems to even support the progressive loading?

you sure about progressive loading/decoding? maybe you could take a video of what you are seeing

You're probably seeing a photo app loading the file explorer thumbnail before the full image

the jxl_winthumb made by jxl_oxide? Yeah it's pretty cool, too bad it doesn't work with the newer photo viewer, only the old winvista photo viewer

I think that's just a limitation with windows though

I think you *can* make it work, but it requires a lot of registry edits

I see a blurry photo then the full res after I’ll try to capture a video, hold on

which do you all think is better?

less or more "categories"?

It's so small that there's no point in splitting the last one up.

Personally I think the one with 3 categories looks best

I like the second image more. Maybe headers for each category would make it even easier to skim through (Encoders/Decoders, Browsers, Command-line tools, Image editors, Image tools)

Remove Chrome, Edge, Opera, add addon as a separate line instead

perhaps a newline for the ~~hall of shame~~ gimped applications

I decided against headers for each category since I feel like it would be a bit visually messy and unnecessary while also possibly somewhat negatively contrast with the rest of the site which in comparison is quite simplistic and doesn't contain any other multi-level lists https://discord.com/channels/794206087879852103/803574970180829194/1204264884016123954

Affinity Photo/Designer 2 also contains Affinity Publisher

cw: generative AI, AI upscaling ||How curious. I upscaled two images using two different AI-upscaling models. One of them generated a PNG that's **1.25x** bigger than the other. When converted to JXL modular lossless (I just used `cjxl -d 0`), sure they are both smaller than their PNG counterparts (which I didn't pngcrush btw, just saved directly from Upscayl), but the relative size difference increases to **1.5x**! And when compressed into JXL VarDCT (`cjxl -d 1.0`), the relative size difference flips over to **0.93x**!||

is this some exception to your usual experience?

it's mostly a curiosity

I'm fascinated by image compression and I'd love to know more about how different types of compression can have disparities to the point where the size difference between two images flips around like that

Pixelmator Pro can open JXL but cannot export JXL

Hello, everyone, I’m here again! Not sure if this is the best channel to ask, but I have decided to continue working on my JPEG XL extension. I decided to move from libjxl to jxl-oxide (because it is much easier to use!) and it seems to be working better than before. (Bar the fact it doesn’t use a worker anymore, so it might slow down browsing while loading images.) I have made it available on the `jxl-oxide` branch on <https://github.com/zamfofex/jxl-crx> ``` git clone --branch=jxl-oxide https://github.com/zamfofex/jxl-crx cd jxl-crx scripts/build.sh # if you want to use Chrome: rm manifest.json ln -s manifest-v3.json manifest.json ``` Then load it into Chrome/Firefox directly. (The `.zip` for Firefox, or the directory itself for Chrome.) **I’d love any kind of feedback!** Either here or on [#22](https://github.com/zamfofex/jxl-crx/pull/22) Note that now the build uses Node (and npm) for webpack.

I may be able to test it later today, <@703028154431832094> has a good page for testing decode speed, https://giannirosato.com/blog/post/corpus-lossy/ this will cripple most wasm implmentations since it does no lazy loading

actually, If you can throw a premade zip I can try it sooner, I dont have the compilation stuff installed on my device rn

the page doesn't crash now in firefox 0.0

its still slow, likely due to firefox not rendering the images until the addon is done decoding all of them

That sounds good! 😄

welcome back. you could probably post about or ask questions in the https://discord.com/channels/794206087879852103/1065165415598272582 channel

also I wonder how it compares to this standalone demo page https://jxl-oxide.tirr.dev/demo/index.html

chromium is way faster (I dont think it's being knee capped by rendering), and it too does not crash

though it did throw an error so I think it stopped decoding them early

oh yeah, the page did end up crashing, but not before decoding a large amount of images

if the site had lazy loading it would probably be fine, but I wonder if there is a way to limit the concurrent amount of decoding images

either way, seems like a large upgrade

I see! 😄 One neat thing is that now it supports animated JPEG XL images and other such niceties.

> Content-Security-Policy: The page’s settings blocked the loading of a resource (connect-src) at data:application/wasm;base64,AGFzbQEAAAA… because it violates the following directive: “connect-src *”

<:SadCheems:890866831047417898>

using a redirector to force lemmy to load all images as jxl and this causes issues when used with the extension

Amazing! Amazing news!

It does not crash with old jxl addon too, but..

With 17 G total used by ff

0.0

i would assume this has something to do with real-esrgan's very poor maintaining of details, results would prob be different with up-to-date archs. My guess is that VarDCT isn't able to preserve the visual quality as well (due to real-esrgan removing much of it on its own) and ends with a larger file because of that. Maybe the lack of detail makes it harder to find optimizations? this is all just speculation though

What model is better than ESRGAN?

Essentially anything that isn't ESRGAN. DAT, RGT, ATD, SPAN, etc. it's over half a decade old

interesting

How could libjxl become easier to use?

I guess we could add a higher level API for one-shot encoding/decoding, exposing fewer options and less functionality but making it just a single function call to convert a bitstream to or from a pixel buffer.

exposing fewer options ? `cjxl -h` already shows only 3 encoding options: distance, quality, effort how could you do fewer than that <:KekDog:805390049033191445> ~~and I don't want to add another `-v` to expose more options~~

\> API nobody uses cjxl

oh shit I misread <:KekDog:805390049033191445>

So like a thin wrapper?

Yes. But then again, most applications that need simple encode/decode, will not use codec libraries directly, but higher level libraries like libvips, ImageMagick, ffmpeg, CoreMedia, etc.

The nice thing about jxl-oxide is that it’s not just for “one‐shot decoding”. It seems to have most meaningful features of libjxl, but the API is just much simpler. Probably the most significant thing it lacks is converting across color profiles other than “to sRGB”. You just feed bytes into it, and at any point in time, you can just query the known information about the image.

I think it can hmm

just wondering what was the outcome from https://github.com/libjxl/libjxl/issues/3356

it was brought up that it's possible for there to be bitstreams that end up the same but decode differently (which is a very very bad thing for lossless) and that seems to have been the thing that made the decision lean towards changing the spec rather then fixing libjxl but I have to wonder if it's even possible for the libjxl encoder to produce such a bitstream or if it's just purely a theoretical thing

so the spec has been changed so it's now intended behaviour?

<@794205442175402004> would have to be the one to answer because even though it's been months and months I don't know how the spec drafting process works so it's possible that nothing has been done quite yet.

also if the libjxl encoder is incapable of producing JXLs that are undetectable as being invalid then I'm still in favor of the bug being fixed in libjxl rather then the spec being changed

i guess is this what happens if you use pre-release software?

with libjxl being the only real full encoder for JPEG XL (and also being the reference encoder) there is the consideration of all the pre-existing JXL files that people have made however this bug only appears on effort 8 and above which isn't the default and also the type of visual data affected mainly includes pixel art not constrained by a single palette and pixel data from decoded JPEGs.

I remember that it's actually possible for libjxl to produce image that's undetectable and compression density benefits from fixing libjxl was marginal

so they decided to go change the spec

the comparison of compression density was done by <@794205442175402004> on the set of images QOI uses for benchmarking https://qoiformat.org/benchmark/ and the image with the biggest difference was this https://upload.wikimedia.org/wikipedia/commons/8/88/Battle_for_Mandicor_0.0.5.png ``` 432707 Battle_for_Mandicor_0.0.5.png 197284 Battle_for_Mandicor_0.0.5.png.e8.bug.jxl 196985 Battle_for_Mandicor_0.0.5.png.e8.fixed.jxl 188207 Battle_for_Mandicor_0.0.5.png.e9.bug.jxl 187598 Battle_for_Mandicor_0.0.5.png.e9.fixed.jxl ```

I am curious as to what the results would be like on https://github.com/libjxl/libjxl/assets/2322996/6e607820-542f-443f-ae2a-5d6c4db39b5e and https://github.com/saschanaz/jxl-winthumb/files/12315745/anomalous-jxl-files.zip

No, libjxl did create bitstreams that would be incorrect according to how it was written in the spec. We have changed the wording in the spec to correspond to what libjxl has always done.

It was quite rare to find cases where it makes a difference: you need an image where a local palette of more than 256 colors is used and at the same time lz77 matches with special distances are used, which cannot happen in libjxl default effort or lower, but it can happen at e8+.

In any case, if it made a difference for compression, it was a very small one, and the difference could go either way. So we did not consider it worthwhile to change libjxl and potentially break existing bitstreams, and updated the wording in the spec instead.

what about RealESRGAN? Lots of upcaling frontends still use it

Real-ESRGAN isn't an arch, it's just ESRGAN trained with OTF degradation pipeline

https://discord.com/channels/794206087879852103/794206170445119489/1251752202977022014

Compact or SPAN are the best 1:1 replacements imo (trained), but RealESRGAN is not very impressive anymore, and idk why it would still be used

<@&807636211489177661>

Which one of them is good for 2D toons? So far waifu2x is the best in my experience, despite it's age.

how exactly do patches work in JXL? are they stored as hidden frames that are decoded before the main image? or are they encoded as part of the main image frame?

would it just be using `kReferenceOnly`?

https://openmodeldb.info/?t=cartoon

pick the one that suits your use case the best

Waifu2x is definitely very outdated, and it is also more complicated than just looking under the cartoon category on OMDB (majority of those models are outdated, very specific, or not viable), depends on your graphics card, what speeds you are looking for (real time for videos, whichever speed for images, medium for a balance, etc.) though that discussion is prob best suited for elsewhere.

Yes, kReferenceOnly is meant for patch frames, as it hides the frame. Though in an animation or multi-layer image where there is similarity between frames/layers, patches can also refer to previous visible frames.

Is there any way to view these hidden frames?

Hmm, someone should make some kind of GUI that shows the inner workings of the codec and lets you look behind the scenes of images

it's straightforward to output on encode, but idk about decode

What option?

Libjxl does not expose a way to see hidden frames, since they are considered internal stuff (unlike layers of a multi-layer image, which you can get from libjxl by disabling coalescing, and which are conceptually considered part of the decoded data)

But of course you could make a fork of libjxl that does show all the gory internals

`enc_patch_dictionary.cc` -> `FindBestPatchDictionary` ```if (WantDebugOutput(cparams)) { if (is_xyb) { JXL_RETURN_IF_ERROR(DumpXybImage(cparams, "reference", reference_frame)); } else { JXL_RETURN_IF_ERROR(DumpImage(cparams, "reference", reference_frame)); } }``` then run `benchmark_xl` with `--debug_image_dir`

https://discord.com/channels/794206087879852103/803645746661425173/892560805613146172 d1 170514B, d0 47355B, tiles d0 12400B

ah cool I forgot about that

https://uprootlabs.github.io/poly-flif/polyflif-sample.html

Speaking of forgetting about things, this is really cool

oooh I gotta try JXL performance on pixel art

I wonder if flif is better at progressive lossless than jxl...

FLIF is better at avoiding compression loss while doing progressive, though it has the same problem where for non-photo it will compress better in non-progressive mode. JXL is better in the quality of progressive steps (you get downscales with pixel averaging, not nearest neighbor like it is in FLIF).

is pixel averaging specified, or in other words, could an encoder choose a good scaling algorithm?

You *can* provide custom upsampling weights for resampled images (NN pixel art scaling), but I don't think you can for progressive scans

for pixel art, you can hint JXL to use nearest neighbor to further improve lossless compression with `--resampling=1|2|4|8 --already_downsampled --upsampling_mode=0` https://discord.com/channels/794206087879852103/794206087879852106/1239238259784024117

Yes, it is specified. No, an encoder has no choice, it has to be (A+B)/2 or else the reconstruction will not be lossless.

thanks!

lossless webp is way more practical. jxl can get denser at highest effort, but it's not comparable in compute efficiency

usually lossless webp will be smaller too (than *any* effort level of <:JXL:805850130203934781>)

if you venture to use settings beyond e you can get denser than webp

time to brute force some settings

I already did it

here's a small sample <https://loathra.com/jxl/bench/20240506.html#single-extra-22>

what's -strip do?

Like how WebP has tuning?

Here's using the upscaling trick where possible+best options (jixel)

(but that script assumes scaled pixel art, which is probably most distributed stuff)

even making the script would be too much effort for me lol

that just signifies no metadata

ah

here's a group of settings covering all minimum outputs found across 2207 commands

This is because of a shortcoming in the libjxl encoder, not the format itself, from what I think I heard

Hopefully one day libjxl improves, or better yet a new encoder steals the spotlight...

any future encoder does not help much in the present

Like how jxl-oxide seems to be slowly stealing the spotlight when it comes to decode

Yeah, for now, things are the way they are. :(

perf wise, its a ways off, progressiveness however, it will progressive decode files that libjxl just gives up on lol

At some point we should spend some time on improving lossless compression for images with few colors — not just pixel art but also e.g. bit depth < 8 images (e.g. RGB565), 4-bit grayscale, 1-bit black&white, etc. We have been focusing mostly on getting things right for 8 to 16 bit per channel full color images, but those do behave quite differently from low-color images. I have some ideas on things to try (mimicking pixel packing with Squeeze, better palette heuristics, finding ways to better combine lz77 with MA trees, more generic patch detection with better estimation of patch signaling cost vs benefit) but these are all rather nontrivial things to do and we're mostly talking about images that already compress extremely well (compared to 'normal' images) so the potential gains in absolute terms are not as big — I mean, a 1% improvement on a 10 MB file has more impact than a 20% improvement on a 10 kB file.

Does jxl have support for checksums, like for example dng and flac?

Not natively, but you could generate one from the image data and then store it as metadata

or create accompanying .par2 files

Would be nice to have as it would facilitate using jxl as an archival format

using par2, you can not only detect that something is wrong, but possibly even fix it (here, I manually corrupted three consecutive bytes in a hex editor) ```console $ par2 repair _W4A2518.jxl Loading "_W4A2518.jxl.par2". Loaded 4 new packets Loading "_W4A2518.jxl.vol0+1.par2". Loaded 1 new packets including 1 recovery blocks Loading "_W4A2518.jxl.par2". No new packets found There are 1 recoverable files and 0 other files. The block size used was 31296 bytes. There are a total of 2000 data blocks. The total size of the data files is 62591652 bytes. Verifying source files: Opening: "_W4A2518.jxl" Target: "_W4A2518.jxl" - damaged. Found 1999 of 2000 data blocks. Scanning extra files: Repair is required. 1 file(s) exist but are damaged. You have 1999 out of 2000 data blocks available. You have 1 recovery blocks available. Repair is possible. 1 recovery blocks will be used to repair. Computing Reed Solomon matrix. Constructing: done. Solving: done. Wrote 62591652 bytes to disk Verifying repaired files: Opening: "_W4A2518.jxl" Target: "_W4A2518.jxl" - found. Repair complete. ```

Ooh, par2 🥰

IA-32 JXL

I'm working on the docs on decoding jxl images <#1254012901816274956> main motivation is that afaik there's no open docs describing how to actually decode jxl, and the (paywalled) ISO spec is very difficult to read and understand

why does jpegview and irfanview show my jxl file like this?

imageglass opens it just fine but it's slow

Color management?

could be? iirc jpegview has color management off by default

I see

I'll look around in the settings

Maybe this will get into images :D

alright it's fixed

changing this option did it

IrfanView does not see color profile inside jxl 😦

Hi, is this normal? `-e 2 --faster_decoding 4 -d 1`

** ** `-e 6 --faster_decoding 4 -d 1`

** ** Original file:

no

well, actually at `d 1` I'm not sure <:Thonk:805904896879493180>

`-e 2 --faster_decoding 4 -d 0`

** ** `-e 6 --faster_decoding 4 -d 0`

** ** Weird

weird indeed, could you share the image?

what happens without faster_decoding?

Depending on the contents of the image, `-d 0` may be smaller than `-d 1`

Haha, no unfortunately. But I will try without faster decoding.

d0 being smaller than d1 can happen for 'clean' images (no photo, nothing 'noisy')

I remember libjxl did something weird when image is dithered

`-e 2 -d 1`

** ** `-e 6 -d 1`

** ** I think we've found the problem.

wow I am really curious about this image now, lol

so e6 d1 is a LOT smaller than e2 d1, but when adding faster_decoding 4 it becomes a LOT larger

is the image not legal to publicly share, or from someone who prefers it's not shared, or is it just nsfw?

The 3rd option.

If you can try cropping the image to a smaller region that would be OK to share and that still exhibits the weird cjxl behavior, that would be nice

if it's just nsfw then you can share it as far as I'm concerned, just remove the discord preview or put a spoiler thing around it with a warning so we're not blasting nsfw images at people

or putting in something like a zip file with a warning would work as well

I'll see what I can do.

There are only the legs, but it represents well the overall composition of the image. It's drawing combined with an assembly of textures of different qualities which results in a lot of banding and aliasing. ||https://litter.catbox.moe/w4e2ua.png||

Original dimensions: 6260 x 19252 (a kind of dakimakura).

I'm probably wrong, but the highlights almost look like clipped HDR to me

The PNG is 8-bit, but I don't know about the original PSD.

``` w4e2ua.png Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs -------------------------------------------------------------------------------------------------------------------------------------------------------- jxl:2:d1 18830 583436 0.2478740 142.099 578.221 1.81921705 83.32991363 52.29 0.54721688 0.135640859273 0.451 0 jxl:6:d1 18830 579887 0.2463662 20.822 488.140 1.40984583 85.53871848 54.98 0.40049452 0.098668329307 0.347 0 jxl:2:d1:faster_decoding=4 18830 619533 0.2632099 126.808 722.429 1.82612011 83.15371525 52.12 0.55527767 0.146154595606 0.481 0 jxl:6:d1:faster_decoding=4 18830 713773 0.3032480 45.504 730.564 1.72649039 84.61082300 54.41 0.41836603 0.126868659417 0.524 0 Aggregate: 18830 621928 0.2642276 64.280 621.259 1.68630999 84.15829259 53.44 0.47501319 0.125511576137 0.446 0 ```

these numbers are more or less normal — higher effort does produce better quality per byte, faster_decoding does come at some cost in both quality and size but mostly in size...

Guess we need the full image after all

for science, of course

In the name of da Vinci, we require the midriff

This is the heaviest PNG I could find on a forum, and even though there's nothing shocking about it, I find it really weird to have to share this. But if it's for science... ||<https://litter.catbox.moe/pfnoal.png>|| (NSFW)

a little `ect -9 -strip`: > Processed 1 file in 3m55s and saved 46,59MiB (59,679%)!

But where can I actually see all the possible commands? And what does the one you recommend correspond to?

Huh, so it's actually the midriff that's censored with a blurred lower resolution

I don't understand `ect` is something completely unrelated to JXL (it is a file optimizer, meaning that it losslessly recompress stuff without changing the file format - in this case only PNG) to see all possible commands of `cjxl`, use `cjxl -v -v -v -v -h`...

both images are already 404 not found 💀

guess you're not allowed to upload them to catbox 😆

no worry I have it, just need to wait for `cjxl -e 10 -d 0` to finish

in hope to bring it below 25MB to send it here

maaaaaan it is using 16GB of RAM <:NotLikeThis:805132742819053610>

I shouldn't have tried on my weak cpu, even just on default -3 it's still running Dx I should've done e1 d0

Chunked encoding my beloved

...that's all?

anyway try streaming in/out

wdym

Nah, just e9. 'Actual' streaming makes some heavy tradeoffs

I'm just saying I've had a lot more RAM used by cjxl on some images

well I have plenty of free RAM, I'll just wait <:KekDog:805390049033191445> it's just uncommon for me to see a program eating that much

wait til you see what ssimulacra2-rs uses...

I think I hit 13 GB once... Having 16 GB total.....

Boy oh boy was my SSD having *fun*

It's normal, I don't want them to be archived.

it remembers me that time cjxl took 26 Gigs of RAM to compress a 512,000x600 png file <:kekw:808717074305122316> this is that file > in case you want the 512,000x600 png: https://cdn.discordapp.com/attachments/874012579880660993/1047220909288722492/7gk51u.png :av1_pepeShy:

Ah, I thought you were talking about JPEG XL compression. But thanks for the cjxl command.

oh, I might have went for slower settings than that <:CatSmile:805382488293244929>

```wintime -- ect -p -r -k pfnoal.png Processed 1 file Saved 46.21MB out of 78.06MB (59.2009%) PageFaultCount: 220231218 PeakWorkingSetSize: 1.203 GiB QuotaPeakPagedPoolUsage: 25.39 KiB QuotaPeakNonPagedPoolUsage: 9.289 KiB PeakPagefileUsage: 1.203 GiB Creation time 2024/06/24 17:30:08.744 Exit time 2024/06/24 17:38:00.086 Wall time: 0 days, 00:07:51.342 (471.34 seconds) User time: 0 days, 00:03:15.156 (195.16 seconds) Kernel time: 0 days, 00:04:35.953 (275.95 seconds)``` Took almost twice as long on -3 instead of -9, either my CPU is really showing it's age or you've got a really damn good one haha

But anyway, back to JXL

i7-10870H so not great not bad ig

It's because I had already done it yesterday.

oh that explains it <:KekDog:805390049033191445>

also, this file is weird https://cdn.discordapp.com/attachments/733445413478334504/1254828649178202165/imagen.png

Like I said, a low resolution blur for censoring

👌

oh

Nah, I think the guy just messed up his export. The other versions of the image don't have that.

that's what I thought bc there is censoring in addition to that low-res part

Yep

when will JXL progress bar be a thing <:CatSmile:805382488293244929>

https://discord.com/channels/794206087879852103/804324493420920833/1252594723877556235

so do we have the wrong file?

w.r.t. the -e6 --faster_decoding being 4.5x heavier than -e2?

You have the softest version.

<:PepeOK:805388754545934396>

I just want to know if it's the one with `-e6 --faster_decoding being 4.5x heavier than -e2`

<:KekDog:805390049033191445>

If only there were a way to run the command and find out

Oh wait, e10, I forgot already

One day, this file will embed.... ECT Optimized

shit you made it before me <:KekDog:805390049033191445>

Just an e9 lossless, but now people can help ~~burn their RAM~~ test on it

Why is it lighter than mine?

so this looks like this was upscaled twice, first with nearest neighbor, and then again with bicubic?

More porn in the jxl server <:KekDog:884736660376535040>

If I knew it would take that long, I would have used cjxl nightly builds <:KekDog:805390049033191445>

Could be the viewer not using JXL color management

-e 11 when?

Displaying the image in r3dfox makes it chug holy shit

This is a weird ass export or censoring job

~~would be noice if not oversized~~

It took like a min to display, and yt video in background started having audio cut out

I'm on `4451ce9` and I'm not getting the weird results, seems like it was already fixed

e2 4.32 MB e6 3.99 MB e2 Faster Decoding 4.61 MB e6 Faster Decoding 4.59 MB

anyway this image should never be encoded, for like 5 different reasons...

only 1 of which has anything to do with JXL

RAM usage ? <:KekDog:805390049033191445>

I didn't intend to encode it. The initial idea was to find the heaviest image possible and see how much it could be reduced.

well more the weird BPP results

but its weird upscaling is reason enough to never use this image, let alone the nauseating subject matter <:YEP:808828808127971399>

But is there indeed a problem with faster decoding in the end?

<@1219592742011932732> what version of cjxl are you using?

`JPEG XL encoder v0.10.2 d947eb5`

I think they might mean "lighter" as in file size not visuals