|
Traneptora
|
2024-01-30 06:35:15
|
and you need to implement entropy decoding to determine its length
|
|
|
_wb_
|
2024-01-30 06:35:28
|
Right, but the first opportunity for padding is also only after the ICC profile
|
|
|
|
Traneptora
|
2024-01-30 06:35:41
|
hm? no the ImageMetadata has an extension bundle doesn't it
|
|
2024-01-30 06:35:56
|
oh wait
|
|
2024-01-30 06:35:57
|
no it doens't
|
|
2024-01-30 06:36:02
|
just the FrameHeader
|
|
2024-01-30 06:36:03
|
huh
|
|
2024-01-30 06:36:20
|
oh, no it does
|
|
2024-01-30 06:36:24
|
right before default_matrix
|
|
|
|
_wb_
|
2024-01-30 06:36:29
|
Yes, after the colorspace bundle there is an extension bundle
|
|
|
|
Traneptora
|
2024-01-30 06:36:31
|
and right after tone_mapping
|
|
2024-01-30 06:36:32
|
yea
|
|
2024-01-30 06:36:39
|
so, suppose you changed the orientation field
|
|
2024-01-30 06:36:47
|
and you changed the alignment by +2 bits
|
|
|
|
_wb_
|
2024-01-30 06:37:00
|
The ICC profile is part of the colorspace bundle
|
|
|
|
Traneptora
|
2024-01-30 06:37:05
|
no it's not
|
|
|
|
_wb_
|
2024-01-30 06:37:14
|
It's not?
|
|
|
|
Traneptora
|
2024-01-30 06:37:22
|
the flag "want_icc" is part of the ColourEncoding bundle
|
|
2024-01-30 06:37:30
|
but the actual ICC profile is immediately after the end of ImageMetadata
|
|
|
|
_wb_
|
|
|
Traneptora
|
2024-01-30 06:38:38
|
orientation by itself is easy to change cause it's fixed size
|
|
2024-01-30 06:38:41
|
1 + u(3)
|
|
|
|
_wb_
|
2024-01-30 06:38:59
|
Yeah, if it's not all default
|
|
|
|
Traneptora
|
2024-01-30 06:39:00
|
but changing the tagged colorspace is a lot more difficult
|
|
2024-01-30 06:39:29
|
but yes theoretically, okay, so I change tagged colorspace
|
|
2024-01-30 06:39:35
|
alignment changed by +3 bits
|
|
2024-01-30 06:39:42
|
so now I add an extension
|
|
2024-01-30 06:39:51
|
previous extension flag was 0, now it's 1
|
|
2024-01-30 06:40:41
|
so, to encode 1 as a u64 you have 100000 (6 bits)
|
|
2024-01-30 06:40:51
|
so you've now changed the alignment by +9 bits
|
|
2024-01-30 06:41:21
|
then the actual extension? set the payload size to 1
|
|
2024-01-30 06:41:31
|
1 bit that is
|
|
2024-01-30 06:41:38
|
encoding that in U64 is 100000, 6 bits
|
|
2024-01-30 06:41:42
|
so now you're at +15 bits
|
|
2024-01-30 06:41:46
|
and then the actual payload is 16 bits
|
|
2024-01-30 06:42:00
|
boom, you've now added a multiple of 8, and nothing else needs to be shifted
|
|
2024-01-30 06:42:45
|
that's the concept
|
|
2024-01-30 06:43:01
|
it's not ideal, but it makes it actually possible without having to implement an entropy decoder
|
|
|
|
_wb_
|
2024-01-30 06:44:31
|
Let's reserve the first extension on all extension bundles to be just for padding, with all payload bits equal to zero (other payload values reserved in case we want to reuse/overload this extension for something other than just padding)
|
|
2024-01-30 06:45:12
|
OK, <@179701849576833024> ? We just take note of this for a third edition and nothing else needs to be done.
|
|
|
|
Traneptora
|
2024-01-30 06:45:26
|
ye, it's backward compatible since decoders ignore unrecognized extensions
|
|
2024-01-30 06:45:43
|
but iirc each of the 64 possible extensions has a key
|
|
2024-01-30 06:45:52
|
what would the key be for "padding"
|
|
2024-01-30 06:46:28
|
currently the way decoders function is they read a u64 into a uint64_t key
|
|
2024-01-30 06:46:41
|
and then for each nonzero bit set in the key, they read a u64 indicating payload size
|
|
2024-01-30 06:46:48
|
and then each payload occurs in order
|
|
2024-01-30 06:46:59
|
so in order for the "first" extension to always be padding, it would have to be the bit at 0x1
|
|
|
|
_wb_
|
2024-01-30 06:49:16
|
Yes, bit 0x1 is what I mean with "the first extension"
|
|
|
|
Traneptora
|
|
|
_wb_
|
2024-01-30 07:05:48
|
We can define it to be also used as an extension extension in case we ever run out of extension identifiers. First bit of payload equals 0: it's padding. If it's 1, then read another extension bundle (for identifiers 64-127, and recursively all the rest of them since the first one (64) would again be a padding/extension extension)
|
|
|
|
veluca
|
2024-01-30 08:09:47
|
We should probably implement this 😛 I mean there's not much to implement, just avoid the warning
|
|
2024-01-30 08:24:37
|
and probably test it in the encoder...
|
|
2024-01-30 08:24:49
|
(and in general make clear what we are doing)
|
|
|
|
Traneptora
|
2024-01-30 02:33:48
|
Is there any reason libjxl doesn't support negative strides?
|
|
2024-01-30 02:34:00
|
I mean other than the fact that they use size_t
|
|
|
|
veluca
|
2024-01-30 02:37:04
|
when are they useful?
|
|
2024-01-30 02:37:09
|
PFM? opengl?
|
|
2024-01-30 02:38:03
|
I think the answer is a mix of (a) doesn't seem that useful and (b) easy source of bugs in implementation
|
|
|
|
Traneptora
|
2024-01-30 02:40:12
|
those are two examples of when they are useful, yea
|
|
2024-01-30 02:40:25
|
FFmpeg explicitly supports them though so I had to work around it
|
|
|
|
_wb_
|
2024-01-30 04:59:53
|
I suppose BMP is also using this weird bottom-up order where negative strides would be useful
|
|
|
spider-mario
|
2024-01-30 06:50:28
|
it would be, if people used BMP
|
|
2024-01-30 06:50:30
|
(kidding)
|
|
|
fab
|
2024-01-31 07:23:35
|
|
|
2024-01-31 07:23:42
|
How i improved avc codec
|
|
2024-01-31 07:39:41
|
|
|
2024-01-31 07:39:50
|
Youtube quality seems slowly improving
|
|
2024-01-31 08:09:36
|
|
|
2024-01-31 08:09:38
|
Premium
|
|
2024-01-31 08:09:43
|
|
|
2024-01-31 08:09:49
|
Not premium
|
|
|
w
|
2024-01-31 09:00:48
|
umm
|
|
2024-01-31 09:00:52
|
guys
|
|
|
jonnyawsom3
|
2024-01-31 09:06:54
|
Oh no, it's happening again
|
|
|
|
_wb_
|
2024-01-31 09:44:33
|
@fab putting you on a 1-week timeout again — don't spam channels with offtopic stuff pls
|
|
|
|
JendaLinda
|
|
spider-mario
it would be, if people used BMP
|
|
2024-01-31 10:56:58
|
Windows is littered with BMPs, the clipboard uses it as well.
|
|
2024-01-31 10:57:40
|
BMP can be top-down if negative height is specified, that's one way how to fix it.
|
|
|
username
|
2024-01-31 12:01:25
|
about to post this to the 2024 WPT interop issue for JPEG XL before it closes
|
|
2024-01-31 12:02:49
|
originally there was a lot more I wanted to say besides just a list of pre-existing websites for testing but I ended up putting it off until the last second
|
|
2024-01-31 12:13:44
|
I was gonna have a whole list showing what support for JPEG XL was like between browsers implementations currently however I didn't since there's a bunch of unknowns with WebKit especially since support for JXL seems to differ between platforms including ones restricted between Apple devices
|
|
2024-01-31 12:16:56
|
other thing I had planned to bring up was some under advertised features of JXL such as having the best worlds of both lossy and lossless in a single image with the use of patches or that JXL could function as a full replacement for stuff like HashBlur/ThumbHash rather then compliment it
|
|
|
username
other thing I had planned to bring up was some under advertised features of JXL such as having the best worlds of both lossy and lossless in a single image with the use of patches or that JXL could function as a full replacement for stuff like HashBlur/ThumbHash rather then compliment it
|
|
2024-01-31 12:19:56
|
although I guess one of the reasons stuff like this isn't really advertised is because libjxl don't really take full advantage of patches yet and also doesn't do very very low res previews yet
|
|
|
HCrikki
|
2024-01-31 01:40:37
|
ladybird's development moved into serenityos' main trunk. its crossplatform and shows browser dev isnt only ruinous big boy play
|
|
2024-01-31 01:57:05
|
about site support, afaik pict-rs starting recently released v5 decodes jxl by default. feels meaningful given this library is part of Lemmy-powered reddit clones. anyone looked into how well it works?
|
|
|
Quackdoc
|
2024-01-31 02:04:23
|
a few people have tested jxl and it seems to work fine with lemmy, iirc pict-rs uses imagemagick for support
|
|
|
|
Lucas Chollet
|
2024-01-31 02:12:40
|
If you mentioned Ladybird because of the comment about WPT. There is some, but support for JPEGXL is far from good
|
|
|
|
Traneptora
|
|
Traneptora
in other news, I'm starting work on better Exif handling in avcodec
|
|
2024-02-01 01:39:27
|
> https://github.com/Traneptora/FFmpeg/commits/exif-overhaul/
|
|
2024-02-01 01:39:31
|
if anyone wants to take a look
|
|
2024-02-01 01:39:38
|
and or a test
|
|
|
JendaLinda
BMP can be top-down if negative height is specified, that's one way how to fix it.
|
|
2024-02-01 03:42:37
|
that actually works?
|
|
2024-02-01 03:42:45
|
huh
|
|
2024-02-01 03:43:04
|
for the ffmpeg libjxl wrapper the way I fixed it not supporting negative linesizes is I set the orientation header to flip_vertical
|
|
2024-02-01 03:43:23
|
and take the absolute value of the linesize
|
|
2024-02-01 07:08:26
|
Does anyone have the original `sunset.jxl`? The one used as a backdrop for the conformance sunset_logo
|
|
|
|
username
|
|
Traneptora
Does anyone have the original `sunset.jxl`? The one used as a backdrop for the conformance sunset_logo
|
|
2024-02-01 07:11:28
|
doing a search on my drives I apparently downloaded these at some point back in 2021
|
|
2024-02-01 07:11:53
|
hopefully this is what you are looking for
|
|
|
|
Traneptora
|
|
username
doing a search on my drives I apparently downloaded these at some point back in 2021
|
|
2024-02-01 07:12:08
|
they are not, those are animated JXLs
|
|
2024-02-01 07:12:35
|
a video rendering of them is right below them if you find the messages where they appear in <#824000991891554375>
|
|
2024-02-01 07:12:51
|
the OG sunset is much smaller than 6k
|
|
2024-02-01 07:13:03
|
it's less than 200 bytes iirc
|
|
|
Traneptora
a video rendering of them is right below them if you find the messages where they appear in <#824000991891554375>
|
|
2024-02-01 07:13:37
|
(I know this because me finding those animated JXLs is what prompted me to ask the original question)
|
|
|
|
username
|
2024-02-01 07:15:17
|
https://discord.com/channels/794206087879852103/824000991891554375/1013130706777542772 ?
|
|
|
|
Traneptora
|
2024-02-01 07:17:12
|
yea that, ty
|
|
2024-02-01 07:17:16
|
I asked in the past but forgot to save it
|
|
2024-02-01 07:20:28
|
huh, this is a fun file
|
|
2024-02-01 07:20:41
|
it's got one frame that is size 2048x1024 that starts at (-224, -224)
|
|
2024-02-01 07:20:57
|
it's antitransposed
|
|
2024-02-01 07:21:25
|
there's only one cluster in the modular stream and one transform, RCT
|
|
2024-02-01 07:21:49
|
I should take apart the MA tree
|
|
|
|
JendaLinda
|
|
Traneptora
that actually works?
|
|
2024-02-01 07:43:10
|
It does, see the description of BITMAPINFOHEADER
|
|
|
|
Traneptora
|
2024-02-01 07:44:21
|
to wikipedia
|
|
|
|
afed
|
2024-02-01 03:04:24
|
<:Poggers:805392625934663710>
https://github.com/libjxl/libjxl/pull/3228
|
|
|
|
veluca
|
|
afed
<:Poggers:805392625934663710>
https://github.com/libjxl/libjxl/pull/3228
|
|
2024-02-01 04:25:22
|
please test it 😄
|
|
|
|
afed
|
2024-02-01 04:28:59
|
streaming should work for all efforts, even for e9?
|
|
|
gb82
|
2024-02-01 06:03:39
|
https://github.com/web-platform-tests/interop/issues/430#issuecomment-1921864485
Welp
|
|
|
|
veluca
|
|
afed
streaming should work for all efforts, even for e9?
|
|
2024-02-01 06:05:52
|
no no just to 6
|
|
2024-02-01 06:06:00
|
or maybe 7
|
|
|
lonjil
|
|
gb82
https://github.com/web-platform-tests/interop/issues/430#issuecomment-1921864485
Welp
|
|
2024-02-01 06:08:45
|
fairly predictable outcome
|
|
|
|
veluca
|
|
lonjil
fairly predictable outcome
|
|
2024-02-01 06:12:54
|
indeed
|
|
|
|
jonnyawsom3
|
2024-02-01 06:15:52
|
Who would've guessed the council with Chrome members wouldn't have a unanimous vote for yes
|
|
|
|
afed
|
|
Traneptora
already merged
|
|
2024-02-01 06:16:19
|
```Note: Brotli is more optimized for text rather than generic data,
and should be the preferred format for subtitles. Presently, it is
also more supported on the web.```
talking about brotli and it being preferred format for text
but as already discussed brotli is also a general purpose format, for text it just has an extra built-in dictionary, but for any other data it also has better compression than zstd and much better optimized for streaming data with low memory consumption
and was originally invented for font compression
also started to be used for texture compression with gpu encoding <:Hypers:808826266060193874>
https://gpuopen.com/learn/compressonator-v4-5-improved-brotli-g-compression/
|
|
|
MSLP
|
2024-02-01 06:18:07
|
in this year "codecs interop category" neither JPEG XL, WebM AV1, nor WebM Opus passed
|
|
|
|
Traneptora
|
|
afed
```Note: Brotli is more optimized for text rather than generic data,
and should be the preferred format for subtitles. Presently, it is
also more supported on the web.```
talking about brotli and it being preferred format for text
but as already discussed brotli is also a general purpose format, for text it just has an extra built-in dictionary, but for any other data it also has better compression than zstd and much better optimized for streaming data with low memory consumption
and was originally invented for font compression
also started to be used for texture compression with gpu encoding <:Hypers:808826266060193874>
https://gpuopen.com/learn/compressonator-v4-5-improved-brotli-g-compression/
|
|
2024-02-01 06:18:35
|
>for any other data it also has better compression
this is not entirely true, it depends on the type of data
|
|
2024-02-01 06:18:48
|
however, I'm not the designer of AVTransport
|
|
2024-02-01 06:18:53
|
you'd have to take it up with Lynne
|
|
|
|
jonnyawsom3
|
|
MSLP
in this year "codecs interop category" neither JPEG XL, WebM AV1, nor WebM Opus passed
|
|
2024-02-01 06:19:04
|
We love when companies can't just agree
|
|
|
Traneptora
>for any other data it also has better compression
this is not entirely true, it depends on the type of data
|
|
2024-02-01 06:20:15
|
I used this for some easy benchmarking, and Brotli works very well with web oriented content, but ZSTD is more universal and generally faster
https://bench.nickb.dev/
|
|
|
|
veluca
|
|
I used this for some easy benchmarking, and Brotli works very well with web oriented content, but ZSTD is more universal and generally faster
https://bench.nickb.dev/
|
|
2024-02-01 06:22:56
|
I think the zstd *encoder* is faster and tends to compress better, I am 99% sure the brotli format is more expressive and ought to be able to compress faster 🙂 (the optimal zstd decoder is probably faster than the optimal brotli decoder though, even if zstd cannot really do streaming decoding)
|
|
|
|
_wb_
|
|
Who would've guessed the council with Chrome members wouldn't have a unanimous vote for yes
|
|
2024-02-01 06:23:00
|
Would be interesting to see who voted for and against. Is that documented somewhere or is that secret info?
|
|
|
|
Traneptora
|
2024-02-01 06:23:16
|
how can Zstd not do streamed decoding?
|
|
|
|
veluca
|
|
_wb_
Would be interesting to see who voted for and against. Is that documented somewhere or is that secret info?
|
|
2024-02-01 06:23:38
|
AFAIU it is secret
|
|
|
|
Traneptora
|
2024-02-01 06:23:43
|
the ANS symbols are reordered on encode time
|
|
|
|
veluca
|
2024-02-01 06:23:57
|
IIRC they are reordered on decode time
|
|
|
|
Traneptora
|
2024-02-01 06:24:01
|
oh, huh
|
|
|
|
veluca
|
2024-02-01 06:24:09
|
which is... certainly a choice
|
|
|
|
afed
|
|
Traneptora
you'd have to take it up with Lynne
|
|
2024-02-01 06:27:13
|
yeah, just thought of it again when i saw this update for texture compression
about compression, there are many incorrect tests when brotli is used with limited memory modes vs zstd with much larger dictionary size, then it can be worse, but on average brotli has denser compression (in current implementations), though not for free, due to slower decompression (but it is still very fast speeds for typical use and much faster than lzma for example)
|
|
2024-02-01 06:36:34
|
there are attempts to optimize zstd for streaming and less memory usage and reducing binary size for use as a web standard
but i also think it's not worth it, especially when chrome refuses to add new formats and it would be better to optimize brotli for some fast modes
https://bugs.chromium.org/p/chromium/issues/detail?id=1246971
|
|
|
|
MSLP
|
2024-02-01 06:44:22
|
zstd content-encoding is available behind flag since chrome 118, it's future in chrome doesn't look bad <https://caniuse.com/zstd>
|
|
|
|
afed
|
2024-02-01 06:53:20
|
it's just an experiment that could be removed
and in my opinion adding a new format when there is already a similar one, but with the difference that the new format has a better optimized implementation for some purposes is not a good thing, instead of optimizing the existing one
|
|
2024-02-01 06:57:39
|
it's like adding new incompatible jpeg-like formats with some changes, by using a better encoder like mozjpeg or jpegli and showing that they are better in some cases, instead of making mozjpeg for jpeg without adding new formats
|
|
|
|
jonnyawsom3
|
|
MSLP
zstd content-encoding is available behind flag since chrome 118, it's future in chrome doesn't look bad <https://caniuse.com/zstd>
|
|
2024-02-01 06:59:33
|
It says that, doesn't actually work when I tried, just gave a memory error
|
|
|
|
MSLP
|
2024-02-01 07:02:18
|
on thorium it seems to work, ex. facebook serves svgs with `Content-Encoding: zstd`
|
|
|
afed
it's just an experiment that could be removed
and in my opinion adding a new format when there is already a similar one, but with the difference that the new format has a better optimized implementation for some purposes is not a good thing, instead of optimizing the existing one
|
|
2024-02-01 07:03:28
|
i'm courious if they will ship it, it's planned to ship in v123 according to <https://chromestatus.com/feature/6186023867908096>
|
|
|
|
afed
|
2024-02-01 07:05:15
|
it's just like for jpeg xl, it's not necessarily going to be in any release version
|
|
|
|
lonjil
|
2024-02-01 07:06:58
|
Wasn't it Chrome devs who actually proposed it, though? A bit different, adding an external proposal vs their own.
|
|
|
|
afed
|
2024-02-01 07:19:35
|
i think that might have more impact than who exactly made this proposal
|
|
2024-02-01 07:24:08
|
and i still think adding such a format is very wrong and irrational
maybe it has some benefit in terms of extra costs for optimization and support when zstd is already more optimized (but still much worse for web use), but anyway
|
|
|
|
Traneptora
|
|
veluca
I think the zstd *encoder* is faster and tends to compress better, I am 99% sure the brotli format is more expressive and ought to be able to compress faster 🙂 (the optimal zstd decoder is probably faster than the optimal brotli decoder though, even if zstd cannot really do streaming decoding)
|
|
2024-02-01 07:59:23
|
Brotli's not able to use FSE, is it?
|
|
|
|
veluca
|
2024-02-01 08:01:47
|
nope
|
|
2024-02-01 08:02:02
|
but I would be mildly surprised if that's very relevant for text
|
|
2024-02-01 08:02:10
|
or at least, non-pathological text
|
|
|
|
Traneptora
|
2024-02-01 08:02:41
|
I was under the impression that Brotli worked better for streaming encodes anyway
Zstd's large windows can take advantage of high-compression for things like packages
|
|
|
|
veluca
|
2024-02-01 08:03:09
|
brotli can do large window too (it is somewhat of an extension though)
|
|
|
|
Traneptora
|
2024-02-01 08:05:42
|
does brotli actually compress large software packages better than Zstd though
|
|
|
|
veluca
|
2024-02-01 08:08:35
|
I *think* the answer is yes if you do `-11`
|
|
|
|
Traneptora
|
2024-02-01 08:09:25
|
Arch defaults to `--ultra -20`
|
|
2024-02-01 08:09:34
|
hm
|
|
2024-02-01 08:09:44
|
I'd have to do some benching
|
|
|
|
veluca
|
2024-02-01 08:10:12
|
it would take *a while* to encode though
|
|
|
|
afed
|
2024-02-01 08:10:52
|
yeah, with a large window, but with like ~2x slower decoding (but it's still fast) as i remember when i tested
|
|
|
|
veluca
|
2024-02-01 08:10:53
|
according to https://quixdb.github.io/squash-benchmark/, it gets pretty close to zpaq & friends
|
|
|
|
Traneptora
|
2024-02-01 08:11:19
|
one of the reasons arch switched from xz to Zstd was the decode speed
|
|
|
|
_wb_
|
2024-02-01 08:13:17
|
Are there any GPU or other very parallelized algorithms for doing lz77 matching? Could be useful for faster / more exhaustive encoding in brotli/gzip (and even lossless jxl for some kinds of images)
|
|
2024-02-01 08:13:49
|
Because that's the main bottleneck for encoding, right?
|
|
|
|
veluca
|
|
_wb_
Are there any GPU or other very parallelized algorithms for doing lz77 matching? Could be useful for faster / more exhaustive encoding in brotli/gzip (and even lossless jxl for some kinds of images)
|
|
2024-02-01 08:13:53
|
if you want to be exhaustive, do suffix arrays 😛
|
|
|
|
Traneptora
|
2024-02-01 08:14:01
|
other than breaking the data up into several chunks right
|
|
|
|
afed
|
|
Traneptora
one of the reasons arch switched from xz to Zstd was the decode speed
|
|
2024-02-01 08:14:01
|
but, lzma is about 10-15x slower than zstd, brotli just about 2-2.5x for slower modes
|
|
|
|
Traneptora
|
2024-02-01 08:14:14
|
sure, I'm just saying that's why it happened
|
|
|
|
veluca
|
|
Traneptora
one of the reasons arch switched from xz to Zstd was the decode speed
|
|
2024-02-01 08:14:16
|
also according to squash, the ... yeah what <@1034873369314730065> said
|
|
|
|
Traneptora
|
2024-02-01 08:14:34
|
I'm not arguing in favor of either brotli or Zstd here
|
|
2024-02-01 08:14:37
|
I just don't have enough data
|
|
2024-02-01 08:14:44
|
I just know that's why Arch switched from xz to Zstd
|
|
2024-02-01 08:15:03
|
xz is slow to decompress, this is known
|
|
2024-02-01 08:15:09
|
and bzip2 is insanely slow to decompress
|
|
2024-02-01 08:15:18
|
which is why nobody uses it anymore
|
|
|
|
afed
|
|
afed
but, lzma is about 10-15x slower than zstd, brotli just about 2-2.5x for slower modes
|
|
2024-02-01 08:15:32
|
and given that zstd is much, much more optimized
|
|
|
|
Traneptora
|
2024-02-01 08:15:49
|
one major issue with XZ is a lack of a spec
|
|
2024-02-01 08:16:05
|
the xz container format has a spec but lzma2 itself is outside the scope of it
|
|
2024-02-01 08:19:12
|
https://sourceforge.net/p/sevenzip/discussion/45797/thread/09814bb2/?limit=25#d81a
|
|
2024-02-01 08:19:15
|
this is as good as I've found
|
|
2024-02-01 08:19:19
|
and it was by deliberately asking
|
|
2024-02-01 08:19:25
|
(14 years ago)
|
|
|
|
afed
|
|
Traneptora
I just know that's why Arch switched from xz to Zstd
|
|
2024-02-01 08:19:29
|
for arch it might be reasonable, because zstd is updated quite often and has active developers, it is also highly "advertised" and it's not a big deal to change formats
but I'm mostly unhappy when some new format is added to browsers, where it's not so easy to avoid fragmentation or remove this format in the future
especially when there is already a very similar format
just not with the most optimized implementation
|
|
|
|
lonjil
|
2024-02-01 08:20:49
|
I've heard from a lot of people that zstd is much more actively developed, is nicer to integrate with stuff, and adds stuff users need more actively, than Brotli.
|
|
|
|
_wb_
|
2024-02-01 08:21:14
|
Anything based on content negotiation is not really a problem imo. Servers that hardcoded assume something like zstd or br is supported by the UA are just bad servers.
|
|
2024-02-01 08:24:25
|
So I don't really see why not just support both, can always remove something again if needed. Nothing that is doing things correctly should break when removing it again.
|
|
2024-02-01 08:25:36
|
(same with new image/video formats btw, if you assume people who use new formats without fallbacks are just doing it wrong, which they are)
|
|
|
|
spider-mario
|
|
lonjil
I've heard from a lot of people that zstd is much more actively developed, is nicer to integrate with stuff, and adds stuff users need more actively, than Brotli.
|
|
2024-02-01 08:27:52
|
for what it’s worth, from writing two very small command-line tools to test the streaming capabilities of brotli and zstd, I found the experience with brotli a bit more pleasant
|
|
2024-02-01 08:28:02
|
from what I recall, the API seemed a bit more straightforward
|
|
|
|
lonjil
|
2024-02-01 08:28:10
|
I see
|
|
|
|
spider-mario
|
2024-02-01 08:28:42
|
the main drawback I remember was that its documentation, while good, wasn’t offered as a simple webpage, unlike zstd’s
|
|
2024-02-01 08:29:11
|
so it was a bit more effort to find it
|
|
|
|
afed
|
2024-02-01 08:31:19
|
fragmentation is not as bad as for images or video, but still, browsers already have support for multiple compression formats and many of which have faster and more optimized implementations than the built-in ones
my point was more that it would be better to improve encoders and decoders for the current format, rather than adding a new one because it has a more optimized implementation, but not better as format capabilities (and in many cases even worse for the web)
|
|
|
|
lonjil
|
2024-02-01 08:32:06
|
I'm looking forward to when the AVIF spec includes AV1, AV2, AV3, AV4...
|
|
|
|
spider-mario
|
2024-02-01 08:41:07
|
JPEG XL…
|
|
|
|
lonjil
|
2024-02-01 08:45:05
|
ah, yes, AVIF5: now allows JXL codestreams in the AVIF container
|
|
|
|
jonnyawsom3
|
2024-02-01 08:46:00
|
Introducing A, for All things you could want in a file
|
|
|
|
_wb_
|
|
afed
fragmentation is not as bad as for images or video, but still, browsers already have support for multiple compression formats and many of which have faster and more optimized implementations than the built-in ones
my point was more that it would be better to improve encoders and decoders for the current format, rather than adding a new one because it has a more optimized implementation, but not better as format capabilities (and in many cases even worse for the web)
|
|
2024-02-01 08:56:02
|
I agree that stuff like mozjpeg or jpegli (getting the most out of an existing format) is nice, and I agree that if brotli is already there, it's not at all clear if zstd really brings something new to the table.
|
|
2024-02-01 08:58:23
|
In the end, any format is only as good as the best easily available encoder for it
|
|
|
|
jonnyawsom3
|
2024-02-01 08:58:49
|
Part of the reason I assumed is because zstd is more widespread as a system library, being the main option for Linux filesystem compression even (As far as I'm aware)
|
|
|
|
Traneptora
|
|
_wb_
Are there any GPU or other very parallelized algorithms for doing lz77 matching? Could be useful for faster / more exhaustive encoding in brotli/gzip (and even lossless jxl for some kinds of images)
|
|
2024-02-01 09:05:52
|
I think the overhead of spinning up a hardware encoder is probably not worth it for web streams that come in bursts
|
|
2024-02-01 09:06:30
|
making it more parallelizable for cpus makes sense, but gpu stuff probably not
|
|
2024-02-01 09:06:59
|
especially considering that many datacenters don't actually have gpus to delegate to servers
|
|
2024-02-01 09:07:24
|
delegating gpus to a qemu instance is nontrivial
|
|
|
|
afed
|
2024-02-01 09:10:31
|
sometimes fpga is used for generic compression, but gpus mostly for images, video and some processing
|
|
|
|
_wb_
|
|
Traneptora
I think the overhead of spinning up a hardware encoder is probably not worth it for web streams that come in bursts
|
|
2024-02-01 09:34:43
|
Agreed, for on the fly streaming encode this is not a good idea. But maybe for something like packaging distros it could be worth the trouble.
|
|
|
|
Traneptora
|
2024-02-01 09:36:35
|
Distros encode packages enough that they can effect parallelize by doing several at once, right?
|
|
|
|
_wb_
|
2024-02-01 09:41:30
|
I mean, if it's encode-once serve-many-times (unlike e.g. serving html which is usually dynamic), you might want to be more exhaustive in the encode and then maybe some super expensive GPU-based very exhaustive search might be worth it.
|
|
2024-02-01 09:43:39
|
Assuming there is some way to do zopfli-like very expensive encoding faster if you just throw more parallelism at it, like something that can run on GPU/TPU.
|
|
2024-02-01 09:44:26
|
(since you probably still don't want new packages to take a few days to compress)
|
|
|
|
veluca
|
2024-02-01 09:53:49
|
brotli -11 is already "zopfli-like"
|
|
2024-02-01 09:54:15
|
ought to be parallelizable for the most part though
|
|
|
|
jonnyawsom3
|
2024-02-01 10:01:27
|
I feel obliged to mention ECT, being a much faster version of zopfli at it's core
|
|
|
|
afed
|
|
veluca
please test it 😄
|
|
2024-02-01 10:32:43
|
i think it will be useful to see in cli stats when streaming compression works
for example
`Encoding [Modular, streaming, lossless, effort: 5]`
or
`Encoding [Modular, lossless, effort: 5, streaming input, streaming output]`
|
|
|
|
veluca
|
2024-02-01 10:34:32
|
good point
|
|
2024-02-01 10:34:40
|
can I get an issue? or I'll forget for sure
|
|
|
|
afed
|
2024-02-01 10:34:41
|
and how to disable streaming if it's the default? <:kekw:808717074305122316>
|
|
|
|
veluca
|
2024-02-01 10:34:54
|
... good question xD
|
|
|
|
afed
|
2024-02-01 10:42:00
|
other than that, on some of my images it works, i didn't notice any difference, maybe less memory, but for comparison at least i need settings to disable streaming
|
|
|
|
veluca
|
2024-02-01 10:50:50
|
you can go a few commits before
|
|
2024-02-01 10:50:50
|
😛
|
|
|
|
Traneptora
|
2024-02-01 10:59:33
|
so update in my Exif endeavor
|
|
2024-02-01 11:00:20
|
TIL
|
|
2024-02-01 11:00:21
|
> Most vendors write the makernote in TIFF format, i.e., in the same format as the rest of the Exif information is encoded. This appears to be a sensible thing at first glance. Unfortunately, in general it means that any change of an Exif tag, which moves the makernote field, will corrupt it.
|
|
2024-02-01 11:00:48
|
so apparently my code to extract EXIF from tiff files treats MakerNote as a binary blob
|
|
2024-02-01 11:01:07
|
so now I gotta go revise it :p
|
|
|
|
JKGamer69
|
2024-02-02 12:38:04
|
Does jpeg xl support YUV?
|
|
|
|
jonnyawsom3
|
2024-02-02 01:05:00
|
Still trying to get lossless video frames?
|
|
|
|
w
|
2024-02-02 01:09:23
|
XYB is a yuv
|
|
|
|
Quackdoc
|
2024-02-02 01:22:56
|
isn't xyb an lms based colorspace?
|
|
|
|
w
|
2024-02-02 01:37:16
|
yuv like color model
|
|
2024-02-02 01:39:39
|
<:trollface:834012731710505011>
|
|
|
yurume
|
|
_wb_
Are there any GPU or other very parallelized algorithms for doing lz77 matching? Could be useful for faster / more exhaustive encoding in brotli/gzip (and even lossless jxl for some kinds of images)
|
|
2024-02-02 01:54:19
|
I don't know about specifics but Intel QAT does a hardware acceleration of LZ77 matching (and additional direct support for DEFLATE): https://github.com/intel/QATzip
|
|
|
|
_wb_
|
|
JKGamer69
Does jpeg xl support YUV?
|
|
2024-02-02 06:19:06
|
Only the exact kind of yuv that is used in JPEG (or rather, in JFIF, to be pedantic)
|
|
2024-02-02 06:19:51
|
(i.e. that specific full-range YCbCr matrix with that specific chroma siting)
|
|
|
|
Traneptora
|
2024-02-02 09:03:01
|
iirc you can't actually ask libjxl to use YCbCr right
|
|
2024-02-02 09:03:21
|
it only does that for jpeg transcodes iirc, since it's just worse than XYB
|
|
|
|
veluca
|
2024-02-02 10:16:43
|
you can give it ycbcr and tell it to encode as such, I *think*
|
|
|
|
Traneptora
|
2024-02-02 10:24:05
|
It's not one of the JXL_COLOR_SPACE options
|
|
|
|
_wb_
|
2024-02-02 11:47:20
|
We had a way to do it before we switched cjxl to use the API. Now there is no way, since the API assumes buffers are RGB (in particular it has no way to pass 4:2:0 data)
|
|
|
yoochan
|
2024-02-02 12:03:46
|
is there wide gamut RGB sensors ? why increase the gamut of the screen if the gamut of the sensor is unchanged ?
|
|
2024-02-02 12:04:18
|
(ok, you could balance your color outside the narrow gamut but still)
|
|
|
|
spider-mario
|
|
Traneptora
iirc you can't actually ask libjxl to use YCbCr right
|
|
2024-02-02 12:13:56
|
theoretically, you can, but the program has to connect to Discord and try to convince us to add it to the API, then it can wait a while and update its copy of libjxl
|
|
2024-02-02 12:14:08
|
the call is long-blocking and may not succeed
|
|
|
Oleksii Matiash
|
|
yoochan
is there wide gamut RGB sensors ? why increase the gamut of the screen if the gamut of the sensor is unchanged ?
|
|
2024-02-02 02:08:29
|
What do you mean by "sensor"?
|
|
|
|
yoochan
|
|
Oleksii Matiash
What do you mean by "sensor"?
|
|
2024-02-02 02:14:34
|
like a camera sensor, bayer matrices uses blue, red and green filters, but is there a link between these filter colors and the three subpixels of sRGB screens ? If we want wide gamut display, shouldn't we have wide gamut cameras ?
|
|
|
|
Oleksii Matiash
|
|
yoochan
like a camera sensor, bayer matrices uses blue, red and green filters, but is there a link between these filter colors and the three subpixels of sRGB screens ? If we want wide gamut display, shouldn't we have wide gamut cameras ?
|
|
2024-02-02 02:18:42
|
Cameras *are* wide gamut, however it is not directly so, because color "appears" in the convertation flow, after color profile and saturation are applied. So I can easily get image that does not fit even in ProPhoto
|
|
2024-02-02 02:19:24
|
Do not look on the screenshot colors, my monitor is wide gamut, and screenshots appears in wrong colors
|
|
|
|
yoochan
|
|
Oleksii Matiash
Cameras *are* wide gamut, however it is not directly so, because color "appears" in the convertation flow, after color profile and saturation are applied. So I can easily get image that does not fit even in ProPhoto
|
|
2024-02-02 02:21:31
|
nice ! I wonder if it exists some plot (similar to https://fr.wikipedia.org/wiki/Adobe_RGB#/media/Fichier:CIE1931xy_AdobeRGB.svg ) which place the color of the sensor filters in this La*b representation... if it make sense
|
|
|
|
Oleksii Matiash
|
2024-02-02 02:21:39
|
Image is in ProPhoto, look at the blue channel
|
|
2024-02-02 02:23:21
|
Oh, it did not capture cursor. It is under cyan dot
|
|
|
|
yoochan
|
2024-02-02 02:23:43
|
zero blue 🙂
|
|
|
|
lonjil
|
|
yoochan
is there wide gamut RGB sensors ? why increase the gamut of the screen if the gamut of the sensor is unchanged ?
|
|
2024-02-02 02:28:03
|
I think a good camera should cover the entire human color gamut pretty well.
|
|
|
|
Quackdoc
|
2024-02-02 02:29:45
|
scrgb camera time
|
|
|
|
Oleksii Matiash
|
|
yoochan
like a camera sensor, bayer matrices uses blue, red and green filters, but is there a link between these filter colors and the three subpixels of sRGB screens ? If we want wide gamut display, shouldn't we have wide gamut cameras ?
|
|
2024-02-02 02:33:11
|
And it is often a real pain for me - to see how nice pure colors become dull and often just wrong when I convert them from, for example, adobe rgb to srgb to upload it
|
|
|
|
spider-mario
|
2024-02-02 03:08:21
|
I think some of you might find this interesting: https://www.spiedigitallibrary.org/journals/optical-engineering/volume-59/issue-11/110801/Color-conversion-matrices-in-digital-cameras-a-tutorial/10.1117/1.OE.59.11.110801.full
|
|
2024-02-02 03:09:21
|
but anyway, colours can be made arbitrarily saturated in editing
|
|
|
|
yoochan
|
|
spider-mario
but anyway, colours can be made arbitrarily saturated in editing
|
|
2024-02-02 03:18:41
|
obviously
|
|
2024-02-02 03:19:01
|
the paper is... dense, I bookmark for later
|
|
|
|
Oleksii Matiash
|
|
spider-mario
but anyway, colours can be made arbitrarily saturated in editing
|
|
2024-02-02 03:57:38
|
In case of flowers it is often not necessary to use any oversaturation, they are already a nightmare for srgb
|
|
|
gameplayer55055
|
2024-02-02 09:20:02
|
how to correctly use imagemagick to make HDR jxl images?
|
|
|
|
Traneptora
|
2024-02-02 09:43:10
|
what's the source?
|
|
2024-02-02 09:43:29
|
like what HDR image do you have
|
|
|
|
gameplayer55055
|
2024-02-02 09:46:53
|
HDR or EXR
|
|
2024-02-02 09:47:39
|
ive tried to just do magick image.exr image.jxl but it creates an SDR image
|
|
|
|
spider-mario
|
2024-02-02 09:48:30
|
`tools/exr_to_pq` in libjxl should be of interest
|
|
|
|
gameplayer55055
|
2024-02-02 09:48:52
|
... i use macos and brew
|
|
|
|
spider-mario
|
2024-02-02 09:49:08
|
not necessarily an obstacle
|
|
2024-02-02 09:49:10
|
https://sturmen.github.io/posts/hdr-jpeg-xl-2022/
|
|
|
|
gameplayer55055
|
2024-02-02 09:53:21
|
cmake, oh shi
|
|
2024-02-02 09:53:48
|
I think its better to proceed in WSL2
|
|
|
|
Traneptora
|
|
gameplayer55055
HDR or EXR
|
|
2024-02-02 09:54:32
|
cjxl supports OpenEXR if compiled in
|
|
|
|
gameplayer55055
|
2024-02-02 09:56:21
|
oh i see, that problem is called "safari shows every jxl in sdr"
|
|
2024-02-02 09:56:41
|
converting exr->jxl->exr back shows that everything works, thanks
|
|
|
|
MSLP
|
|
gameplayer55055
oh i see, that problem is called "safari shows every jxl in sdr"
|
|
2024-02-02 10:11:04
|
damn, it would be good if they fixed it. My friend recently started playing with HDR in Adobe Lightroom, and since he's on MacOS i mentioned to him about that he can use JPEG XL for developed HDR images, but was dissapointed to find out that Safari and builtin MacOS system viewer show HDR JXLs in SDR
|
|
|
|
Traneptora
|
2024-02-02 10:55:06
|
I'm currently adding `cLLi` and `mDVc` chunk support to FFmpeg for PNGs
once that gets merged I'll allow the libjxl wrapper in FFmpeg to transfer the CLLI info to/from the toneMapping bundle
|
|
|
|
spider-mario
|
2024-02-02 10:55:08
|
it’s likely that JXLs created directly from EXRs will stay that way, since they’re signalled as being linear rather than PQ or HLG
|
|
|
|
Traneptora
|
2024-02-02 10:55:10
|
should help a lot with HDR support
|
|
|
spider-mario
it’s likely that JXLs created directly from EXRs will stay that way, since they’re signalled as being linear rather than PQ or HLG
|
|
2024-02-02 10:55:46
|
tbh most images that are in Linear Light with a wide gamut are actually HDR
|
|
|
|
spider-mario
|
2024-02-02 10:55:52
|
(and their `intensity_target` is not unlikely to be wrong)
|
|
|
|
Traneptora
|
2024-02-02 10:56:11
|
well `intensity_target` being wrong for linear is something that we can fix
|
|
|
|
spider-mario
|
|
Traneptora
tbh most images that are in Linear Light with a wide gamut are actually HDR
|
|
2024-02-02 10:56:39
|
true, although being wide gamut would have to be detected from the values, since a lot of EXRs use Rec. 709 primaries
|
|
2024-02-02 10:56:56
|
wide gamut is just achieved with <0 and >1 values
|
|
|
|
Traneptora
|
2024-02-02 10:56:56
|
even then, BT.709 primaries in linear light is unlikely to be SDR
|
|
2024-02-02 10:57:36
|
xyb-encoded JXL files can in theory be linear-tagged and SDR but I don't believe any of the current encoders do that
|
|
|
|
spider-mario
|
|
Traneptora
well `intensity_target` being wrong for linear is something that we can fix
|
|
2024-02-02 10:57:50
|
it’s more “wrong for EXRs encoded without analysis of the actual maximum value” than “wrong for linear”
|
|
2024-02-02 10:58:11
|
`cjxl` takes the `whiteLuminance` tag from the input EXR, which represents the luminance of (1, 1, 1)
|
|
2024-02-02 10:58:31
|
it’s correct as the `intensity_target` iff the EXR is normalised accordingly
|
|
2024-02-02 10:58:58
|
but it seems to be that a typical EXR would instead set `whiteLuminance` to, say, 100, and then have values above (1, 1, 1)
|
|
2024-02-02 10:59:08
|
(if it even sets `whiteLuminance` at all)
|
|
2024-02-02 10:59:49
|
if you transform a 0-5 `whiteLuminance=100` EXR into a 0-1 `whiteLuminance=500` one, that solves the issue
|
|
2024-02-02 11:00:29
|
(or if `libjxl/lib/extras/dec/exr.cc` did that automatically through a preliminary analysis pass)
|
|
|
|
Quackdoc
|
|
Traneptora
tbh most images that are in Linear Light with a wide gamut are actually HDR
|
|
2024-02-02 11:00:52
|
scRGB my beloved
|
|
|
|
spider-mario
|
2024-02-02 11:02:22
|
(but then, an exr->jxl->exr roundtrip would not have the same scale)
|
|
|
|
Traneptora
|
|
Traneptora
I'm currently adding `cLLi` and `mDVc` chunk support to FFmpeg for PNGs
once that gets merged I'll allow the libjxl wrapper in FFmpeg to transfer the CLLI info to/from the toneMapping bundle
|
|
2024-02-02 11:25:20
|
It's not a major change. mostly just nobody did it yet
|
|
2024-02-02 11:25:22
|
https://github.com/Traneptora/FFmpeg/commits/png-clli/
|
|
|
|
gameplayer55055
|
|
MSLP
damn, it would be good if they fixed it. My friend recently started playing with HDR in Adobe Lightroom, and since he's on MacOS i mentioned to him about that he can use JPEG XL for developed HDR images, but was dissapointed to find out that Safari and builtin MacOS system viewer show HDR JXLs in SDR
|
|
2024-02-02 11:35:06
|
YES. Photoshop camera raw can do jpeg xl, but it's still not complete support, but only camera raw.
Also I like how krita deals with HDR, but it works only on windows, when i choose rec2020 krita crashes in macos
HDR + JXL = 2 new exotic things = a disaster
|
|
2024-02-02 11:38:47
|
exr works the best
|
|
|
|
MSLP
|
2024-02-02 11:39:52
|
but is taking the most diskspace 😦
|
|
|
|
gameplayer55055
|
|
MSLP
but is taking the most diskspace 😦
|
|
2024-02-02 11:45:39
|
Yes, that sucks
|
|
2024-02-02 11:46:20
|
feels like it's almost TIFF 😱
|
|
|
|
JKGamer69
|
|
_wb_
Only the exact kind of yuv that is used in JPEG (or rather, in JFIF, to be pedantic)
|
|
2024-02-03 12:48:03
|
What about YUV 4:2:0, 4:2:2, and 4:4:4?
|
|
|
|
Traneptora
|
2024-02-03 01:35:58
|
Ah, this is the chatbot posting on reddit
|
|
2024-02-03 01:36:55
|
Didn't realize they were automated until they posted the same question verbatim
|
|
|
|
_wb_
|
|
gameplayer55055
oh i see, that problem is called "safari shows every jxl in sdr"
|
|
2024-02-03 08:09:54
|
Safari shows every image in SDR, not just jxl. It does the same thing with HDR avif or png or jpeg or j2k.
|
|
|
JKGamer69
What about YUV 4:2:0, 4:2:2, and 4:4:4?
|
|
2024-02-03 08:12:49
|
JXL supports 444, 420, 422 and 440, i.e. anything that is at most 2x subsampled in either direction. That covers nearly all JPEG files you'll find in practice (though in principle you can also do weird stuff like 3x subsampling in JPEG).
|
|
|
MSLP
damn, it would be good if they fixed it. My friend recently started playing with HDR in Adobe Lightroom, and since he's on MacOS i mentioned to him about that he can use JPEG XL for developed HDR images, but was dissapointed to find out that Safari and builtin MacOS system viewer show HDR JXLs in SDR
|
|
2024-02-03 08:14:37
|
Safari and Preview show only SDR, however the Photos app does show HDR jxl properly, so deep down Apple knows how to do it 🙂
|
|
|
|
gameplayer55055
|
|
_wb_
Safari and Preview show only SDR, however the Photos app does show HDR jxl properly, so deep down Apple knows how to do it 🙂
|
|
2024-02-03 09:35:03
|
Hmmm. Need to give it a try
|
|
2024-02-03 09:37:51
|
photos app shows sdr for me
|
|
2024-02-03 09:38:27
|
oh wait, it shows HDR
|
|
2024-02-03 09:38:33
|
|
|
2024-02-03 09:38:41
|
using that image for testing
|
|
|
|
MSLP
|
|
_wb_
Safari and Preview show only SDR, however the Photos app does show HDR jxl properly, so deep down Apple knows how to do it 🙂
|
|
2024-02-03 11:56:35
|
That might've been the apple cloud client then which shown SDR; on his phone it behaved odd too, where zooming on image also switched to SDR. In general it wasn't consistent across ecosystem.
|
|
|
|
JKGamer69
|
2024-02-03 01:22:43
|
How do I losslessly compress JXL files into a pdf file without losing quality?
|
|
|
|
w
|
2024-02-03 01:24:33
|
very carefully
|
|
|
|
spider-mario
|
2024-02-03 01:29:35
|
you’ve already asked that in the past
|
|
2024-02-03 01:30:06
|
until Adobe adds JPEG XL to PDF, one must decompress the JPEG XL files and put the resulting decompressed files (PNG, or JPEG if the JXLs are losslessy-recompressed JPEGs) in a PDF
|
|
2024-02-03 01:31:09
|
(PNG would also work in the latter case but it would be wasteful)
|
|
|
|
Quackdoc
|
2024-02-03 01:38:33
|
speaking of compressing a series of photos, I wonder if it would be viable to optimize the encoder to encode JXL files in a way that would make it conducive to compressing a bunch of them into a single file. currently when compressing image sets of similar images, me and a few other guys typically use BMP + lzma2.
|
|
|
|
Traneptora
|
2024-02-03 04:32:55
|
someone's probably having fun with ChatGPT
|
|
|
|
JendaLinda
|
2024-02-03 04:35:56
|
As VarDCT always stores pixels in 32bit float no matter what, is it the case for lossless Modular as well? Or does it use appropriately sized unsigned integers? After all, Modular can losslessly store values from 1 to 24 bits in size.
|
|
|
|
Traneptora
|
2024-02-03 04:37:55
|
VarDCT doesn't store floats at all
|
|
2024-02-03 04:38:12
|
internally, libjxl uses floats to calculate the coefficients
|
|
2024-02-03 04:38:23
|
but each Varblock has an "HF Multiplier" associated with it
|
|
2024-02-03 04:38:49
|
and the actual entropy-coded stream of HF coefficients stores integers
|
|
2024-02-03 04:39:00
|
which are then divided by the HF Multiplier on decode to obtain the real number value
|
|
2024-02-03 04:40:03
|
but to answer your original question, Modular is a way to store rectangular integer arrays
if you encode an 8-bit image losslessly with libjxl it will just use modular to store those 0-255 values
|
|
2024-02-03 04:41:05
|
do keep in mind that by spec, the values from modular are normalized to be in the 0.0 to 1.0 range, and then rescaled afterward by the image's bit depth. this has no effect in practice unless modular frames and vardct frames are blended together
|
|
|
|
JendaLinda
|
2024-02-03 04:44:12
|
By normalization, the values are turned into floats, aren't they?
|
|
2024-02-03 04:46:10
|
For 8bit, it is division by 255.0
|
|
|
|
_wb_
|
2024-02-03 04:47:34
|
Modular works on int32 in libjxl. It can store float32 losslessly by bitcasting it to int32 and encoding that.
|
|
|
|
Traneptora
|
|
JendaLinda
For 8bit, it is division by 255.0
|
|
2024-02-03 04:51:58
|
yes, and then multiplied by 255.0
in practice, libjxl skips this step entirely if there's nothing to frame-blend
|
|
2024-02-03 04:52:15
|
keep in mind that the spec doesn't specify anything to do with floating-point numbers, it only specifies anything about real numbers
|
|
2024-02-03 04:52:30
|
floating points are just an implementation detail
|
|
2024-02-03 04:52:54
|
everything in the spec either pertains to integers or real numbers
|
|
|
|
JendaLinda
|
2024-02-03 04:53:24
|
I see now. Thank you.
|
|
|
_wb_
Modular works on int32 in libjxl. It can store float32 losslessly by bitcasting it to int32 and encoding that.
|
|
2024-02-03 04:54:43
|
Just for curiosity, values smaller than int32 are padded with zeros of is there any scaling?
|
|
|
|
Traneptora
|
2024-02-03 04:55:01
|
integers themselves are entropy-coded
|
|
2024-02-03 04:55:41
|
for each sample in a modular stream, there's a predicted integer, and the actual coded value
|
|
2024-02-03 04:55:53
|
the difference between the prediction and the value is what's entropy-encoded
|
|
2024-02-03 04:56:30
|
the value to be entropy-encoded is a 32-bit signed integer but because of the way entropy coding works it'll end up a lot smaller than that in the compressed bitstream
|
|
|
|
_wb_
|
|
JendaLinda
Just for curiosity, values smaller than int32 are padded with zeros of is there any scaling?
|
|
2024-02-03 04:59:10
|
Just the usual msb padding. Spec-wise it's just integer numbers, you can implement it with int16 if you want (for 8-bit or even 12-bit images)
|
|
|
|
yurume
|
2024-02-03 05:00:59
|
not only it's just an integer number, but (technically) it can be an arbitrarily-sized integer. of course the spec guards against the maximum integer ever used in the bitstream, but does allow for a coding configuration that *can* encode a very large integer as long as that integer is never used.
|
|
|
|
JendaLinda
|
2024-02-03 05:02:31
|
That makes sense.
|
|
2024-02-03 05:06:16
|
And one more thing I've noticed, 16 bit Modular will use the container. Couldn't bare code stream do?
|
|
|
|
Traneptora
|
2024-02-03 05:13:22
|
if you don't need any features of the container, libjxl won't use it by default, iirc
|
|
|
|
_wb_
|
2024-02-03 05:16:56
|
Actually 16-bit lossless is not possible in Main profile, Level 5, since Level 5 can be implemented using int16 and uint16 doesn't fit in int16.
And if you need something other than Main profile Level 5, you need a container to signal the profile/level.
|
|
|
|
Traneptora
|
2024-02-03 05:17:57
|
ah, right
|
|
2024-02-03 05:18:30
|
could you in theory do 16-bit lossless with level5 by biasing the uint16 into int16
|
|
2024-02-03 05:18:43
|
or reinterpret-casting the uint16 as int16
|
|
2024-02-03 05:19:33
|
I suppose to bias it you'd have to have a constant 0x8000 frame with kAdd on top of the original frame
|
|
2024-02-03 05:20:00
|
which in theory can be done but it seems like a pointless computation exercise
|
|
|
|
JendaLinda
|
2024-02-03 05:21:47
|
I'd say platforms supporting just int16 would be quite underpowered.
|
|
|
|
Traneptora
|
2024-02-03 05:29:02
|
hm?
|
|
2024-02-03 05:30:00
|
there's a flag in the header that says "modular mode uses 16 bit buffers" that is required to be true for level5 codestreams, but can be false for level10
|
|
2024-02-03 05:30:03
|
currently there's no level5-only decoders
|
|
2024-02-03 05:30:20
|
libjxl reads the flag to know if it needs to allocate a 32-bit or a 16-bit buffer
|
|
2024-02-03 05:30:32
|
but then it just uses that
|
|
2024-02-03 05:30:51
|
jxlatte ignores the flag and allocates a 32-bit buffer in all cases
|
|
2024-02-03 05:31:10
|
(because 16-bit arithmetic is not any faster than 32-bit arithmetic on the jvm)
|
|
2024-02-03 05:31:29
|
I don't know what jxl-oxide does
|
|
|
|
JendaLinda
|
2024-02-03 05:32:12
|
I see the only advantage of int16 is to save memory.
|
|
2024-02-03 05:40:21
|
So in principe the level can be determined from the codestream itself.
|
|
|
Soni
|
2024-02-03 06:30:39
|
has anyone made an 88x31 JXL?
|
|
|
|
username
|
|
Soni
has anyone made an 88x31 JXL?
|
|
2024-02-03 06:42:19
|
? like this? or what are you specifically asking?
|
|
2024-02-03 06:46:23
|
ohhh wait are you asking if anyone has made a old web style 88x31 banner for JPEG XL?
|
|
2024-02-03 06:49:34
|
there's one that exists on this site https://saklistudio.com/ which has a few 88x31 banners but the JXL one is white when served as a PNG and colored when served as a JXL
|
|
2024-02-03 06:52:14
|
oh also there's an animated one present here https://embed.moe/
|
|
|
|
Soni
|
2024-02-03 07:18:43
|
yeah it'd be cool to have a copyright free one tho
|
|
|
|
Traneptora
|
|
JendaLinda
I see the only advantage of int16 is to save memory.
|
|
2024-02-03 10:40:40
|
not just memory. if you have 16-bit buffers you can take advantage of 16-bit integer operations with vector instructions
|
|
2024-02-03 10:42:42
|
for example, PADDW lets you add packed 16-bit integers together (this is an SSE2 instruction)
|
|
2024-02-03 10:42:58
|
with 16-bit integers you can fit 8 of them in a 128-bit vector register
|
|
2024-02-03 10:43:15
|
32-bit integers would need the PADDD instruction, which can fit four in a 128-bit vector register
|
|
|
JendaLinda
So in principe the level can be determined from the codestream itself.
|
|
2024-02-03 10:45:33
|
not quite
the level is specified by the container, in a `jxll` box
|
|
2024-02-03 10:45:49
|
naked codestreams are assumed to be level 5
|
|
|
|
JendaLinda
|
2024-02-03 10:48:21
|
Alright, that's fair.
|
|
|
|
Traneptora
|
2024-02-03 10:49:04
|
a naked codestream that uses level 10 features is invalid
|
|
2024-02-03 10:49:20
|
although atm none of the current decoders verify level compliance
|
|
|
|
JendaLinda
|
2024-02-03 10:55:43
|
Also it seems that jxll is present only in level10 files.
|
|
|
|
lonjil
|
2024-02-03 11:44:17
|
That's weird
|
|
|
|
Traneptora
|
|
JendaLinda
Also it seems that jxll is present only in level10 files.
|
|
2024-02-03 11:52:28
|
if it's not present codestreams are assumed to be level 5
|
|
2024-02-03 11:52:33
|
so they don't bother to write it, most likely
|
|
|
|
JendaLinda
|
|
_wb_
Modular works on int32 in libjxl. It can store float32 losslessly by bitcasting it to int32 and encoding that.
|
|
2024-02-04 07:37:03
|
Casting 32 bit float to int32 is a neat trick.
Integer bit depth seems to be limited to 24 bits in libjxl. Is there any technical reason for that?
|
|
|
|
Traneptora
|
2024-02-04 07:38:28
|
it's not particularly clear to me why libjxl doesn't have JXL_TYPE_INT32 as one of its data types
|
|
2024-02-04 07:39:39
|
JXL_TYPE_UINT32 used to exist but it was removed
|
|
2024-02-04 07:39:50
|
I don't know why
|
|
2024-02-04 07:40:29
|
https://github.com/libjxl/libjxl/commit/b90ba633a7ac419f24115e4f623ac400d89d0e23
|
|
2024-02-04 07:41:58
|
the logic given was that the max size was int32_t, not uint32_t
|
|
2024-02-04 07:42:01
|
(in the PR)
|
|
2024-02-04 07:42:37
|
but atm you can't losslessly compress a 32-bit integer EXR, for example without reinterpret-casting to float and then telling libjxl to be lossless, which internally reintepret-casts back to int32
|
|
|
|
JendaLinda
|
2024-02-04 08:06:36
|
That's what I thought, uint32 can be casted to int32 the same way as float32 is.
|
|
|
|
Traneptora
|
2024-02-04 08:07:18
|
one issue is that for unsigned integers greater than 0x80000000, it wraps around, and distorts the predictors
|
|
|
|
JendaLinda
|
2024-02-04 08:08:44
|
Sure but I suppose predictors don't work that well for casted floats either.
|
|
|
|
Traneptora
|
2024-02-04 08:09:16
|
for example, consider 0x7F000000 - 0x80000000. This difference is `-0x1000000` when treated as unsigned integers, but when treated as signed integers, it's 0xFEFFFFFF
|
|
2024-02-04 08:09:26
|
this can cause wraparound issues
|
|
2024-02-04 08:09:37
|
but I agree that it's not that much better when reinterpret-casting floats to ints
|
|
|
|
JendaLinda
|
2024-02-04 08:26:33
|
If lossless modular is considered to be an universal compression method for 2D arrays, IIRC compressing scientific data was one of the proposed use cases, it should definitely support all 8 bit, 16 bit and 32 bit integers, both signed and unsigned.
|
|
|
|
Traneptora
|
2024-02-04 08:27:04
|
the codestream itself can do that
|
|
2024-02-04 08:27:07
|
the library just won't (atm)
|
|
2024-02-04 08:27:35
|
do note that current scientific data is mostly lossless jpeg2000
|
|
2024-02-04 08:28:22
|
jpeg2000 supports depths from 1 to 38, so you'd need to do some kind of hacks to compress ultra high bit depth jpeg2000
|
|
2024-02-04 08:28:28
|
but most medical imagery is not higher than 32 bpp
|
|
|
|
_wb_
|
|
JendaLinda
Casting 32 bit float to int32 is a neat trick.
Integer bit depth seems to be limited to 24 bits in libjxl. Is there any technical reason for that?
|
|
2024-02-04 08:31:47
|
Because we want to be able to losslessly convert to float32 and back (for frame blending etc, so we only have to implement that on floats), and that gives you 24 bits of precision.
|
|
|
Traneptora
but most medical imagery is not higher than 32 bpp
|
|
2024-02-04 08:33:49
|
Most medical imagery is 12-bit afaik 🙂
|
|
2024-02-04 08:34:46
|
This j2k limit of 38 bits is kind of weird and inconvenient imo.
|
|
|
190n
|
2024-02-04 08:36:14
|
where does 38 come from? is that integers?
|
|
|
|
Traneptora
|
2024-02-04 08:39:41
|
iirc it's because 40 is a multiple of 8
|
|
2024-02-04 08:39:52
|
and 38 is due to precision loss from a reversible color transform
|
|
2024-02-04 08:40:06
|
Y is defined to be (R + 2G + B) / 4
|
|
2024-02-04 08:40:21
|
so if you have 38-bit integers, you end up with 40-bit coded integers
|
|
2024-02-04 08:40:33
|
which is a full number of bytes
|
|
2024-02-04 08:40:53
|
if you had 32-bit coded integers you'd have 30-bit representable integers
|
|
2024-02-04 08:40:59
|
which was the other alternative
|
|
2024-02-04 08:41:05
|
the full byte requirement is a DICOM requirement
|
|
2024-02-04 08:42:46
|
there may be 2 bits lost elsewhere instead of in the RCT but iirc that's the gist of it
|
|
|
|
_wb_
|
2024-02-04 08:42:55
|
In jxl the transforms are optional, RCT and Squeeze each require an extra bit of precision so if you want to do lossless float32, you have to not do those — though if the numbers are all positive, you could still do one of them.
|
|
|
|
JendaLinda
|
2024-02-04 08:43:17
|
24 bits are kinda unconvenient as well. It's not a native integer size. If data processing, calculations on array of 32 bit values are being done, one might want to just dump the entire array to file.
|
|
|
|
Traneptora
|
2024-02-04 08:43:35
|
24-bit integers keep in mind are the size of the mantissa in an IEEE standard float
|
|
2024-02-04 08:43:50
|
well (23 bit with assumed leading 1)
|
|
2024-02-04 08:44:02
|
any 24-bit integer can be represented perfectly as a float
|
|
2024-02-04 08:44:08
|
but the same is not true for 25-bit integers
|
|
|
|
_wb_
|
2024-02-04 08:44:19
|
The jxl spec allows signalling up to 64-bit, but we currently define things so you can implement everything using floats.
|
|
|
|
Traneptora
|
2024-02-04 08:44:32
|
does it?
|
|
2024-02-04 08:44:50
|
entropy coding involves sending packed signed 32-bit integers
|
|
2024-02-04 08:44:57
|
so all the residuals have to be 32-bits
|
|
|
|
_wb_
|
2024-02-04 08:44:59
|
That header field can have that value, but it's not allowed to use it
|
|
2024-02-04 08:45:35
|
Ah yes, doing the actual encode might be a bit tricky too 🙂
|
|
|
|
Traneptora
|
2024-02-04 08:45:50
|
considering the specification defines entropy in terms of hybrid 32-bit integers
|
|
2024-02-04 08:45:57
|
and disallows anything larger than 32-bit
|
|
2024-02-04 08:46:00
|
yea I'd say it's tricky
|
|
2024-02-04 08:46:01
|
<:kek:857018203640561677>
|
|
|
|
JendaLinda
|
2024-02-04 08:46:18
|
So how it could be allowed in compatible way? Defining another codestream level?
|
|
|
|
Traneptora
|
2024-02-04 08:47:25
|
atm hybrid integers are capped at 32-bits
|
|
2024-02-04 08:47:54
|
```
ReadUint(config, token) {
if (token < config.split) return token;
n = config.split_exponent − config.msb_in_token − config.lsb_in_token +
((token − config.split) >> (config.msb_in_token + config.lsb_in_token));
/* n < 32 */
low = token & ((1 << config.lsb_in_token) − 1);
token = token >> config.lsb_in_token;
token &= (1 << config.msb_in_token) − 1;
token |= (1 << config.msb_in_token);
result = (((token << n) | u(n)) << config.lsb_in_token ) | low;
/* result < (1 << 32) */
return result;
}
```
|
|
2024-02-04 08:48:26
|
in order to make this work, you'd need to relax the requirements on split, msb in token, and lsb in token
|
|
|
|
_wb_
|
2024-02-04 08:49:00
|
If we would want to allow it, we'd probably have to generalize some stuff to allow bigger numbers first, yes. And change the spec to not forbid it in the first place 🙂
|
|
|
|
Traneptora
|
2024-02-04 08:49:24
|
atm, the way split exponents are read is
> `config.split_exponent = u(ceil(log2(log_alphabet_size + 1)));`
the maximum log alphabet size is 15, so config.split_exponent can be at max 15 as well
|
|
|
Dexrn ZacAttack
|
2024-02-04 08:49:28
|
PHP has this as a dependency?
```
==> Installing php dependency: jpeg-xl
==> Downloading https://ghcr.io/v2/homebrew/core/jpeg-xl/manifests/0.9.1
Already downloaded: /Users/Zach/Library/Caches/Homebrew/downloads/0f5e4b24fe774102590ae76c337997de3e38fc965c5694441167cac407924cdd--jpeg-xl-0.9.1.bottle_manifest.json
==> Pouring jpeg-xl--0.9.1.sonoma.bottle.tar.gz
```
|
|
|
|
Traneptora
|
2024-02-04 08:49:52
|
since log2(16) = 4, and `u(4)` caps out at 15
|
|
2024-02-04 08:50:38
|
that being said, the restriction on `n < 32` could be lifted
|
|
2024-02-04 08:50:52
|
but it would require implementations to expect the possibility of 64-bit output
|
|
2024-02-04 08:50:55
|
and could slow things down
|
|
|
|
JendaLinda
|
2024-02-04 08:53:34
|
I guess that's the purpose of codestream levels, so the decoder does not take certain thing into account in the lower levels.
|
|
2024-02-04 08:55:44
|
In addition to avoid less capable decoders to attempt to decode the bitstream.
|
|
|
|
jonnyawsom3
|
|
Quackdoc
speaking of compressing a series of photos, I wonder if it would be viable to optimize the encoder to encode JXL files in a way that would make it conducive to compressing a bunch of them into a single file. currently when compressing image sets of similar images, me and a few other guys typically use BMP + lzma2.
|
|
2024-02-05 04:37:29
|
I remember my amazement when I zipped a few edits of photos together as jpegs and they were only marginally larger than the source file, I can only assume they must've been extremely high quality jpegs for that to have worked so well
|
|
|
|
Traneptora
|
2024-02-05 06:28:05
|
that being said I don't think much of the machinery with JXL is fundamentally incompatible with 64-bit entropy streams
|
|
2024-02-05 06:28:27
|
packed signed integers, for example, pack the sign bit into the least significant bit
|
|
2024-02-06 01:32:05
|
yea, they crosspost every message they post here on reddit
|
|
2024-02-06 01:32:12
|
regardless of the response they get
|
|
|
|
yoochan
|
2024-02-06 11:56:31
|
my bad, I didn't saw that is was the robot 😄
|
|
|
Cacodemon345
|
2024-02-06 03:11:48
|
How feasible writing an on-GPU JPEG XL decoder would be?
|
|
|
|
Traneptora
|
2024-02-06 03:12:19
|
GPU-accelerated JXL decoder would be possible, but some things can't be parallelized well
|
|
2024-02-06 03:12:22
|
e.g. entropy decoding
|
|
2024-02-06 03:12:42
|
if you're referring to a *hardware decoder* that's something feasible, but it's not on-GPU
|
|
|
|
Cacodemon345
|
2024-02-06 03:13:18
|
I mean software decoder using compute shaders.
|
|
2024-02-06 03:13:35
|
I'm aware that it can consume a lot of VRAM but still.
|
|
|
Cacodemon345
I mean software decoder using compute shaders.
|
|
2024-02-06 03:14:16
|
Like for example a OpenCL JXL decoder.
|
|
|
|
Traneptora
|
2024-02-06 03:14:58
|
GPU-accelerated JXL decoding could be used for things like inverse DCT that VarDCT uses
|
|
|
|
veluca
|
2024-02-06 03:15:34
|
and the filters 😄
|
|
2024-02-06 03:15:39
|
pretty much anything post entropy coding
|
|
|
|
Traneptora
|
2024-02-06 06:22:49
|
ye, epf is a biggie
|
|
2024-02-06 06:27:21
|
huh, GDK pixbuf is having some issue with `orange.jxl`
|
|
2024-02-06 06:27:31
|
|
|
2024-02-06 06:27:45
|
it's actually several JXL files concatenated together
|
|
2024-02-06 06:28:18
|
calling `djxl orange.jxl orange.png` just decodes the first one
|
|
2024-02-06 06:28:41
|
whereas the pixbuf loader is reporting `JXL decoder load_increment called after end of file`
|
|
2024-02-06 07:00:45
|
```c
GdkPixbufJxlAnimation *decoder_state = context;
if (decoder_state->done == TRUE) {
g_set_error(error, GDK_PIXBUF_ERROR, GDK_PIXBUF_ERROR_FAILED,
"JXL decoder load_increment called after end of file");
return FALSE;
}
```
|
|
2024-02-06 07:01:01
|
looks like it refuses if there's trailing data at the end of the file
|
|
2024-02-06 07:09:10
|
hm
|
|
2024-02-06 07:09:10
|
https://github.com/libjxl/libjxl/pull/3253/
|
|
|
|
lonjil
|
2024-02-06 08:30:05
|
did anyone ever make something like jxlinfo but super detailed?
|
|
|
|
_wb_
|
2024-02-06 08:57:35
|
Not really afaik
|
|
2024-02-06 08:58:10
|
I use debug builds of djxl for that, with verbosity cranked up
|
|
2024-02-06 09:01:26
|
Using just the library API there's only so much info you can get. A very verbose djxl with some funky compile flags can even output MA trees and stuff like that, things we don't want to compile into release builds...
|
|
|
|
lonjil
|
2024-02-06 09:04:21
|
I see. I guess that's another thing I should try to implement 😄
Though, not using libjxl if its APIs only allow for so much. My decoder was reading all metadata before I got too busy with school, so I suppose it would be very easy to repurpose that code to just dump out that stuff (more work if I want to dump trees and stuff)
|
|
|
|
Traneptora
|
|
lonjil
did anyone ever make something like jxlinfo but super detailed?
|
|
2024-02-06 09:31:55
|
how detailed?
|
|
|
|
lonjil
|
2024-02-06 09:32:37
|
Like, noting every single thing in the headers?
|
|
|
|
Traneptora
|
2024-02-06 09:33:01
|
`jxlatte --info=trace` dumps the frame headerse atm
|
|
2024-02-06 09:33:04
|
but not the image header
|
|
2024-02-06 09:33:12
|
I should probably make it dump the image header as well
|
|
|
|
lonjil
|
2024-02-06 09:34:08
|
that's funny, I just went back to my cancelled implementation, and apparently printing the image header is all it does!
|
|
2024-02-06 09:35:13
|
though it is the frame headers I actually need atm, so I'll go check jxlatte out
|
|
|
|
Traneptora
|
2024-02-06 09:35:32
|
it's not graceful btw
|
|
2024-02-06 09:35:38
|
it's supposed to be used mostly for debugging
|
|
2024-02-06 09:35:45
|
```
FrameHeader [type=0, encoding=0, flags=128, doYCbCr=false, jpegUpsampling=[[x=0, y=0], [x=0, y=0], [x=0, y=0]], upsampling=1, ecUpsampling=[], groupSizeShift=1, groupDim=256, lfGroupDim=2048, logGroupDim=8, logLFGroupDim=11, xqmScale=3, bqmScale=2, passes=PassesInfo [numPasses=1, numDS=0, shift=[], downSample=[1], lastPass=[0]], lfLevel=0, haveCrop=false, origin=[x=0, y=0], width=3840, height=2160, blendingInfo=BlendingInfo [mode=0, alphaChannel=0, clamp=false, source=0], ecBlendingInfo=[], duration=0, timecode=0, isLast=true, saveAsReference=0, saveBeforeCT=false, name=, restorationFilter=RestorationFilter [gab=false, customGab=false, gab1Weights=[0.115169525, 0.115169525, 0.115169525], gab2Weights=[0.061248593, 0.061248593, 0.061248593], epfIterations=0, epfSharpCustom=false, epfSharpLut=[0.0, 0.06571429, 0.13142858, 0.19714287, 0.26285717, 0.32857144, 0.39428574, 0.46], epfWeightCustom=false, epfChannelScale=[40.0, 5.0, 3.5], epfSigmaCustom=false, epfQuantMul=0.46, epfPass0SigmaScale=0.9, epfPass2SigmaScale=6.5, epfBorderSadMul=0.6666667, epfSigmaForModular=1.0, extensions=Extensions [extensionsKey=0]], extensions=Extensions [extensionsKey=0]]
```
|
|
2024-02-06 09:35:47
|
so you get stuff like this
|
|
|
lonjil
though it is the frame headers I actually need atm, so I'll go check jxlatte out
|
|
2024-02-06 09:37:39
|
possibly useful: `jxlatte --info=trace --parse-only input.jxl`
|
|
2024-02-06 09:37:58
|
`--parse-only` makes the reader skip over frame data sections
|
|
|
|
lonjil
|
2024-02-06 09:38:07
|
that was the easiest to build java project I've ever come across in my life
|
|
|
|
Traneptora
|
2024-02-06 09:38:37
|
there's a reason I don't use gradle
|
|
|
|
lonjil
|
2024-02-06 09:39:38
|
that's a decent amount of image header data I think ```
Image: test.jxl
Level: 5
Size: 1024x1024
Pixel Format: RGB
Bit Depth: 3
Extra Channels: 0
XYB Encoded: false
Primaries: sRGB / BT.709
White Point: D65
Transfer Function: sRGB / ISO-IEC 61966-2-1
Permuted TOC: false
TOC Lengths: [7]
Lossless: Possibly
Frame Info:
Encoding: Modular
Type: Reference Only
Size: 1024x1024
Origin: (0, 0)
YCbCr: false
```
|
|
|
|
Traneptora
|
2024-02-06 09:40:00
|
that's with `--info=v`
|
|
|
|
lonjil
|
2024-02-06 09:40:08
|
even if it isn't a massive data dump
|
|
|
|
Traneptora
|
2024-02-06 09:40:08
|
if you use `--info=trace` it just dumps the header as-is
|
|
|
|
lonjil
|
2024-02-06 09:40:16
|
that's trace
|
|
|
|
Traneptora
|
2024-02-06 09:40:24
|
oh right, TOC isn't printed in verbose
|
|
|
|
lonjil
|
2024-02-06 09:40:25
|
I just didn't copy the FrameHeader below
|
|
|
|
Traneptora
|
2024-02-06 09:40:28
|
ah
|
|
2024-02-06 09:41:51
|
jxlinfo still prints the box structure
|
|
2024-02-06 09:41:57
|
jxlatte ignores the box and just strips it
|
|