JPEG XL

I'm against non-English not only because of inconvenience, but also because I believe that those who ask must do a little work to be understood by community

They have no respect to others. Chinese is native to me but I don't type in Chinese in an English-major community

A question of "question" is really rude

The same for me, my language is of slavonic group, but I respect others, as everyone should do

His question is pretty simple however that adding with -d or -q is okay

btw it's not obvious to someone who doesnt spend all their time online

1) Maybe defaulting to linear sRGB is a bad choice, and it would make more sense to default to something like Display P3, to avoid the gamut clipping and possible banding issues you'd get when storing the result in a format that uses uint8? Is this a libjxl default or a djxl default? 2) With the new decoder cms api, it should no longer be true that djxl cannot convert back to an ICC profile, right? Maybe djxl is not using the new api yet though, but that should be fixable then.

Is there a way to tell when clipping occurs during decoding?

Regardless of language, opening a github issue for something that should be rather easy to figure out (it's explained in the repo README.md, in the help screen of cjxl itself, in the man page, etc) is not a great sign of respect. I don't expect people to dig down deep in all the documentation before asking a question, but a minimum amount of RTFM would be nice...

if i said that to my mom i'd be beat

We could keep track of out-of-range values when converting from float to uint; it may add a bit of overhead but it might be worth it. Only thing is: even when the input is e.g. just 8-bit sRGB, lossy compression might cause some pixels to get slightly out of range, and then you'd probably not want to get a "gamut was clipped" warning but rather just clip it silently...

does your mom know how to open github issues?

she'd know to ask me to open one

i mean EVERYTHING isnt obvious

you can extend rtfm to read the code

and that is even less obvious

but maybe not to some

but you wouldn't open a github issue, you'd first try to figure it out yourself from the help screen, maybe search the web for some answers, and only if it's still unclear after 2-3 minutes of trying to figuring it out, then consider to open a github issue

even that process isn't obvious

even for computer literate users

True... but there should be a good way to know when to be silent and when the clipping is significant enough to not be silent.

Maybe the metadata would have hints

The metadata says what the original bit depth and color profile is, and when decoding to the same pixel format as the original then there should not be significant clipping.

yeah basically the issue is just when decoding to a different colorspace than the original one, which I think is now no longer something djxl should ever do if it would just use the new cms-enabled decode api.

If it's an enum color space, does it still need a full CMS to decode to a nonlinear format?

no, it should know how to encode to all the transfer functions that the enum can express

Wonder if people encounter this too https://github.com/libjxl/libjxl/issues/2111

I didn't set up -e (supposed to be default as 7) and the results for lossy JXL with an Alpha channel are larger than lossy AVIF at the similar DSSIM or SSIMULACRA2 quality value

Or I need to verify more images with an Alpha channel to get the more comprehensive results

Well that's pretty awesome, so then no CMS is needed to decode to adobe RGB it sounds like

for jxl files created after the cjxl fix for detection, indeed not

does changing around `--alpha_distance` for cjxl make anything better? https://github.com/libjxl/libjxl/pull/2117

Yeah, it says that setting it to lossless is usually better

so alpha_distance=0

which fix?

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

ty

`-a` for quick cmd use

Forgot to mention that I've tried with and without -a 1 when testing with -d 1

The difference was small

I tested with some that were originally several MBs in lossless JPEG XL

Most alpha channels are basically just a simple blobby 1-bit shape with some feathering at the edges. For that kind of content, the difference between lossy and lossless will not be huge.

What does make a difference is `--keep_invisible`.

Does the opposite of that essentially... premultiply? :)

Or it's more lossless than that

it does something different, since just making invisible pixels black is not the best thing to do (it causes dark fringes around the edges since the black will influence the non-invisible pixels)

that's why you should always pre-multiply

pre-multiply helps if the alpha edge is feathered, but if it is a hard edge you'll still have discontinuities in the color components that are bad for DCT and potentially introduce ringing into the visible pixels.

