JPEG XL

(but djxl is *not* part of the core libjxl library anyway :P)

What's the reason for not putting dithering in the uint8 output path of libjxl?

What is "core libjxl library" then?

Weren't you included in those discussions? 😄

lower-than-8-bit back than is like lower-than-16-bit now ;)

just the C library that does the decoding

of just jxl

`djxl` can have more dependencies, e.g. a CMS, and code to write to various formats

that you can implement it with the callback-float-output, and that often you'd need to do it *after* a CMS, say...

Why have a uint8 output at all then?

Can also implement that with the float output, after all

<:This:805404376658739230> 😁

eh, because we didn't have callbacks

xD

Presumably, if you do uint8 output, it's either because you're planning to reencode to some 8-bit format (or 8-bit mode in a format that could also do higher bit depth), or because you hope to get things in the display space and can just blit them to the screen without color management

also, because I didn't want to discuss too much

it's not going to be used in Chrome anyway, and currently we're focusing on that

Sure but for viewing apps that use the uint8 output (and for djxl) it would be quite useful to avoid banding

let me rephrase my statement: we are not going to add dithering to libjxl *now*

I think we should either get rid of the uint8 output, or do the best possible uint8 output (or at least some fast approximation if the best possible thing)

Ok, not doing it now I can live with 😁

Me too, but I will keep being sceptical about how much control Chrome has over JXL...

ideally at some point we'll add a wrapper around libjxl to which you tell your display color profile and that wrapper takes care of things for you

how so?

Yes, a convenience libjxl-with-cms sounds like a really good idea to make it easier for applications to avoid messing up

(of course there will still be applications that are too lazy to figure out the display space and just claim to be sRGB all the time, but we cannot really stop that)

(unless we find a portable way to get the display space and use that by default)

haha

nice joke, that one

You are paid by Google. <:YEP:808828808127971399>

indeed, but I don't quite understand what exactly you are skeptical about 😛

