JPEG XL

The style kinda makes me think of that.

Lol not really, but I can see what you mean. It was painted by a friend a decade ago or so...

I followed these instructions on debian and found the `libjxl_dec.a` in the lib directory. When trying to link it into my project with wasm-ld, the linker says "undefined symbol: malloc" among other standard library functions. This is probably more an issue with my project, but if there's anything I need to change with the libjxl build please advise : )

commits were made last week on this topic, did you tried the last version ? I have no idea how to help you yet, I'll try to compile myself and see what I get

I pulled latest main and tried rebuilding. Seems to be the same for this case

what if you link it with `emcc` instead?

Using emcc (`emcc libjxl_dec.a libhwy.a hello_world.c`) does seem to do the job. Since emscripten is designed to convert entire native apps to a browser experience, I'm unsure how to call specific functions it outputs from javascript, but if this is the official way to use libjxl in wasm I'll dig more into emscripten. Thanks for the suggestion.

nice speedup for jpeg reconstruction: https://github.com/libjxl/libjxl/pull/2534 🙂

Is GIF to lossy animated JXL supposed to work ? ``` $ ./cjxl -d 1 -e 9 1671398343573.gif poked1.jxl JPEG XL encoder v0.9.0 561baa06 [AVX2,SSE4,SSSE3,SSE2] Read 1280x720 image, 12372743 bytes, 10.2 MP/s Encoding [VarDCT, d1.000, effort: 9], ./lib/jxl/image.h:60: JXL_CHECK: xsize <= orig_xsize_ Illegal instruction (core dumped)```https://cdn.discordapp.com/attachments/673202643916816384/1114828631022247967/1671398343573.gif Works fine with `-d 0`

perhaps the issue is the size (quite a big gif) ?

Just to test, try with -e 1 instead of 9

no issue with -e 1

My first thought is a memory issue, e 9 hogs a *lot*, but the error suggests the output had it's size changed. I'll leave it to the experts

-e 1..7 no problem

8 and 9 have the error

not related to memory, I have 32 Gigs <:dogelol:867794291652558888> and already compressed a 356000x600 png with effort 9 <:kekw:758892021191934033>

if I need to open an issue no prob

that's a bug then, open an issue

probably something broken in the case of e8/e9 with cropped frames or something

Maybe to do with the full-frame techniques they enable

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

does anyone know if this part is neccessary when building jpeg xl? https://github.com/libjxl/libjxl/blob/c27d499263435ac77007174e0f1cf54557cff23a/ci.sh#L463 I'm talking about the part ` -- all doc`

I'm getting a weird error like `ninja: error: unknown target 'doc', did you mean 'box'?` but I can make it go away if I just remove this part. I think it has something to do with documentation

but I'm worried if it's actually something more important you shouldn't mess with

lands here

thanks, that seems quite informative

does that still happen on a deoptimized version of the input GIF? ```console $ gifsicle --unoptimize input.gif -o unopt.gif ```

I suspect that cropped frames are the issue

I think this gifsicle command should make it use a full frame throughout instead

oh, the GIF is included in the issue

I can try it myself

it does seem to prevent the crash

which makes it plausible that this is the issue

somewhat embarrassingly, that means that there is no need for a large GIF to trigger this, just `testdata/jxl/traffic_light.gif` from libjxl itself is enough

Why do flags with more than one word use underscores instead of hyphens like in other programs?

From what I've seen underscore is the usual for commandline programes with the occasional hyphen rarely

it’s kind of the norm in google programs given that this is how gflags / absl::flags behave

you’ll write ```c++ ABSL_FLAG(std::string, my_flag, "", "My flag."); ``` and your program will have `--my_flag`

readable from the program using `absl::GetFlag(FLAGS_my_flag)`

no `_`↔`-` translation between the two

Thanks for explaining!

In my experience, it's actually been the opposite: mostly hyphens, sometimes underscores. Usually I see underscores in Python argparse programs, so I guess it might be up to the argument parsing libraries a lot of programs use, if they don't parse the arguments themselves.

it's improved, but on some images e3 is still much bigger than e1 and e2, even if the palette detection works, e3 is still using the single filter that's mostly good for photos?

Yeah e3 uses the Weighed predictor in a fixed way, e1 and e2 use Gradient

Probably we should add some of the e1 features to e2 and e3, like doing runs with lz77

https://embed.moe/https://cdn.discordapp.com/attachments/804324493420920833/1118554879187767376/mario.png.default.jxl

default upsampling is not so nice for pixel art, makes it all fuzzy

so I want to add this as an option

https://embed.moe/https://cdn.discordapp.com/attachments/804324493420920833/1118555056430649404/mario.png.NN.jxl

for 8x upsampling the overhead is 420 bytes (for 4x upsampling 110 bytes, for 2x upsampling 30 bytes)

funky custom upsampling could also be done, like this thing:

https://embed.moe/https://cdn.discordapp.com/attachments/804324493420920833/1118555360211505152/mario.png.funky.jxl

why so many bytes ! just to upsample ?

Is this because there's no NN upscaling option encoded as an enum, so a custom matrix is needed?

what can be done is a bit limited by the clamping the upsampler does, I wanted to get nice visible pixels but you can see that in the solid regions it cannot make the pixel borders black because it's clamping to the range of the local neighborhood

yeah, there's just the default weights which are the fancy one, and the option to signal something else but then it's basically an F16 per weight

420 bytes for custom 8x upsampling is a bit of a silly cost, for NN those are almost all zeroes though so the cost when sent with gzip or brotli is small in that case

I'm not familiar with web compression, but isn't it common for compression to be aborted if substantial incompressible data is found in the first 4k bytes or so?

yeah it doesnt even matter because it all fits in a single ethernet frame anyway

In this case the 420 bytes that are mostly zeroes are close to the start so it could be compressed

Anyway 420 bytes is not that bad, still better than manually upsampling the image and encoding it like that

And maybe 4x upsampling makes more sense for pixel art, which is only 110 bytes of overhead

Wonder how the upsampling scales compared to rendered at the larger resolution to start

Well in terms of signaling upsampling has a constant cost, encoding more pixels comes at some per pixel cost even if the pixels are easy to predict and RLE can be used

In terms of encode effort it's of course easier to encode fewer pixels

In terms of decode effort, the upsampling is an extra step but it should be cheaper than decoding more lossless pixels...

This would be massive. Currently: ```4045 2g56jd7gqee71_1x.jxl 5251 2g56jd7gqee71_4x.jxl 4180 39145ugc6z081_1x.jxl 5731 39145ugc6z081_4x.jxl 1213 4defpr3sffm61_1x.jxl 1628 4defpr3sffm61_4x.jxl 4192 h47sip13u1a71_1x.jxl 6279 h47sip13u1a71_6x.jxl 3514 ommpg9mflv571_1x.jxl 5483 ommpg9mflv571_6x.jxl 4798 xfr4rch46f371_1x.jxl 6861 xfr4rch46f371_6x.jxl 4102 zjw3unww9t371_1x.jxl 6603 zjw3unww9t371_8x.jxl 5320 zxx5nl7wrd771_1x.jxl 7657 zxx5nl7wrd771_6x.jxl```