:(

I see three ways to use alpha channels: 1. As a selection/clipping mask to "cut out" parts of an image, where you may later still want to change the mask and you don't want to lose the parts you cut out. In this case, non-premultiplied (like in PNG) and keep_invisible=1 is the way to go. 2. As a way to have transparent/semi-transparent pixels, i.e. images with an arbitrary shape (not rectangular) and possibly holes or translucent regions, where the color of invisible pixels is irrelevant/undefined. In this case, you can go either premultiplied or not, you can safely use keep_invisible=0, and I have a slight preference for non-premultiplied since when using 8-bit buffers (as is common), premultiplication reduces the effective precision of semi-transparent pixels (since the maximum value is equal to the value of alpha). 3. As a way to model both occluded and light-emitting pixels, combining the usual alpha blending with a way to have additive effects (to model things like reflections in glass, or a light source). In this case you need premultiplied, where you allow color values to be larger than the alpha value (so "premultiplied" is a bad term since the values are not actually the result of a multiplication by the alpha value).

nice summary 😄 can I save it for later ? #bookmark

This time, after -d 1 -a 1, I added with --keep_invisible. Value 1 made no difference, but 0 reduced 18% of the file size, while DSSIM became slightly lower (better). The size of .jxl is now close to .avif at the similar quality

> --keep_invisible=0|1 > disable/enable preserving color of invisible pixels (default: 1 if lossless, 0 if lossy). This confuses me as what I did was lossy but it chose --keep_invisible=1 by default

Why avif effect should have different Flavia

Not that inefficient now but not impressive actually

Meow do you think people can discern about that

I'm western not asia

I tested -d 1 however

I see zero difference

Only the grain at the center

If ssimulacra2 also cheated me as well

Has anyone tried to convert a JPEG file encoded with Jpegli --xyb, to JPEG XL successfully?

> Note: Implicit-default for JPEG is lossless-transcoding. To silence this message, set --lossless_jpeg=(1|0). > Encoding [JPEG, lossless transcode, effort: 7] > JxlEncoderProcessOutput failed. > EncodeImageJXL() failed. Adding -j eliminated only the first line of warning

JPEG xl, avif, jpg

JPEG xl looks too much like antonia freckles added not present in the original image

Jpg has the better contrast

Avif is good not excellent

Yes. For some reason the default jpegli settings uses chroma subsampling.

which is not supported for RGB images for lossless jpegxl transcoding

you need to disable it by using 444

On the jxl side we cannot fix this unless we make breaking changes to the bitstream syntax. Chroma subsampling info is signalled as 6 bits that are written only in case `do_YCbCr` is true.

On the jpegli side it could be fixed by not doing chroma subsampling in the XYB case.

Encoder API - jxl/encode.h ``` enumerator JXL_ENC_FRAME_SETTING_DECODING_SPEED Sets the decoding speed tier for the provided options. Minimum is 0 (slowest to decode, best quality/density), and maximum is 4 (fastest to decode, at the cost of some quality/density). Default is 0. ``` Anyone can, please tell, why this setting named DECODING_SPEED? As i can see with 0 encoded files smallest size and at 4 it biggest. I can guess that compression is stronger and need more time to decode, but how that correlated with quality?

If you disable some coding features to prioritize decoding speed, you may get less dense files at your target quality compared to files with all features allowed.

You could also technically think of it as moderating the quality at a given density, but this is probably a less useful mental model.

Could someone else verify the file sizes of lossy .jxl with an Alpha channel, with and without --keep_invisible=0?

I got the different sizes but they're supposed be identical

just found a bug with `cjpegli v0.10.2 e1489592`, produced a corrupted XYB JPG Got fixed in the nightly builds, but not released yet? Why <:PepeHands:808829977608323112>

I assume the input was png, iirc it's a bug with alpha channels

yeah input was PNG

let me try removing the alpha (thought it was thrown away it there's no transparency in the file lol)

JPEG xl normal was bugged one hour ago

I'm pretty sure there's a fully opaque alpha channel

For 5 days it had outstading prestansions in Anime

Is like purple- Violet Darkest

It's like the colour profile not applied correctly

the corrupted pic is on the right open the left one in your browser and you should see it correctly (Discord doesn't support ICC)

I think that's just discord dropping the profile and we're seeing xyb interpreted as rgb

Scarier on my browser

that seems like... xyb interpreted as ycbcr?

Discord may have corrupted it further

nope

Discord just adds some metadata stuff (if you download an uploaded image you'll get a few bytes more) unrelated to how the file should be decoded

I simply clicked the left one and opened it on Safari

Not downloaded locally

that's surprising, doesn't safari support iccv4?

you were right the problem was only with XYB and transparency right ?

not sure about xyb, but that's alpha channel bug, yes

My XYB JPEG by Jpegli (without Alpha) is displayed on Safari correctly

apparently (at least in my case) it is corrupted only for XYB

Well the colours of those Liyue ladies are correct on Firefox

and just tested a few files non-XYB outputs were all bit-identical between the 2 versions of `cjpegli` luckily I don't need to rerun my previous benchmark during 48h <:KekDog:805390049033191445>

everything webkit and blink based does. oddly only firefox doesnt support iccv4 (support claimed since v108 against a flawed test they never adressed since)

The alpha bug in jpegli was *supposedly* fixed in the past, but I noticed on optimised PNGs with Alpha it still broke the encoding. I'll have to check when I'm home though

Oh, wow. Tapping on the image in Discord mobile (Android) actually loaded the ICC profile

Interestingly it only loads the ICC of the image I tap, not if I swipe to the next one

When clicking on the iOS client

So that's how WebKit handles

maybe... iOS does something different than macOS Safari

The iOS client of Discord and Safari on macOS do the same thing

The core for desktop clients is actually Electron (Chromium)

Oh, wow. Even those screenshots are color managed. After a few seconds they suddenly 'click' into being slightly brighter and more vibrant

Yeah it was applied with the colour profile of my display

> (btw why don't we support JXL as an output format? e.g. using fast lossless encoding it could perhaps be a good alternative to PNG or PPM...) would be useful i guess there is no support, simply because it wasn't added, and there are no other reasons <:kekw:808717074305122316> <https://github.com/libjxl/libjxl/pull/3506>

No is based on Discord font

So usually 2k display

Is the same as this but re encoded to jpegli q74

I told them to requantize at 80% and I'm getting much better results now. Just replace the lubrication matrix.

Anime had a bug but it was fixed last week

this looks like not only is it stripping ICC but it's interpreting an RGB jpeg as YCbCr

this was supposedly fixed in git master

so try that

Discord hasn't a specific quantization, 5 days ago I got q39 and was good

It depends on the Bitrate

Hello, can anybody suggest a way to do a visually-lossless encoding of an image in Bayer matrix form (RGGB)? I am looking for a way to encode them with little to none information loss but decent compression ratio (similarly to what I get with quality >95 for normal rgb pictures)

This sugguests -d 0.5 https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front

If I understand correctly, that’s the option for doing a visually lossless compression, which I already obtain on RGB, alternative to -q

It doesn’t specifically cover Bayer/CFA images

As of right now jpegxl does not have support for bayer encoding

It's possible it could be extended in the future but so far it does not support mosaic encoding

D 0.81 -e 7 sometimes it looks good

Preset are rapidly improving

Recompile with strawberry psychotuning if you want the most optimal ghost chili vectors. I got it down to 15kb now.

What format are they in currently? Adobe added JXL as a compression method in DNG, although support is limited due to libraw not updating

DNG probably stores the Bayer data as 4 separate planes or something like that, using the payload codec just to store grayscale images. I would assume.

In JXL we have the `kCFA` extra channel type where the intention is that you could do something like storing RGGB as R,avgG,B and diffG in a `kCFA` channel. That would cause naive decoders to just render it as a half-resolution image with the Bayer 2x2 pattern considered as one big pixel, but the real data would still be there. It would require a custom ICC profile to make it make sense though (to properly scale/interpret the RGB values), and some way to embed the additional metadata needed (like the layout of the Bayer pattern etc).

See also a discussion item I just created today: https://github.com/libjxl/libjxl/discussions/3509

libjxl allows you to create jxl files with kCFA extra channels if you want, but I'm not aware of any applications that are doing that

<@794205442175402004> the context I'm working on is an industrial application that would internally use jxl as compressed storage. I don't need the images to be readable by third party software. As soon as I can use libjxl to compress a visually-lossless image and recover it (as CFA raw image), then it's fine by me

I don't know how these extra channels work. Are they still compressed somehow? As greyscale channels?

extra channels are modular encoded, so no DCT, but it can be lossless or lossy

but I guess the challenge is figuring out what is needed for "visually lossless" in the context of Bayer RGGB data — presumably you want to still have enough precision to adjust colors etc, so you need a bit more, possibly a lot more than just what we usually mean by visually lossless (no noticeable difference between the images as they are rendered on a screen)

It's a bit hard to describe; we process the images through several computer vision algorithms to do things like feature detections; so in general we prefer to work with uncompressed images as any kind of compression artifact can create problems to the algorithm, but we have sometimes issues with image storage in large scale installations

in general, stuff like the classic jpeg dct blocks basically destroy everything we do

for RGB images (so not CFA), we can somehow work with jpeg 99% but still suboptimal

with jpeg xl, we found out that 95% is absolutely ok for what we do. At 90% we start to have some rare issue

we plan to deploy jpeg XL for RGB images at 95% and that would solve half of the problem for us

CFA images is the other half, so I was trying to understand what options do we have

notice that we could of course also demosaic the CFA image and compress it with JXL at 95%, but that's 4 times more input pixels

what about using jpeg 2000

wavelet doesnt have that artifact problem

Out of curiosity, did you try lossy modular along with VarDCT? The different type of artifacts might mean you can use a lower quality without impacting the machine vision

My first thought goes to the various kinds of textures for 3D models, but I think the spectral imaging would be a better choice assuming the images are encoded on the satellite and then transmitted on a limited connection. Naturally testing would tell what kinds of extra channels are worth compressing together

Demosaicing and then doing out-of-the-box lossy on that is probably the easiest thing to do. It's more pixels but basically the chroma components will effectively have little of the highest frequencies so they will just compress better. Keeping the raw Bayer data probably makes the most sense if you're going for lossless. In principle you could also do something near-lossless on raw Bayer data but it's not quite clear to me what metric you would want to optimize for in such a lossy encoder.

Right I could try also demosaicing after all

I’ll try both approaches and report back

Actually it’s not clear to me as well the metric, I’m trying to understand that myself. I would say that psycho visual metrics meant for human eye are most likely wrong, and that includes transformations like chroma subsampling

I noticed that JXL at 95% does a very slightly “blur like” effect that removes some traces of thermal noise from the picture; that’s actually almost an improvement in our case

We do have denoising we run on the pictures often

Lossy modular doesn't produce macroblocking artifacts

It's worth trying

is it safe to say `cjpegli --xyb` will only add an ICC colormapping profile to the output JPG ? Or does it do something else too ?

I mean, except for the ICC, everything in that JPG is standard?

yeah

thx

isn't it an RGB jpeg so it's kinda less standard

I don't think so, since we can set `--chroma_subsampling=444|440|422|420` 🤔

I don't think that setting works correctly when you do XYB

oh

so if I recap correctly cjpegli use by default `yuvj444p` for non-XYB images and `gbrp` for XYB And since it is `gbrp`, a bruteforcing scans prog (for JPG optimization) just crash bc it's not common (but surprisingly not everytime) and when using `--xyb --chroma_subsampling=444|440|422|420` still seem to work

oh, I see we can use the color space we want with ``` -x key=value, --dec-hints=key=value color_space indicates the ColorEncoding, see Description(); ```I just don't know where is the `Description();` 😅

I can't find anything useful in the in the code

how do I set that?

also what's "modular mode"?

You need to use 444, by default it uses chroma subsampling with RGB which is incorrect

`cjxl -m`

It just means it doesn't use DCT

That's all it means really in this context

jpegxl has a lot of non-DCT tools

If using modular and lossy together it uses DWT I think

Haar/Squeeze/wavelet transform of some kind

I am not that knowledgeable about it

But it doesn't produce macroblock artifacts

So you might be interested in it

I used to think it was just an unoptimized and unrecommended setting but it's actually quite good

Softwares will show an ICC called "XYB_Per"

interesting, maybe this will help compatibility and xyb finally become more usable https://github.com/libjxl/libjxl/issues/3512

> If TRUE, an Adobe APP14 marker is emitted. jpeg_set_defaults() and > jpeg_set_colorspace() set this TRUE if JPEG color space RGB, CMYK, > or YCCK is selected, otherwise FALSE. It is generally a bad idea > to set both write_JFIF_header and write_Adobe_marker. In fact, > you probably shouldn't change the default settings at all --- the > default behavior ensures that the JPEG file's color space can be > recognized by the decoder. From libjpeg-turbo, for boolean write_Adobe_marker

It's an apparent issue for Finder now

I've seen at least 3 different kinds of wrong colours with softwares I use

Nice

Some really really good issues being raised on the issue tracker lately

Lots of low hanging fruit spotted by people thanks to increased attention to libjxl

lol, this is the dev of `jpegultrascan` (bruteforcing scans script for JPG optimization), yesterday I opened an issue on its repo because some XYB JPGs were'nt parsed correctly

the world is small <:KekDog:805390049033191445>

Doesn't djxl convert JPEG XL to JPEG via Jpegli?

The file size at the same quality becomes much larger and closer to libjpeg-turbo

it just uses whatever libjpeg you happen to have installed. If that isn't jpegli, it doesn't use jpegli.

Is this related to an ICC profile? https://github.com/libjxl/libjxl/issues/3515

I don't know why the generated .jxl would be applied with an ICC called "QuickTime 'nclc' Video (1,2,2)" for me

The .jxl image is slightly brighter

> chunk gAMA at offset 0x00025, length 4: 0.45455 > chunk cHRM at offset 0x00035, length 32 > White x = 0.3127 y = 0.329, Red x = 0.64 y = 0.33 > Green x = 0.3 y = 0.6, Blue x = 0.15 y = 0.06 yeah, probably color management. Viewing them side by side in waterfox they're identical, trying to drag them onto a comparison website shows differences

does djxl decode it to a png properly? I would assume it should

Looks identical but DSSIM value is 0.00118823

and ICC becomes "RGB_D65_SRG_Rel_g0.45455"

My own files don't have this issue

ffmpeg seems to be decoding it fine for me, or jxl encoding it fine for me, can you send me the jxl file you encoded? ```ps ➜ meow ffmpeg -hide_banner -loglevel error -i me.png -c:v ppm -f image2pipe - | b3sum c228e956aa2d81b3e30f3e3198dd5f61311f5a97e92890b71b0775333552d597 - ➜ meow ffmpeg -hide_banner -loglevel error -i me.jxl -c:v ppm -f image2pipe - | b3sum c228e956aa2d81b3e30f3e3198dd5f61311f5a97e92890b71b0775333552d597 - ➜ meow ffmpeg -hide_banner -loglevel error -i me.jxl.png -c:v ppm -f image2pipe - | b3sum c228e956aa2d81b3e30f3e3198dd5f61311f5a97e92890b71b0775333552d597 - ```

Reminder: I didn't submit that issue

I simply used `cjxl -d 0` for the PNG file

yeah that's decoding to the same thing for me, so Id assume whatever the issue is, it's software failing to decode the ICC properly

I think ffmpeg decodes the icc anyways [Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&quality=lossless&name=Hmm)

yeah MPV looks similar on all of them and I know it handles ICC

All softwares I could use on macOS show "QuickTime 'nclc' Video (1,2,2)", and the person also uses macOS

Not sure about what's wrong with the original PNG file

ImageMagick tends to produce PNGs with gAMA and cHRM but no sRGB chunk

(I don’t think they’ve fixed it)

the net result is that those PNGs are, strictly speaking, _not_ sRGB

cjxl then turns that into an ICC profile, and software that normally ignores gAMA chunks ends up taking it into account through the ICC profile

in software that does take gAMA into account (e.g. Chrome, Thorium), the original and decoded file look the same

Why would it do something that makes sense?

Hi guys, from current libjxl API, is it possible to call jpegli functions to encode a u16 RGB data to jpeg? I cannot find a clue in current libjxl doc.

Hi, is there a way to set the quality of the compressed image? I used to use `CompressParams.quality_pair` but ig it has been removed

https://github.com/libjxl/libjxl/blob/main/lib/include/jxl/encode.h#L1437

You may want to use JxlEncoderDistanceFromQuality if you prefer to use a quality scale where higher number is better

Gotcha, thanks

Corrected a few typos https://github.com/libjxl/libjxl/issues/3514

anyone knows how I can get the ssimulacra2 score of PNG source and XYB JPG ? It does not support ICC, and ICC is still used with `djpegli`, so I'm searching for either ssim2 with ICC support or to apply (then remove) the ICC to PNG

nevermind, apparently there's a ssimulacra2 tool in libjxl that supports XYB, didn't know it before

it has to be built with lcms2 or skcms and then it should support xyb jpegs just fine

Good news that Homebrew enabled `butteraugli` and `ssimulacra2` within jpeg-xl https://github.com/Homebrew/homebrew-core/pull/168660

Yes, thanks <@702298678333014087> 🙂

Hope they'll find a solution for enabling cjpegli and djpegli

Question: ~~what kind of bear is best?~~ <:CatSmile:805382488293244929>

Can a jpeg-transcoded jxl created with v0.10.2 be decoded with e.g. djxl v0.3.7? How far compatibility between cjxl/djxl versions goes?

I guess it can't... ``` > cjxl PXL_20240224_135225460.jpg v0102.jxl -j 1 JPEG XL encoder v0.10.2 e148959 [AVX2] Encoding [JPEG, lossless transcode, effort: 7] Compressed to 5207.5 kB including container > .\djxl v0102.jxl v037.jpg Read 5207483 compressed bytes [v0.3.7 | SIMD supported: AVX2] Unknown compressed image format ```

libjxl 0.4 is supposed to be the first version that has a full decoder implementation

libjxl 0.2 is the first version that has a compliant encoder (one that writes valid files that can still be decoded)

older versions than 0.4 should probably still be able to decode the codestream itself, but the container format (file format) was still being developed iirc

<:Thonk:805904896879493180> ``` > cjxl PXL_20240224_135225460.jpg v0102.jxl -j 1 JPEG XL encoder v0.10.2 e148959 [AVX2] Encoding [JPEG, lossless transcode, effort: 7] Compressed to 5207.5 kB including container > .\djxl v0102.jxl v070.jpg JPEG XL decoder v0.7.0 36ece47 [AVX2,SSE4,SSSE3] Read 5207483 compressed bytes. Warning: could not decode losslessly to JPEG. Retrying with --pixels_to_jpeg... Decoded to pixels. 3000 x 4000, 166.73 MP/s [166.73, 166.73], 1 reps, 16 threads. Allocations: 695 (max bytes in use: 2.444956E+08) ```

could be there were some bugs in earlier versions of the decoder that cause it to fail on some specific inputs

In general it is a good idea to not use old versions of software — there is no good reason to still be using old libjxl versions. Bugs have been fixed meanwhile.

Agreed. I'm just participating in a conversation where a person complains that some jpeg-transcoded jxl created in v0.10.2 doesn't open in the current version of IrfanView. And the IrfanView author explains it this way: “The file uses some new features which don't work with the older LibJXL”. Of course, without the file itself, this is just chitchat.

Well, IrfanView has recently updated Jpeg_XL.dll, but with previous one I've never faced any issue with opening jpeg->jxl. It still does not read any metadata from jxl, so no exif, no color profile, unfortunately

There are no new features, the bitstream has been final since libjxl 0.1. But there are bugs in older versions of libjxl, some of which causing it not to be able to decode some valid jxl files.

I use qimgv on windows with qt-jpegxl-image-plugin. I always build it myself based on the latest version of libjxl. Recently I figured out how to build with exiv2 v0.28.2, and now qimgv can read exif even in jxls with compressed boxes. Hope the qimgv author will fix this in main soon.

A solution? lol, just don't disable it. cjpegli is enabled by default.

huh something seems to be very wrong with faster decoding 1 and lossless `cjxl windwaker35xnative.jpg windwaker-no-fast-1.jxl -d 0 -e 7 --lossless_jpeg=0 --faster_decoding=$VAL` ```ps ➜ Pictures time djxl windwaker-no.jxl --disable_output JPEG XL decoder v0.10.2 e1489592 [AVX2,SSE4,SSE2] Decoded to pixels. 23164 x 18480, 35.611 MP/s [35.61, 35.61], , 1 reps, 12 threads. djxl windwaker-no.jxl --disable_output 131.58s user 1.99s system 1102% cpu 12.112 total ➜ Pictures time djxl windwaker-no-fast-1.jxl --disable_output JPEG XL decoder v0.10.2 e1489592 [AVX2,SSE4,SSE2] Decoded to pixels. 23164 x 18480, 181.492 MP/s [181.49, 181.49], , 1 reps, 12 threads. djxl windwaker-no-fast-1.jxl --disable_output 21.16s user 3.99s system 933% cpu 2.694 total ➜ Pictures time djxl windwaker-no-fast-3.jxl --disable_output JPEG XL decoder v0.10.2 e1489592 [AVX2,SSE4,SSE2] Decoded to pixels. 23164 x 18480, 170.684 MP/s [170.68, 170.68], , 1 reps, 12 threads. djxl windwaker-no-fast-3.jxl --disable_output 19.92s user 5.69s system 975% cpu 2.626 total ➜ Pictures l | rg -i windwaker .rw-r--r-- 533M quack 24 Apr 18:03 windwaker-no-fast-1.jxl .rw-r--r-- 90M quack 24 Apr 17:53 windwaker-no-fast-3.jxl .rw-r--r-- 51M quack 24 Apr 17:54 windwaker-no.jxl .rw-r--r-- 23M quack 24 Sep 2022 windwaker35xnative.jpg ```

https://dolphin-emu.org/m/user/blog/progress-report/2016-november/windwaker35xnative.jpg here is the source image, ill try a couple more images when I get the time and write up an issue ticket if one doesn't already exist

https://github.com/Homebrew/homebrew-core/pull/167195

Quite a challenge

Anyone know where does the fact that NetBBM PFM (float) files are "bottom-to-top" appear?

https://pauldebevec.com/Research/HDR/PFM/

PBM and PNM are top to bottom, but it looks like every open-source tool thinks PFM another way.

Oh, looks like a source for this is a Gnome GIMP 🤦‍♂️

https://netpbm.sourceforge.net/doc/pfm.html

Have the encoder and decoder of libjxl addressed APNG and HDR functions of PNG, described in the third edition of PNG specification?

That's a cjxl/djxl problem, not a libjxl problem. Libjxl does not deal with PNG.

cjxl/djxl should handle animation and cICP chunks correctly, modulo bugs.

Sorry that's what I wanted to mention

These could encourage more artists and photographers to experiment JPEG XL

Technically cjxl and djxl are tools in libjxl source tree and included with the rest of the libjxl project

I think he was asking if the bug was fixed that made 99% of apng files unable to be read

Yes, in particular HDR works quite well, converting HDR PNG to/from HDR JXL with the current tools works fine as far as I can tell. I use Thorium on macOS to view the images and they look identical; it also works correctly in Adobe Camera Raw and in Apple's Photos app. In most other things though, actual HDR rendering of images is still broken (e.g. Safari and Preview, anything linux afaik, ...)

Looks like it was fixed by https://github.com/libjxl/libjxl/pull/3476

Perhaps we should change our PNG reading/writing and get rid of the dependency to libpng. We could use lodepng for decoding and fpnge for encoding instead. As a side effect, cjxl and particularly djxl would get faster from the end-user point of view (especially djxl is currently often spending most of its wall time on png encoding of the decoded image, not on the decoding itself). WDYT, <@&803357352664891472> ? (also we should stop using libjpeg-turbo/sjpeg for reading/writing jpegs and use jpegli instead)

In general it would be good imo to reduce the amount of dependencies we introduce in libjxl builds. Currently e.g. the homebrew package (https://formulae.brew.sh/formula/jpeg-xl) depends on libpng, libjpeg-turbo, giflib, openexr, and webp. Probably webp is just for benchmark_xl because cjxl/djxl don't even support that. The libjxl repo kind of has a lot of different things besides the core libjxl itself — there's cjxl/djxl, jpegli, metrics, hdr tools, benchmark_xl, plugins, various other tools. We're not really helping distro maintainers to make sense of it all by putting everything together in one big kitchen sink repo and basically letting them figure out what is important and what is not, which tools should be included in a distro package and which tools not really, and how should it be split up into several packages. Maybe some reorganization of `tools/` would be useful, or at least some document that gives a high-level overview of all the software that is on the repo (and how to build it or disable building it).

yeah, that would be really great one of the most requested things

IIRC lodepng is significantly slower than libpng at deciding

also lodepng doesn't support streaming (not that it's useful right now, but maybe in the future)

some time ago i tested decoding and lodepng with zlib-ng is about as fast on average as other png libs, but maybe spng will be something better for decoding, also streaming is supported but I noticed that lodepng is more robust for decoding, for some reason much less failed decodes

lodepng should be good enough though, it's only required for the tools...

It might be a good idea to separate the library and the tools in separate trees, like how opus/vorbis/xiph does things

That way the library itself can have very minimal dependencies

That I imagine would make lots of developers happy, to have a pure library with very minimal dependencies and is very fast to integrate and compile

That would have huge value.

It would also help the libjxl devteam, since library issues would be separated from issues with the tools.

Btw, I notice dozens of duplicate issues on the issue tracker, all centered around a bug with djxl incorrectly decoding to linear values when using integer output format, best explained here: https://github.com/libjxl/libjxl/issues/2147

If the tools are in a separate tree than the library, the benefits are so diverse and numerous the more I think about it. For the tools, it would make it easier to show people a good example of how to use the library, and it would discourage the library and tools from being too interdependent or too bloated since there would be a clearer boundary between tool code and library code.

It actually blows my mind how beneficial it would be, the more I think about it. And xiph does a similar thing with their codec tools and library code.

They're a good example of what I mean.

I wonder if there are any benefits to having them in the same repo...

I think libjxl should only contain the actual library including libjpegli, and everything else like decoding and writing foreign filetypes and conversion tools like cjxl and cjpegli should be in a different repo such as jxltools

Or jpegxl-tools if you prefer

With no "lib" in the name so it's clear it's not meant to be used as a library and it's just tool code

ssimulacra2 is placed inside Cloudinary

There are 8 repos inside libjxl's Github account

The main benefit of just having everything in one repo is that it makes it really easy to make tools that use internal functions of the library that are not available through the api. A lot of general image functions (convolution, color conversions, etc) are used by tools like the metrics, the hdr tools, etc. Also I believe in Google there may be some per-repository bureaucracy, which would also be a reason to avoid splitting things. But yes, I like the idea of a libjxl repo that is as lightweight as possible, and a jxl-tools repo that has the dependencies and clutter (and has libjxl as a submodule).

it's also part of libjxl, the version at Cloudinary is just an attempt to make it easier for people to get just the metric without having to build all the rest (and also it's a way to show some more info about it via that README.md)

many possible options

I'm trying to use libjxl from zig, but a quite weird thing happened. The correct jxl generated from my Rust binding ``` [255, 10, 8, 16, 252, 100, 2, 0, 19, 136, 0, 204, 0, 183, 30, 170, 1, 0, 80, 161, 50, 202, 184, 193, 203, 185, 158, 47, 63, 116, 88, 76, 219, 184, 206, 208, 86, 219, 22, 150, 48, 54, 219, 11, 131, 132, 132, 83, 216, 184, 248, 13, 223, 156, 170, 6, 157, 110, 3, 34, 100, 84, 146, 0] ``` The wrong jxl generated from Zig binding ``` [255, 10, 8, 16, 252, 100, 2, 0, 19, 0, 4, 0, 204, 0, 183, 30, 170, 1, 0, 80, 161, 50, 202, 184, 193, 203, 185, 158, 47, 63, 116, 88, 76, 219, 184, 206, 208, 86, 219, 22, 150, 48, 54, 219, 11, 131, 132, 132, 83, 216, 184, 248, 13, 223, 156, 170, 6, 157, 110, 3, 34, 100, 84, 146, 0] ``` The only difference is the 10th element. In the correct one, the 10th element is `136`. In the wrong one, the 10th element is `0` and an additional `4`. Both codes are the same to encode a 2x2 pure red u16 RGB data. What could be wrong in the Zig version?

By the way, all the `JxlEncoderStatus`s are 0 during the process steps.

Oh, I figured it out. This was caused by forgetting to close the frame.

That's a very bad practice though for so many reasons. If you want the codec tools to be a good example project that demonstrates how to use the libjxl library, then that's a terrible way to do it.

Having them separated will make it clearer and easier for the library code to be the best library without any baggage from the tools, and the tool code to be the best example tools, without relying on any special internal stuff that no one else would rely on.

Forcing yourselves to use libjxl the same way any other adopter would use it. To avoid becoming out of touch with the needs of actual libjxl adopters/users.

Otherwise, libjxl developers are shielded from the potential shortcomings and deficiencies of the library API

It will be less obvious what convenience features are missing from libjxl's publically exposed API

Less obvious to the libjxl devteam that is. But still obvious to third party adopters.

I hate bureaucracy. If that's a real concern, then it's possible to just separate the filesystem tree and build systems as much as possible without actually making a new repo, for the sake of better code organization and clarity, and convenience for packagers.

Have a separate build system and folder for the tools and the lib

A clearer demarcation would be incredibly convenient for adopters, packagers, and even the devteam to keep things more organized

Sorry I'm getting so excited about it lol

It's extremely common to have reference tools in the same repo as the library, I don't see the issue.

What would perhaps be more useful would be reorganizing the repo into fully separate things in separate folders.

Isn't that what I'm saying?

More separation for clarity and organizational sake, and to give the libjxl devteam slightly more exposure to the limitations of the public API that everyone else is supposedly expected to use

The biggest improvement would be separate build systems for packagers.

So the library code itself can be built alone with minimal dependencies and the tools can be built separately

sorry, I stopped reading about halfway thru your wall of text

It would be bad if cjxl or djxl did that. But e.g. for something like jxl_from_tree it is unavoidable. We don't want to put that stuff in the API, but it does make sense to reuse the code to generate jxl bitstreams.

Well, little utilities like that should stay bundled with the rest of the library code. They probably don't have any external dependencies.

the "devtools" as they're called in the build system

There's no reason to separate those, since doing so won't reduce any dependencies or bloat in the library code

They kinda belong there.

Yeah I hate that to include jpegli I have to also build bechmark_xl_fuzzer

And require minimum 4g ram to build

And minimum 4 core processor

And 30gb of storage

jpegli needs something like zlib-ng, like a libjpeg-compatible version and a standalone with extended native api, also for windows dlls (and vcpkg libs) without headers and stuff from libjpeg(-turbo) <https://github.com/zlib-ng/zlib-ng>

You don't though...? Devtools are not built by default I don't think.

Anyone else getting a failure with JxlTest.RoundtripLargeEmptyModular ?

with the latest dev version

Hey, could a C/C++ developer please take a look at this patch: https://github.com/JacobDev1/libjxl-utf8/blob/main/utf8_0.10.2.patch I cobbled together some code to patch in UTF-8 support to `cjxl`, `cjpegli` and the rest. I could use some feedback on it. Can it be improved or it's a bad idea in general? Thanks

it’s something we’ve considered doing and just not got around to actually looking into

I thought the windows api uses utf16 lol

Windows’ “Unicode” API uses UTF-16, whereas its “ANSI” API uses whatever the local codepage is

this manifest exploits a new feature in Windows 10 whereby applications can ask for the “local codepage” to be UTF-8 within their process

https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

> Win32 APIs often support both -A and -W variants. > > -A variants recognize the ANSI code page configured on the system and support char*, while -W variants operate in UTF-16 and support WCHAR. > > Until recently, Windows has emphasized "Unicode" -W variants over -A APIs. However, recent releases have used the ANSI code page and -A APIs as a means to introduce UTF-8 support to apps. If the ANSI code page is configured for UTF-8, then -A APIs typically operate in UTF-8. This model has the benefit of supporting existing code built with -A APIs without any code changes.

`cjxl` and other `libjxl` tools fall back onto ANSI on Windows. You can enable UTF-8 support in `intl.cpl`, but that just breaks other software. People suggest adding UTF-8 support instead of UTF-16, since that's "more crossplatform". https://github.com/libjxl/libjxl/issues/683 My software relies on `cjxl`, which is why I'm trying to patch this any way I can.

Does it really break software?

Seems like Windows is configured to mangle filenames by default and there isn't a simple and obvious way for a developer to ask nicely for windows to not mangle filenames

Since its still in the pre-DOS era where maximum absolute path for a file can't be longer than 256 characters including slashes.

I recommend you just install WSL and run the linux version of cjxl that way

Or just install fedora or something

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later

Took this long and it's still opt-in? :P

<@1028567873007927297> I've seen reports that this Windows Beta: UTF-8 feature does break software. I'd rather avoid modifying users' systems. UTF-8 support is doable even without modifying the original source code. For my use case `cjxl` has to be run natively on Windows. The patch I posted does seem to work fine. I'm just trying to get feedback from more experienced devs.

Yeah, apparently it does break software that assumes you are using a non-ascii code page

Like a russian code page for example

Basically it will break software that only works if your system is set to a foreign language codepage in the first place

So... unless your system was already set to the language and codepage it's expecting, it was already broken to begin with and no more or less broken after setting your system to utf8. So, no harm in setting it to utf8...

Also, what happens if you use the new Windows Terminal and pwsh.exe that have utf8 support? Does it still mangle the command line arguments?

Download Windows Terminal and use that instead of command host or whatever

I'm using it via `subprocess.run` in Python, but the shell choice is probably irrelevant. The patch fixes `fopen`'s ability to read UTF-8 paths in `libjxl`. Personally, I use Linux where `cjxl` does read UTF-8. However, this is more of a "I need this to work for other people as well" type of issue. Don't worry about it. I already got the fix. I just wanted someone to take look at that patch and tell me If there is something I should know about.

Ok 😂

It's just annoying because it looks like cjxl is using the C api correctly and Windows can't make up it's mind what sort of hoops the programmer should have to jump through in order for it to work as expected

For what it's worth, the patch makes sense to me, except for the changes to add_definitions/add_compile_options, that's some cmake greek to me.

but I'm just a fox

TORYAH

there is no such thing as "using the C api correctly"

https://youtu.be/zRTP3QgOBSo

FIYAA!

https://i.kym-cdn.com/photos/images/original/001/005/231/17f.jpg

https://en.cppreference.com/w/c/io/fopen

C has a standard library, and a specified way of relying upon it, in order to open files, so I don't know what you possibly mean.

Hmm, I'm trying to find out more information about text encoding for arguments in python's subprocess module...

Sorry, I can't seem to find anything useful, I thought I did at first but no. :(

According to this: https://peps.python.org/pep-0529/ ...you might be able to pass filenames as arguments to cjxl by wrapping them in os.fsencode()

As I mentioned before, this is not an issue with Python, but with the `libjxl` itself. `subprocess.run` natively supports UTF-8. I tried the `os.fsencode()` workaround and this is the result > Could not open C:\Users\user\Desktop\???.jxl for writing > Error: No such file or directoryCould not write jxl file. I've spent so many hours trying out different workarounds, and I just don't want to anymore. If `cjxl.exe` cannot open it, no amount of Python trickery can make it work. Yes, I tried changing code page, specifying UTF encoding, pretty much everything. `libavif` used to have the same problem, until recently. The patch I posted is based on their approach https://github.com/AOMediaCodec/libavif/commit/3ec01cefd1ddd266a622d5e114a0888581b68f4a

`cjxl anim-icos.png anim-icos.jxl -d 0 JPEG XL encoder v0.10.2 0.10.2 [AVX2,SSE4,SSE2] Getting pixel data failed.` I can't make it work, downloaded from https://jpegxl.info/test-page/, neither .apng nor .png

https://github.com/libjxl/libjxl/issues/3430

Uh I missed this one

Is it okay to use latest git libjxl if `JxlTest.RoundtripLargeEmptyModular` fails? I can't find any information about the testing harness...

can I make `ci.sh` skip building test binaries? `SKIP_TEST=1` skips *running* tests but not building those.

-DBUILD_TESTING=Off probably does that

didn't know that `ci.sh` accepts extra cmake arguments, that works. thanks!

How to convert greyscale images correctly? cjxl results a larger but "empty" .jxl file

sounds like a bug somewhere

does it look empty regardless of viewer? what does `jxlinfo` say about it?

Completely empty regardless of viewer. The prompt was simply `cjxl -d 0`

`JPEG XL image, 3500x3500, (possibly) lossless, 8-bit Grayscale+Alpha Color space: Grayscale, D65, sRGB transfer function, rendering intent: Relative`

is the alpha correct?

perhaps worth trying to compress a version of the PNG without it, just to check

Uh so without Alpha, cjxl can work correctly. I was mistakenly thinking about if ImageOptim was a cause

With the Alpha channel, the tested greyscale image without being optimised by ImageOptim still becomes empty via cjxl

Regardless the status, resulted JXL files are always larger than optimised PNGs

The tested greyscale PNG images are generated by Clip Studio Paint

For other codecs, libavif and libwebp can work correctly but libheif corrupts severely

Tried another image and the resulted JXL remained empty

Although it's smaller this time

Thus the possible issue is from "8-bit Grayscale+Alpha"

Those filesizes of the jxl files seem to indicate they do actually do contain the data. Maybe it's a bug in how the decoded image is passed back?

is this a bad jxl? its decoding fine for me

Affinity Photo displays it properly

whatever their OS or file browser is using to decode JXL files might be on some version of libjxl that fails to decode it?

I've been having problems with "8-bit Grayscale+Alpha" PNG->JXL on MacOS forever. My solutions are 1) convert to RGB in Photoshop and save as new PNG or 2) "Flatten Image" in Photoshop then save as a new grayscale PNG. either of those changes produce a PNG that converts to jxl just fine.

So here's a real-world, in-the-wild example of the problems I'm running into with some grayscale PNG files with alpha channels This is not my photo, it was a PNG downloaded off twitter as a PNG. Original PNG from Twitter opens just fine with every app I have that reads PNG That PNG converted to JXL as follows is broken almost everywhere (Adobe Camera Raw seems to read it, messing up only the gamma) The conversion with relevant info (macOS Sonoma 14.4.1): xxxxx xxxxx % cjxl --version cjxl v0.10.2 0.10.2 [NEON] Copyright (c) the JPEG XL Project xxxxx xxxxx % file original.png original.png: PNG image data, 1024 x 1280, 8-bit gray+alpha, non-interlaced xxxxx xxxxx % cjxl original.png converted.jxl JPEG XL encoder v0.10.2 0.10.2 [NEON] Encoding [VarDCT, d1.000, effort: 7] Compressed to 62472 bytes (0.381 bpp). 1024 x 1280, 5.529 MP/s [5.53, 5.53], , 1 reps, 12 threads. xxxxx xxxxx % file converted.jxl converted.jxl: JPEG XL codestream xxxxx xxxxx % jxlinfo converted.jxl JPEG XL image, 1024x1280, lossy, 8-bit Grayscale+Alpha Color space: Grayscale, D65, gamma(0.454550) transfer function, rendering intent: Relative Opening both original.png and converted.jxl in Acorn reveals the JXL to be stretched horizontally, cropped off and translucent - unusable.

Opening both original.png and converted.jxl in Photoshop forces Adobe Camera Raw to open the JXL first, then it opens in Photoshop with darker gamma, I can recover the hair where it gets dark but it no longer looks the same by default.

Apple Preview will open the JXL stretched, cropped and weirdly interlaced. (zoomed on right to show interlacing)

Mac Finder and Safari will just show blank white. When I examine the Twitter-downloaded PNGs that won't convert correctly (like this one), they consistently show a single translucent column of pixels on the right-hand side, I've seen this exact same pattern on a hundred or more images.

I tested on macOS 14.4.1

Just a workaround. Having to convert to RGB all the time is annoying

Grayscale is a big sector for artworks but the usage of grayscale+alpha is relatively rare

The potential big usage could be exchanging clips of comics

Grayscale is somehow something that always causes trouble. E.g. what transfer curve to apply to untagged grayscale images is something applications still disagree on, iirc.

It seems that GIMP and Thorium can read

How does r3dfox handle them? <https://github.com/Eclipse-Community/r3dfox/releases/tag/125.0.3>

works fine. I even tested a fork of Firefox without the unmerged JXL patches and it worked fine as well.

<:astolfoarc_thumbs_up:1152603499230675054>

This looks suspiciously a lot like the bug with jpegli and images with alpha channel

Wonder if it's related

Or the issue is from built-in libjxl in macOS

However cjxl still produces much larger greyscale .jxl files regardless Alpha

<@794205442175402004> maybe for lossless it's also not that much needed by default in most cases (like webp lossless)? https://github.com/libjxl/libjxl/pull/3562

maybe start with integrating fpnge at least (would be nice) or some simpler things? other core devs seem to have other priorities for now <:FeelsSadMan:808221433243107338> fpnge also still doesn't have ppm support

one issue with fpnge is that it's not portable, it's hardcoded for x64 iirc

sad, it would give fpnge a second life and not to be abandoned but at least as an option for x64 and official binaries, and because png decoding still uses libs with encoding capability if fpnge doesn't support something

or maybe jpegli first and also because it's already in the libjxl repository anyway, but it would be better to use some extended features, not just the libjpeg api and I would say, a lot of time and work spent on developing something, but then very little initiative to bring it to the masses and make it more polished and usable like jpegli has no standalone libraries that are easy to integrate and distribute, so people after the initial hype of the announcement may forget that jpegli exists <:PepeHands:808829977608323112>

jpegli is an amazing feat but it brought many confusion for non tech readers

it's not *too* hard to make fpnge work on non-x86

just never had enough motivation for it 😄

Trying to understand how exif meta-data writing working. Use cjxl for that. In debug mode check AddBox steps that looping for exif, jumbf, iptc and xml boxes. And see that all boxes except xml is empty. Source image jpeg or png have exif metadata. And output Jxl also have exif metadata block. What I missing in process? Did box decoder import all meta data to XMP and encoder encode this data back to exif/xmp/iptc back?

so when fpnge is integrated into libjxl it won't just be a project for fun <:KekDog:805390049033191445>

the exif box is called `Exif`, not `exif`

Right. But a question not it it name but a process. I see that a code skip all except xml but final jxl file still have exif data. I guess that all original meta data in xml box?

The issue was simply for not following the designated behaviour

`--keep_invisible=0|1 disable/enable preserving color of invisible pixels (default: 1 if lossless, 0 if lossy).`

It's nothing to do with which one is better or not

yeah, but I mean it can also be changed for lossless by default, because in most common use cases it's not needed and will slightly improve compression and there's still an option to enable it if needed for specific cases

But is it still technically lossless?

visually it's still lossless, but there may be some data lost, but in most images it's just junk data (from some editors, wrong conversion, etc)

Then default to 1 would be safe for the absolutely lossless needs

Speaking of keep invisible, Does enabling associated alpha also enable keep invisible?

for non associated alpha this is true. 1,0,0,0 is not a valid colour, but for associatied alpha it is

so it matters a lot for proper compositing in color managed pipelines

Unfortunately, this is needed because There are image formats that don't properly signal whether or not they're associated with alpha or not.

That being said, if you're encoding from a PNG, you can always do it because PNGs are never associated alpha. So you could do it input aware, I suppose.

* PNG you can always discard since it is never associated alpha so it's fine to discard even during lossless encoding if you want to maintain spec accuracy (PNGs encoded for associated alpha does exist but they violate the spec) * ppm based, don't signal, so it's not ok to discard lossless, but probably fine for lossy * EXR is always associated alpha, so it should never discard invisible pixels even during lossy encoding

What would keep_invisible=0 do for EXR converted to lossy JXL? I've never used it

not all EXRs have invisible pixels with color data, so those would be fine. some EXRs will completely break however

Will the image look corrupted with invisible pixels?

not corrupted, but color data would be all sorts of messed up, imagine a candle in a dark room, the glow of the candle gives a yellow-orangeish tint to everything in the room right? so imagine a picture like that, but just completely missing the yellow-orangeish tint

depending on how the image is encoded, it may also be missing the flame

That could be kind of "lossy"

well it would be very lossy, as it would completely destroy the image when rendered out

there _are_ no invisible pixels in EXR, are there?

since any non-zero pixel data is supposed to be added to the (optionally occluded by alpha) background

any non-negligible change to the pixel data is potentially visible

I thought the background was optional? but that would give context to this issue https://gitlab.gnome.org/GNOME/gimp/-/issues/5370 https://twitter.com/jkierbel/status/1210235542404775945

<@277378565304090636> for reference as to how it would look, these are good things to read

The result is the same on my GIMP

My other viewers can't open it at all

gimp is just bugged, if you go into `channels` then disable the alpha it should render

Yeah I actually referred to the GitLab page

interesting result from the encoded jxl image

oculante's preview renders it right but not the main image viewer

The issue has been opened for 3 years

oh good `cjxl ../CCSkull_Linear709.exr test-skull-invis-no-pre.jxl -d 1 --keep_invisible=0 --premultiply=1` keeps the no alpha pixels [pepeHappy](https://cdn.discordapp.com/emojis/1160370117302046780.webp?size=48&quality=lossless&name=pepeHappy)

oh i wonder if the transfer is messed up with this

Okular renders it on a pure white background, funny

KDE's thumbnail generator fucks it up

krita has the same issue where you need to disable the alpha, but it renders the jxl properly unlike gimp.

im an idiot, like a massive idiot, this is because with alpha disabled, all of the pixels are as if they were solid, the fact that krita doesn't have this issue, just means krita is really weird

it works with olive *perfectly* even when compositing other images, ffmpeg didn't properly tag it as associated alpha though, so I needed to manually do that

maybe fpnge could use smde for portability :)

cross platform intrinsics

https://github.com/simd-everywhere/simde

IIRC we never modify the color of invisible pixels in the premultiplied/associated case, since 1) it would be incorrect if invisible pixels are not black, and 2) it would be unneeded if the image was originally unassociated and converted to associated, since then invisible pixels automatically become black.

Some PNG optimizers do change the color of invisible pixels, often by making them repeat the color of the last visible pixel on each row (which is good for DEFLATE). This can introduce weird horizontal lines in the colors of invisible regions, which is not that great for VarDCT since those lines can be high-contrast high-frequency which is expensive for DCT encoding and can cause ringing artifacts that bleed into the visible parts. That's why changing the invisible pixels (turning them into a blurry mess that smoothly blends into the visible part) can be good for both compression (less entropy to encode) and quality (no artifacts bleeding into the visible part).

The "blurry mess" thing is good for VarDCT but for lossless probably something else would be better (not sure how to do it, but basically make the invisible pixels correspond to zero residuals — the tricky thing here is that we don't know the predictor until the encoding is done, so it's hard to do this as just a pre-processing step).

re: 1), afaict, it’s incorrect even then, since making them anything else than black (i.e. modifying them) would then make them visible

right, any change is incorrect in the associated case

I've seen some formats used by games where fully transparent pixels are not encoded at all and they are simply skipped over.

FLIF can do that — but it's a pretty bad idea for speed, introduces extra branching in the decoder

I suppose one trick we could apply to make invisible pixels "don't care, don't spend any bits" in modular mode, is to first permute the channels with RCTs so Alpha comes first, and then make sure the MA tree has a context for the A=0 case, with the predictor set to the Zero predictor. Then you can make all invisible pixels black and they will be in a context that has only zero symbols so it gets a singleton histogram and uses zero bits per symbol.

^ this kind of thing is why I love the expressivity of Modular — you can replicate FLIF's "skip invisible pixels" concept just by using modular transforms and MA trees

That sounds like a good idea. Also black pixels look better than random mess when viewed with alpha disabled.

In the case of the game, skipping over the transparent parts actually increased the rendering speed as only the non-transparent pixels had to be drawn on the screen.

I've noticed a regression in lossless jpeg transcoding. The same jpeg files result in slightly bigger jxl files. I'm not sure when the change happened. Any idea what caused that?

it's nice that they aren't modified for sure. I ill for sure look into JXL for replacing *some* parts where I would use EXR

I believe in 0.10, it tends to produce very slightly larger files than 0.9

0.8 is the smallest

Often when the encoder gets tuned, quality/bpp improves but also bpp gets a little bit higher for the same settings.

I don't know what settings I could try for lossless jpeg transcoding, there's only the effort which seems to be limited to 10.

E

yeah `-E 3` or some other `-E xxx`

Interesting. I thought E was only for modular.

Hmm -E has no effect on lossless jpeg transcode

oh

on older versions there was a difference, but not on all images

By tinkering with the source jpeg files I noticed the size of the jbrd box can be influenced. If the only thing to care about is to preserve the visual data and being able to revert to jpeg format, I figured out how to minimize the size of jbrd. 1) use Baseline jpeg with optimized Huffman tables. Either Progressive jpeg or "unoptimized" Huffman would increase the size of jbrd. 2) remove the JFIF header. As cjpegli does not write JFIF header at all, I suppose bare jpegs should be just fine.