(Jon isn't, FWIW)

Yes, but he's the only one from externally and apparently also wasn't considered in all decisions. 😉

Nothing was decided except what the google folks are going to work on this week, afaiu

Which is fine, I am not their manager 😂

yes 😛

So all this fuss for nothing? 😞

the code is there, we know it works, at some point when we're less on fire we'll think about what to do for it exactly 🙂

It would have been nicer if more people were involved in jxl development; maybe when we have moved to a public dev repo that will get better

Originally the chair of the jxl AHG was a Netflix guy, btw

(another argument against dithering in the core libjxl is: why *that* dithering and not *that other one*?)

Sure, but "no dithering" is also a kind of dithering, namely the worst kind 😁

eh but that's a weaker argument 😛

Anyway, for now people can do djxl --bits_per_sample 16 and do whatever dithering they like. We can later figure out a good dithering to do by default for uint8 output, and add it to both the end of the chrome/firefox/viewers' rendering pipelines (after color management and rescaling), and to djxl with 8-bit output.

after rescaling in chrome/ff: yeah, no

It's not the most urgent thing, but by the examples I saw I do think it can help to get more out of the 8-bit displays that are currently still very much the norm. Especially now they're moving to wider gamuts...

image decoders give you u8s or f16s, at the original resolution, and the scaling is somewhere deep in the guts of the possibly-GPU-accelerated page rendering

I suppose after color management things go to the gpu as 8-bit RGBA?

yep

Yeah so if there's not much rescaling happening, the info is already lost

<@!794205442175402004> I guess it's not possible to fix every mistake of the past. ;)

Actually, it is possible. Windows 11: 10-bit minimum display spec in 2035 🤣

the problem of 8-bit buffers is that having "deeper" buffers actually costs a nontrivial amount of memory

If there's enough downscaling, then dithering can still be done even if the source is already 8-bit, but not going to happen/controllable if hw rescalers are used...

<@!111445179587624960> do you please have 9a8f5195 generic builds? thanks. i want to test how it add sharpness to image

now i'm testing contrast with the one more recent

10-bit RGBA could theoretically be done in 5 bytes per pixel, costing only 20% more...

How is it done for HDR?

you take the hit of 8 bytes per pixel 😛

The displays are only 10-bit though

as for 10-bit: then you get funny alignment issues, and I have no idea how much GPUs actually like that

nah, f16 for those

at leas in chrome

Maybe the driver wants f16, but the displays themselves take 10-bit PQ or HLG, afaik

btw, did you know that now you can have *lossy compression* between your video card and your display? 😛

Does HDMI have lossy modes?

apparently yes

https://vesa.org/vesa-display-compression-codecs/ They provide efficient compression and **visually lossless** quality for consumer and professional products.

8bpp and 6bpp 🤔

That is possibly quite lossy

I mean there must be patterns where it is not visually lossless

Because of pigeon holes and stuff

😁

If it's a fixed bpp that means it is probably like those texture formats

The "download the spec" doesn't seem to have a link though

ah, yes, just the text “Download Now”

almost as if an instruction

— Download Now! — But… but… I don’t know where! — I SAID

https://glenwing.github.io/docs/VESA-DSC-1.2a.pdf

Found something

(not on that page though)

It's fancier than what I expected, even has a little color cache thing like webp!

Does encode 3 pixels per group (which gets encoded to exactly 3 bytes, so 8bpp)

Would be fun to make a noise image that has some low freq thing visible when seen uncompressed that disappears when using DSC 1.2a

Maybe some of the <#824000991891554375> already has that property 😁

cjxl.exe v0.3.7-6-g30ea86a The problem with temp jpeg files not being deleted still persists.

how do i force jpg -> modular encode?

-j -m right?

I think so

oh `-j`

forgot about that one

sorta expected `-m` to already assume that

I'll tell you a secret: the cjxl command line is a mess 😛

heh yeah `-m` ended up smaller

Really?

must be one weird JPEG

Using lossless modular?

Or lossy

kinda funny how some pixiv jpegs are so quality that they compress better with modular

lossless

~~time for more heuristics~~

can you share?

uhh id have to find another one this one is lewd

but i wouldnt be surprised that a lot of stuff if encoded with jpeg q 100 would result in something like this

But legitimately, it may be nice to have a heuristic when you tell cjxl to compress a jpeg and remove metadata/reconstruction data that can tell you if it would compress better with modular or lossless jpeg

Since you're already removing the reconstruction data

is it anime-ish?

Ohhh

That's why it's working

He said it was from pixiv

Essentially exclusively anime

yeah definitely anime-ish

Japanese art site

ok, then I'm not surprised 😄

wonder if it's an RGB or YCbCr JPEG...

Can cjxl transcode from jxl to jxl?

nope

That would be useful in the future

Especially when we have files from now

In the future when cjxl gets more improvements it would be useful to take an older jxl and transcode it to give it the new improvements in coding

For lossless you can do that, for lossy not really

ehhhh, takes more wok than we have time ATM 😄

Lossless is mainly my goal

Lossy yeah you can't retrieve data that's already been thrown away to do a better encode

Main priority right now is making browsers decode all kinds of jxl as well as possible

Seems to be going well

Then I guess we'll turn to support in viewers and authoring tools

I think adoption is faster than avif was originally

Maybe similar

Avif stopped at the "decode once full bitstream is available" stage, which is reasonably easy to implement

Since today we have incremental decode too, which is already an improvement.

Progressive would be even better, but is some more implementation effort.

<https://www.pixiv.net/en/artworks/89893232> happens with this one too

from something i can't post on discord to something i almost could

Btw, about improving image compression and progression is not needed in today's world

that was faster for me but wasn't unnoticeable either

Yep, not all sites have CDNs around the world or good speed and transport routes to every client

though i could squeeze it down to fit but i guess that aint going to happen ``` 8.5M 89893232_p0.jpg.s9e3i1m.jxl ```

that's going to be pretty slow to decode...

rule of thumb: VarDCT images will decode 20x faster or more than modular images

it was really (like really really) slow to encode so I wouldn't be surprised

Well decode speed should still be a lot better than that encode speed, lol

Could also do slightly lossy vardct encode, -d 0.5 or so

Probably smaller than modular, and not much more lossy

(decoding jpeg to pixels and encoding those pixels losslessly is a slightly lossy thing to do anyway)

not that much more lossy than decoding jpeg to pixels on the screen

but yes somewhat

Someone should submit an issue "Decrease cjxl command line mess", right? 😜

😛

you will not get smaller anyway than for %i in (C:\Users\User\Documents\xs3*.png) do cjxl -s 6 -q 63.52 --epf=2 -p --gaborish=1 --patches=0 --dots=1 --use_new_heuristics %i %i.jxl

modular is less efficient

for jpegs

and do too much research

Why do you want to use modular for jpeg.

me not

Someone should submit a PR <:Poggers:805392625934663710>

Nooo. I like having more flags

it's for the third image, if you pass one

mmmmmhhhh, if I remember correctly that's an annoyance of compiling compare_images with skcms instead of lcms

I *think* you can fix it by passing -DJPEGXL_ENABLE_SKCMS=Off to cmake

but I'm not sure

<@!604964375924834314>

I do wonder what is wrong with using skcms, but I fear we have more pressing concerns that that xD

making sure our decoding lib is as good as it could be in the next 3 weeks

(mostly in terms of memory usage and proper support for progressive decoding)

v0.4 is what we have today, basically

it's feature-complete, bitstream-wise, but the quality of the implementation of some features... let's say could be improved

0.4.x is mostly 0.4.0 but without a bugfix or two

I had come across that bug with compare_images+skcms but hadn’t figured out the cause — after all, it’s fine in djxl

it’s rather puzzling

maybe I’ll investigate deeper at some point

possibly some slightly negative value that wrecks havoc somewhere (wrapping?)

<@!416586441058025472> jpegxl-44778c69-master [v0.3.7 | SIMD supported: AVX2,SSE4,Scalar]

do you have also 100e3c7e

please

i will not look into actual difference

i will only convert a photo

<@!416586441058025472> I find a old cjxl on my Program Files 20210520 create, I can't guarantee this version is 100e3c7e.

old cjxl

100e3c7e is older, use 44778c69

ligcc compiler i don't have

sorry for the font

i did wrong

i'm thinking of -q 70,05 --epf=1 --dots=0 --resampling_2

i need like mozjpeg q 32 and separate chroma quality 15

but in higher fidelity

i want to distort image on purpose

to look better on the selfie

i did photo with a flash and hdr and with a sony dsc wx60

2013 camera

why is giving that error?

you can try jpeg xl 44778c69, I think this sync don't have much quality change.

ah it was compiled in windows 10

I using windows 10 64bit

but is relative to windows 10 or because it's compiled using newer version of compilers?

is fault of windows 10 or of the version of the compiler?

msys2-64 mingw64 clang

mingw-w64-x86_64-clang 11.0.0-8

i downloaded another person build

and is not starting

same error

You using windows 7 32bit or 64bit?

64 bit

but i do not have any compiler installed

no msys

i uninstalled them

I think you can try Scope avx only version? https://encode.su/threads/3564-JXL-version-0-3-released?p=69684&viewfull=1#post69684

ok i did

for %i in (C:\Users\User\Documents\67\*.jpg) do cjxl -j -q 91.832 -s 8 --faster_decoding=7 --dots=1 --gaborish=0 --patches=1 -p --epf=2 --use_new_heuristics %i %i.jxl

and now i open squoosh and i do avif q 16

with default effort and settings and that encoder

no idea what that combination of options actually ends up doing

it's a combination that does not make a huge amount of sense to me — why epf 2 but gaborish 0?

jpeg xl encoder fuzz test?

it's good to find bugs there in the sense of combinations that make cjxl crash or do something wildly bad

pretty sure dots and patches do nothing with the new heuristics either

but for quality comparisons please don't use weird non-default options, it is likely not to give good results

-s 8 likely doesn't do much too

faster_decoding=7 doesn't mean anything different from =4 😛

and I don't know if you can even disable gaborish with the new heuristics...

probably yes

i used 12052021

to convert a selfie

that i compressed with avif q 16

i got a 16 mpx 31,6 kb AVIF image

Use image editing programs then.

its a bit of a problem

I have no idea what may cause it, honestly... I don't recall any part of our encoder that creates jpeg files 🤔

Probably libjpeg(-turbo)

We get these tmp files

They are basically the source images

<https://github.com/libjpeg-turbo/libjpeg-turbo/blob/main/example.txt> > * 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. > * (Note that temp files are NOT needed if you use the default parameters.) > * On some systems you may need to set up a signal handler to ensure that > * temporary files are deleted if the program is interrupted. See libjpeg.txt.

So this could come from ffmpeg when decoding jpegs ?

I don't know, but maybe from libjpeg-turbo or some other libs

So we just need the encoder to call libjpeg-turbo with some parameters that don't create tmp-files, or at least have libjpeg-turbo clean up after itself. Dunno, maybe this "maximum memory setting" is set to zero. 😄

Hello! Multithreaded optimization for cjxl seems to be... just average I guess. I am currently converting very large files in lossless (modular) mode and I noticed at best one or just two threads are being used. Is there any plan for further optimizations?

also it would be great if I can convert tiff files to jxl directly instead of using png as interim format.

More optimization is possible, but note that to some extent, optimal encoding has inherently sequential parts. Fast, non-optimal encoding is easier to parallelize. So the difference between -s 2 and -s 9 will be quite large.

ImageMagick should support this.

We are not aiming to read all possible input formats, cjxl is not ImageMagick

The input formats that are there, are there because we needed some kind of input for testing that we couldn't get from other formats

For basic still images, PNG input is ok. Or JPEG for lossless jpeg recompression. PPM can do non-power-of-two bitdepths. PFM can do floats. EXR can do half-floats. GIF can do animation. APNG can do it with full color and alpha. PSD can do layers, cmyk, and spot colors. Y4M can do yuv444/422/420.

if you're a programmer, and want to speed this up, you could take a shot at parallelizing tree learning 😄

Not sure if that's the best place to start when you're new to libjxl and want to make a contribution 😅

it should actually be relatively self-contained xD

but I might have a weird perception here

Well speaking about parallelzing by non-programmer the closest would be setting up multiple docker containers. Though this will require tons of RAM.

Easy way is to encode 2 or more file in the same time (i will create a powershell script for that). Other way, encoding file with DCT -s7 is multithreaded.

I see. Thank you for the comments folks.

With Powershell 7 ```Powershell ls *.jpg | % -ThrottleLimit 2 -Parallel { cjxl $_ "$($_.Basename).jxl" } ```

If efficiency wasn't much of an issue, would doing independent tiles on large images with overlap compensation be possible?

overlap compensation?

I may have worded it poorly based on previous experience, but block overlap compensation essentially means you do some mild blurring and filtering on the edges of a block/tile to make the separation considerably less obvious.

ah, we don't need that 😄 our decoder handles cross-tiles data the proper way

somehow I hadn’t noticed https://github.com/fish-shell/fish-shell/pull/7673

Is there something for zsh

<https://github.com/tachiyomiorg/tachiyomi> https://github.com/jobobby04/TachiyomiSY/

<https://github.com/jobobby04/TachiyomiSYPreview/releases>

Yes ! 😍 you are fast, the commit is here 13 hours ago 😄 We only need to wait the compilation apk 😄 First ever jxl viewer on Android!

for Android 6.0 and above. no galaxy s4 i need to wait another week

indeed my galaxy s4 refuses this app

(Android 6 users using v0.10.12 will need to manually download the APK and update due to a bug, sorry!)

this isn't a jpeg xl viewer

false claim

is a manga viewer it doesn't open jxl photos

this is actually from <https://github.com/tachiyomiorg/image-decoder/pull/1> and <https://github.com/tachiyomiorg/tachiyomi/pull/5512>

should've probably been posted in adoption

I'm not interested in proving you anything

this app doesnt' work

don't display anything

nobody haa sent a screenshot of their phone here

I personally use only tachiyomi, not its forks, so I'll wait for official release with that enabled to start testing

but additions to the code are exciting nevertheless

<https://github.com/tachiyomiorg/tachiyomi-preview/releases>

Ah ok i don't see it, so it's great there are preview apk I do test now and it works, but there are posterisation :/

Ah i find in option an "32 bits" decoding. It's not enabled by default ... So it's not a bug it's a feature ...

It's a cool software, but it only read files in specific folders with chapters or zip.

nice. maybe ill try this if i have time.

works

do you have android 6.0 and up

the screenshot appears to be 18:9

I have "up"

also yes that's my phone's aspect ratio

:)

