JPEG XL

Squoosh includes jxl support: https://squoosh.app/

ImageMagick supports jxl since version 7.0.10-54: https://imagemagick.org/

https://www.reddit.com/r/jpegxl/comments/l4nwb2/how_to_view_jpeg_xl_images_in_nomacs_for_windows/

Instructions how to get JPEG XL for all QT stuff on Linux: https://github.com/novomesk/qt-jpegxl-image-plugin After that, you will be able to view your pictures, have thumbnails generated, and even capture JXL screenshots.

How to get nomacs on Windows to decode JPEG-XL images natively: https://old.reddit.com/r/jpegxl/comments/l4nwb2/how_to_view_jpeg_xl_images_in_nomacs_for_windows/

macOS JXL viewer + QuickLook plugin https://github.com/yllan/JXLook

Thumbnail handler for Windows File Explorer: https://github.com/saschanaz/jxl-winthumb

https://jeremylee.sh/bin.html

https://github.com/mirillis151/jpegxl-wic

Cool, so that'll help with windows

Yeah, this will help a lot with the adoption on windows

i don't understant "according value is added to your PATH environment variable" What folder need to be in the PATH?

the readme is incomprehensible for non dev.

Probably because these aren't non-dev instructions, but how to compile it manually and have it install afterwards. I'd imagine binary releases will be available sooner or later.

The easy part is putting stuff in yout path. The hard stuff is everything else.

I remember when I was 11 or 12 and got my hands on a Java book (1.2 iirc)

it said to install the JDK, and then to run “javac foo.java”

without explaining the required “add to PATH” step in between

so it didn’t work for me and I gave up (and learned C++ instead)

Which was a good thing in retrospec.

Honestly, I like C/C++.

first learned Basic ("wow I can make a computer do things"), then C ("wow I can make a computer do things quickly!"), then Java ("wow a language with some helpful abstractions and standard routine"), then C++ ("wow, that, but fast!")

Python, then C

Fun, stuff. But more faster language is used for matrix GUI app -> worse it is

C++ have icons and button misalign, bare bone functionality. Rust is ugly as hell because gtk+. JS is nice, a lot of features, etc

I learned C from a book that was printed before I was born.

I started with Commodore Basic, then GW Basic and QuickBasic, then TurboPascal, PPL, C, C++, PHP, Perl, Java, Prolog, Haskell, [series of weird academic declarative languages you never heard of], and now just C++

GWBasic, QBasic, QuickBasic, Visual Basic 3, 5, 6; Perl, C, Java, PHP, Prolog, Haskell, [series of weird academic declarative languages you never heard of, except you, <@!794205442175402004>], C++, Python.

Ah yes, QBasic was the stripped down version of QuickBasic, right? Without compiler, only interpreter iirc.

Yes. But I learned about QBasic before QuickBasic (or even the existence of a "compiler")

Same. QBasic shipped with DOS iirc

GWBasic I learned maybe around 1994. QuickBasic I got from Pater Leo, who I believe you know. Maybe in 1996 or 1997.

QBasic was somewhere in between.

Haha, Father Leo, Latin teacher. Yes. I once made a RPG/adventure game set in that school. Text based, written in really ugly QuickBasic spaghetti

Apparently he died in 2019.

