JPEG XL

<@768090355546587137>

That way we could make api-based versions of cjxl and benchmark_xl quite easily, but also applications that want to offer CLI passthrough of parameters, like ImageMagick or ffmpeg

(or darktable, apparently)

It would also be a way to add encode params without adding new api functions

that sounds to me like it would be extremely brittle

In what sense?

well, it relies on the CLI being stable

not exactly guaranteed

I mean something like `JxlEncoderAddParam(enc, "progressive=1")` that can return OK, BAD_PARAM, or UNKNOWN_PARAM

Yes, but cli being stable is something we kind of want anyway, people may rely on that in scripts etc

By moving it into the api, there are more guarantees that it will evolve in a stable way and that it is harmonized across cli applicatiins

It could be something like libavif: ```-a,--advanced KEY[=VALUE] : Pass an advanced, codec-specific key/value string pair directly to the codec. avifenc will warn on any not used by the codec.``` But I don't think a lot of extra settings will be needed very often in third party applications, if some experimentation or fine-tuning is needed, the official cli encoder is a better choice

It's convenient if things can also be tested through imagemagick or ffmpeg directly

The goal for cjxl is to eventually become redundant :)

I also think it is better to hide `Decoding speed` somewhere in the advanced options section, because it will be confusing for ordinary users and it is not an option that needs to be changed often (if at all, except for some cases)

Also it might be worth setting a slower speed for lossy, like 6 by default (as I remember it is not very different in speed from some optimized Jpeg encoders), but 3 for lossless And there might be confusion with speed, because the higher the value, the slower the encoding speed, and perhaps better to use a more intuitive term `Effort` (also applies to GIMP plugin, but I noticed it too late)

Maybe we should align lossy and lossless effort settings so the same can be used for both

May be put those speed sliders in advanced options?

I think this is ok or just distance, although perhaps for more familiar things it would be better to change it to just `quality`, because `-q` anyway correspond to distance values and there is no difference in the methods or encoding quality

A choice of encoding speed may be quite often needed, but decoding speed is a very rare to use and for many people can be confusing option

Yes, or move it to advanced settings and enable it by default. Might be good to keep an option to strip metadata

I wanted to prepare google/highway package for Gentoo Linux but noticed that the package installs only static libraries (libhwy.a). Gentoo has strong preference for shared libraries. Why the project has the static target only?

I don't think a SIMD library makes sense to link dynamically, since you usually call it in the inner loop. I dunno though.

<@806098177983643658> is the highway expert

https://mageia.pkgs.org/cauldron/mageia-core-release-x86_64/lib64hwy-devel-0.14.1-1.mga9.x86_64.rpm.html This distribution has shared highway library. They converted .a to .so or patched cmake script to achieve that.

I don't quite understand how highway is a library at all, I would expect it to be more like boost, just a bunch of .h files to be compiled into your code.

it is

it just also has a few utility things

like detection of CPU and aligned allocators

which is pretty much what the .a / .so is about

Ah, I see

So most of the stuff would be "statically linked" anyway, as in, inlined in the inner loops. It's not like you can update highway and get better SIMD. Though maybe for those utility things, a shared library could make sense?

yeah I don't see why not

and statically linked is something different 😛

most things are header only

I mean, even with a shared library, what the application will use is what it was compiled with, not what that version of the shared library would do. So in that sense (for the core functionality) a shared library is not very useful, exception being the utility things (allocators and cpu detection)

I’d like that libjxl will be added to MSYS2, that’s important for Windows GIMP and few Qt viewers on Windows. It will be good to have https://github.com/libjxl/libjxl/pull/490 which should solve one of the MSYS2-related problems. Do you think a new release of libjxl (0.6?) will be ready soon? I am asking if I should wait with the request to MSYS2 or it is fine to suggest them 0.5.0 version? I do not want to bother them with frequent requests.

we branched off 0.6.x on Friday, I think in a week or so 0.6.0 will be out if nothing is on fire - but likely not with the hwy update

OK, so I wait and I will tell the MSYS2 maintainers not to use bundled libhwy but newer one.

non-bundled hwy is not a bad idea anyway 😄

Also from MangaDex discord

https://news.ycombinator.com/item?id=28440742

Any chance to enable photon_noise in lossy Modular in 0.6? I'm waiting with this PR: https://github.com/GoogleChromeLabs/squoosh/pull/1136 for that.

... does it not work?

<@!604964375924834314>

I thought I had used it in modular

I used `jxl_from_tree` as part of developing it

oh, maybe `cjxl` doesn’t go through the call to noise generation in modular mode?

