JPEG XL

Worse: they do not use the library api at all yet. They predate the library...

Of course I use it from the compiled sources 🤣

`>cxl cmpk.jpg 16A.jxl -j -d 0.5 -s 7 [v0.3.7 | SIMD supported: AVX2,SSE4,Scalar] Read 3456x4608 image, 27.2 MP/s Encoding [Container | VarDCT, d0.500, squirrel | 402-byte Exif], 2 threads. Compressed to 1571659 bytes (0.790 bpp). 3456 x 4608, 2.54 MP/s [2.54, 2.54], 1 reps, 2 threads.`

`>identify -verbose 16A.jxl | ag Format Format: JXL (JPEG XL Lossless JPEG1 Recompression) `

Possible imagemagick bug?

It might confuse "uses container" with "is losslessly recompressed jpeg", which is not the same thing

ah, right, I have noticed that bug in GNU file as well

but wasn’t sure how to report it

someone, somewhere, must have assumed that the container was only for losslessly-recompressed JPEGs

we might have miscommunicated somewhere

Lossless-recompressed jpeg implies container, but not the other way around

Need to check for a `jbrd` box in the isobmf if you want to make that distinction...

(not sure if it is a distinction really worth making)

I don't think the api gives that info atm. The api is still evolving.

Yes

And also the `file` magic should be updated

Ah that is ok

👍

https://drafts.csswg.org/mediaqueries-5/#prefers-reduced-motion

<@!710762823986446367> do you think it would make sense to interpret `prefers-reduced-motion` to also avoid progressive repaints?