Could it be cheaper to do multiple smaller upsampling steps (e.g. 4x, 2x)?

Surely dumb to consider at this scale, but what if you wanted like 32x upsampling ...

Spec only has 2,4,8

Though I guess you could do multi-step upsampling with patches

Oh, so 6x is right out.

Well you can do 2x on a manual 3x but yeah, powers of two only for signalled upsampling

Generic compression provides some nice savings for that Mario image. ``` Algo | Bytes -------|------ none | 975 gzip | 635 brotli | 596 zstd | 597 ```

Yeah the 8x upsampling weights are 210 half-floats (so 420 header bytes), and for NN those weights are all zeroes except for 10 weights which are one

We should probably have specified that info to be in a modular compressed image and maybe not in the image header but as part of the frame header or LfGlobal, but too late for that now

There is fix in libjxl 0.8.2 for the infinite loop bug. Please accept my apology that I overlooked this problem and haven't reported when it was known: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=51259

Made my first Pull and Commit on Github, signed the CLI but the Authors check failed. So I fixed my profile to use my actual email instead of the github noreply and then put it into the Authors file. However, on the last run it seemed to find my correct email, then fail while trying to find the removed one. Not sure if the next attempt will work, but being new I thought it's worth double checking here that I'm doing it right The PR <https://github.com/libjxl/libjxl/pull/2552> The failed check <https://github.com/libjxl/libjxl/actions/runs/5281413911/jobs/9555018375?pr=2552> At least I won't have to do it again in future

is it possible to only build decoder library without all the extra stuff (or decoder+encoder)? as minimal as possible

there's `libjxl_dec` that tries to be that

v0.8.2 does not have binaries in Release

that is weird, they should be added automatically, but apparently this didn't happen yet

wasn't XYB the default mode of jpegxl ? I'm confused

Yeah, it's confusing. An image can be tagged to be in some RGB space, or it can be tagged to be XYB. The internal space used for lossy is always XYB, but usually the decoder will convert it back to some RGB space (except in this exotic case where the image is tagged to be "natively" XYB)

so kXYB, kRGB and kGray do not actually change the data inside a lossy JXL they only instruct the decoder?

Yep. As long as XYB is used internally (which is what is always done when doing lossy), the tag is only a suggestion for what to convert the data to

When not doing XYB, the tagged space does define how to interpret the pixels though

is `uses_original_profile == true` and `CS == kXYB` valid?

I don't see why not, and it means exactly the same thing as `uses_original_profile == false` and `CS == kXYB` since in both cases the pixel data is XYB and the nominal 'original' space is also XYB

> When I am running tests with libjxl from git, the success rate depends on whether I use SKCMS or LCMS2. I don’t like the sound of this

this may be relevant: lcms2 creates slightly different icc profile compared to libjxl, with same constants for primaries

any tips on decoding to jpeg using libjxl? i modified the `decode_oneshot.cc` example, and what i have mostly works. but it seems like `JxlDecoderReleaseJPEGBuffer` is returning the full size of the jpeg buffer i provided with `JxlDecoderSetJPEGBuffer`, implying that it hasn't written anything, even though it has actually written data that matches the jpeg file i started with

here's what i have currently

ok, it seems like if i call `JxlDecoderReleaseJPEGBuffer` after receiving `JXL_DEC_FULL_IMAGE` that reports the actual value

at that point i have resized the buffer enough times that it can hold the whole jpeg

neat

When 1.0 is out, "Getting Started" and other tutorial pages for various use cases really should be there, especially considering that library is really sensitive about everything.

or reevaluate API surface and redesign it for usability

<https://github.com/libjxl/libjxl/pull/2627> > So there clearly is some benefit of AVX512 over AVX2, but the difference is not huge, and the impact is mostly on encode speed, not so much on decode speed. so maybe keep AVX512 enabled for the encoder/libjxl and disable just if it's a separate decoder? because I don't think the size of the full libjxl and tools is as important as just a separate decoder

that's tricky because the decoder code gets compiled only once, it is shared by libjxl and libjxl_dec

I find it interesting that on D1 AVX512 scores ever so slightly higher on quality too

> (these are single-core timings on a Intel(R) Xeon(R) Platinum 8275CL CPU @ 3.00GHz) also, since Cascade Lake is a slightly improved Skylake, it may have frequency drop issues, so newer or AMD CPUs may have higher performance improvement from AVX512 https://www.phoronix.com/news/LLVM-Google-Light-AVX-Option

that's probably just random small fluctuations due to some things being slightly different depending on simd width — I doubt it will be systematically better or worse with avx512

I've been out the loop for a while, but I know Intel disabled AVX512 on their 'flagship' chip that featured it, then AMD made a big deal of bringing it back properly. The fact there's separate compiler options for nomral 512 and AMD512 suggests there's probably *some* difference to them, but Jon already said he can't test that

I probably could test it if I spin up an AMD512 ec2 instance, but basically I think we should focus in the default build on hardware that is common enough — with SSE2 we cover 100% of x64 platforms, and then SSE4 gives an extra speedup for 99% of people, and AVX2 will give another extra speedup for 90% of people. For those < 10% people with AVX512, using 'only' AVX2 does not really make it significantly slower, and they have beefy machines anyway.

For use cases where that extra 5% speed matters, a custom build can always be done — we're just talking about what makes sense for a default build as it will end up in distros or applications statically linking with libjxl

I think the main difference between AMD and Intel as far as AVX512 is concerned is which operations are faster and which are slower.

IIRC some stuff involving mask registers is significantly faster on AMD, otoh some operations cannot be efficiently executed using the 256 bit wide math units AMD chips have.

(and of course, every AVX512 chip ever support a different subset of all the various extensions)

Actually yeah, good point. The only chips with 512 are already almost twice as fast as ones from 2017, so would make even less of a difference anyway

yeah, but it depends on how much increased binary size is critical for some cases, for normal distributions I don't think it is as important as for some standalone apps with integrated jxl decoder, especially for mobile ones for speed it's also relative, jxl encoding speed is still not fast enough to be completely neglected even on fast processors and if there are advantages for avx512 on the same system, why not maybe not right now but in the future if jxl gets more avx512 optimizations and assuming at least all amd processors starting with zen4 will support avx512 ```When taking the geometric mean of all the raw AVX-512 benchmark results in this article, the Xeon Platinum 8380 2P "Ice Lake" performance went up by 34% with the AVX-512 enabled run where as the Xeon Platinum 8490H 2P "Sapphire Rapids" AVX-512 performance improved by 44% and the EPYC 9654 2P "Genoa" performance was up by 21% with AVX-512. Sapphire Rapids not only enjoyed much larger uplift from AVX-512 compared to with Ice Lake, but also a big win for power efficiency.```

