JPEG XL

but I can see how someone would write code that says "they probably meant sRGB"

and then just interpret it as sRGB anyway

I think we can avoid trouble by just always including an icc profile in the pngs we write

Even in the cases where it's strictly speaking redundant

And we might want to consider printing a warning in cjxl when we are getting a png as input that we know gets interpreted differently by different browsers/viewers

Because that's a recipe for "look how jxl changed the colors!"

the issue is that PNG spec is a bit less clear what happens if the iCCP chunk is present but the display cannot perform color management

Strictly speaking it should be redundant in 100% of cases. No iCCP, no gAMA, no cHRM **should** mean sRGB. But at least default Firefox is still not that smart/conformant. That’s why Adobe’s decision to not allow to even save an ICC with sRGB PNGs seems to me premature and uncharacteristically (for them) optimistic. TinysRGB is what I do for PNGs to be safe.

under the gamma chunk it says this

> An sRGB chunk or iCCP chunk, when present and recognized, overrides the gAMA chunk.

but also this under iCCP

> PNG decoders that are used in an environment that is incapable of full-fledged colour management should use the gAMA and cHRM chunks if present.

I wonder what's the status of iccv4 support, if it's good enough (IIRC both ff and chrome are OK with it) we might want to make a v4 TinysRGB

should be much smaller

what does firefox actually do btw

does it not render sRGB PNGs as sRGB?

Yeah it's annoying, it's what you get with formats defined in the 90s I guess

IIRC, it renders it as whatever your display is

i.e. pass-through to the display without thinking about it

Firefox by default just throws pixels to the screen if there's no explicit colorspace

so it doesn't perform color management

or it doesn't unless one of the color chunks are present

The latter

So it can be circumvented but you need to waste bytes on signaling

While W3C has already for a long time specced that any untagged images are sRGB

> PNG decoders that are used in an environment that is incapable of full-fledged colour management should use the gAMA and cHRM chunks if present. This is typical, over-optimistic, spec-writing: use this invented-by-us three pieces of “simple” metadata signals if you cannot be clever about it. But, well, you need to interpret it anyhow, so you need to do ICC, by which time you can just read ICC anyhow. > Yeah it's annoying, it's what you get with formats defined in the 90s I guess Not sure if we are not being similarly optimistic with CICP…

(I assume GIF and untagged JPEG have the same issue in firefox)

Firefox by default only does tagged images. And by default color management is still disabled. <:pepeWeird:585744188742828042> <https://searchfox.org/mozilla-central/source/modules/libpref/init/StaticPrefList.yaml#4713>

Closest to comprehensive I know of: https://kornel.ski/en/color (still not fully, and written results outdated)

keep in mind that the PNG spec does not state that PNGs without color information are sRGB

I think we can try to minimize issues by putting as much of the color management logic into the decoder library, but the application will always have to do the actual color management because libjxl will not know the display color space

Nope, but w3c specifies that GIF and any other untagged images are sRGB

what about providing the libjxl a display profile in decoder step

> When the incoming image has unknown gamma (gAMA, sRGB, and iCCP all absent), choose a likely default gamma value, but allow the user to select a new one if the result proves too dark or too light. The default gamma may depend on other knowledge about the image, for example whether it came from the Internet or from the local system. so in other words the PNG spec explicitly allows the decoder to guess or do whatever the fuck if it doesn't fidn it

``` #if defined(XP_MACOSX) || defined(NIGHTLY_BUILD) value: true #else value: false #endif ``` why do they hate nice things

That's exactly what we are planning for a high-level decode api

nice

often display profiles are LUTs though, and it can be tricky to decode to that

what about zimg?

like I think skcms doesn't fully support that

https://github.com/sekrit-twc/zimg

license is very permissive

Yeah: so here, I still cannot get my head around how is it suppose to help? So app authors can request output in any colour space? Can they request it in display colour space? If not, they should get it always in the source colour space or there will be one conversion too many? Or am I being dumb?

it's a joke and is essentially public domain

Oh yeah I've always wanted to ask, what are the pros of using skcms over LCMS?

there's no good documentation for skcms

You could also provide a hierarchichal API like how libplacebo does its rendering abstraction

libplacebo exposes a lower level interface as well as a more convenient higher level wrapper around it which you can ignore if you want to fine tune

but most applications will opt for the higher level one

In the low level decode api, you get pixels and an icc profile, and the application hopefully can deal with that. By always being able to produce an icc profile, at least there is only one code path to implement in applications, so hopefully that's less error prone.

IIRC: lcms is slower by default and less well-written (say, used to be not quite thread safe), but supports more things

In the high level decode api, we could deal with color management completely and return pixels ready to send to screen

> we could deal with color management completely and return pixels ready to send to screen So in display colour space?

speaking of dependencies, is there a way to use system dependencies?

like brotli is a common system lib

we don't need to include it as a git submodule

https://en.wikipedia.org/wiki/WTFPL it's not quite 100% agreed upon that that's an OK license everywhere 😛

-DJPEGXL_FORCE_SYSTEM_BROTLI I believe

other things for the most part should come for the system

I mean, that should be default

what happens if you git clone from the libjxl repo and try to build with cmake it goes "run ./deps.sh"

which you then do

and then it downloads them all even if you don't need them

file an issue 😛

Yes, well, the application will still have to say what display space they want, e.g. by giving an icc profile

There's no way we can know which of the possibly several screens the application wants to send pixels to

I always wondered what would happen if you put a window halfway between two displays with different ICC...

But also for CMYK, a high level api would be useful