re > 2) Some (ancient?) apps treat such jpegs as corrupt

The jpeg to JXL conversion is almost a fixed 20% reduction, or at least was, so it's always been advised to optimise the joegs first before transcoding for maximum savings

Progressive jpegs result in slightly larger jxls than baseline

iirc the actual JPEG data gets compressed the same way no matter the metadata or whether or not it's progressive, it's just the reconstruction data that's used to bring back the original JPEG that changes

I believe somebody explained this, but I forgot both who it was and explanation 😔

How many files have you tested where this is the case?

Lot of. Actually I wrote a script that produces 3 jpeg variants, compresses it, and leaves smallest. And the result was: optimized and non-optimized baseline produces the same jxl, progressive - a bit larger. Probably there were exclusions, but in general it was so

From what I found, the difference between baseline and progressive jpegs was only in the jbrd size.

Adding a new JFIF marker where it's missing is easy enough to do.

Maybe I should do that test again..

Optimizing jpegs before transcoding to jxl is deffinitely a good idea. This can fix slightly broken files that wouldn't transcode directly. The another topic is optimizing metadata. EXIF is a mess. It's often bloated with data most users don't need. The only metadata I care about is: 1) a timestamp in UTC format 2) a comment in UTF-8 format 3) geographic coordinates The rest can be discarded. Also the jpeg thumbnail can go away as it can be always recreated and jpeg thumbnails don't work inside jxl anyway.

We are all different. I don't care about comments and coordinates, but need information about camera. So I use exiftool with -photoshop:all= -xmp:all= -Software=