Sure, defaults will likely evolve and if avx512 becomes more widely adopted, of course we should include it in the default at some point. Just like at some point probably everything will have at least sse4 so we can drop sse2.

ARM architectures exist as well and weren't mentioned in this discussion despite libjxl working there as well. Tho most people will likely not use those when using libjxl

builds for x64 will not include ARM code 🙂

for ARM, we currently only build NEON with a scalar fallback, I think

Yeah, Neon is what I saw iirc

But well, I compiled from source back then, heh

Speaking of evolving defaults, is there a benchmarking test currently to find what effort setting has the best balance across a wide range of images, or are we just setting it based on the techniques used and personal experience? I was wondering about lowering the lossless effort to `e5`, but I don't know if that'd complicate things having different defaults between lossy and lossless or how that'd effect the vast majority of images. It results in 5% larger files but double the MP/s from what I've been getting lately

generally the default is chosen so it's still kind of reasonable and anything slower will either make it unreasonably slow or not really pay off — but yes, especially for lossless e7 is unreasonably slow for larger images, and for lossy probably e6 would be a better default

I thought e5 for lossless since that's when patches are included too, so you aren't doubling the filesize if there's lots of text or such. For lossy e7 is also when patches are enabled, at least according to old docs on the github, so might be best to leave it as is

is there something for lossy e9 that can be further optimized or something not very useful that does not give a visible improvement but is very costly? or is this just more butteraugli iterations?

<https://github.com/libjxl/libjxl/blob/main/doc/encode_effort.md>

currently even e9 lossy is not super exhaustive yet, e.g. it uses some heuristics to do the block splitting and it doesn't try multiple options for it: once the block splitting is chosen, it will stick to it and just tweak the adaptive quant weights

going from 80% coverage to 84% coverage took a bit of effort, I think we can go a few percent points higher but to get to 100% would mean adding tests for all possible ways in which a bitstream can be invalid, and that's probably not so useful (fuzzing is a better way to check for robustness against invalid/malicious bitstreams)

When I do -q 85, sometimes -e 9 produces ~30% higher filesize than -e 5, while at the same time slightly lower ssimulacra score. If we look at individual pixels, then typically -e 9 is slightly closer to the original values, but overall it's not very noticeable at a normal viewing distance. At the same time doing something like -q 93 -e 5 produces the same filesize and better quality, both visually and metric. So I was thinking if it would make sense to have a mode that would mix both? Would it be possible to determine the better option during encoding?

Here is a graph between -e5 and -e9 on a small set of drawings. -e9 often has 8-10% smaller size without changing ssimulacra score much, but then it sharply transforms into putting more and more bits. And sometimes it works, that gives from 1.5 to 3 ssimulacra points, but sometimes it doesn't help much at all. https://i.imgur.com/YI10QJu.jpg

Thanks

Also what I don't like about jxl is that screenshots look like this even at d 0.346e9

And this should be solved in 1.0libjxl

Sometimes it even severely underexpose

There's no tune to it

Seems like jxl_from_tree simply crashes when given splines, either that or I did something catastrophically wrong

The spline also needs 4 * 32 coefficients, and there was no background

I tried with the coefficients too but it didn't change anything, although I guess I missed that last `set` while copy pasting though a few sites. That must've been it, thanks

this is helpful

Can the libjxl take y4m as input now? I tried but got "getting pixle data failed "

I don’t think we have any code dedicated to reading those

thanks!

does it work for cli encoder? just for lossy or also for lossless? and how much does it make compression worse? https://github.com/libjxl/libjxl/pull/2632

at present, there are no plans to make it work for the CLI encoder (which would require that the readers for PNG, etc. read those in a streaming fashion as well)

there will probably be a flag to make the CLI encoder use the API in that way, for testing, but there will likely not be a practical advantage

Depending how it works, for large 8 bit images on high effort settings it could keep the memory usage in check, but that's just an idea

for practical use it would be useful for example for encoding gigantic resolutions with small memory consumption or am I misunderstanding something about this streaming encoding?

it would do that when the gigantic images are generated/read piece by piece by the software using libjxl, but for the foreseeable future, `cjxl` itself will read input images all at once

there may be some reduction in memory usage but not as much as will be achievable by other software

with `cjxl`, enough memory for the entire image will still be needed

There's a difference between needing the entire image once in a 3-byte-per-pixel uint8 RGB buffer versus what it does now, which is making a few copies as 12-byte-per-pixel float buffers...

right, I just want to make sure that the limitations are clear 😁

I usually prefer to err on the side of slightly underselling

Yeah, that's what I was talking about too, 1/4 the memory usage should definately come in handy haha

Where libwebp-dev dependency used? I can't neither encode from nor decode to webp format.

In benchmark_xl only, I think

In vague relation to the streaming encoder conversation the other day, I wondered if it could be enabled for lower effort settings before full-frame features such as patches are used. I just tried a 12K 38MB PNG and noticed even on singlethread and lowest group size, it would read the image into memory (400~MB), then skyrocket on `-e 2` to above 8GB before I did ctrl+c (e 1 lossy being the same, but fast lossless reaching 1~GB and completing). Although, if the float buffers can be avoided on 8bit images anyway then obviously that would help

The max size needed in theory would be only one LF group plus some overhead

once the image is in RAM

LF groups don't really interact with other LF groups much

except some edge pixels

Does libjxl libjpeg aka jpegli contain libjpeg headers for compiling software to use libjpeg?

Also will it ever have libjpeg v8 abi support?

Some distros use v8 as the default for some reason

Like arch