It's 21:9. Not 18:9.

Why not simply say 7:3 and 2:1? 🤨

because you can compare them without having to bring them back to the same denominator again

I suppose

yes im bad at remembering numbers it's sony xperia 5 ii

Finally!

What about non-anime-oriented Android <:JXL:805850130203934781> viewers?

once I'm done with icc profiles for tachiyomi I might just get it fixed for jxl in firefox

I've been working on it for all of today (the embedded icc part not the display profile part)

How did you profile your phone?

I have a colorimeter aswell but didn't know Android supports profiling, android 11

or do you just generate an icm independent of the os?

so you don't install the profile?

hmm guess I'll spend tomorrow calibrating my phone

<:KanataOyasumi1:754561613930954764>

Yo, how do I change associated editing application of ImageGlass?

How can I make those graphics that display the varDCT blocks that were created for an input image?

benchmark_xl has an option to save debug images

That's one of those

thanks 🙂

For those looking for a Windows build of the latest GIT tip: https://www.dropbox.com/s/bpog8d4ca2j02dk/jxl_20210728.zip?dl=0 <@!416586441058025472>

amazing

thanks

I know, I know, mental shorcut 😉 (I've been on a vacation, I'm catching up on the messages)

https://github.com/SoftCreatR/imei this looks handy

