|
fab
|
2022-07-29 01:32:08
|
not convenient for development
|
|
|
improver
|
2022-07-29 02:08:11
|
agreed. i'd probably rename <#804324493420920833> to #implementations instead
|
|
|
yurume
|
2022-07-29 02:11:58
|
or have both, for non-libjxl implementations
|
|
|
_wb_
|
2022-07-29 04:23:44
|
96th JPEG meeting ended
|
|
2022-07-29 04:25:35
|
We'll postpone the 2nd edition of 18181-1 a bit to make sure all spec bugs can get fixed - we're back to WD stage with it, with the aim of going to CD stage at the 97th (October) meeting
|
|
2022-07-29 04:26:07
|
So now is a good time to find and fix more spec bugs :)
|
|
2022-07-29 04:28:32
|
Also, very annoyingly, we will need to produce a Word document because the ~~idiots~~editors at ISO cannot handle any other file format. So we will need to find a good way to convert latex to Word automatically without requiring (a lot of) manual layout fixing...
|
|
|
Traneptora
|
2022-07-29 09:09:11
|
Embed it as an image
|
|
2022-07-29 09:09:16
|
<:Kekw:859968756523335710>
|
|
|
Pashi
|
2022-07-30 03:36:54
|
I fear for our world and for the future and security of our civilization if the self-styled "International Standards Organization" requires specs to be in Microsoft Word and not LaTeX
|
|
2022-07-30 03:41:28
|
Who appointed them anyways? Or is it a self appointed position? We should proclaim this discord server to be the new "Planetary Standards Alliance" to supercede the ISO.
|
|
2022-07-30 03:42:03
|
All spec documents to be submitted as discord chat messages
|
|
|
190n
|
2022-07-30 06:08:07
|
docx is an iso standard to be fair
|
|
|
_wb_
Also, very annoyingly, we will need to produce a Word document because the ~~idiots~~editors at ISO cannot handle any other file format. So we will need to find a good way to convert latex to Word automatically without requiring (a lot of) manual layout fixing...
|
|
2022-07-30 06:10:29
|
any easier to get it as odt first?
|
|
|
|
_wb_
|
2022-07-30 06:21:28
|
ISO is legally speaking just a Swiss private company. The only reason they are "important" is that all the national standards organizations are giving them legitimacy, and many national and international governments or governmental organizations are empowering ISO by normatively citing ISO standards in various regulations.
|
|
|
190n
any easier to get it as odt first?
|
|
2022-07-30 06:24:54
|
I don't think that will make much of a difference...
|
|
|
|
yurume
|
2022-07-30 06:26:30
|
pandoc can convert latex to docx for most simple cases I think, that may work with the spec as well
|
|
|
|
veluca
|
2022-07-30 09:01:57
|
Latexml is probably an easier choice here
|
|
2022-07-30 09:02:12
|
Unless pandoc improved significantly in the months since I last tried
|
|
|
|
yurume
|
2022-07-30 09:02:49
|
what I'm most unsure about is the table support
|
|
|
|
_wb_
|
2022-07-30 10:34:18
|
When I open a pdf version in Word, it does some import magic and the tables look good actually. But the rest, especially pseudocode, looks bad
|
|
|
|
Deleted User
|
2022-07-30 11:32:02
|
Well, ISO has to live with that, not our problem if they don't accept LaTeX. ;)
|
|
|
Fraetor
|
2022-07-30 11:32:37
|
It is a problem for anyone who has to use the specs though.
|
|
|
|
_wb_
|
2022-07-30 01:35:07
|
It is also a problem for me to get it approved by JPEG for submission to ISO
|
|
|
|
Pashi
|
2022-07-30 08:07:15
|
Why don't they accept PDF?
|
|
2022-07-30 08:07:35
|
Or Postscript
|
|
2022-07-30 08:09:11
|
I would seriously consider the embedded image in docx idea.
|
|
2022-07-30 08:12:00
|
Converting a LaTeX document to Microsof Word is such a brainlet idea
|
|
|
|
190n
|
2022-07-30 08:13:56
|
well presumably they want to be able to edit the document which sucks on PDFs and is basically impossible with the image method
|
|
|
|
_wb_
|
2022-07-30 08:24:16
|
They have some proprietary software to convert Word to xml which they then use to produce pdf, epub and html versions of the standards
|
|
|
|
Deleted User
|
2022-07-30 09:45:48
|
LaTeX and PDF aren't very responsive nor accessible, so it's understandable if one would prefer HTML or ePUB.
|
|
|
|
Pashi
|
|
_wb_
They have some proprietary software to convert Word to xml which they then use to produce pdf, epub and html versions of the standards
|
|
2022-07-30 11:22:02
|
Sounds great for an organization trying to foster standardization.
|
|
|
|
yurume
|
2022-07-30 11:23:33
|
technically speaking docx is also ISO/IEC 29500
|
|
|
|
Pashi
|
2022-07-31 04:27:39
|
Last I heard MS Office does not even conform to their own ISO standard so that's kinda irrelevant and marketing lies.
|
|
|
The_Decryptor
|
2022-07-31 04:29:17
|
Standards as only useful when people agree on them, if everybody does something else then the standard's useless and should be changed
|
|
2022-07-31 04:29:25
|
e.g. the entirety of HTML/CSS/JavaScript
|
|
|
|
Pashi
|
2022-07-31 04:30:34
|
Not to mention the spec itself is supposedly extremely difficult for a third-party to implement and contains a lot of things that aren't useful for anything but MS Office
|
|
2022-07-31 04:31:29
|
From what I heard anyways.
|
|
|
|
Fraetor
|
2022-07-31 10:08:57
|
It's one of those fiendishly complicated standards that is essentially impossible to fully implement, though fortunately 99% of usecases can be covered by a small core part.
|
|
2022-07-31 10:09:06
|
A bit like SVG.
|
|
|
spider-mario
|
|
veluca
Unless pandoc improved significantly in the months since I last tried
|
|
2022-08-01 11:01:31
|
my impression is that pandoc’s docx output is decent, it’s probably latex input that is more problematic
|
|
2022-08-01 11:01:43
|
writing in pandoc markdown might work better
|
|
|
|
_wb_
|
2022-08-01 11:35:30
|
I don't think markdown is expressive enough
|
|
2022-08-01 11:36:46
|
Can it do macros, crossreferences, and math?
|
|
|
|
spider-mario
|
2022-08-01 01:21:13
|
pandoc’s flavor of it can do some of those
|
|
2022-08-01 01:21:41
|
https://pandoc.org/MANUAL.html#pandocs-markdown
|
|
2022-08-01 01:23:07
|
> TeX math will be printed in all output formats. How it is rendered depends on the output format:
> […]
> **Docx**
> It will be rendered using OMML math markup.
|
|
|
|
Pashi
|
2022-08-02 02:25:29
|
https://discord.com/channels/794206087879852103/805722506517807104/995601247048577054
|
|
2022-08-02 02:26:04
|
Is it bad that I find this post hilarious?
|
|
|
Jyrki Alakuijala
|
|
Pashi
I fear for our world and for the future and security of our civilization if the self-styled "International Standards Organization" requires specs to be in Microsoft Word and not LaTeX
|
|
2022-08-03 03:57:28
|
It will just require a generation or two of new standard makers
|
|
|
|
Pashi
|
2022-08-03 04:14:20
|
Well I guess starting with the way he implies a familiarity with ffmpeg but doesn't know about the configure script...
|
|
2022-08-03 04:20:28
|
The rest of it was funny just because of the clusterfuck of third party support like Firefox having the option in all versions but only having an effect if you are using nightly for some asinine reason
|
|
2022-08-03 04:22:20
|
Or the steps required to get Irfanview passably working
|
|
2022-08-03 04:23:57
|
Taking several seconds with of a black screen to load a single frame when it normally takes less than a second to decode
|
|
|
zebefree
|
|
_wb_
We'll postpone the 2nd edition of 18181-1 a bit to make sure all spec bugs can get fixed - we're back to WD stage with it, with the aim of going to CD stage at the 97th (October) meeting
|
|
2022-08-03 07:08:10
|
If there is going to be an update to 18181-1 it would be great if it clarified whether intrinsic_size is the size before or after any rotation from orientation.
|
|
|
|
_wb_
|
2022-08-03 08:12:40
|
Ah, isn't that clear atm? Should be before orientation, and same orientation applied to intrinsic dimensions as to actual dimensions, but you could be right that this is not clear from the spec.
|
|
2022-08-03 08:13:40
|
(one issue is that afaik nothing really uses previews and intrinsic dimensions yet for anything, we should probably change that somehow)
|
|
|
|
zebefree
|
2022-08-03 08:18:45
|
If it is supposed to match the intrinsic size that web browsers use (i.e. size before any CSS) then I would expect it to be after rotation.
|
|
2022-08-03 08:18:49
|
Also I may be misinterpreting it but it looks like libjxl reports it after rotation when not explicitly in the file.
|
|
2022-08-03 08:18:56
|
https://github.com/libjxl/libjxl/blob/main/lib/jxl/decode.cc#L2187
|
|
2022-08-03 08:19:08
|
swaps, then reports on line 2233
|
|
2022-08-03 08:28:59
|
The only thing I see in 18181-1 about it is F.1 where it says that the width/height in the frame header is before rotation. But it doesn't mention it for intrinsic_size.
|
|
|
|
Pashi
|
2022-08-04 02:38:50
|
I agree that Firefox is to blame here
|
|
2022-08-04 02:39:48
|
Still funny
|
|
|
|
Jyrki Alakuijala
|
2022-08-04 01:54:29
|
Once it is turned on on Chromium, Firefox is likely able to follow. The formal place to justify JPEG XL is here. https://bugs.chromium.org/p/chromium/issues/detail?id=1178058
|
|
|
|
improver
|
2022-08-04 01:56:48
|
i suspect this would happen sometime after v1.0
|
|
2022-08-04 01:56:57
|
of libjxl
|
|
2022-08-04 01:57:53
|
kinda wondering how many months left. v1.0 looks like it's kind of starting to take shape but it still feels few weeks away, at least looking from afar
|
|
|
w
|
2022-08-04 02:02:07
|
what about 0.7
|
|
|
|
Jyrki Alakuijala
|
2022-08-04 02:03:16
|
Chromium people are not following libjxl development. They are focused on AV1/AV2/AVIF etc.
|
|
2022-08-04 02:03:53
|
Chromium people have developed AVIF, from their point of view JPEG XL looks as a distraction and something that can be an obstacle to deploy AVIF quickly
|
|
2022-08-04 02:05:03
|
or cause confusion in the field
|
|
|
|
JendaLinda
|
2022-08-04 02:38:37
|
In IrfanView, it takes about 2 seconds to load a 10kx10k JXL image for me. That's not bad imo.
|
|
|
Jyrki Alakuijala
Chromium people are not following libjxl development. They are focused on AV1/AV2/AVIF etc.
|
|
2022-08-04 03:19:31
|
That's kinda paradox that Chromium based MS Edge doesn't support AVIF at all.
|
|
|
|
Jyrki Alakuijala
|
2022-08-04 03:46:41
|
I didn't know that
|
|
|
|
Pashi
|
2022-08-05 06:33:53
|
Have you tried installing the AV1 codec from the MS store?
|
|
2022-08-05 06:34:13
|
After that all the apps on windows support avif
|
|
|
|
The_Decryptor
|
2022-08-05 06:34:18
|
Not Edge
|
|
|
|
Pashi
|
2022-08-05 06:34:32
|
including the file manager and default photo viewer
|
|
2022-08-05 06:36:37
|
wow you're right edge is the exception
|
|
2022-08-05 06:36:48
|
how weird
|
|
|
|
w
|
2022-08-05 06:37:06
|
many things dont work in edge
|
|
|
|
Pashi
|
2022-08-05 06:37:11
|
yet exactly to be expected from a piece of shit unremoveable malware like edge
|
|
|
|
w
|
2022-08-05 06:37:22
|
the odd browser
|
|
|
|
Pashi
|
2022-08-05 06:37:34
|
The browser you can't uninstall
|
|
2022-08-05 06:39:37
|
You can never get rid of
|
|
2022-08-05 06:39:49
|
Opens itself even if you selected another browser as your default
|
|
|
|
w
|
2022-08-05 06:40:00
|
i haven't ever had that issue
|
|
2022-08-05 06:40:03
|
and it's not too bad
|
|
2022-08-05 06:40:34
|
and for the normal person it's good enough
|
|
2022-08-05 06:40:38
|
i use it more than i do chrome
|
|
|
|
Pashi
|
2022-08-05 06:40:58
|
Happens all the time, on all of the PCs I use, and I use a lot of PCs because my job is to use everyone's PC.
|
|
|
|
The_Decryptor
|
2022-08-05 06:41:04
|
If Firefox supported PWAs (And fixed some other annoying issues) I might have stuck with it, but as it stands Edge is Chrome but without all the annoying Google stuff
|
|
|
|
Pashi
|
2022-08-05 06:42:36
|
No annoying google stuff, just unremoveable adware that spams sponsored political stories and can never be uninstalled
|
|
2022-08-05 06:43:20
|
Like that shitty "news and interests" bullshit on the taskbar in Windows 10
|
|
2022-08-05 06:43:47
|
that automatically opens itself if your mouse accidentally merely hovers over it
|
|
|
|
The_Decryptor
|
2022-08-05 06:43:56
|
Yeah I just disabled that
|
|
|
|
w
|
2022-08-05 06:44:21
|
just disable it man
|
|
2022-08-05 06:44:23
|
it can all be disabled
|
|
|
|
Pashi
|
2022-08-05 06:44:28
|
I disable that like 10 times a day because of how many computers I have to use lol
|
|
|
|
w
|
2022-08-05 06:44:29
|
no point in getting angry over it
|
|
|
|
Pashi
|
2022-08-05 06:45:00
|
You'd be angry too if you had to deal with it that much lol
|
|
|
|
w
|
2022-08-05 06:45:00
|
everything has something like that in some form
|
|
|
|
Pashi
|
2022-08-05 06:45:45
|
But yeah I've tried using edge and I don't think you can fully disable everything on the new tab page
|
|
2022-08-05 06:46:09
|
There's still political shit on the bottom edge even in "focused" mode
|
|
|
|
w
|
2022-08-05 06:46:13
|
|
|
2022-08-05 06:46:14
|
?
|
|
|
|
Pashi
|
2022-08-05 06:47:18
|
I could never get it to look like that.
|
|
2022-08-05 06:48:11
|
I selected "focused" mode and even tried custom mode and there's always some political stuff at the bottom edge of the page and even more of it if you scroll
|
|
|
|
w
|
|
|
Pashi
|
2022-08-05 06:48:47
|
I don't use Windows when I'm not at work either
|
|
|
|
w
|
2022-08-05 06:49:27
|
this is actually pretty nice
|
|
2022-08-05 06:49:43
|
|
|
2022-08-05 06:50:27
|
lmao
|
|
|
|
Pashi
|
2022-08-05 06:50:29
|
Yeah, I tried custom mode like that
|
|
2022-08-05 06:51:21
|
And there was always stories of the bottom mostly of the political derp yawnfest variety
|
|
2022-08-05 06:51:34
|
No matter what settings I chose
|
|
2022-08-05 06:52:06
|
Maybe because we just had some kind of ceremony recently, I think the humans call it an election
|
|
2022-08-05 06:53:00
|
Seems like a pretty asinine ritual if you ask me
|
|
|
|
w
|
2022-08-05 06:53:19
|
it's the content setting
|
|
|
|
Pashi
|
2022-08-05 06:54:31
|
All that it seemed to do is move the content to the very bottom
|
|
2022-08-05 06:54:44
|
While still always there.
|
|
2022-08-05 06:55:00
|
And the page was always scrollable
|
|
2022-08-05 06:56:16
|
You want to know another great feature of Windows that I have to deal with all the time? Microsoft store apps that aren't even installed taking up ALL of the space on the hard drive. Like every version of Candy Crush that has ever been released
|
|
2022-08-05 06:56:27
|
All in an undeleteable hidden folder :)
|
|
|
|
_wb_
|
2022-08-05 06:57:09
|
Maybe move this discussion to <#806898911091753051> ?
|
|
|
|
Pashi
|
2022-08-05 06:57:12
|
Even though it isn't installed and has never been installed, for some reason 100 versions of candy crush collect in this folder
|
|
|
|
fab
|
2022-08-05 03:41:32
|
|
|
2022-08-05 03:41:44
|
Jxl s7 s8 isn't optimized for those kind of photos
|
|
2022-08-05 03:42:13
|
You need s9
|
|
2022-08-06 12:00:15
|
though svt isn't is as pleasant
|
|
2022-08-06 12:01:23
|
it denoises too much
|
|
2022-08-06 12:01:50
|
|
|
2022-08-06 12:02:20
|
and certain movements appears too fast as someone is using a mooping
|
|
2022-08-06 12:03:14
|
original is 23,5 mb with included 4,56 audio track
|
|
2022-08-06 12:03:22
|
this will be 49,6 mb
|
|
2022-08-06 12:04:28
|
encoding is slow 9 hours for a 5:02, 640x480 video
|
|
2022-08-06 12:04:41
|
with these settings
|
|
2022-08-06 12:04:42
|
--input-depth 10 --preset 3 --tune 0 --film-grain 33 --crf 15
|
|
2022-08-06 12:04:59
|
and staxrip choosed 8 bit
|
|
2022-08-06 12:05:27
|
so with 10 bit and tune 0 even slower
|
|
2022-08-06 12:06:37
|
this is a normal cpu 3 settings
|
|
|
Fox Wizard
|
2022-08-06 12:51:59
|
Are you using a potato? <a:DogeScared:926955696669466636>
|
|
|
|
fab
|
2022-08-06 01:33:07
|
i3 330m
|
|
2022-08-06 01:33:28
|
basically is like using xiaomi mi11 lite 5g for encoding
|
|
|
|
Fox Wizard
|
2022-08-06 01:54:27
|
That's... oh no. No wonder it's taking that long <:KekDog:884736660376535040>
|
|
|
|
fab
|
2022-08-06 01:59:47
|
Can you do in 20 minutes with modern laptop processors?
|
|
|
|
Fox Wizard
|
2022-08-06 02:10:40
|
No idea tbh. Can't say I ever use laptops <:KekDog:884736660376535040>
|
|
|
diskorduser
|
2022-08-06 02:37:07
|
Poor cpu doing heavy work
|
|
|
|
fab
|
|
diskorduser
Poor cpu doing heavy work
|
|
2022-08-06 03:04:46
|
Why all people says only this all the time?
|
|
|
|
diskorduser
|
2022-08-06 03:07:06
|
Because encoding avif on cpu is a heavy work.
|
|
2022-08-06 03:07:20
|
Especially on that processor
|
|
|
|
fab
|
|
diskorduser
Because encoding avif on cpu is a heavy work.
|
|
2022-08-06 03:27:01
|
Yes i know encoding HTML screenshot Is superslow
|
|
2022-08-06 03:27:18
|
43 minutes for 440x22000
|
|
2022-08-06 03:27:21
|
S6
|
|
2022-08-06 03:38:06
|
|
|
2022-08-06 03:38:07
|
That's how Wikipedia works
|
|
|
|
w
|
2022-08-08 02:18:15
|
omg free nitro from steam!?
|
|
2022-08-08 02:18:45
|
<:uhoh:650565843851280384>
|
|
|
Demez
|
|
Brinkie Pie
|
2022-08-09 10:52:23
|
I think the bots just search the web for open invite links, similar to how you can (and do) get email spam even as a non-popular person.
|
|
|
|
Fox Wizard
|
2022-08-09 01:19:25
|
That and people who fall for scams which causes their accounts to be used for spamming ~~like those very obvious free Nitro scams XD~~
|
|
|
|
JendaLinda
|
2022-08-09 02:32:50
|
Oh those spammers have such terrible life. They have no friends. Nobody likes them. They're so unappreciated. They just need some love and attention but they're going about it the wrong way.
|
|
|
|
w
|
2022-08-10 05:55:47
|
<:weirdge:778473410341896222>
|
|
2022-08-10 12:07:56
|
can someone delete that
|
|
|
|
_wb_
|
2022-08-10 08:45:26
|
https://twitter.com/pantrymoth/status/1557085719318990850?t=370DSHfOgypfsGL5zyPgCQ&s=19
|
|
2022-08-10 08:45:50
|
I wonder if jxl's noise generator can be abused to generate that
|
|
|
|
yurume
|
2022-08-10 08:49:32
|
is it a *single* particular image?
|
|
|
BlueSwordM
|
|
yurume
is it a *single* particular image?
|
|
2022-08-10 08:49:57
|
It's similar to blue noise dithering.
|
|
2022-08-10 08:50:02
|
Very important thing 😄
|
|
|
|
_wb_
|
2022-08-10 08:50:08
|
Frame 0: reference-only, solid gray with noise
Frame 1: 8x upsampling, patch from frame 0 (which gets upsampled using some suitable kernel)
Frame 2: 4x upsampling, patch from frame 0 at different offset, alpha at constant 0.5, blended with frame 1.
Etc.
|
|
|
|
yurume
|
2022-08-10 08:50:24
|
yeah, I assumed it's just a general introduction to Perlin noise, not that particular noise
|
|
|
|
_wb_
|
2022-08-10 08:50:36
|
Would that work or did we define patches in a way that doesn't make that work?
|
|
2022-08-10 08:52:35
|
Another approach would be to use some chaotic modular cellular automaton to directly generate something that is close enough, something involving Weighted predictor probably
|
|
|
|
yurume
|
|
_wb_
Frame 0: reference-only, solid gray with noise
Frame 1: 8x upsampling, patch from frame 0 (which gets upsampled using some suitable kernel)
Frame 2: 4x upsampling, patch from frame 0 at different offset, alpha at constant 0.5, blended with frame 1.
Etc.
|
|
2022-08-10 08:53:51
|
thinking about that, I think this is not exactly Perlin noise, and is generally called https://en.wikipedia.org/wiki/Value_noise
|
|
|
|
_wb_
|
2022-08-10 08:55:30
|
<@768090355546587137> has an ancient webpage about this: https://lodev.org/cgtutor/randomnoise.html
|
|
|
|
fab
|
|
fab
|
|
2022-08-13 10:13:19
|
<@794205442175402004> this has difficulty to retain noise in new cjxl binary
|
|
2022-08-14 12:33:49
|
there is a way to force jpeg xl to retain noise is
|
|
2022-08-14 12:33:50
|
for %i in (C:\Users\Use\Documents\SE\*.png) do cjxl --progressive -d 0.341 --intensity_target=292 --gaborish=0 -e 9 --modular_predictor=1 --keep_invisible=1 "%i" "%i.jxl"
|
|
2022-08-14 12:34:03
|
with the fix
|
|
2022-08-14 12:34:08
|
|
|
2022-08-14 12:34:12
|
without the fix
|
|
2022-08-14 12:34:21
|
|
|
2022-08-14 12:34:30
|
for %i in (C:\Users\Use\Documents\SEVEN\*.png) do cjxl -d 1 -e 7 "%i" "%i.jxl"
|
|
|
|
Jyrki Alakuijala
|
|
_wb_
I wonder if jxl's noise generator can be abused to generate that
|
|
2022-08-15 05:16:57
|
no
|
|
|
|
_wb_
|
2022-08-15 05:24:06
|
Well not directly, of course — jxl's noise is pixel-sized
|
|
2022-08-15 05:24:57
|
But maybe in combination with repeated upsampling and blending, something can be done
|
|
|
|
Jyrki Alakuijala
|
2022-08-15 05:57:54
|
I think better chances with palette and context tree magic
|
|
|
|
_wb_
|
2022-08-15 06:38:31
|
Yes, this kind of jxl art can produce various kinds of natural looking textures: https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDTgCs9MATOMTLg8UjPTM0og7NCC4sTcgpxUBUOuIOcQBVMursw0hUoFO6CsAZeCApAT7u4B5OoaAnkKCroKjmXp4dp-CsYIrp-2n6uCrjFUNVCtAVQuHGxPagpCc3BqiYIR0GAA
|
|
2022-08-15 06:38:36
|
|
|
|
|
Jyrki Alakuijala
|
|
|
fab
|
2022-08-16 03:17:32
|
what is libjxl tiny
|
|
2022-08-16 03:17:40
|
https://github.com/libjxl/libjxl-tiny/pull/15/files
|
|
|
|
improver
|
2022-08-16 03:52:56
|
a tiny libjxl
|
|
|
|
_wb_
|
2022-08-16 04:57:00
|
Goal is to make a simple encoder, a bit worse than libjxl but much less code and maybe a bit faster. Will be used to help design a hardware implementation.
|
|
|
|
fab
|
2022-08-16 05:18:13
|
Will use to improve Picture quality of libjxl encoder?
|
|
|
|
_wb_
|
2022-08-16 06:13:32
|
No
|
|
2022-08-16 06:15:38
|
Its goal is to preserve as much density and quality as possible while also reducing the complexity of the encoder, to get something that is simple enough to eventually turn into a cheap chip to put in cameras.
|
|
|
|
diskorduser
|
2022-08-16 06:16:15
|
So brotli gets hw encoder and decoder too?
|
|
|
|
_wb_
|
2022-08-16 06:16:37
|
Nah, jxl doesn't really need brotli
|
|
2022-08-16 06:17:16
|
Brotli is only used for metadata and jpeg reconstruction data, both of which are optional
|
|
|
|
diskorduser
|
2022-08-16 06:18:06
|
I know. So uncompressed data for hw implementation?
|
|
|
|
_wb_
|
2022-08-16 06:18:28
|
I don't think things like brotli and gzip would benefit much from hw anyway
|
|
|
|
yurume
|
2022-08-16 06:19:04
|
I guess there would be no metadata to begin with for most HW applications
|
|
2022-08-16 06:19:38
|
you don't really need jbrd, while XMP and Exif can be probably pre-compressed
|
|
|
|
_wb_
|
2022-08-16 06:20:05
|
Yes, either there is no or very little metadata so uncompressed is fine, or they can do the metadata compression separately in software, or just keep it uncompressed which is what they currently do (Exif in JPEG is just uncompressed)
|
|
|
|
yurume
|
2022-08-16 06:20:41
|
it does need to compress an ICC profile, but that also rarely changes
|
|
|
|
_wb_
|
2022-08-16 06:21:15
|
The preview image is typically the largest thing in Exif, but that is better done as a native jxl preview
|
|
2022-08-16 06:22:09
|
Enum colorspaces don't need compression, and they cover all sane RGB colorspaces
|
|
2022-08-16 06:22:44
|
Cameras don't shoot in CMYK, which is the only thing you really need actual non-Enum ICC profiles for in jxl
|
|
|
|
diskorduser
|
2022-08-16 06:26:27
|
Is modular jxl difficult to implement on hardware? I hope they don't omit it
|
|
|
username
|
2022-08-16 06:30:37
|
I would guess that most hardware implementations would be used for stuff like cameras of which lossy does pretty well with photos so modular will probably be not present. and also I have never really heard of a equivalent in the past like say for example a hardware png encoder
|
|
|
|
yurume
|
2022-08-16 06:31:59
|
there exist hardware PNG encoders, but they seem to fix the Huffman table
|
|
|
|
diskorduser
|
2022-08-16 06:33:13
|
Modular is important for raw/dng.
|
|
|
|
_wb_
|
2022-08-16 06:55:44
|
An encoder can pick a simple subset of modular, like fjxl did. It needs to implement some of modular in any case because all encode modes use it. VarDCT uses it for the 1:8 LF image, the map of which block types are used where, the adaptive quantization weights, the chroma from luma multipliers, the epf filter strength map, and custom quantization tables. Most of those are optional and could be a constant value (which doesn't require a real modular implementation), but the LF image is not optional.
|
|
2022-08-16 07:02:33
|
I wonder to what extent raw/dng will still be that useful if you can just do a d0.3 lossy jxl that preserves all the dynamic range the sensor can capture (so adjustments can still be done). Of course some pros will still want to do manual debayering and avoid even the tiniest dct artifact and generation loss, but I think in nearly all use cases a very high quality jxl would be as good as a raw and a lot more convenient (more software support, smaller size, no need for embedded previews etc).
|
|
|
|
fab
|
2022-08-17 04:03:59
|
I edited the JPEG XL italian article
|
|
2022-08-17 04:04:35
|
Also av1 article
|
|
2022-08-17 04:05:06
|
The only thing i didnt was to precise 1.2.1-3 is out
|
|
2022-08-17 04:05:12
|
Of SVT av1
|
|
2022-08-17 05:56:08
|
Is Jon dyslexic?
|
|
|
|
Brinkie Pie
|
2022-08-17 07:36:15
|
I think there's discord bots that try to take care of spam automatically
|
|
|
|
_wb_
|
2022-08-17 07:37:00
|
the main source of spam is the integration with Matrix
|
|
|
|
fab
|
2022-08-17 07:55:23
|
Latest svt vs jxl
|
|
2022-08-17 07:55:39
|
Svt 143 kb sharp
|
|
2022-08-17 07:55:48
|
Jxl 103 kb
|
|
2022-08-17 07:55:54
|
Less sharp
|
|
2022-08-17 07:56:05
|
More resampled
|
|
2022-08-17 07:56:24
|
But overrall higher Nicky jam Niko pandetta sharpness
|
|
2022-08-17 07:56:44
|
They look sharper than all image
|
|
2022-08-17 07:58:28
|
|
|
2022-08-17 08:00:28
|
Svt looks so daala in the first
|
|
2022-08-17 08:10:01
|
D 0.886 s 9 is the best for jxl
|
|
2022-08-17 08:13:03
|
D 0.464 epf 0 s9 is what I recommend
|
|
2022-08-17 08:23:26
|
D
|
|
2022-08-17 08:23:37
|
Discord isn't working anymore for me
|
|
2022-08-17 08:23:41
|
Too problems
|
|
2022-08-17 08:23:46
|
I must quit
|
|
2022-08-17 08:24:23
|
Firefox Windows 7 notepad when i press enter it makes a space and don't upload the post
|
|
2022-08-17 08:25:12
|
The new bluecord version is bugged with the chinese font i have
|
|
2022-08-17 08:25:22
|
It's 22:25
|
|
2022-08-17 08:25:32
|
I have not watched reddit
|
|
2022-08-17 08:25:44
|
Local news i didnt read
|
|
2022-08-17 08:25:49
|
Even shower
|
|
2022-08-17 08:25:57
|
Nothing i did todau
|
|
2022-08-17 08:28:17
|
Discord already shows the copy messages with the graph paranthesis
|
|
2022-08-17 08:28:31
|
I hate it, i can't copy nothing
|
|
2022-08-17 08:28:47
|
My font are messy to do this stuff
|
|
2022-08-17 08:29:14
|
|
|
2022-08-17 08:30:34
|
Many programs promise the compatibility with Windows 7 when the reality is that you can't do nothing
|
|
2022-08-17 08:30:57
|
Honestly keyboard looks better with jxl
|
|
2022-08-17 08:31:08
|
Even android keyboard
|
|
|
|
Jyrki Alakuijala
|
|
diskorduser
I know. So uncompressed data for hw implementation?
|
|
2022-08-22 10:00:02
|
libjxl-tiny is a feasibility study that gives some guidance for hardware implementors -- but hw guys will make their own design. Some guidance on what to leave out can be found from the compromise that Zoltan will give in libjxl-tiny.
|
|
|
daxpedda
|
2022-08-23 01:41:01
|
I'm having some problem with the specification
I can't make any sense of the Distribution Clustering decoding. Specifically I can't figure out how to calculate `num_clusters`. In C.2.2 it says:
> The decoder then initializes a symbol decoder using a single distribution D, as specified in C.2.1. For each pre-clustered distribution i, the decoder reads an integer as specified in C.3.3.
I have no clue what "distribution D" means here, I feel like "C.2.1" and "C.3.3" are not correctly referenced here, maybe some of them where moved in the past and not corrected here.
I did look at the reference implementation, but can't seem to find anything in the spec that correlates to whats going on there.
|
|
|
|
Greg Benz
|
2022-08-23 03:31:38
|
Anyone know of a way to create an HDR JXL from a source image which is 32-bit (ideally) or 16-bit PNG? I just tried CJXL on a 16-bit PNG which shows as HDR in Photoshop, and the resulting JXL does not show as HDR in Chrome. I am able to see valid HDR AVIF in Chrome but do not know yet if Chrome properly supports HDR JXL (ie unclear if I'm seeing clipped data because of the conversion or Chrome), so...
I then did a reverse conversion via DJXL to bring that JXL back to PNG to see how the round tripped image would look in Photoshop, and the twice converted image was no longer HDR in Photoshop. The image is clipped to SDR values.
|
|
|
|
yurume
|
|
daxpedda
I'm having some problem with the specification
I can't make any sense of the Distribution Clustering decoding. Specifically I can't figure out how to calculate `num_clusters`. In C.2.2 it says:
> The decoder then initializes a symbol decoder using a single distribution D, as specified in C.2.1. For each pre-clustered distribution i, the decoder reads an integer as specified in C.3.3.
I have no clue what "distribution D" means here, I feel like "C.2.1" and "C.3.3" are not correctly referenced here, maybe some of them where moved in the past and not corrected here.
I did look at the reference implementation, but can't seem to find anything in the spec that correlates to whats going on there.
|
|
2022-08-23 03:33:46
|
`num_clusters` is implicit (not directly encoded), it is defined to be the maximum of each `cluster[i]` plus 1.
|
|
|
|
daxpedda
|
2022-08-23 04:30:12
|
is this mentioned in the specification anywhere?
|
|
2022-08-23 04:33:24
|
<@268284145820631040> https://gist.github.com/lifthrasiir/137a3bf550f5a8408d4d9450d026101f#file-j40-h-L1752-L1756
what is this magic you are doing here? is this some nice efficient way to determine maximums?
|
|
|
|
yurume
|
2022-08-23 04:35:05
|
uh, so the cluster map is a length-defined array of unsigned integers, which bound is implied from the prefix code or ANS distribution
|
|
2022-08-23 04:35:24
|
once they are read you can compute the maximum value to determine the actual number of clusters used
|
|
|
DuxVitae
|
2022-08-23 04:35:31
|
Anyone know of a way to create an HDR
|
|
|
|
yurume
|
2022-08-23 04:35:54
|
in that particular code I'm also testing whether there is an unused cluster (not "seen"), which is an error according to the spec
|
|
|
|
daxpedda
|
2022-08-23 04:39:18
|
yeah okay, maybe I will understand this when I get a bit further
just to get this right, to determine `num_clusters` I find the biggest number in `cluster[i]` plus 1?
|
|
|
|
yurume
|
2022-08-23 04:39:34
|
yes
|
|
2022-08-23 04:40:30
|
the draft spec and libjxl makes sure that `num_clusters <= 256` as well, so if you are concerned about reading out-of-bound integers, that's how you prevent that
|
|
|
|
daxpedda
|
2022-08-23 04:41:19
|
aaaah, so that's what this is ... I get it now 😄
|
|
|
|
yurume
|
2022-08-23 04:41:31
|
sorry for a cryptic C speak lol
|
|
|
|
daxpedda
|
2022-08-23 04:42:09
|
all good, just didn't do C in a long while, I feel a bit sick every time I look at it now
|
|
|
|
yurume
|
2022-08-23 04:42:23
|
C makes me sick as well 😉
|
|
2022-08-23 04:43:05
|
honestly speaking I didn't know that j40 would be 6000+ lines of C code, if I knew that I would have chosen Rust haha
|
|
|
|
daxpedda
|
2022-08-23 04:46:02
|
I looked into the code <@179701849576833024> has written so far, I really like the approach with the proc-macros, it makes the code much cleaner and easier to read (after you understand the proc-macro) and avoids a lot of errors that naturally come with hand-written code
|
|
|
|
yurume
|
2022-08-23 04:46:33
|
AFAIK that's a natural translation from libjxl, which had a same sort of Fields code
|
|
2022-08-23 04:47:03
|
but in Rust you can't have undefined fields in structs at all anyway, so that makes a hand-written code much more safer
|
|
|
|
daxpedda
|
2022-08-23 04:47:46
|
I have a question about the specification
so, I understand that this is under ISO, which means that ISO owns the specification and it can't just be easily shared, legally
I don't know exactly how to maintain a JPEG-XL decoder open source project without being able to properly link to the specification in code or in issues and PRs
in addition, considering the specification is kinda awful to read, in my humble opinion, I would like to provide feedback, also plenty of errors as you guys already know
also, it would be nice to see draft iteration, to make it easier to update code
is this possible legally? basically keep the draft open source and public but let the specification be closed behind ISO?
|
|
2022-08-23 04:49:19
|
alternatively, if this can't work, is it legal to upload the "leaked" draft, as part of the repo for example?
|
|
|
|
_wb_
|
2022-08-23 04:51:34
|
It is all a bit of gray zone, but bottom line is that ISO owns the copyright and can sue people who illegally distribute specs
|
|
|
|
daxpedda
|
2022-08-23 04:51:47
|
yeah, but what about the draft?
|
|
|
|
_wb_
|
2022-08-23 04:52:02
|
Now how exactly it works with drafts is not very clear
|
|
|
|
yurume
|
2022-08-23 04:53:49
|
given ISO C/C++ WG are regularly publishing drafts including those almost identical to the IS, there seems no actual hurdle at least from ISO if an WG wants to do so
|
|
2022-08-23 04:54:43
|
but I don't know if things greatly differ between different SCs (C/C++ are JTC1/SC22 while JPEG is at JTC1/SC29)
|
|
|
|
_wb_
|
2022-08-23 04:55:50
|
I tried to get the green light from JPEG to make the spec drafting repo public but they didn't give me the green light
|
|
|
|
daxpedda
|
2022-08-23 04:56:27
|
bribe them with cookies plz
|
|
2022-08-23 04:57:18
|
I really think this is incredibly unfortunate, I've worked with plenty of IETF specs before and the amount of feedback they get from the open source community is incredible ... JPEG is missing out
|
|
|
|
_wb_
|
2022-08-23 05:00:31
|
I agree, but I don't really see a way to improve the situation. Other JPEG members are worried about ISO burocrats getting mad at them, so I don't get consensus to make the spec drafting repo public. If I unilaterally do it anyway, other JPEG members will get mad at me.
|
|
2022-08-23 05:02:05
|
Even though everyone in JPEG sees the advantages of having open access to (draft) specs, they don't really seem to have the guts to stand up to ISO.
|
|
|
|
daxpedda
|
|
_wb_
I agree, but I don't really see a way to improve the situation. Other JPEG members are worried about ISO burocrats getting mad at them, so I don't get consensus to make the spec drafting repo public. If I unilaterally do it anyway, other JPEG members will get mad at me.
|
|
2022-08-23 05:02:14
|
I understand of course, apologies, I think I was kinda venting some frustration here
|
|
|
|
_wb_
|
2022-08-23 05:04:09
|
The gray zone I can work with is leaking drafts in a plausibly non-public way, i.e. not on a public website, but in a 'private' space like this discord.
|
|
|
|
yurume
|
2022-08-23 05:04:11
|
I personally don't like this "solution", but one possibility is a parallel "guide" document that is detailed enough to implement everything without the actual spec
|
|
2022-08-23 05:04:46
|
I learned, for example, ASN.1 DER/BER via http://luca.ntop.org/Teaching/Appunti/asn1.html which was pretty enough for my purpose
|
|
2022-08-23 05:05:04
|
I don't like this because this is very hard to maintain
|
|
|
|
_wb_
|
2022-08-23 05:05:30
|
Yes, at some point I want to make a jxl book that basically contains an annotated spec as one of its main parts
|
|
2022-08-23 05:05:50
|
But that only makes sense if the spec is bug-free and final
|
|
2022-08-23 05:06:27
|
Atm it's still a buggy draft of a spec, tbh
|
|
|
|
daxpedda
|
2022-08-23 05:07:18
|
I would be very happy to contribute to something like that, I'm doing my own little "guide" as I'm going along anyway
|
|
|
|
yurume
|
2022-08-23 05:11:12
|
just in case, are you writing a (presumably Rust) code in progress?
|
|
2022-08-23 05:11:40
|
or are you reading the draft to make sense of it?
|
|
|
|
daxpedda
|
2022-08-23 05:13:12
|
I'm currently just reading the draft and test parsing some things by hand to see if I understand it correctly
|
|
2022-08-23 05:13:31
|
but the plan is to write a Rust library
|
|
|
|
yurume
|
2022-08-23 05:14:56
|
yeah, I thought if you already had some code I would join
|
|
|
|
daxpedda
|
2022-08-23 05:15:25
|
I will make it public as soon as I write my first line of code and post it here!
|
|
2022-08-23 05:15:52
|
(just changed my name on this server to match my GitHub profile)
|
|
|
|
yurume
|
2022-08-23 05:16:55
|
I do have some code sketches in Rust, but not really working together
|
|
2022-08-23 05:17:57
|
it might be the case that I'm thinking too far beyond and don't make an actual progress
|
|
|
|
daxpedda
|
2022-08-23 05:20:13
|
would you be interested in re-using <@179701849576833024>s work? (I think I asked this before)
|
|
|
|
veluca
|
2022-08-23 05:20:54
|
You can also take over the repo and write whatever you want as far as I'm concerned 😉
|
|
|
|
yurume
|
2022-08-23 05:20:54
|
I'm actually not sure, I originally wanted to roll my own but that might not be really productive
|
|
|
|
improver
|
2022-08-23 05:20:59
|
i think veluca's stuff was very declarative & indirect
|
|
2022-08-23 05:21:05
|
and also faulty in places back when i checked
|
|
|
|
daxpedda
|
2022-08-23 05:21:13
|
I was thinking of forking it, cleaning it up and and continuing from there
|
|
|
|
yurume
|
2022-08-23 05:21:22
|
I do feel that Fields are very hard to understand
|
|
|
|
veluca
|
|
daxpedda
I was thinking of forking it, cleaning it up and and continuing from there
|
|
2022-08-23 05:22:02
|
You can also work in the repo directly 😛 (or at least as far as I'm concerned)
|
|
|
|
improver
|
2022-08-23 05:22:10
|
what have you written rust wise so far? maybe i could just integrate my rust stuff on top of that
|
|
|
|
veluca
|
2022-08-23 05:22:18
|
I can even review if you want
|
|
|
|
yurume
|
2022-08-23 05:22:41
|
if you want to see what I was aiming for, this is my sketch of SizeHeader:
```rust
#[derive(Debug)]
pub(crate) struct SizeHeader {
width: u32,
height: u32,
}
impl Decodable for SizeHeader {
fn read_from(&mut self, br: &mut BitReader) -> DecodeResult<SizeHeader> {
let div8 = read!(br, div8 = Bool());
let height = if div8 {
implied!(height = read!(br, h_div8 = 1 + u(5)) * 8)
} else {
read!(br, height = U32(1 + u(9), 1 + u(13), 1 + u(18), 1 + u(32)))
};
let width = match read!(br, ratio = u(3)) {
1 => height,
2 => (height as u64 * 6 / 5) as u32,
3 => (height as u64 * 4 / 3) as u32,
4 => (height as u64 * 3 / 2) as u32,
5 => (height as u64 * 16 / 9) as u32,
6 => (height as u64 * 5 / 4) as u32,
7 => height * 2,
_ => {
if div8 {
implied!(width = read!(br, w_div8 = 1 + u(5)) * 8)
} else {
read!(br, width = U32(1 + u(9), 1 + u(13), 1 + u(18), 1 + u(32)))
}
},
};
Ok(SizeHeader { width, height })
}
}
```
|
|
|
|
improver
|
2022-08-23 05:23:45
|
i have stuff like
```rust
pub fn read_size_header(&mod self) -> Result<SizeHeader> {
let mut x: SizeHeader;
let small = self.read_bool()?;
if small {
x.height = self.read_u(5)?;
x.height = (x.height + 1) * 8;
} else {
x.height = self.read_dist_u32(Bits(9), Bits(13), Bits(18), Bits(30))?;
x.height++;
}
let ratio = c.read_u(3)?;
if ratio == 0 {
if small {
x.width = self.read_u(5)?;
x.width = (x.width + 1) * 8;
} else {
x.width = self.read_dist_u32(Bits(9), Bits(13), Bits(18), Bits(30))?;
x.width++;
}
} else {
match ratio {
1 => x.width = x.height,
2 => x.width = x.height * 12 / 10,
3 => x.width = x.height * 4 / 3,
4 => x.width = x.height * 3 / 2,
5 => x.width = x.height * 16 / 9,
6 => x.width = x.height * 5 / 4,
7 => x.width = x.height * 2 / 1,
_ => unreachable!(),
}
// specification doesn't mention it but limit anyway
if x.width > 1<<30 {
return Err(Error::new(ErrorKind::InvalidData, "resulting width exceeds 2^30"));
}
}
Ok(x)
}
```
|
|
|
|
veluca
|
2022-08-23 05:24:31
|
(fwiw the spec defines level that *do* limit the width :P)
|
|
|
|
improver
|
2022-08-23 05:24:46
|
draft ive read didn't, i think
|
|
2022-08-23 05:24:50
|
oh
|
|
2022-08-23 05:24:55
|
level
|
|
2022-08-23 05:25:00
|
maybe not at decoder site tho
|
|
|
|
yurume
|
2022-08-23 05:25:00
|
yes, but SizeHeader doesn't have to know about profiles 😉
|
|
|
|
veluca
|
2022-08-23 05:25:22
|
Sure but my point was that if you want to limit it, best limit it to a level
|
|
|
|
improver
|
2022-08-23 05:25:25
|
it just doesnt feel fair to allow decoding something unintended
|
|
2022-08-23 05:26:38
|
and uhh i guess i should probably change it to something "probably limited by all levels mentioned in spec"
|
|
2022-08-23 05:26:48
|
either way it's impossible to represent without using ratio
|
|
2022-08-23 05:26:55
|
which is why ive put it there
|
|
2022-08-23 05:27:24
|
as u can read max of 2^30
|
|
|
|
yurume
|
2022-08-23 05:27:42
|
I do have the same sort of limit in j40, but only because I don't want to use `uint32_t` specifically for width
|
|
2022-08-23 05:28:25
|
in Rust signed and unsigned types do not mix so there is no reason to disallow 2^31 width
|
|
2022-08-23 05:28:31
|
at least in decoders
|
|
|
|
improver
|
2022-08-23 05:30:43
|
there is a reason imo - it opens doors for something not really properly defined and conceptually dirty - you can't specify it going so high without using ratio, so its not really 2^31
|
|
|
|
daxpedda
|
|
veluca
Sure but my point was that if you want to limit it, best limit it to a level
|
|
2022-08-23 05:31:09
|
I would love to take you up on the offer for review
I don't mind contributing directly to jxl-rs instead of forking it, but I would like to test first if I don't want to make any large scale changes and get your approval first
so I will do the following, I will come up with some sort of decoding proc-macro of my own and let you guys take a look to see if it's good or not, and you can tell me if it's a good improvements to integrate into jxl-rs
|
|
|
|
veluca
|
2022-08-23 05:31:30
|
Sounds good to me
|
|
2022-08-23 05:31:49
|
You can also drop the black magic to produce a .tex description of the fields, btw 😛
|
|
|
|
daxpedda
|
2022-08-23 05:32:07
|
ahaha, alright 😄
|
|
|
|
Jyrki Alakuijala
|
2022-08-23 05:53:46
|
please write to https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 why we need JPEG XL
|
|
2022-08-23 05:54:30
|
Chrome's next review to consider enabling/keeping/removing JPEG XL is coming up
|
|
2022-08-23 05:54:51
|
they will only read this bug and disregard other evidence
|
|
|
|
Fraetor
|
2022-08-23 06:14:38
|
This is what I've got. I don't know whether it is worth adding, as I'm hardly an authority.
https://www.frost.cx/2022/why-jpeg-xl
|
|
|
|
_wb_
|
2022-08-23 07:07:52
|
<@604964375924834314> what's the syntax again for telling cjxl that a ppm input should be interpreted as rec2100 PQ?
|
|
2022-08-23 07:08:03
|
(and does that still work in current cjxl?)
|
|
|
|
spider-mario
|
2022-08-23 07:08:38
|
```cjxl -x color_space=RGB_D65_202_Rel_PeQ```
and yes
|
|
|
|
_wb_
|
2022-08-23 07:10:15
|
Thanks!
|
|
2022-08-23 07:15:48
|
This is kind of hard to remember, we could use at least some info in the help screen about it, and maybe also some shorthand notation (something like `cjxl --input_color rec2100pq`, with other options being e.g. srgb, adobe98, prophoto, displayp3, dcip3, rec2100hlg, and it showing a list of those when passing an unrecognized one)
|
|
|
|
Jyrki Alakuijala
|
|
Fraetor
This is what I've got. I don't know whether it is worth adding, as I'm hardly an authority.
https://www.frost.cx/2022/why-jpeg-xl
|
|
2022-08-24 09:02:12
|
Consider linking your writing to the bug, just a single line comment is enough for Chrome guys to discover your opinions
|
|
|
|
gurpreetgill
|
|
Jyrki Alakuijala
Chrome's next review to consider enabling/keeping/removing JPEG XL is coming up
|
|
2022-08-24 02:18:31
|
hey Jyrki! Do we have an exact date on when's the next review!
|
|
|
Jim
|
2022-08-24 02:21:50
|
They are very different. Chrome devs are much more open to people posting their ideas as long as they are on-topic. On the other hand, Mozilla only wants "new" reasons that haven't been stated previously. Though you can vote for the issue if you support it (and I encourage you to do so to let them know there is a large interest in it). I've heard there's also a split among Firefox developers. Older developers are almost universally against adding any new formats while younger devs do want to add at least JXL and maybe WebP2 (though development of this format has slowed considerably over the last year).
|
|
|
|
Jyrki Alakuijala
|
|
gurpreetgill
hey Jyrki! Do we have an exact date on when's the next review!
|
|
2022-08-24 02:32:08
|
The review is on 2022-08-29
|
|
2022-08-24 02:32:46
|
it would be nice to get everything in long before the review, as soon as possible
|
|
2022-08-24 02:33:38
|
yes -- a very senior Chrome lead has asked me to collect the support in that bug
|
|
|
|
Traneptora
|
2022-08-27 04:51:50
|
just added my two cents
https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c68
|
|
|
|
Jim
|
2022-08-28 08:01:52
|
I've always thought JXL should be part of the Alliance for Open Media. I know it's basically controlled by Google and will likely never accept it, but having open formats that cover a large swath of things (low fidelity, high fidelity, lossless, video, etc) should be their goal. It shouldn't have just stopped at AV1/AVIF.
|
|
|
|
Fraetor
|
2022-08-28 09:48:20
|
JPEG XL was developed by the JPEG committee, which is a workiong group of the ISO. As such it is an ISO standard.
|
|
|
|
yurume
|
2022-08-28 09:59:11
|
the same standard can be submitted to multiple standard organizations in principle
|
|
|
|
Fraetor
|
2022-08-28 10:06:20
|
I think part of the issue is that the ISO has copyright over the standard.
|
|
2022-08-28 10:06:50
|
I think you could do it so long as you entirely rewrite the entire standard.
|
|
|
|
BlueSwordM
|
|
Jim
I've always thought JXL should be part of the Alliance for Open Media. I know it's basically controlled by Google and will likely never accept it, but having open formats that cover a large swath of things (low fidelity, high fidelity, lossless, video, etc) should be their goal. It shouldn't have just stopped at AV1/AVIF.
|
|
2022-08-28 11:20:43
|
The problem is not Google.
It is ISO itself.
|
|
|
|
w
|
2022-08-29 02:23:10
|
is this from the matrix bridge
|
|
|
|
username
|
2022-08-29 02:24:30
|
probably, I would assume that's why they are marked as a bot
|
|
|
|
w
|
2022-08-29 03:07:47
|
does anyone actually use matrix
|
|
|
|
diskorduser
|
|
|
w
|
2022-08-29 05:58:25
|
does anyone actually use matrix for this server
|
|
|
OkyDooky
|
|
|
Jyrki Alakuijala
|
2022-08-29 02:24:58
|
last chance to contribute to the fate of JPEG XL in Chrome before it gets decided in 30 min 🙂
|
|
2022-08-29 02:25:18
|
participate here https://bugs.chromium.org/p/chromium/issues/detail?id=1178058
|
|
|
Traneptora
just added my two cents
https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c68
|
|
2022-08-29 02:26:35
|
perfect!
|
|
|
Fraetor
JPEG XL was developed by the JPEG committee, which is a workiong group of the ISO. As such it is an ISO standard.
|
|
2022-08-29 02:28:06
|
99.999 % (or more) was developed outside of the JPEG committee and within Google and Cloudinary.
|
|
2022-08-29 02:28:31
|
these developments were then brought into the JPEG committee and standardized there
|
|
2022-08-29 02:29:04
|
nothing related to psychovisual modeling or compression was developed in the committee, that was all brought in
|
|
2022-08-29 02:29:28
|
the JPEG committee was smart enough not to change it, however
|
|
2022-08-29 02:30:08
|
there were some requirements that were reflected from requests by JPEG committee members, like ISOBMFF structure vs. plain code stream
|
|
2022-08-29 02:30:22
|
they did come up with the name
|
|
2022-08-29 02:31:11
|
also profiles (5 and 10) were probably a consequence of JPEG committee thinking
|
|
|
|
fab
|
2022-08-29 02:52:35
|
Made a stupid comment
|
|
|
|
_wb_
|
2022-08-29 02:53:57
|
The name "JPEG XL" was decided very early in the process, it was chosen before the Call for Proposals was issued and certainly before it was known on what proposals it would actually be based and who would be working on it.
|
|
2022-08-29 02:55:05
|
The main contribution of the JPEG committee was to bring together various proposals, including Pik and FUIF, and to 'force' us to collaborate and combine the best elements from both of them.
|
|
|
|
diskorduser
|
|
fab
Made a stupid comment
|
|
2022-08-29 03:02:18
|
Bruh
|
|
|
|
Jim
|
2022-08-29 03:51:22
|
Don't think it's as dumb as the next comment. There are multiple implementations being worked on and at least I've seen Rust and WASM implementations already in the wild. In most cases having a "native code" implimentation will be slower and make things more confusing for people. Just having a C/C++ wrapper library is common for many formats and keeps the speed of the original encoder/decoder.
If they are referring to having something like libjpeg-turbo, there's nothing stopping anyone from making such a thing... but why not contribute back to libjxl and help make it faster rather than making a separate library?
|
|
2022-08-29 03:51:40
|
Also, why would they be deciding on it "in 30 minutes?"
|
|
|
|
Fraetor
|
|
Jim
Also, why would they be deciding on it "in 30 minutes?"
|
|
2022-08-29 03:56:00
|
There is a chrome meeting going on about it.
|
|
|
|
Jim
|
|
|
fab
|
|
Fraetor
There is a chrome meeting going on about it.
|
|
2022-08-29 03:56:38
|
Explain more
|
|
|
|
Jim
|
2022-08-29 03:59:11
|
Likely just what was said - the Chrome dev team are having a meeting and one of the agenda items is whether to start adding JXL support to the browser. I'm crossing my fingers it's a yes. 🤞 <:JXL:805850130203934781> It's really needed.
|
|
|
|
username
|
2022-08-29 04:03:09
|
I should have left a comment but I ended up not sadly, I was going to focus on how useful the progressive decoding would be since with other formats loading them on a slow connection is painful
|
|
2022-08-29 04:03:20
|
and my internet sucks so being a able to see full images in a lower quality would be amazing, I have encountered progressive jpegs in the past and they are great in that way unlike other formats which very slowly load from top to bottem and I can't even tell what the images are supposed to be
|
|
|
|
_wb_
|
2022-08-29 04:04:19
|
Also crossing my fingers. I wish I could attend this meeting, but it looks like it's a Google-only thing.
|
|
|
|
fab
|
2022-08-29 04:05:57
|
The ssimulacra2 don't change output size
|
|
|
|
_wb_
|
2022-08-29 04:06:21
|
output size of what?
|
|
2022-08-29 04:06:35
|
it is not used in libjxl in any way
|
|
|
|
fab
|
2022-08-29 04:06:40
|
Cjxl s7 d1
|
|
2022-08-29 04:06:57
|
Ok
|
|
|
|
_wb_
|
2022-08-29 04:07:37
|
it is just a new metric, maybe at some point it can be added to benchmark_xl and/or as an option for e8/e9 encoding, but atm it's just a metric
|
|
|
|
fab
|
2022-08-29 04:08:14
|
Did jxl have video inter as some time like with jxl2
|
|
2022-08-29 04:08:40
|
Is there someone Who will try to use JPEG XL for video?
|
|
2022-08-29 04:11:01
|
Like JPEG himself
|
|
|
|
Jim
|
2022-08-29 04:11:04
|
JXL wasn't made for video. If you mean the animation portion, I think it's just one jxl image after another, don't think there any P frames.
|
|
|
|
fab
|
2022-08-29 04:11:07
|
Or someone big
|
|
2022-08-29 04:11:28
|
Like to fork it
|
|
|
|
Jim
|
2022-08-29 04:21:58
|
You can if you're looking to try, but I don't see why you would do that. AV1 was designed for video and works well. JXL would likely produce a significantly larger file that may not be good for streaming - granted, it would likely be higher visual quality.
|
|
|
|
BlueSwordM
|
|
Jim
You can if you're looking to try, but I don't see why you would do that. AV1 was designed for video and works well. JXL would likely produce a significantly larger file that may not be good for streaming - granted, it would likely be higher visual quality.
|
|
2022-08-29 04:29:05
|
Indeed.
|
|
2022-08-29 04:29:25
|
The biggest inter feature would be delta coding, which is what ffv1 has as well.
|
|
|
|
fab
|
2022-08-29 04:34:08
|
A full hd video of jxl can be decoded on i3 330m or xiaomi mi 11 lite 5g?
|
|
2022-08-29 04:35:00
|
Someone has made it possible?
|
|
|
|
JendaLinda
|
2022-08-29 04:44:33
|
I would use animated JXL in lossless mode for small animations. I suppose the goal was to replace GIF and APNG.
|
|
|
|
Jim
|
2022-08-29 04:47:55
|
Added my comment, a little late likely, but I noticed nothing was said about viewport sizes & container query units that would fit well with the responsive sizing feature.
|
|
|
|
_wb_
|
2022-08-29 05:03:41
|
I wish there was a public cross-browser discussion platform where decisions could be made on what codecs to support or not, on a basis of evidence and rational arguments.
|
|
2022-08-29 05:04:47
|
But sadly, Chrome just does its own thing, Safari does its own thing, and the others don't really have any impact at all on the web platform.
|
|
|
|
Demez
|
2022-08-29 05:08:30
|
that would be quite nice, yeah
|
|
|
|
paperboyo
|
2022-08-29 05:08:35
|
Is the scenario presented in https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c74 possible (browser just downloading not-yet-downloaded portion of an already-partially-downloaded file) how JXL progressive does already work? Or how it could work (if browsers/servers complied)? Or is it sci-fi?
|
|
|
|
_wb_
|
2022-08-29 05:21:02
|
It is how it could work. And it does come at some cost in filesize and decode speed, and requires browsers/servers to implement new logic. But the bitstream certainly does allow encoding e.g. a 1x image in a first pass and a 2x in a second pass, without redundantly storing the 1x info twice.
|
|
2022-08-29 05:31:24
|
Progressive and responsive are basically the same thing, and in theory you could even do this with progressive JPEGs, but that would be not very effective since 1) JPEG has no TOC so you need to externalize that functionality, 2) you need to respect zigzag order in progressive scan scripts in JPEG, which is not optimal for responsive images, and you also cannot revisit coefficient bits once they have been signaled (unlike jxl where you can e.g. zero coeffs in the 1x image but then make them nonzero in the 2x image)
|
|
2022-08-29 05:33:24
|
And of course 3) JPEG only does 8x8 DCT and has poor DC compression, so it is not very effective for 1:2 and certainly not for 1:4.
|
|
|
|
Jim
|
2022-08-29 06:20:40
|
On the server side, nothing needs to be supported. If content ranges are supported (most servers already support this), it will reduce the amount of bandwidth needed. Otherwise it has to re-send the entire image file each time a new viewport or container size is requested.
|
|
2022-08-29 06:27:00
|
Also, it might increase the filesize some, but its likely still far less total size than having 5-10 of the same image for each size you want to support.
|
|
|
|
_wb_
|
2022-08-29 06:41:03
|
For powers of two size factors it works well. For other factors not really. So you might still want to have something like a 200px, 400px, 800px image in one jxl file, and a 300px, 600px, 1200px image in another jxl file.
|
|
|
|
Traneptora
|
|
Jim
JXL wasn't made for video. If you mean the animation portion, I think it's just one jxl image after another, don't think there any P frames.
|
|
2022-08-29 07:58:53
|
sorta
|
|
2022-08-29 07:59:31
|
subsequent frames can be smaller than the viewport, which only overwrites pixels within their rectangle
|
|
2022-08-29 07:59:51
|
but otherwise yes
|
|
|
|
_wb_
|
2022-08-29 08:01:57
|
well you can also do kAdd frame blending (i.e. subtract the previous frame from the current and encode the difference), use patches, and store up to 4 earlier frames to use as a basis for the next one
|
|
2022-08-29 08:02:25
|
for stuff like sprite-based animations, it's probably quite powerful
|
|
2022-08-29 08:03:34
|
something like a C64 or SNES emulator could in principle exploit this to make quite compact screen recordings since it knows what the sprites are when hardware sprite blitting is used...
|
|
2022-08-29 08:04:42
|
but it is true that all the inter tools of jxl are only there because they can also be useful for (layered) still images
|
|
2022-08-29 08:05:20
|
and we don't have any jxl encoder that tries to do something clever for animation
|
|
|
|
Jim
|
2022-08-29 08:13:01
|
Would be interesting if you could store the sprites in different hidden layers then size/position them in the visible frame as needed.
|
|
|
remsleep
|
2022-08-29 08:16:45
|
Likely just what was said the Chrome dev
|
|
|
|
_wb_
|
|
Jim
Would be interesting if you could store the sprites in different hidden layers then size/position them in the visible frame as needed.
|
|
2022-08-29 09:17:04
|
You can do that. There are kReferenceOnly frames exactly for that purpose, used only to use as a source for Patches.
|
|
|
|
Jyrki Alakuijala
|
|
fab
Did jxl have video inter as some time like with jxl2
|
|
2022-09-01 09:55:42
|
we don't have motion, but we can blend frames which may allow primitive delta coding -- we tried it out in late 2018 and out of ~13 sample videos one was better than h265
|
|
|
_wb_
well you can also do kAdd frame blending (i.e. subtract the previous frame from the current and encode the difference), use patches, and store up to 4 earlier frames to use as a basis for the next one
|
|
2022-09-01 09:56:52
|
this is pretty closely what we did -- we may have reused the adaptive quantization matrix, too, don't remember any more
|
|
2022-09-01 09:57:18
|
the promising results of that experimentation led to the kAdd frame
|
|
|
|
fab
|
2022-09-01 09:58:06
|
Does JPEG XL beat pingo a30 optimizer
|
|
2022-09-01 09:58:20
|
Why s7 is blocky in modular
|
|
2022-09-01 09:58:35
|
Is too fast at moment
|
|
|
|
Jyrki Alakuijala
|
2022-09-01 09:59:57
|
pingo is perfect at what it does, but it does a different thing than JPEG XL
|
|
2022-09-01 10:01:08
|
modular is not a competitive way to store lossy compression -- it is great for control fiels, lossless and palette-lossy
|
|
2022-09-01 10:01:40
|
if you start making loss in modular, it is okeyish in the psnr sense, but it will not look beautiful
|
|
|
|
fab
|
2022-09-01 10:01:56
|
Yes but some parts of jxl is modular
|
|
2022-09-01 10:02:38
|
Also has error this article https://en.m.wikipedia.org/wiki/JPEG_XL
|
|
2022-09-01 10:02:47
|
Because i added some italian things
|
|
2022-09-01 10:03:11
|
In the texhbical details
|
|
2022-09-01 10:03:22
|
And i do not if it will change
|
|
2022-09-01 10:03:54
|
Someone probably will readapt it
|
|
2022-09-01 10:04:24
|
Does it get read by JPEG XL commitee
|
|
2022-09-01 10:04:33
|
Does JPEG XL commitee exist
|
|
2022-09-01 10:04:42
|
Or is called only JPEG
|
|
2022-09-01 10:25:22
|
Pingo preserves more tattoo but quality is too sharp and does only aitomatic detection
|
|
|
|
_wb_
|
|
fab
Does JPEG XL commitee exist
|
|
2022-09-01 11:11:23
|
there's a JPEG XL Ad-Hoc Group within the JPEG committee (which is formally known as Working Group 1 of SubCommittee 29 of the Joint Technical Committee 1 of the International Organization for Standardization and the International Electrotechnical Commission, i.e. ISO/IEC JTC1 / SC29 / WG1)
|
|
2022-09-01 11:12:45
|
using Modular for visual data is not really recommended in general, at least for photographic material, VarDCT will perform significantly better, both because it has more suitable coding tools and because it has a perceptually tuned encoder.
|
|
|
|
fab
|
2022-09-01 12:02:39
|
|
|
2022-09-01 12:03:06
|
Jxl s9 d1 vardct
|
|
2022-09-01 12:04:50
|
2 minutes and 10
|
|
2022-09-01 12:05:03
|
For 1 minutes and 40 of audio
|
|
2022-09-01 12:05:15
|
Average ram used 710 mb
|
|
2022-09-01 12:11:38
|
2.054178
|
|
2022-09-01 12:11:42
|
Average
|
|
2022-09-01 12:11:55
|
I'm doing heavier things
|
|
2022-09-01 12:12:04
|
Quality will be greater
|
|
2022-09-01 12:15:01
|
|
|
2022-09-01 12:16:55
|
That only modular 128 kbps
|
|
2022-09-01 12:19:04
|
From 132 kbps and up is decent
|
|
2022-09-01 12:20:28
|
E 9 q 96 gaborish 0 epf 2 dots 0 fsster decoding 1
|
|
2022-09-01 12:20:37
|
2 gb RAM used
|
|
2022-09-01 12:21:28
|
Though Is impressive like wma 174 kbps
|
|
2022-09-01 12:24:51
|
Though i think is 258 kbps at least
|
|
|
|
_wb_
|
2022-09-01 12:26:33
|
lol what are you doing? compressing audio with an image codec?
|
|
|
|
fab
|
2022-09-01 12:27:11
|
The volume will be different
|
|
2022-09-01 12:27:42
|
But i wanted to test if is audible
|
|
2022-09-01 12:35:11
|
|
|
2022-09-01 12:35:27
|
Without vardct is worse percetivly
|
|
|
|
_wb_
|
2022-09-01 01:14:11
|
if you take uncompressed audio and interpret it as an uncompressed image, I'm sure you can do something. E.g. take an uncompressed 16-bit wav, remove the wav header, replace it with a 16-bit ppm header, and voila, it is an image now
|
|
2022-09-01 01:14:53
|
the only thing is how to turn the 1D audio into a 2D image — I suppose you can just pad it and pick an arbitrary number for the width to make the image more or less square
|
|
|
|
Fraetor
|
2022-09-01 01:17:25
|
For music maybe you could have it split where melodies change or something. That might help compression.
|
|
|
|
_wb_
|
2022-09-01 02:01:42
|
heh what is relevant for visual compression is very likely not very relevant for audio compression
|
|
|
ExpedientFalcon
|
2022-09-02 04:35:05
|
Hi, I'm looking for any docs specifically on the XYB colorspace, if someone has links for that? I'm looking to see if it can be used for optimizations in other video coding applications.
|
|
2022-09-02 04:50:54
|
Neat, thanks! I also found a tweet which links to how the conversion is done in butteraugli, which is hugely helpful, although it's from Linear RGB to XYB. *Ideally* there's a direct path from YUV to XYB but I'm not sure if that's feasible.
|
|
|
|
BlueSwordM
|
2022-09-02 05:15:57
|
Yeah, it'd be really nice if that actually existed, as it would make it far easier to use in other applications that are sadly limited to YCbCr sources.
|
|
|
|
_wb_
|
2022-09-02 05:21:40
|
Yuv to nonlinear rgb is easy enough
|
|
|
|
yurume
|
2022-09-02 05:24:16
|
XYB-to-RGB transformation is basically a non-linear per-channel function followed by a 3x3 matrix multiplication, and RGB-to-YCbCr is also just a 3x3 matrix multiplication so it can be combined
|
|
|
|
BlueSwordM
|
2022-09-02 05:25:18
|
Basically, here's what we want to do:
YCbCr to XYB at input, XYB to YCbCr at output 😄
|
|
|
|
yurume
|
2022-09-02 05:26:47
|
jxl allows for different XYB transformation parameters, which makes it possible to produce an.... interesting image.
|
|
2022-09-02 05:37:22
|
as it stands I think jxl allows for free linear transformation across channels and arbitrary 3x3 convolution
|
|
2022-09-02 05:38:10
|
for example you can abuse gaborish to make a sobel-like filter
|
|
|
|
_wb_
|
2022-09-02 05:55:11
|
Yes, I have been thinking about using non-default gaborish to do a reversible sharpening/blurring effect just by fiddling with the header
|
|
2022-09-02 05:55:40
|
And similarly you could do some kinds of color adjustments by fiddling with custom xyb weights
|
|
2022-09-02 05:56:37
|
(that you could actually also do in jpeg/png by modifying the icc profile, I suppose)
|
|
|
|
Traneptora
|
|
ExpedientFalcon
Hi, I'm looking for any docs specifically on the XYB colorspace, if someone has links for that? I'm looking to see if it can be used for optimizations in other video coding applications.
|
|
2022-09-02 09:19:08
|
https://discord.com/channels/794206087879852103/794206087879852106/1002706317061922909
|
|
2022-09-02 09:21:05
|
in particular, the opsin absorbance matrix can be left-multiplied by the yuv -> rbg matrix
|
|
2022-09-02 09:21:43
|
since this is a composition of a affine transforms, you can bake them together
|
|
2022-09-02 09:21:56
|
do note it is linear sRGB
|
|
2022-09-02 09:23:10
|
so if you have a nonlinear transfer, like Rec 709 you must first convert it to RGB, then apply the transfer to linearize it, then convert it to Opsin space before cuberooting
|
|
|
|
ExpedientFalcon
|
2022-09-02 09:23:36
|
Ah I see. That's a bit of a pain. I was hoping we'd be able to use magic math to make it one op.
|
|
2022-09-02 09:24:19
|
Given that generally we'll be working with either Rec.709 or PQ.
|
|
2022-09-02 09:24:57
|
Still, thanks for the info! Very helpful
|
|
|
|
Brinkie Pie
|
|
Jim
On the server side, nothing needs to be supported. If content ranges are supported (most servers already support this), it will reduce the amount of bandwidth needed. Otherwise it has to re-send the entire image file each time a new viewport or container size is requested.
|
|
2022-09-03 10:30:33
|
I made a Proof of Concept of this with JPEG and service workers a few years ago, but both Chrome and Firefox were a bit buggy and sometimes rendered images as all-white when scrolling.
[update: certainly not my finest piece of code; https://ba.jtbrinkmann.de/gallery/ loads a JSON with the list of images incl. byte count for each progressive scan, then uses `fetch` with a range header to load only a portion of the image file, depending on the dimensions needed; https://ba.jtbrinkmann.de/gallery/sw.html also includes a (broken) service worker implementation, which automatically sets the range headers depending on parameters in the image url, so you can use it in `<img>` for example]
|
|
|
|
BlueSwordM
|
2022-09-04 06:33:51
|
<@794205442175402004> How exactly is in-block RDO done currently in libjxl? I know it sounds like a strange question, but I'm currently looking at the differences in use and aptitude of in-block RDO vs normal block RDO, and it is rather interesting to see the differences in approach and how it is done.
|
|
|
|
_wb_
|
2022-09-04 07:54:48
|
<@179701849576833024>, <@532010383041363969> and @szabadka#0582 know more about that than me. Afaiu, we always first do block type selection (per 64x64 macroblock, segment it into the various block sized and types), then select the adaptive quantization weights. At effort 8+, this is done iteratively by evaluating butteraugli and adjusting weights. At lower effort, some kind of heuristics select the quantweights directly.
|
|
|
|
veluca
|
2022-09-04 08:48:35
|
Nah, we select the weights first 😉
|
|
|
|
_wb_
|
2022-09-04 09:05:48
|
Really? Weights are chosen before blocktype is known?
|
|
2022-09-04 09:16:40
|
Why do I keep misremembering this
|
|
|
|
yurume
|
2022-09-04 10:02:21
|
I don't have a copy of 18181-2 so I'm not very sure about this, but is the header of the last codestream box (either jxlc or jxlp) guaranteed to be early in the container in normal cases? I know that an intentionally crafted container has no such guarantee, but if most container-based images utilizing jxlp have such guarantee my current design will surely work.
|
|
|
|
_wb_
|
2022-09-04 11:05:01
|
Currently libjxl makes one jxlp per frame in case of animation, so the last one can be arbitrarily far
|
|