can someone point me in the right direction for cross compiling a minimal jxl build? cross compiling for android and I just need it to be compatible with ffmpeg (for use with libmpv) this is the script thus far ```sh cmake -B $build \ -DCMAKE_TOOLCHAIN_FILE="$ANDROID_NDK_HOME"/build/cmake/android.toolchain.cmake \ -DANDROID_PLATFORM=22 \ -DANDROID_ABI=$cpu \ -DBUILD_SHARED_LIBS:BOOL=ON \ -DCMAKE_BUILD_TYPE:STRING='None' \ -DJPEGXL_ENABLE_BENCHMARK:BOOL='false' \ -DJPEGXL_ENABLE_EXAMPLES:BOOL='false' \ -DJPEGXL_ENABLE_FUZZERS:BOOL='false' \ -DJPEGXL_ENABLE_PLUGINS:BOOL='false' \ -DJPEGXL_ENABLE_VIEWERS:BOOL='false' \ -DJPEGXL_BUNDLE_LIBPNG:BOOL='NO' \ -DJPEGXL_ENABLE_TOOLS:BOOL='false' \ -DJPEGXL_ENABLE_JNI:BOOL='false' \ -DJPEGXL_ENABLE_JPEGLI:BOOL='false' \ -DJPEGXL_ENABLE_JPEGLI_LIBJPEG:BOOL='false' \ -DJPEGXL_ENABLE_DOXYGEN:BOOL='false' \ -DJPEGXL_ENABLE_MANPAGES:BOOL='false' \ -DJPEGXL_ENABLE_SJPEG:BOOL='false' \ -DJPEGXL_ENABLE_OPENEXR:BOOL='false' \ -Wno-dev cmake --build $build ``` currently running into this issue when compiling ```ps In file included from /home/quack/code/mpv-android/mpv-android/buildscripts/deps/libjxl/lib/jxl/test_utils.cc:6: /home/quack/code/mpv-android/mpv-android/buildscripts/deps/libjxl/lib/jxl/test_utils.h:14:10: fatal error: 'jxl/thread_parallel_runner_cxx.h' file not found #include <jxl/thread_parallel_runner_cxx.h> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. make[2]: *** [lib/CMakeFiles/jxl_testlib-static.dir/build.make:104: lib/CMakeFiles/jxl_testlib-static.dir/jxl/test_utils.cc.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1813: lib/CMakeFiles/jxl_testlib-static.dir/all] Error 2 make: *** [Makefile:146: all] Error 2 ```

or is this just a issue that should be reported?

I only really care about decoding since I'm only trying to get jxl images to work

try with `build_testing=false`

or whatever it's called

`-DBUILD_TESTING:BOOL='false'`

huh, I completely missed that, thanks a bunch

also you can pass `-GNinja` to cmake to make it use ninja instead of Makefile

which is a bit faster

ill give that a try for sure too

sorry, another issue, this one leaving me even more puzzled, any idea why this would be failing? I decided to build brotli myself since it's causing me issues when trying to do a static build. I did do a grep for `PC_BROTLICOMMON_INCLUDEDIR` `760:PC_BROTLICOMMON_INCLUDEDIR:INTERNAL=/home/quack/code/mpv-android/mpv-android/buildscripts/prefix/armv7l/usr/include` and the file it should be looking for does exist ``` file /home/quack/code/mpv-android/mpv-android/buildscripts/prefix/armv7l/usr/include/brotli/decode.h /home/quack/code/mpv-android/mpv-android/buildscripts/prefix/armv7l/usr/include/brotli/decode.h: C source, ASCII text ``` ```sh -- Checking for module 'libbrotlicommon' -- Found libbrotlicommon, version 1.0.9 -- Checking for module 'libbrotlienc' -- Found libbrotlienc, version 1.0.9 -- Checking for module 'libbrotlidec' -- Found libbrotlidec, version 1.0.9 -- Could NOT find Brotli (missing: BROTLI_INCLUDE_DIR BROTLICOMMON_LIBRARY BROTLIENC_LIBRARY BROTLIDEC_LIBRARY) CMake Error at third_party/CMakeLists.txt:53 (message): Brotli not found, install brotli-dev or download brotli source code to third_party/brotli from https://github.com/google/brotli. You can use /home/quack/code/mpv-android/mpv-android/buildscripts/deps/libjxl/deps.sh to download this dependency. ```

why not just have it use the submodule to build brotli?

Im having troubles getting it to build statically, so I took a look at what mabs and btbn are doing for windows and both of them are building it independantly so I thought Id try to reference that to no avail

Does djxl tool use jpegli for jpeg output? Also it would be nice if there was an option for cjxl to produce jpeg using the new jpegli encoder, or jxl-recompressed jpeg, using an option flag.

I believe this would speed up adoption of the library and tools.

By making it more useful and easier to access since many distros will ship jxl without jpegli

I anticipate that including a significantly more efficient legacy-compatible jpeg encoder with the library in an easy to access way will help attract more interest in the library

Beating mozjpeg is a big deal

It's a huge achievement

> Does djxl tool use jpegli for jpeg output? For pixels to jpeg, it uses whatever libjpeg it links to, which may not be jpegli > Also it would be nice if there was an option for cjxl to produce jpeg using the new jpegli encoder cjpegli does this, it's a tool installed alongside cjxl > jxl-recompressed jpeg not sure about this one, since iirc the purpose of this feature is to improve existing legacy jpegs. if you have the original pixel buffer it makes more sense to cjxl a native JXL and cjpegli a fallback, than to use one file

Yes, it does make more sense, except in the very specific and unlikely case that someone cares about having a legacy fallback option

And wants one file

In that fairly unique and unlikely case, someone can run cjpegli and then cjxl

the djxl/cjxl tools link to a libjpeg, which isn't guaranteed to be jpegli unless you install that

I ran into this issue when using ssimulacra2 on jpegs

it's the latest stable build of TurboJPEG, which is why they do that

and MozJPEG

I just tested it, it installs `<jpeglib.h>` `<jconfig.h>` and `<jmorecfg.h>`

Ssim2 doesn't work well on images that were transposed to xyb and back again, it unfairly penalizes images that look visually indistinguishable from what I heard, so is that a bug that will be tuned and improved in the future or is that just a "feature" of ssim2 for the forseeable future?

ssimulacra2 or ssim2?

(not the same thing)

Oh, cool, thanks for testing that

I think ssimulacra

Didn't know they are distinct

That's confusing

Especially since there's a ssimulcra2.1

well `ssim2` is not a thing, SSIM is a metric and SSIMULACRA2 is an improved version of SSIMULACRA

if you say ssim2, people won't know what that means

Oh well that's different then

as there's other ssim variants, like dssim, ms-ssim, and ssimulacra, etc.

Ssim2 is a term that only ever gets used in the jxl community

as for the question about ssimulacra2, I don't know, might make sense to drop it in <#803645746661425173>

To refer to wb's new xyb ssim

I didn't know that it's also called ssimulacra

Or that it's the same thing

ssimulacra2 is the name of wb's new metric

it's not XYB-based

oh I lied

it is

Really? Then xyb ssim and ssim2 are different? Because I am pretty sure I heard him referring to them as if they are the same algo

Ah, so I am still not going crazy yet. That's good

ye I just checked the docs, it is

https://github.com/cloudinary/ssimulacra2

this

I like the WordArt™️

😄

so 1999

was wordart even a thing in 1999

I thought that was added in MS Word 2000

So it seems like a pretty big deal if you can’t use it to compare xyb codecs to rgb codecs

might be misremembering tho

And I heard that it unfairly penalizes xyb converted images with surprisingly low scores that do not correspond to what you would expect given how they look, that seems like something that would subvert the design goals and purpose of the algo