Does the current wasm implementation support converting from jpeg/png/gif to jxl? Since the conversion requires libjpeg, libgif etc. <@!439539398657441832>

Libjxl itself only does encoding/decoding from/to pixel buffers (plus optionally encoding jpeg bitstreams exactly and reconstructing them again)

If you want a wasm build of cjxl/djxl, you'll indeed also need wasm builds of the dependencies (which are all optional iirc)

Okay, thanks for the answer. But as I understood currently there is now way to set path to library dependencies for wasm build.

I haven't tried wasm builds myself. <@710762823986446367> or <@228116142185512960> likely know more about how to get it done

Which reminds me: does squoosh already have v0.5?

there: https://github.com/GoogleChromeLabs/squoosh/pull/1120

link for the jxl decoder february 09th https://mega.nz/file/fA8CnAIT#FZiMDYy1tEqDhDFy6ZL5hixvSug1lxpEEk229L2THu4

W t needs older binaries

it has no virus i just installed now from a new formatted computer;windows 7 though is not in good state;the speed is good

and is from my account; someone uploaded in discord jpeg xl

why wouldn't you just use the daily builds at http://artifacts.lucaversari.it/libjxl/libjxl/latest ?

Easy ways and simple solutions are not for Fabian

February 9th 2021 was a good vintage for jxl encoders, any jxl sommelier will confirm that.

