JPEG XL

If you care about the camera, good for you. I don't 😉

Anyway. does jxl have equivalent to JPEG comments? It seems it just gets buried inside jbrd.

Comments in PNG are simply discarded by cjxl.

why I don't why so many formats added comments to their specs like, why the fuck would anyone want a comment in a GZIP file ? And even more useless because there's no support at all for stuffs like that

It's certainly useful being able to store text information inside media files. Unfortunately different formats use different methods, so it's difficult to manage.

At least in PNG having just a text box is useful as stated above, since it can store any range of data, but the different formats of text in different image formats means they're rarely compatible apart from default EXIF and maybe XMP

I think a format like XMP could be used to store all kinds of metadata, keeping it tidy and human readable, and optionally compressed inside the file.

That's what I tried to tell the owner of a Github repository, but they pointed out that Discord removes the chunk even on a PNG so they're sticking to a custom text type

Everything could be translated to XMP during conversion to JXL.

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

For JPEG there's at least jbrd, where cjxl can dump everything that doesn't fit elsewhere.

Maybe it would be good to have a tool that takes all the metadata stuff from a PNG, which can be in specific chunks or encoded in various ways in text chunks, normalizes it, and turns it into one single XMP blob.

Maybe reversible with the same tool, PNG input and XMP compatible output (JXL), or formatted XMP (JXL) input to PNG for text chunk output. Then it's all fully lossless still

There should be a way to reconstruct a JPEG from a JXL that's missing JBRD but otherwise compatible

Yes, in principle that should be easy, but there's no code path in libjxl atm to do that

Actually yeah, all png text chunks already need to have a type assigned, be it custom or predefined, so that could be directly converted to an XMP entry, with others for any more unrecognised/unhandled chunks

This metadata conversion tool should be able to transcribe most ancillary chunks to XMP, although some of them couldn't be converted back. For example the original palette. We were already discussing it would be useful to have an option to keep information about the original palette and XMP could be the right place for it.

is it normal that adding `--brotli_effort=11` to `cjxl -e 11 -d 0` gives me a smaller output ?