I'm curious if that's a minor fixable thing or a more fundamental flaw

What do you mean? The latest stable build of -turbo and mozjpeg are v6 by default afaik

But the distros explicitly compile everything v8

Arch does at least

Probably because some obscure packages need v8 headers to compile?

oh I see what you mean

Probably because they don't have any real reason not to

So they just switched libjpeg to be v8 by default with a libjpeg6 package for compat

until jpegli, there wasn't any reason to lock it into v6 api

I don't think anyone made v8 headers that map to v6 abi data structures

But I didn't look closely at the -turbo sources

No? We only ever say SSIM**U**2. 🙂

Ssimu2 can punish a lot color space conversions. The worst case I've seen was visually lossless image (jpeg --> avif --> png), but score around 82 due to very minor edge change. It's easy to test, we can make 2 jxl files, one lossless and one lossy, then compare original-lossless, original-lossy, lossless-lossy to see if it affects or not, and if yes, then how much.

what was used for colorspace conversion?

Avifenc and avifdec. I think it's less common for jpeg xl, but still if we take jpeg, losslessly transcode into jxl, but decode into png, very often it's still 93-94 ssimu score and not 100, because of color conversions.

I actually got curios if xyb has a similar situation or not.

I dont think it's color conversions unless avifenc is really bad at them, I would try ffmpeg for color conversion since that seems like a lot

try decoding to 16-bit png

`djxl --bits_per_sample 16`

to be clear, a ssimulacra2 score of 93 is pretty much visually lossless, in subjective testing we had visually lossless already around a score of 87 for most images

but quantizing image data to 8-bit does introduce some quantization error and even some banding, so it's normal that you don't get a perfect score

Not sure if I do something wrong. Jpeg --> jxl (transcode) --> jpeg gives me 100, but jpeg --> jxl (transcode) and jpeg --> jxl --> png give me 93.5 . Jpeg --> jxl with -q 100 is also 100, so maybe my decoder reads transcoded jxl differently.

is cjxl -q 95 means -d 0.5 or -d 1?

q90 is d1, I dunno about q95 but probably something like d0.5

Thanks

No, it means -d 0.55 <https://github.com/libjxl/libjxl/blob/1a7931e264854e35362d46d46e8462900980c923/tools/cjxl_main.cc#L629C1-L633C68>

OK, I calculated all distances from 100 to 0.

thanks, easier than calculating mentally every time

It also prints the distance when using `-v` even with a quality input (Should probably tweak the verbosity some more, see what people want most often)

so I got libjxl to at least compile now, however now I'm getting missing symbol issues not sure if where im messing up, but at least its progress in trying to get libjxl into media_kit

hmm I'm a bit lost, this is the updated cmake scripts I'm working with when I compile with these and build ffmpeg against them it builds, but libmpv will crash with undefined symbol errors ```ps cmake -B $build \ -GNinja \ -DCMAKE_TOOLCHAIN_FILE="$ANDROID_NDK_HOME"/build/cmake/android.toolchain.cmake \ -DANDROID_PLATFORM=21 \ -DANDROID_ABI=$cpu \ -DANDROID_NO_UNDEFINED=ON \ -DBUILD_SHARED_LIBS:BOOL=OFF \ -DJPEGXL_STATIC:BOOL=OFF \ -DJPEGXL_EMSCRIPTEN:BOOL=OFF \ -DCMAKE_BUILD_TYPE:STRING='Release' \ -DJPEGXL_ENABLE_BENCHMARK:BOOL=OFF \ -DJPEGXL_ENABLE_EXAMPLES:BOOL=OFF \ -DJPEGXL_ENABLE_FUZZERS:BOOL=OFF \ -DJPEGXL_ENABLE_PLUGINS:BOOL=OFF \ -DJPEGXL_ENABLE_VIEWERS:BOOL=OFF \ -DJPEGXL_FORCE_SYSTEM_BROTLI:BOOL=ON \ -DJPEGXL_BUNDLE_LIBPNG:BOOL=OFF \ -DJPEGXL_ENABLE_TOOLS:BOOL=OFF \ -DJPEGXL_ENABLE_JNI:BOOL=OFF \ -DJPEGXL_ENABLE_JPEGLI:BOOL=OFF \ -DJPEGXL_ENABLE_DOXYGEN:BOOL=OFF \ -DJPEGXL_ENABLE_MANPAGES:BOOL=OFF \ -DJPEGXL_ENABLE_SJPEG:BOOL=OFF \ -DJPEGXL_ENABLE_TRANSCODE_JPEG:BOOL=OFF \ -DBUILD_TESTING:BOOL=OFF \ -DCMAKE_PREFIX_PATH="$prefix_dir"/lib \ -DCMAKE_MODULE_PATH="$prefix_dir"/lib \ -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=BOTH \ -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=BOTH \ -DCMAKE_FIND_ROOT_PATH_MODE_PACKAGE=BOTH \ -Wno-dev ``` ```ps cmake -B $build \ -GNinja \ -DCMAKE_TOOLCHAIN_FILE="$ANDROID_NDK_HOME"/build/cmake/android.toolchain.cmake \ -DANDROID_PLATFORM=21 \ -DANDROID_ABI=$cpu \ -DCMAKE_BUILD_TYPE:STRING='Release' \ -DBUILD_SHARED_LIBS=OFF \ -DCMAKE_PREFIX_PATH="$prefix_dir"/lib \ -DANDROID_NO_UNDEFINED=ON \ -DCMAKE_POSITION_INDEPENDENT_CODE=ON ```

which undefined symbols?

just did a fresh rebuild of the pinned brotli commit after removing build folders, currently getting `java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_kBrotliPrefixCodeRanges"` and on brotli git it is `_kBrotliContextLookupTable`

finally think I found the issue https://hastebin.com/share/atowekexiz.bash had to pass `-Dc_link_args='-Wl,--no-undefined'` to mpv compile but it is what it is

I am so bloody stupid I forgot meson tries to link dynamic before static, well -Dprefer_static=true to mpv fixed it for me

PAM file from decode_progressive is this?: https://en.m.wikipedia.org/wiki/Netpbm#PAM_graphics_format Or something else?

it's that

That sounds normal since you are comparing the libjxl decoder with a different jpeg decoder, and different decoders can produce different output since there are multiple valid ways to decode jpeg

also jpeg -> png will not give you 100 — what you get depends on what jpeg decoder you use, and even if it's the same one as the one ssimulacra2 uses, it will not be 100 since converting a decoded jpeg sample values to integers (especially 8-bit integers) is a slightly lossy operation

Hi, do someone know how can a use .JPEGXL image with SDL_image, I had tried with IMG_Load and IMG_Load_RW but their are not working?