theres no app which splits it

MacOS does not let me do that

Every window is only on one screen

although it doesn't sound too hard to do

Would be weird if one half is wide gamut and the other is standard gamut HDR

the current windows photos app switches profiles between displays instantly and uses the center to pick

Bad manners and awful to reply to oneself, but I’ve tried to express my worries about > Not sure if we are not being similarly optimistic with CICP… here: https://github.com/AOMediaCodec/av1-avif/issues/84#issuecomment-626153246

It's an issue with video people: they always think color spaces are someone else's problem

Getting videos to display consistently across different codecs and different implementations is a major pain

Even in same browser, same platform, you can get different results depending on whether hw decode is used or sw decode

mpv picks a display

and renders for that one

by where middle of window is, or something else?

mpv also doesn't split the refresh rate either

but it does adapt that as soon as it's fully in the other monitor

on windows, the window's handle gets associated to a single display, and it uses the center. I would assume other OS libraries do the same.

in X11 most applications have a display that they belong to by default

which is usually where the cursor is when it's launched

some applications are a pain if they're not programmed to be able to just be moved

yeah same experience on windows

for example if I open GIMP on my right display, and then move it to the left, and then open the toolbox, the toolbox still ends up on the right

the fastest way to solve this is to quit and relaunch it from the left

like I push Ctrl+B and it ends up over here anwyay even though this is the right monitor and the gimp window is on the far left

interestingly, that screenshot of the GIMP color dialog doesn't produce the same color as the dialog itself

TIL

rgb(23, 112, 19)

became (5, 112, 30)

iirc, Chrome switches the moment the center of the window crosses the border

but yeah, at least on Linux and Windows, it’s up to the applications to handle this

and I doubt that many of them bother

few even bother to handle this for single-display setups after all

for the viewers in libjxl, we handle single display but not more

ideally, we would, but it seemed like too much effort

it's just such an edge case

~~Can someone remind me how to compile the GDK PixBuf module for jxl? I've done it before, but can't remember how to do it now.~~

Ignore that.

I forgot that it was compiled with the rest of libjxl. It's just that I need to re-associate eog with the image/jxl mime type.

Yeah something to do with corporate lawyers going "What is this? Why does it exist?" When people ask if they can use stuff under it in the companies apps.

Basically :P

I'd **love** to use WTFPL, but I'm de facto forced to use Unlicense (still cool) because it contains explicit liability and warranty limitations that WTFPL lacks.

You can put the warranty limitations into the WTFPL. From the license's website:

I know about that clause (I've read the website), but this way looks... shoehorned? I prefer it to be explicit in the license text itself.

I personally don't

though being a bit legally questionable kinda disqualifies it as license of choice for me

like if you wanna declare something public domain, just do it, why gimmicks

if you wanna ensure that it's really really available, CC0

which, btw, does not include "warranty" stuff either

FWIW, it seems Google cannot contribute to projects under the WTFPL: https://opensource.google/docs/patching/#forbidden

but using seems fine: https://opensource.google/docs/thirdparty/licenses/#notice

Why does BSD0 get a pass compared to other public domain equivalents?

¯\_(ツ)_/¯

I think the reason you can't just say public domain is that not all countries have a legal concept of public domain.

So these licenses try to give the same rights in the absence of legal public domain

Yeah.

what's the difference between the Unlicense and the MIT license basically

in practice

MIT license iirc just contains "you can do anything you want, under the condition you put this text file in the thing you do with it"

and also waives implied warranty

MIT requires crediting the author. It's a nice thing, but I want even higher freedom than that for *my* software. Not like I have any beef with MIT license 🙂

ah. so for most practical purposes it's the same

since you can do the same things, you just need a text file

there's nothing you can't do with MIT license that unlicense allows

now, I wonder if there's a hyper embedded system case where the license file is large enough to take up a nontrivial amount of space

in that event, I suppose being able to obtain the license from the manufacturer's website would suffice

Not sure. Putting it in the smallprint somewhere with the "safety information" etc is probably the safest option

not that this is anything beyond hypothetical in this case though

if it's placed in the owner's manual rather than in the firmware itself I can imagine that is sufficient

since the MIT license is by design to allow people to use it

With MIT you're supposed to distribute a license and copyright notice. But with Unlicense you don't have to do *even that*.

HELP! I'm trying to install Butteraugli on Windows and the README states the code will compile if "_CRT_SECURE_NO_WARNINGS" is defined in the project settings. I don't know where the project settings are.

<@!376221034946494465> <https://docs.microsoft.com/en-us/cpp/build/reference/d-preprocessor-definitions?view=msvc-160> I guess (just used a search engine). The butteraugli in the libjxl repo is newer, btw.

Probably we should make some kind of benchmarking package that includes the butteraugli and ssimulacra from libjxl, which don't depend on opencv at all

What are the dependencies required to build the gdk-pixbuf plugin? I've got it working in the past, but can't remember what I need to do currently.

I've made a gtk4 image viewer with jxl support! it's on flathub if anyone is interested, so it's a one-click install: https://flathub.org/apps/details/org.libvips.vipsdisp supports very large images, animation, loader is sandboxed and fuzzed, many other formats, visualisation tools, etc. more technical info here: https://github.com/jcupitt/vipsdisp#features

oh, sorry, probably the wrong chat room

channel is not too wrong dont worry this is really cool though. does it do color mgmt for all the stuff it supports?

<@!260412131034267649> thanks! No colour mgmt yet --- this is going to be the image view window for an image processing package, so colour management will be done elsewhere in the system. This viewer should have a simple thing too though, you're right. It's missing some other obvious stuff, the README has a list. Eg. you can save images in other formats, but there's no UI at the moment for image save options, so (for example, again) save as PNG always saves losslessly, there's no save as palette RGB The underlying image processing library has all this stuff, it's just a question of hooking up some UI

Anyway, it's much faster than eg. "eog" for large images (and has jxl support, woo!)

It wasn't able to open a JXL image for me (cjxl encoded, both lossy and lossless). Is that something recently added that might not have made its way into the flatpak yet?

I didn't have issues with opening JXLs. But I only tried a few files as the flatpack is not convenient for me.

OK, I've narrowed down the issue. It doesn't like a lossless transcoded JPEG.

Maybe container vs no container issue?

Try encoding a png with cjxl --container

Or encoding a jpg with cjxl --strip

That seemed to be it.

This file works.

This file (created from, the jpeg with the -j option) does not work,

I'll file an issue on the GitHub.

Likely the container magic is not detected

yes, it wasn't checking the signature correctly, fixed now, thank you!

actually, now I check, it does sort-of do colour management -- it just forces everything to srgb not a very useful thing to do, and there's no UI to control the process yet, but it is taking profiles into account

source profiles, that is

yes, exactly

<@!877735395020927046> is there any way to translate `file-jxl` GIMP plugin? I'd gladly help!

Strings must be marked translate-able (right now they are not) and then the translation is made in Poedit. That's approximately how it is made in official GIMP.

I don't have any experience adding translations to programs. Based on a quick search, it looks like it would use `gettext`. I'll start paying attention to marking strings translatable.

https://developer.gimp.org/README.i18n Read the part "Localization of third-party plug-ins"

I made a libjxl wrapper for elixir <https://github.com/wwww-wwww/jxl_ex> Also a demo app <https://embed.moe/URL> that transcodes to png if the browser does not support it you can force it to do png with <https://embed.moe/png/URL> or jxl with <https://embed.moe/jxl/URL> for example: https://embed.moe/http://jpegxl.info/logo.jxl

for a github link, you get the raw url. For this it's https://embed.moe/https://raw.githubusercontent.com/libjxl/conformance/master/testcases/bicycles/input.jxl

i just changed the pattern matching on the link to be easier to type. this can be used to embed jxl into discord, and still link to the actual jxl when opened in a browser

🤔 https://grass-test-0.gigalixirapp.com/jxl/auto/https://cdn.discordapp.com/attachments/803663417881395200/895480186965987328/2048x1320_delfi-de-la-rua-23324.jxl

For ideal use it would be nice to make a very short URL and a Discord bot to automatically insert the generated links for any posted JXL images <:Stonks:806137886726553651>

yeah i can make a discord bot that replaces jxl files

although i don't know about extending too much onto this server

Yep <@!321486891079696385> Btw, if someone from the AV1 conference has their own server with some extra spare capacity, a such bot would be useful there as well 🤔 This is basically support for JXL images even without the support from Discord itself (except the preview would be in Jpeg)

i also dont mind buying a short domain just for this

Yeah, it's just a thought of what it might look like in a kind of ideal implementation

And there are free domains like tk, ml, ga, cf ...

those are always blocked

if it's just jxl i was thinking jxl.rocks

For this kind of links, I think some of these will be fine

unfortunately those are all taken for jxl

Well, maybe something a little longer like jxlc, jxlp or jpegxl, etc

jpgxl <:megapog:816773962884972565>

I've tried some images I've got with that, and a few spit out "Not a valid jxl" instead of a more specific error (They're 4K screenshots, like 40MB as PNGs, so I'm guessing it's a file size limit)

Apart from that though, very nice, doesn't even feel like there's any delay in loading them to me

shouldnt be a file size limit

can you send me the file or link?

Sure, https://flawlesscowboy.xyz/stuff/Destiny%202%20HDR/tower.lossy.jxl

It might also be because it's HDR, but things like the WIC plugin and djxl itself still decode it (just really dark) without any special flags

the validity check only checks for the container/codestream header

oh i see the issue

it's a uri encoding thing

I hadn't even considered that as a possibility 😆

haha this image killed the node

I hope that's not a bug on our side 😛

nah it just gets killed when oom

im trying to get it onto google app engine instead

https://embed.moe/png/https://flawlesscowboy.xyz/stuff/Destiny%202%20HDR/tower.lossy.jxl

Nice, like the new URL too

`>magick 1gbxt.jpg /tmp/a.jxl /mnt/data/yay/libjxl-git/src/libjxl/lib/jxl/encode.cc:220: Invalid value for orientation field magick: UnableToWriteImageData `/tmp/a.jxl' @ error/jxl.c/WriteJXLImage/641.`

Is this a bug? Should I write a bug report at imagemagick GitHub?

I guess that JxlBasicInfo was not correctly initialized. File bug to imagemagick. It probably worked with older libjxl.

Ok

Right, the changelog explains what to do there

http://embed.ml/https://jpegxl.info/anim_jxl_logo.jxl

wrote a whole png/apng encoder in elixir but discord doesnt even support apng

😩

<:Cheems:884736660707901470>

Same thing about animated WebP, Discord disallows this stuff because they want people to use animated stickers and emoji

well at least it shows proper in browsers incapable of jxl when opened as orig

Yep, I think encoding in Jpeg would be less resource consuming for the server, especially for large photos or for heavy loads, especially considering that JXL can also be lossy, but on the other hand Jpeg is less versatile and does not support transparency and animation, and it can't be used for something like a quality comparison Lossless WebP could also be more effective for bandwidth, but it is heavier to encode

there's like no jpeg encoder library for elixir/erlang

and encoding png is so simple that i was able to implement it by hand in native elixir

but it is supported for the preview when uploading 🙂

Only for full previews, as I recall, but not in chat

<:sadge:860304344771461130>

yes, joking about discord being able to support it easily but not doing so

Most likely to promote paid features, because then Stickers would become useless

i guess i have to make a gif wrapper aswell

https://embed.moe/image.gif?q=https://jpegxl.info/anim_jxl_logo.jxl

discord not only checks the image itself, but it also requires the path to be a gif to embed a gif

WebM/VP9 next? 🙂

that's way too heavy

Is there even a need for it?

VP9 is natively supported in Discord 🤔

animation to vp9 i think

or just use tenor <:kekw:808717074305122316> h264 = gif apparently

useful/not?

whoa! is that a new discord feature or a modded client?

i wouldnt say new

commands and interactions have been around for a while

ooh, i've seen commands but i just hadn't encountered a bot using the context menu thing yet

Cool!

if you want to add it https://discord.com/oauth2/authorize?client_id=902036286074925096&permissions=277025704000&scope=applications.commands%20bot

does it store another copy of the image on the web other than the one you send to discord?

it caches the decoded image for an hour

what does it means

i can't embed

useless

<:Thonk:805904896879493180>

on my server i can embed because i'm the admin

but i don't know if i really save internet bandwidth in this way or image get stored on internet two times

<@!288069412857315328> answer

you wont save internet bandwidth

ok but can be enabled fo eveyone in sev without admin pemission

admin confims it

i upload a jxl and eveyone see in full screen

also why don't you extend to avif?

because i dont feel like it

avif decoder is heavy?

so i confimed the bot on my seve

if someone upload jxl will be seen on full screen

or i have to extend it (as admin

<@!288069412857315328>

stop pinging me

so i confimed the bot on my seve if someone upload jxl will be seen on full screen or i have to extend it (as admin

done

wb it woks

i can do it

https://embed.moe/https://cdn.discordapp.com/attachments/803663417881395200/902537817895338024/unknow88n.png.jxl

32 seconds total after uploading

Not sure why you would need an extra tool... https://videocardz.com/newz/nvidia-launches-image-quality-comparison-and-analysis-tool-icat

it seems that cjxl only copies exif, not xmp, but only if -j, not if png input or bit-exact jpeg transcoding. what's up with that?

it should copy exif and xmp in all cases of png and jpg input, but maybe something is broken?

note that there might be a few different ways to add exif/xmp to png and maybe we only support some of those ways - it's not standardized very well how to add metadata to png

right, i can understand if exiftool prints xmp but cjxl doesn't understand it, but it is odd that cjxl detects xmp but only in some modes, and always detects exif. if -d 1 secretly disables metadata (since it is no longer accurate after reencoding) then i would expect it to affect xmp and exif equally

It is not intentionally stripping anything unless you do cjxl --strip

so concretely, if i run `cjxl image.jpg` and it says `Encoding [Container | JPEG, lossless transcode, squirrel | JPEG reconstruction data | x-byte Exif | y-byte XMP], 12 threads.` (where x and y are integers) and then run `cjxl -d 1 image.jpg` and it says `Encoding [Container | VarDCT, d1.000, squirrel | x-byte Exif], 12 threads.` (where x is the same integer as previously) that's a bug?

Yes

That's a bug in cjxl not copying the xmp for some reason in that code path

actually looking at the code now, i'm not sure how xmp gets read in the first place

er, wait, i lost track of where i was.

so DecodeImageJPGCoefficients is DecodeImageJPG which is not DecodeImageJPG :/

anyways, SetBlobsFromJpegData reads exif and xmp. it is called via DecodeImageJPGCoefficients -> jpeg::DecodeImageJPG. in jxl::extras::DecodeImageJPG, exif is read by ReadExif

There are weird things happening when I tried to re-build libjxl in Squoosh based on the latest git `4413553`. It's complaning about something related to skcms... ``` Building CXX object lib/CMakeFiles/jxl_dec-obj.dir/jxl/toc.cc.o /emsdk/upstream/emscripten/em++ \pm:load:cleanup -O3 -flto -std=c++17 -Wno-deprecated-declarations -pthread \ -O3 -flto -s FILESYSTEM=0 -s PTHREAD_POOL_SIZE=navigator.hardwareConcurrency -s ALLOW_MEMORY_GROWTH=1 -s TEXTDECODER=2 -s NODEJS_CATCH_EXIT=0 -s NODEJS_CATCH_REJECTION=0 \ -I node_modules/jxl \ -I node_modules/jxl/lib \ -I node_modules/jxl/lib/include \ -I node_modules/jxl/build/mt-simd/lib/include \ -I node_modules/jxl/third_party/highway \ -I node_modules/jxl/third_party/skcms \ --bind \ -s ENVIRONMENT=worker \ -s EXPORT_ES6=1 \ -o enc/jxl_enc_mt_simd.js \ enc/jxl_enc.cpp node_modules/jxl/build/mt-simd/lib/libjxl.a node_modules/jxl/build/mt-simd/lib/libjxl_threads.a \ node_modules/jxl/build/mt-simd/third_party/brotli/libbrotlidec-static.a \ node_modules/jxl/build/mt-simd/third_party/brotli/libbrotlienc-static.a \ node_modules/jxl/build/mt-simd/third_party/brotli/libbrotlicommon-static.a \ node_modules/jxl/build/mt-simd/third_party/libskcms.a \ node_modules/jxl/build/mt-simd/third_party/highway/libhwy.a em++: error: node_modules/jxl/build/mt-simd/third_party/libskcms.a: No such file or directory ("node_modules/jxl/build/mt-simd/third_party/libskcms.a" was expected to be an input file, based on the commandline arguments provided) make: *** [Makefile:39: enc/jxl_enc_mt_simd.js] Error 1 make: *** Waiting for unfinished jobs.... ```

That was clean compile, with the whole Squoosh repo removed completely from drive and re-cloned from remote.

Surprisingly enough v0.6.1 worked...

<@&803357352664891472> <@228116142185512960> is it something related to libjxl or Squoosh?

no idea but it looks like a build script problem if you get `No such file or directory`

No idea either. Just like I said, those were clean compiles from clean directories, both v0.6.1 and latest git.

What formats can be used to for CMYK images in cjxl?

Atm only PSD

And it probably only works if you don't try to use XYB, e.g. lossless should be fine but vardct probably not

cjxl can do PSD? That should probably be added to the help screen.

It's kind of experimental and partially implemented only

I added it to test layers, spot colors and cmyk, since we didn't have any input format for those things yet

fair.

is there a tool that prints information about a jxl file? some specific things I'm interested is if the image is modular/vardct and if it's progressive or not. I tried jxlinfo and exiftool but no dice. jxlinfo prints just some very basic information like height and width and exiftool only reads data from the exif chunk

Modular/vardct and progressive is not currently exposed in the API

So jxlinfo does not know

Uses_original_profile is maybe more useful info than modular vs vardct

If true, it's possible that the file is lossless

If false, it's certainly lossy

Ah, okay. But a decoder should know the encoding type, right? I was checking the format draft and frame header does contain at least a field for the encoding type

A decoder would probably also need to know if the file is progressive or not, I looked into the documentation and there seemed to be at least four different types of progressive encoding so it was not super clear to me how it works under the hood 😅

Modular vs vardct is a frameheader field, we could expose it, just not sure why it would matter from an application pov

Progressive decode works in the sense that you can send partial data and call Flush to get progressive previews.

We are adding an subscribed event so you can also get intermediate stages explicitly

But yes, it might also be good to expose info about what stages will be available and when (what byte offset)

This is possible to know after decoding the frame header (including toc)

I would think it would be useful for graphic designers and developers to be able to see at a glance if it's lossless or lossy.

The only thing we can tell is "certainly lossy" and "maybe lossless"

I think it could be useful to have that info since it's not something you can tell right away from the file extension like with JPEG and PNG. I think this "problem" started with WebP

Right now I'm debugging a library I'm working on and the way I validate that different encoding options like quality/losslessness/progressive are passed correctly is I run cwebp/convert/vips jxlsave with the same parameters and check that the MD5 hash matches

Because JPEG and PNG are different formats, not just modes and further JPEG formats also had a lossless mode

and some PNGs are recompressed from lossy sources

The original JPEG spec had a lossless mode. The IJG libjpeg didn't bother to implement it though, so it didn't become part of the de facto standard.

how good was that lossless mode, by the way?

if it was added to libjpeg today, would there be any point in using it?

Also most PNGs that Cloudinary serves on the web are lossy ones - we either reduce to png8 or do some preprocessing to make png24/32 compress better.

(I suppose that if the answer was “yes”, it would probably have been added, so I guess not)

It sucks, it's basically same as DC encoding so just a West predictor and Huffman coding of the residuals, iirc.

Still better than the alternatives of the time though (BMP and TIFF)

I think it mostly didn't get implemented because people didn't have full-color screens anyway, only at most 256-color ones, so GIF was better as a "lossless" format.

the human eye can’t see more than 256 colors anyway

Nah, we all know 64 is the limit

640 colors ought to be enough for anybody

I did some oppo research and it seems like imagemagick identify doesn't know if webp is lossy or lossless, only if it's paletted or RGB (I think webp makes a file paletted if it has less than 255 colors or something)

Here's output for webpinfo ``` webpinfo lena-lossy.webp File: /path/to/file/lena-lossy.webp RIFF HEADER: File size: 37998 Chunk VP8 at offset 12, length 37986 Width: 512 Height: 512 Alpha: 0 Animation: 0 Format: Lossy (1) No error detected. webpinfo lena-lossless.webp File: /path/to/file/lena-lossless.webp RIFF HEADER: File size: 416526 Chunk VP8L at offset 12, length 416514 Width: 512 Height: 512 Alpha: 0 Animation: 0 Format: Lossless (2) No error detected. ```

Note that near-lossless webp will also look like lossless

**jxl, lossy, lossless and progressive:** I'm currently writing a library for converting images to jxl and I want to have some sane defaults. Right now if the user specifies lossy compression, progressive encoding is turned on by default. If the user specifies lossless compression, the progressive is turned off by default. My reasoning is that progressive lossless jxls are much larger than non-progressive ones. Is this a good default or not? I think a progressive lossless image *can* be smaller than a non-progressive one if the client downloads only part of the image. But there doesn't seem to be any browser/client that supports this currently.

and by lossy I mean vardct and lossless modular 🙂

> Is this a good default or not? id say yes, that's the same default as in cjxl

it uses squeeze for progressive modular iirc and that's quite less efficient

ok, great that I'm not doing anything that's not smart

now I just need to wait for imagemagick and vips to add support for progressive encoding, since I want to support using those as a backend too in addition to cjxl 😅

Current easy way to encode a list of png files into a looping jxl animation?

maybe `ffmpeg -i frame%d.png input.apng; cjxl input.apng output.jxl` works, I dunno

Nice. Also very pleased to see prebuilt linux releases, so I don't have to hunt down a ton of dev libraries. amd64 Ubuntu here.

Also thumbnailer package = Nice.

Works except for APNG with transparency I get this. ``` cjxl ./test.apng output.jxl -v JPEG XL encoder v0.6.1 0.6.1 [Scalar] Corrupt or CMYK JPEG. Failed to read image ./test.apng. ```

Created using `ffmpeg -pattern_type glob -i "*.png" test.apng`

we have some limitation in the current apng reader, maybe we should get rid of it because it's annoying

<@!179701849576833024> Just curious, any specific reason you couldn't just copy & paste APNG support over to fjxl?

not really

just wanting to stick to single-image, single-file encoder 😛

<@!179701849576833024> Are there noteworthy parts of fjxl that can be used for other modular JXLs? Like a faster lossy palette?

modular jxl encoder performance is a bit of a dumpster fire 😛 even if you don't do tree learning, it's still quite worse than it could be

<@!111445179587624960> Can you share a newer fjxl version that has veluca's train fix?

do you have it fo sse3

I find it's also possible to do `cat *.png | ffmpeg -f image2pipe -i - -f apng anim.apng`

"quite worse than it could be" sounds far better than "cannot be made faster"

veluca has a PR, wanna test it? https://github.com/libjxl/libjxl/pull/1058

Feel free to share newer versions, should you build them.

Lol, Windows Defender doesn't like that file <:KekDog:884736660376535040>

Modern AV software don't like fresh unsigned executables.

The SmartScreen is basically a thing which prevents you from running programs which were executed not frequently enough by many people.

When enough people choose "run anyway" for a fresh program, it may consider to not prevent running the program.

If you want to avoid this thing completely, you need an EV signature from an organization for that executable.

If you have just a IV certificate (which is given to individual programmers) and sign your software with it, the SmartScreen still can complain and prevent your programs from running 😦

That seems like a crude way to detect malware. I would assume that either the threshold is low and it's easy for malware makers to get enough people to choose "run anyway", or the threshold is high and it becomes very annoying since a lot of legit software gets blocked

i imagine the threshold is high because most users probably don't run unsigned executables very often

not to mention unsigned executables that a lot of other people don't also use

Yeah, that's a horrible thing

Some people trust it and don't run a program when it complains

I consider buying an IV certificate for 10 years with hope that it will learn that software with my signature is never malware. As far as I know, it will complain when both your certificate and program are new, but when it learns about your signature a bit more, it should start to trust your software a bit more, so should be better.

645$ for 10 years: https://www.ssl.com/certificates/code-signing/buy/

But you need an EV signature to get instant trust from SmartScreen and similar stuff 😦 IV or OV should make it better, but not 100%.

sounds like scam business tbh

It would be not that bad if the EV certificates were cheaper (now it is 250+$ a year https://www.ssl.com/certificates/ev-code-signing/buy/) and available for individual programmers.

Sorry for the offtopic 🙂

My website once even was banned by Google because some stupid AV considered one of my programs as suspicious, and a lot of other "security" software import data from Google Safe Browsing, so some sofware like Malwarebytes started to block my website completely.

https://github.com/vrubleg/soundkeeper/commit/02b8f25dfbbd252a2ae6827dd0ee48a026ee534c

I had to make this unnecessary change just to please Google

All the requests to review their decision (with link to the source code, etc.) were automatically rejected. Only replacing the file with "less suspicious" version and waiting for some time helped. After this, I had to write to some companies like Malwarebytes to unban my website. Horrible experience. That's why I hate modern AV software.

Sorry that I'm that talkative. I was triggered by that message related to SmartScreen. It is my sore spot 🙂

the joys of developing windows software

It is even worse for MacOS. It is not that easy to install unsigned software there. You need to make a special dance for it 🙂

also probably good idea to have separate domain for binary distribution

Last time I used a mac, double clicking on an unsigned app would produce an error, but right clicking and using open reduced it to a one time warning you could bypass

making progress on my lossless PSD to JXL recompression tool

`Converted 75873293 byte PSD to 27718794 byte JPEG XL`

encoding time?

This one was with -e 3

The psd parsing code and stuff is not optimized yet, first need to make it correctly deal with at least all the cases that matter

PSD is a very hairy format and it has many features, so just extracting the pixel data isn't that trivial

(in the tool I also try to decode it again to PSD to verify that it actually roundtrips bit-exactly)

Unity engine supports PSD, but shipping a bunch of textures that way inflates the install size rather quickly. I wonder if JXL PSD recompression could slot into that use case.

Some results on lossless PSD recompression using general-purpose compression and using JXL: Original set of 10 PSD files: 345.88 MB Compressed with ZIP: 223.18 MB (takes 18 cpu seconds) Compressed with brotli effort 4: 212.72 MB (takes 9 cpu seconds) Compressed with brotli effort 7: 190.92 MB (takes 53 cpu seconds) Compressed with brotli effort 8: 183.93 MB (takes 1m35s cpu time) Compressed with brotli effort 10: 148.64 MB (takes 10m32s cpu time) Compressed with jxl effort 2: 127.66 MB (takes 52 cpu seconds) Compressed with jxl effort 3: 108.82 MB (takes 1m32s cpu time) Compressed with jxl effort 7: 99.40 MB (takes 6m58s cpu time)

Is this file exact lossless recompression, or just pixel exact?

File exact

There is a lot of non-pixel stuff you also want to preserve in PSD files

Pixel exact is even hard to define when there are things like layer fx

Very true.

That is pretty cool then. Its a little slow for directly saving, but could be nice for archiving.

He did not tell us the size of the images.

Yep, still not fast enough, especially for large projects and something like FJXL `-e 3` variant would also be useful for this use case (also for GIMP, PDF, etc. and also it may not always be photo-like content)

libjxl -e 2 is probably fast enough for this, memory is a bigger issue with libjxl encoding atm (it's using about 20 bytes per sample, so 80 bytes per pixel atm...)

`-e 2` is something like 5 seconds on average per project, I think it is acceptable to have up to 2-3 seconds for compression (depending on the hardware and project size and also some time may be taken by other things besides compression), although this usually happens in the background, but still For memory consumption, I think it would also be useful to have some sort of fastpaths for 8 (10/12/14 depending on format support) bits images

PSD only has 8, 16 and 32 bit

Photoshop save operations are in the background and some PNG saves are **really** slow already. Just sayin’

we should at some point make an -e 2 that doesn't do global histograms but per-group ones; then it would perfectly parallelize and be a lot faster on a typical machine running Photoshop

I'm looking for a way to convert existing images to jxl.

Google search reveals shady websites.

What? My Google search returned MConverter (which works and isn't shady for me) and jpegxl.io (author of which, <@439539398657441832>, is on this server) as first results.

You can use squoosh.app by Google devs if you want to convert one by one in your browser (offline in WebAssembly, not server-side), or you can use an executable, write a batch script and do it natively without a browser and on a mass scale.

Ey 😦 There's no Eminem on jpegxl.io ...unfortunately.

XnConvert supposedly supports jpeg-xl now too. https://www.xnview.com/en/xnconvert/

*Brub*

Oh ok

I just oom'd on my phone lmao

Ok maybe i should do this on pc

thee's no app

only cmd command

and the new encode is a demo

https://chafey.github.io/libjxl-js/test/browser/index.html

you need to wait libjxl 1.0

and ffmpeg integation

to be sue app like aves in a phone could ead jxl

when you need it put this

https://artifacts.lucaversari.it/libjxl/

in a folde with the gui app

jxl isn't still adopted

`PNG1 cjxl-> modularJXL djxl-> PNG2` I get the icc profile in PNG2, how can I avoid this?

I write an exif comment to PNG1 before encoding, if that matters, but only the comment, nothing else.

djxl always writes colorspace info in output pngs to make sure it's not ambiguous

you can strip that with `convert PNG2 +profile * PNG3` or something like that iirc

but why?

I have a bunch of important pngs that I encoded to lossless jxl. Then I decoded them to png and compared to the originals. Because of the icc profiles inside the resulting pngs and the originals don't match. So I have to strip the icc profiles from the resulting pngs before comparing. The images are hi-res and there are a lot of them, so it takes unnecessary extra time.

I thought https://github.com/libjxl/libjxl/pull/270 should have solved this, would you maybe have a pair of {original png, compressed jxl} to share for investigation?

<@!604964375924834314> I feel completely stupid. With today's `libjxl` I can't reproduce the problem on the same image as yesterday. `ssimulacra` finds no difference, but yesterday it showed 0.1

I will try again to encode and compare a group of images. If `ssimulacra` finds differences between the original and the resulting png, I will share them.

don’t beat yourself up, it doesn’t look like that PR has actually made it to a stable release yet

so if you were using v0.6.1, it probably didn’t have that change

which ssimulacra are you using? the one from libjxl is fine, the original one ignores colorspace info and assumes input is sRGB, so that won't help you

I use the latest git version of `libjxl` tools, which I build myself almost every day, including `ssimulacra`.

Besides the fact that yesterday `ssimulacra` showed a difference of 0.1, the resulting png was also displayed in Edge with a brightness different from the original image. But when I removed the icc profile, the images became the same.

I need more tests with more images to be sure.

what is likely happening is that it was (incorrectly) ignoring the gAMA chunk in the original PNG, but (correctly) taking the equivalent ICC profile into account in the decoded image

the change in #270 makes it so that it’s at least consistently (in)correct at both ends

but it doesn't...

I saw that someone was looking for help with batch conversion of images (like a month or two ago lol) in another channel, so I wanted to share my batch script in case it helps anyone. Depends on ImageMagick, and `convert` being on your path. ```bat @echo off REM run convert -version to raise the ERRORLEVEL if 'convert' is not found echo Searching for convert (from ImageMagick) convert -version REM convert was not found if ERRORLEVEL 1 ( echo convert was not found on your PATH. echo Please install ImageMagick and add convert.exe to your PATH. REM Exit the batch script exit /B 1 ) REM Definitely I missed some file types, if it's not converting (insert REM image format here), add the extension here. for %%G in (.jpg, .jpeg, .jfif, .tiff, .png, .webp, .bmp) do ( echo converting %%G files... REM Loop over files in this directory and convert them all to jxl. REM Your homework is to make this recurse if you're looking for that. forfiles /M *%%G /c "cmd /c convert @file @fname.jxl" ) ```

it seems reasonable but i think it won't work for file names containing whitespace

i think in powershell it should be something like `get-childitem -include *.jpg -include *.jpeg -file | foreach-object convert $_.fullname $([System.IO.Path]::ChangeExtension($_.fullname,".jxl"))`

then just stick a -recurse on the front if you want that

also afaik there's no need for cmd /c there

pwsh7 ```PowerShell ls *.jpg,*.jpeg -af | % -ThrottleLimit 4 -Parallel { cjxl --quiet $_.FullName ($_.FullName -replace '\.jpe?g$','.jxl') } ```

works for files with ws in name

think it's because * will select anything with ws and honestly I'm ngl I don't know why @fname works. Maybe it subs in quotes if it's got whitespace in it already?

~~perhaps batch doesn't require you to quote every expansion like SH~~

<@853026420792360980> Basically, I'm trying to take high bit depth screenshots inside of mpv, but it's not working according to jxlinfo(and the fact that a JXL compressed PNG is quite a bit larger): https://cdn.discordapp.com/attachments/652991792106438686/969398784419332096/mpv-shot0001.png ```jxlinfo /home/bluezakm/mpv-screenshots/mpv-shot0001.jxl JPEG XL file format container (ISO/IEC 18181-2) JPEG XL image, 1920x1080, (possibly) lossless, 8-bit RGBA Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative frame: full image size``` HBD version of that image compressed by JXL: https://cdn.discordapp.com/attachments/652991792106438686/969401463967211590/mpv-shot0002.jxl ```jxlinfo /home/bluezakm/mpv-screenshots/mpv-shot0002.jxl JPEG XL image, 1920x1080, (possibly) lossless, 16-bit RGB Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Perceptual frame: full image size``` mpv config: ```screenshot-format=jxl screenshot-jxl-distance=0 screenshot-directory=/home/bluezakm/mpv-screenshots/ screenshot-tag-colorspace=yes screenshot-high-bit-depth=yes```Git everything: mpv, ffmpeg, libjxl.

Sorry, it's just that I think this is a better place than IRC to discuss about this.

Does the ffmpeg jxl integration set the bitdepth in the basicinfo?

One potential confusion is that passing data as uint16 will automatically encode the data as uint16. It doesn't. The data will be encoded as set in the basicinfo. The pixelformat for buffer passing is just for passing the buffer, so you can encode 1-bit images by using float buffers if you want, or even the other way around.

I'm not sure on that.

Anyway, I think I found a way to fix it.

yes, but the issue here is that it declares what pixel formats it supports

so it declares that it supports rgba64

if it declared that it supported 10-bit RGB then it would have to convert it via swscale before feeding it to libjxl

since libjxl realistically only supports 8-bit and 16-bit input

what do you mean by "it's not working"

It doesn't encode to high bit depth.

that looks like it's doing exactly what is intended

`screenshot-high-bit-depth=yes` does that provided that the input is > 8 bits

Yeah, but the input is indeed >8b(10b).

post a sample

because I tested that and it works

Here's another small sample you can test with. Output that libjxl gives me(first frame):

appears to be an mpv bug

setting `screenshot-sw=yes` makes it work properly

note that if you have `screenshot-sw=no` then it uses `rgba64be` for the PNG, and with `yes` it uses `rgb48be`

It might be this conditional return that is the issue: https://github.com/mpv-player/mpv/blob/master/video/image_writer.c#L326 ```bool image_writer_high_depth(const struct image_writer_opts *opts) { return opts->format == AV_CODEC_ID_PNG; }```

the think you linked doesn't show what you probably want it to show

that's just my commit

Fixed: https://github.com/mpv-player/mpv/blob/master/video/image_writer.c#L326

I had planned to do a very quick PR with this change but I wanted to check with you first if it was the right way to do it: ```diff diff --git a/video/image_writer.c b/video/image_writer.c index d12394a5a9..e01cc837f4 100644 --- a/video/image_writer.c +++ b/video/image_writer.c @@ -325,7 +325,7 @@ const char *image_writer_file_ext(const struct image_writer_opts *opts) bool image_writer_high_depth(const struct image_writer_opts *opts) { - return opts->format == AV_CODEC_ID_PNG; + return opts->format == AV_CODEC_ID_PNG || AV_CODEC_ID_JPEGXL; }```

well that doesn't work

even if it compiles

``` return opts->format == AV_CODEC_ID_PNG || opts->format == AV_CODEC_ID_JPEGXL; ```

you'd also have to guard it with the appropriate ifdefs

I can raise a PR for this, gimme a sec

in the short term you can just use `screenshot-sw=yes`

which works as expected

<@321486891079696385> https://github.com/mpv-player/mpv/pull/10147

It works! Everything LGTM 😄

hello! anyone been able to use the cjxl tool in Linux with GNU Parallel?

just to speed things up

Yes: `(find -type f -name '*.png') | parallel cjxl {} {.}.jxl --num_threads 2`

<@321486891079696385> thank you 🙂

it will not necessarily be faster

It will be faster.

Per file threading is always faster since it has practically infinite scaling.

it's usually better to set `--num_threads 0` when using gnu parallel

which disables threading

Did a quick benchmark to check efficiency of `--num_threads 0` (results are an average of 3 runs, files on tmpfs) Having 4-core 4-threads CPU, it indeed seems better to run `--num_threads 0` with `-j ${cpu_count}` jobs in parallel

if you totally ignore caching.

just so you know, num_threads=1 is basically the same as num_threads=0

if `num_threads=N` where `N > 0` what it does is it creates `N` worker threads and one control thread which doesn't do decoding, just coordinates

whereas `0` just disables threading

so for `N=1` you end up with one control and one worker, which has no gain over just not threading