JPEG XL

It now multithreads properly proportional to the image size and threads available

So small images are roughly the same, but the larger the image the bigger the gains

Currently 3am so I'll make an issue tomorrow, but so I don't forget... It seems using ISO noise in lossless causes it to have a green tint compared to lossy. Maybe trying to use an XYB color when the image stays RGB for lossless?

<@794205442175402004> the "very low quality" JPEG1 image looks much better than the avif or jpegxl images at the same ssim2 score

It has a lot more fine details.

And just looks much better. ssim2 seems to prefer a blurry fuzzy downsampled-looking image to a noisy or blocky image?

Noise does not look bad to the human eye. Maybe ssim2 unfairly penalizes noise too much compared to the human psychovisual system

Plus the best thing about high frequency noise is that it disappears if you downscale the image. Or even just step further back.

Noise only looks bad or noticeable if it's low-frequency.

Speaking of noise, I was complaining to a friend about artists adding fake ISO noise to 8K images, then they reminded me JXL does actually have a noise 'encoder' along with the ISO noise setting. I had it set to lossless, gave it a shot, and I got a 0.057 out of 11 bpp reduction... Not quite what I was hoping for, although maybe low distance lossy would work much better

I didn't think it would be functional in lossless mode.

I assume it's more useful when you have a noise removal prefilter and the ISO noise added as a postfilter. Preferably it ought to be automatic too.

Mean Opinion Scores are the Mean Opinion of many people. Some people prefer blockiness over blur, others prefer blur over blockiness. I agree that the 0.4 bpp JPEG has more detail than the 0.1 bpp jxl/avif, and if I had to choose one of them, from an "information preservation" point of view I'd pick the JPEG. But if I had to choose one to put on a website, I'd take one of the blurry ones. If you cannot compare to the original, it just looks out of focus, and people don't know if that's an artifact or an artistic intention. The JPEG however has quite obvious chromatic blocking and also without access to the original, it is immediately clear that there are compression artifacts on this image. So if I had to summarize it in a single score, I would say those three "very low quality" images have an equivalent quality, but the artifacts are very different so if you ask different people it is likely they will have different opinions on which is best.