> Support for AVIF, JPEG-XL, TIFF, and WebP are not included by default because of the size of the decode libraries, but you can get them by running external/download.sh Maybe that helps

Hi <@238552565619359744>, thank you for your time, but I am in Windows with VScode and like and do not know the external/download.sh things. Like do you have a youtube tutorial or more detailed instructions?

And does libjxl have a link to make work the .jxl file?

https://github.com/libsdl-org/SDL_image

Yes I know it

But that what I am looking for how to make it work.

how are you building your program? msys?

With Makefile

This is the code ``` all: cls g++ -I src/include -L src/lib -o TestExp main.cpp -lmingw32 -lSDL2main -lSDL2 -lSDL2_image -lSDL2_ttf ./TestExp ```

are you doing this within a development environment such as msys?

No I am directly coding with VScode

for your sanity, I would *highly* reccomend trying to work with a development environment such as msys/mingw64, however if you choose not to, you will first need to figure out how to build SDL2, when you figure that out, you can link jxl by doing `-DSDL3IMAGE_JXL=ON` this will be a lot easier to do using mingw64/msys since it handles deps for you

I am using mingw64

It is in my path

It is with mingw64 that I can compile

im talking about the msys/mingw64 development environment

when launched you will get a unix like system / terminal

Ok but I want to stay with the way of the Makefile. What do you mean by build SDL2?

And where is located the -DSDL3IMAGE_JXL=ON and what I need to add to make it work after I put it ON

Looks like using statically linked prebuilt

<@288069412857315328> I do not understand what you said

I have no idea if any statically linked prebuilts with jxl exist

and besides learning how to do dep management will be immensly useful for any dev anyways so may as well get through it now

modern programs are like trees, where you rely on dependancies, and those dependencies have their own deps, SDL2 doesnt build jxl by default so that means you will need to rebuild SDL2 with support for it

the .dll file you got from somewhere instead of you making it right?

I highly reccomend watching/reading some msys introduction resources, plenty of good ones on youtube.

By rebuild, you mean create a new SDL2

Yes, from the github

correct, download the source code, then compile it yourself

the GitHub build might or might not have jxl enabled

I guess that error message is saying it isn't

So you either have to find another build that has it, or build your own

But this is on the CMakeLists.txt

You mean like with a Makefile

no, you will use CMAKE's buildsystem they already have up, all you will need to do is clone the source, compile and setup like that, however if you use msys, you can download a script that will be mostly already setup

But if I a put the JXL on what I need to do to make it work.

Like to I have to add a library

To be more clear, you have to compile the SDL source code to make that dll

Ok

but with that flag enabled

Ok

And do I need to put like something with it like a library, other code?

thankfully msys uses pkgbuilds for compilation and installation so it's significantly easier in that regard, packaging... well maybe not so much

I think sdl2 is setup statically though

probably, I haven't done it so I wouldn't know. I'm sure it'll complain to you while compiling

Another option is to ask someone here to do it for you.

basically inside msys, install libjxl, get sdl2 buildscript edit it minor edit, compile and install sdl2 using edited script, then compile program from within MSYS

I will do it my self but just like give a link to a tutorial

Can a do it without my MSYS?

sure, but it would probably be a lot more effort

Ok thank you for your help <@184373105588699137> and <@288069412857315328>, I will try to find something in the internet that is in link with what you said.

does anyone know how to get jpegli to work where it was previously libjpeg-turbo? `set(JPEGLI_LIBJPEG_LIBRARY_SOVERSION "8") set(JPEGLI_LIBJPEG_LIBRARY_VERSION "8.2.2")` These two are set but I keep getting

Is there a way to enable `JPEGXL_STATIC` in cmake without having to compile all the dependencies statically?

That is, can I have FORCE_SYSTEM_HWY on, so it'll dynamically link to system libraries like libpng, libhwy, etc, but builds libjxl itself as a static library and links cjxl and djxl to that static library?

otherwise, it'll attempt to statically link in /usr/lib/libhwy.so and that'll fail

on my system I can't build with JPEGXL_STATIC at all anyway, as it'll attempt to statically link in `/usr/lib/libtcmalloc.so`

but if I have `JPEGXL_STATIC` disabled, it'll link cjxl and djxl to my system libjxl, rather than the one built

which makes testing changes very hard, as I always have to LD_PRELOAD before calling djxl/cjxl

is there a way libjxl can tell me, for a recompressed JPEG file, how many bytes the original JPEG was, without decoding the whole file?

I don't think so. I don't think there is a way to do that without doing an actual decode.

ah, that's a shame but it does probably simplify my life

i'm working on a jxl-to-jpeg fuse filesystem, so i have to decode to jpeg in order to get the file size for `stat`. but at least doing that does cause the jpeg data to be cached, and it means i probably don't need to bother with progressive decoding (at least for a while)

I mean, we could make an option to add some metadata that tells you the original jpeg size, but there would be no guarantee that this metadata is present

probably unnecessary unless a bunch of other people complain about this specific thing

maybe i could cache the filesizes :galaxybrain: <:monkaMega:809252622900789269>

:galaxybrain:

discord isn't rendering only that emoji for some reason, whatever

if you have a fuse filesystem that losslessly stores JPEGs as JXLs then you should add that metadata when the original JPEG is written

<:GalaxyBrain:792908897010188328>

:GalaxyBrain:

true, but i'm making this read-only for now

well they didn't just poof there

even if it's like squashfs, it's still metadata you can encode at creation time

rn the way this would work is you batch convert a bunch of jpegs and then point my program at the directory with jxls

honestly i might keep it read-only just so that my coding mistakes can't cause data loss... i certainly at least want to get everything working for reading before i attempt any writing

i guess i could make a separate tool for this which also encodes the size metadata in some way?

meh that's a later problem

~~It is wrong approach, I believe. While decoding to pixels will give bit-identical images, decoding to jpeg will not give bit-identical *file*. And personally I would not be happy if my files are not identical to the before-archiving-ones, even if the data they carry is not changed.~~ I'm very sorry, have no idea where this point came to my head from

The point of jpeg transcoding is bit for bit file restoration

It does give bit-identical files, that's what the `jbrd` is for.

<@238552565619359744> <@794205442175402004> Thank you, IDK why I was thinking so 😔

Probably getting mixed up with *en*coding a new jpeg rather than *trans*coding back it

ok, now i'm coming around to the "in-memory cache of file sizes" option <:Thonk:805904896879493180>

No, I figured why I thought so, but it is so stupid.. Some time ago I wrote small script to convert my jpgs to jxl, but in order to achieve maximum compression it converts jpg to non-progressive, compresses both jpgs and chooses the smallest. And I forgot about this conversion step 🤦‍♂️

Huh, I thought progressive was pretty much always smaller anyway

In jpg - yes, but converted to jxl - not always, and if I remember correctly - most of times no

Interesting