in `jxl_from_tree`, I modified the `image_features` directly

It doesn't work, checked both in self-compiled `cjxl` and Netlify's PR preview of Squoosh: https://deploy-preview-1136--squoosh.netlify.app/

(the checkbox is called *Alternative lossy mode*)

This is my current way to save the encoding parameters for the image and be able to view them quickly.

``` PS > exiv2 -M "set Exif.Photo.UserComment 'jpg -j -e 8 -d 0.8'" mo 0.jpg PS > cjxl 0.jpg 1.jxl -j -e 8 -d 0.8 ```

`qimgv` built with the latest git version of `exiv2` (`-DEXIV2_ENABLE_BMFF=ON`):

Maybe we should add a cjxl option to add arbitrary exif/xmp sidecar files

Also note that cjxl should read exif from png files too

It'll be a bit tricky, because there are not only (recently standardized) eXIf chunks, but also (more legacy and thus widespread) unofficial "Raw profile type exif" zTXt chunks...

<@!768090355546587137> should probably know that already

Oh, and don't forget about "XML:com.adobe.xmp" iTXt chunks for storing XMP (because <:JXL:805850130203934781> BMFF supports both Exif and XMP)!

I think cjxl should support all ways to have exif/xmp in png, both official and unofficial

If not, please open an issue

This work well with Ffmpeg?

does libjxl? not yet

I haven't gotten around to writing it

the API documentation is not amazing for libjxl

I'd prefer there to be some sort of quick start guide beyond `example.c`

so I've been holding off

And i think ffmpeg can work with cjpx when we use "-f image2pipe"

oh, yea, I know how to do it from ffmpeg's side

or rather, I know how to make it work inside libavformat/libavcodec

but libjxl's api documentation is not good and I'd prefer if it were improved before I tried

not necessarily in depth as this

https://zlib.net/zlib_how.html

but a quick english-text explanation would be nice

it would work like other images. you'd have to add the header magic to the image2 and image2pipe demuxers/muxers in avformat, and add a libjxl based encoder/decoder in avcodec

the ffmpeg-side wouldn't be too hard since there's very little logic

it's just about splicing in the jxl interface into ffmpeg's own internals

At least something more convenient started https://libjxl.readthedocs.io/en/latest/

oh nice, when did this happen

it's not the easiest thing to do

I do know how to do it though

<https://github.com/libjxl/libjxl/commit/73724bfe2be72e29242db658d7e5cb92d97bbe57>

I've worked with the FFmpeg codebase before

ah, it happened 4 hours ago

😆

it was enough to ask 😅

fwiw, x264/x265 do something like that, https://github.com/videolan/x265/blob/419182243fb2e2dfbe91dfc45a51778cf704f849/source/x265.h#L1953-L1961 nice encoders will also bake all the parameters into the output file as well

oh meant to quote reply to `JxlEncoderAddParam`

https://www.reddit.com/r/jpegxl/comments/pr2sk6/facebook_now_seems_to_accept_jpeg_xl_image_uploads/

Is that true?

Yep, can confirm that.

is not true

you're lying

dilvish and kylxbn

700 kb image

<@!111445179587624960> why it doesn't work

i deleted .jpg extension

same it isn't recognized

it shows the image but it blocks the posting

I don't know, I don't use fb

... I'll ask

I suspect it's more of a side effect than being actually intentional

Probably because it uses something like IM or LibVips to convert or its own tools where libjxl support has also been added for faster future integration when it will be in browsers by default

https://bestsecuritysearch.com/facebook-hacked-via-imagemagick-exploit/

only for lossless recompressed jxl

Any jxl with a container seems to work

