JPEG XL

seems useful 😛

alright, I think I see how it works

I predict that the hardest part will be to rearrange the processing so that the splines are drawn at the right time and all that :p

updating the spline drawing itself doesn’t look hard

it almost approaches making JXL a vector format

(just with extremely basic vector primitives and very advanced bitmap capabilities)

spec says to first apply patches, then splines, then noise, and then do upsampling and color conversion

so technically it's not correct to do something else

I don't mind changing it to do splines after upsampling, that does seem better, but it requires a spec change (we can do it in the 2nd edition)

while we're at it: it might also make sense to have spline coords in the upsampled image, not in the downsampled image, but that's an even bigger spec change because it will totally change the way things look if splines + upsampling is used

(having the coords in the upsampled image allows more accurate splines, and would be needed if you want to do something like spline-based text with an upsampled photo background)

(then again, you can always put the spline on the next frame which is not downsampled, if you want to do that)

pretty sure it says to do noise *after* upsampling 😛

oh right

spec says first upsample, then patches, then splines, then noise, then color conversion

I was confused by this figure, which is not quite completely correct

there's no upsampling

are you sure it says upsample first?

what we do today is patches -> splines -> upsample -> noise

the upsampling from L.7 and L.8 is done first, then K.2 (patches), K.3 (splines), K.4 (noise), and then anything else from Annex L

ugh

so we're doing it wrong? or the spec is wrong? or I'm missing something?

oh wait

new_sample is the sample from the patch frame

old_sample is the sample from the current frame

so this says only that patch frames have to be upsampled before they are stored for future reference

that's kind of vague

"after decoding", what does that mean

I can't find anything specific in the spec saying when exactly the upsampling is supposed to be done

Figure 2 and the text around it doesn't mention upsampling specifically, it only mentions Annex L in general (which includes both upsampling and color transforms)

another thing to put on my list of "things to clarify/fix in the second edition of the spec"

anyway

Looks like we're getting ready for a v0.6 release!

these blended emojis are fun but why does it make such huge images, haha

where can I find libjxl documentation

docs/api.txt just says "generate html docs"

is it not something I can just find on a webserver somewhere?

I think in build/html if you build it yourself

a prebuilt version... IDK

asking 🙂

`file:///usr/share/doc/libjxl/index.html` giving me a blank page

well not blank, it's got doxygen boilerplate

but no content

is the library just not well documented?

I'm not sure where the doxygen stuff is

I mean

this

but in `/usr/include/libjxl/*.h` there's a few comments that should give some documentation

there's no docs

why documentation in comments in header files when we have doxygen

in theory doxygen should give you something

not sure what went wrong

I've never used the API before. what I'd like is a quickstart intro to showcase its use

ah

go to "Files"

nah, we don't have that yet unfortunately - try reading `examples/decode_oneshot.cc`

ah, that helps thanks

Where can I see this document?

Nowhere unless you're an ISO member, atm

Unfortunately

I hope for the second edition, we can make a public Committee Draft that will be identical in content to the published standard

Actually, isn't it possible for a company like Google to just pay an X/year fee for the spec to be available to everyone?

Nope, not afaik

I've always hated that the ISO charges for specs

Afaik ISO only has two options: - paywall - no paywall (but nobody knows how you can get that done for non-trivial specs)

Giving them money to just drop the paywall is not an option, afaik

Option 3: neither just give them away

the software itself is given away

why can't the spec

I am legally not allowed to do that because a condition for participating in ISO standardization is that you transfer copyright to ISO

Ah, so they own the copyright

but what I meant was, why can't *they* just give it a way

So while I literally wrote a big chunk of that spec (together with other jxl devs), we cannot just publish it

They get income from selling specs

It's a private company

They have two main sources of income

Selling specs, and membership fees

it's especially funny when I found that ISO apparently charges for the MPEG-4 AVC spec but the H.264 spec is available for free from the ITU's website.

I have to pay (or rather, Cloudinary pays for me) to be an ISO member