To anyone confused here, <@794205442175402004> and I went to the same school (but didn't know each other there), and later became colleagues.

<@!799692065771749416> <@!794205442175402004> I'm betting I've heard at least *one* of these academic declarative languages 😄

Pretty sure I even pass posters explaining one of them daily (well, before the Covid-19 pandemic lockdown obviously)

CHR probably?

*ding ding*

And probably at least one of you learned Mercury as well 🙂

yes

<https://github.com/novomesk/qt-jpegxl-image-plugin/commit/9af0185382957c99e58455af940f14f88784c18e> `Adjust for new encoding API` <:Hypers:808826266060193874>

Yeah, that fixed the compile bug I had yesterday.

When i compile with the new commit i have: `-- CMAKE_SYSTEM_PROCESSOR is x86_64 -- tcmalloc version -- tcmalloc 2.8.0 disabled due to https://github.com/gperftools/gperftools/issues/1204 CMake Error at CMakeLists.txt:127 (message): Different C/C++ compilers set: GNU vs Clang` I'm a noob, i do this command: export CC=clang-7 CXX=clang++-7 What i need to do in debian to correct that? 🥺

I never learned Mercury.

Yeah, I wasn't sure whether it was the engineering or Informatica students who had to learn that as well in the declarative languages course :). I remember studying it when I had to TA the course 😂

I think in Declarative Languages we only had Haskell and Prolog (and maybe one course about something else, I'm not sure).

Anyone else have trouble compiling the latest version of the qt-jpeg-xl plugin?

I get this:

It compiles fine here

https://openbenchmarking.org/test/pts/jpegxl&eval=38154180e2f8902493961238685d09b5b503d8ff#metrics

has anyone jpeg xl 0.3.1 without compiling anything on linux? ah that's probably adoption and not tools

Yes, <@111445179587624960> on encode.us

For windows

as far i understood there is only gwenview and another program for screenshots master of zen used who still needs the codec compiled or has old version (older than 0.3.0) so it doesn't count and i don't think you can can change an executable like 0.3.0 or -s 4 -q 99.2. anyway is old version older than 0.3.0. Windows with jxl winthumb the new release it uses only one core. at the moment you need the cmd to encode like i made for %i in (D:\Immagini\Screen\screendecember\*.png) do cjxl "%i" "%i.jxl" -s 4 -q 99.2 --num_threads=2 there is a \ before *PNG

but maintaining all colors or most colors isn't worth it and i think neither near lossless as it had grooves in the image before 0.2.0 got released

<@456226577798135808> i see you compiled jxl encoder with mingw64, can you help me to do the same? I don't understant what cmake param i need to use to compile it for windows.

I didn't, that was Scope's build. https://encode.su/threads/3564-JXL-version-0-3-released?p=68594&viewfull=1#post68594

Ah ok, i did not see it thank you. Somebody have a link to explain how to cross compile with cmake? google is not my friend :/

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

https://twitter.com/phoronix/status/1360596837070213122

But, there are still no lossless modes and I have the same suggestions (developers may have their opinion): - adding lossless modes (at least with default encoding speeds and some of the faster `-s 3` or `-s 5`, depending on which is more tuned and planned for practical use) - decoding speed for default lossy and lossless modes - Jpeg recompression speed comparison is not that important practically since it is fast enough or at least leave only one default speed mode, but it would be better to add fast lossless and lossy modes instead - use the same test image/images as for AVIF and WebP2

Agreed with the above

https://openbenchmarking.org/test/pts/jpegxl-decode

Hmm, although WebP2 has lossless mode tests

is there a viewer that properly implements animation already?

gwenview

Yeah, gwenview QT on Linux seems to support proper JXL animations with the QT JXL plugin.

drop me jxl animation example?

works

no animation on pixbuf

Also doesn't work in Nomacs (windows)

Is there a list of tools supporting jxl somewhere? (apart from upthread, that is)

Not afaik, at some point I want to put one on my jxl website but haven't done it yet

If someone can summarize the most significant tools (and the ones that are not stuck in an old libjxl), that would be useful

<@!794205442175402004> is butteraugli no longer in maintenance? https://github.com/google/butteraugli/pulls Pull requests from 2+ years ago are not merged

there's a butteraugli in libjxl

I don't know if the standalone butteraugli is still maintained

Ability to use it for video, building videos out of heatmaps, that's would be amazing

I think people are already experimenting with butteraugli-optimized av1

my understanding is that jxl butteraugli is preferred

it has the butteraugli_main binary too

or maybe only if enabling the dev tools? I don’t remember

but it doesn’t take motion into account, which would be desirable for video

so for video, at the moment, it would really only be applicable to the use case of pausing the video to look at an individual frame from it

could probably just weigh everything by the amount of motion happening in that part of the frame with some simple heuristic

there is niche for high fidelity metrics in video encoding

So far "best" video metric is VMAF, and it quite forgivable in terms of being true to the source, and focus on preserving appeal

I've added a new section "Software" to the "JPEG XL" article on English Wikipedia (translated from "JPEG XL" on Czech Wikipedia, also by me). I think this could be a good public list of JXL tools.

citing online media converter and tools that break windows or are unofficial for Microsoft even if you're tempted by Linux you shouldn't make it shown

the article is about jpeg xl not linux

someone from jpeg itu will delete what you wrote the same

Anyone uses "Mirillis Action!" screen recorder? It reportedly now supports JXL for screenshots. https://www.neowin.net/news/mirillis-action-4160/

For screenshots I use spectacle, and with qt jxl plugin it support making jxl screenshots

https://gitlab.com/wg1/jpeg-xl/-/blob/945ad0ce4262382f850bea3f5cc51ca5cc2a40a2/plugins/gdk-pixbuf/pixbufloader-jxl.c#L276 this should probably be just "jxl", not "JPEG XL". I think. as it currently sticks out compared to other loaders

good point. The media type is `image/jxl` so it does indeed make sense to use `jxl` there

Would anyone be interested in making a "mozjpegxl" tool? I'm not talking about a new jxl encoder, but something simpler: just a tool that encodes an image to jpeg with mozjpeg, then recompresses the jpeg to jxl with cjxl. As a starting point, it could be as simple as a git repo with two subrepos (one for mozjpeg, one for libjxl) and a two-line bash script. It could later be extended into something more complicated (a single cli tool that doesn't write the intermediate jpeg and directly does pixels to jxl).

I don't think this requires a special tool when it can be done by a simple script (and it will also extend the life of a Jpeg even further)

And for what purposes, for comparisons or to quickly convert back to legacy Jpeg for clients who do not support it? But I think that if the source image is available, it would be better to directly convert to jxl (and if necessary convert to legacy jpeg, even if it is not lossless recompression)

Have to agree with Scope. It is easy enough to pass a jpg into mozjpg then pass the output file into cjxl with a script. Not sure there needs to be a separate tool. Also, mozjpegxl would probably be confused as a mozjxl by many thinking it will compress a jxl more like mozjpeg.

But it might be good to have MozJpeg in JXL by default instead of LibJpeg

Not sure about that, I think mozjpeg drops all metadata and that might not be what people want... Or maybe have a specific need for following the standard (maybe using older software). Also, I think you can define which jpg encoder it uses when you compile as long as it is compatible with libjpeg. I believe mozjpeg can be used in place of libjpeg. Correct me if I'm wrong.

Yep, although sjpeg (which can be used in JXL) is also not very different in quality

And about MozJpeg (or rather jpegtran): ```-copy none Copy no extra markers from source file. This setting suppresses all comments and other metadata in the source file. -copy comments Copy only comment markers. This setting copies comments from the source file but discards any other metadata. -copy all Copy all extra markers. This setting preserves miscellaneous markers found in the source file, such as JFIF thumbnails, Exif data, and Photoshop settings. In some files, these extra markers can be sizable. Note that this option will copy thumbnails as-is; they will not be transformed.```

It would be just to have a convenient way to make jxls that can be converted to legacy jpegs if needed, which is indeed kind of trivial but maybe there are things that can be done to make it better than the simple two-line script.

E.g. maybe there are mozjpeg options that turn out to result in jpegs that compress better with jxl

or maybe you want to pre-process the input image to convert it to a particular color space (e.g. Display P3) and save some bytes on the icc compression

for instance, you'd probably want to make mozjpeg do 4:4:4, since jxl compression is better for 4:4:4 jpegs than for 4:2:0 jpegs

and you'd probably want to disable any huffman optimization or progressive scans, because that will just make the jpeg reconstruction data larger, mozjpeg slower, and does not have an effect on the main jxl file

though if you also care about the size of the legacy jpeg, you may want to do that after all — so the tool may have different settings depending on if you want to optimize mostly the jxl or mostly the jpeg

I've been experimenting with running jpegultrascan (https://github.com/MegaByte/jpegultrascan/blob/master/jpegultrascan.md) on JPEG files before transcoding to JXL, which sometimes results in smaller JXL files (although your milage may vary: sometimes they're bigger!).