It would have make sense (to me) for -e 11 to try it [⠀](https://cdn.discordapp.com/emojis/654081052108652544.webp?size=48&quality=lossless&name=av1_Hmmm)

Actually, why isn't brotli effort connected to JXL effort at all?

i dont think a correlation is needed for all efforts, but maybe yeah, it would be useful to enable `--brotli_effort=11` for like `-e 10-11`

could make sense to make the default for brotli effort depend on the jxl effort — it only makes a difference if there is metadata or jbrd stuff to compress, but still...

it wouldn't make much sense for all efforts, most metadata is not that big and there is no noticeable difference in speed but maybe something like brotli 6 for `-e 1-2`, brotli 9 for`-e 3-8`, brotli 11 for `-e 8-11`

Yeah, especially for e1 a lower brotli effort might be useful, and for jpeg transcoding going from brotli 10 to 11 might make a fair amount of difference

interesting <:FeelsReadingMan:808827102278451241> https://github.com/libjxl/libjxl/pull/3569

The file I was talking about is the one from the issue where they can't encodeit with cjpegli (100x100 pure black)

it has **no** metadata

JXL e11 size is 19 bytes with brotli_effort=11, 17 bytes

```17 black.jxl 30 black.webp 76 black.png 193 black.jpg```

<:Thonk:805904896879493180> https://www.w3.org/TR/png-3/#11IHDR

Yes HDR is a significant part added to the spec

afaik, this is unrelated, it’s just “ihdr” as in “image header”

those actually relevant to HDR are https://www.w3.org/TR/png-3/#cICP-chunk and https://www.w3.org/TR/png-3/#mDCv-chunk

IHDR is indeed image header

`cICP`, `mDVc` and `cLLi` are the relevant chunks for HDR content

yeah, in general, it seems like a pretty standard png <:FeelsReadingMan:808827102278451241> ``` chunk IHDR at offset 0x0000c, length 13 100 x 100 image, 1-bit grayscale, non-interlaced chunk IDAT at offset 0x00025, length 19 zlib: deflated, 32K window, maximum compression row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (100 out of 100) chunk IEND at offset 0x00044, length 0 No errors detected in black.its_a_png (3 chunks, 94.2% compression).```

Oh I was thinking of HDR as it was mentioned frequently today

How's jpegli handle greyscale PNG input? Might be that

it's greyscale, yea

1bit

your e11 is broken

I'm just refering to the sizes

I still don't undertsand what you mean

oh wait

ahhhhhh I found out it is when recompressing that JXL https://cdn.discordapp.com/attachments/673202643916816384/1238391325942878208/black.jxl (24bytes) that I get 19 bytes while if take the same command with PNG input, it goes down to 17 bytes

19B: ```$ jxlinfo black\ \(1\).jxl JPEG XL image, 100x100, (possibly) lossless, 1-bit RGB Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Perceptual```17B:```$ jxlinfo out.jxl JPEG XL image, 100x100, (possibly) lossless, 1-bit Grayscale Color space: Grayscale, D65, sRGB transfer function, rendering intent: Relative```

now stop touching e11. just use d0e10P0I100g3 directly

```$ cjxl -d 0 -e 10 -P 0 -I 100 -g 3 --brotli_effort=11 black\ \(1\).jxl out.jxl JPEG XL encoder v0.10.2 e1489592 [AVX2,SSE4,SSE2] Encoding [Modular, lossless, effort: 10] Compressed to 21 bytes (0.017 bpp). 100 x 100, 1.265 MP/s [1.27, 1.27], , 1 reps, 16 threads.```<:KekDog:805390049033191445>```JPEG XL image, 100x100, (possibly) lossless, 1-bit RGB Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Perceptual```

that's the jxl input

jxl is bad

with PNG input, still 17B

yes, that's what e11 would use

note to myself: never use JXL as input [⠀](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

It was added for convenience, don't think JXL input has actually been tested much

why is JXL input bad?

probably some quick checks and optimizations are not implemented as it works for png

like it was with fjxl for png, but not for ppm (before some changes)

Well it just seems like it's using RGB instead of Greyscale

that's just a bug, not a fundamental flaw

Has someone compared 10bit+ quality/size for jpegli and JXL?

How do you tell cjpegli to encode in 10 bit? I don't see the option.

use high bit depth input

It always encodes in high precision, but writes nominally 8-bit jpeg files.

decoding to a high-bit-depth PNG, however, requires `djpegli --bitdepth=16`

I've tried to encode a 16 bit PNG but the resulting jpeg looks and behaves just like an ordinary jpeg.

So there's no method to output 10bits+ jpeg with jpegli, right? I've checked that it uses `jpeg_compress_struct` for parameters setting like libjpeg, there's no output bit per sample in it.

8-bit jpeg is internally using 12-bit DCT coefficients, which in smooth regions is enough for 11 bit sample precision

Thanks for you answer.

Ah that makes sesns. I've noticed, that ordinary jpegs may decode to values between the original 8 bit.

So there could be more than 256 values in the decoded output.

I don't know if jpeg92 standard has this inside it? Does jpeg92 use 8bit DCT coefficients?

It seems that jpeg always used 12 bit DCT. I'm trying some ancient jpeg viewers, that don't even support progressive yet. Non-progressive jpeg encoded using cjpegli from 16 bit PNG works just fine.

Yeah, it's completely within spec, which a lot of people don't belive and think it's like gain maps or an entire new format

So traditional decoders just truncate the values to 8 bits.

Jpegli uses floats internally, other decoders use 8bit int so decimal precision is lost

Old jxl files transcoded from jpeg have container structure jbrd-jxlc. Newer files have structure jxlp-jbrd-jxlp. Is something wrong with the older structure?

Might be making them progressive by default now? > The codestream can optionally be split into multiple `jxlp` boxes; > conceptually, this is equivalent to a single `jxlc` box that contains the > concatenation of all partial codestream boxes. > This makes it possible to create a file that starts with > the data needed for a progressive preview of the image, followed by > metadata, followed by the remaining image data.

The first jxlp is very small, the second jxlp contains the rest of the jxl data.

It seems the reason was just to have the jxl header and jbrd box close to the beginning of the file. The question is, is there any disadvantage of the older arrangement or should I convert everything to the new arrangement?

But how to feed 16bit data to jpegli? The `jpegli_write_scanlines` only works for 8bit input.

<@532010383041363969> is this prs ready to merge? or still need some changes i want to test something but with all lossy improvements <https://github.com/libjxl/libjxl/pull/3563> <https://github.com/libjxl/libjxl/pull/3536>

yes, I'm working towards it right now

I will change other heuristics later this week, possibly by tomorrow

the current generation loss is pretty bad -- it looks like I have broken it in a complex way in several 'improvements' for difficult images

I don't yet know what is the best way to fix -- it looks like I don't understand the issue yet as what happens right now shouldn't happen by pure logic

but if I remove the heuristics that I added, then everything is fine (except the difficult images get quite a bit worse)

both 3536 and 3563 are on they way in now (approved, possibly merged in a few hours)

thanks 👍

Meanwhile I've been tweaking lossy modular a bit, also made some small improvements to its generation loss: https://github.com/libjxl/libjxl/pull/3575

do you want to remove the out-commented printf statements before a review?

right

I notice lossy modular (with squeeze disabled) preserves edges of line art perfectly but changes the colors radically

it will improve memory management? https://github.com/libjxl/libjxl/pull/3582

lossy modular without squeeze has not been tweaked yet at all — it just does precision reduction in XYB, and probably does it too much for X/B then

maybe at least do some auto bruteforce tuning based on metrics, not the best, but at least something and anyway lossy modular has only some specific use

default lossy modular is with squeeze, that's the only way to get it somewhat competitive with vardct

but yes, makes sense to get the non-squeezed lossy modular a bit better — it's used when doing patches so there's that...

now I have merged all quality changing PRs that I was planning to

hooray

To Be Tested 🙂

still not merged <https://github.com/libjxl/libjxl/pull/3575> <https://github.com/libjxl/libjxl/pull/3563>

Those are Jon's PRs ;P

<@794205442175402004> but maybe it needs retuning for the new quality changes? <https://github.com/libjxl/libjxl/pull/3563>

The changes in that PR are orthogonal to the changes Jyrki made — my PR is turning off Gaborish by default at d <= 0.5, Jyrki's change makes Gaborish behave better than before at all distances. The best cutoff point of switching from Gaborish enabled to disabled might change, but is a bit arbitrary anyway. In any case Gaborish (like any filter) will introduce some additional generation loss, and in any case it is less useful/needed at very low distances, so I think my PR can stay the way it is.

yeah, I meant after these quality changes the gaborish cutoff point can be shifted to higher quality

Maybe, but to me it's more about the use case — for the final encode for e.g. web delivery, generation loss is not as important as if you would want to use jxl in an authoring workflow (and lossless is not an option due to speed / disk io / limited storage). I think it's safe to assume that for web delivery, you'll typically want d >= 1 (probably usually d2 up to d3), while for authoring workflows you'll want to use a (much) higher quality. Distance 0.5 seems a reasonable cutoff point in that sense: that's about the lowest quality that can still be used in an authoring workflow.

In any case this is just the default for gaborish, of course applications are free to enable or disable gaborish at any quality setting.

also for such high qualities it would be interesting to compare different efforts, maybe some introduce more distortion or maybe faster ones would be better, even if gaborish is disabled

it seems quite likely that lower effort encodes will be better to avoid generation loss — using fewer coding tools generally means less different ways to accumulate artifacts 🙂

then maybe tuning some other parameters also makes sense for very high quality, some will probably not be somehow worse for a single generation or maybe even give some improvements

I did think about having the gaborish strength tied to distance, so as the distance increases so does the strength, probably with the cutoff similar to Jon's PR but then starting gradually instead of a hard on/off

yes, that makes sense, though if the strength is close to zero, it's probably best to skip it and save the encode/decode time of doing those convolutions

probably slightly worse at very large distances

at very large distances, gaborish can make the difference between having a very minor headache AND cholera, and only having cholera without the minor headache

those who use large distances are mostly looking for a way for a video codec to win -- not to have utility for image compression

We don't have good metrics to assess very low quality images. The usual metrics start to break down at some point. Banding is one of the main problems at very low quality, but most metrics are not so great at estimating the visual impact of banding in slow gradients.

Since I can't yet build the latest nightly tools with skcms, this raised a question: how much difference is there in the resulting images between building with skcms and without it, just with lcms2? Or are there any differences at all?

lcms2 is more feature-complete (e.g. can convert to LUT-based profiles), skcms is faster

within their feature overlap, there shouldn’t be significant differences in the results

(if there are, I would tend to trust lcms2’s results more, as the difference might then stem from something skcms doesn’t support)

basically, you’re not missing out, if that’s what you were worried about

Ok, thanks, that's exactly what I'm worried about.

you could possibly use spng

instead of lodepng

well I just hope noob questions are allowed... lol I was converting some Images just to save storage space and discovered that some images throw an error. It seems that all of those who do are coming from WhatsApp. So I tested it with one photo someone sent me, when I save it to my Photos App and then AirDrop it, it converts just fine, but when airdrop it from the share sheet within WhatsApp it throws the error. "Error while decoding the JPEG image. It may be corrupt (e.g. truncated) or of an unsupported type (e.g. CMYK). EncodeImageJXL() failed." I don't get it. What is WhatsApp doing to those poor images?

are there any samples you can provide?

ofc

hmm, i'm not seeing anything super strange about magick, and disabling lossless_jpeg seems to encode the image fine. This is probably an issue with libjxl itself and is probably worth reporting on the git

I didn't try lossy tbh.

here is the diff between the two that magick reports, nothing too major, but i've not looked at libjxl's code base so Im not sure if there is an aha here or not

Thanks for checking it. btw sorry you had to witness these pics, but rather weird food pics than weird feet pics 🤷‍♂️😅 Alright I just checked further. (All sent over WhatsApp, all standard settings -> lossless) From iOS to iOS I have no problem whatsoever. From Android to iOS the Problem persists. (my initial photo I shared was taken on Android as well and sent to iOS) I can not check Android to Android / iOS to Android. Somehow WhatsApp is crippling these imags but how come it works for iOS to iOS?

where it's complaining: ```lib/jxl/jpeg/enc_jpeg_data_reader.cc:229: JXL_FAILURE: DHT marker: no Huffman table found lib/jxl/jpeg/enc_jpeg_data.cc:388: JXL_FAILURE: Error reading JPEG lib/jxl/encode.cc:2034: Error during decode of input JPEG```

might they use arithmetic encoding?

ah, there’s the zip, I can check

(actually, I don’t know how to check)

if you can't open it with `ffplay` then it's arithmetic <:KekDog:805390049033191445>

so no, in this case it's not arithmetic

even `ffmpeg-full-git` with 6+ GB of deps doesn't support JPG arithmetic but even Discord does for some werid reasons

I just use [ExifTool](https://exiftool.org/) to check

Might be fixed by this, like a few other issues https://github.com/libjxl/libjxl/pull/3503

After jpegtran it transcodes just fine: ``` > exiftool -encodingprocess PHOTO-2024-05-18-19-30-05.jpg Encoding Process : Progressive DCT, Huffman coding > cjxl PHOTO-2024-05-18-19-30-05.jpg PHOTO-2024-05-18-19-30-05.jxl JPEG XL encoder v0.10.2 e148959 [AVX2] Note: Implicit-default for JPEG is lossless-transcoding. To silence this message, set --lossless_jpeg=(1|0). Encoding [JPEG, lossless transcode, effort: 7] Error while decoding the JPEG image. It may be corrupt (e.g. truncated) or of an unsupported type (e.g. CMYK). EncodeImageJXL() failed. > jpegtran -optimize -outfile PHOTO-2024-05-18-19-30-05_tran.jpg PHOTO-2024-05-18-19-30-05.jpg > cjxl PHOTO-2024-05-18-19-30-05_tran.jpg PHOTO-2024-05-18-19-30-05.jxl JPEG XL encoder v0.10.2 e148959 [AVX2] Note: Implicit-default for JPEG is lossless-transcoding. To silence this message, set --lossless_jpeg=(1|0). Encoding [JPEG, lossless transcode, effort: 7] Compressed to 97600 bytes including container ```

I've also came across a jpeg which cjxl refuses to losslessly compress. No arithmetic coding, no metadata. no trailing data, everything looks just fine. I don't have information about the origin of the file unfortunately. jpegtran fixes the issue though.

I also have an issue with jpgs of one kind - panoramas produced by samsung phone 🤦‍♂️

They are opened ok with all viewing software, but cjxl refuses to consume them

Perhaps we could create a forum thread "jpegs that won't transcode" Anyway, here's `djpeg -d -v` output for my file.

> Perhaps we could create a forum thread "jpegs that won't transcode" Probably this should be a bug report on github with examples of such jpegs.

There's a similar forum thread for images, where Modular lossless encoding is inefficient.

Different code, but jpegli decodes it fine

Great picture. But even jpegtran couldn't fix it. <:SadCat:805389277247701002>

It's version from normal camera 😅

Well, cjxl communicates clearly the issue with this one

I did more tests on my file. `cjxl --allow_jpeg_reconstruction=0` failed `cjxl --lossless_jpeg=0` wokrs, but it's not lossless anymore. `djpegli` failed to decode the file, but can decode it after running it through `jpegtran`.

This file has a differnt issue. It contains lot of non-jpeg data at the end of the file, `jpettran` refuses to touch the file.

Yes, I know, that's why these jpegs are still jpegs, not jxls. But all viewers and PS open these files ok

Image viewers and editors just look at the jpeg data and ignore the rest of the file. The problem begins if a program is trying to process the entire file.

I see, your jpeg file has a video file appended to it. After splitting the file to two, the jpeg part still couldn't be losslessly transcoded to jxl. It's apparently missing the "end of image marker" but this can be fixed using jpegtran. So after moving the video to a separate file, the jpeg image can be transcoded to jxl. I don't know how one is supposed to watch the video while it's attached to jpeg. The separate video file can be watched using any video player.

So, it turns out cjpegli actually uses libjpeg-turbo for decode. jpegli doesn't like DHT length 2, same as libjxl.

why are there so many different jpeg decoders

(by 'doesn't like' it just refuses to decode. if you disable that check, both libjxl and jpegli decode fine)

Perhaps jpegli is not yet considered to be a reliable decoder. After all, djpegli can't decode my test file as is, but it can be decoded by libjepg without problems.

And my file doesn't have any funny marker ordering.

but you should integrate it into your own production software <:Thonk:805904896879493180> https://discord.com/channels/794206087879852103/794206170445119489/1240359173083107470

djpegli just fail here... `djpegli 1704206981.arralipskedsy_sandra_jpeg.jpg out.png Read 282576 compressed bytes. jpegli decoding failed`

so a question for the experts is why is that check there. because libjpeg-turbo doesn't care, nor does libjxl/jpegli really (at least on these concerned files)

Just curious, how did you find start of the video? Exiftools says Surround Shot Video : (Binary data 9492301 bytes, use -b option to extract), but file is a bit too large to scroll it and look for video start by eyes

djpeg complained about invalid marker, so I searched for it. Good to know Exiftool can extract the video, so it should be able to remove it from the jpeg file as well.

And perhaps put i back if desired.

Thank you

It says this tag is not writable, but maybe it can be done writable

This file arrangement is definitely application specific so these files are intended to be viewed using special software. Maybe it's difficult to recreate the arrangement so the special software accepts the file.

Exiftool refuses to read or write any custom tags/data, only telling you that it exists. You need to manually create a configuration file and then tell it a discription of the tag before it will let you do anything with it, even just copying

I'm not aware of such software, and I definitely do not need it. So I'll learn how to create config for exiftool to remove it, and then there will be no .jpg in my \photos 🙂 So thank you very much for this finding about embedded video

Could you please explain how exactly did you achieved this? Removing trailing data with exiftool removes this video part from file, but cjxl and jpegtran still refuse to read it

I simply sliced the file at the beginning of the video file. I will take a look what Exiftool does.

I used -trailer:all=

Exiftool seems to leave the video header inside the jpeg. jpegtran complains about `Invalid SOS parameters for sequential JPEG` but produces a fixed file.

Hmm, that is strange, my jpegtran just shows this error and writes nothing

What version of jpegtran are you using?

My command line is `jpegtran -copy all -optimize in.jpg out.jpg`

IrfanView can fix the file after Exiftool. Irfanview has lossless JPEG transformations based on jpegtran.

Efficient-Compression-Tool works as well.

I tried two: version 9f 14-Jan-2024 and version 9a 19-Jan-2014

No 😦

I t works after Exiftool removes the trailer.

Yes, I mean the same. This file is after exiftool -trailer:all=

Interesting, it worked for me.

Try ECT, it uses jpegtran from Mozilla.

Ah so this one doesn't work.

F:\temp\photo>ect 20180313_090517-t.jpg 20180313_090517-t.jpg: Invalid SOS parameters for sequential JPEG 20180313_090517-t.jpg: Unsupported marker type 0x76

Exiftool doesn't remove everything, so there are some data left that sometimes upset jpegtran. I think this is something to bugreport at Exiftool.

I'm not familiar with jpeg internals, so I'd be happy if someone who is explained a bit more what is that SOS parameter, and is it possible to fix it at all

SOS parameter is not the problem, jpegtran will fix that. The problem is the unsupported marker. jpegtran is trying to interpret random data as jpeg data.

If you can use hex editor, you can manually delete the rest. Search for Motion_Panorama text and delete it and everything that follows.

Finally it worked! Thank you!

Small python script, and all these panos are jxls now <:Hypers:808826266060193874>

hello

is the 1.0 version of libjxl planned ?

planned as in: we know what we still want to get done before releasing it (basically https://github.com/libjxl/libjxl/labels/v1.0) not planned in the sense of having a deadline date for the 1.0 release

before Christmas (but we don’t know which year)

like perl6

You know what would be a killer feature? If lossy transcoding of jpeg input never bloated the file size by decoding to pixels.

Like jpegdropscan

So by default it should never increase the filesize when doing lossy. That would be a killer feature and great behavior

https://github.com/MegaByte/jpegultrascan

I see it was Jyrki's suggestion to create a recompressor that uses butteraugli to determine what to drop

https://encode.su/threads/2489-jpegultrascan-an-exhaustive-JPEG-scan-optimizer?s=5eab706bdd6e826364ce7c0769b6952a&p=47959&viewfull=1#post47959

<@794205442175402004> thank you

Speaking of bloating the filesize, it would be cool if the tools printed a warning or confirmation when producing a file larger than the input size. As well as a way for the library to detect when an image would be smaller in lossless mode instead of vardct

https://github.com/libjxl/libjxl/issues/3512 I would just like to confirm, I just ran a test on my iphone, which renders xyb jpegs incorrectly, but after writing the app14 marker, my iphone renders the image correctly no problem in all apps

According to libjpeg documentation, app0 marker should be written for grayscale and ycbcr images only, and app14 for other color spaces.

So current jpegli behavior is writing the wrong header file, and that's the main reason behind the rendering issues. Otherwise they would be supported perfectly fine.

it's not wrong, quite the opposite, it's fully compliant with the open standard, and app14 is some proprietary metadata from adobe, just for some reason app14 has better compatibility (because older? or because images edited in adobe sw are pretty common?)

but at least having an option for a different marker would be nice, because it's already supported in libjpeg* and other libs

According to libjpeg documentation: ``` boolean write_JFIF_header If TRUE, a JFIF APP0 marker is emitted. jpeg_set_defaults() and jpeg_set_colorspace() set this TRUE if a JFIF-legal JPEG color space (ie, YCbCr or grayscale) is selected, otherwise FALSE. ```

``` boolean write_Adobe_marker 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. ```

So, it looks like jpegli is not fully compliant since XYB JPEG is an RGB JPEG, which is not a JFIF-legal color space and therefore, according to libjpeg's own documentation should be handled with an app14 marker instead

I'm not familiar with the data structure but the libjpeg api automatically writes the app14 marker by default for RGB JPEGs so it can't be that obscure or proprietary, any more than RGB JPEG is at least.

seems like jpegli requires colour management through iccv4 for xyb, but if it works with app14 then that's also another possible solution though I'm not sure how correct it would be and how properly displaying colors

More relevant quotes: ``` By default, the IJG compression library will write a JFIF APP0 marker if the selected JPEG colorspace is grayscale or YCbCr, or an Adobe APP14 marker if the selected colorspace is RGB, CMYK, or YCCK. You can disable this, but we don't recommend it. The decompression library will recognize JFIF and Adobe markers and will set the JPEG colorspace properly when one is found. ... If you override the default APP0 or APP14 processors, it is up to you to recognize JFIF and Adobe markers if you want colorspace recognition to occur properly. We recommend copying and extending the default processors if you want to do that. (A better idea is to save these marker types for later examination by calling jpeg_save_markers(); that method doesn't interfere with the library's own processing of these markers.) ```

Well, that's a separate issue

It's an RGB JPEG with a color profile.

That's a pretty normal and common thing

That's all that it is

But RGB JPEGs need to have an APP14 marker

Then the color profile will be properly interpreted by a lot more software, such as my iphone for example.

Right now I just did a test with my iphone. The colors are totally whacky when displaying the output of cjpegli. But, after fixing it with jpegultrascan, which adds the missing app14 marker, my iphone is able to display it perfectly fine

https://cdn.discordapp.com/attachments/794206087879852106/1235735007377490051/image0.jpg

This is how the iphone reacts to the missing app14 marker

hmm, yeah, I checked and without iccv4 it still doesn't work, so it only fixes apps who basically don't follow the standard and use some custom adobe marker

so it's basically breaking the standard and keep writing the wrong non-standard marker for apps that don't have the proper support

Hmm, really... Because what I'm reading from the libjpeg sources, an RGB JPEG is not JFIF and should not have an app0 JFIF marker, only an app14 adobe marker.

For maximum compatibility there should be no app0 marker

jpegultrascan only adds an app14 marker but doesn't remove the app0 marker, unfortunately.

But even that is enough to fix the rendering problems with Apple software.

Also the exact data structure of the app0 and app14 markers are in the libjpeg source code

https://github.com/libjpeg-turbo/libjpeg-turbo/blob/main/jcmarker.c

They're both only a few bytes and very simple.

Hmm, minor correction. There is no app0 JFIF marker in cjpegli output. But there is app1 exif marker

So there is no need to remove the app0 marker since it's not there

https://www.itu.int/rec/T-REC-T.872-201206-I/en Section 6.1: > Images encoded with three components are assumed to be RGB data encoded as YCbCr unless the image > contains an APP 14 marker segment as specified in 6.5.3, in which case the colour encoding is considered > either RGB or YCbCr according to the application data of the APP14 marker segment. The relationship > between RGB and YCbCr is defined as specified in Rec. ITU-T T.871 | ISO/IEC 10918-5.

In other words, Apple is in compliance by assuming that 3-channel JPEG without an APP14 segment is YCbCr

the app14 segment is required, according to this. In order to specify that there was no color transform applied.

<:Thonk:805904896879493180> https://exiftool.org/TagNames/JPEG.html

https://exiftool.org/TagNames/JPEG.html#Adobe

So basically... You're supposed to assume all 3-channel JPEG, contains RGB data with a YCbCr color transform applied... unless there's an APP14 marker.

So Apple mangling the colors is the correct behavior from Apple correctly assuming an unmarked 3-channel JPEG is YCbCr-encoded

Come to think of it, how do some apps know not to apply the ycbcr transform? Something in the app1 or app2 markers?

could your sample with and without APP14 pls ?

Do you want me to upload an example image before and after adding the app14 marker?

hey uh there's an issue with jpegli (actually multiple).. the default for jpegli is to output YUV as 4:4:4 and for XYB to output as 4:2:0 at all quality levels all the time always unless a chroma subsampling value is manually defined and this is a problem because JPEG XL can only transcode XYB JPEGs that are 4:4:4

another issue is for XYB JPEGs the colors are way different between the default 4:2:0 and the manually defined 4:2:0

pretty strange behavior overall that doesn't really make much sense

if I where to file an issue on GitHub should these be separate or in the same issue post?

yep please

oh wait

Unfortunately I don't know of any software that can reliably embed the app14 marker. jpegultrascan only does it if it can make the image smaller :(

yeah that's what I was going to say lol

so you tested with another image in jpegultrascan and it did add an APP14 ? Nice <:FeelsReadingMan:808827102278451241>

Yes, when it manages to shrink the image

ok, I managed to shrink the image lol. It took a long time of optimizing

Behold, the difference.

On my iphone, one of them is a normal image... the other is blue.

Which one looks better?

Looks identical, Windows, FF. Also identical in IrfanView and FastStone

A lot of software displays them identical despite the missing app14 marker. But then, I wonder how it knows not to use ycbcr...

It's definitely not identical on iOS

According to the bug report it's also broken on macOS safari and Finder as well as Photoshop

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

Telegram desktop generates wrong preview from these links, but Telegram Android works correct. Also FF Android works correct. Photoshop opens both files correct

Is there any difference between the two?

No

Most software seems to behave the same with or without app14 then

Unless you're on Apple

Telegram desktop shows them like without color management (keep in mind that it is "AdobeRGB as sRGB", in reality it is much more 'acid')

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

it seems like the piece of code causing the default to be 4:2:0 is here: https://github.com/libjxl/libjxl/blob/45e688cb6df41203a29e9f9d8fa946f34ba171cd/lib/extras/enc/jpegli.cc#L457

yeah this should really be changed, especially since the current behavior causes JXL transcoding to fail

Yeah, pretty weird how the default for ycbcr is 4:4:4 but for xyb it's 4:2:0

Literally all anyone has to do is remove the exclamation mark in front of the check for XYB. Or replace it with something like `jpeg_settings.xyb || jpeg_settings.quality > 75` for example

Actually, it might be a good idea to move the `jpeg_settings.xyb` check, and override the chroma subsampling settings regardless of what the user chooses.

to prevent xyb from being used with chroma ss

nothing to do with dependencies. there's one jpeg decoder in ffmpeg and it's the builtin one

It's a little bit weird, I tried to get `jpegli-static.a` with the flag `-D JPEGXL_ENABLE_JPEGLI=ON`, but it didn't work. Only turning `JPEGXL_ENABLE_TOOLS` to `ON` can produce the jpegli static lib. Is it normal? (Building with 0.10.2)

thanks <3 perhaps we should add it to the github issue so other people can see the difference ?

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

should I add the above pics ?

Programs can identify RGB encoded jpegs without Adobe marker by looking at the tags of the channels. YcbCr has channels tagged as 1, 2 and 3, RGB has channels tagged as ASCII R, G and B.

But apparently inclusion of the Adobe tag improves reliability.

I couldn't find this convention documented anywhere, but it would have been nice to know.

Hmm... Up to you, if you think it would help. Best thing would be a patch or pull request...

If I was more used to edit other's code why not, but unfortunately it's not my case

So I'm seeing that libjxl has jni wrappers. I'm however having an issue. I'm not sure how to add libjxl into gradle.build to actually use the library in java via that JNI wrapper

The only description I could find is this from Java documentation. https://docs.oracle.com/javase/8/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html

Thanks, that's cool. Looks like it only uses the channel ID if no app0 or app14 markers are present. And it also assumes that non-subsampled 3-channel imagea are RGB.

Even though app14 is a vendor specific "Adobe" tag, it has become a standardized part of RGB JPEG

Since JFIF didn't support RGB

And it looks like nearly all jpeg decoders look for the app14 tag

And use it to determine how to display the resulting image

Doesn't sound intentional

I am not familiar with gradle but first place I would look is other software that implements jxl decoding in Java on android.

https://github.com/awxkee/jxl-coder

RGBA_8888, RGBA_F16, RGBA_1010102, RGB_565 Question what exactly do these translate in opengl usable terms?

nvm. What I need is RGBA_8888 just was confusing to parse.

Incase you want context. I'm a mod developer working on a mod where we are using jxl as a way to store the massive amount of textures we have into a smaller footprint so the mod in question can fit into the size limit of modrinth one of the two main options for posting minecraft mods onlien.

online

Already use jxlatte but is a bit sluggish so native option. Hence my question here.

I suppose the assumption is the last resort if neither of number or ASCII IDs match.

I'm not sure of the size requirements on Modrinth nor what the size of all your textures are however wouldn't doing a native option mean the jar/mod would have to contain multiple different compiles of libjxl causing the mod's size to bloat a bit? each compile would be around 4 or 2 MB which times the number of different platforms and architectures would assumedly add up and also make the mod less portable. I know there are some mods that get away with including native binaries like the Physics mod and older versions of that one mod that allows Lua programming (forgot it's name) so maybe from the portability angle it doesn't matter much for your use cases.

I do wanna note that the dev of Jxlatte is in this server however they have stated they don't have much free time to work on it

I need to sleep right now but I can give more detail on my situation once I wake up.

So I had various issues that made me wake up so Here I go. I'm one of the developers of the mod Generations which is a addon for the mod Cobblemon. Our biggest feature is is an instance rendering based renderer. The model loading process from what my boss and I can tell is texture loading.

https://github.com/GenerationsMod/RareCandy/blob/legacy/src/main/java/gg/generations/rarecandy/renderer/loading/Texture.java#L74

So there is a another issue with purely jxlatte. Opengl is is RGBA while bufferImages are stored as a RGB.

And yes what looks like an extra step of preprocessing is needed.

In the current method I posted the link to. I just double checked.

I should add context that Cobblemon is newer of the minecraft mod's the adds pokemon to minecraft. By itself, it uses blocky models. There are API hooks to add additional rendering options. One of Generations features is adding the ability to load fully meshed models. We package alot models with the mod and it gets alot very quickly. One of the solutions to keep things small was the adoption of jxl. ALso a bit of a implmentation detail when it comes to minecraft itself. Minecraft uses stbimage to load pngs. I'm effectively looking for what jxl's equivlent is. Hence the looking for JNI of libjxl or equivlent.

Preloading all thsoe models and textures can get a wee bit taxing...I also had to learn computer graphics better after the tax of getting system fully operational got tossed soley on me. ><

jxlatte looks pretty well written. It also supports all features except animation.

theoretically Java should be able to achieve the same speed as C

Just requires profiling and optimizing

O

I'm fearing that I'm just reaching the limit of speed for how we are doing things.

A more optimized version would be a direct RGBA.

well direct ByteBuffer. I agree thought jxlatte is quite nice. Just have an exact use case where its output is a tinge indirect.

Actually now that I'm thinking about it. Are there any other java programs that are trying to directly upload the image data of a jxl into the gpu?

Sounds like a novel use case

Can't your problem be solved by using RGBA jpegxl?

Encode the images as 4 channel rgba so they can be decoded as rgba

Encode them in the same format you want them decoded in

BufferedImages are ARGB? And last I checked jxlatte doesn't out direclty into raw byte buffer.

Sorry, I might have misunderstood the problem

Java recently got some SIMD features though, which would be crucial to optimize the conversion between pixel formats

Java 21 right?

Vector api

Or even the decoding process itself?

It can accelerate most data processing pipelines

Idk if jxlatte uses the simd api

But it could definitely accelerate jxl. The c++ library uses libhwy

<@1028567873007927297> I have begun to understand teh vector api. Its actually a bit fun.

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

I was hoping someone would eventually do this, I look forward to seeing your progress

Ah modded minecraft implemetnation?

usage

Yeah, JXL in a mod to lower sizes

I'm considering asking for Generations to be added to adoption page after we properly release since it seems its for any project implmenting jxl!

hey btw your issue on the jxlatte repo got a response if you haven't seen yet https://github.com/Traneptora/jxlatte/issues/31#issuecomment-2138440178

I wonder how this would compare, performance and compression wise, to some form of spline detection, or layer separation.

Ideally the encoder should be able to detect when vardct would inflate the file size and only use vardct when and where it performs well

I think a good start would be to make lossless mode the default unless specified otherwise, for all file types and not just gif and jpeg

it's pure Java, so no

you can use `Math.fma` for some things but if the system doesn't have fma instructions it runs horribly slowly

and there's no easy way to query that

unless you mean some super recent stuff

java.util.vector

Java 17

? `java.util.Vector` was in jdk 1.0

and it's a list element

I must have gotten wrong information then. I'm not a java developer but I know that they recently added a simd api to java

looks like it's jdk.incubator.vector

which will be removed

as it's a preview feature

possibly ported to main java

Technically the patches *are* layer separation

Yes, patches are technically layers... but I mean separating and detecting different types of signals rather than repeated signals

https://openjdk.org/jeps/417

https://docs.oracle.com/en/java/javase/17/docs/api/jdk.incubator.vector/jdk/incubator/vector/Vector.html

I guess this is the latest version of it? https://openjdk.org/jeps/460

https://github.com/hyvanmielenpelit/GnollHack/wiki/Starting-Guide-for-NetHack-Veterans The PNG image here is larger when using e=9 d=0 compared to using e=8

Specifically, the image of the gnoll holding the book.

e=2 is also larger than e=1 but idk if that's really a big deal compared to 8 and 9

e=4 is also bigger than e=3

I thought I would do some tests on this image since it's small cute and silly :)

Also in lossy mode, d=2 for example, the color of the book radically changes.

To a lesser extent so does her eyes.

But the change in the color of the book is easy to notice from a distance.

I just got the vector api to fully behave. Gonna plug it into the renderer I'm doing this for and try benchmarks. The inititial tests I did before look promising.

Pretty sure this is the same bug that's causing the factory leaves to lose their color.

Yeah, I didn't realize it's still in incubation after being added in 16 or 17 and we're already on Java 22

From what I read, it's waiting on project valhalla.

Look how dull that book became

I assume the ability to define SIMD operations for value types.

It changed color, from a golden amber to a washed out sepia parchment color

The whole entire book

Not just a few small pixels

`--container=0` does not force not using the container format?

Is there a way to throw away all extraneous data that isn't necessary for decoding the image data?

I see many issues with this image but none concerning the colors ... you are an amazing yellow issue spotter

Maybe it's my special talent of having defective M cones

I mean, I see it as well

the parts where it's especially noticeable are the eyes, rimlighting/light-highlights on hair and nose, and the title/text on the book

When you have defective M cones, there is a lot of overlap between the L and M cones, which corresponds to yellow.

So maybe that's why

I can see it in the eyes too, but I think the book is bigger and more obvious

There are plenty of artifacts I can see in the d2 image, in particular the fur and the shiny metal looks blurry. To me, these artifacts are worse than the color changes. If we would change the luma/chroma balance to improve the colors, it would make the blur worse...

It could possibly be a good idea though to have some encoder option to adjust the luma/chroma balance manually (and maybe also the DC/AC balance).

I think large objects becoming a different color is easier to spot from a distance than some pixels getting blurry. Although, again, I would prefer hf noise over blur

Obvious smears look more upsetting to human eyes, compared to "natural" looking noise

That's why I prefer the look of 0.8 for Tf2 screenshots, even at the expense of accurate colors. The sharper image was just more pleasing to the eyes

I mean, I have a soft spot for jpeg-like compression. I love the sharpness it retains despite the horrible mosquito noise.

That's why I just ended up with storing game screenshots as lossless

I really like the speed of lossless mode at e=3 and below

It's near instant

And decent compression too

I really think e=7 is too slow in lossless mode

Especially if you have a large image

Having near-instant compression that still beats other lossless formats, is awesome.

PNG is way too slow by comparison, when e=3 JXL is close to instant

Probably we should make an e4 that just tries e2 and e3 for every group and picks the best of the two.

does e2 sometimes do significantly better?

depending on e4’s, e3’s and e2’s current speeds, there might be an argument to be made that a new e3 should be that combination and never just “current e3”

Yes, it does happen that e3 is worse than e2 and that is something we should probably avoid.

<@853026420792360980> I need your help. I ultimately took your advice and did float directly. It works but everything seems dark and transparency outright isn't working. https://github.com/GenerationsMod/RareCandy/blob/f27daa6bc3ad1255a08ed28defae9926680b0724/src/main/java/gg/generations/rarecandy/renderer/loading/Texture.java#L112 This is how I'm parsing the raw float buffer like what you suggest in the issue I posted awhile ago. I'm not sure what I'm doing wrong.

Probably you're not turning it into sRGB first

jxlatte decodes an XYB image into linear

I think that could be fixed encoder side rather than decode, right? Assuming they want to keep it as light as possible

So how would I do that?

two ways, one is to call JXLInage.transform, the other is to draw the buffed image on an sRGB image

For the former what's recommended?

wdym?

Both. JXLImage.transform have parameters

it takes the colorspace as an argument. the int constants are in ColorFlags

for sRGB, you want BT709 primaries, D65 white point, and SRGB transfer

Hey <@853026420792360980> It took me a while to get back to this but I have a question. Does this way of doing things merge the channels together?

Eh I don't think I described it well. There is a rendering techinque involved layered masks that gamefreak uses in legends arceus, and the scarlet and violet game including its dlc that we replicate in Rare Candy.

Each channel of a certain texture being a channel used to color certain areas of a base texture.

For whatever reason when when I try the code I showed earlier today It goes pure white and when even I test the textures by themselves... Eh let me take screen shots. I rigged a frankenstein setup to see all four channels at once

First one. I ignore the texture quality. ALot of textures got corrupted durign the mass conversion to jxl my boss did a bit ago.

That's the original method involving copying the JXLatte derived BufferedImage data to a normal BufferedImage

I can't possibly help you debug without seeing your code, but let's move to <#1042307875898408960>

Alrighty.

It seems cjxl is going to be supporting PAM images with multiple extra channels. I wonder if it will be possible to encode CMYK images this way.

You can always encode cmyk images with jxl. Just not jpegs in lossless mode

And how do you serve pixels in CMYK format to cjxl?

In jxl, CMY is encoded in the RGB channels. So for CMYK you can make a PAM file with a header ``` TUPLTYPE RGB TUPLTYPE Black ``` and then you also need to add `-x icc_pathname=SOME_CMYK_PROFILE.ICC` since PAM cannot store ICC profiles and in jxl, an ICC profile is obligatory for CMYK images.

The sample values follow the (Adobe) convention that 0=full ink, maxval=no ink, which makes it make more sense to encode CMY as RGB (all-zeroes is still black, all-maxvals is still white).

This will be fixed via PR https://github.com/google/highway/pull/2231.

Huh, I didn't realise there was an even earlier attempt at the mixed encoding https://github.com/libjxl/libjxl/pull/466

is there a simple .so version libjxl for linux?

Looking into the jni for libjxl for my issues but I found a 2mb files for windows and then what looks like a bloated obtused solution fo rlinux...

Look on the github, download le latest release for Linux? Or compile it yourself

What does "simple" means?

like just an .so file.

you can make your own

the issue with distributing that is linking to the exact version of the other libraries in use

it's the same problem in windows

Yeah it's called the linux-static download on github releases

Wait no

That's not an .so I don't think

Since shared objects are not static

It's not THAT hard to compile... but it's still a lot more complicated to compile compared to any other codec library I have ever seen in my life

Most other codecs try to keep things as simple as possible for maximum uptake and adoption

I'm using Zig to compile (just telling cmake to use that instead of Clang) and with a ~50-line shell script I can now compile libjxl targeting Linux, OS X and Wasm.

I'm compiling everything static for my own tools, for easier deploy and with Wasm shared isn't really an option anyway.

Don't need Emscripten, just Zig

and zag

(don't know how zig can do wasm without LLVM and at this point I'm too afraid to ask)

Captain: Take off every 'zig'!!

Captain: You know what you doing.

It uses llvm but just packages it nicely, so I can compile C and C++ libraries and call them without much pain. My laptop is OS X and desktop is Linux, trying to keep projects working on both to easily switch when at home vs elsewhere.

Then I've got 50 lines of bindings written in Zig, and through those calling libjxl from TypeScript. The same interface works for Wasm (browsers) and native (under Node). Just doing everything the simplest laziest way possible while prototyping various things. It's a pretty nice tech stack, since the browser provides GPU access as well. Lots of options to try things.

I don't actually think it uses llvm

It does. Especially since I'm talking about compiling libjxl, written in C++, to Wasm. But that's kind of painful to figure out how to do with just cmake and clang, or at least I have no idea how to get it working.

zig cc/zig c++ always uses llvm (via clang) compiling zig code right now usually uses llvm, but they're working on making the non-llvm backends more viable

Oh, gotcha. I remember hearing something about them abandoning llvm

Is it possible to access the current encoding progress though C API?

I don't think so. I guess you could do chunked encoding and use that as a crude way to show progress. In general we're aiming at being fast enough to not require a progress bar. Though I guess for huge images and/or high-effort lossless encoding, it could make sense.

Signalling when a group has finished encoding (Bar full-frame heuristics) could be one way

yes, I suppose we could make some API for a callback that does something like that — not a priority though, imo. We can do that after 1.0 without breaking things...

Got reminded of this yet again, I'm very much assuming it's not as simple as removing the `=` so that 32 bit is valid https://github.com/libjxl/libjxl/issues/3511

Thanks for the reply. I'll try the chunk encoding method.

I miss the procedure or flag to compile the gdk pixbuf loader... could someone give me a clue? The readme found here (https://github.com/libjxl/libjxl/tree/main/plugins/gdk-pixbuf) contains information on how to install it, but not how to compile it

Not sure but I think it should automatically get compiled if the gdk-pixbuf headers are found, you probably have to install some -dev package for that...

ha ! this is a nice clue... I'll have a look

(found a `libgdk-pixbuf-2.0-dev`)

(didn't worked, try again with `libgdk-pixbuf2.0-dev`)

(didn't work either.... I'll have a look at the cmakelists)

``` cmake -DJPEGXL_ENABLE_PLUGINS=ON ```

oui ! I just found it 😄 `-DJPEGXL_ENABLE_PLUGINS=ON -DJPEGXL_ENABLE_PLUGIN_GDKPIXBUF=ON`

the `-DJPEGXL_ENABLE_PLUGIN_GDKPIXBUF` is not required ?

oh, I didn’t remember that we had separate options for individual plugins

it seems the individual options default to yes

didn't test without to be honest

perhaps I should have used the ./ci.sh script...

I confirm this is enough, I'll submit a modification of the documentation to help others

Congrats on the libjxl work to avoid assert. Lots of thanks and gratitude to all involved in giving the world such a cool codec. Maybe now it can be added to certain projects like paint.net without fear of it aborting and losing unsaved work...?

<@1028567873007927297> there's a special decode path for e1 along with the fast encode, I'd guess e2 is using some of that too depending on the image hence why e3 is a sudden slowdown for you

e3 compression is much faster than decompression funny enough

It should be about the same, no?

E1 compression is faster than decompression

Inherently, compression can be made faster than decompression because the encoder already knows the image so it can do things in parallel that the decoder inherently has to do sequentially.

That gives me the idea of a lookup table in the TOC so the decoder is aware, but naturally that would be a spec change and probably only on faster decoding settings due to size overhead

Hmm, doing another test, on a different computer, with only 1 thread, it is about the same speed

But I think when multiple threads are used, e3 compression is significantly faster than decompression

By the way, I see that jpegli was moved into a separate google/jpegli repo? This seems strange, since it would make sense for jpegli to be more integrated as part of libjxl, not less. Not only that, but it would also encourage adoption of libjxl.