Yeah, they're cracking down on ITU too now though, lots of stuff that used to be available through ITU is getting removed there so ISO can sell it

you say "cracking down" but it's a division of the UN

Yeah

ISO is bullying ITU somehow

this sucks

Perhaps some pirate sites like LibGen may have ISO papers

https://docs.google.com/document/d/12Gmy2s4Nmkw6VDv2B6b5K1DLYhPrTUqSntrlmYzJpNw/edit?usp=drivesdk

lmao it's actually on libgen thank god

I am trying to get something going, but it might be a bit too much of a niche thing to get significant public attention

we need a site like this 😛 > www.iso.onion

speaking of ITU

is this goign to become ITU-T recommendtion T.900 or something

No, for some reason I don't quite understand, jxl is only an ISO/IEC project, not an ITU one

(the reason has something to do with Gary Sullivan from Microsoft not wanting jxl to be an ITU recommendation, but I don't really know why not)

for splines, it is unclear what the coordinates should be in. It's unspecified for the starting points in that doc, but in libjxl, starting points are floats and control points in QuantizedSpline are deltas as integers. Is there a reason why everything isn't just floats?

> Gary Sullivan > he became a founding co-chairman of the > Joint Video Experts Team (JVET) that developed the Versatile Video Coding (VVC) standard Something not quite right...🤔

<@!288069412857315328> I found a previous draft of the spec free on ISO's website

and by I found I mean JEEB found

<@604964375924834314> any idea what is correct? I think everything is encoded using ints, right?

The CD is the last draft ISO lets us publish, for DIS, FDIS and IS they don't allow it

That one is for part 2, the file format, not part 1, the core codestream

Unfortunately the CD versions are quite early drafts, not very correct compared to the final draft

Nice, seems like you have a few big names behind you there <:Hypers:808826266060193874>

It would be great if everything can be encoded as floats. It would also be good with upsampling

We cannot change the bitstream anymore

We could consider interpreting the int coords in the upsampled image though, as opposed to the downsampled one

Spec isn't super clear on when exactly to do upsampling, so it's not really set in stone yet what exactly to do when there are splines+upsampling

(which is an issue a second edition can clarify/fix)

speaking of that, what pixel formats does jxl support

The bitstream spec itself is formulated in terms of mathematical real numbers

You can in principle signal bitdepths up to 64-bit, iirc

(for lossless)

For lossy, it's all defined as infinite-precision arithmetic in the spec

And it is a matter of conformance how accurate you have to implement it

In practice though:

Libjxl does everything internally with standard single precision floats

So 8 exponent bits, 24 mantissa bits

(23 explicit mantissa bits, 1 implicit one, and a sign bit)

Modular mode does things with int32_t

The libjxl implementation supports lossless up to 24-bit uint, and lossless float of anything that fits into a single precision float

(which includes bfloat16, binary16, fp24 and binary32)

So we can do lossless compression of pfm

Or openEXR

For lossy, we have plenty of precision internally

As far as the API is concerned, we're trying to keep it simple and define only a few pixel formats

I think we have uint8, uint16, binary16 (half-float) and binary32 (float)

That's regarding the single sample representation

A pixel format is also about how multiple components are represented

The spec doesn't really say anything about that, since that's an implementation question

Libjxl internally uses planar representations atm, not interleaved

The API only has interleaved formats atm, afaik. RGB, RGBA, and I think we will likely add permutations like BGR and ignored-alpha (RGBX)

That is for the main color channels plus alpha

The remaining extra channels are handled in a planar way also in the API

The bitstream supports RGB, YCbCr (444, 422, 420 and 440), and CMYK

For lossy we usually use XYB (an absolute colorspace with nice perceptual properties), for lossless we have YCoCg-R and a bunch of other reversible color transforms, which can be switched up per group (tile)

There are a bunch of extra channels where the spec defines what they mean, like depth, temperature, the K of CMYK, selection masks, spot colors, and additional alpha channels.

And you can have custom extra channels that have a name and a type id that you can set to inform the decoder if it can safely just ignore that extra channel or not

Every extra channel can have its own bitdepth and dimension shift (1x, 2x, 4x or 8x downsampled)

So what pixel formats does jxl support? I think pretty much anything any image format has ever supported, and then some

If you plan on adding extra permutations then GBR planar is another one

I do think that exposing the planar format makes sense

but not doing anything with it other than telling you the order

it seems unecessary to me to store it internally as planar, export only an interface as packed, so callers then have to unpack it back from packed to planar

while I understand a lot of these things are for convience for the caller, there should be an option to request the more basic format in case someone has their own more optimized (or empty) way to handle it

thanks, this is pretty cool. I think only EXR has it beat since it supports 32-bit integer

also JPEG does not support "Oy Vey!"

my nickname for packed UYVY422

The internal representation is not just planar, it's also using padding on the left and right

(that's needed if you want to be able to do simd without lots of edge cases)

well isn't that just with a variable rowstride

Yep

in either case, packing a buffer only for it to be unpacked back to planar is kind of disappointing

I think if the internal buffer is planar it should at least be exposed as an option

to receive planar RGB

(although BGR makes more sense since the rest of the spec is little endian)

Yeah, for applications that want planar I suppose it would make sense to just get access to the internal representation

Though it's a bit more complicated than that: we don't always keep the full decoded buffer internally

I didn't mean necessarily a pointer reference to it

just, rather than pack it and return packed, just don't pack it. and then return it not packed.

Yes, makes sense

So, I know this might sound strange, but can butteraugli_main actually be made faster?

I assume it can, but I dunno

Is downscaling the input a viable strategy for lots of inputs, IE when processing thousands of frames from a video to get the average pooled butteraugli score?

Downscaling? Maybe, if you're interested in high distance... But of course d1 on a 1:2 image means something else than d1 on the 1:1 image

Depending on the use case, you maybe could do cropping (look only at the middle of each frame)

But likely there are also just speed optimizations possible or computationally good-enough approximations to just speed it up without having to make such compromises

I see. It is just that I prefer not using VMAF much for pure quality evaluation(rather than just compression efficiency) since the current VMAF models don't exactly take into account color performance, or in some of its metrics, not at all. Even metrics that are supposedly more "accurate" than VMAF like Fraunhofer's XPSNR aren't actually better in that regard, or are even worse. butteraugli in that regard works much better and is usually better psycho-visually speaking, especially in challenging scenarios(low luminance/low contrast scenes). The only problem is that the compute requirements in video for butteraugli are a lot higher than something like VMAF, which makes it tricky to use in large comparisons.

Something like dssim/ssimulacra might also work

(ms-ssim in Lab space)

Yeah, SSIMulacra is indeed a lot faster.

```[bluezakm@bluezakmpc ~]$ ssimulacra_main '/home/bluezakm/Pictures/Test/SonicGenerations 2020-05-28 17-21-31.ppm' '/home/bluezakm/Pictures/Test/SonicGenerations 2020-05-28 17-21-31_lul.ppm' 0.02659602 [bluezakm@bluezakmpc ~]$ time ssimulacra_main '/home/bluezakm/Pictures/Test/SonicGenerations 2020-05-28 17-21-31.ppm' '/home/bluezakm/Pictures/Test/SonicGenerations 2020-05-28 17-21-31_lul.ppm' 0.02659602 real 0m0.491s user 0m0.441s sys 0m0.049s [bluezakm@bluezakmpc ~]$ time butteraugli_main '/home/bluezakm/Pictures/Test/SonicGenerations 2020-05-28 17-21-31.ppm' '/home/bluezakm/Pictures/Test/SonicGenerations 2020-05-28 17-21-31_lul.ppm' 1.8718318939 3-norm: 0.685487 real 0m1.322s user 0m1.263s sys 0m0.102s ```

MTed DSSIM: ```time dssim '/home/bluezakm/Pictures/Test/SonicGenerations 2020-05-28 17-21-31.png' '/home/bluezakm/Pictures/Test/SonicGenerations 2020-05-28 17-21-31_lul.png' 0.00086633 /home/bluezakm/Pictures/Test/SonicGenerations 2020-05-28 17-21-31_lul.png real 0m0.313s user 0m1.212s sys 0m0.183s ```

Does anyone have any ideas to debug a `JXL_ENC_ERROR` result from `JxlEncoderAddImageFrame`? I am thinking I might have to compile with debug messages added in manually. Or maybe compiling with debug symbols and using gdb. It seems strange that there is no better error distinction than just returning `JXL_ENC_ERROR` for every error - it would be very beneficially to have something like printing to stderr, even if it had to be enabled at runtime.

We want to avoid bloating binary size of the library by having lots of error strings in it, but yes, it would be good to have at least a debug compile option where there are useful errors.

you can avoid stripping debug messages

say by compiling with CMAKE_BUILD_TYPE=relwithdebinfo

Thank You, that might make it viable to debug with gdb

it *should* also make JXL_API_ERROR print a message on the CLI

Thank You, that helped a lot. Turns out I forgot to account for the 3 channels when providing the buffer size, I just did `width * height * sizeof(float)`

Now it is kind of working XD

Heh time for <#805007255061790730>

good idea lol

What is going wrong here? Wrong buffer format?

not quite sure, it is quite strange

you can see very clearly in this image it seems to be splitting the image into fourths, overlaying those splits, then repeating the overlay three times

anyway I dont think its a libjxl bug

just a result of me not giving libjxl the right data

that's the usual kind of stuff you get when you get strides wrong, FWIW

Yes, maybe stride is not multiplied by 3?

idk if this is better or not

feel like its a slight improvement...

With lossless mode output now looks perfect!

Thanks for the advice

It was a stride issue

there are still some weird artifacts when encoding it in lossy though

what kind of quality setting is that?

14

oh

I just realised I forgot to invert the scale

because its as distance

so smaller should be higher quality

I see only 8x8 blocks in these lossy encodes... Maybe something else is wrong, too?

It's indeed quite blocky, what encode effort is this?

Is it distance 14? That is very lossy of course

Yes, it was distance 14

Now I have fixed it so that a quality setting of 14 will be transformed into a distance setting of 1.0

this is the output now and it looks great

are you trying to make a new heuristics

so the encoder isn't changed

no, just using libjxl from the github

ok

The nice thing about software libraries is that if there are encoder improvements in the future, all applications will get them

does darktable work with windows 7

should i install it

How are you passing the color profile?

As an ICC binary blob

Kind of strange that you don't get the error all the time, but only at effort 5

yeah, it works from 3-4 (on v0.5 so 1-2 are not available), but from 5 onwards it crashes

I will try building from latest main and see if that fixes it

switching to latest main fixed it 👍

I have one unanswered question regarding animated JXL files. I'd like to get number of total frames inside a JXL file. API let's me to decode till the end and to count them. Isn't it possible to get the number directly?

Not really

It's not something that is in the global header

There might be streaming use cases where an encoder doesn't know yet in advance how many frames will be encoded

There is a "frame index" box defined at the file format level, which maybe contains that info (not sure actually), it's meant to make seeking easier in large files

But I don't think it has been properly implemented yet, and in any case it's an optional box

It should be quite fast to skip through all the frames to get the count and timing info, without actually decoding the frames

(jxlinfo does that now, iirc)

can the quality go above 14? 🙂

Yes, 0-15, 15 would be reversed into distance of 0

I think for this use case, and assuming 0-15 is the scale it uses for all formats, it might make more sense to put d1 at 10 so there is more room for d0.5 etc

or maybe at 12, say - I'd want something between 1.0 and 0.0

and exposing d14 is likely not very useful tbh 😛

No, the 0-15 quality slider is specific to and controlled by the jxl format module. That’s a good idea though, I mean I could just increase the slider step range? At the moment it steps by 0.5, I could make it 0.1.

I think it would be better to match `-q` in cjxl (although I don't know if libjxl has it) ``` -q QUALITY, --quality=QUALITY Quality setting (is remapped to --distance). Range: -inf .. 100. 100 = mathematically lossless. Default for already-lossy input (JPEG/GIF). Positive quality values roughly match libjpeg quality.```

https://discord.com/channels/794206087879852103/803645746661425173/818396672081788958

I'd match what the Gimp plugin does :D

hi, i was wondering, what is the best way to convert a jxl file to a jpeg bytestream in memory?

Arbitrary jxl or recompressed-jpeg jxl?

Could somebody compile and share add-noise.exe?

*plz

i suppose arbitrary would be great, but i would like to know just recompressed primarily

I guess `djxl foo.jxl /tmp/bar.jpg` is the easiest way (assuming /tmp/ is a ramdisk)

You can also use the api to decode to memory

ah ok, interesting ty

What's wrong with this .gif? ... except that it's not an anime chibi girl. 😜

``` PS > cjxl patrick.gif JPEG XL encoder v0.7.0 233e5c8 [SSE4] Corrupt or CMYK JPEG. Failed to read image patrick.gif. ```

``` lib/extras/codec_gif.cc:147: JXL_FAILURE: GIF specifies out-of-bounds background color ```

also looks like we're saying "Corrupt or CMYK JPEG" a bit too easily - it's only supposed to say that when the file looks like a JPEG but is broken

So is it a .gif or .jpeg? I see `GIF89a` at the beginning of the file.

I used `magick` to convert it to .png, then passed it to `cjxl` since I need to add an exif comment anyway.

<@!111445179587624960>, <@!179701849576833024> or anybody?

it's a gif

a gif is also a corrupt jpeg, in a way 🙂

but that error is not helpful

I'm traveling :D also I don't really have a real windows build environment... I guess I could cook something up but not this week for sure

I will compile later, because I also need my main PC with MSYS2 and stuff

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

<:Hypers:808826266060193874>

thx

... but it is not what I thought it would be ... 😄

avx2

Hmm what avx2?

Addnoise.exe

out of curiosity, what did you think it would be?

I thought you could input a JXL with noise and apply the noise to another JXL. ^^

oh, so sort of like that elusive jxltran we so much want?

yes

> `typedef void *(*jpegxl_alloc_func)(void *opaque, size_t size)`

if you do not provide these, does it rely on libc's system malloc?

it doesn't quite say what the default is

also is there any practical difference to passing a memory manager struct with all entries set to NULL

yup

I *think* today that function call is 100% ignored

YUP! 😃 I wrote a bit about it in https://github.com/libjxl/libjxl/issues/477

what you describe reminds me a little of swfmill somehow

you could convert asset libraries back and forth between SWF and XML

progressive modular works great now 👍 (in firefox with updated libjxl)

v nice

Yep

So, waiting for Chrome

<@111445179587624960> what's that website?

https://stan-kondrat.github.io/progressive-image-viewer/

That's a cool tool

Indeed, thanks! 😃

Unless, perhaps, this is one of the last of the progressive features that have not yet been implemented: > Error: progressive lossless JPEG transcode is not yet implemented.

what exactly is progressive jpeg transcode?

transcoding progressive jpegs always worked for me

what does this mean

jpeg transcoded jxl?

It's about the output, not input. Currently transcoding JPEG results in just the "baseline progressiveness" that JXL offers

Yep, now MQIP and sequential block rendering works

True progressive at ~60%

Regular with center-first groups at ~60%

Regular modular with center-first groups

However, yes, if center-first or other custom group order is a bit more resource-intensive, it might be not a good idea to enable it by default for normal encoding, but perhaps for `--progressive` it may be useful, since this encoding option implies that progressive features are more likely to be used

how does one update firefox 3rd party stuff?

you import the patch

import this https://phabricator.services.mozilla.com/D126359

ok we rebuildin

very nice it works

though progressive modular is awful size wise

it's not progressive modular. that always worked i think

it was progressive loading of non progressive modular

so uhh just default `-m` right?

yeah

before it didnt load until the end but now it loads in blocks

Yes, except that MQIP will not work, something like an initial preview

why is progressive modular so inefficient :<

Also, `--centerfirst` may be interesting

does that make it the same size

if it does then i may have to re encode every single modular file i have

...

and that's going over 30000 files

It increases the size slightly, from a few to hundreds of bytes

tbh blocky without background from center kinda makes no sense to me idk

itd look weird

hmm yeah ur right

may aswell load from top down

playing with slider too much crashed the tab :--DDD

okay this encoded image crashes tab basically

(firefox nightly with D126359.diff and jxl-2c2fbc870b92617a6bcda90e3976e252c47c3fbf.patch applied)

For photos this is more often useful, given that loading each block separately will anyway rarely occur (only in very bad or slow connection) and usually the updates will be packs of groups

(it's lossy encode)

vardct

doesnt crash if you go real slowly

i dont notice any difference past 300kb

around 60k it p much always dies for me

nvm the difference is there but it's so tiny

hmm yeah it instantly crashes at 65

if it's not libjxl ill take a look at it uhhhh when im free

Is this a progressive image? At about ~60-65% it will be almost like a fully loaded image

encoded with `-s 8 -d 0.5 --progressive`

Then yep, in the beginning will be MQIP, then HQIP at 60-65% (almost full quality), maybe on HQIP something is broken

65 as in 65kb

before any image shows up

It's libjxl

🙏

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

That might fix it

i cant reproduce crashes with current djxl though

how does one get backtrace from firefox nightly

you build with debug on

it's a pain to do so

1

just under 1 hour for clobber build

it's not fast

iirc chromium compiles way slower than firefox

chromium takes about 10 hours to download

Interesting 🤔

JXL `-s 2` Nomacs

JXL `-s 9` Nomacs

Same in jxl-winthumb, but displaying correctly in djxl and browsers

Except for Firefox with the recent libjxl and with patches from <@!288069412857315328>

Weird

Could be a bug in the new codepath that tries to reduce memory cost by decoding modular straight to the output buffer

(in -e 2 it would apply, and in -e 9 probably not because the global Palette transform blocks it)

Compared the other speeds and it only happens at speeds 1-4 🤔 (5-9 fine)

Could be that palette is tried at e5 and up

It does look like YCoCg data being shown as RGB or something

Please file a bug

This is Not Good (tm)

How does decode_oneshot render it?

Seems to be ok (although I'm not sure if I'm using it correctly)

what happens if you use `-e 9 --palette 0`?

Same as just `-e 9`

interesting, so apparently it's not *just* palette

I'm sure Jon will be having loads of fun with it 😛

Also on photo images it happens even more often (it seems that always)

does it happen with v0.5?

But, on other types, here, the colors are fine

here - not

Hmm, if I find an old plugin, I'll try to compare versions

On an older version the colors are fine (but I don't know the exact version, something like 0.5 or older) 🤔

Whar about `-e 9 --palette 0 -X 0 -Y 0`?

(to disable all kinds of palette, you also need the -X 0 -Y 0)

I think it always happens when no palette is done.

When it's only doing RCT and no Squeeze or Palette, it skips the global modular image and directly copies decoded modular groups to the output buffer

No, nothing has changed

With -e 9 --palette 0 -X 0 -Y 0 it still looks OK?

Yep

`-s 2`

What about -s 2 -C 0 ?

And -s 9 with all the those options but also -C 1 ?

I need a way to reproduce but I don't have a patched firefox or nomacs/winthumb

Yep, so it's `-c 1/0` `-s 9 --palette 0 -X 0 -Y 0 -C 1`

`-s 2 -C 0`

I suspect something is going wrong when it moves a global RCT to the group level, somehow causing it to not be undone

yep, that was it

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

trying to use container + jpegmetadata on an image frame so as to be able to decode to a jpeg but looks like i can only decode to pixels this way?

How are you encoding/decoding?

<https://github.com/libjxl/libjxl/commit/fd06f61d0e49a28b8b0894e227994b40d2e446d0> > distance, lower = higher quality. Range: 0 .. 15. Also, it's not up to 20 now?

It is up to 25 no?

Or even 25

And also images with `--resampling` still do not work correctly, including in browsers and apps, it would require a lot of rewriting to fix and not so easy to find the cause? Because, given that it is now enabled by default (with higher -d) and also can be useful for encoding, this is quite a noticeable bug

Agreed

imo resampling stuff should internally upsample and only give downsampled size when relevant flag is passed which would be something in lines of "plz giv downsample i can resample myself", similar with how colorspaces are handled

(ive not dug into this so may be misunderstanding something)

what's the point of resampling

This way to achieve better quality with very high compression (although not for all types of content, mostly for photos) This is something more advanced than normal downsampling/upsampling, especially when there are compression artifacts

it probably actually is not even exposed to users right now. so above comment of mine is silly

This is a weapon for lowbpp encoding fans

Source

lowbpp JXL

Same size lowbpp JXL (+ `--resampling=2` and `photon_noise`)

what abt lowbpp JXL + photon_noise

to me it seems like the most of effect comes from photon_noise

though some things are really more detailed in resampled version

No, photon_noise cannot add details

yeah I see. though it looks closer to original still

than non-noise lowbpp JXL I mean

And for low bpp it is anyway impossible to achieve high accuracy of the image and the main goal is to reduce artifacts, save some details and create a more appealing image, in what AVIF and other video-based codecs are good, but JXL was not and this is also one of the ways to improve it

that with 0.6?

As far as I remember it has not worked for a long time, also in 0.5 and 0.7

I would like to see some examples how to read/write CMYK, CMYKA images via libjxl API. Is the API final/ready for CMYK or we can expect some changes?

bitstream-wise, the K is stored in an extrachannel of type kBlack

and the CMY just in the RGB

convention is that 0=max ink, so CMY behaves like RGB

so reading it should be a matter of getting the RGB (CMY) and the kBlack extrachannel, then possibly giving those 4 channels to lcms/skcms together with the ICC profile (which should be a CMYK profile in this case) so you can convert it to something displayable

it's all gonna be in the api right? As in output RGB.

the aim is to at some point have a high-level api that deals with color management too and that can provide RGB output also for CMYK files

the low-level api can only return the CMYK itself, since full color management is out of its scope

but with the decode API, what happens when the output format is 3 channels?

it will just give you the CMY only

in the low-level api (currently the only api), you'll have to explicitly check if there's a kBlack extrachannel and separately get it

or I guess you can ask 4-channel CMYK output too

for CMYKA you'll definitely need to fetch either A or K separately

I hope we can make a high-level api soon, it will make the task of "just show me the image" easier

oh and I'm guessing the higher level API, when it happens, would allow to request specific output formats like RGB, gray, etc?

atm even djxl gets it wrong, https://github.com/libjxl/libjxl/pull/237 fixes that but still needs to be merged

so right now CMYK isn't "supported"? I just don't want to worry about it

in Level 5 of jxl, CMYK/kBlack is not allowed

which is what we expect browsers to implement

oh epic

the bitstream supports it but atm it requires manually getting the kBlack and doing proper color management

is there any plan atm for the high-level api? i figured it's something i want to contribute to

not yet, but contributions are certainly welcome...

I suppose it can be developed as a rather thin library that depends on libjxl and some color management library, and just does something like decode/encode_oneshot (calling the low-level api to do the work) but also including color management (converting the RGB or CMYK output data to whatever RGB color space that gets requested by the application)

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

you can start commenting there 😄

nice 👍

interesting progressive load

(jpeg transcode)

Looks like chroma upsampling is not done when flushing? <@179701849576833024>

ugh

have I mentioned that I really really don't like chroma upsampling?

but no, I think something is more broken than that

what's the original image? is it a recompressed JPEG?

```$ exiftool 001.jpg ExifTool Version Number : 11.88 File Name : 001.jpg Directory : . File Size : 866 kB File Modification Date/Time : 2020:11:05 05:31:28-08:00 File Access Date/Time : 2021:09:30 12:42:27-07:00 File Inode Change Date/Time : 2021:09:30 12:42:26-07:00 File Permissions : rwxrwxrwx File Type : JPEG File Type Extension : jpg MIME Type : image/jpeg JFIF Version : 1.01 Resolution Unit : inches X Resolution : 96 Y Resolution : 96 Image Width : 2078 Image Height : 3040 Encoding Process : Baseline DCT, Huffman coding Bits Per Sample : 8 Color Components : 3 Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2) Image Size : 2078x3040 Megapixels : 6.3```

the image is just jxl lossless transcode of this

Does look like in the top left it properly did upsampling (since AC is available and that group is finalized), but in the rest we see Y DC correctly and chroma DC without upsampling

... file a bug?

I currently don't see how this would happen

I have the hardest times describing bugs, i'll submit this anyway

I should have fixed it: https://github.com/libjxl/libjxl/pull/675

I really hate chroma subsampling related bugs, there's too many of them xD

Can confirm it's fixed 👍

cool

i'm having(had) trouble building the libjxl cmake project when included inside another cmake project (using include_subdirectory). ${CMAKE_SOURCE_DIR} in <https://github.com/libjxl/libjxl/blob/main/third_party/skcms.cmake#L35> is referring to the root project, but when fetched, it's under a subdirectory deps created by cmake. I'm able to fix this by changing `${CMAKE_SOURCE_DIR}/lib/jxl/enc_jxl_skcms.h` to `${CMAKE_CURRENT_SOURCE_DIR}/../lib/jxl/enc_jxl_skcms.h` but I'm unsure about the correctness

It is probably correct... But please open a PR :)

This enc_jxl_skcms.h include is doing problems frequently.

yeah my first solution was to disable it and make it use lcms2

It is a bit of a hack...

is there an example for decoding to jpeg using the api?

https://github.com/libjxl/libjxl/pull/583/files#diff-ab4713b34c4b813999f1b8467050d922a5f6b61fd5b3b23ed6391199f3ac9b9bR236

does that count?

hmm not quite... I'll wait for jpeg to be more flushed out

on another note, i found some weird behaviour when decoding some headers, waiting a bit (maybe jumping out of memory), then continuing decoding after basic_info: lib/jxl/dec_bit_reader.h:212: JXL_FAILURE: Non-zero padding bits lib/jxl/toc.cc:64: JXL_RETURN_IF_ERROR code=1: reader->JumpToByteBoundary() lib/jxl/decode.cc:991: invalid toc entries or after color_encoding: lib/jxl/dec_frame.cc:370: JXL_RETURN_IF_ERROR code=1: dec_state_->shared_storage.matrices.DecodeDC(br) lib/jxl/decode.cc:1325: decoding frame failed lib/jxl/quant_weights.cc:476: JXL_FAILURE: Invalid dc_quant: coefficient is too small.

and to get around this i just setinput and flush the decoder every time

I don't know if this is intentional but it works

what's missing from that?

i just have no idea how to use it after staring it lol

... what happens if you don't flush instead?

haha ok, that function should give you a buffer containing the JPEG as output and do nothing else...

i get JXL_DEC_ERROR along with the errors above

odd

does it happen if you don't flush?

I mean

still set input, but not flush

(and also release input)

oh i mean release, not flush

ok 😄

then maybe some stuff moves around in memory? did you try running it under sanitizers?

(you might have to build libjxl with sanitizers too)