I'm searching for a way to have nice progressive loading by default, while still allowing those who really don't like progressive loading to have a way to disable it, ideally without introducing new user preference flags (since I understand that chrome devs don't like adding those)

<@794205442175402004> My gut feeling is no, but it might depend on how many passes there are. Even with reduced motion, you'd still have motion if it was required to make sense of the page. It's mostly for prevent unnecessary transitions, and I don't think JXL's progressive rendering is particularly obtrusive

I think some basic progression (1 fast preview, followed by eventually the final image) is actually "less motion" than the flash that happens when an image instantly appears out of nowhere.

But several repaints might be more obtrusive because with many repaints the image would (subtly but noticeably) change several times while loading, possibly in weird middle-out ways (progressive passes can be re-ordered in e.g. a spiral shape in jxl)

<@!794205442175402004> it might depend on whether the switch is more distracting than the progression JXL would use otherwise

I think two-step progression (e.g. DC followed by final image, or blurhash followed by final image, or avif preview followed by final image) is uncontroversially less distracting than "blank spot followed by final image"

agreed

But many-step progression (e.g. a JPEG with 10 scans like what mozjpeg produces) is somewhat more controversial: the image keeps changing subtly and you don't know when it is done loading

In JXL we can always do two-step progression but we can also optionally do many-step progression.

Perhaps it would make sense to do only the first step (which would be an upscaled 1:8 image) and then wait for the final image in case `prefers-reduced-motion=true`, but show more intermediate results (assuming the connection is slow enough to do that in the first place) in the default case of `prefers-reduced-motion=false`?

<@!794205442175402004> might be good to reach out to someone who works with a11y stuff, like https://twitter.com/rob_dodson. If JXL is made to be 2-pass for this reason, seems like we should do it for JPEG too

For JPEG already some stuff happened in that respect: the "green martian" effect from showing DC with YCb with Cr still missing is no longer something that can happen.

There is no way to do the AC of a progressive JPEG in a single pass though, you have to use at least 3 passes after the DC (one for each component).

Rob doesn't have his twitter DMs open, so I'd have to reach out via public tweet which I don't really like to do. Could you ping him and ask him to dm me? (or to join this discord, even better 😀 )

<@!794205442175402004> what's your twitter handle again?

yes that's me

here's a discord link if you want to get him here: https://discord.gg/DqkQgDRTFu

that's where we are

oh nvm

that's what you meant

😁

👋

Oh haha I still have my shadowrun character profile for discord. This is Rob. Let me change that 😅

Hi Rob!

we had a little discussion here about the possible connection between `prefers-reduced-motion` and progressive rendering of images

your thoughts on this would be very welcome 🙂

oh ok, taking a look now

<@!794205442175402004> for progressive repaints I'm assuming it sort of paints in a bit pixelated, then paints in again with higher resolution, and so on until the picture is at its final resolution?

or is it more like a choppy partial painting where the top third paints in, then the middle, then the bottom

well it's not really pixelated, more blurry

but yes, the first thing

the choppy partial painting is not progressive but sequential or incremental rendering

which is also something that may or may not have a connection with `prefers-reduced-motion`

(for that matter, a JPEG XL image might even do choppy partial painting in a weirder order, like middle -> bottom -> top)

(it's an encode-time decision)

hm it's an interesting question.. I don't know enough about vestibular disorders to know what kinds of screen actions can be triggering for folks, with the exception of things like parallax... Let me send a quick email to some Chrome a11y folks I work with to see if they know who we could ask.

do y'all happen to have a video of what the progressive loading looks like?

something like this? https://www.youtube.com/watch?v=inQxEBn831w

(you can assume that the "black squares" part will be skipped in a browser)

For mozJPEG, this article is my favourite: https://cloudinary.com/blog/progressive_jpegs_and_green_martians (look for _Here is a comparison of an image encoded with MozJPEG as a nonprogressive JPEG_). So: it may look different.

these videos are "slow motion" simulations of what could be done on a very slow connection when the browser is doing a lot of repaints when new data arrives - in reality browsers will not do that many repaints

ok great, thank you! I'm sending this over with the note about the slow motion bit

gthumb have a strange bug with jxl

view very low definition

eog

monospace legible font

got strong Mattino vibes here xD

(well, Ungaretti in general, I guess)

<@794205442175402004> here is the feedback I got from the chrome a11y team. ``` I'd need to understand more about why users don't like progressive loading. prefers-reduced-motion would have a lot more impact than that (though I'm not sure how well supported it is). It's also not obvious to me that that's how I'd stop progressive loading, if that were my goal as a user. I'm trying to think about what the settings UX would look like, and I'm coming up with something pretty confusing. ``` And another teammate chimed in: ``` I don't feel like an expert on this at all, but my initial thoughts are that it might be very one-directional. People who already have prefers-reduced-motion *might* benefit from avoiding progressive repainting. Most likely they'd be fine with it, even if progressive painting didn't bother them. However, people who dislike progressive painting aren't as likely to be happy with enabling "prefers reduced motion" since it makes a bunch of other changes too, like eliminating smooth scrolling. This is tough - it is a challenge to add another setting, and I also worry that this setting could be yet another way to fingerprint users. ```

Fingerprinting: valid concern, and would be a reason not to expose this preference in any (easily) observable way: e.g. don't add a http header that asks servers to send a progressive or non-progressive image, don't make it something that can be queried in css or js, just make the progressive rendering of images have more or less repaints.

The one-directional aspect of it I agree with: if you are fine with motion in general but you just dislike progressive loading, you'd have to "kill a mosquito with a bazooka"...

Why users don't like progressive loading is a good question. I think the vast majority of users **do** like progressive loading (90% or more). But apparently there are some who don't like it, and I don't really know their reasons.

afaik the only way to read pixels from an image is to draw it to a canvas and read image data from there. that api might already be disabled if the browser is trying hard to resist fingerprinting. otherwise they could probably make it so that (if this is not already the case) drawing an image to the canvas will only draw anything if the image has been fully downloaded and decoded

i should try this out actually

Two reasons why people might not like it: (but I am mostly just hypothesizing here) - the image goes from blurry to sharp in a series of updates, which adds cognitive load because the screen is updating more, but also because they first thought there was a blurry image there but then it turns out to be a sharp image - not knowing when the image is actually fully loaded (do I see all detail now? Or is it still loading?) can be uncomfortable

The first reason could be alleviated by doing fewer repaints. The second reason could be alleviated by showing progress of loading in an additional way, e.g. by having the option to overlay a non-obtrusive little progress bar on images that haven't fully loaded yet. (For sequentially loading images, this isn't needed because the image itself **is** a kind of progress bar, but for progressively loading images it is less obvious what the loading status is)

Both are possible, but it makes more sense to me as a browser-wide preference than as a page specific design choice.

ok so i tested with a progressive jpeg and throttled network. if you draw an image on a canvas it only draws anything if the image is fully loaded

i can't think of any other ways you could access a partial image, unless you are decoding it yourself in wasm or something (but then you decide whether to decode it progressively)

just firefox

chromium is the same

and epiphany (based on webkit)

Yes, I don't think there is a fingerprinting issue

<@!356568358407241729> feel free to send back my comments to the chrome a11y folks, or to invite them here 🙂

_showing progress of loading in an additional way_ Isn’t the usual Stop navigation cross button in the address bar (that changes to Reload page) already in every browser not enough to indicate that the page is still loading? Adding per-image loading indicator would increase visual noise and would come with its own 77 problems IMHO.

For me it is enough, but for people who say they don't like it that they don't like progressive because it is hard to tell when an image is done loading, it might not be enough to have a global "page is loaded" indicator but they may want it per-image. In any case I agree that it does add visual noise and it should certainly not be something to do by default, but only as an optional browser ui/ux preference... just to give those who prefer incremental over progressive because incremental has a 'built-in' per-image progress bar that they're missing in the progressive case. I would do it as a small, 50% transparent overlay at the top or bottom of the image, so it doesn't add too much visual noise.

seem an over-complicate solution

I guess that depends on how strongly people feel about the problem.

If they feel strongly enough about it to make it a reason to not do progressive rendering for anyone, then I'd rather have an over-complicated solution than to just say "too bad, let's not do progressive rendering at all".

This problem can be similiar to patch finding problem? https://en.wikipedia.org/wiki/Longest_repeated_substring_problem

seem O(n)

heh, I didn't know that problem - but unfortunately a suffix tree is inherently a 1d data structure, not going to help for patches...

https://link.springer.com/referenceworkentry/10.1007/978-0-387-30162-4_442, help?

That the same for me, even for lightroom. A cool solution is the decoder add information on partial decoded picture, like a 2px green frame, or something like that ^^

not with those complexities 😄 also it's useful to find "similar enough" patches, not just exactly equal patches

damn

there are probably some reasonable ways to do it

I think with hash tables we can do better than what we do now

... for detecting *similar* patches

for detecting *text-like* patches, that's another story

Other solution is the partial decoding was pixelated with no blur, only display 1:8 1:4 and 1:1 so there are no ambiguity about partial decoding ^^

For detecting regions suitable for encoding with modular patches, a heuristic that works like this can be useful: Compute residuals of some modular predictor (gradient or select would likely work well), bucketing it into three classes: equal to zero (A), non-zero but lowish amplitude (B), and high amplitude (C). Then if in some part of the image you have mostly A and some C but little B, it is likely good to segment that part into a modular frame (and investigate it for repetitive stuff).

From what I know patches can be modular, lossy modular, and vardct. A lossless image by definition should use lossless modular patches. Also a jpeg lossless transcode can't use patches because it's supposed to be able to reconstruct the original jpg

Maybe jpeg lossless compression could use patches but I don't think it can without making it not reconstruct identically

It might be that the computation was being done, but not applied.

This might give a free efficiency boost, particularly in some type of content.

No, patches are after DCT decoding... you can't output DCT coefficients if patches are to be applied afterwards.

Oh

(this is based on my high-level understanding, I don't know the actual details)

I guess patches inside the DC part of VarDCT could work... unsure.

0.4 may be the next release, given: https://discord.com/channels/794206087879852103/804324493420920833/840310585719652392

It was still doing some of the work, for nothing. It might get a bit slower now if it actually finds patches, not sure.

Q1: Yes. At least for up to 16-bit. For higher bitdepth we are disabling patches in lossless mode because our implementation is working on floats at that point and we run into the problem that A+B-B != A can happen in floating point arithmetic (not a bitstream issue, just an implementation limitation). Q2: Right. The old JPEG doesn't have patches so when losslessly recompressing it, we cannot use patches.

<@794205442175402004> What about patches in the DC component?

Or are those restricted to full-frame end results?

You could do it with a DC frame, I suppose

Not with the default "DC is part of the frame data" approach though

The current encoder is not trying to find patches in DC frames (also not in the spritesheet frames created for Patches)

> The current encoder is not trying to find patches [...] ([...] in the spritesheet frames created for Patches) That'd be "patch-ception", right?

<@!794205442175402004> apparently SSIMULACRA uses L\*a\*b\* color space. Do you think it'd give better results if it was rewritten to use XYB instead?

Maybe. Or maybe XYB for the high-res scale, Lab for the lower res scales.

Patch-ception is possible, bitstream-wise, but the current encoder doesn't go there (and it is likely very hard to do that in a useful way)

it can be useful for colored text: you encode black and white letters in a first patch frame, use alpha blended patches to color it in the second patch frame, and then paint them on the main image

Yes, or to make letters from letter segments or common words from letters, if that ends up being cheaper to signal

My hunch is that this may be the strongest argument against making it part of prefers-reduced-motion. As a user and as a developer I think I'd be surprised that choosing this option (which I normally associate with transitions/animations) would affect the way images render.

I don't disagree. I suppose the question is: how severe is the problem that some people seem to have with progressive rendering, and does it justify adding a user preference setting to choose between two (or more) rendering behaviors?

yeah that's a good question... How have users previously reported not liking it? I'm trying to sort of brainstorm a way of getting this feedback from folks.

I am personally fine with just always rendering images as progressively as possible (within reason - I don't need more than 2 repaints per second or something).

I don't know many people who don't like progressive rendering. I know Pascal Massimino doesn't like it.

As far as I know, it is a topic that pops up every once in a while, but there's not really a lot of data available on actual user preferences

I pinged the Chrome a11y folks to ask if they know of any sort of standards associated group that can help determine if a feature has potential accessibility issues. I guess I'd be most interested in seeing if something may affect someone because of a possible disability, versus them not liking something because they have a strong stylistic opinion.

If it turns out that progressive rendering really does bother someone because they have a vestibular disorder then that would further the case that it should be gated by prefers-reduced-motion.

Yes, that makes sense.

Y'all might also try doing a survey of some kind? Or creating an open discussion thread on GitHub. I've done that in the past when we had open questions related to specs. We'd create a thread and put the word out on twitter to ask for feedback.

It would certainly be interesting to know how people think about it - both in terms of stylistic preference and in terms of actual a11y issues.

Progression does of course also bring a11y benefits, in particular for people with poor or unreliable network conditions

there would be ways to reduce the visual noise, for example the indicator could appear on images of at least a certain size, after at least a few seconds of loading, and with a smooth fade-in / fade-out animation instead of abruptly

Some older discussions on progressive loading: https://github.com/WICG/largest-contentful-paint/issues/68

png and jxl are in same size. Is it a imagemagick bug? (The Input is a 16bit PNG)

Is the jxl actually a jxl?

(I think if you have an imagemagick without jxl support, it might produce png files if you give it an "unknown" output extension)

Strange coincidence then that the sizes are so close. I would expect a q95 jxl to be much smaller than a png... Does cjxl have the same behavior?

File is 27mb. From file manager properties panel.

Yeah. Your are right. It is outputting a PNG file. That's why file size is huge.

Not really, at least not as a valid jxl bitstream

What are the first few bytes of the file?

`hexdump bla.jxl | head` or something would be useful

Sorry. It was my fault. Recently I updated my arch. It replaced the imagemagick compiled with jxl with Arch's non jxl imagemagick.

ff0a is a jxl codestream

So I guess just a coincidence that the sizes are so close

got another problem.

no. all file sizes are same. 171kb , different quality

The imagemagick is from https://build.opensuse.org/package/binaries/home:user5664536:linux/imagemagick/Arch

😦

Maybe related https://gitlab.com/wg1/jpeg-xl/-/issues/179

Probably that code predates most of the libjxl encode api. We should improve the encode api and update ImageMagick/Gimp/... integrations...

Was already reading `cjxl.cc` to figure out how the quality option works there.

if you're using the C API then cjxl won't tell you much

the relevant API function IIRC is `JxlEncoderOptionsSetDistance`

It does and it doesn't 😋 It at least tells me that we should probably call `JxlEncoderOptionsSetDistance`

yup

But it does look like we don't have access to `quality_pair` that we probably also need to set when the quality is `100`

That one is for lossy modular

`if (quality < 7 || quality == 100 || params.modular_mode)` ?

there's a SetLossless for that

We are using that but I was wondering if we should also set the quality_pair

Yes, currently it uses lossy modular only if you do really low quality

We call `JxlEncoderOptionsSetLossless` when the `-quality` is set to `100`. That is not sufficient?

no no, that is sufficient

you only need SetLossless for q=100 or SetDistance for q < 100

I don't think so, there's something like `JxlEncoderStoreJpegFrame` but I have no idea if IM can even get a JPEG frame at that point (<@693227044061839360>)

It looks we are are talking about two different things. Storing a jpeg lossless in a jxl container and storing image data lossless.

yep, two completely separate things, agree

We cannot do the first one because we decode the jpeg and store it in our internal pixel storage. If you want that it would be better to use JXL tooling instead.

This is now not possible indeed. And in theory we could do this with an "image attribute" to store the raw jpeg data but I really wonder if we should add that to ImageMagick.

yeah, it does seem somewhat out of scope to me

Not saying we will never do that but it feels like an edge case to me. And our normal process is to decode the file to pixels first. And that will mean that we don't have the original data after the image has been read. This would mean you would need to "attach" the original data to a bogus image and then encode it. That feels super hacky and probably not something we would add. Attaching the original JPEG data to the image when we decode it could be an option. But also something that we will not likely add very soon.

Done, and also just added support for setting the Butteraugli distance using `-quality`.

I agree that IM objects are pixel data, not jpeg bitstreams. Maybe a special case could be added somehow for direct `convert foo.jpg foo.jxl` and back, but it would have to bypass the normal IM pipeline and of course cannot do any manipulation.

libjxl is the name of the library

So it would be a logical name for a package

libjxl, libjxl-dev, libjxl-debug, jxl-tools

I think that would be the most expected package names, at least for me

The official name of the codec is also "JPEG XL", so with a space, not "JPEG-XL"...

For the reference implementation, we go for "jxl" everywhere, since spaces are inconvenient. libjxl, cjxl, djxl, .jxl

Seach engine also dislike two letter word.

maybe the one exception to this is `benchmark_xl`

Yes, but it doesn't only benchmark jxl, you can also compare with webp/avif/jpeg with it, so maybe it's an extra-large benchmark tool? 😅

https://www.reddit.com/r/compression/comments/ndule0/best_compression_method_to_store_files_on_a/

Avif could do it

I think it's better suited

Because of course if you are aiming to fit images into a floppy disk

Lower quality is acceptable

if only AVIF headers wouldn't take kilobytes on their own

though in some cases it could probably still come out as better trade-off so ¯\\\_(ツ)\_\/¯

I mean, to be fair, it can easily be made smaller from 300 bytes down to 150-188b.

how?

i used a usb floppy drive once to copy some stuff off floppies, must have been 7-10 years ago but suppose it would still work on anything with a type-a port

depending on how much of the avif header is fixed, maybe they could see space savings from zipping up a bunch of avifs

avifz

<:monkaMega:809252622900789269>

I assume?

Well, cavif-rs only has an 188b header, even on larger images.

ah interesting

nice to hear tbh

Does it produce spec-compliant avif files, or just files that happen to decode?

That is an application-level choice, I suppose.

you're talking about an animated jxl?

I think it would be reasonable for a viewer to display it as an animation but also have an option to go through the frames and e.g. extract a single frame

but it depends on the scope of the viewer, e.g. probably a browser shouldn't have that functionality (or at least not when showing it in the img tag)

It might also make sense to present it in a multi-page way, like how a PDF is shown

It would be good to have some convention on when to interpret it as animation (so autoplay makes sense) and when to interpret it as a multi-page thing (so manual page flipping makes sense, or even showing the pages vertically with a scrollbar). This is not something that the spec specifies, it's a bit out of scope since it's more about presentation than about decoding.

How would a browser even access multiple pages in one file? Would you need html commands to trigger a change of pages? Or could you access them like: `src="/image.jxl#2"`?

I dunno, I was thinking about how a PDF gets shown

Or like multipage TIFFs are shown

How are they shown?

Also, who is going to decide about that? Are you talking to the Chrome and Firefox devs and recommend how things should be handled or is this something every browser will do differently?

This is a multipage TIFF, first converted from GIF to individual PNG frames with `ffmpeg` and then merged into TIFF with ImageMagick's `convert`.

Which browser are you using?

I can't even open it in my firefox

Windows opens TIFFs by default in older Windows Photo Gallery and it looks like this:

So you mean how multipage TIFFs are shown in general, not in browser: Understood.

Okular sees it as a multipage file, but qview, the viewer I use, doesn't acknowledge the extra pages

eog:

in document viewer:

<:kde:821845105518444625>nome

Which distro?

arch

eog and evince v40.1

I've got arch

The only problem I have is that it's networking is always cludgy trying to install

<@!794205442175402004> I spoke with the Chrome folks and they mentioned that there's something called the APA which is connected to the w3c. I'm not very familiar with them, but I think they usually review specs for possible accessibility issues. I'm not sure how this aligns with their work since this is more of an implementation question rather than a spec question. But one can file a spec review here: https://github.com/w3c/a11y-request/issues

Cool, that is interesting. Not sure if there's something for them to review, like you say. But might be good to ask their opinions, maybe.

magick ref.tif -profile icc/ProPh.icc -resize 300x -profile icc/sRGB_v4_ICC_preference_displayclass.icc temp.jxl

magick ref.tif -profile icc/ProPh.icc -resize 300x -profile icc/sRGB_v4_ICC_preference_displayclass.icc temp.jpg

jxl colors look washed out

Hm, wonder where the issue is. What happens if you first make a png and use cjxl on that?

It looks fine. png -> jxl with cjxl

And if you do png -> jxl with magick?

washed out colors.

magick ref.tif -profile icc/ProPh.icc -resize 300x -profile icc/sRGB_v4_ICC_preference_displayclass.icc temp.png

magick temp.png pngtojxl.jxl

I am using gwenview with this patch. https://invent.kde.org/novomeskyd/gwenview/-/commit/c0c613bf665e827f912f4a9c71384469b3ba3f7e

Hm, what if you do lossless jxl?

Is -quality 100 on imagemagick lossless?

I think so

JXL_ASSERT: !fp [1] 26515 illegal hardware instruction (core dumped) magick temp.png -quality 100 pngtojxl.jxl

lol nice

Could we get the png?

ok

Hm I remember that assert, but I don't remember if or how it was fixed

``` % cjxl -q 100 temp.png temp.png.jxl J P E G \/ | /\ |_ e n c o d e r [v0.3.7 | SIMD supported: AVX2] Read 300x400 image, 13.0 MP/s Encoding [Modular, lossless, squirrel], 6 threads. Compressed to 476525 bytes (31.768 bpp). 300 x 400, 0.36 MP/s [0.36, 0.36], 1 reps, 6 threads. ``` this worked okay. do i need color profile too to trigger, or is that different ver?

I don't understand. the png has both srgb and prophoto icc. 🤔

the error happens on imagemagick. not on cjxl

Icc takes precedence then

Or you mean it has two icc profiles?

I see both srgb in colorspace and prophoto in magick identify

`identify -verbose temp.png | ag colorspace Colorspace: sRGB exif:ColorSpace: 65535 identify -verbose temp.png | ag prophoto icc:description: ProPhoto RGB`

Exif colorspace? 🤔

What does the result of cjxl --strip look like?

`identify -verbose temp.png | ag exif exif:ApertureValue: 1.851999 exif:ColorSpace: 65535`

Imagemagick is too confusing. I should stick to cjxl then.

Things are really complicated when there is both an ICC profile and Exif saying stuff about the color interpretation too

cjxl by default preserves the exif, while magick might strip it atm

It still looks washed out even with `>magick ref.tif -profile icc/ProPh.icc -resize 300x -profile icc/sRGB_v4_ICC_preference_displayclass.icc -strip temp.png >magick temp.png pngtojxl.jxl`

can imagemagick in its current state even do jxl color profile stuff?

<@693227044061839360> is the expert on that

My poor-man’s understanding: > Colorspace: sRGB This is meaningless and doesn’t say anything beyond that the image is RGB (ie. not CMYK). It [may indicate](https://imagemagick.org/script/command-line-options.php#colorspace) a way IM is nterpreting the default, uncalibrated, images and in which colour space it performs operations (?) if you don’t explicitly convert to intermediary space, or it may not. It changed one day, before it said just `RGB` (around the time IM started to be serious about colour management). > exif:ColorSpace: 65535 This is Exif DCF saying _Uncalibrated_. So, basically, not sRGB. Together with [InteropIndex](https://exiftool.org/TagNames/EXIF.html) it may well mean AdobeRGB (the only two colourspaces Exif can indicate via DCF are sRGB and AdobeRGB). Proper ICC colour profile should always take precedence over any of this (just like it should with PNG colour metadata, not sure, but hopefully, how it should also take precedence over new fancy AVIF or JXL colour metadata). It‘s the responsibility of any good software always reconcile all the colour metadata and never leave any redundant or, worse still, conflicting bits in. Don’t think I have met such software yet, though 😜 .

TL;DR: only that bit matters: > icc:description: ProPhoto RGB

colors looks dull even after using strip on imagemagick. It is very confusing 😣

For many transcoded jxl images in GIMP (w/ and w/o icc_profile), i'm getting `GIMP-Error: JPEG XL image plug-in could not open image` after `JXL_RETURN_IF_ERROR(DecodeFile(dparams, compressed, &io, &pool));` in `file-jxl-load.cc:LoadJpegXlImage`

And opening some lossy/lossles jxl images gives blank canvas

Some examples https://drive.google.com/file/d/1T5X-Cp02JaC50jdKrGhUSIrAJIdHGj8X/view

oops wrong channel

the SC 29 secretariat is in Japan

how do you delete attached files from discord?

it would be really bad for ISO's paywall if people could just download that from here

got wifi trouble bbl

Wifi is back

Well we have a private discord channel for these things

delete the message

On my phone on 4G now

How do you delete messages on the phone app for discord?

How do I check if the link no longer works if I do that?

Can someone put the link here so I can test after I delete?

Thanks. Deleted the message

still accesible

Really?

Well we did what we could

Yes, committee draft is public

But indeed outdated

What is the link again? Maybe I can ask Discord to take it offline...

Maybe delete the mentions of this?

yes, I just need to find a way to ask Discord to take https://cdn.discordapp.com/attachments/794206087879852106/844161270164881428/ISO_IEC_FDIS_18181-1.pdf offline

the link no longer works, it seems

I get this if I click it:

<Error> <Code>AccessDenied</Code> <Message>Access denied.</Message> <Details>Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object.</Details> </Error>

so I think we're good

firefox still work

that means 1 to 7

[ is included, ( is not included

that's the same thing

I can't download

tfw missed standard leak :<

Also I, i'm so sad

#mathematicians 😛

`)` vs `]` in loop usually means `< maxval` vs `<= maxval`

it's a standard mathematical notation

`(a, b)` -> a and b excluded

`[a, b]` -> a and b included

`(a, b]` -> a excluded, b included

and so on...

some horrible, horrible people write it `]a, b[` instead of `(a, b)`

w-what

https://en.wikipedia.org/wiki/Interval_(mathematics)#Notations_for_intervals

that’s the notation we use in France

I had never heard of the () notation before emigrating

in italy all two are in use

[a,b[ = [a,b)

as I said, horrible people 😛

I should add that we use ; as the separator rather than ,

since , is already the decimal separator

:p

]1,5 ; 4,5[

Oh, there are issues on gitlab already https://gitlab.com/wg1/jpeg-xl/-/issues/234 https://gitlab.com/wg1/jpeg-xl/-/issues/186

Is it okay to open a GitHub issue on imagemagick jxl related bugs ? is it too early?

I dunno, I guess it doesn't hurt?

I found that It doesn't properly convert any 16bit PNG to jxl.

We read the ICC profile of the image. We don't write color profiles at the moment.

so would work okay if transform to srgb happened i guess

I have seen that assert before and we had that issue with an older version of the jpeg-xl library. Haven't seen it afterwards

<@!260412131034267649> If you transform to sRGB it should work.

Not sure what you mean here. Maybe open a discussion on GitHub with a bit more info and the versions of ImageMagick and jpeg-xl that you are using?

You can open issues on GitHub or start a discussion if you have a question about ImageMagick and jxl.

Private Discord channel just for JPEG XL core devs?

In higher education in Poland we use [a, b) "international" notation, but below college/uni, in primary and secondary schools we use <a, b). We also use a comma as a separator despite it being used for decimals too, so I personally use semicolon as a separator instead and keep commas just for decimals.

At school we used [a,b[. At university it was [a,b) I think.

Yes. There's also a gitlab-dev channel btw

I am unable top open your `temp.png` file it looks like your 1mb zst file only contains a 0.5mb png (using 7-zip 19.0). And the other one is not a bug but an unsupported feature. Currently we only support writing 8 or 32 bit jxl files. And because the input file is 16 bit it will be "upgraded" to 32 bit. We will probably add support for `JXL_TYPE_UINT16` in the future but I don't know when that will happen.

I can reproduce your assert issue. I don't know what is causing this though. It does seem to be related to the bit depth. Doing a convert with `logo:` (8-bit) does not reproduce the problem. Can your produce the issue the cjxl if you force it to use 32-bit instead of 16-bit? I suspect that this is a problem in the encoder.

Do you also get an assert error when you do -q 100 (lossless)? Or is -q 99 lossless?

Could you open up an issue on GitHub <@456226577798135808> ? This will probably take a lot more time to investigate why there is a difference between `cjxl` and ImageMagick.

There are some weird things in how jxl deals with 32-bit

It can do lossless 32-bit float

And it also looks like we have a problem with 32-bit alpha because it looks like the alpha channel is a half float then? There is no 32-bit alpha support <@!794205442175402004> ?

There is

Internally everything is a 32-bit float

``` switch (info->alpha_bits) { case 0: break; case 32: case 16: enc->metadata.m.SetAlphaBits(16); break;```

Hm, is that in the api?

`JxlEncoderSetBasicInfo`

That doesn't seem right

Probably not causing the problem here because this `temp.png` file has no alpha.

Still

<@768090355546587137> can you take a look at the alpha encode api? Looks like it doesn't support 32-bit alpha

But what causes that assert is attempting to do XYB and lossless float at the same time, iirc

When doing lossless float, it shouldn't do any color conversion because that is not going to be lossless

Might be some logic in cjxl that needs to migrate to the encode api, or something

It looks like jxl gimp plugin doesn't support exporting 32 bit jxl.

Don't you have "forbidden" characters in the path? https://gitlab.com/wg1/jpeg-xl/-/issues/184

This could be reported as a bug?

I think this

Intent

probably a gwenview bug. those png display fine on photoshop.

Or maybe something bitdepth-related? It doesn't matter in VarDCT, but it's crucial in Modular.

both are 8 bit pngs

The next version of ImageMagick will support reading and writing 16-bit jxl images. This can be used as a work around for the assert that you had with the "32-bit" `temp.png` file <@456226577798135808>. I think we need to wait for the jpeg-xl team for proper 32 bit support.

This also "solves" https://github.com/ImageMagick/ImageMagick/issues/3699.

https://www.reshade.net/

Do not know if is original reshade this

it claims to be really free

FYI `convert temp.png temp.icc` can also be used for extracting ICC profiles

You can get better results with esrgan or with topaz ai

this came up briefly in another server... jxl's additional (beyond color/alpha) channels could be used for steganography no?

either hiding arbitrary data encoded into the channel values, or having another image there encoded with jxl. like if channels 5/6/7 produced an image when interpreted as r/g/b.

Sure

Can hide extra images or whatever in any codec if you want. JPEG has markers for arbitrary stuff, PNG can add arbitrary chunks, etc

Or just concatenate to the file.

That works too

there's a lot more subtle ways to do steganography by the way 😛

if you're decoding to a format that only supports the standard color channels i assume djxl would just ignore any other channels

iirc one can specify whether extra channel can be ignored or must be processed

Some extra channels have render impact, like alpha and spot colors

Others don't, like selection masks, depth, temperature

For types of extra channels that we now don't know yet, we have 1) defined generic channel types "unknown but optional, feel free to ignore" and "unknown and non-optional, don't just ignore this", and 2) also channels can optionally have arbitrary channel names, which can be used to describe the channel semantics using some convention

https://distill.pub/

What's that fabian

it was in video discord av1

The viewer doesn't do animation at all, we need to fix that I guess

Icos4D tests for a bug that was only very recently fixed

I wonder what's up with the grayscale one...

Can you link to all the files?

Could be it doesn't handle grayscale color management or something

No, ISOBMFF does not itself support cropping/layering/rotation etc

HEIF supports that

JXL is not HEIF based, so you cannot crop at the container level

(you can crop etc at the bitstream level though, but that requires modifying the codestream, harder to do for external applications)

ISOBMFF is a generic box container format that defines a few boxes like `ftyp`

JXL and JPEG 2000 extend ISOBMFF by defining new boxes to contain j2k/jxl codestream payloads

HEIF extends ISOBMFF by defining boxes for cropping, grids, rotation, layers, etc

Yes, jbrd, jxlc, jxlp, etc

If you use the HEIF-specific boxes, theoretically Nokia could sue you

I personally don't think their patents are valid, I would argue prior art: image editors have containers like XCF or PSD that can do layers, cropping etc for decades, so I don't see much novelty in HEIF.

But IANAL and afaik their patents have not yet been tested in court.

but! JXL doesn't need nor use those boxes for anything

and I believe exiv2 wouldn't either

JXL is not based on HEIF so it doesn't have those boxes, decoders should ignore them if anyone adds them for some bizarre reason

Exiv2 may or may not want to look at those boxes in the case of heic/avif

anyway, ISOBMFF is too old to be still covered by patents (if it ever was) AFAIU, having been published in 2000

If they want to give information on how many images there are in a sequence, how many layers, orientation/crop info, etc, then they will have to look at those boxes

Yes, ISOBMFF itself is certainly OK

The HEIF extension of it could be risky until 2035

What issue is this?

it's pretty amazing how patents cause problems to things that are entirely not covered by the actual subject of the patent

nobody likes lawyers

Well I can understand how you might want to avoid parsing heif even if you're only going to touch the boxes that are from isobmff and not from the heif spec...

But jp2 (the original kind, not the part 16 "j2k in heif" one, which is also a thing for some reason) and jxl have nothing to do with heif.

Well at least for HEIC, adoption does seem to be limited to the Apple ecosystem, but I think that's mostly because of the heavily patent-encumbered h265 payload, not so much because the lightly and questionably patent-encumbered container.

For AVIF, I have been saying since 2017 that I don't think it's a good idea to use the heif container for a format that aims to be royalty-free, but my concerns were typically ignored or shrugged off. There's a widespread "folklore" wisdom that "containers cannot be patented" so everything "should be fine". This may be true, but it still has to be tested in court, and not everyone can afford to take that risk, since how the system works is that when they sue for bogus patent infringement, _possibly_ you can get the patent invalidated and 'win', but _certainly_ you're going to have to pay a lot of money to lawyers.

can you send 100e3c7e jpeg xl for windows?

send it

i new to do -d 4.56 -s 9 new heuristics

cjxl only i need

That low quality? Is that even doing VarDCT?

If it's modular, new heuristics will not affect it

ah i meant -d

Still d 4 is lower quality..

the photo is good quality is 16 mpx

i need to look as few a possible on all screens

Just stick to d1 to d2? No?

The 1st file can be decoded just fine here strangely enough.

the bug should be fixed in latest github libjxl

Help. Compiling jxl in termux

pass `-DJPEGXL_ENABLE_SJPEG=Off` 🙂

Thanks veluca

Why does my phone compiles faster than my laptop lol

same for me really (well, depends on the laptop) xD perhaps some things are easier on the phone...

like, less optimization is done, or register allocation is easier

Does register allocation become harder or easier if more registers are available?

Compiling with March armv8.2-a mtune cortex-a76. It should do optimizations. Right?

it should do some but maybe more if you have -O3 in there

maybe not as many optimizations are implemented for arm as for x86 🙂

and as for register allocation - it's certainly easier if you have an orthogonal ISA I think

and not things like "shifts counts need to be in the cl register"

do you mean in terms of absolute performance compared to fewer registers (more is obviously better) or in terms of proximity to optimal?

register allocation in my limited (and several years old) experience is often the one reason why compiled code may be slower than handwritten assembly (special instructions/vectorization being another of course)

at least a few years ago gcc would emit far more spills to memory than needed in some cases

more and less constrained registers are of course better, but does the problem of finding the best possible allocation become easier or harder with more registers?

it's an NP-hard problem, right?

yeah you can reduce graph coloring to it

I think most things compilers do are NP-hard problems 😄 some are even Turing-complete, of course...

not that it matters, they don't need to find the optimal solution

just an acceptable one

sure, optimal is not really needed - getting close to optimal is nice though

I wonder how many problems there are APX-hard --- I think graph coloring is...

🤔

https://www.theverge.com/2021/5/24/22451607/google-photos-high-quality-storage-saver-tool-free-space-blurry-screenshots

users wouldn't see this

20% = about what lossless jpeg recompression saves

so they could use it and decompress a jpeg to the user transparently

without much effort

by the way - how much interest would there be in a plugin for nginx that transcodes your JPEGs on the fly to JXL? 😄

I'm interested. It reminds me of my pet project (<https://github.com/weserv/images>), which should soon support JPEG XL load/save.

I *almost* had it working during the weekend but then I found out our API has some problems for it

We are using http://nginx.org/en/docs/http/ngx_http_image_filter_module.html. It uses LibGD, which recently got AVIF. But it doesn’t understand colour management 🤦‍♂️ (https://github.com/libgd/libgd/issues/136).

to transcode a JPEG you first need to parse it 😄

this would be for lossless recompression though

If direct use libavif(--cicp 2/2/6), icc profile can keep on compressed avif image. ```https://github.com/AOMediaCodec/libavif```

JXL to Jpeg transcoding can also be useful for browsers that don't support JXL, for cases when high quality source images is no longer exist or when Jpegs are uploaded by users, to save space as Lepton does: https://dropbox.tech/infrastructure/lepton-image-compression-saving-22-losslessly-from-images-at-15mbs

yeah but this would be in the other direction 🙂

for the situation where you have a website and you don't want to think too much about it 😛

IIRC less dense but faster

and probably a few more features like progression, since AFAIU Lepton is intended to be a storage format only

lepton is anti-progressive, it predicts DC from AC...

use paq8px 🙂

Is it possible to build a static jxl binary? If yes, how?

On Linux

there's a flag in cmake somewhere

it might be the default cmake flag even

Not default on Windows. Maybe it is on Linux?

this?

ah, probably

by "default cmake flag" I meant that maybe there is a flag in CMake that makes everything static, but apparently not 😄 or at least it's not the one we use

[` 79%] Built target jxl_enc-obj [ 79%] Linking CXX static library libjxl.a [ 79%] Built target jxl-static [ 80%] Building CXX object examples/CMakeFiles/encode_oneshot.dir/encode_oneshot.cc.o [ 80%] Building CXX object tools/box/CMakeFiles/box.dir/box.cc.o [ 80%] Building C object examples/CMakeFiles/jxlinfo.dir/jxlinfo.c.o [ 80%] Building CXX object lib/CMakeFiles/jxl_extras-static.dir/extras/codec.cc.o [ 80%] Linking CXX executable jxlinfo /usr/bin/ld: attempted static link of dynamic object `/usr/lib/libtcmalloc_minimal.so' collect2: error: ld returned 1 exit status make[2]: *** [examples/CMakeFiles/jxlinfo.dir/build.make:104: examples/jxlinfo] Error 1 make[1]: *** [CMakeFiles/Makefile2:939: examples/CMakeFiles/jxlinfo.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... [ 81%] Building CXX object lib/CMakeFiles/jxl_extras-static.dir/extras/codec_jpg.cc.o [ 81%] Linking CXX executable encode_oneshot /usr/bin/ld: attempted static link of dynamic object `/usr/lib/libtcmalloc_minimal.so' collect2: error: ld returned 1 exit status make[2]: *** [examples/CMakeFiles/encode_oneshot.dir/build.make:105: examples/encode_oneshot] Error 1 make[1]: *** [CMakeFiles/Makefile2:908: examples/CMakeFiles/encode_oneshot.dir/all] Error 2`

ahhhh... `-DJPEGXL_ENABLE_TCMALLOC=Off`

Just testing that flag

I think

`[ 93%] Linking CXX executable djxl /usr/bin/ld: attempted static link of dynamic object `/usr/lib/libgif.so' collect2: error: ld returned 1 exit status make[2]: *** [tools/CMakeFiles/djxl.dir/build.make:136: tools/djxl] Error 1 make[1]: *** [CMakeFiles/Makefile2:1044: tools/CMakeFiles/djxl.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... [100%] Linking CXX executable benchmark_xl /usr/bin/ld: attempted static link of dynamic object `/usr/lib/libjpeg.so' collect2: error: ld returned 1 exit status`

I am doing everything wrong ha ha

Why is djxl linking libgif? I don't think we do gif output... 🤔

For decoding?

cjxl needs to decode gif as an input, but djxl shouldn't need it

Have the encoder/decoder and benchmark already been separated from the shared unnecessary code?

In the library, mostly yes, I think

In the tools probably not really