do you mean encode as pixels to compare modular against vardct

When the jpeg coefficients are the same, the jxl codestream you get (from a given version of libjxl) will be the same — it doesn't know/care how the jpeg bitstream was organized.

The only difference is in the `jbrd`, which will be the most compact if it's a simple baseline jpeg. Progressive scan scripts take a bit more space to describe — though in any case the `jbrd` data should be quite small unless there's big APP markers or tail data or stuff like that — but then again you might be losing something if you remove those...

oooh, i just found the thread pool api, this looks very cool even if i probably won't use it right away

my favorite construction with tail data is embedding an entire mp3 file as tail data

which apparently is both a legal mp3 and a legal jpeg file

which one does `ffprobe` report it as?

(I would assume jpeg)

jpeg, but if you force the format to mp3 it reads it fine

here's the jpeg file, dunno if discord mangles it

looks like it does

download this and gunzip it

then `ffplay -f mp3 -i eggnog.jpg`

Discord strips a lot of things from image files and especially since aCropalypse

alternatively, `ffplay -f mp3 -i 'https://buzo.us/h.jpg'`

not much of a fan, is it

ffplay reads it tho <:kekw:808717074305122316>

it does analyse it in the end

all those errors are “recoverable”

I find it kinda silly that you can do this

the trailing mp3 data on a jpeg file is not that surprising

what surprises me is that mp3 demuxers can skip the leading JPEG and read it fine

mp3 file format itself isn't particularly well designed

I usually embed any existing mp3 files I have inside matroska since it's much better

do note, that mp3 is something that was posted as a free download by a youtuber, but it's not CC

jpeg is from wikimedia commons, it's CC

I don't mind redistributing stuff I obtained legally for free in a discord, but I wouldn't post it to a bug tracker for example

I don’t know about other people but as far as I’m concerned, the most likely fate for my copy of the file is that it’s going to sit untouched in my temporary directory until I finally clean it

I have `~/Downloads/` mounted as a tmpfs

so for me it cleans automatically on reboot. anything I want to keep I have to move out of it

That's a pretty smart move. I delete or move things from it pretty quick, but that would save me the trouble.

it's occasionally annoying if I'm downloading a massive file

since I have to download it elsewhere

but otherwise it's more convenient than it is inconvenient

I actually have two temporary directories: ~/Downloads on my SSD, and another one on my hard drive for larger files when I don’t want needless wear on the SSD

for example when I temporarily want to get an MKV out of a blu-ray disc dump

ohey I know how to do that :D

https://traneptora.com/articles/ffmpeg/#remuxing-bdmv

#shameless plug

I’ve been using MakeMKV for that

hm

so it appears that if I create a libjxl decoder instance with the library

and decode a color image, and then later on decode a grayscale image

it'll whine that the pixel format requested has a number of channels too low for color output

despite it being a grayscale image

``` if (format->num_channels < 3 && !dec->image_metadata.color_encoding.IsGray()) { return JXL_API_ERROR("Number of channels is too low for color output"); } ```

it is a grayscale image

this only occurs *after* I decode a color image first tho

ah, nvm it's my own bug

I wasn't setting jxl_color.color_space correctly

e3 d0 ```ps Benchmark 1: cjxl -e 3 -d 0 mona.png jxl-test/mona-3-0.jxl Time (mean ± σ): 3.040 s ± 0.021 s [User: 11.210 s, System: 4.110 s] Range (min … max): 3.017 s … 3.085 s 10 runs Benchmark 2: LD_PRELOAD=/usr/lib/libmimalloc.so cjxl -e 3 -d 0 mona.png jxl-test/mona-3-0.jxl Time (mean ± σ): 3.143 s ± 0.093 s [User: 11.496 s, System: 3.864 s] Range (min … max): 3.049 s … 3.315 s 10 runs Summary cjxl -e 3 -d 0 mona.png jxl-test/mona-3-0.jxl ran 1.03 ± 0.03 times faster than LD_PRELOAD=/usr/lib/libmimalloc.so cjxl -e 3 -d 0 mona.png jxl-test/mona-3-0.jxl ``` e7 d3 ```ps Benchmark 1: cjxl -e 7 -d 3 mona.png jxl-test/mona-7-3.jxl Time (mean ± σ): 11.214 s ± 0.155 s [User: 24.355 s, System: 6.418 s] Range (min … max): 10.833 s … 11.386 s 10 runs Benchmark 2: LD_PRELOAD=/usr/lib/libmimalloc.so cjxl -e 7 -d 3 mona.png jxl-test/mona-7-3.jxl Time (mean ± σ): 11.586 s ± 0.113 s [User: 25.009 s, System: 6.925 s] Range (min … max): 11.434 s … 11.751 s 10 runs Summary cjxl -e 7 -d 3 mona.png jxl-test/mona-7-3.jxl ran 1.03 ± 0.02 times faster than LD_PRELOAD=/usr/lib/libmimalloc.so cjxl -e 7 -d 3 mona.png jxl-test/mona-7-3.jxl ```

<@794205442175402004> seems like mimalloc is actually a pretty very minor consistent net loss

ill try jemalloc I guess

seems like jemalloc seems to be the same

interesting — I guess encoding is doing more allocs (and with more variable sizes, more via std::vector than in the decoding where most allocs are for per-group fixed-size stuff) which might be trickier to perf-optimize dynamically

I understood you use, or used, skcms as a color management system, but google returns no result for it. What project is it?

It's part of skia I guess?

https://skia.googlesource.com/skcms/

Thank you!