decoder wic

this is the original by mirillis

but the original is djxl

i think is a library

don't know

a windows thumbnail decoder is described as

jxl winthumb is newer but throws error 0x80004005 on windows 7

Questo problema può verificarsi se un file necessario per l'Attivazione di un prodotto Windows (WPA) risulta danneggiato o mancante. Un'utilità di backup o un programma antivirus di terze parti interferisce con l'installazione di Windows XP. ...

basically my windows isn't regularly paid

that's the issue

things work differently in fabianland

Install windows 10

Or 11

I'd guess Win 7 is less annoying and resource hungry than Win 10 on an old machine.

the word is italy

i don't even know what is genuine windows anyway it's a different discussion than jxl tools

I believe there are some tools to remove unneeded components and services from official windows iso 10. Those installations are lighter like w7.

don't know i don't installed myself plus i don't have original cd

i'm being honest

don't debate more it should be present

last time i formatted was may 2018

windows 10 can't open programs without direct x 11 even the task manager

i have direct x 7 i tried in 2017 this

so i know

It comes directx inbuilt.

in fact but my driver don't support it

and my graphic card

You don't need directx11 graphic card to run programs

ok

You need only dx9 for w10

Even w11 runs fine on dx9 gpu

probably my driver is ancient

No

I run w11 in 2009 desktop. What are you .....

pretty sure "regularly" = "properly" in that sentence 😛 might be an Italian phrasing...

Do the jxl animations work anywhere?

At least in Chrome/Chromium

So cjxl does encode animated gifs then?

It does, but it's a part of the encoder that hasn't gotten much attention yet

I.e. we can very likely do a lot better than what we have now

Then again, jxl will never come close to real video codecs like avif