The subjective data I used to tune ssimu2 was from various other datasets besides CID22 (where we didn't go to such low qualities, we started at libjpeg q30), most of them doing side-by-side comparisons and not fliptests. When you do side-by-side, it's more like a no-reference quality assessment, i.e. blockiness and other "obvious artifacts" will be more problematic than smoothing.

from what I recall, it doesn’t try to do anything to remove the noise, it just works under the assumption that lossy compression will have obliterated it anyway

in that sense, it doesn’t do anything special compared to photon noise (except that the noise curve can have a different shape)

That's a reasonable assumption at the lower qualities, but at the more usable qualities, I'd expect lossy compression to preserve at least some of the noise, especially in otherwise smooth regions where the noise is basically the only HF signal to encode (and visual models will likely encourage the encoder to not quantize it away, if it has any bits to spare)...

definitely

we could consider adding an explicit denoising option or something like that, but we’d have to consider whether it’s worth the effort

I think there would be a potential benefit if we would do something like this: - estimate noise level in the image, if there's no or not enough noise, skip the next steps - automatically set photon noise level to the estimated noise level - apply the EPF at a strength setting (number of iterations / sigma) proportional to the estimated noise level before encoding the image

Hi! Trying to figure out libjxl and looking into cjxl. And not sure is this a bug or 32bit float is not supported? both half and full float OpenEXR files encoded into half float jxl file with identical size. Also are there true losless for uint images or it always "near lossless" ? Half float looks like a true lossless.

we can just reuse the decoder EPF as an encoder preprocessing step, it should be pretty good as a general-purpose denoiser

This could be a cjxl bug in how it reads exr files. Try converting the exr to pfm first and encoding that.

ah, looks like i missed PFM. Thanx. I thought that might be openexr decoder issue.

the thing is, if I had to estimate the noise level, I would probably attempt to denoise and look at how much noise it removed

are there cheaper ways to do that?

I have code that takes an original image and a denoised image, and outputs an estimated photon noise level based on that, but in libjxl, I think I might have miscalibrated the photon noise option (-> it generates more noise than it should)

so the estimated noise level is off for cjxl

(it should be fine for the libaom implementation)

I’ve been meaning to recalibrate cjxl for a while but haven’t gotten around to it

(that is, https://github.com/libjxl/libjxl/blob/f78c90b9992f2c9adcb2da80b1a012e21e55c3c9/lib/jxl/enc_photon_noise.cc#L87 might be too high)

it’s encoder-only, so even if we change this, an image that was previously encoded with what looked like the desired amount of noise will still be decoded with that same amount

some simple wavelet denoiser similar to libraw maybe?

_but_ someone who is used to “`--photon_noise_iso=3200` gives me the amount of noise I want” would have to search for their new preferred level for future encodes

How is that graph

Second graph

Probably a disaster

Now is better 0,31bpp

Still too noisy for my taste

But i have a bit problemzz

is this a library issue? 😉

ohh. So it looks like cxjl/djxl are just full of bugs. The idea to incorporate support for multiple file formats import/export gives a wrong idea about JPEG XL. looks like only PFM/PNM/PGM <> jxl is works correctly. all other have issues on encoding or decoding.

I am worried that these metrics might illustrate a tendency for ssim2 to unfairly punish high frequency noise?

It might be a good idea to have either an optional flag to enable noise detection, or to have automatic noise detection and estimation at the default effort level. Filtering out high frequency noise before encoding, and adding it back after decoding, can save a lot of bandwidth by not wasting bits on encoding noise.

Wb is too optimistic

sorry, which encoding/decoding issues are you referring to?

JPEG XL is superior

OpenEXR 32bit convert to 16bit. Color space tagging. UINT16 PNG <> jxl <> PNG looks like do something with roundings in lossless. etc.

some small issues that only visible when you try to compare pixel by pixel

is there an issue open for those?

the 32-bit exr will probably be somewhat involved to fix since half floats is all that the API we are using exposes, but colorspace tagging should work in both directions

(https://github.com/libjxl/libjxl/blob/f78c90b9992f2c9adcb2da80b1a012e21e55c3c9/lib/extras/enc/exr.cc#L105-L116, https://github.com/libjxl/libjxl/blob/f78c90b9992f2c9adcb2da80b1a012e21e55c3c9/lib/extras/dec/exr.cc#L176-L188)

I think Vlad is referring to this

when i import original exr and converted from jxl EXR in Photoshop (exr-io) and Afinity i found that colors are tagged incorrectly. I used ProphotoRGB (RIMM/ROMM RGB)

Vlad, have you tried using vips? vips seems to be a pretty good interface or frontend to libjxl as well as multiple other image processing and codec tools

oh, wait, I wonder if it might have to do with this https://github.com/libjxl/libjxl/commit/197ee929232b0a63138996095b16bb8525f3de84

actually i just need to check all libjxl properties without digging too deep into it code as soon as plan to work on OpenImageIO JpegXL plugin.

maybe something similar is going on in `djxl`

maybe running something like `vips jxlsave` on the command line can do what you want

I love vips

i'm from VFX/3D scanning camp 😄

Not sure how good it is at converting between metadata formats or transposing between colorspaces

I would try something like doing an 8x8 DCT, ignoring the first few or even half of the LF coeffs, taking the sum of the HF coeffs, and taking the minimum (or some kind of soft-min) of those sums over the entire image. In a noise-free image, you would expect to get zero (since there should be at least some blocks that are solid or a perfectly smooth gradient), while if there's noise, there will always be some HF signal.

That makes logical sense to me.

Not very elegant but probably good enough

we might expect solid black or solid white even in noisy images, so perhaps some _ad hoc_ rule for that in addition

Fixed

In my opinion you should add a even lower quality to the graph

I tune even lower but a loweer quality needs To be put off

I assumed it would lower the bpp on lossless by making the predictions closer to the input. But I suppose if it's just the same as ISO noise, then it wouldn't be aware the noise synthesis is enabled at all, still trying to preserve the noise rather than just letting the predictions 'carry on' since they'll be covered up anyway (similar to the proposed splines)

Naturally it was also pretty slow and memory hungry, but I doubt the noise estimation could be run per block and a mean found at the end

This? https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4055

Yep. But that draft not my. It pretty basic and just don’t properly handle jpeg xl

Just was not sure about what libjxl is support. Libheif for example support only 12bit and near zero chance they add higher bit depth.

Libjxl looks much better on start with supporting much more. And maybe can be an interesting alternative to OpenEXR DWAA/DWAB

Would be nice if an update to jpegxl could support raw sensor data

It was considered, since there is a planned way to encode RAW bayer patterns, but nothing is set in stone yet and Adobe already decided one way to do it

What's adobe's way? Is there a link?

bayer encoding is a cool topic

Well, I'm not entirely sure how they do it, but I know I can extract raw JXL tiles form it that decode normally https://helpx.adobe.com/content/dam/help/en/photoshop/pdf/DNG_Spec_1_7_1_0.pdf

That can be done in a several ways. From pixel shift that make Bayer pattern become a lines. To rearranging RGGB planes into the same channel. Or encoding RGGB as a separate channels

Btw, are there any GPU implementation for jpeg xl are exist?

GPU image decoding is a false promise that fools many

For a programmer, it's not practical to use

Even on phones

jxl is fast in cpu decoding and scales well. its avif that literally requires maximum hw accelerations just to not generate and decode way too slow

I think by gpu they mean asic?

Oh. Do you want discuss about managing multiply highres high speed Machine vision cameras for 4D capture without using GPU encoder?

well technically i can hold up to 2 minutes of capture in ram (servers have 2TB ram) but nvjpeg make it possible transcode in realtime (8x cams per server on two A4000)

i wish nvjpeg2000 would be such fast, but it 20x times slower

Specifically, what I mean is, hardware decoders usually can only decode one frame at a time, serially.

If you are browsing a webpage or gallery, you need to be able to decode multiple different images in parallel

if measure everything in web browsings we are doomed 😉

Most image gallery apps store thumbnails that are decoded on the CPU in parallel

ehh... it doesn't really matter since queues exist, asics are fast enough.

the issue is when you have really unoptimized pipelines

it still plenty of use cases where GPU encoder/decoders are preferred.

Agreed

for example CinemaDNG Encoder from fastmedia

when you have thousands camera raws you need to process

30-60fps for Sony A7RIV raws

at least jxl has pretty fast decoding :D especially with the faster decoding flag

i pretty much enable it for all of my encodes

It depends on the use case. There are some use cases where it makes sense practically, and some use cases where it doesn't but people think it does.

Yes, i love how fast jpegxl on decoding. jpeg2000 extremely slow

JPEGXL was designed to be efficient on the CPU. Hardware encoders are in the works I hear

There is a new version of jpeg2000 that is much faster since it uses a different entropy coder I think. Called HTJ2K

High throughput

But jpegxl should still give good performance and better compression density

adobtion of jpeg2000 even for part1 and 2 is so low 😦

Honestly it's amazing that a modern format like jpegxl is faster than baseline jpeg2k

Especially when the trend of all other formats is to get slower and slower like avif

what the slowest part of jp2 huffman encoding or wavelets?

Normal jp2 does some kind of bitplane per bitplane binary arithmetic coding with branchy conditionals, iirc. This is quite slow. High-throughput j2k (HTJ2K) changes the entropy coding to be faster.

Yeah, so, it's not the wavelets.

Is HTJ2K any worse density than normal J2K?

And since only the entropy coder is different, doesn't that mean they can be losslessly transcoded?

I achieved Transparency with JPEG XL at 0,143bpp

Yes, HTJ2K is a bit worse density than normal J2K, and yes, in principle it can be losslessly converted between the two (though I don't know if there's tooling available for that)

Jxl is destroying av01

I think it's pretty cool that JXL is able to losslessly compress both integer and float image data

Underrated feaure. Underrated format.

Need to add to OpenEXR for better adoption in VFX industry

They use awful DWAA/DWAB instead

I normally use PXR for photographs and just use RLE or PIZ for everything else

Last night I was thinking the EXR code in Blender could be used for layered JXL, but just making it a compression type like in DNG could work

Looks like it's a better lossy format than JPEG, pretty similar though, but probably with encoders that are much less well tuned.

High bit depth is of course very cool.

Looks not so good for extreme post processing. Like fine tuned masks based on color channels or some ranges. Even for quite good compression 0~4

certainly

JPEG is not a very good format for near-lossless, highest possible quality is often not perceptually lossless

I think effort=5 would make a better default for libjxl. It seems to be the best trade between density and speed.

effort=5 in v0.10 seems to be very close to the maximum density.

Before mpx/s jumps off a cliff

I heard there was already plans to make 5 the default?

Although I can see how e7 is a good choice too.

e6, not e5, because for lossy e6 is almost the same as e7, and for lossless it's not much worse, but the speed gain is noticeable, so perhaps it's more balanced

encoding speed is generally not much of an issue for image encoding

for who is not issue?

For me 😁 but I understand that other people may have other needs

I keep wondering, with all the benchmarks and comparisons we've run, surely we know the best speed/compression ratio across a wide range of images?

E 8 q 76.1

E 5 q 43,4

But I don't have the ffmpeg build or stand alone

That's svt av1 psy

No but people trying it for the first time are going to be impressed with how fast it is, as long as the speed doesn't effect density that much

<@794205442175402004> I'll stop training JXL, I don't know the differenze on specs to AV01

E4 q10

E4 q10

E9 q14

E6 q10

Microsoft encouraged its developers to hide plenty of easter eggs like mini games in their Office software, to bloat its filesize, as people associate larger files with better software.

<@1028567873007927297>

How is compared to libjxl 0.7.0

Q46 E9

fax, I don't understand what you're asking... Why are you highlighting me? :P

E9 Q10

20c in Catania no more encoding i care about climate change

Jxl e5 q14

I'm objective best jxl settings is e3 q14

First jxl q20 second avif q56

AV2F is way superior

Jxl

I need some help

I bring up saturation

I think fab is an AI...

Everything he seems to do and say is completely random and has barely any correlation to anything.

IQ 66-68 I'm less smarter than 99% of the poiplation

I did 91 one month ago now I'm tired so I'm not ABle

Another set image, I do not think I'm talented

This is avif

Cheese parmesan has some problem at q16

Those images seems like re encoding

There is a saying fab

Better to be silent and have people think you're a fool, than to open your mouth and thus remove any doubt

I think I'm butchering the quote

But basically what I'm saying is maybe you should make less noise.

And try to attract less attention

Btw congrats <@794205442175402004> on the excellent article and thank you to everyone who contributed to making libjxl, large and small. It's amazing news that libjxl is now the pareto front of nearly all types of compression.

I am really excited to see the future of third party implementations with cleaner codebases than libjxl

What kind of sneaky attack is this 😅

I know only one alternative encoder attempt. I bet it will take some time before a more efficient alternative appears

Is already efficient at e5 q14

Encoder or decoder

The rust decoder is probably going to get adopted into browsers some day.

Encoder

An attempt was made by tranoptera if I remember

libjxl has some impressive accomplishments but it also has a lot of fat to cut. And it still calls abort(). Which completely excludes it from possibility being used in many projects from the start

This last point is marked as to be corrected for 1.0

Very simple things like that are holding back its potential... If I didn't have so many people breathing down my neck I would be more involved in OSS and make some pull requests... Maybe I should get involved anyways.

I think it would be a trivial patch to begin with

It's low hanging fruit with a big impact

It's just adding an #ifdef

To like 2 functions

If it was so easy it would have been made already. I fear it requires a big overhaul of error handling

I looked at the relevant file a month or so ago and maybe I am blind but it looked trivial

I'll try to pull it up now. Honestly no idea why it's like that if it's seemingly so trivial

I'm not skilled enough to tell 😅

Even something as simple as a macro that redefines the routine to a noop would be better than what it currently is

Because aborting the caller completely denies the opportunity for developers that use the library to gracefully handle errors or malfunctions or unexpected behavior. It's basically hostile and malicious sabotage of the calling application and people attempting to use libjxl

Not checking return status for malloc is also a similar issue but more subtle and less blatantly hostile

I don't know how many different ways there are in C++ to dynamically allocate memory or how the incomprehensibly comprehensive C++ API expects the developer to check for memory allocation failure, but in C it's relatively straightforward.

Sadly there's hardly any discussion on the issue tracker about this from libjxl API users like ffmpeg/vips/magick developers

https://github.com/Traneptora/hydrium/

It's funny how some people are gifted math geniuses really good at doing the hard work that no one else is able to do or comprehend... but the really basic simple stuff like checking for failure conditions and returning JXL_DEC_ERROR if anything goes wrong, is difficult and elusive instead lol

I don't copy hydrium i do e7 with my math

Don't judge me by my IQ today is the easter

I think in 6pm someone would give some updated workings

the default way (`new`) throws `std::bad_alloc`

https://en.cppreference.com/w/cpp/memory/new/bad_alloc

C programmers never check for malloc errors, they just assume allocation always succeeds 😄

which, on systems with overcommit, will be true

Bad ones.

(there’s also `new(std::nothrow)` which returns null instead of throwing https://en.cppreference.com/w/cpp/memory/new/nothrow)

Maybe that's standard policy for developers that work for Red Hat

what

But that is considered misuse of the C standard library API

To not check for failed malloc

The API clearly says it can fail

And gives the developer the opportunity to handle it

not entirely true. There are situations where malloc can fail on systems with overcommit, hell even when there's plenty of memory left!

If you have the opportunity to handle something gracefully and prevent data loss then why write fragile and broken code?

Even if you don't care, other developers that link to your code might care

E9 q12 looks how is good

I don't think I've ever seen software that tries to gracefully handle out of memory situations, except maybe SQLite

Libraries would usually return some kind of "ALLOC_FAIL" error, but then what do you do? Probably call abort.

maybe display an error message like “Sorry, exporting failed due to insufficient available memory. Consider closing a few applications and trying again.”

sound like a job for the thing that's running the program

Most libraries return an error status and return control back to the caller

And in the case of host applications they have an opportunity to ask the user if they want to try again, or try to free some memory, or just try to avoid data loss caused by a sudden crash

It's theoretically possible for computers not to suck if you don't want them to

I'm a champion but Jon refuses to load the image for me

https://jon-cld.s3.amazonaws.com/test/ahall_of_fshame_SSIMULACRA_2_modelD.html

Let's try

He needs dozens of persons

If you have talent please do some partecipation

Let's talk every 30 minutes not every 10 minutes

Interesting link, is wb the author? It is the first time I see this kind of comparison

This is the latest i have

The doors now looks more sharp

But you have to use e9 so it needs an improvement in that sense

My browser doesn't load the images, cpu problem if you have a serious computer please do the comparison

Yeah, it's a cool link, and I believe wb is the author of both ssim2 and the hall of shame

Good job

YooChar

It's not meant to compare codecs. It's meant to compare "image similarity" algorithms.

Jxl experimental manga encoderr

Experimental one

Here's https://jon-cld.s3.amazonaws.com/test/ahall_of_fshame_SSIMULACRA_2_modelD.html

What is aurora? Never heard of such a codec. Unless it is a jpeg encoder?

Dday.it fast av1 encoder you can also train on dday.it dataset

Is by zoe liu and visiolarum

Like this one? https://visionular.ai/auroraimage/

I'm struggling to have idea

In 2:00 pm they were 9 people working, now is only me on that page

I'm getting ludicrously slow performance with libjxl transcoding an animated gif into jpegxl. It says it's using multiple threads but only one thread is actually being utilized. Even at effort=1 it's extremely bad performance, 0.019 MP/s, unless the tool does not count the pixels in additional frames when counting MP/s

But cjxl core usage is bad

It's single threaded even though it says it's using multiple threads

At all effort levels.

And density is much worse than gifski

By comparison gifski uses multiple threads and outperforms cjxl by a massive margin in both speed and density

Also I am unable to encode APNG produced by ffmpeg.

Oh, I think I know why, though...

That's probably because Arch sucks and stopped including the apng patch to libpng, so never mind that.

...Nah, it still says "getting pixel data failed" even after rebuilding it with patched libpng...

So essentially, it's impossible for me to create an animated jpegxl from an apng, unless I convert to gif first, and then it will use one core and be worse in every way compared to gifski

I wonder how all those animated jpegxl test images were created

Also, I don't think any libjxl developers have ever reached out to any of the users of the libjxl API, to offer suggestions about how the libjxl library is being used in applications and image libraries that link to libjxl

Therefore, ffmpeg does not have animation support and I don't think anyone knowledgeable about the API is around to take a look at https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/libavcodec/libjxlenc.c for example, in order to offer suggestions to the ffmpeg devs or to the author of this file, on the best way to add animation support.

Even though such a thing would increase the usefulness and ease of adoption of libjxl :)

Or really, offering advice or feedback to the developers of any library or application that links to libjxl.

Particularly in the areas of partial/cropped/thumbnail decoding, animation, streaming i/o, and setting memory limits to prevent DoS attacks.

the author of that code is <@853026420792360980>

https://github.com/libjxl/libjxl/issues/3430

if there's a bug in cjxl's reading of apngs, that'll get fixed

regarding libjxl_anim encoder, there's an existing patch for that that someone here authored. it needs to be tweaked a bit because of changes I have made to the encoder, but the work has mostly been done

it hasn't been merged already mostly because of my time, not because I don't know how to use the libjxl API

regarding feedback and API, I regularly ask and provide those sorts of things

so that's not the issue

So i'm saying libjxl whitepaper 2.0 can't produce animation?

No one said anything about a whitepaper

Probably some things got reserved that users asked in 0.7.0

So idk how it could be the new encoder

I meant the spec was made by 100+ people

I didn't realize you were the same person. That's cool. There was a developer from another important image processing library, I think it was maybe vips, who said they would welcome someone from here to look at their code and offer feedback about their use of the libjxl API. vips is a great library used by a lot of software for loading images. It has a great speed-optimized thumbnail generation feature for codecs like JPEG that support being decoded at a reduced resolution and increased speed.

It has great support for decoding lots of different image types by linking to many different codec libraries, so it would be a great general image transcoder, and a great model for how the libjxl API is expected to be consumed by applications in the wild

Same with other general image libraries that support lots of codecs and link to libjxl

As far as I know, they asked for suggestions and are awaiting feedback and I assumed it's like that way for most projects that use libjxl

Vips has another encoder which I haven't compiled

JPEG XL now reached decent ssim

This is the result of interframe jxl

It improved for me but your eyes can just flagged say no

fab, that's just from the metrics comparison page. It has nothing to do with animation and it's comparing metrics, not codecs

I did another improvements of all codecs now but I have to wait for getting the better encoderz

ye. one issue that needs to be reconciled is that libjxl doesn't support negative linesizes for buffers

currently the way ffmpeg handles that is if the frame to encode has a negative linesize, it takes the absolute value and sets the orientation flag in the image header to "flipped vertically"

that way buffers with negative linesizes, such as those from decoded PFM images, will be handled properly

issue with this is that linesize is a property of an AVFrame, and not of an encoded stream, but orientation is in the JXL imageheader, not the frame header

so if the linesizes aren't *all* negative or *all* positive, then this trick can't work, and I won't know if this is the case until i receive a frame down the line

I'm considering just assuming this is a very unlikely scenario and failing intentionally if it isn't

Are you referring to images that scan up from the bottom like bmp?

I never heard the term linesize before

Sounds unlikely for an apng to have differences like that between frames.

Depends on whether you consider adding more threads a speedup. Outside photo-like and sufficient threading, webp is competitive or superior.

Notice in the blog post how jxl just beats webp on "non-photographic" when it's given 8x as many threads.

And this advantage diminishes as images become smaller.

That's too bad. Hopefully Jyrki's webp algorithm gets ported over...

Anyone have idea on how write_scanline() logic works for file formats that do not natively support scanlines? For example, JPEG just can't support scanlines because it encoded by blocks 8x8. But at the same time, even in libjpeg, they have write_scanline().

i think it's just because a lot of things are done by row

makes it easy

Well if the scanline is not a single line of pixels but a data block with 8x lines of pixels than they have sense. But not sure if that implemented like this.

the function is for the human

it can do whatever it wants under the hood

Solved this image after 12 days Sorry jon Sneyers

Still unclear. If scanlines are accumulating before passing to encoder. That probably should be mentioned in API. Otherwise someone would decide that write in columns also great idea 🙂

columns are just rows

Performance wise they are the not the same 😉

does anyone know what's calling convention on jxl.dll functions and callbacks?

cdecl.

even on windows 64 bit? ty

(more generally, any library that wasn't particularly developed for Windows in the first place will use cdecl by default)

I've been burned in the past assuming cdecl so I wanted to be sure

unless `__stdcall` somehow became a default, cdecl will continue to be a default

(you can also search for `declspec` to confirm that 🙂

pretty sure it's __fastcall on 64 bit

btw are you using something other than C++?

C#

cause your question sounds like that, yeah sure

writing C# bindings to jxl for multiple platforms

which I'm going to use

I hate when documentation doesn't list actual values on enums, especially when it doesn't say which header this enum is defined in exactly

uh oh, is using int a good idea for public function?

what's the `sizeof(JxlBasicInfo)` because I don't want to make it unsafe because of padding at the end?

is it 196 (24 fields 4 bytes + 100 padding)?

I think you want to (partly) generate such information via a small C program to be robust

oh and another question, is there a way to know which library I need to reference for each function because I can't find it in documentation either

I also ended up with different set of libraries after building it compared to what was in prebuilt download for windows - first image is from building it myself, 2nd is prebuilt (sizes are also all different)

oh, I figured it's `*_EXPORT` defines, they are different for each library

it seems 204 bytes in x86-64 btw, confirmed with the actual header and godbolt.org. I think your count was invalid, it should have been 26 fields (so that 26 x 4 + 100 = 204).

ah, thanks, I'll probably just go over this again and run some C once I finish

nearly done writing thin low level wrapper

I'm assuming `double white_point_xy[2];` these have x first?

and other CIE xy space fields

what exactly is jxl_opaque in parallel runners?

is that decoder/encoder opaque?

yes

yeah, I missed couple fields in my bindings, good thing I manually counted, these were missings somehow

ook, seems to work, will need to figure out how to build this for other platforms eventually <:SadCat:805389277247701002>

is there any way to make decoder turn image upside down? for now I just set this ```csharp JxlPixelFormat format = new() { NumChannels = 4, DataType = JxlDataType.UInt8, Endianness = JxlEndianness.NativeEndian, Align = 0, }; ``` and try to load that as ARGB32 texture but I end up with wrong colors and upside down image

ok, color issue solved by using RGBA32 format but there is still orientation issue

is there a way to flip output upside down?

for now I'm just manually flipping output buffer but it'd be great if there was a way to tell decoder to do that

I really like the dithering added to the decoder!

why is extra channel index using both `size_t` and `uint32_t`?

either should work, the actual range is much smaller and fits to uint16_t.

(as for why, I think `uint32_t` is generally used for structures while `size_t` is preferred for function arguments? that's the very fundamental decision that has to be made when you program in C/C++, and that convention is not too surprising to me.)

((the main exception here is, of course, structure fields which can reasonably exceed 2^32 without OOM))

size_t needs to be deleted

Then what type would you use

`size_t` has purpose

but I think using them interchangeably is just asking for trouble at some point in the future

also these doc lines confuse me ``` * The returned pointer is an opaque struct tied to the encoder and it will be * deallocated by the encoder when @ref JxlEncoderDestroy() is called. For * functions taking both a @ref JxlEncoder and a @ref JxlEncoderFrameSettings, * only @ref JxlEncoderFrameSettings created with this function for the same * encoder instance can be used. ```

it mentions functions that take both JxlEncoder and JxlEncoderFrameSettings but I couldn't find any in either my bindings or headers that I ported to C#

is it outdated or for future stuff?

i always specify the size of the int

I think native one makes sense to use when you don't care about size or representation and just use the one most fitting for the platform, less so in library headers but especially when it uses specific size in certain place and then size_t or even worse something like int/short in others

Has anyone actually managed to encode apngs recently? I can't find a single image that decodes due to this https://github.com/libjxl/libjxl/issues/3430

well, older `cjxl` managed to, yes see this one

used 0.8 release aka `JPEG XL encoder v0.8.0 adfc39bc [AVX2,SSE4,SSSE3,Unknown]`

Hence `recently`, I have an old 0.6 verson laying around but the memory use is too much without 0.10

I didn't understand the "recently" as a version number <:KekDog:805390049033191445>

Well, within this year would've been nice xD

because in your GitHub comment you say > Do we actually know of any apng encoders that are compatible with cjxl currently? > apngasm is also affected so yeah there's one, cjxl 0.8.0 <:kekw:808717074305122316>

and my file viewer supports animated JXL <:Stonks:806137886726553651>

``` C:\Users\jonat\Downloads>djxl Test.jxl Test.apng JPEG XL decoder v0.10.2 e148959 [AVX2,SSE2] Decoded to pixels. 384 x 256, 0.315 MP/s [0.31, 0.31], , 1 reps, 16 threads. C:\Users\jonat\Downloads>cjxl Test.apng Test.jxl JPEG XL encoder v0.10.2 e148959 [AVX2,SSE2] Getting pixel data failed. ```

Hmm

perhaps also libpng vs lodepng? i got more issues with libpng when compiling with libjxl

it can't read apng. Almost all apng has fcTL before IDAT because that's what the actual spec recommends

is it known djpegli not working with cmyk?

if I use JxlDecoderReset do I have to set runner again? I assume so but I want to confirm that's the case

daaamn, decoder is fast

would really like jpegli to be able to be build as a separate library so it can actually be used

separate also as in different from libjpeg

It can be... but I'm too lazy rn to do it... are you using arch?

would prebuilt stable and nightly dlls distributed alongside jxl's not be adequate enough ?

also needs headers to be included in any project

rn there are none

so it's literally unusable

Not entirely... it's supposed to be compatible with libjpeg headers

And doesn't it also have its own API that allows higher than 8-bit input and output?

So maybe it does have headers...

they're not installed

so it's only a replacement

except it's not a complete replacement

so it cant be used as a replacement

wait, it's not even a replacement

since you need libjpeg to use it

it's a hack

It definitely has a long way to go in order to make it into a proper replacement

I also want to be able to use it alongside libjpeg

How? It IS libjpeg... but it also has its own jpegli_ prefixed API

Maybe that's what you mean by using it alongside

If you use the jpegli api then you can use it alongside a different libjpeg

They raise a good point, what happens to jpegli's '10-bit' when transcoded to JXL? https://github.com/libjxl/libjxl/issues/3464#issuecomment-2047846092

I think libjxl decodes to high precision in the same way that libjpegli does

a peak absolute error of 0.000304968 is pretty low, right?

i encoded a 16 bit png to jpeg with cjpegli, then transcoded to jxl, and finally decoded both to PFM, them compared with imagemagick

jxlinfo calls it an "8-bit RGB" image, but that's just metadata

there is a legitimate concern in that djxl and other software might default to decoding to 8-bit if not instructed otherwise

yeah

Uh, nothing? jpegli internally uses higher precision, so does libjxl, the DCG coefficients are losslessly preserved when you do lossless transcoding, so why would anything change?

Guess my brain thought about how jpegli isn't used in djxl, ect. Although the transcoded jpegs having better decoding *was* already a feature

When jxlinfo says 8-bit RGB here for DCT images, it's technically lying and not even applicable at all.

It can be decoded at any precision.

Apparently the JFIF format has around 10 bits of "effective" precision if you do the calculations at a higher precision.

technically, it's supposed to be the bit depth of the source data

it depends. 8-bit JPEG can actually have an effective bit depth of 7 in some situations! What Jyrki found was that in *smooth gradients*, the effective bit depth can be as high as 10.5, and since smooth gradients is exactly where you want more bits to reduce banding, that's perfect.

(also, JFIF is just a container format for JPEG)

Yeah, that's what jxlinfo is actually listing, not the current representation of that data

That explains a lot and is very awesome

And makes a lot of sense

So basically jpeg doesn't need to have such horrible banding

It's partially a deficiency of the coder/decoder and not the data format itself

I guess one could argue that it’s a sort of meta-failure of the data format that it gives implementers the wrong idea about what is possible

And the reason why is that smooth gradients don't actually contain a lot of frequency data

Well I don't think anyone was necessarily forced to use 8 bit precision for everything.

Back then, 32kb RAM should be good enough for anybody

8 bit color was considered impressive, shockingly amazing probably

Anything higher than 16 unique colors was state of the art

:)

In jxl, the internal DCT coefficients do not have a specific bit depth (dequant factors are arbitrary real numbers), so the bit depth in the image metadata is only a suggestion of how to quantize the decoded RGB pixels if you need to use a limited precision integer buffer format. In jpeg, the internal DCT coefficients are 12-bit, and those 4 extra bits are added to help make a round trip of iDCT(DCT(original)) not lose too much precision due to rounding. It's not enough to do fully reversible 8-bit in general (i.e. including "difficult" blocks like pure noise), but for a smooth block, one that effectively can be represented using just the first few low frequency coefficients, the effective precision that is available is closer to 12 bit. Assuming of course that the decoder doesn't immediately quantize the result after iDCT to 8-bit, which is what is often done (to save memory and because it is assumed that this is enough).

Perhaps jpegli should add a metadata note indicating that the source was (potentially) higher bit depth, and then libjxl could set different metadata than it usually does for jpeg?

Does jpegli still use higher precision calculations internally and then dither during decoding if both the input and output buffers are 8 bit?

jpegli during decoding doesn't know whether the original input was high precision

also, using higher precision internally produces higher quality regardless (though only slighty, of course)

Well yeah. The smart thing to do is use high precision calculations internally all the time regardless of what the input or output precision is, and dither back down to lower precision at the final step when decoding to a lower precision output

Just for the sake of less error and amplification of errors during the encoding and decoding steps

I have a question about custom memory manager

documentation doesn't mention it - do I have to handle double free

or does it guarantee that free is never called twice

Is it true that libjxl had problems with adobeRGB somehow, before 0.10, like the commenters on phoronix are suggesting?

Also <@154245620557807617> could you go into more specifics?

iirc it had some issues with reproducing the proper ICC data but it was proper colorimetery?

what I meant is if I use custom allocator is it possible for `free` function to be called twice on same memory, from my logging it doesn't seem to be the case, so far I only see one memory allocation and one free

since it defaults to standard `malloc`/`free` and double free with those is illegal i would assume that double free by libjxl is also considered a bug

alright, ty

let us know if you find any <:KekDog:805390049033191445>

If you use a custom malloc it should not change anything at all with how to use libjxl

Some malloc implementations can detect double free

mimalloc is supposed to be basically the best general purpose malloc afaik

i've heard praise for mimalloc and jemalloc

I think it's kinda cool that unreal engine uses it

for something like libjxl (as used in many applications), it might even be beneficial to use an arena -- so you can allocate quickly and then destroy all jxl-related memory in one go when you're done with your encode or decode

The problem with jxl is that I cannot even decode a large enough image

Without running out of RAM

It doesn't use a fixed amount of memory

Also I think I found the source of people saying libjxl does not support adobe RGB color profiles properly

https://github.com/libjxl/libjxl/issues/2550#issuecomment-1649736670

So apparently djxl mangles/chops the colors, and recreates the color profile incorrectly as a linear profile?

(writing in the present tense but I'm not sure if we've changed it) djxl defaults to outputting to linear sRGB because it can't convert back to an ICC profile (as opposed to an enum colour profile), but there's no inherent chopping there (the linear data is unbounded), and the ICC profile is stored in the .jxl file

the chopping happens when the linear data is written to PNG

cjxl is now able to make an enum colour profile out of Adobe RGB, which works around the issue because the decoder can convert to that without needing a CMS

but even without that, the previous .jxl files are fine, they're just less convenient to decode to Adobe RGB

Well if the output is png or jfif, then it's gunna get chopped because I don't think those output formats support unbounded values or floats... and I think the root problem is that it's coverting it into a linear colorspace in the first place

Also it would be nice if the decoder produced some kind of warning when clipping occurs.

yeah, that's one of the first things I asked for also some extended api that would use all the jpegli features without libjpeg compatibility and it would be nice to have that even before the official announcement, because it creates difficulties for those who want to try jpegli and it's already happening https://github.com/libjxl/libjxl/issues/3489

especially for windows, and it would be nice to add jpegli for vcpkg <https://github.com/microsoft/vcpkg>

I think it's nice to see a conversation where the languages are mixed

He asked a question titled "ask a question!"