Hi y'all, my codebase is building libjxl from a random commit sometime after `0.6.1`. I tried migrating to `0.7.0` but I keep getting this error ```wasm-ld: /b/s/w/ir/cache/builder/emscripten-releases/llvm-project/llvm/include/llvm/Support/Casting.h:104: static bool llvm::isa_impl_cl<lld::wasm::DefinedGlobal, const lld::wasm::GlobalSymbol *>::doit(const From *) [To = lld::wasm::DefinedGlobal, From = const lld::wasm::GlobalSymbol *]: Assertion `Val && "isa<> used on a null pointer"' failed.```

It looks to be an emscripten/llvm error but I'm not entirely sure

I'm trying different commits between the original one (9f54464) and `0.7.0` to see where this error starts appearing, but hopefully there's a better solution? 😅

Fixed it! Commit `ef97fe0` sets the environment node version to 18. Updating node fixed the issue for me lol.

The encoder cannot process files if the name or path contains some characters. For example, the letter "é" from the French word "Février". No error messages appear, it just silently skips such files.

it is something that we should ideally fix but I am not sure of the “right way” to do that in a cross-platform manner

I am tempted to assume this is on Windows?

Does `fopen(argv[i]` not work on Windows if there are non-ascii characters involved?

there are two components to this: how it is passed to us in `argv[i]`, and how `fopen` then interprets this

I am not sure of the former

regarding the latter, I suspect that the argument is interpreted as being in the current codepage

maybe adding a manifest to our executables to use the new “utf8” locale would work and let us not have to change any code

https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page#set-a-process-code-page-to-utf-8

Yes, Win 10 English.

I'm assuming something either reads utf8 as cpSomething or the other way round

Telling it to always do utf8 would be ideal xD

Win10 uses UTF-16 by default for NTFS

which, as it's incompatible with ASCII, has some conversion going on between ASCII and UTF-16

It doesn't just compare requested filename with the filename in the inode tree byte-for-byte, because if so requesting an ASCII filename would never work

Contrast this behavior with POSIX systems where there's no character conversion done at the libc level.

Since most POSIX systems use UTF-8 to store filenames, ASCII filenames are automatically forward-compatible.

As a result, Windows has `FILE *_wfopen(const wchar_t *filename, const wchar_t *mode)`

https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen?view=msvc-170#remarks

that was indeed my impression, but then what does that mean for `argv[i]`? shouldn’t it also end up passed to us from the command line in the current codepage?

I mean, in such a way that when `fopen` converts back to UTF-16 for comparison, it does find the file

I don't know how Codepage in windows interacts with argv

I kind of fear it might even be runtime-dependent (as in, e.g. msvcrt vs. mingw)

from what I understand, on windows, splitting the command-line arguments, parsing the globs and so on is not the shell’s responsibility, it’s that of the process, which receives the command line in one chunk

then, the C runtime does the splitting into argv

https://zetcode.com/gui/winapi/main/

(rust, but still illustrates the point) https://github.com/rust-lang/rust/issues/44650

Does JXL support pure single threading when building with emscripten? I can't seem to build without passing the `-pthread` flag even for the JXLDecoder API (version 0.7)

https://github.com/libjxl/libjxl/blob/main/CMakeLists.txt#L290 implies that `-pthread` is enabled for all JXL builds when Emscripten is detected

AIUI, if you export wmain, your wchar_t *argv[] will be utf-16. if you export main, libc will convert argv based on the active code page. therefore, if you set the active code page to utf-8, you should get argv in utf-8 like every other platform

BtbN is reporting that libjxl is failing to build in the buildscripts for win32

but not on win64

likely sometime between c3a4f9ca89ae59c6265a2f1bf2a6d2a87a71fc16 and 06ce6cb513c442bfe9a0a9ad7df0d6d5f17dc07d

https://gist.github.com/BtbN/6a8ec61a5d1958e6092c96e6d02653e7

hm, looks like it's a regression in Highway

It was fixed, however

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

This fails with `-DVCPKG_TARGET_TRIPLET=x64-windows-static` option passed to CMake when vcpkg is used to pull in libjxl.

can you provide a log? it "failing" by itself isn't particularly helpful info

```[main] Building folder: jxl-vcpkg-test [build] Starting build [proc] Executing command: "C:\Program Files\CMake\bin\cmake.EXE" --build c:/Users/wahil/jxl-vcpkg-test/build --config Debug --target ALL_BUILD -j 10 -- [build] MSBuild version 17.7.2+d6990bcfa for .NET Framework [build] [build] main.cpp [build] LINK : fatal error LNK1104: cannot open file 'jxl.lib' [C:\Users\wahil\jxl-vcpkg-test\build\main.vcxproj] [proc] The command: "C:\Program Files\CMake\bin\cmake.EXE" --build c:/Users/wahil/jxl-vcpkg-test/build --config Debug --target ALL_BUILD -j 10 -- exited with code: 1 [driver] Build completed: 00:00:00.969 [build] Build finished with exit code 1```

> `[proc] The command: "C:\Program Files\CMake\bin\cmake.EXE" --build c:/Users/wahil/jxl-vcpkg-test/build --config Debug --target ALL_BUILD -j 10 -- exited with code: 1`

what happens if you just run this command

in the CLI

it just means libjxl failed to be built, but doesn't really say why

Same error.

DLL-built libjxl builds work fine.

Not sure how vcpkg is failing here on the static pkg-config one vs. the DLL-built copy, but it may be a lead.

well I presume if you just run that command as-is it produces some output

but it's not?

It's exactly the same error.

1:1.

well cmake output doesn't look like that

so I'm sure that's not what happened

what happens if you open up command prompt and just put in: `"C:\Program Files\CMake\bin\cmake.EXE" --build c:/Users/wahil/jxl-vcpkg-test/build --config Debug --target ALL_BUILD -j 10`

and push enter

```C:\Users\wahil\jxl-vcpkg-test>"C:\Program Files\CMake\bin\cmake.EXE" --build c:/Users/wahil/jxl-vcpkg-test/build --config Debug --target ALL_BUILD -j 10 MSBuild version 17.7.2+d6990bcfa for .NET Framework LINK : fatal error LNK1104: cannot open file 'jxl.lib' [C:\Users\wahil\jxl-vcpkg-test\build\main.vcxproj]```

looks like the static library just isn't being built, which means vcpkg configured something incorrectly

you'd have to take that up with vcpkg

you can always build libjxl directly or install it with pacman on msys

It IS built, the library exists, but with `-static` appended to their names.

looks like vcpkg has a broken cmake configuration then

I mean I'd prefer for a CMake package solution from libjxl itself.

To make it easier to use on Windows.

I managed to get to the root of the problem. The pkgconfig files are hardcoded to always assume shared library linking and `m` library presence, and this: `Libs: "-L${libdir}" -ljxl -lm` should be replaced with:

`Libs: "-L${libdir}" -ljxl-static -lm`

And the `-lm` part stripped off on MSVC.

https://github.com/libjxl/libjxl/pull/2754

Uh is there any reason why libjxl's decoder is around 5.4MB when linked with statically? That size doesn't looks very comfortable.

it seems like someone was assigned to the issue page you posted on the vcpkg repo and has a draft pull request up, bringing this up since i'm unsure if the two conflict at all or are trying to solve the same problem https://github.com/microsoft/vcpkg/pull/33422

That one uses suffixing.

And is not complete because it still attempts linking with non-existent math library.

I need to explore compiling libjxl without RTTI and exceptions next, since those do not appear to be needed.

I think there was a discussion in this server at some point about the decoder's compiled size although I don't remember much but maybe <@794205442175402004> or someone else would be able to comment about this? Looking at some older messages in the server it seems like the decoder can be around 197 KiB in compiled form possibly? although this is what was reported for google chrome on android so idk how comparable it is.

libwebp for instance weighs way less than libjxl on static builds.

And on an objective assessment.

It depends a lot on how many SIMD targets you compile for

Also: debug builds will be larger than release builds

Well the release static libraries take up 5.4MB of space with default vcpkg configuration on final executable.