So imo it's a bit pointless to make a great encoder for animated jxl, it makes more sense to use av1 for animations

And it seems that using lossless webp for pixel art animation would be a better choice?

not sure - for now maybe yes (considering encode speed etc), but I think jxl should generally be able to beat lossless webp, bitstream-wise

Did browsers and other programs support animated WebP right when they deployed their WebP support?

No

There were no animations and lossless when WebP appeared, they were added to the format much later, after more than a year of WebP's existence

Hi. What is difference between jxl::ConvertFromExternal and jxl::SetFromBytes which check input data codec ?

ConvertFromExternal takes raw pixel data

it doesn’t do any decoding beyond that

SetFromBytes takes PNGs, JPEGs, that sort of stuff

So before using ConvertFromExternal image should be converted to raw pixel data? And does SetFromBytes do it conversion? Thanks for the answer.

yes, however those are internal APIs

what are you trying to do?

Actually just found code of using JXL convetor with ConvertFromExternal. But it does not use OpenEXR, JPEG etc. libs. I wondered how this could be.

Now I understand that they do format conversions somewhere earlier, before calling jxl. Am I right?

libjxl is only meant to encode/decode jxl from/to uncompressed pixel buffers

(and maybe between jpeg bitstreams and lossless recompressed jxl)

Okay. Thanks. It make sense for me.

What do you think about that? https://deploy-preview-1136--squoosh.netlify.app/

It's made from this PR and it FINALLY WORKS! https://github.com/GoogleChromeLabs/squoosh/pull/1136

can I make `cjxl` read from stdin and write to stdout?

`cjpeg` can do it

doing `cjxl /dev/stdin /dev/stdout <input.png >output.jxl` seems clunky

(these might not be files on disk at some point)

ideally it should accept `-` as an alias for stdin/stdout like most tools

or do stdin-to-stdout if filenames are omitted completeley

(like cjpeg)

I think there is an open issue for it.

while we're talking about cli parsing, is there a `--` to force cjxl to interpret all remaining arguments as filenames?

Yep

nice

Added a few weeks ago

essential scripting convenience tool

So I don't know if it is in the release yet

But it is on main

good enough for me

since I can build from master in the shorterm

I can't see and open issue for it on either the Gitlab or GitHub, so I'll open one.

👍

Oh it is me.

Sorry, I missed that because I was searching for stdin / standers input

does using `/dev/stdin` / `/dev/stdout` work for this?

let me try

Probably not because we check if it's a regular file and we want to know its size

/dev/stdout probably works

“Failed to read image /dev/stdin.”

I made a pull request to make it work for stdin with `-`

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

Are there any tools to write exif comments to a jxl file? I can read the exif with `exiftool`, but I can't write with it.

We're working on it

We first have to decide on the api, then we'll likely make a demo tool that uses the api to do container manipulation

And then it will be up to exiftool, exiv2 etc to implement full support

If you create the jxl file with a container (`cjxl --container`) exiftool can write metadata to it. But `djxl` seems to ignore the metadata when decoding. It might also interfere with jpeg reconstruction.

For now, I just write a comment to the source file and then `cjxl` transfers it to the resulting jxl. But looking forward to the implementation.

djxl should write exif/xmp to at least png output and reconstructed jpegs

Wow, that was a *fast* merge... ~1.5 hours since its creation!

Is there any PR that was merged quicker?

Hey, it works!

When https://github.com/libjxl/libjxl/pull/544 lands, it will also work with newly encoded jpg output

Yes, when someone happens to check the code quickly and there are no remarks, things have been merged within minutes

Dealing better with the container format is something we need to get done, there's stuff in the file format spec we're not yet properly implementing

In particular compressed exif/xmp

It should help quite a bit to get better recompression of jpegs that contain big exif/xmp, like produced by some cameras that have lots of makernotes or Adobe products that put lots of stuff there

But we need to get our implementation in shape to properly decompress metadata when needed, and then we need to get it in exiftool/exiv2 too

Because currently no tools know what to do with compressed metadata

there's quite a few with <10m merge time I think 😛 but most of those are tiny

If you have problems, try using `exiftool -wm w` to make exiftool only modify existing tags, without creating any new ones.