I uploaded that as a 258 byte jxl (the original 218 byte <#824000991891554375> file plus 40 bytes for the container), this is how I can download it

What are you trying to do?

add -j

now it compressed same 191000 kb jpg

189 kb the jxl

what is a jxl with a container

One that uses the isobmff file format and not just the naked codestream

If the file starts with 0xFF0A it won't work

how to convert the old jxl and scans my pc for invalid jxl?

ah

all the files i had have this problem

because i used early converters

If it starts with the JXL ftyp jxl stuff, it will work in facebook

It's trivial to put naked codestreams in a container, it just adds 40 bytes

when you added the container

is for exif

Maybe we should make a tool for it

or exif is something that add even more

the support for exif is more byte

Container is indeed to store other stuff like exif, xmp, jpeg bitstream reconstruction data, etc

Exif can have any size

when you added container

The container spec was finalized in April 2021

Its implementation is still unfinished, though the basic support has been there since before November 2020

i think -d 1.52 -s 8 can be good fidelity with samsung gn1 photos

there is various datas from 02 07 2021 from 31 12 2021

You think it's accidental? Could also be the first step in a deployment strategy. Adding server-side decode support would be a logical thing to start with...

This is even more curious. The web version of MS Outlook allows you to add jxl as an image when writing an email.

Does it maybe not check file type at all?

Or do you have the jxl WIC thing installed or something? That might change such things

The `Add file` dialog has images filter with *.jxl included

I don't have jxl WIC

Gmail doesn't allow jxl as image

Interesting...

I wrote him an email already 😛

So we have facebook and microsoft silently supporting jxl upload in at least a subset of their products

That's interesting, also considering they are both AOM founding members

No i do all*.

Yes i also have WIC

you don't see the image?

it converts to JPG?

Is normal

is not included

but at least do you see the image?

in jxl or in jpg

with firefox nightly

on facebook i said it shows on explorer with all files

`outlook.live.com` Windows 10 MS Edge Canary

Also Chrome

And Discord preview in a browser with jxl support (but sadly not in the desktop client and preview in messages)

it works in the canary client for discord if you set --enable-features=JXL

For discord, I assume it's just the browser

facebook, looks like they do support it server-side (it also works from safari or other non-jxl-enabled browsers)

Microsoft also looks like they did something to at least update the list of extensions they consider 'images'

It's glad to hear some company start use jxl, 🙂 non-optimize parameter avif still not suitable for photo image or some complex structure graphics. maybe we also have some good news for graphics(non-photo) quality improve or separate mode in this month?

If that news depends on my progress, it'll most likely take more time than "this month". Encoder improvements are nice but not at the top of my todo/priority list

Thank you for your reply Yes, I understand this not a high priority request, I just look forward maybe have some good news in this month. 🙂

<#840831132009365514>

no is not good

bit late but discord ptb still uses a chromium version of 83 <:kekw:808717074305122316>

at least according to dev tools

`qimgv` made it to release with support for both jxl and avif on windows. I put this to <#822120855449894942>

https://github.com/saschanaz/jxl-winthumb/releases now supports WIC decoding, if anyone still wants it

Very much want that. 👍

Works really well, though it surprises me just how little software on my computer uses WIC to handle images. Office and the legacy Photo Viewer seem to be it

Personally, I can recommend these WIC-supported viewers if anyone is interested: JPEGView https://sourceforge.net/projects/jpegview/ NeeView https://bitbucket.org/neelabo/neeview/

https://twitter.com/zemarmot/status/1442436382765588483

gimp_file_procedure_set_magics looks wrong

it probably works but matches stuff only partially when it could do full match

anybody volunteers to moving documentation on how to use JPEG XL in viewers etc in the main readme? (asking people who are familiar with Windows especially)

We can have it in both places. I think we need to make it as easy as possible for end-users to "make it work". For devs who need info, it's ok if it's a few clicks away, but for end-users who just want to get jxl to 'work' on their system (i.e. Windows and maybe MacOS) it should be easy and prominent instructions.

I'd say both...

or one, and we do the other

https://twitter.com/CHLThor/status/1443585512426520584

https://twitter.com/PDFAssociation/status/1443562578228269058

https://www.reddit.com/r/jpegxl/comments/pyf84v/development_gimp_299_win64nightly_with_jpeg_xl/

libappstream-glib 8 missing

file is called gimp-2.99.exe

gimp-2.99

recordings when

gimp-2.99.exe do not work alone. It is working for you when it sits among all the DLLs and other components from the archive?

with 7zip i extracted and did some errors

it said dangerous root path

because of some folders called path ... root

i delete the archive i don't know i will try tomorrow

they are 60000 files

I used only Windows copy+paste to uncompress the archive.

it's coming along

``` leo@gauss ~/Development/ffmpeg :( $ ./ffmpeg_g -i ../test_images/lenna.jxl ffmpeg version N-103959-g5f08956fe7 Copyright (c) 2000-2021 the FFmpeg developers built with gcc 11.1.0 (GCC) configuration: --disable-doc --disable-stripping libavutil 57. 7.100 / 57. 7.100 libavcodec 59. 10.100 / 59. 10.100 libavformat 59. 5.100 / 59. 5.100 libavdevice 59. 0.101 / 59. 0.101 libavfilter 8. 11.100 / 8. 11.100 libswscale 6. 1.100 / 6. 1.100 libswresample 4. 0.100 / 4. 0.100 [image2 @ 0x563ad367e3c0] Could not find codec parameters for stream 0 (Video: jpegxl, none): unspecified size Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options Input #0, image2, from '../test_images/lenna.jxl': Duration: 00:00:00.04, start: 0.000000, bitrate: 82511 kb/s Stream #0:0: Video: jpegxl, none, 25 fps, 25 tbr, 25 tbn At least one output file must be specified ```

streamcopy works, without corruption

not a surprise, copies the file bit by bit

but still a good sanity check

The test version of IrfanView comes with jxl support.

I dunno why, but the plugin is disabled by default. You need to enable it in `Help -> Installed PlugIns`

https://www.irfanview.info/test/iview64_test.zip

https://youtu.be/h8UHIHhDBHU

Also, timing about PDF Association: <https://youtu.be/h8UHIHhDBHU?t=2429>

hashtag fail :(

https://archlinux.org/packages/community/x86_64/libjxl/

JXL is in the arch repos 🙂

v nice

<:megapog:816773962884972565>

I guess so

Someone should send a CL ;)

https://twitter.com/tbonfort/status/1446164979456090115?t=e89r20QyCCgMabdD1P7jzQ&s=19

Hmm, but, why compared to zstd or is it some special data that is not supported by other lossless image formats?

I think they currently use TIFF because they need many channels

I mean, even something like Jpeg2k would be better than zstd for images

Yes, I dunno why they don't compare against j2k

J2K is quite good for lossless sensor data

(not as good as cjxl -e 3 though)

All these special use cases have their own current solutions, it seems

GeoTIFF for aerial/satellite multispectral images

DICOM for medical imagery

Motion J2K for digital cinema

has there been any thought towards using system libpng instead of embedded lodepng? it seems like the only remaining mandatory bundled library, and using system libraries would make linux distro packagers more comfortable. i think it is only used for tools, but we already get enough annoying bug reports complaining that someone's crappy vulnerability scanner found a dozen cves in some non-exposed library

it's not a huge issue, but seems like jxl project takes adoption very seriously

Huh, libjxl does use system libpng <:Thonk:805904896879493180>

https://openmandriva.pkgs.org/cooker/openmandriva-main-release-aarch64/jpeg-xl-tools-0.5-1-omv4050.aarch64.rpm.html

well, the "instead of" part is important; also i still mean libjxl the repository and not libjxl the shared object

afaict libpng is only used for apng, and all other png operations are done with lodepng

libjxl.so shouldn't depend on any png, but cjxl/djxl currently depend on both lodepng and libpng and we should probably make it a compile option to use one or the other

i assumed the reason why both are used is that lodepng has simpler api and is easier to embed for windows but doesn't support apng. does that sound right?

Yes, but libpng also doesn't really support apng, so I guess we should just add animation support to the lodepng decoder too (and the encoder too, so djxl can save as apng)

And for linux distros it might make more sense to depend on libpng to reduce the jxl package size / security surface

my theory is that hopefully people are not passing arbitrary files to cjxl, but who knows...

it may be simpler to just always use libpng

IIRC the main reason we use lodepng is because Lode is in our team 😛 but I don't think he'd mind switching to libpng at all

PRs are welcome

Libpng is not so practical for windows builds iirc, or is that not really an issue?

I don't think it's worse than say libjpeg...

I don't particularly care, just would be nice to use just a single one instead of two, and to support apng input and output

Two could be useful if have support for one of the most stable/distributed and one of the fastest libs (like libspng or similar fast ones), although cjxl/djxl is better to have the bare minimum functionality and for something more - IM/VIPS is better, but it is still not rare to use such de/encoders directly

one is less maintenance 😛

I'm not sure what's missing from codec_apng wrt codec_png to allow just libpng

It ignores icc and doesn't encode

how hard is that to fix?

Probably not hard

Regarding lodepng, I had some problems with that too for the libvips Windows builds (libvips only depends on `libjxl.{so,dylib,dll}`, so that dependency isn't needed). I was able to make the dependency optional with patch 3 from here: <https://github.com/libvips/build-win64-mxe/blob/87185888391a13c4d22e4becf4b10e6ff55cce5a/build/patches/libjxl-0.6-fixes.patch> I could look into upstreaming these patches, if there's any interest.

mhhh I think that it would be better to make it not needed, rather than just allowing not to use it

yes, i think so too. i considered that option for distro but decided it may cause unnecessary user confusion and annoyance, since png is a very common format

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c48

What does priority 2 mean?

(is that higher or lower priority than whatever it was?)

0 is most urgent. 3 is least urgent.

https://www.chromium.org/for-testers/bug-reporting-guidelines/chromium-bug-labels

Did it even have a priority before? And what was it?

It was Priority 1 before: https://discord.com/channels/794206087879852103/803574970180829194/810060217336725515

I wonder why they lowered it 🤔

Politics

In my experience vp9 1440p 3129 kbps still look better than jxl -s 7 -d 4.586

for 1080p jxl

so nothing incredible

but still jxl is good

if you know how to use it

for phones you need to have multi hdr like 30 frame or 60 frame like is there is photon camera on github

otherwise file will look bad

you need good quality image

photon camera is a camera app that does multi hdr

but don't sh0ot 10 bit photos

raw maybe is 16 bit but i didn't check it

don't know if is still 10 bit of range HDR 10+ but don't think it's good nits

anyway is off topic

for %i in (C:\Users\Utente\Documents\89\*.png) do cjxldelta -q 96.8 -s 4 -I 0.745 --use_new_heuristics %i %i.jxl

Ok send proof on #offtopic

vp9 improved a lot for youtube

but still my phone can't play 4k vp9

I think that Chrome leadership thinks that if they (are the first to) support jxl, they will be seen as not being loyal to the aom roadmap, and they don't want to endanger that major strategic alliance in any way.

and is snapdragon 780g

so av1 is still good to bet

av1 decoding is fast

It's rather frustrating and ironic that the AOM roadmap, of all things, seems to be the biggest obstacle to get a royalty-free codec supported by a browser.

> AOMedia unites top tech leaders behind a collaborative effort to offer open, royalty-free and interoperable solutions for the next generation of media delivery. The Alliance's shared vision is to make media technology more efficient, cost-effective and of superior quality for all users, on all devices, and on all platforms using AOM standards & tools. > Assertion: AOM member companies are committed to continuing to provide the focus and investment required to develop and maintain a future roadmap of standards and tools for AV1 and media delivery.

Note how that AOM mission statement starts quite broadly with "open, royalty-free and interoperable solutions", but ends with specifically "AV1".

key words: "focus" and "AV1"

"Alliance for ||blocking any non-AV1|| Open Media"

If not Chrome, then Firefox will have to be the first...

Also in Firefox as well, patch reviews have suddenly stopped and even after enabling AVIF by default, it doesn't look like it will happen anytime soon https://phabricator.services.mozilla.com/D119700

Mozilla is also an AOM member

Apparently Microsoft is a founding member

So... Opera?

opera won't get it out any faster than chromium

help us apple, you're our only hope

i think apple forgot they're a member of aom

Probably a consideration is prior investments in hardware, which causes both heic and avif to get pushed just because chip makers want to sell their chips and device makers who already ordered those chips want to make use of them

So our final hope is <@!532010383041363969>'s plan? Only start with lossless JXL for the first 6 months to avoid competition with AVIF?

I think we just need to convince AOM that jxl is not an enemy but an ally w.r.t. their overall mission of having royalty-free media codecs.

And even if they don't care about their mission but only about pushing av1: jxl does not threaten av1 in any way because jxl is not a video codec. AV1 does not need avif to 'win' and jxl to 'lose' in order to be successful.

What's the battle plan to realize that?

I send a nice email to Aomedia 🙂

IMO, the Google AOM devs are some nice folk, they just need some pushing.

They've already taken some stuff from JXL, so it shows that there is interest.

Fate of any new format is not easy. It took long time for older formats to get supported. You see that the progress is slower than you want but it is relatively faster than older formats. JXL is still young but for example it was accepted to GIMP much quickly than AVIF in the past. Don't be discouraged. Continue with patience and perseverance.

Part 2 was published yesterday: https://www.iso.org/standard/80617.html <:BlobYay:806132268186861619>

Yes, and the ballot for part 1 should finally start today - sure took the ISO editors long enough to prepare that ballot, considering we submitted it to ISO back in January... But of course it's a much longer document.

Only 16 pages? That makes it a readable document.

How long is the part 1 spec?

Somewhere about 100 (and something) pages.

I've just added it to English Wikipedia 🙂 Is there any source for an exact date? ISO page only mentions year and month.

part 1 ballot has started

it only describes the container and the jpeg bitstream reconstruction data/procedure

part 1 is the main spec that describes everything needed to decode the actual image

with part 2 the voting ended on Aug 28 and it took until yesterday to have the IS published

so I expect part 1 to be officially published end of January 2022

(assuming the vote goes well)

🤞

It's near the bottom of that page (quite user-unfriendly to reach).

IMO the "PR confusion" reasoning behind "AV1 or bust" kind of makes sense: people already accuse open source of having too much fragmentation, and format fragmentation doesn't help. yes, AV1 is a video codec and JXL is an image codec, but popular media can't even consistently acknowledge that there are at least three factors when comparing codecs (speed, size, quality) rather than just picking one or two (usually whichever are favorable to proprietary side...). "JXL, JXR, AVIF, FLIF, WebP, too much confusion, better use HEIC to be safe"

Most people have never heard of jxl, jxr, avif, flif and webp.

They just know jpeg, png and gif

And I would say avif is the new gif, and jxl is the new jpeg and png

The other problem is that these people don't even know about the 20 codecs MPEG members make 😛

There's a pretty big hentai mirror site that switched to AVIF a while ago.

Is it a 6 digit code site?

6 character name? yes

i dont see the appeal of using a lossy format for a medium that's just images. am afraid of generation loss

Only if lossless size is smaller than lossy one.

there's a big difference depending on what the use case is: - just watching the image - using the image

yeah, I see no problem with serving a lossy d1 or d2 version by default, and offering to optionally download the original if such use is desired

On cwebp near-lossless 60(not webp lossy), If compare with original, I can't find any difference on near-lossless 60 version, Probably jxl -d 0.5 -e 8 also can reach near-lossless quality(pass blink compare test)? so I guess high quality lossy also a good choose.

https://twitter.com/corbindavenport/status/1449114622720622598

huh they actually did that? kinda silly. id expect webp's lossless mode (possibly with some loss) wouldve been better

i think it was called near-lossless unless im mistaking it

not seeing avifs on that one

There's a download button for the whole book which gives higher quality images (typically jpeg from what I've seen).

🤔 > ひとみ.lx 😛

apparently its not for all pictures

or.. depends on browser? works in mysterious ways

If I set disable avif in Firefox about:config, it sends webp. If avif enabled it sends avif

depends on gallery

try picking some obscure tag and going to last page

How do I know which one is obscure 😔

So they encode avif for popular ones

makes sense. as it's expensive to do

Somehow it manages to produce bigger files than png when set to q100 + modular

E.g. I took a noisy cover art (https://f4.bcbits.com/img/a0101909125_10.jpg), png is 2,784 KB, irfanview jxl q100 + 2nd slowest + modular is 2,979 KB, and the latest nightly cjxl q100 + 2nd slowest is 1,697 KB

On the other hands irfanview q100 without modular produces the same sized result as cjxl -d 1.0, 396 KB

Ok, I may have exaggerated a bit, because I have OptiPNG plugin too, so probably a normal png would be over 3K. Still, irfanview's lossless is **significantly** bigger than cjxl's

I guess irfanview is doing something wrong <:Thonk:805904896879493180>

He switched the effort order (so that 2 in IrfanView is now kitten and 8 is thunder), but that doesn't matter, files are much bigger regardless

Looks like something is not done correctly - are the results even fully lossless? Check `compare -metric pae orig.png irfanview_bla.jxl.png`

I'm a sunday tester here, so I'm not sure where can I do that

I only have the latest nightly binaries cjxl/djxl/benchmark_xl

But yeah, even IrfanView itself reports a different number of unique colours, png and cjxl files are equal (145359), the file saved in IrfanView is different (145097)

You need to install imagemagick for compare tool

ok, thanks

yeah ok

so quality 100 + modular with this test IrfanView plugin is not 1:1

The GIMP plugin seems to do the same thing (Inverted speed and lossy 'lossless') (And checking "Do not use XYB colorspace" does nothing)

``` ➜ du * 1700 jxl_cjxl_jms8.jxl 3192 jxl_gimp_ms8_noXYB.jxl 2980 jxl_gimp_ms2_noXYB.jxl 2980 jxl_gimp_ms2_toXYB.jxl 3012 orig.png ➜ compare -metric pae orig.png jxl_gimp_ms2_noXYB.jxl diff.ppm 771 (0.0117647) ```

`uses_original_profile: 0` in both cases from gimp

Looks like it doesn't do lossless properly and converts to XYB. This seems to be a big pitfall for api users, is there anything we can do to make that less likely to happen, <@768090355546587137> ?

GIMP 2.99.8

I heard that 2.99.8 was scheduled for the 17th, but was postponed due to some problems on the msys2 side.

Are you using default gnome theme or custom themes?

The picture is not from my computer, it is from one GIMP developer.

I thought the dash isn't supposed to be in JPEG XL. ie shouldn't be JPEG-XL

great work. I'm very excited for GIMP 2.99.8

this looks like default theme's dark variant

I suppose this is not final, but I'd consider 'Effort/Speed' -> 'Compression effort' and use a numerical slider, 'Compression/maxError' -> 'Distance/Max error'.

distance is quite uncommon parameter name though

Yes, that's why I kind of like the addition of '/Max error' to perhaps aid in understanding for those unfamiliar. Distance is accurate and familiar for others having experience with the codec. To that same point, there's an argument for labeling it 'Distance' alone, understanding that people will gain a familiarity with the setting over time.

Otherwise, 'max error' could become the popular description for the distance setting, which I'm not sure whether would be a good thing.

Depending on how you interpret "error", it is OK

As long as people don't interpret it as max numeric 8-bit RGB error or something like that

Yes, 'error' is quite vague, but so is 'quality'.

one could just have additional slider for 'quality', and let them move in sync (change of one would change another)

that would make connection between two easy to discover and more obvious imo

I considered that as well. The downside is that it's redundant.

i don't see that as big downside at all. command line parameter is redundant too, but sometimes it's more handy, especially for people who are used to jpeg way of handling things

right now seeing only cryptic named slider which means exactly opposite what jpeg's stuff does is just not good experience for ones who haven't heard of this stuff at all

Redundancy is good where it increases usability. I don't think that's the case here, where the argument is really for guiding the user's mental model of an archaic option. If quality is decidedly more intuitive/familiar, there's an argument for just having a quality slider. But I do think people will come to understand the effect of distance, and I like the accuracy of the option over quality.

depends on demography. pretty sure some will be surprised, also given the fact that it's got jpeg in name. also use case of "lets just do similar quality what I used to do with jpeg"

some people learn fast, some don't

People also tend to be surprised that JPEG XL can do lossless

im saying this as someone who actually prefers jpeg quality way of doing things

so this showing of distance makes me go ewww

JPEG has become a synonym for lossy (though actually all jpeg standards since the original one can do lossless too, but it kind of sucked and was usually not implemented)

it's bad enough that id rather export to png and invoke cjxl by hand

Maybe a single slider but with a dual display of the value as a d and a q could also work

now that's actually good idea

Yes, I was trying to visualize how to do that.

Two input boxes, in case you want to enter a number instead of adjusting the slider, but just one slider

I guess: Quality/Distance [slider] [number] q [number] d

It's just perhaps a bit tight horizontally. But looking at other dialogs, I didn't see precedent for small clarifying labels above an input.

I'm not sure about: Quality [number] [slider] Distance [number]

But maybe that's readable (if possible in gimp UI framework).

https://github.com/thebombzen/FFmpeg/tree/libjxl

If anyone would like to help me test

https://0x0.st/-dXd.png

Is it ffmpeg fork with jxl support?

that's my development branch

once it gets tested/approved it'll get merged

re: that gimp pop-up

does checking lossless automatically disable the slider/set it at distance 0?

and the other way, does moving slider to distance 0.00 automatically check lossless?

because for a normal user that would be intuitive, i think

cjxl is intuitive, help explicitly states that if you want mathematically lossless mode, just set quality to 100 and that's all

yeah, checking lossless should automatically move slider to 0.00/jpeg 100, and moving slider to that value would autoenable it too. synchronized settings

lossy modular is probably obscure enough to not have option at all yet

imo it shouldnt disable slider, just set its value

where do you hook up mov? doesn't it need some entry/entries in mov_default_parse_table?

it seems potentially confusing that ffmpeg -threads is not interpreted the same way as cjxl --num_threads for values 0 and 1

at the moment, I don't

I just cause its score detection to be lower than image2

if you force the mov demuxer instead of the jpegxl_pipe demuxer it will fail

https://github.com/thebombzen/FFmpeg/blob/libjxl/libavformat/mov.c#L7116

see this line

note that this is lowercase `"jxl "` which is intentional

the signature atom is captial `"JXL "`

also <@!765599758559215616> that's intentional in order to make it inline with the rest of ffmpeg's kit, w/r/t the threading

cjxl with num_threads=0 apparently is zero *worker* threads. disable threading. num_threads=1 means one dispatch thread and one worker thread, which there's usually very little reason to do

and I believe unless i map it over, the average user will find it confusing to just be told "don't use threads=1 to single-thread, use threads=0 instead"

this, because having to go uncheck it would be annoying

I'd prefer if checking lossless set it to 0 but left it enabled

and sliding it off 0 would uncheck lossless

yep

only issue is, what happens if the user manually unchecks lossless

I'm thinking you could set it to the default

or to 1

or v near lossless

but maybe 1 is good too

or to whatever it was at before, if possible

ah, remembering it would be handy

I find d=1 corresponds to q=90 for OG jpegs about for photographic content, but it performs much better for synthetic content

which q=90 on jpeg butchers

its okay though. will show jxl's superiority

id rather people accidentally encode in better quality than in worse

https://www.gimp.org/news/2021/10/20/gimp-2-99-8-released/#improved-file-formats-support-jpeg-xl-psdpsb-and-more

Put the info to reddit too.

By the way: I think <@!886264098298413078> deserves being designated as a dev. Pinging <@!794205442175402004>

True that

Also, does JXL lossless in GIMP now work correctly?

If you check both Lossless and Save original profile, probably yes.

Yep, it works 🎉, although the colour profile seems to be specified differently from cjxl (image from https://discord.com/channels/794206087879852103/803574970180829194/898964309667876895 to png) cjxl: ``` color profile: format: JPEG XL encoded color profile color_space: 0 (RGB color) white_point: 1 (D65) primaries: 1 (sRGB) transfer_function: gamma: 0.454550 rendering_intent: 1 (Relative) ``` gimp 2.99.8 ``` color profile: format: ICC profile ICC profile size: 680 CMM type: "lcms" color space: "RGB " rendering intent: 0 ``` ``` ➜ compare -metric pae 1_jms8.jxl 1_jms8_gimp.jxl 1_diff.png 0 (0)% ```

Probably a good idea to make lossless imply save original profile, because lossless without save original profile is not actually lossless, will compress poorly, and just doesn't really make sense.

irfanview test version has also been updated and now produces exactly the same results as command line tool

`Update (20/10/2021) : The test version has been updated (use the same link, shown above) Changes include: 1. The "modular" saving option has been added. 2. JXL animations can now be played. 3. A new API for JXL saving (the resulting file size should be similar to cjxl). 4. The Speed option has been changed/reverted, to be similar to cjxl .`

Where does one find the test version ?

It is not difficult to implent. It is good to add this recommendation to API documentation.

Yes, I saved profiles as ICC data.

https://www.reddit.com/r/jpegxl/comments/q72d8b/irfanview_has_now_added_jpeg_xl_compatibility/

---> https://www.irfanview.info/test/iview64_test.zip

ah! thanks

you'll get the exe to replace in program files + plugin dlls

It works <:pogey:798146744977719326>

it crashed

Heh

Well it hasn't for me yet, but I was basically only checking if lossless mode finally works as it should

Now for browsers to support animated jxl

Chrome already supports animated <:JXL:805850130203934781>, we have to wait for Firefox

Viewer PhotoQt v2.4 (64-Bit) for Windows has JXL support working out-of-box now (no need to add plug-in, it is there already). Just install and you can view JXL files. https://photoqt.org/downpopupwindows

ok updating

<@!219525188818042881> wants someone to adopt him

<a:FrogStab:821038589345136682>

png i still see with imageglass

avif also

jxl i have jxlwinthumb that now works even in the win viewer

infarview by irfan test.info version now can read jxl animation and it does fast

chrome 95 should support jxl even in the stable version if you enable the apposite flag

so no need for canary

firefox is still waiting

animated avif i have no idea whether to produce them

what is the procedure

on reddit i have seen a post, but does it support avifenc or libavif gif as input?

webp to me opens with firefox (nightly build)

is still too confused

ah jpeg remains

jpg i have imageglass

i have doubts for svg

sorry but capital letters also don't seem to work

https://github.com/eeeps/exif-intrinsic-sizing-explainer

Is something like this going to be supported for JPEG XL?

Probably, it would be enough to have just ExifImageWidth and ExifImageHeight without XResolution, YResolution and ResolutionUnit, it won't break anything for JPEG XL since the format is new

We have IntrinsicDimensions in the image header exactly for that

It can be done without Exif, following our philosophy that render-impacting stuff goes in the codestream, Exif is only used for non-render-impacting metadata

Oh, cool

Probably all/most viewers are ignoring it atm though, maybe we should do something about that...

This thing is important to support in browsers, since they already support a similar thing for usual JPEG

I don’t understand this proposal, I must admit. Even less the speed with which it was adopted… Does it **only** apply to pictures shown directly instead of a page in a browser, like `file:///mypic.jpg`? Or also to pics sized by HTML/CSS (in divs etc)? If former: pretty uninteresting, marginally unhelpful, practically unoperable (luckily). If latter: I must understand it much, much less than I think I do!

It applies everywhere, standalone or when embedded in a page (So unless the size is overridden by HTML/CSS, it'll match what the Exif metadata says)

It's a nicer solution than the previous `Content-DPR` http response header approach.

https://www.wpclipart.com/famous/composers/Beethoven/Beethoven_by_Stieler_large.jpg.html

Looks like this site has jxl and avif versions of all images