If it's a lossless jpeg recompressor, it can only affect the jpeg reconstruction data, not the actual jxl codestream

In the next version there will be a `--strip` option to just remove the jpeg reconstruction data and any metadata, so you get a containerless jxl. Still the exact same image data, but you cannot convert back to the exact original jpeg file anymore (but you could in principle convert to a different one that has an identical image)

What would be the advantage of such a method?

Slightly higher efficiency?

Yes, it is more costly to save the exact same Jpeg than just the same pixels

Could also be used for things like social media or photo sharing/storage services to remove metadata to prevent you from accidentally sharing a photo with your location information embedded in it.

If there's no metadata, the difference is small, just a few hundred bytes or so

Someday I think it is possible to add something like `--optimize` in addition to `--strip`, for more efficient JXL compression, instead of using MozJpeg before that (if the exact same Jpeg isn't needed)

You mean still use only jpeg-compatible encoding, but do a new one from pixels?

If jpeg-compatible is not needed, you can do `-j`

To get a pixel-by-pixel match, but not a byte-by-byte in a decoded Jpeg

Not really sure why jpeg-compatible will ever really be needed. I mean, we'll just have jxl for the next couple decades before finally converting them to JPEG 2040 (whatever that will be called). Not sure what the reason for converting back to jpeg will be.

Legacy applications that cannot be upgraded to jxl would be a reason...

That's what --strip will do. The data itself (dct coeffs) are always optimized.

Oh, okay, then that's what I mean

I actually like byte-by-byte equal mode. Having a way to get exactly same file opens up possibilities of more efficient storage for systems which use hashes for addressing files (in some cases but not others).

Would've been cool to have something like that for PNG -> JXL modular case but I guess that's asking a bit too much

For Jpeg this is how it works now in JXL, for PNG I think this is a much more rarely needed thing, although it is possible to hash the decoded PNG after JXL and it will be exactly the same (well, unless the encoding in libpng/lodepng is changed)

That would only work if the PNG was created with the same encoder/encode settings as whatever djxl does

There are way more ways to encode pixels as a PNG than there are ways to decode dct coefficients as a JPEG

really?

oh, i guess zlib itself adds a ton

Yes

JPEG is just huffman so if you know the huffman table it is deterministic

(you still need the scan script etc, but that's a small amount of info)

PNG is lz77 matching, which can be done in many ways

png i guess is the transformation on the pixel data, the metadata chunks... but then lz77

(there's also the per-row predictor, but that's a small amount of info)

lz77 is the main problem, some png optimizers spend a lot of time in finding good matches

you could make a png recompressor dat only guaranteed identical pre-lz77 bytes, but that's not as fun

We kind of already have that (well minus the chunk order)

kind of an interesting question, what metadata you need to reconstruct various compressed formatd

https://github.com/google/grittibanzli one could use that as metadata, I guess 🙂

What? Lode actually did that already? Lol I did not know that

Then we have the main thing needed for a `pbrd` box, I think. Just need to record some other png-specific things like the pixel format, palette, chunk order, interlacing, non-image-chunks, and predictors per row.

Very low priority, but if there's a use case, we could do lossless png bitstream compression

we could name it “PNG XS” for maximum confusion

call it PNG (short for __p__ng __n__ext-__g__en)

JPNG (__J__XL __PNG__) - confusion with JPG and PNG at the same time

JPNG XL

`.jpxl`

The concept of "[format] bitstream reconstruction data" is nice. For PNG I don't think it's particularly useful, but we could also do it for PSD, TIFF and XCF. It gets a bit trickier (probably would do layers as jxl sub-bitstreams in the reconstruction data, and only encode the merged image in the jxl itself, unless all layers do normal blending without layer fx, then you don't really need a separate merged image)

Properly compressed PSD/XCF that also just works in browsers would be pretty great. PSD compression is so weak (basically RLE only) that huge savings would be possible, and you could even do it near-lossless for the pixel data in many use cases, saving even more bytes.

https://ci.appveyor.com/project/novomesk/qt-jpegxl-image-plugin/builds/38248446/artifacts

Cool! Which apps can use it?

All qt-based, for example nomacs https://ci.appveyor.com/project/diemmarkus/nomacs/build/artifacts

Seems that also XnView MP can use it. Great!

I feel like i've been asking this every month but are there windows builds of the latest cjxl somewhere ?

i'm sure you could make your own with msys

https://discordapp.com/channels/794206087879852103/794206170445119489/821360934919602176, today message

They don't support avx2 for some reason when I build it mysalf

There is a bug in the GCC compiler on Windows (but Clang is fine)

how

when xnview had jpeg xl 0.1.0

i could get work libjxl 0.2.0

how you did?

with new build

now they work re troactively?

XnView (latest version) had jpeg xl 0.3, where did you get 0.1?

XnView MP uses Qt, so it should be able…

I installed it, but have no idea if it's working. It already has 0.3 so I don't know if it's using that or the plugin. I don't see any way of identifying which is being used.

Does anyone use AppVeyor? (https://www.appveyor.com)

I found it when searching for AV1 binaries for Windows: https://ci.appveyor.com/project/marcomsousa/build-aom/build/artifacts

I guess it could be used to build libjxl and thus provide a **reliable** and **stable** place for downloading binaries.

It would look more attractively for users than searching through threads on encode.su.

And if I'm correct, the builds would be available soon after releasing new versions of libjxl (unlike https://jeremylee.sh/bin.html).

Not only libjxl could use it. Also JPEG XL WIC and other tools.

MozJPEG uses it, too.

This is just a kind of virtual machine, it still requires scripts and the proper environment to compile, as well as manually checking for any changes that might break the build

OK. I was just asking to find out whether it could ease lives of both the developers and the users…

At some point we're going to move development to a public github repo (instead of the current private repo), and I hope that besides the various builds for CI, we can also automate some builds for releases. It would mostly be useful for Windows and MacOS, I suppose. For GNU/Linux it's more convenient to get it in the major distros, and for platforms like iOS/Android/exotic stuff, the target audience will probably know how to compile things.

Yeah I don't have an automatic build thing, its just when I feel like clicking on it

what is the laguage of squoosh

web assembly

web asm

can you write in the right way

WebAssembly

If you configured it to do the build with just one click then it's a pretty high level of automation. 👍

Yeah but its cheating https://github.com/m-ab-s/media-autobuild_suite

who needs clicking? 😄 just a few command (in my history) here... then again, I'm a dev xD

<:galaxybrain:821831336372338729>

m-ab-s also needs some changes for Jpeg XL, but I think it would be better to wait until GCC 11 release and then write all the requests

As long as it doesn't harm anyone, such cheating is welcome and appreciated. 🙂

It would be cool to have a simple way to do wasm-based jxl decoding to include some jxl images on a web page, as a demo. Does anyone know enough about js/wasm to do that?

I know squoosh.app does it, so it shouldn't be *too* hard...

(for example by copying whatever they do 😛)

And here http://libwebpjs.appspot.com/jpegxl/ (but it's a very old version) > Jan 3: *.jxl images can add as input for decoding

i have compiled c++ code to wasm in the past

Probably wouldn't be too hard to take how some of the polyfills for previous image formats work and mash in the wasm files from Squoosh to build browser support.

from the quick look I gave, it seems to work drawing on a canvas - so not quite a native experience

then again, likely not too hard to convert img src=*jxl into a canvas

Either that or the AVIF polyfill converts the decoded pixels into a BMP and feeds it into an img tag.

Using canvas would likely work better since you can detect when they try to download the image and feed in the JXL data so it has more native feel. I don't think that can be done through an img tag.

Squoosh is a rather big project and it uses fancy build tools I don't know. I am quite lousy at keeping up with frontend things. <@!710762823986446367> <@!228116142185512960> how hard would it be to make something that loads some jxl decoder js/wasm code and then I can write something like ``` <canvas data-jxl-src="bla.jxl"></canvas> ``` and it works?

Check out https://github.com/jakearchibald/jakearchibald.com/blob/main/shared/demos/2020/avif-has-landed/DecodedImg/index.tsx which I wrote for the AVIF post on my blog

That's a nice website

I am an absolute noob. How do I turn that into a `.js` I can use on a webpage?

looks like a JSX file written in typescript. double ew

you could copy/paste it into https://babeljs.io/repl

then check the React and TypeScript boxes, but I'm pretty sure it only outputs to ES5

so you'd probably be better off just going from TSX to JSX to attempt to make it more readable. but it would still require react or preact to run it anyway

If it's on npm, you can use skypack and let it handle all the transpiling complexity for you

https://www.skypack.dev/

Ohh wait nevermind, if I'm understanding correctly that DecodedImage index.tsx is meant to be used as a Preact component, not as a standard JS polyfill on a webpage

yep, it's a meta-language wrapped in a meta-language

Look like XnView MP 0.98.2 64bits (Feb 19 2021) jxl decoder break again, some jxl file will decode fail(black rectangle) and display wrong bit depth(8bit => 48bit), nomacs can success decode jxl file.

Hey guys. Can anyone share the latest cjxl.exe with input jpg support?

https://jeremylee.sh/bin.html

`INPUT the input can be PNG, PPM, PFM, or PGX` `Failed to read image 0.jpg`

let me test

oh you have right wait

https://encode.su/attachment.php?attachmentid=8418&d=1617022583

Thanks, but is there any chance to get at least avx build? Can't run it on my Ivy Bridge. Sorry for bother you 😄

you can try to build it, you can use mingw

Ok, I'll try

or more automatic

media autobuild_suite

Why would anyone build libjxl without jpg support in the first place? 😲

I think for a dependency issue

but it's not disabled

it fail to read jpeg

I am aware

But I have no idea why

I have built 0.3.7 using mas. JPEG support is present. 😄 `INPUT the input can be PNG, APNG, GIF, JPEG, PPM, PFM, or PGX`

I'm so tired of this

I can't even check if I can make it work

rm -r from powershell

even powershell crashes

I'll have to reboot

so next week lmao

Try fastcopy or robocopy?

Delete permanently

-i -g

If I want to achieve the maximum compression level for lossless jpeg transcoding, all I have is “-s 9”, right? No more tricks to reduce file size without sacrificing original quality?

There are probably things that could be done to slightly improve the AC ctx modeling and the DC encoding in JPEG recompression.

Like doing -E 3 for the DC (but I guess cjxl will not pass that option to the right place atm)

you said that even 30% is achievable

No, I don't think I said that, and I don't think it's achievable

This is quite impressive result 😄 ` J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: SSE4,Scalar] Read 4077x3978 image, 56.4 MP/s Encoding [Container | JPEG, lossless transcode, squirrel | JPEG reconstruction data], 4 threads. Encoding [Container | JPEG, lossless transcode, kitten | JPEG reconstruction data], 4 threads. Encoding [Container | JPEG, lossless transcode, tortoise | JPEG reconstruction data], 4 threads. Name Size_bytes Ratio ---- ---------- ----- 0.jpg 24582566 100 7.jxl 15095192 61,41 8.jxl 15097305 61,41 9.jxl 13352148 54,32` Image from here https://3dnews.ru/assets/external/illustrations/2021/04/05/1036515/gal1.jpg

https://c.tenor.com/wEtLAbx6hSAAAAAM/snoop-dog-dance.gif

Keeping in mind that JPEG isn't optimized to begin with. mozjpeg gets it down to 17.9 MB.

Yeah, I know that 😊

With jpegtran?

With Leanify we can go even further `PS > .\leanify gal1.jpg Processing: gal1.jpg 23.44 MB -> 17.08 MB Leanified: 6.36 MB (27.14%) PS > cjxl gal1.jpg 2.jxl -s 9 J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: SSE4,Scalar] Read 4077x3978 image, 28.5 MP/s Encoding [Container | JPEG, lossless transcode, tortoise | JPEG reconstruction data], 4 threads. Compressed to **13351568** bytes (6.586 bpp). 4077 x 3978, 0.08 MP/s [0.08, 0.08], 1 reps, 4 threads.`

Yes, that's what I meant.

leanify is displaying the size in mebibytes, the savings are equivalent with mozjpeg's jpegtran.

If you're just referring to the jxl size, well, stripping metadata likely helped.

Suggestion: make `jxl_merge` tool. Takes multiple .jxl files and merges them into one multi-layer, single-page .jxl image, to keep this tool simple. (Optionally with `jxl_split` tool which does the exact reverse of the first one.)

Are there any cjxl options that can significantly reduce RAM consumption for lossless modular encoding?

Looking through the code, it's not obvious that anything exposed to the command line should make a significant difference besides speed/effort.

this is kind of a joke but is a `tree_from_jxl` tool possible? would it have any use?

i don't see why not

it'd probably only work for jxl files actually created through jxl_from_tree though

you think it would work on a regular modular jxl or nah?

probably not

well regular jxl can have tons of features that can't be represented in the jxl_from_tree format (actual pixels that differ from the prediction being the most obvious one...)

might be an interesting feature to convert a regular modular jxl to just the prediction

or not, but I assume it would look interesting at the very least

i guess just a way to show the MA tree (in jxl_from_tree format) would be interesting on its own, even if it can't exactly represent the input

you'd need to explicitly say "the output is not identical to the input" so there was no confusion

Ideally everything in the codestream could be represented in the text format.

It would be cool to be able to dump an image to the text form, edit it in your favorite text editor, and convert it back to a jxl.

If you store the differences along with the tree that's gonna be a big text file

If you toggle a constant bool some part of the code, you can print MA trees as part of the debug info you get in benchmark_xl (you can also get quantization heatmaps and block selection maps for vardct that way, and maps of predictor choices per pixel for modular)

Interesting

I think this is a bug. When processing jpeg files, cjxl creates .tmp files in the %temp% folder and doesn't remove them after encoding is complete. My %temp% is of limited size and I noticed that it was almost full after playing around with cjxl and a bunch of jpegs. cjxl 0.3.7, win 10

that shouldn't happen...

This only happens if the input file is jpeg

I was building the cjxl using media-autobuild_suite because the other 0.3.7 binaries I found on the internet don't support jpeg for input.

But your binary 0.3.7 works with jpeg input? (with temp but)

Yep

I didn’t even think we had any code in cjxl that creates temporary files

do we?

I'm actually surprised. With how much JXL I encode these days, I would have a massive temo folder.

Maybe it is a Windows thing?

<@!387462082418704387> i'm searching the lastest binary working perfectly fine for windows (i'm using 0.3.4 😕 ). You can send it here, i can test it on my machine.

Sure 😄 https://eddiezato.github.io/bin/

Thanks, i'm searching where is the temps folder? %user%\AppData\Local\Temp ?

see, this is one of the aspects that surprise me: to write there, we would have to actually know the location of the folder

and I don’t think we have code that does that (outside of the `custom` codec in the benchmark)

Press Win+R and type %temp%

ah, `codec_apng` seems to

is it APNG files that you are encoding?

I confirm the problem

ah no, you said JPEG

Yep, I only play with jpeg and png

Ah yes i see it, i have a temps file too. That's the same for 0.3.4 binary.

that really puzzles me

They are just copies of the input jpeg files.

Windows flush temp folder sometime? But it's not smart to wear ssd for nothing with temp file, it need to be only in ram non?

maybe libjpeg is causing that somehow

apparently yes, it could be

> If the compressor requires full-image buffers (for entropy-coding optimization or a multi-scan JPEG file), it will create temporary files for anything that doesn't fit within the maximum-memory setting.

GDAL users have noticed a similar thing: https://trac.osgeo.org/gdal/ticket/1795

I would have thought that it would then remove them, but maybe it doesn’t or we need to do something specific to trigger the removal

My %temp% is located on the RamDisk created by the ImDisk Toolkit. It resets itself every time the OS is rebooted.

I don't know, but for me it's not suitable to have an useless copy of jpeg in temp, it's created even if it's a low res jpeg.

> NOTE: Unless you develop your own memory manager back end, then temporary files will never be used. The back end provided in libjpeg-turbo (jmemnobs.c) simply malloc()s and free()s virtual arrays, and an error occurs if the required memory exceeds the limit specified in cinfo->mem->max_memory_to_use.

so maybe that’s not it, then

So a windows specialist need to debug the binary to find what function ask a temp file creation 😄

maybe that’s a difference between libjpeg and libjpeg-turbo and your binary actually links to the non-turbo version?

ah, I seem to have a few too

a few of them are PNGs or GIFs, actually

or even PPM

(oh, right, maybe it’s just that we try to decode them as JPEGs first)

:<

i tried saving to exr and converting that via cjxl, which failed with illegal instruction

what cpu do you have?

zen2

huh weird

that should support most instructions unless your cjxl build somehow uses avx512

it really shouldn't

``` % cjxl -v 20210424_201012.exr 20210424_201012.jxl J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: AVX2] /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/extras/codec_exr.cc:57: no OpenEXR whiteLuminance tag found and no intensity_target specified, defaulting to 255 Read 4016x3008 image, 6.9 MP/s Encoding [VarDCT, d1.000, squirrel], 6 threads. /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/jxl/enc_ac_strategy.h:60: JXL_DASSERT: masking_field_row[by * masking_field_stride + bx] > 0 zsh: illegal hardware instruction (core dumped) cjxl -v 20210424_201012.exr 20210424_201012.jxl ```

not really sure if it's because of assert

on a CPU and OS that support AVX2?

zen 2 supports avx2

did you compile this yourself? or is it someone else's build?

compiled from AUR, -git

I did include `-march=native -mtune=native` in CFLAGS/CXXFLAGS but not sure whether they could be causing it

pfm and png encoding seem to work fine

Illegal instruction is what you get if an assert fails

confusing

in theory it's possible that your OS didn't enable AVX2 support (it needs runtime opting in by the OS beyond hardware support), but that's extremely unlikely on OSes that are less than a decade old

Please open a bug report, it is likely just a bug on our end

alright.

Exr is not exactly well tested

As an input for cjxl I mean

https://gitlab.com/wg1/jpeg-xl/-/issues/215

That's an interesting error

OTOH, dassert should be disabled by default in optimized builds... Something might be off in the pkgbuild

The assert probably shouldn't fail though :)

Ah that for sure :D I suspect it's some form of impossibly bright pixels or something like that that makes the encoder do weird stuff

I don't think we ever test exr, so it might have broken in funny ways...

There can be NaN or infinities in an exr, and I assume the encoder heuristics are not designed for that 😅

Or just large negative values or extremely large values

``` % cjxl -v -m 20210424_201012.pfm 20210424_201012.pfm.m.jxl J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: AVX2] /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/extras/codec_pnm.cc:301: PNM: no color_space/icc_pathname given, assuming sRGB Read 4016x3008 image, 65.3 MP/s Encoding [Modular, lossless, squirrel], 6 threads. /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/jxl/fields.cc:818: JXL_FAILURE: No feasible selector for 8927592 /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/jxl/fields.cc:818: JXL_FAILURE: No feasible selector for 9700587 /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/jxl/fields.cc:818: JXL_FAILURE: No feasible selector for 10143300 /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/jxl/fields.cc:563: JXL_RETURN_IF_ERROR code=1: ok_ /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/jxl/fields.cc:720: JXL_RETURN_IF_ERROR code=1: CanEncode(fields, &extension_bits, &total_bits) /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/jxl/enc_modular.cc:1051: JXL_RETURN_IF_ERROR code=1: Bundle::Write(stream_headers[stream_id], writer, layer, aux_out) /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/jxl/enc_frame.cc:1243: JXL_RETURN_IF_ERROR code=1: modular_frame_encoder->EncodeStream( get_output(0), aux_out, kLayerModularGlobal, ModularStreamId::Global()) /home/anon/.cache/yay/libjpeg-xl-git/src/jpeg-xl/lib/jxl/enc_file.cc:268: JXL_RETURN_IF_ERROR code=1: EncodeFrame(cparams, info, metadata.get(), io->frames[i], passes_enc_state, pool, &writer, aux_out) Failed to compress to Modular. ```

That's odd.

I don't get the bug on my side.

It encodes just fine with the EXR file?

It must be a build issue.

I exported exr and pfm from gimp. pfm isn't from exr

(just clarifying incase)

<@!321486891079696385> which version? is it latest git or tagged one?

(in my case it was latest git)

Latest git as well interesting enough.

did you use aur or manual build? https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=libjpeg-xl-git seem to have some stuff what could change whether asserts are enabled, specifically `-DCMAKE_BUILD_TYPE:STRING='None'`

(not really sure whether that's what is happening here)

Manual build: ``` git clone https://gitlab.com/wg1/jpeg-xl.git --recursive cd jpeg-xl mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_FLAGS="-O3 -march=native" -DCMAKE_C_FLAGS="-O3 -march=native" - DJPEGXL_ENABLE_PLUGINS=ON -DJPEGXL_ENABLE_GIMP_SAVING=1 -DJPEGXL_ENABLE_DEVTOOLS=ON -DCMAKE_INSTALL_PREFIX=/usr - DBUILD_TESTING=OFF -DJPEGXL_WARNINGS_AS_ERRORS=OFF -DJPEGXL_FORCE_SYSTEM_BROTLI=1 -DJPEGXL_ENABLE_SJPEG=OFF .. cmake --build . -- -j 16 sudo make install```

Well, that's a "true" error, at least... Interesting that it doesn't seem to happen to everyone, sounds like it will be fun to debug

idk if pfm one "doesnt happen to everyone'

ive not made issue for and havent uploaded file

blueswordm's messages were about exr

https://gitlab.com/wg1/jpeg-xl/-/issues/216

will look into it next week, thanks for the report!

I can confirm, I get the same error with pfm using lossless modular.

can you tell me what to modify to compile it this way? I'm interested in getting the trees from some jxls

DW if you see this a lot later I didn't ping you to not disturb you 🙂

There's a kPrintTree constant in lib/jxl/modular/enc_encoding.cc

But I don't remember if the decoder can do this, you might have to add a call to PrintTree in lib/jxl/dec_modular.cc, in DecodeGlobalInfo - or something like that

(you also need to install graphviz)

so best case scenario toggling this to true will make the decoder print the tree?

In theory, but likely not

it appears i already have graphviz installed

I can probably make a simple patch to make that happen - but in a few hours, I have my PhD defense coming up 🤣

nah it's fine

I just needed to get the trees of a few jxl arts that didn't have the trees published for whatever reason

i can wait a few days etc 🙂

In general a tree_from_jxl utility would be useful. The tree for the xor pattern I only found because I made a xor pattern image, used the existing encoder to encode it with -s 9 -I 1, printing the tree. That gives you the shape of the tree but not the offsets in the leaf nodes (those are not really used in the current encoder, since usually the symbols in a leaf have a nontrivial distribution anyway).

Has anyone tried opening JXL files from https://sneyers.info/jxl/art/ in ImageGlass? It seems that ImageGlass crashes whenever it tries to open "Tropical Island Sunset"

i think there was a recent bug related to a feature used in some of those jxl art pictures, fixed in the latest release

is it possible you (or imageglass) is still using an older version/plugin or so

Oh, you're right. An update is available.

No wait, huh?

It told me an update was available, but when I clicked on it, it said it was already up-to-date

Anyway, it seems I'm up to date but it still crashes. The files open fine in Chrome Dev.

I think it will be fixed in the next sync. Firefox was also reporting a problem with that image

Or rather with the multi-layer version of it

it's the same with nomacs

maybe it's the qt plugin?

because the gdk pixbuf plugin has no issue with it

No, it works just fine here with latest Git.

hm

Does it crash only on the very last image of the page?

Because then it's a bug that will be fixed in the public repo at next sync

Oh, it actually does. There were 2 Tropical images, I did not notice.

There was a bug in layer blending

Fixed last week, hasn't been a sync yet since then

The last 2 cause a crash for me.

I think the bug was only created at the last sync, so the released version should still be ok but the current public git head is not

Both of them? That's a bit weird

The one without the overlay logo should not be affected

imageglass don't read half of the jxl image on windows 7

Mine crashes on the black and white jxl logo, the bamboo and lightning, and the jxl logo overlayed on the tropical background

I think it might crash on the tropical background by itself but idk

i didn't compiled i downloaded the latest release in github

the ones that i converted now work

even older

it was an error because i used strange options maybe

i got some file corrupted

about 100

of 800

with q 60.4 options and faster decoding with some modular q 86.6 before

i did with an old build now that the folder hasn't error file imageglass works

Maybe imageglass cannot deal with higher bitdepth or out-of-bounds values. Likely an application bug then.

no

in my case not

is just that i put error file in a folder

--target_size doesn't work with --modular? ```PS > cjxl 0.png 4.jxl --modular --target_size=5350 -E 3 -I 1 -s 9 J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: SSE4,Scalar] Quality 100.00 yields 17328 bytes, 15.042 bpp. Quality -900.00 yields 516 bytes, 0.448 bpp. Quality -612.47 yields 529 bytes, 0.459 bpp. Quality -408.00 yields 548 bytes, 0.476 bpp. Quality -262.63 yields 563 bytes, 0.489 bpp. Quality -159.08 yields 615 bytes, 0.534 bpp. Quality -85.68 yields 683 bytes, 0.593 bpp. Quality -33.62 yields 780 bytes, 0.677 bpp. Quality 3.28 yields 982 bytes, 0.852 bpp. Quality 29.13 yields 1384 bytes, 1.201 bpp. Read 96x96 image, 5.7 MP/s Encoding [Modular, Q29.13, tortoise], 4 threads. Compressed to 1384 bytes (1.201 bpp). 96 x 96, 0.24 MP/s [0.24, 0.24], 1 reps, 4 threads.```

Looks like the search is just doing a very poor job here (I think it stops after 10 tries and it wasted most of them at way too low quality)

-900 quality? xD

I'd suggest you don't even try it - either lossless compresses better than vardct, or likely vardct will do a better job than lossy modular...

--target_size / --target_bpp is in any case an inefficient way to set a quality target, and it is likely to give much more inconsistent results than setting --distance.

I'm just trying different options with lossy vardct/modular to compete with lossy avif on digital art images. First aiming for close dssim values, then for the same size. Unfortunately, avif almost always wins when looking at quality and file size. For example, enlarged pngs to show the difference in quality. Yeah, avif has lost some details, but it looks better and is smaller. ```avifenc -j 4 -y 444 -r f --min 23 --max 23 -s 0 0.png 1.avif cjxl 0.png 2.jxl -d 0.94 -E 3 -I 1 -s 9 name dssim size 1.avif 0.00057152 3765 2.jxl 0.00057467 4999``` png original https://i.imgur.com/x6fVXzH.png png from avif https://i.imgur.com/oXP6CBO.png png from jxl https://i.imgur.com/KMR2hHm.png

Maybe try if -s 7 or -s 8 do better

For these kind of images we've seen it before that avif encoders are better in lossy than the current jxl encoder is.

-E 3 and -I 1 is work on vardct?

-I F, --iterations=F [modular encoding] fraction of pixels used to learn MA trees (default=0.5, try 0 for no MA and fast decode) -E K, --extra-properties=K [modular encoding] number of extra MA tree properties to use

Those options aren't really used in vardct, at least not currently: it uses a fixed MA tree for the DC

and what are this

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

For drawing content, you need wait jpeg xl implement some vardct improvement.

Hello, I am once again posting in a server I am very inactive in. Are there any really powerful image editors for JXL? Specifically, one where I can select the most important parts of an image (like text) and they will be the parts that are prioritized in the progressive encoding. I have been encountering Internet speeds that are even more incredibly slow than usual and I realized such an editor would be useful for anyone in the same situation. Please ping me with any replies because, like I said, I am not very active here. (Did you know that when Discord loses connection it seemingly deletes the message you're composing? After 2 tries I gave up and composed this message externally and just pasted it in, including this part.)

*such an editor would be useful for the creators of images that are viewed by users in the same situation

Support of software is read and basic encode with default param, i list all software: https://docs.google.com/spreadsheets/d/1bTeraUXIl-nGM8c53IdURxmJbabX9eXqPZwVSynoH9U

> select the most important parts of an image (like text) and they will be the parts that are prioritized in the progressive encoding Sorry, there are no such powerful editors yet. Even simple JXL merging tool for encoding every JXL layer separately remains only a suggestion: https://discord.com/channels/794206087879852103/803663417881395200/830745493368733697

it appears I have some options: - do nothing and wait for such an editor to be available - make one myself (this option will be harder)

I vote for the second option.

I also wanted to do this, but the codebase is too complex for me (at least now) and I don't have "proper" tools to help me with coding and definitely make understanding such an advanced codebase easier.

next option (it is actually a question): what would be the best language to code a powerful editor in

I assume the current encoder API doesn't let you do this, so for starters you'd need your own fork of the C++ encoder codebase, or get patches to do these things merged.

It doesn't let you select prioritized areas in the encoder, which is what <@281958058190700546> seems to be after.

Well even no JXL software exists that can do this, but at least the format supports things like that to a certain extent. I don't know of any other formats that do.

technically I could massively misuse GIF and make the first frames be ones with the most important areas but then of course I'd be restricted to 256 colours per layer so the solution is to make it an even more progressive image using layered local colour palettes

https://cdn.discordapp.com/attachments/818293093714886679/838607259511554058/xatu.gif then I made an example (yes it's a scene from the pokémon anime with subtitles, I had that on hand) (only 256 colours here because Discord massively messes up displaying local colour palettes)

There is not such editor/tool yet, but there is a "saliency progression" option to cjxl iirc that takes a heatmap as input and uses it to guide detail in progressive passes (iirc)

I don't know if and how well it works atm

yeah, we didn't test it for a long time, but in theory it should work...

jxl on android chrome canary when (iirc building that was disabled)

I figured out how to build jxl with msys2. No need to wait for other stuff like when using mabs. But one thing still bothers me. The size of the binaries has gotten bigger. For example: ``` msys2 cjxl.exe 9920070 bytes djxl.exe 7924854 bytes masb cjxl.exe 6735872 bytes djxl.exe 5039616 bytes from jeremylee.sh cjxl.exe 4818432 bytes djxl.exe 4107776 bytes``` I build like this: ```cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DJPEGXL_ENABLE_DEVTOOLS=ON -DJPEGXL_ENABLE_OPENEXR=OFF -DJPEGXL_ENABLE_SKCMS=OFF -DJPEGXL_ENABLE_BENCHMARK=OFF -DJPEGXL_STATIC=ON -DJPEGXL_WARNINGS_AS_ERRORS=OFF .. ninja``` Of course, this isn't a big problem. But how to reduce the size of the binaries?

`strip.exe -s cjxl.exe`

Yay, it works! Thanks!

also -DCMAKE_CXX_FLAGS='-ffunction-sections -fgc-sections' can help (I don't remember if we pass it by default though)

`c++.exe: error: unrecognized command-line option '-fgc-sections'; did you mean '-fdata-sections'?`

Eh, nevermind then xD

Ah, maybe it is -Wl,--gc-sections

Since it's a linker option...

(you can also pass -s in the cxx flags, ought to be equivalent to calling strip afterwards)

This worked: 😄 ```cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=OFF -DJPEGXL_ENABLE_OPENEXR=OFF -DJPEGXL_ENABLE_SKCMS=OFF -DJPEGXL_ENABLE_BENCHMARK=OFF -DJPEGXL_STATIC=ON -DJPEGXL_WARNINGS_AS_ERRORS=OFF -DCMAKE_CXX_FLAGS='-ffunction-sections -fdata-sections' -DCMAKE_EXE_LINKER_FLAGS='-Wl,--gc-sections -Wl,--no-export-dynamic' .. ninja strip -s cjxl.exe djxl.exe Name Length ---- ------ cjxl.exe 6023680 djxl.exe 4798464```

Took flags from ci.sh

Playing with tools. Trying to capture the output to a variable in pwsh. Just curious why cjxl output is sent to stderr?

Good question. Maybe we at some point wanted to keep the option open to encode to stdout?

Tools like cjpeg/djpeg write their output to stdout. Not very convenient if you ask me, since it is very rare that you want to do anything else than `> outputfile`, and much more common that you forget to redirect stdout and end up with a messed up terminal...

Oh, ok, that makes sense.

Other programs that can output binary data to stdout check isatty(STDOUT_FILENO) first and report an error in that case, to avoid sending binary output to a terminal.

Yes, not sure if that is easy to do in a portable way though

#ifndef _WIN32 ... #endif

Are there any image viewers that dither high bit depth images to 8 bpc?

I think Photoshop does that, if you call that an image viewer

No, I'm thinking more about tools that focus on image viewing over everything else. mpv can dither but that's again mainly a video player and not pleasant for typical image viewing.

maybe we should contribute a bit to an image viewer and make it do everything better: in particular doing downscaling in linear color and dithering in the conversion to display space are things that all image viewers should do but probably none actually do.

somewhat relatedly, I have found it disappointingly difficult to find a color-managed comic book viewer

I was almost tempted to try and write one myself at some point

but in the end I got an iPad for that

great comic book machine.

right, that’s another option, as well as some Chrome app I used a few years ago

(2018 iirc)

in my experience, they are more often distributed as cbr/cbz/cb7/all that stuff

btw, we decided not to do dithering in the core libjxl library - if a software wants dithering, they can implement it themselves on top of the float-based callback system

but yes, the Readium Chrome app works well for EPUB, including math formulas in EPUB3

it renders the second edition of “Physics of Digital Photography” very well 😁

Photoshop has dither option on explicit conversions between colour modes, not in the display path AFAIK.

On windows there is a good viewer for comics and ebooks - SumatraPDF. I created an issue for jxl support. Without much expectation, but just in case.

iirc, that one is not color-managed at all

There is another great and functional app for comics - NeeView. It has "effect panel" with some color management, I dunno if there is anything useful there. It could view jxl, if only were plugins for wic or susie. https://bitbucket.org/neelabo/neeview/

But even djpeg supports dithering! That would be quite a regression for JXL. :/

does it? IIRC it suports dithering to lower-than-8-bit output