But by adding an `EXIF:XPComment`, I'm literally creating a new one, right? 😄

If the original didn't already have a comment tag. The problem with creating new tags is djxl and other tools might not be able to read the exif anymore. Until everyone is on the same page, it's probably better to do what you've been doing... write the tag to the original file before encoding to jxl.

Yeah, it's safer for now.

You can backup tags to a sidecar too: `exiftool -tagsfromfile image.ext image.ext.xmp`

By the way: what do you think about my PR #1136 for Squoosh? I changed it a bit since the last time. See what happens if you turn the quality slider between >=7 and <7. Do you think it's user friendly? https://deploy-preview-1136--squoosh.netlify.app/

Is specifying output format so djxl can go to stdout being considered?

Not sure what to do with animation frames

Allow specifying the frame maybe? Seems like too useful a feature to not have

I agree, my whole system already supports jxl but some things rely on temporary files to read this format. Being able to use stdout would be quite useful.

JPG is a temporary file to go from digital camera to JXL 😆

imagemagick have something like `convert '{}' png:-` / `convert '{}' ppm:-` for stdout output

I don't know why but my imagemagick is not recognizing jxl files, even though it's updated 😩

also for non-stdout output, in case you specifically want an 8-bit RGB PNG and not a grayscale one for example: `convert input.ppm PNG24:output.png`

btw, would it be too hard to implement stdout to APNGs if it's an animation?

instead of prefixing it you could just add `--output-format` or something

"force output format instead of choosing by filename"

it's a fairly common way to do it

Just like `-f` output option in FFmpeg

would nice to also have standard formats defined for the output in case `-f` is omitted, like - jpeg if it was first encoded from jpeg without `--strip` - apng for animated pictures - png for everything else

when piping stuff, I would assume that for the same reason you want to avoid intermediate files, you also want to avoid intermediate encoding effort

i.e. uncompressed output likely makes most sense in most cases

reconstructing a jpeg is not really encode effort (it's probably less effort than decoding it to pixels, or about the same)

but producing apng/png is often taking more time than the decode itself

(well we don't produce apng atm but it will be the same as png)

my personal take is that the user must request the output file format

if explicitly, then use that one

if not requested explicitly via an option, then implied by filename

if the output format was not requested and not implied then the CLI should just refuse to do anything IMO

rather than guess

I like this since script writers tend to force formats and end users tend to give things filenames that mean things

you can produce a PNG extremely quickly by setting the filter to the identity filter and zlib's settings to be uncompressed

which apparently is legal zlib

```c #define ZLIB_NO_COMPRESSION 0 ```

but I still hold the above stance

where if the output format cannot be determined one way or another, cjxl should refuse rather than guess

Yeah I know but then it's basically a PPM with checksums and an icc profile

Which is cool

png doesn't even need iCC does it?

But people might get upset if we produce decoded pngs that large

Yeah it's optional in png

We always produce a png that is well-defined in terms of colorspace though

yea, just pointing it out I think it still makes more sense to me to just refuse to produce a file if the format cannot be determined

rather than guessing

the question is what other applications will think its colorspace is... 😛

Yeah, I think we should stop producing technically-correct-but-firefox-and-many-viewers-get-it-wrong-anyway pngs

ah, you mean, you produce files with the right colorspace

but since that colorspace is not sRGB

and that field is ignored by many renderers

The thing with png is: you can do three things to define a colorspace

ICC profile is one of them, and that now works in most self-respecting viewers and in all browsers

sRGB chunk is another thing

gAMA is another thing

many programs disagree on what happens if you have both gAMA and sRGB IIRC

spec is very clear

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

but that doesn't mean implementations adhere

The confusing thing is that sRGB is not a gamma curve, but you are still recommended to use both the sRGB chunk and the gAMA chunk, and the sRGB chunk takes precedence but viewers that understand gAMA but not sRGB (viewers from the 90s I guess) still do something reasonable

So that is mostly fine

as far as I'm aware that's in the name of compatibility PNG spec requires decoders to ignore chunks they do not recognize to preserve forwards compatibility of the format

But now if you have gAMA but no sRGB, with the gAMA value set to 2.2

Then many viewers will assume you actually meant sRGB

While that's not what it is

Ah, the correct thing to do be to do gamma=2.2 by spec