|
Traneptora
|
2022-04-28 09:49:03
|
and it's *my* responsibility to convert that? or do I just pass the ICC Profile and let the viewer handle it
|
|
|
_wb_
|
2022-04-28 09:49:21
|
you just attach the ICC profile you get with TARGET_DATA
|
|
|
|
Traneptora
|
2022-04-28 09:49:49
|
the ICC Profile I get with TARGET_DATA isn't necessarily the same ICC profile that is embedded in the codestream, is it?
|
|
|
|
_wb_
|
2022-04-28 09:50:02
|
no it is not, that would be the one you get with TARGET_ORIGINAL
|
|
2022-04-28 09:50:34
|
but that one is only useful if you want to do the conversion from the DATA space to the ORIGINAL space
|
|
|
|
Traneptora
|
2022-04-28 09:50:48
|
I see. so libjxl outputs an approrpriate ICC profile that can be used to convert sRGB pixel data received into the appropriate space for viewing
|
|
|
|
_wb_
|
2022-04-28 09:50:56
|
in case of uses_original_profile, DATA = ORIGINAL
|
|
2022-04-28 09:51:16
|
in case of !uses_original_profile, often DATA = ORIGINAL but not always
|
|
|
|
Traneptora
|
2022-04-28 09:51:21
|
this documentation is very not clear, btw
|
|
2022-04-28 09:51:52
|
`JxlDecoderGetColorAsEncodedProfile` implies that if you use `TARGET_DATA` you'll get a JxlColorEncoding struct that tells you it's using XYB most of the time
|
|
2022-04-28 09:52:02
|
at least, that's how I read it
|
|
|
|
_wb_
|
2022-04-28 09:52:15
|
with https://github.com/libjxl/libjxl/pull/1366 I want to simplify some things so you can request pixels in whatever space you want and always get it in that space
|
|
|
|
Traneptora
|
|
_wb_
if the image is in an enum space, you'll get pixels in that space, but if it's an arbitrary ICC color profile, you will get pixels in sRGB
|
|
2022-04-28 09:59:08
|
more specifically if there exists an attached ICC Profile will I *always* get sRGB?
|
|
2022-04-28 09:59:15
|
and will it always be nonlinear? or linear?
|
|
|
|
_wb_
|
2022-04-28 10:17:25
|
nonlinear when requesting uint, linear when requesting float
|
|
2022-04-28 10:18:51
|
unless you set a preferred color encoding, then it will use that
|
|
2022-04-28 10:19:41
|
but it will only use that if !uses_original_profile (so it has the data in xyb internally, and knows how to convert it to an enum colorspace as set with SetPreferredColorEncoding)
|
|
|
|
Traneptora
|
2022-04-28 10:20:30
|
I see
|
|
|
|
_wb_
|
2022-04-28 10:20:46
|
if uses_original_profile (so the data is actually in the colorspace of the icc profile), it will return the data in the image colorspace, since it doesn't handle arbitrary icc profiles itself
|
|
|
|
Traneptora
|
2022-04-28 10:20:46
|
this doesn't appear to be documented in https://libjxl.readthedocs.io/en/latest/api_decoder.html
|
|
2022-04-28 10:20:53
|
or if it is, it's not in an obvious location
|
|
|
|
_wb_
|
2022-04-28 10:21:25
|
I think it is somehow documented, but probably not very clearly. I think we need a bit of an api tutorial to better explain these things
|
|
|
|
Traneptora
|
2022-04-28 10:22:35
|
but the general strategy for files with an attached ICCP is to set `TARGET_DATA` and then forward the returned ICCP to the viewer, which then uses that ICCP to convert the sRGB data into whatever it needs to for display
|
|
2022-04-28 10:22:39
|
is this correct?
|
|
|
|
_wb_
|
2022-04-28 10:23:53
|
basically the goal was to make a libjxl_dec that doesn't depend on a cms and that does what it can, which is a lot but not everything (we can convert between xyb and enum spaces, but cannot handle arbitrary icc profiles). The pull request extends that by allowing you to set a cms and then the decoder can do any conversion.
|
|
|
|
Traneptora
|
2022-04-28 10:24:28
|
also, what happens if there's an an ICC profile attached to the codestream and then I set `TARGET_ORIGINAL`?
|
|
2022-04-28 10:24:34
|
it forwards that ICCP directly, right?
|
|
|
|
_wb_
|
2022-04-28 10:24:51
|
yes, the general strategy that always works is to give the TARGET_DATA profile to the viewer along with the pixel data, and that should always be correct
|
|
2022-04-28 10:25:06
|
regardless of what the input image is
|
|
|
|
Traneptora
|
2022-04-28 10:25:14
|
and what space is the pixel data in if I use TARGET_ORIGINAL?
|
|
|
|
_wb_
|
2022-04-28 10:25:35
|
the pixel data is always in the TARGET_DATA space
|
|
|
|
Traneptora
|
2022-04-28 10:25:58
|
I meant, what's the space for the pixels laid into the decoder buffer
|
|
|
|
_wb_
|
2022-04-28 10:26:13
|
the TARGET_DATA space
|
|
|
|
Traneptora
|
2022-04-28 10:26:16
|
ah, I see
|
|
2022-04-28 10:26:26
|
then what's the point of TARGET_ORIGINAL?
|
|
|
|
_wb_
|
2022-04-28 10:26:34
|
there is no reason to fetch the TARGET_ORIGINAL profile if you just want to show the image
|
|
|
|
Traneptora
|
2022-04-28 10:26:38
|
it's the space that `cjxl` was fed originally, right?
|
|
|
|
_wb_
|
2022-04-28 10:27:12
|
it is only useful in case you want to reconstruct a png in the same colorspace as what was in the input to cjxl
|
|
2022-04-28 10:27:38
|
but then you'll still have to convert the data you get from the DATA space to the ORIGINAL space yourself
|
|
|
|
Traneptora
|
2022-04-28 10:28:21
|
if this is the case, why is the responsibility for converting the attached ICCP on the decoder side and not the encoder side?
|
|
2022-04-28 10:28:58
|
oh right, cause you can request a different space
|
|
|
|
_wb_
|
2022-04-28 10:31:31
|
say the input is in some weird RGB space that is not covered by the enum and you do lossy encoding, then cjxl will convert the input to XYB and store the weird icc profile, but the libjxl decoder is not able to give you back pixels in that weird space by itself, since that would require arbitrary icc handling. It can give you the pixels in any enum colorspace though (sRGB by default, or maybe PQ in case of HDR), since it knows how to convert XYB to enum spaces.
|
|
|
|
Traneptora
|
2022-04-28 10:32:36
|
but if that's the case, how does the library produce the ICCP that `TARGET_DATA` gives you?
|
|
|
|
_wb_
|
2022-04-28 10:32:36
|
djxl will take the libjxl output and additionally convert it to the weird space (using lcms2 or skcms) to produce a png
|
|
2022-04-28 10:32:59
|
it can synthesize an icc profile that corresponds to any enum space
|
|
|
|
Traneptora
|
2022-04-28 10:34:03
|
> say the input is in some weird RGB space that is not covered by the enum and you do lossy encoding, then cjxl will convert the input to XYB
if libjxl cannot handle arbitrary ICCs, how does it convert this weird space to XYB in the first place
|
|
|
|
_wb_
|
2022-04-28 10:34:26
|
the full libjxl does depend on a cms
|
|
2022-04-28 10:34:31
|
libjxl_dec doesn't
|
|
|
|
Traneptora
|
2022-04-28 10:34:41
|
ah
|
|
2022-04-28 10:34:56
|
so this is to remove the CMS dep from a minimal decoder library
|
|
|
|
_wb_
|
2022-04-28 10:34:59
|
yep
|
|
2022-04-28 10:35:22
|
to reduce binary size for applications that care about that
|
|
|
|
Traneptora
|
2022-04-28 10:35:34
|
~~like firefox~~
|
|
2022-04-28 10:36:55
|
now, is there a way to have the full libjxl decode to a custom space
|
|
2022-04-28 10:41:00
|
I'm just wondering if there's a better way to handle ICCs than I'm currently using with the wrapper
|
|
2022-04-28 10:41:31
|
how can I check to see if I'm messing up the pixel data?
|
|
2022-04-28 10:42:05
|
I try `ffmpeg -i bench_oriented_brg/input.jxl test.png` and ffmpeg decodes the pixel data, encodes it as a PNG, and attaches the `TARGET_ORIGINAL` profile to `test.png`
|
|
2022-04-28 10:42:11
|
and then the viewer viewing `test.png` sees a red bench
|
|
2022-04-28 10:42:14
|
which I assume is accurate
|
|
|
|
_wb_
|
2022-04-28 11:02:22
|
yes, if it's red it's fine, if it's green you messed up 🙂
|
|
2022-04-28 11:03:37
|
though that example only helps a little, since it doesn't use xyb
|
|
2022-04-28 11:04:07
|
so TARGET_DATA == TARGET_ORIGINAL for that image
|
|
2022-04-28 11:04:32
|
in general, you need to attach the TARGET_DATA profile
|
|
2022-04-28 11:05:41
|
maybe we should add a conformance image that uses xyb with a weird icc profile, that would help catch bugs
|
|
|
|
Traneptora
|
2022-04-29 02:40:06
|
sounds like a good plan
|
|
2022-04-29 02:40:23
|
that would make it easier to test if I'm doing the right thing
|
|
|
|
_wb_
|
2022-04-30 07:39:23
|
<@260412131034267649> yes, the matrix room is only linked with this channel, I dunno how to do it with more channels easily
|
|
2022-04-30 07:39:47
|
The matrix thing was proposed by someone on the jpegxl reddit iirc
|
|
|
improver
|
2022-04-30 07:48:05
|
reddit is an awful site that always keeps nagging me to install their app so not something i'll voluntarely use. imo should be linked from semi-official site, if its maintained semi-officially just like this discord guild is
|
|
2022-04-30 07:49:28
|
also i think yeah one should be able to link whole guild. it used to be harder before they added spaces stuff
|
|
2022-04-30 07:54:50
|
not really nagging to do it right now, whatever you have time & feel like doing, but with current ways its done it might aswell not exist, both functionality & discoverability wise
|
|
|
nathanielcwm
|
|
improver
reddit is an awful site that always keeps nagging me to install their app so not something i'll voluntarely use. imo should be linked from semi-official site, if its maintained semi-officially just like this discord guild is
|
|
2022-04-30 07:57:12
|
use old reddit
|
|
2022-04-30 07:57:21
|
/ i reddit
|
|
|
The_Decryptor
|
2022-04-30 08:00:25
|
This would be the best option, bridge the entire JXL server to a Matrix space
https://github.com/Half-Shot/matrix-appservice-discord/issues/738
|
|
|
|
nathanielcwm
|
2022-04-30 08:01:17
|
unfortunately not all the discord / matrix features are mapped with these bridges iirc
|
|
2022-04-30 08:03:40
|
https://github.com/discord/discord-api-docs/discussions/3282 oh rip
|
|
2022-04-30 08:03:55
|
requires upstream changes from discord lol
|
|
|
|
improver
|
2022-04-30 08:10:37
|
i think this one aint too blocking. but yeah uhh idk
|
|
2022-04-30 08:10:44
|
one can make a new space
|
|
2022-04-30 08:10:57
|
and add every channel one by one
|
|
2022-04-30 08:11:00
|
ithink?
|
|
|
|
_wb_
|
2022-04-30 08:11:25
|
why are all these basic things like chat and document editing, that have been around for at least 4 decades, still not solved in a satisfactory way with an open standard that just works
|
|
|
|
improver
|
|
|
_wb_
|
2022-04-30 08:12:20
|
it feels like no real progress has been made since WordPerfect 5.1 and IRC
|
|
2022-04-30 08:13:00
|
only more proprietary variants of the same thing but less open and more broken, but with shinier user interfaces
|
|
|
|
improver
|
2022-04-30 08:13:31
|
exactly my thoughs
|
|
|
|
The_Decryptor
|
2022-04-30 08:14:12
|
I like the idea behind Matrix, but it's hard enough to setup that I'm not surprised people use Discord/Slack over it
|
|
2022-04-30 08:14:29
|
When Dendrite isn't crashing, it's also entirely unable to join rooms for me
|
|
|
|
improver
|
2022-04-30 08:14:36
|
i host my own server and wouldnt call it too hard
|
|
2022-04-30 08:14:46
|
but yeah kinda
|
|
|
|
_wb_
|
2022-04-30 08:16:23
|
it's probably that these things are too boring, too much work, and not intellectually challenging enough for the real good coders to work on until the point of really well-polished tools with well-thought-out APIs and protocols
|
|
2022-04-30 08:16:49
|
yet they are too tricky for mediocre coders to get right
|
|
|
|
improver
|
2022-04-30 08:17:33
|
matrix is actually not bad protocol wise. it supports a lot of stuff. just manpower isn't there because lol why work for free
|
|
2022-04-30 08:18:27
|
so server impls are kinda either very inefficient (synapse) or half-done (dendrite and whatever rust one was called)
|
|
2022-04-30 08:19:18
|
and bridges arent perfect either, but thats part of propietary side being uncooperative too
|
|
2022-04-30 08:21:07
|
i mean they have that whole room state resolution mechanics stuff going in protocol, its pretty interesting actually
|
|
|
|
The_Decryptor
|
2022-04-30 08:21:37
|
Their plans for a mesh based P2P backend are very cool too, I hope it pans out
|
|
|
|
nathanielcwm
|
2022-05-01 10:45:18
|
iirc google talk used to use an open standard called xmpp?
but hangouts / whatever new messaging app that google is pushing today use their own proprietary standards?
|
|
|
|
Traneptora
|
2022-05-01 05:10:34
|
```
R = Y + 0.5 + 1.402 * Cr;
G = Y + 0.5 + 0.344136 * Cb - 0.714136 * Cr;
B = Y + 0.5 + 1.772 * Cb;
```
^ does anyone know if this matrix is the same as Rec 709?
|
|
|
|
_wb_
|
2022-05-01 05:54:06
|
Jxl uses the same one as jpeg
|
|
2022-05-01 05:55:16
|
https://en.m.wikipedia.org/wiki/YCbCr lists all the different flavors of YCbCr
|
|
2022-05-01 05:56:25
|
In ffmpeg terms, that would be pix_fmt yuvj444p / yuvj420p, iirc
|
|
2022-05-01 05:58:16
|
It's full-range Rec.601, iirc
|
|
|
|
Traneptora
|
2022-05-01 06:16:09
|
it's 601, thanks
|
|
|
_wb_
In ffmpeg terms, that would be pix_fmt yuvj444p / yuvj420p, iirc
|
|
2022-05-01 06:16:28
|
these are deprecated
|
|
2022-05-01 06:16:37
|
and have been for like a decade
|
|
2022-05-01 06:16:52
|
it's yuv444p (with range set to `pc`)
|
|
2022-05-01 06:17:08
|
but 601 is what I'm looking for, thanks
|
|
|
|
_wb_
|
2022-05-01 06:20:18
|
Ah is that deprecated?
|
|
2022-05-01 06:21:17
|
I suck at remembering ffmpeg syntax, so --pix_fmt=yuvj444p is something I can do, but setting range separately I dunno
|
|
|
|
Traneptora
|
2022-05-01 06:22:43
|
`ffmpeg -i foo.png -pix_fmt yuv444p -color_range pc foo.jpg`
|
|
2022-05-01 06:23:00
|
this would be one way to do it
|
|
2022-05-01 06:23:08
|
although it automatically will do these options in this specific case
|
|
2022-05-01 06:31:11
|
ideally you'd do this tho
|
|
2022-05-01 06:31:35
|
```
ffmpeg -i foo.png -vf zscale=m=bt470bg:r=pc,format=yuv444p foo.jpg
```
|
|
2022-05-01 06:32:02
|
that lets you explicitly select the JPEG matrix so the colors won't be messed up
|
|
2022-05-02 03:01:59
|
Are there any conformance samples that have colorspaces that aren't sRGB and have no attached ICC Profile?
|
|
2022-05-02 03:02:37
|
I'm trying to test something regarding non-sRGB data coming from libjxl
|
|
|
|
_wb_
|
2022-05-02 05:47:52
|
I think he meant enum rgb that is not srgb
|
|
2022-05-02 05:48:18
|
Cmyk is probably not in scope of ffmpeg, it's an annoying can of worms...
|
|
2022-05-02 06:50:47
|
they're ignoring the black and not applying the color profile, which is not very surprising - that easily happens
|
|
2022-05-02 06:52:09
|
it's annoying because you need color management that goes from 4 channels to 3 channels (so an extra code path, it's not the usual 3 to 3), and also with the current api you need to explicitly fetch the kBlack channel and probably interleave it yourself with the RGB/CMY channels
|
|
2022-05-02 06:53:16
|
I want to change things so that at least if there is a CMS available, libjxl itself will convert CMYK to RGB, so viewers will get it right without needing to implement extra stuff on their end
|
|
|
w
|
2022-05-02 07:21:26
|
is cjxl on cmyk jpeg supposed to work right now?
|
|
|
|
_wb_
|
2022-05-02 07:40:50
|
no
|
|
2022-05-02 07:41:07
|
atm there is no input format for cjxl to pass it cmyk data
|
|
2022-05-02 07:41:21
|
at some point cmyk PSD input worked
|
|
2022-05-02 07:43:00
|
cmyk jpeg could theoretically be converted losslessly as dct coeffs for the cmy part, and then the k component would have to be decoded to pixels and encoded like that.
|
|
2022-05-02 07:43:31
|
that's not implemented though, it would require quite a bit of annoying plumbing work to make that work
|
|
2022-05-02 07:44:12
|
imo, if you care about black separation, you should also use a lossless format, not jpeg
|
|
2022-05-02 07:47:02
|
It's just annoying that there is no non-proprietary format for lossless cmyk (well, besides jxl)
|
|
2022-05-02 07:47:46
|
Tiff and PSD are proprietary Adobe formats with specs that are moving targets and incomplete
|
|
2022-05-02 07:48:30
|
I guess imagemagick's miff could be used, but that's not really a very interoperable format either, and I don't think it has a spec besides the code
|
|
|
|
w
|
2022-05-02 07:48:36
|
out of 37000 pages, 1 from 2017 was cmyk and it gave me a headache when i started this
|
|
2022-05-02 07:48:48
|
i think i used imagemagick to convert it to a png
|
|
|
|
_wb_
|
2022-05-02 07:49:29
|
In printing industries, cmyk is still widely used
|
|
|
diskorduser
|
2022-05-02 10:25:41
|
How to convert CMYK tiff to lossless jxl?
|
|
|
|
_wb_
|
2022-05-02 11:56:34
|
At the moment, you'll have to do it yourself with the api, setting cmy as rgb and k as a kBlack extra channel.
|
|
|
|
Deleted User
|
2022-05-02 04:23:45
|
hi to everynyan, how i can use overlays in jxl?
https://jpegxl.io/articles/faq/#doesjxlsupportoverlays?
|
|
|
|
_wb_
|
2022-05-02 04:39:59
|
At the moment, only via the api.
|
|
|
|
Deleted User
|
|
|
_wb_
|
|
|
Deleted User
|
|
Fraetor
|
|
190n
|
|
|
_wb_
|
2022-05-02 06:43:31
|
}
|
|
2022-05-02 06:43:59
|
But the next unclosed bracket is for <#806898911091753051>
|
|
|
lonjil
|
2022-05-02 10:00:10
|
Apologies to whoever designed it, but the FAQ page is really annoying. Huge text, loads of space between every question. Everything is so big it's hard to read.
|
|
|
|
_wb_
|
2022-05-03 05:06:45
|
I think we need a faq on the community website jpegxl.info too.
|
|
|
Justin
|
|
lonjil
Apologies to whoever designed it, but the FAQ page is really annoying. Huge text, loads of space between every question. Everything is so big it's hard to read.
|
|
2022-05-03 07:00:11
|
https://tenor.com/view/depressed-bored-boredom-swing-head-gif-17224602
|
|
|
|
lonjil
|
|
|
Justin
|
2022-05-03 08:14:32
|
Though I agree it needs way more love for a better reading experience 🙂
|
|
|
|
Traneptora
|
2022-05-03 04:39:36
|
What are the jxl primaries for re-encoded JPEG?
|
|
2022-05-03 04:39:59
|
IIRC JPEG uses BT.601 also known as BT470BG
|
|
|
|
_wb_
|
2022-05-03 04:42:05
|
It does what most viewers do: sRGB if untagged, otherwise whatever the icc profile says
|
|
|
|
Traneptora
|
2022-05-03 04:42:19
|
thanks
|
|
2022-05-04 02:23:17
|
that response from jon seems to imply that progressive jpeg transcoding is supported
|
|
|
|
_wb_
|
2022-05-04 05:11:14
|
It's certainly supported by the jxl bitstream to do progressive transcoding of progressive jpeg.
|
|
2022-05-04 05:11:58
|
Also jxl is always somewhat progressive when doing vardct, since it always puts the dc first.
|
|
2022-05-04 05:16:58
|
Adding something about cmyk jpegs and other limitations would be nice. But as I said, I think we should add a faq section to jpegxl.info, which is on github so easier to community maintain. If anyone wants commit rights on that repo, feel free to ask.
|
|
|
|
Traneptora
|
2022-05-04 11:48:44
|
Are these two transfer functions specified by the same standard, or is this a typo?
|
|
2022-05-04 11:49:17
|
`JXL_TRANSFER_FUNCTION_PQ` and `JXL_TRANSFER_FUNCTION_DCI` both cite `As specified in SMPTE ST 428-1`
|
|
2022-05-04 11:53:34
|
iirc PQ was published in SMPTE 2048 which is why I ask
|
|
2022-05-04 11:54:21
|
so it is a typo
|
|
2022-05-04 11:54:29
|
probably a copy/paste error if I had to guess
|
|
2022-05-04 11:55:30
|
that part was *my* typo
|
|
2022-05-04 11:55:39
|
but the docs list it as SMPTE ST 428
|
|
2022-05-04 11:55:46
|
which is probably just a copy/paste error from DCI
|
|
2022-05-04 12:01:33
|
sent a PR for it
|
|
2022-05-04 12:01:34
|
https://github.com/libjxl/libjxl/pull/1390
|
|
2022-05-04 05:51:34
|
Is there any interest in standardizing Motion JXL, like consecutive single-frame JXL in a mpegts container?
|
|
2022-05-04 05:51:47
|
or some container
|
|
2022-05-04 05:52:07
|
I ask because JXL could potentially replace ffv1 as an intra-only lossless archiving format
|
|
2022-05-04 05:52:26
|
or, it could be delivered in an ultra-low-latency (1-frame) environment inside mpegts
|
|
|
BlueSwordM
|
|
|
Deleted User
|
|
Traneptora
Is there any interest in standardizing Motion JXL, like consecutive single-frame JXL in a mpegts container?
|
|
2022-05-04 06:21:43
|
Is it possible to (correctly) use delta frames in a video container?
|
|
|
|
Traneptora
|
|
Is it possible to (correctly) use delta frames in a video container?
|
|
2022-05-04 06:27:49
|
you would not want to do that
|
|
2022-05-04 06:28:00
|
I'm talking about a sequence of stills, not an animation
|
|
2022-05-04 06:28:30
|
like, a sequence of codestreams, each would represent one frame
|
|
2022-05-04 06:28:40
|
in a proper container
|
|
|
Orum
|
|
Traneptora
I ask because JXL could potentially replace ffv1 as an intra-only lossless archiving format
|
|
2022-05-04 06:36:01
|
I think we still have quite a ways to go before that makes sense
|
|
2022-05-04 06:36:29
|
but yeah, it'd be a good idea to standardize it so it's an option
|
|
2022-05-04 06:38:57
|
Is there even a way to losslessly encode YCbCr with chroma subsampling in JXL? 🤔 I assume it's possible but I'm not sure how...
|
|
|
|
Traneptora
|
|
Orum
Is there even a way to losslessly encode YCbCr with chroma subsampling in JXL? 🤔 I assume it's possible but I'm not sure how...
|
|
2022-05-04 06:41:20
|
lossless jpeg transcode does support 4:2:0
|
|
2022-05-04 06:41:38
|
I'm not entirely sur what the technical details are though
|
|
|
|
Orum
|
2022-05-04 06:42:21
|
so you need to first use a lossless jpeg encoder, and then transcode to JXL? <:SadOrange:806131742636507177>
|
|
|
|
Traneptora
|
2022-05-04 06:42:35
|
no, I mean, JPEG -> JXL does support 4:2:0
|
|
|
|
Orum
|
2022-05-04 06:42:42
|
oh, yeah, I get that
|
|
2022-05-04 06:43:08
|
but if I have a lossless clip in 4:2:0 how do I get that into a lossless jxl?
|
|
|
|
Traneptora
|
2022-05-04 06:43:28
|
Atm, you'd have to store it as 4:4:4
|
|
2022-05-04 06:43:40
|
libjxl doesn't support planar input, and doesn't support YCbCr input atm
|
|
2022-05-04 06:43:57
|
even though internally it's planar, libjxl right now only supports packed RGB input and output
|
|
|
|
Orum
|
2022-05-04 06:44:03
|
yeah, so like I said, we've got quite a ways to go
|
|
2022-05-04 06:45:12
|
Still would be nice to have an alternative to FFV1. Few codecs even come close to it in intra performance.
|
|
|
|
Traneptora
|
2022-05-04 06:45:20
|
mostly just JXL
|
|
2022-05-04 06:45:42
|
problem is RGB is twice the size of 4:2:0
|
|
2022-05-04 06:45:53
|
I don't believe you save much in the lossless department there
|
|
2022-05-04 06:46:16
|
though in lossy I believe it doesn't matter much
|
|
|
|
Orum
|
2022-05-04 06:46:17
|
well RGB is always going to be heavier
|
|
|
|
Traneptora
|
2022-05-04 06:46:31
|
the issue with 4:2:0 is the internal usage of XYB
|
|
2022-05-04 06:46:50
|
it would have to treat Y as a full plane, and X and B as half-resolution
|
|
2022-05-04 06:47:01
|
I'm not sure if the codestream format allows you to do that, at the moment
|
|
|
|
_wb_
|
2022-05-04 07:16:13
|
Not for xyb
|
|
2022-05-04 07:16:16
|
Only for ycbcr
|
|
2022-05-04 07:19:05
|
We consider chroma subsampling a very crude way to do lossy, it's basically the same thing as zeroing the 75% highest frequency DCT coefficients in every block. It's not useful for compression if your entropy coding is good enough, it's only somewhat useful maybe to save video memory if the gpu can do the upsample+convert to rgb itself.
|
|
2022-05-04 07:19:56
|
Lossless ycbcr 444, 420, 422 is possible, at some point I even had a y4m loader in cjxl to test it
|
|
2022-05-04 07:21:00
|
But with the library api atm it's not possible to pass buffers that way
|
|
|
|
Orum
|
2022-05-04 07:22:34
|
So it's not possible to accept y4m input right now in cjxl? When would we see it in the API?
|
|
|
|
_wb_
|
2022-05-04 07:23:20
|
As for motion jxl: why not just use a single codestream with all the frames? That allows future encoders to use some of the (simple but sometimes probably effective) inter frame coding tools (like just doing gif/apng style cropped frames if only part of the canvas needs updating).
|
|
|
|
Orum
|
2022-05-04 07:24:22
|
APNG's more transparency than crop-based AFAIK
|
|
|
|
_wb_
|
|
Orum
So it's not possible to accept y4m input right now in cjxl? When would we see it in the API?
|
|
2022-05-04 07:24:49
|
At some point we simplified the image loaders to use some representation that corresponds closer to the api, and that made it hard to keep the y4m loader
|
|
|
|
Orum
|
2022-05-04 07:25:12
|
ah <:NotLikeThis:805132742819053610>
|
|
|
|
_wb_
|
|
Orum
APNG's more transparency than crop-based AFAIK
|
|
2022-05-04 07:25:15
|
It can do both, and so can jxl
|
|
|
|
Orum
|
2022-05-04 07:26:28
|
well, once we see support for it in the API I assume we'll get it in cjxl (and perhaps, more importantly, in ffmpeg)
|
|
|
|
_wb_
|
2022-05-04 07:26:29
|
It's just a matter of priorities, we didn't consider it essential for the 1.0 version of the api so we dropped it for now, but the bitstream can do it just fine
|
|
|
|
Orum
|
2022-05-04 07:28:49
|
are we going to see a 0.7, 0.8, 0.9, or just a jump to 1.0 at some point?
|
|
|
|
Traneptora
|
|
_wb_
As for motion jxl: why not just use a single codestream with all the frames? That allows future encoders to use some of the (simple but sometimes probably effective) inter frame coding tools (like just doing gif/apng style cropped frames if only part of the canvas needs updating).
|
|
2022-05-04 07:29:57
|
because frames embedded inside mpegts need to able to be read if you're not at the start of the stream
|
|
2022-05-04 07:30:31
|
and the whole point was an intra-only archival which doesn't work if you only have one codestream and one codestream header
|
|
2022-05-04 07:30:56
|
at that point you lose any and all advantage over H.264
|
|
|
|
Orum
|
2022-05-04 07:31:02
|
I see no reason it can't do both: an intra-only stream, and a APNG-style stream
|
|
2022-05-04 07:34:28
|
even FFV1 lets you have a larger GOP (which still encodes all data on each frame, but lets the context adapt over multiple frames)
|
|
|
|
Traneptora
|
2022-05-04 07:34:43
|
ffv1 uses g=1 for archival
|
|
2022-05-04 07:34:54
|
it's not recommended to span the entropy encoder across multiple frames
|
|
|
|
Orum
|
2022-05-04 07:35:12
|
all depends on what you want 🤷♂️
|
|
|
|
Traneptora
|
2022-05-04 07:35:21
|
the prediction itself is intra but the entropy coding is not and that's generally not recommended
|
|
2022-05-04 07:35:29
|
at that point just use something that has interprediction like lossless 264
|
|
|
|
Orum
|
2022-05-04 07:36:30
|
I think it makes more sense TBH, as integrity should really be taken care of at other levels
|
|
|
|
Traneptora
|
2022-05-04 07:37:02
|
well all the standards agencies disagree with you
|
|
|
|
_wb_
|
|
Orum
are we going to see a 0.7, 0.8, 0.9, or just a jump to 1.0 at some point?
|
|
2022-05-04 07:39:15
|
Just a jump to 1.0.
|
|
|
|
Orum
|
2022-05-04 07:41:12
|
😆 I don't care if they do. The savings from inter are such that you'd probably get better resiliency by doing an inter encode and spending the difference in size on parity than just doing an intra encode
|
|
|
|
Traneptora
|
2022-05-04 07:41:33
|
if you're doing that, then you should just use lossless H.264
|
|
|
|
Orum
|
2022-05-04 07:41:56
|
that's what I'm saying <:YEP:808828808127971399>
|
|
|
|
_wb_
|
2022-05-04 07:42:17
|
Integrity should be taken care of at another level, but I guess for really long term archival, it might be worth it to sacrifice some compression for robustness. For lossless, inter doesn't help that much unless it's synthetic stuff like screen content.
|
|
|
|
Traneptora
|
2022-05-04 07:42:36
|
it does help when you have things like pans
|
|
2022-05-04 07:42:42
|
as long as there's motion compensation
|
|
2022-05-04 07:42:59
|
which H.264 has
|
|
|
|
Orum
|
2022-05-04 07:43:01
|
well it definitely helps a lot more on synthetic but even on natural content (especially low-noise natural content) it helps
|
|
|
|
_wb_
|
2022-05-04 07:44:12
|
I mean, jxl could do the motion compensation for panning with patches
|
|
2022-05-04 07:44:33
|
Panning is fine, as long as it's just a 2D translation
|
|
|
|
Orum
|
2022-05-04 07:45:35
|
the pan would have to be in whole pixel increments (or some multiple thereof)
|
|
|
|
_wb_
|
2022-05-04 07:45:59
|
Yes, we don't have subpixel patch offsets
|
|
2022-05-04 07:47:33
|
How does subpixel motion work anyway? Is that effective for lossless?
|
|
|
|
Orum
|
2022-05-04 07:48:48
|
most of subpixel support that I know of is for MV/ME
|
|
2022-05-04 07:49:39
|
I don't see why it would *hurt* lossless but I imagine the gains depend entirely on the content
|
|
|
|
_wb_
|
2022-05-04 07:54:03
|
For lossy, just getting a good approximation of what it should be is fine, and lossy residuals take care of the rest. But for lossless, just getting close is not good enough. The residuals need one more bit than the data itself, and they need to compensate for whatever weird artifacts the approximation introduced, which generally means you're mixing two sources of entropy and hurting compression instead of improving it.
|
|
2022-05-04 07:55:41
|
E.g. subtracting the previous frame from the current one can be great if there are exact matches, but if the frames are noisy sensor data, it just kind of adds one bpp of entropy
|
|
2022-05-04 07:56:25
|
Lossy is very different from lossless in that respect. Lossy doesn't care about least significant bits.
|
|
|
|
Orum
|
2022-05-04 08:11:52
|
yeah, you can definitely see that on noisy content, where FFV1 will best x264 in bitrate
|
|
|
|
Deleted User
|
|
Orum
are we going to see a 0.7, 0.8, 0.9, or just a jump to 1.0 at some point?
|
|
2022-05-04 10:37:52
|
version numbers don't work like fractions 😆... you could also have 0.10, 0.11 and so on
|
|
|
Traneptora
if you're doing that, then you should just use lossless H.264
|
|
2022-05-04 10:38:10
|
but lossless x264 is extremly slow compared to fjxl :)
|
|
|
|
Orum
|
|
version numbers don't work like fractions 😆... you could also have 0.10, 0.11 and so on
|
|
2022-05-04 10:38:38
|
true, all depends on what the devs decide
|
|
2022-05-04 10:39:19
|
personally I'm a fan of using 0.0x if you are willing to ever go to 0.1x
|
|
|
|
Deleted User
|
2022-05-04 10:40:10
|
yes, and maybe add an additional 0 just in case 😁
|
|
|
|
Orum
|
2022-05-04 10:42:14
|
anyway, it's really hard to compare lossless x264 to jxl right now, as RGB is certainly not one of x264's strengths, and 4:2:0 (or YCbCr in general?) isn't possible in jxl at present
|
|
|
|
_wb_
|
2022-05-04 10:50:55
|
444 ycbcr is possible
|
|
|
|
Deleted User
|
|
Orum
anyway, it's really hard to compare lossless x264 to jxl right now, as RGB is certainly not one of x264's strengths, and 4:2:0 (or YCbCr in general?) isn't possible in jxl at present
|
|
2022-05-04 10:51:21
|
but that's exacly why we need a good and fast RGB video encoder based on fjxl (though this should have low priority for now).
|
|
|
|
Orum
|
2022-05-04 10:57:21
|
How do I feed 4:4:4 YCbCr in? Am I stuck using it via ffmpeg then?
|
|
|
|
Fraetor
|
2022-05-04 11:07:41
|
What original source is this YCbCr content coming from? It naively seems to me that most lossless original recordings/renders would be RGB.
|
|
|
|
_wb_
|
2022-05-04 11:22:17
|
If you pass ycbcr as rgb to libjxl and set JXL_ENC_FRAME_SETTING_COLOR_TRANSFORM to 2, it will encode it marked as ycbcr.
|
|
2022-05-04 11:23:10
|
Has to be jpeg-style full range though, no tv range in jxl
|
|
|
|
Orum
|
2022-05-05 02:02:27
|
I assume ffmpeg will do that?
|
|
|
|
_wb_
|
2022-05-05 05:10:49
|
Not atm probably, I assume
|
|
2022-05-05 05:11:32
|
It also only works for lossless, I dunno what that does for lossy but probably something bad
|
|
|
|
veluca
|
|
Traneptora
because frames embedded inside mpegts need to able to be read if you're not at the start of the stream
|
|
2022-05-05 12:24:06
|
fwiw the frame index box does in principle allow you to skip to any frame in a intra-only setting
|
|
|
|
Traneptora
|
|
veluca
fwiw the frame index box does in principle allow you to skip to any frame in a intra-only setting
|
|
2022-05-05 12:25:45
|
and what if you didn't read this box because you aren't at the start of the stream?
|
|
2022-05-05 12:26:00
|
or the image header?
|
|
|
Orum
well, once we see support for it in the API I assume we'll get it in cjxl (and perhaps, more importantly, in ffmpeg)
|
|
2022-05-05 12:28:44
|
as for this, I find it unlikely that animated jxl will happen anytime soon
|
|
|
|
veluca
|
2022-05-05 12:36:37
|
I'm not sure why that would need to happen
|
|
|
|
_wb_
|
2022-05-05 12:42:03
|
if/when we have an fjxl-style low effort lossless encoding integrated in libjxl, then animated jxl could be a somewhat useful alternative for ffv1
|
|
2022-05-05 12:43:48
|
but for web delivery of animation, I think the future is clearly just using video codecs - preferably browsers would just support anything they support in a video tag also in an img tag, with the only difference being that audio gets muted, no player controls are shown, and it loops.
|
|
2022-05-05 12:44:07
|
add that, and GIF, APNG and animated WebP become completely redundant
|
|
|
|
Traneptora
|
2022-05-05 04:07:18
|
would fjxl be effort=0 or something?
|
|
2022-05-05 04:07:27
|
and is there an equivalent of fjxl for lossy?
|
|
|
|
_wb_
|
2022-05-05 04:14:26
|
either we could add effort=0, or we make it effort 1 because the current e1 isn't very different from e2
|
|
2022-05-05 04:16:31
|
fast lossy is an interesting idea, something faster than the current e3 (fastest for lossy) is certainly possible I guess, but probably more work than fast lossless
|
|
|
|
JendaLinda
|
2022-05-06 05:05:15
|
I'm playing with animated JXL. I converter an animated PNG using cjxl -d 0 -e 9. Works pretty well. Then I converted the animation back to APNG using djxl and found out an interesting thing. In the source APNG, there were frames with transparent background, that were being blended against the previous frames like layers. In the APNG after the JXL encode/decode process, the frames are just flattened, each frame contains layers blended together. Does JXL attempt to do some optimizations between the frames in animated JXL? When is the flattening happening? During encoding to JXL or decoding to APNG?
|
|
|
|
_wb_
|
2022-05-06 05:12:00
|
During decode to apng
|
|
2022-05-06 05:12:30
|
During encode, it just encodes the input literally, including frame crop
|
|
2022-05-06 05:13:20
|
During djxl decode, since coalesced decoding is the default, it will blend all the frames to image size and end up encoding it like that too in apng
|
|
2022-05-06 05:14:46
|
Non-coalesced decoding is also possible, but jxl has more blend modes than apng so in general (if the input does not come from apng) coalesced decoding is easier to deal with for applications.
|
|
|
|
JendaLinda
|
2022-05-06 05:27:52
|
I see, so it's still possible to encode animations losslessly. I hope that in the future there will be some tool for editing JXL animations, inserting and extracting individual frames, changing the timings etc.
|
|
|
|
_wb_
|
2022-05-06 05:45:08
|
That would be nice. The API supports most things you would need for that, except when you want to do header-only manipulations without re-encoding the pixel data, we don't have an API for that yet.
|
|
|
|
JendaLinda
|
2022-05-06 06:18:10
|
Speaking of multiple blending modes, is there some overview in the documentation? And overview of the header fields would be nice too. Probably I'm just dumb, but I couldn't find anything. I'm not very good in coding, but I might do some poking around.
|
|
|
|
_wb_
|
2022-05-06 06:29:36
|
It's in the spec, and to some extent in the api documentation
|
|
|
fab
|
2022-05-06 06:45:35
|
do you have a win build
|
|
2022-05-06 06:45:39
|
someone
|
|
2022-05-06 06:48:14
|
|
|
|
|
Diamondragon
|
|
fab
do you have a win build
|
|
2022-05-06 07:04:29
|
https://artifacts.lucaversari.it/libjxl/libjxl/latest/jxl-x64-windows-static.zip
|
|
|
|
fab
|
2022-05-06 07:08:07
|
i'm loooking fo a non elease build
|
|
2022-05-06 07:11:51
|
pipelines takes so long
|
|
2022-05-06 07:12:13
|
i'm waiting since an hou fo svt av1
|
|
2022-05-08 10:29:23
|
i need a build
|
|
2022-05-08 10:30:06
|
https://github.com/libjxl/libjxl/pull/1395
|
|
|
|
_wb_
|
2022-05-08 07:55:24
|
https://github.com/libjxl/libjxl/issues/1399#issuecomment-1120477577
|
|
2022-05-08 07:55:41
|
That's a nice gif there
|
|
2022-05-08 08:07:02
|
50 fps
|
|
2022-05-08 08:07:36
|
single-threaded decode is not fast enough for that on my machine
|
|
|
Fox Wizard
|
2022-05-08 08:08:24
|
Gotta convince Cloudinary to give you some monster PC for... "development" <:thinkies:854271204411572236>
|
|
|
|
_wb_
|
2022-05-08 08:09:25
|
heh no actually I think devs should generally try to use not too powerful machines
|
|
|
|
Fox Wizard
|
2022-05-08 08:09:42
|
1 mega powerful machine and 1 low end machine :p
|
|
|
|
_wb_
|
2022-05-08 08:09:53
|
yeah, that works too
|
|
2022-05-08 08:11:43
|
anyway, not that I think animated jxl is really a very important use case (better to use video codecs than animated still image codecs), but it would be nice if we can speed up decode enough to play an animation like that
|
|
2022-05-08 08:12:21
|
it's 50 fps which is a bit much, but it's only 600x600 which is not unreasonably big
|
|
|
|
JendaLinda
|
2022-05-08 08:12:31
|
IrfanView plays this smoothly on my ancient PC, although it takes several seconds to load. Probably IrfanView loads the whole animation into memory.
IrfanView has a different issue, it seems it ignores frame delays, so it plays all animated JXLs at maximum speed. Not sure if anybody have sent a bug report to the developer.
|
|
|
|
_wb_
|
2022-05-08 08:14:43
|
it's 380 frames at 600x600, that's 400 MB or so in uncompressed 8-bit RGB
|
|
|
|
Fraetor
|
2022-05-08 08:16:01
|
eog also does it on my low power laptop. Again it takes a few seconds to load.
|
|
|
|
_wb_
|
2022-05-08 08:17:33
|
Chrome should probably allow it to use more memory and just keep the whole thing in memory instead of re-decoding the whole time
|
|
2022-05-08 08:18:40
|
It would also help if we added a decode option to update only the changed part (always with kReplace blending but only the changed part, so something in between the current default decode and the non-coalesced decode)
|
|
|
|
Fraetor
|
2022-05-08 08:18:40
|
Probably a bug in GNOME, but when I take a screen recording to compare the framerates, the colours come out different for the two.
|
|
2022-05-08 08:19:07
|
Screenshots look fine, and it displays fine as well.
|
|
|
|
_wb_
|
2022-05-08 08:19:55
|
That's funky. I wonder how that happens. Maybe screen recording sets display color space to something different?
|
|
|
|
Fraetor
|
2022-05-08 08:20:30
|
Maybe. That said the gif goes a different colour as well, so untagged gets affected.
|
|
|
|
_wb_
|
2022-05-08 08:20:32
|
Screenshot also looks slightly different from screen recording for the gif
|
|
|
|
Fraetor
|
2022-05-08 08:20:47
|
The screenshot looks like what I see on the screen.
|
|
|
|
_wb_
|
2022-05-08 08:21:50
|
Interesting that they look different between gif and jxl in the recording, but probably a bug in gnome indeed
|
|
|
|
Fraetor
|
2022-05-08 08:22:46
|
Would it be possible that the video capture is taking it before any colour management has been applied, while the screenshot is after conversion to display colourspace?
|
|
|
|
_wb_
|
2022-05-08 08:23:36
|
No idea but it's clearly doing _something_ wrong
|
|
2022-05-08 08:24:16
|
The jxl and gif should both be sRGB though, so somewhat strange that they end up looking different
|
|
|
|
Fraetor
|
2022-05-08 08:24:17
|
I think the gnome screen recorder is pretty hacky anyway.
|
|
2022-05-08 08:26:02
|
It was only given a ui a version or two ago, but has been accessible with some secret shortcuts for a long time.
|
|
|
|
_wb_
|
2022-05-08 08:27:02
|
<@795684063032901642> that animated jxl is a good example to try to make work in chrome - it's currently very laggy on chrome
|
|
|
Moritz Firsching
|
2022-05-08 08:27:50
|
good to know..
|
|
|
|
JendaLinda
|
2022-05-08 08:32:23
|
Same thing in MS Edge, it's dropping most of the frames.
|
|
|
|
_wb_
|
2022-05-08 08:36:29
|
edge is chrome with a skin
|
|
|
|
BlueSwordM
|
|
_wb_
heh no actually I think devs should generally try to use not too powerful machines
|
|
2022-05-08 08:39:12
|
Lies.
You should get a 12900k machine for development 😈
|
|
2022-05-08 08:39:21
|
That way, you get the highest single core performance possible 😄
|
|
2022-05-08 08:39:41
|
Can libjxl currently do frame threaded decoding for animations?
|
|
2022-05-08 08:39:58
|
As in, decode multiple frames independently? That has a latency penalty, but a huge throughput increase.
|
|
2022-05-08 08:40:51
|
Oh my, it's dropping frames as well.
|
|
2022-05-08 08:40:57
|
Good way to justify a Zen 3 upgrade <:kekw:808717074305122316>
|
|
|
|
JendaLinda
|
2022-05-08 08:44:35
|
I'm rocking an old i5-3570
Anyway, my 1011x960 10fps animation is stuttering for a while but then runs smoothly in MS Edge.
|
|
2022-05-08 08:45:57
|
It has 10 frames though.
|
|
2022-05-08 08:51:27
|
Another animation is 501x776 ~8fps and that runs flawlessly.
|
|
|
|
improver
|
2022-05-08 09:25:18
|
i wonder if one could keep something like 1/2 or 1/3 of frames in memory & decode rest
|
|
2022-05-08 09:25:46
|
could still reduce amount of decoding needed
|
|
2022-05-08 09:26:10
|
but for decoder to figure it out.. i wonder if it'd be hard to make it smart enough
|
|
2022-05-08 09:26:52
|
maybe by keeping stats of what frames were decoded in past
|
|
|
|
_wb_
|
2022-05-08 09:27:21
|
Avoiding full frames would probably help most, then keeping it all in memory is less costly...
|
|
|
|
improver
|
2022-05-08 09:27:31
|
& when the time comes to go to begining again, it could check some condition & just record 1/3rd of frames for the next time
|
|
2022-05-08 09:34:15
|
but yeah only keeping update patches sounds much simpler
|
|
2022-05-08 09:34:25
|
though probably less broad
|
|
2022-05-08 09:34:26
|
but would work for this gif
|
|
|
|
fab
|
2022-05-09 07:38:25
|
d 0.563 s 9 with this commit has to be enough
|
|
2022-05-09 07:38:26
|
https://github.com/libjxl/libjxl/pull/1395
|
|
|
Yari-nyan
|
|
yurume
|
2022-05-09 04:05:20
|
it seems that `Passes::GetDownsamplingBracket` gives a wildly different result from the spec, especially when the Passes bundle is constructed manually.
|
|
2022-05-09 04:06:40
|
I'll post a Python code soon, but the following is a direct counterexample:
```
num_passes [(log2(downsample), last_pass)] spec libjxl
3 [] [None, None, (0, 3)] [(0, 3), None, None]
3 [(1, 0)] [(1, 3), None, (0, 1)] [(1, 3), (0, 1), None]
3 [(2, 0)] [(2, 3), None, (0, 2)] [(2, 3), (0, 2), None]
3 [(3, 0)] [None, None, (0, 3)] [None, (0, 3), None]
3 [(1, 1)] [None, (1, 3), (0, 1)] [(1, 3), None, (0, 1)]
3 [(2, 1)] [None, (2, 3), (0, 2)] [(2, 3), None, (0, 2)]
```
|
|
2022-05-09 04:10:13
|
(for spec/libjxl columns, each element is a (minshift, maxshift) pair for each pass, where minshift is inclusive and maxshift is exclusive to match the specification convention)
|
|
|
|
veluca
|
2022-05-09 04:20:55
|
<@794205442175402004>
|
|
|
|
yurume
|
2022-05-09 04:24:44
|
I've updated the code to i) skip ambiguous outputs from the specification and ii) treat empty shift ranges (minshift >= maxshift) identically
|
|
2022-05-09 04:36:29
|
https://gist.github.com/lifthrasiir/86f15edcc5b10db27839b917c602592c
|
|
2022-05-09 04:40:14
|
(fixed late-night bugs)
|
|
|
|
_wb_
|
|
yurume
it seems that `Passes::GetDownsamplingBracket` gives a wildly different result from the spec, especially when the Passes bundle is constructed manually.
|
|
2022-05-09 05:11:31
|
Ah, interesting, let's try to figure out if it's a libjxl bug or a spec bug or both.
|
|
|
|
yurume
|
2022-05-09 05:12:34
|
the first thing I've noticed was that the spec is ambiguous when there are multiple `last_pass` entries with the same value, but a deeper investigation revealed much more differences
|
|
|
|
_wb_
|
2022-05-09 05:13:03
|
Do you get differences on the specific Passed bundles currently produced by cjxl? (with the different progressive options it has)
|
|
|
|
yurume
|
2022-05-09 05:13:29
|
probably I should try to do that, I'm not sure about the actual consequences
|
|
|
|
_wb_
|
2022-05-09 05:14:06
|
We'll probably want to fix things in a way that minimizes breakage
|
|
|
|
yurume
|
2022-05-09 05:14:34
|
my guess is that it can probably change the image if some portion is omitted from the shift ranges (so that a particular shift is never covered by any pass, this happens for some inputs)
|
|
2022-05-09 05:15:14
|
otherwise I guess... it only affects the progressive decoding?
|
|
|
|
_wb_
|
|
yurume
my guess is that it can probably change the image if some portion is omitted from the shift ranges (so that a particular shift is never covered by any pass, this happens for some inputs)
|
|
2022-05-09 05:16:25
|
Oh, that would be bad, if that can happen we need better fuzzer seeds because that would potentially lead to decoded images being partly uninitialized memory
|
|
2022-05-09 05:18:10
|
The shift ranges determine what ends up in what groups (GlobalLF, LfGroups or HfGroups), so if we change that, it will make images undecodable
|
|
2022-05-09 05:18:41
|
If the ranges used in libjxl make sense for progression, it's just a matter of fixing the spec to match libjxl
|
|
2022-05-09 05:20:35
|
If the ranges used in libjxl don't make sense (but still cover all shifts), it means progression will not be optimal, and then we have to decide if we want to fix libjxl (and break existing bitstreams) or turn the behavior into spec (sacrificing progression for decodability of existing bitstreams)
|
|
2022-05-09 05:23:38
|
I hope it only affects Passes bundles not currently produced by cjxl, then we can solve it in whatever way is best without having to worry about existing bitstreams
|
|
|
|
yurume
|
|
_wb_
I hope it only affects Passes bundles not currently produced by cjxl, then we can solve it in whatever way is best without having to worry about existing bitstreams
|
|
2022-05-09 07:18:41
|
I've verified that the current libjxl only emits 5 combinations of the Passes bundle:
```
num_passes log_ds/last_pass pairs constant name
------------------------------------------------------------------
1 [] progressive_passes_dc_vlf
2 [(2,0)] progressive_passes_dc_lf
3 [(2,0), (1,1)] progressive_passes_dc_lf_salient_ac
4 [(2,0), (1,1)] progressive_passes_dc_lf_salient_ac_other_ac
2 [(1,0)] progressive_passes_dc_quant_ac_full_ac
```
|
|
2022-05-09 07:20:53
|
verifying that minshift/maxshift gets wrecked in the way I've inferred
|
|
2022-05-09 07:21:36
|
note that that wrecked minshift/maxshift is used in both the encoder and decoder, so it is not very surprising that the current implementation showed no issues
|
|
2022-05-09 07:23:40
|
the second entry (..._dc_lf) is the only case where the resulting shift ranges do not cover the whole range, I'll try to reproduce that case
|
|
2022-05-09 07:44:27
|
oh thank $DEITY, the second case actually has pairs of [(2,0)] not [(2,0), (1,1)], because there are only two passes so the last entry (corresponding to the last pass) gets ignored, and it's fully okay
|
|
2022-05-09 07:45:05
|
otherwise I've confirmed that shift ranges get assigned in the unexpected way, but in all cases they do cover all possible ranges
|
|
2022-05-09 07:47:56
|
there are two such cases:
- progressive_passes_dc_lf_salient_ac (cjxl options: `--progressive_ac --saliency_num_progressive_steps=3`)
- progressive_passes_dc_lf_salient_ac_other_ac (cjxl options: `--progressive_ac --saliency_num_progressive_steps=4 --saliency_threshold=<anything more than 0>`)
|
|
|
|
_wb_
|
2022-05-09 07:50:34
|
If those flags are needed to get a bitstream where libjxl disagrees with spec, I think we can assume that not many such bitstreams already exist, i.e. we can fix libjxl instead of fixing the spec
|
|
2022-05-09 07:50:50
|
At least, if the spec makes more sense than libjxl
|
|
|
|
yurume
|
2022-05-09 07:50:57
|
in both cases the image decodes back to original one, probably it only affects the progressive decoding performance
|
|
2022-05-09 07:52:41
|
of course specially crafted bitstreams can result in more problems
|
|
|
|
_wb_
|
2022-05-09 07:53:01
|
I guess in practice this matters most for progressive images with alpha, where the goal was that the modular resolution available should keep in sync with the vardct resolution available
|
|
|
|
yurume
|
2022-05-09 07:54:39
|
fixing this does make existing images using those passes undecodable, because it moves the placement of the modular group bits, right?
|
|
|
|
_wb_
|
2022-05-09 07:55:45
|
Or in fact the actual modular resolution should be a bit ahead of the vardct one, since shift N squeeze residuals would after unsqueeze become shift N-1 pixels, so you should always get alpha at slightly higher resolution than the vardct image, which seemed to make sense to me at the time.
|
|
|
yurume
fixing this does make existing images using those passes undecodable, because it moves the placement of the modular group bits, right?
|
|
2022-05-09 07:57:47
|
Yes, if we change behavior in libjxl, it will make existing such images undecodable. If this would happen on default cjxl or cjxl --progressive, that would be a big no no, and we would change the spec instead. If it only happens with rather exotic options, I think we can just do whatever makes most sense without caring too much about theoretical existing bitstreams.
|
|
|
|
yurume
|
2022-05-09 08:01:02
|
at this point I'd probably better writing an issue 😉
|
|
|
|
_wb_
|
2022-05-09 08:01:19
|
So if I understand correctly, libjxl is writing/expecting some modular data in an earlier pass than what the spec says, right?
|
|
|
|
yurume
|
2022-05-09 08:01:42
|
yes, but only when uncommon option combinations are used (for now)
|
|
2022-05-09 08:02:54
|
if we also consider specially crafted bitstreams, it is possible to *repeat* already handled shift ranges, I actually don't know what happens in this case
|
|
2022-05-09 08:03:50
|
will the decoder just read and paint additional modular data in that case?
|
|
|
|
_wb_
|
2022-05-09 08:03:52
|
It happens when there is more than one pass for a given resolution, and libjxl then puts the corresponding modular data in the first pass for that resolution instead of the last pass, is that right?
|
|
|
|
yurume
|
2022-05-09 08:04:21
|
to my knowledge libjxl never produces such bitstreams
|
|
2022-05-09 08:04:58
|
so it's more a question about like, whether this can cause a security issue or not
|
|
|
|
_wb_
|
2022-05-09 08:05:33
|
I think we should specifically say in the spec that valid bitstreams do not cause repeatedly handled or unhandled shift ranges
|
|
2022-05-09 08:05:41
|
And check it in the code
|
|
2022-05-09 08:05:58
|
I wonder why the fuzzer hasn't discovered this yet
|
|
|
|
yurume
|
2022-05-09 08:07:25
|
it's always possible that libjxl doesn't result in crash even in that case, just degraded performnace or maybe incorrect roundtrip result, so the fuzzer didn't catch that
|
|
|
|
_wb_
|
2022-05-09 08:09:14
|
Fitting modular into the vardct passes was a bit of a design challenge that arose when we combined pik and fuif: both supported progressive, but in fuif it was just done by doing squeeze and ordering the channels appropriately, while pik/vardct had the notion of passes.
|
|
2022-05-09 08:11:08
|
I may have been a bit sloppy when designing and/or implementing how the modular stuff gets spread over the different passes and the different sections within a pass (global, lfgroups, hfgroups)
|
|
2022-05-09 08:16:16
|
I'll look into it tomorrow, but I'm relieved that it's probably only going to affect crafted bitstreams and pretty exotic cjxl options.
|
|
|
|
yurume
|
2022-05-09 08:16:47
|
thank you! should I write an issue anyway? (I was about to write one)
|
|
|
|
_wb_
|
2022-05-09 08:17:19
|
Yes please!
|
|
2022-05-09 08:19:14
|
And thank _you_ for catching this, these kind of "decoder does it just as wrong as the encoder" bugs are very hard to discover
|
|
|
|
yurume
|
2022-05-09 08:26:48
|
agreed
|
|
|
|
veluca
|
2022-05-09 08:28:47
|
can you summarize what, when and how it is wrong?
|
|
2022-05-09 08:29:11
|
(I have limited remaining brainpower because I spent most of the day trying to debug a super annoying off-by-two in patch rendering...)
|
|
|
|
yurume
|
|
veluca
can you summarize what, when and how it is wrong?
|
|
2022-05-09 08:32:16
|
sorry for lengthy discussion! the gist is that in certain cases the passes data is interpreted in unintended ways, diverging from the specification, so the modular group data are misplaced or even repeated or whatever. libjxl might produce some affected bitstreams, but thankfully only when uncommon combinations of options are used, so he's talking about fixing libjxl to match the spec, not the other way.
|
|
|
|
veluca
|
2022-05-09 08:33:22
|
right, I was more wondering what are the certain cases, and how exactly the pass data is wrongly split up in those cases 😉
|
|
|
|
yurume
|
2022-05-09 08:33:43
|
I'm writing an exact issue about that 😉
|
|
|
|
veluca
|
2022-05-09 08:33:46
|
(AFAIU this only happens with modular mode, right?)
|
|
2022-05-09 08:33:53
|
ok, perfect, I'll read that one 😉
|
|
|
|
_wb_
|
2022-05-09 08:35:34
|
Yes, it's about the channel selection in modular based on channel shift. Would also affect alpha and maybe even dc frames, in principle.
|
|
|
|
veluca
|
2022-05-09 08:41:03
|
tbf if it only happens with the saliency map (as I *think* is the case from the table) then it probably affects something like 0, at most 1 existing files 😛
|
|
|
|
yurume
|
2022-05-09 09:05:35
|
https://github.com/libjxl/libjxl/issues/1401 not sure this is enough information but here it is
|
|
|
|
veluca
|
2022-05-09 09:08:50
|
As specified, minshift is determined to be downsample[n] if there is the largest index n such that last_pass[n] is equal to the pass index, otherwise it's set to maxshift. In the current implementation though, n is the largest index such that last_pass[n] is no less than the pass index, or 0 if there's no such n
🤦♂️
|
|
|
|
yurume
|
2022-05-09 09:10:31
|
ah I've miswritten that part, the spec is ambiguous if there are multiple `n` s.t. `last_pass[n] == pass_idx` 😉
|
|
2022-05-09 09:12:36
|
aand having filed this issue I can get back to jxsml coding (phew)
|
|
|
|
veluca
|
2022-05-09 09:13:46
|
https://tenor.com/view/emperors-new-groove-why-lever-complaining-gif-3500175
|
|
2022-05-09 09:13:48
|
```
// How many progressive saliency-encoding steps to perform.
// - 1: Encode only DC and lowest-frequency AC. Does not need a saliency-map.
// - 2: Encode only DC+LF, dropping all HF AC data.
// Does not need a saliency-map.
// - 3: Encode DC+LF+{salient HF}, dropping all non-salient HF data.
// - 4: Encode DC+LF+{salient HF}+{other HF}.
// - 5: Encode DC+LF+{quantized HF}+{low HF bits}.
```
2 and 3
|
|
|
|
yurume
|
2022-05-09 09:17:19
|
wait, is `--saliency_num_progressive_steps=5` a valid option?
|
|
|
|
veluca
|
2022-05-09 09:17:28
|
maybe
|
|
2022-05-09 09:17:40
|
let me check what the *code* does and not what the doc says it does
|
|
|
|
yurume
|
2022-05-09 09:17:49
|
nope, the doc is incorrect (I've just checked)
|
|
|
|
veluca
|
2022-05-09 09:18:34
|
🤦♂️ * 2
|
|
2022-05-09 09:20:27
|
unless I misunderstand the code, it's probably more correct to say that the case D does the same as E if you don't pass a saliency map than the other way round (i.e. it is fine)
|
|
2022-05-09 09:23:57
|
which means that the only broken cases are saliency = 1/2 (which make little sense anyway, as they just drop data IIUC) and 3 / 4 but only if you pass a saliency map (and there is no doc on how to do it at all in the cli option, and for that matter even I wouldn't really know how to do ... <@795684063032901642> might know though). Either way, this only affects modular images, i.e. images with alpha or encoded with modular and these options, and I think I can fairly confidently say that's not very common, so we're probably fine
|
|
|
|
yurume
|
2022-05-09 09:24:20
|
oops I've rotated the table, fixing it (normal cases are still fine, but since veluca's logic is now depending on that)
|
|
2022-05-09 09:25:13
|
the problematic `--saliency_num_progressive_steps` are 3 and 4, not 2 and 3---should have been fixed by now
|
|
|
|
veluca
|
2022-05-09 09:26:16
|
ah, that's a bit worse
|
|
2022-05-09 09:26:32
|
btw, how about --qprogressive_ac?
|
|
|
|
yurume
|
2022-05-09 09:27:07
|
that's the case E, so not affected by this bug
|
|
2022-05-09 09:27:42
|
actually I initially tried `-p --progressive_ac`, not realizing that `-p` will overwrite `--progressive_ac` even though it's placed before
|
|
|
|
veluca
|
2022-05-09 09:27:43
|
huh, really?
|
|
2022-05-09 09:28:07
|
ah, yes
|
|
2022-05-09 09:29:17
|
ok, and --saliency_num_progressive_steps defaults to 2, which is also a combination that is fine
|
|
2022-05-09 09:29:30
|
so you need to pass a non-default --saliency_num_progressive_steps= for things to break
|
|
|
|
yurume
|
2022-05-09 09:29:59
|
indeed
|
|
|
|
veluca
|
2022-05-09 09:31:41
|
my current vote is to make libjxl do the sensible thing
|
|
|
|
yurume
|
2022-05-09 09:33:15
|
yeah, in my opinion `downsample` should be strictly decreasing and `last_pass` should be strictly increasing
|
|
|
|
veluca
|
2022-05-09 09:34:05
|
(tries to remove the cobwebs from when that stuff was written...) what was last_pass again?
|
|
2022-05-09 09:34:41
|
IIRC the reason to have downsample *not* be *strictly* decreasing was to support things like saliency-only passes
|
|
|
|
yurume
|
2022-05-09 09:36:20
|
ah, so that *some* shift ranges can be encoded in different passes (sharing the same range, but decoded in multiple passes)?
|
|
|
|
veluca
|
|
|
yurume
|
2022-05-09 09:36:51
|
that sounds legitimate but I don't think either the spec or libjxl is prepared for that
|
|
|
|
veluca
|
2022-05-09 09:36:54
|
*in VarDCT mode*, it makes sense because the coefficients get summed together
|
|
2022-05-09 09:37:05
|
in modular mode, I don't know, but maybe <@794205442175402004> does
|
|
|
|
yurume
|
2022-05-09 09:37:41
|
both update maxshift of the next pass to minshift of the previous pass, suggesting that they are *intended* to be disjoint (at least to me)
|
|
|
|
veluca
|
2022-05-09 09:38:05
|
maxshift and minshift are not used at all by the actual vardct decoder 😄
|
|
|
|
yurume
|
2022-05-09 09:38:46
|
yeah, but then vardct is independent from the entire downsampling things
|
|
|
|
veluca
|
2022-05-09 09:38:52
|
how so?
|
|
2022-05-09 09:38:56
|
ah
|
|
2022-05-09 09:38:57
|
yeah
|
|
2022-05-09 09:39:10
|
for vardct, those pass definitions are basically metadata
|
|
2022-05-09 09:40:52
|
the actually-meaningful interpretation for modular mode was added after the fact
|
|
2022-05-09 09:42:11
|
(well, VarDCT still uses the *number* of passes)
|
|
|
|
_wb_
|
|
veluca
in modular mode, I don't know, but maybe <@794205442175402004> does
|
|
2022-05-09 09:47:21
|
Doing the same shift more than once was not anticipated and if it works, it doesn't have a useful behavior (it will probably just overwrite, certainly not add)
|
|
|
|
veluca
|
2022-05-09 09:48:11
|
that's what I expected
|
|
|
|
Orum
|
2022-05-10 03:17:00
|
at what effort does patches get enabled?
|
|
|
|
_wb_
|
|
|
Moritz Firsching
|
|
veluca
which means that the only broken cases are saliency = 1/2 (which make little sense anyway, as they just drop data IIUC) and 3 / 4 but only if you pass a saliency map (and there is no doc on how to do it at all in the cli option, and for that matter even I wouldn't really know how to do ... <@795684063032901642> might know though). Either way, this only affects modular images, i.e. images with alpha or encoded with modular and these options, and I think I can fairly confidently say that's not very common, so we're probably fine
|
|
2022-05-10 08:28:59
|
I don't know about saliency map, I'm not even sure that this option works at all anymore. It is something that tfish did, I think.
|
|
|
|
_wb_
|
2022-05-10 09:38:34
|
Added my proposal for how to fix things in https://github.com/libjxl/libjxl/issues/1401
|
|
|
|
fab
|
2022-05-10 09:50:09
|
with
|
|
2022-05-10 09:50:10
|
for %i in (D:\tel\ee\*.png) do cjxl -s 9 -d 0.765 --epf=3 --faster_decoding=4 --dots=0 "%i" "%i.jxl"
|
|
2022-05-10 09:50:28
|
i get compaable efficiency to video codec
|
|
2022-05-10 09:50:44
|
if i use diffetne options jxl bluss eveything
|
|
2022-05-10 09:51:11
|
and the image weights 80 kb oe and i don't see diff
|
|
2022-05-10 09:51:42
|
guess befoe eleasing 1.0 you could optimize
|
|
|
|
Fox Wizard
|
2022-05-10 10:10:43
|
Will you get a working ``r`` key before jxl 1.0 releases? <:thinkies:854271204411572236>
|
|
|
|
_wb_
|
2022-05-10 12:14:00
|
<@268284145820631040> <@179701849576833024> this should make libjxl do the right thing: https://github.com/libjxl/libjxl/pull/1406
|
|
2022-05-10 12:15:26
|
<@268284145820631040> in the python script you have ` if i == num_passes: minshift = 0` but that should be `num_passes - 1`
|
|
2022-05-10 12:15:58
|
I used that script to check that it now indeed does follow the spec
|
|
|
|
yurume
|
|
_wb_
<@268284145820631040> in the python script you have ` if i == num_passes: minshift = 0` but that should be `num_passes - 1`
|
|
2022-05-10 12:34:03
|
thank you for spotting it, I'll check out the PR soon
|
|
|
novomesk
|
2022-05-10 03:44:14
|
I am trying to make JXL with metadata but exiv2 has some problem to parse the file:
http://188.121.162.14/jxl/jpeg-xl-with-metadata.jxl
Can you check if the file is correct?
|
|
|
|
_wb_
|
2022-05-10 03:48:28
|
looks ok to me
|
|
2022-05-10 03:48:57
|
probably exiv2 and exiftool need to be fixed
|
|
2022-05-10 03:49:12
|
this one is even with uncompressed exif/xmp, which I was hoping would work already
|
|
2022-05-10 03:49:34
|
but we also want `brob` metadata, where the blobs get brotli-compressed...
|
|
|
|
Traneptora
|
2022-05-10 06:46:01
|
what do they decompress to, Exif or XMP?
|
|
|
|
_wb_
|
2022-05-10 07:03:46
|
Can be either
|
|
2022-05-10 07:04:18
|
First four bytes of a brob box are a box name
|
|
2022-05-10 07:05:45
|
Idea is that you can brotli-compress any isobmf box that way (but of course it only makes sense for non-codestream boxes that have some amount of compressible data)
|
|
2022-05-10 07:08:35
|
Libjxl can transparently encode and decode brob boxes so you can get a brob'ed exif or xmp box as if it's an uncompressed one
|
|
2022-05-10 07:09:41
|
But exiv2/exiftool and anything else that deals with metadata without using libjxl will still need to implement brob if we want it to work there too
|
|
2022-05-10 07:10:33
|
Not sure if they'll even want to do that, it means adding a brotli dependency...
|
|
2022-05-10 07:11:22
|
Compression works well for metadata though, lots of uncompressed plaintext strings in there, especially with xmp
|
|
|
|
novomesk
|
2022-05-10 07:42:30
|
exiftool works on that file, only exiv2 has problem.
|
|
|
|
Fraetor
|
|
_wb_
Idea is that you can brotli-compress any isobmf box that way (but of course it only makes sense for non-codestream boxes that have some amount of compressible data)
|
|
2022-05-10 10:56:05
|
Would a brotli compressed jxlc box be spec compliant, even if it doesn't really make sense?
|
|
|
|
yurume
|
2022-05-10 10:58:09
|
AFAIK it is downright illegal
|
|
2022-05-10 10:58:39
|
the spec specifically prevents `brob` and any of `jxl`-plus-whatever boxes compressed in that way
|
|
|
|
Fraetor
|
2022-05-10 11:38:49
|
Makes sense. It would only hurt decoder performance.
|
|
|
|
_wb_
|
2022-05-11 05:11:38
|
Does it still happen with current git djxl?
|
|
|
|
novomesk
|
2022-05-11 05:40:39
|
$ djxl jpeg-xl-with-metadata.jxl output1.jpg
JPEG XL decoder v0.7.0 ef97fe0 [AVX2]
Read 19049 compressed bytes.
./tools/box/box.cc:290: JXL_FAILURE: Cannot decode to JPEG without a JPEG reconstruction box
./tools/djxl.cc:210: JXL_FAILURE: Failed to decode JXL to JPEG
Warning: could not decode losslessly to JPEG. Retrying with --pixels_to_jpeg...
Decoded to pixels.
./lib/extras/enc/jpg.cc:208: JXL_FAILURE: alpha is not supported
Failed to write decoded image.
|
|
|
|
_wb_
|
2022-05-11 06:02:47
|
Well, that makes more sense. We should always print such errors, just "failed to write" is not informative
|
|
2022-05-11 06:09:32
|
Exif in png is not really well defined
|
|
2022-05-11 06:10:06
|
We embed it in a way that ImageMagick recognizes, iirc, but I dunno about exiv2
|
|
2022-05-11 06:19:08
|
Interesting, then maybe something was wrong after all... Or exiv2 makes an assumption it shouldn't make
|
|
2022-05-11 06:41:01
|
cjxl seems to put the exif/xmp in the beginning of the file, before the jxlc
|
|
2022-05-11 06:41:15
|
while jpeg-xl-with-metadata.jxl has it at the end, after the jxlc
|
|
2022-05-11 06:42:46
|
maybe exiv2 is assuming it is always in the beginning?
|
|
|
|
novomesk
|
2022-05-11 07:12:24
|
Maybe they search only at start. It would be useful they have more JXL testfiles: https://github.com/Exiv2/exiv2/tree/main/test/data
|
|
|
|
Traneptora
|
2022-05-11 08:51:08
|
how does libjxl tonemap?
|
|
2022-05-11 08:51:20
|
like if the XYB data is outside of the sRGB gamut
|
|
2022-05-11 08:51:24
|
and you request sRGB
|
|
2022-05-11 08:52:48
|
also, if libjxl itself includes a CMS for the encoder half, why can't we add that same CMS to the decoder for the full libjxl version?
|
|
2022-05-11 08:53:27
|
so, you could say request pixel data from libjxl to be the TARGET_ORIGINAL colorspace
|
|
|
|
_wb_
|
2022-05-11 09:34:52
|
Yes, I think we should do that, there's a PR related to that
|
|