|
username
|
2024-09-17 02:39:42
|
I feel like the Android team is closer to the Chrome team rather then the Research team. like AVIF got gainmap support so quickly that I found out about it relatively late
|
|
|
AccessViolation_
|
2024-09-17 02:39:43
|
consolidation is not the right word
|
|
|
|
username
|
|
AccessViolation_
If it's any consolidation I believe Google's gain mapped JPEGs are in the process of being standardized. Downside is, that isn't going to accelerate JXL support
|
|
2024-09-17 02:41:01
|
thankfully it seems like the standardized version is going to have support for "inverse gainmaps" (aka HDR to SDR rather then SDR to HDR). although either way I still don't like really like them
|
|
|
A homosapien
|
|
AccessViolation_
consolidation is not the right word
|
|
2024-09-17 02:41:13
|
Consolation is the word you're looking for.
|
|
|
|
AccessViolation_
|
|
username
thankfully it seems like the standardized version is going to have support for "inverse gainmaps" (aka HDR to SDR rather then SDR to HDR). although either way I still don't like really like them
|
|
2024-09-17 02:42:50
|
That's surprising, I thought the whole point was that they would look fine as SDR images with backwards compatibility for normal JPEG decoders. That wouldn't work with inverse gainmaps I think
|
|
|
|
username
|
|
AccessViolation_
That's surprising, I thought the whole point was that they would look fine as SDR images with backwards compatibility for normal JPEG decoders. That wouldn't work with inverse gainmaps I think
|
|
2024-09-17 02:48:03
|
that was my thought as well but it seems like gainmaps are starting to get used in newer formats that don't even have to consider backwards compat and already have native HDR support built in which doesn't make sense to me but I have seen discussions that apparently say that the only other benefit to gainmaps is that they give more control over the tonemapping process. so for formats that have native HDR and high bit depth support I would much rather have a inverse gainmap (though If I had the choice I would rather not have any type of gainmap)
|
|
|
jonnyawsom3
|
|
Android support ticket https://issuetracker.google.com/issues/259900694
|
|
2024-09-17 02:48:21
|
At the very least we could push for this :P https://sourceforge.net/p/opencamera/tickets/1019/
It'd be janky as hell though, probably taking quality 100 jpegs and then encoding as d1 JXLs
|
|
|
KKT
|
2024-09-17 03:58:17
|
So this just came down the pipe. Tested and it includes support for JXL HDR in Keynote ~~and Pages~~ (only Keynote is seems).
|
|
|
_wb_
|
2024-09-17 04:05:01
|
That is nice, now I no longer have to use huge 16-bit PNG files in Google Slides on Chrome if I want to show HDR images in a presentation 🙂
|
|
|
|
KKT
|
2024-09-17 04:40:39
|
Will have to run some tests to see if you can export to anything that supports it.
|
|
2024-09-17 04:40:58
|
Hah. That was easy.
|
|
2024-09-17 04:44:44
|
Whelp. May need to dig deeper. It's says it's outputting HDR, but doesn't look like it to me. Besides PQ, you can also choose Dolby Vision when you select HEVC as the format.
|
|
|
HCrikki
|
|
username
apparently Final Fantasy 16 (a Video game) has support for JPEG XL‽
https://x.com/NotNite/status/1825577272943751288
|
|
2024-09-18 12:33:21
|
its now released, with demo still accessible.
maybe worth checking their jxl screenshotting support. there's a mod that improves jxl quality further
|
|
|
|
jonnyawsom3
|
|
HCrikki
its now released, with demo still accessible.
maybe worth checking their jxl screenshotting support. there's a mod that improves jxl quality further
|
|
2024-09-18 01:14:10
|
We talked about it before https://discord.com/channels/794206087879852103/803574970180829194/1276785975044870144
|
|
|
CrushedAsian255
|
2024-09-18 01:54:23
|
wtf lmao
|
|
2024-09-18 01:54:42
|
AVIF and lossless are 2 words that should not be in the same sentence
|
|
|
Demiurge
|
|
AccessViolation_
If it's any consolidation I believe Google's gain mapped JPEGs are in the process of being standardized. Downside is, that isn't going to accelerate JXL support
|
|
2024-09-18 07:22:44
|
Wasn't it already standardized long ago by backward compatible extensions in JPEG XT
|
|
|
veluca
tbh threads are not the part that scare me in ~any compression-related C++ codebase
|
|
2024-09-18 07:24:50
|
what then, error handling? functions that take an unbounded amount of memory or time to return?
|
|
|
|
veluca
|
2024-09-18 07:25:14
|
spatial safety, mostly
|
|
|
|
CrushedAsian255
|
|
username
I feel like the Android team is closer to the Chrome team rather then the Research team. like AVIF got gainmap support so quickly that I found out about it relatively late
|
|
2024-09-18 07:48:13
|
Why does AVIF need gain maps?
|
|
2024-09-18 07:48:20
|
It’s a native HDR format -_-
|
|
|
Quackdoc
|
|
CrushedAsian255
It’s a native HDR format -_-
|
|
2024-09-18 07:50:21
|
Gainmaps are for images that are displayed on both SDR and HDR displays
|
|
2024-09-18 07:51:09
|
no single tonemapping method exists that isn't crap. Just "OK" at best. So we use gainmaps as it looks better
|
|
|
|
CrushedAsian255
|
2024-09-18 07:51:26
|
Is this SDR to HDR or HDR to SDR?
|
|
|
|
username
|
2024-09-18 07:53:39
|
either direction (from what I understand at least). though "inverse" gainmaps (HDR to SDR) ones are better I would say since they actually allow the image format in question to take advantage of it's native support for HDR and higher bit depths
|
|
|
|
Quackdoc
|
2024-09-18 08:03:45
|
bitdepth isn't really effected, the transfer would have the biggest impact
|
|
|
|
jonnyawsom3
|
2024-09-18 03:27:26
|
New proposal is up https://discord.com/channels/794206087879852103/794206087879852106/1285973344042352693, yet again they've just posted links to the old ones so we'll have to make a case in the comments https://github.com/web-platform-tests/interop/issues/700
|
|
|
yoochan
|
2024-09-18 05:12:24
|
Nice ! Wasn't the chrome/blink status: _never! See you in hell!_ ? Did I miss something?
|
|
|
|
KKT
|
2024-09-18 08:08:45
|
So speaking of Google. We should remember that when Apple didn't support RCS, they created an entire website built to harass them until they did: https://www.android.com/get-the-message/
|
|
2024-09-18 08:08:59
|
I just went back to check it to see what they're doing now Apple has released support.
|
|
2024-09-18 08:10:02
|
What would be really funny is if we duplicated the entire site and switched it over to JPEG XL for RCS and called Google the asshole…
|
|
2024-09-18 08:10:45
|
This was the important part that's been removed:
Clicking on a link that says "Help @Apple #GetTheMessage" takes you to Twitter where a tweet has already been composed for you to send to Apple. The text says, "@Apple, stop breaking my texting experience. #GetTheMessage."
|
|
|
|
_wb_
|
2024-09-18 08:14:24
|
wow, hadn't seen that page before, looks quite aggressive
|
|
2024-09-18 08:16:12
|
I don't really like that style. But I do appreciate the irony and how funny it would be to give Android (and Chrome, I guess) a "cookie from their own dough" (as we say in Dutch)
|
|
|
|
Quackdoc
|
|
|
HCrikki
|
2024-09-18 08:26:45
|
id caution about aggravating tensions. to be fair, the original removal from chromium was motivated by supposed low ecosystem interest (origin trials shouldve been opted into for chrome and firefox. big mistake not doing so). that always suggested this was a position subject to re-evaluation at a later time
|
|
|
|
Quackdoc
|
2024-09-18 08:27:38
|
android can't be pushed by that stuff, it's largely by manufactures that decide the direction of android.
|
|
2024-09-18 08:27:56
|
if they were to be petty, samsung and co would be pretty angry at that
|
|
|
|
KKT
|
|
_wb_
wow, hadn't seen that page before, looks quite aggressive
|
|
2024-09-18 08:38:34
|
You should have seen it before Apple agreed to RCS.
And yeah, it was seen as Google putting this out, not Android really.
I still bet someone is going to sue them in Europe, since they're a gatekeeper, they measure the speed of your site and insist on penalizing you if you're not using webp (haven't looked if it's been updated to include AVIF). There is clear conflict and monetary damages…
|
|
|
|
CrushedAsian255
|
|
_wb_
I don't really like that style. But I do appreciate the irony and how funny it would be to give Android (and Chrome, I guess) a "cookie from their own dough" (as we say in Dutch)
|
|
2024-09-18 08:46:18
|
Huh, never heard of that phrasing, where I am it’s “a taste of their own medicine” but cookies sound way tastier than medicine
|
|
|
KKT
You should have seen it before Apple agreed to RCS.
And yeah, it was seen as Google putting this out, not Android really.
I still bet someone is going to sue them in Europe, since they're a gatekeeper, they measure the speed of your site and insist on penalizing you if you're not using webp (haven't looked if it's been updated to include AVIF). There is clear conflict and monetary damages…
|
|
2024-09-18 08:46:56
|
They actually hinder your sites ranking if they don’t detect WebP images?
|
|
|
|
KKT
|
2024-09-18 08:47:35
|
If you're not using "modern image formats"
|
|
|
|
HCrikki
|
2024-09-18 09:49:11
|
web.dev gives them that coercive control. like with amp, your light page can have its visibility decreased even though its much smaller than if it included webp/avif and google scripts (sites using adsense get consistently high priority in results even if theyre content farms)
|
|
|
|
KKT
|
2024-09-18 09:54:16
|
@Google #GetThePicture
|
|
|
|
Demiurge
|
|
HCrikki
id caution about aggravating tensions. to be fair, the original removal from chromium was motivated by supposed low ecosystem interest (origin trials shouldve been opted into for chrome and firefox. big mistake not doing so). that always suggested this was a position subject to re-evaluation at a later time
|
|
2024-09-19 12:36:09
|
It's literally just one guy and his team from on2, who was put in charge of newly made "chrome codec team" after google on2 acquisition. Jim Bankowski, same guy who fast tracked and ramrodded webp and avif formats that had zero ecosystem interest compared to jxl. His source was "trust me bro"
|
|
2024-09-19 12:36:48
|
The decision was obviously made in bad faith and he's just taking advantage of his lack of oversight and accountability
|
|
2024-09-19 12:37:44
|
Even his own comparison shows AVIF failing at ssimu2 and butteraugli
|
|
2024-09-19 12:38:22
|
When sneyers asked about that he got no response.
|
|
2024-09-19 12:41:27
|
Bankowski's under no obligation to explain his decision or acknowledge any faults
|
|
2024-09-19 12:41:42
|
He is god of the internet now
|
|
2024-09-19 12:43:49
|
He created vp8 so us mortals better respect him
|
|
|
|
CrushedAsian255
|
2024-09-19 01:00:45
|
Who made VP9?
|
|
|
|
Demiurge
|
2024-09-19 02:08:50
|
Pretty sure it was the same team
|
|
|
Rega
|
|
New proposal is up https://discord.com/channels/794206087879852103/794206087879852106/1285973344042352693, yet again they've just posted links to the old ones so we'll have to make a case in the comments https://github.com/web-platform-tests/interop/issues/700
|
|
2024-09-20 11:01:53
|
This might be a dumb question but how to vote?
|
|
|
|
yoochan
|
2024-09-20 11:05:15
|
you can click on 👍 on the first post, however you need a github account to do so
|
|
|
|
Rega
|
|
yoochan
you can click on 👍 on the first post, however you need a github account to do so
|
|
2024-09-20 04:30:50
|
Thats it?
|
|
2024-09-20 04:31:04
|
I've already done that
|
|
|
|
Quackdoc
|
2024-09-20 05:08:18
|
99% sure that thumbs up, thumbs down, don't actually do anything. I'm pretty sure this is all a behind closed doors can happen.
|
|
|
gb82
|
|
KKT
@Google #GetThePicture
|
|
2024-09-21 04:15:50
|
Oh that’s great tho
|
|
|
|
Demiurge
|
2024-09-21 04:42:48
|
It's kinda unfair to blame "Google" for this
|
|
2024-09-21 04:43:13
|
It's literally just one guy and his team and his fragile ego and pet project feeling threatened.
|
|
2024-09-21 04:43:54
|
If he had any oversight or accountability this wouldn't be happening
|
|
2024-09-21 04:44:44
|
He was put in charge of the newly formed "chrome codec team" after the on2 acquisition
|
|
2024-09-21 04:50:30
|
Even though I don't like Google and think they are a global evil empire and military power, it was literally the decision of just one guy to remove <:JXL:805850130203934781> support from Chrome.
|
|
2024-09-21 04:51:37
|
Google Research Zurich funded (probably most of?) <:JXL:805850130203934781> development
|
|
|
|
HCrikki
|
2024-09-21 05:12:35
|
those favorable can still speak for it or show some support, even if thats not what theyre putting on their own small shortlist
|
|
|
|
Rega
|
|
Quackdoc
99% sure that thumbs up, thumbs down, don't actually do anything. I'm pretty sure this is all a behind closed doors can happen.
|
|
2024-09-21 11:39:56
|
If this is all a behind closed doors I don't think JXL would've got the highest votes in 2024
|
|
|
|
Quackdoc
|
|
Rega
If this is all a behind closed doors I don't think JXL would've got the highest votes in 2024
|
|
2024-09-21 11:49:10
|
im not sure I understand what you mean
|
|
|
Foxtrot
|
2024-09-21 11:55:29
|
tbh, i think right now the rust implementation for firefox if the best step for jxl adoption... if firefox adopts it then it will be chrome vs everyone else which means better position for jxl
|
|
|
|
CrushedAsian255
|
|
Foxtrot
tbh, i think right now the rust implementation for firefox if the best step for jxl adoption... if firefox adopts it then it will be chrome vs everyone else which means better position for jxl
|
|
2024-09-21 11:57:34
|
just wondering, what is wrong with `jxl-oxide` that makes it unsuited for firefox?
|
|
|
|
Foxtrot
|
2024-09-21 11:59:51
|
firefox doesnt want to depend on implementation from "just some random internet guy", sorry tirr 😢
for them to consider adding jxl it needs to be done by dependable team that will promise to keep supporting it in the future, which right now is the official libjxl team
|
|
2024-09-21 12:00:35
|
of course jxl-oxide is good starting point and its used as one
|
|
2024-09-21 12:01:08
|
but it still needs to be redone, see this https://discord.com/channels/794206087879852103/804324493420920833/1286781880573628537
|
|
|
|
Demiurge
|
2024-09-21 12:41:00
|
jxl-oxide is great and perfectly fine and even used in jxl-winthumb but no one has ever wrote glue code for sticking it into firefox yet, and it looks like veluca might have plans to write another heavily optimized jxl codec that uses less memory.
|
|
|
|
yoochan
|
|
Foxtrot
tbh, i think right now the rust implementation for firefox if the best step for jxl adoption... if firefox adopts it then it will be chrome vs everyone else which means better position for jxl
|
|
2024-09-21 12:49:09
|
I asked the exact same question and veluca answered something about memory optimisations. I think the plan is to benefit from the experience of tirr but to start from the rust project started, abandoned and ressucitated by veluca
|
|
|
|
veluca
|
2024-09-21 01:00:48
|
well, also to benefit from the libjxl experience 🙂
|
|
|
|
CrushedAsian255
|
2024-09-21 01:02:49
|
Is libjxl still going to be maintained or is jxl-rs going to take over?
|
|
|
|
Demiurge
|
2024-09-21 01:03:03
|
veluca seems to have a nasty habit of writing ridiculously fast, extremely optimized compression codecs! He's a menace!
|
|
|
|
CrushedAsian255
|
2024-09-21 01:03:16
|
I’m guessing writing it in Rust is more implicated than just translating line by line from C?
|
|
2024-09-21 01:03:26
|
Something about data structures and memory layouts
|
|
|
lonjil
|
2024-09-21 01:03:53
|
Some parts have already been copied from jxl-oxide
|
|
|
|
Demiurge
|
|
CrushedAsian255
Is libjxl still going to be maintained or is jxl-rs going to take over?
|
|
2024-09-21 01:04:37
|
honestly I hope jxl-rs takes over :P as much as I hate the rust meme, a fresh rewrite is always nicer than old spaghetti code
|
|
|
|
CrushedAsian255
|
2024-09-21 01:05:11
|
Is libjxl turned into spaghettis
|
|
|
|
Demiurge
|
2024-09-21 01:05:26
|
...(yes)
|
|
|
|
CrushedAsian255
|
2024-09-21 01:05:34
|
I thought it was my inexperience with C, I can now blame it on the libjxl devs! /s
|
|
|
|
Demiurge
|
2024-09-21 01:05:45
|
:)
|
|
2024-09-21 01:06:27
|
Yes shame on them, they should be ashamed for giving us a free codec that's better than every other proposal >:(
|
|
|
|
CrushedAsian255
|
|
Demiurge
Yes shame on them, they should be ashamed for giving us a free codec that's better than every other proposal >:(
|
|
2024-09-21 01:07:30
|
Yeah! Why can’t we all just use HEIC!! This is dumb, I quit
|
|
|
|
Demiurge
|
2024-09-21 01:08:57
|
we should all switch to Targa
|
|
|
|
CrushedAsian255
|
|
Demiurge
we should all switch to Targa
|
|
2024-09-21 01:09:32
|
I prefer Gzipped ppm files tbh
|
|
|
|
veluca
|
2024-09-21 01:11:04
|
Eh, the libjxl code definitely suffers from 7+ years of incremental evolution, a fresh start has its benefits 😛 (which is another reason not to translate it line by line)
|
|
|
|
CrushedAsian255
|
2024-09-21 01:11:32
|
Will JXL-rs ever have encode or is it just going to be decoder
|
|
|
|
Foxtrot
|
2024-09-21 01:11:49
|
ever is long time 😄
|
|
|
|
CrushedAsian255
|
2024-09-21 01:12:02
|
Is it in the current or near future project scope
|
|
|
|
veluca
|
2024-09-21 01:13:02
|
neither current nor near future
|
|
2024-09-21 01:13:09
|
now, am I thinking about it? mayyyybe
|
|
|
|
Demiurge
|
2024-09-21 01:13:49
|
come now, you know you wanna :)
|
|
|
|
veluca
|
2024-09-21 01:14:13
|
fwiw, the libjxl *encoder* is much more of a mess than the decoder (and I am responsible for a good fraction of that mess :P)
|
|
|
|
Demiurge
|
2024-09-21 01:14:42
|
the funny thing is that writing an encoder is way easier than writing a decoder
|
|
|
|
lonjil
|
2024-09-21 01:15:20
|
Writing *an* encoder is easier. Writing a good encoder is much harder.
|
|
|
|
CrushedAsian255
|
2024-09-21 01:15:25
|
I guess, technically you can make a really simple modular encoder with only a free steps
|
|
|
lonjil
Writing *an* encoder is easier. Writing a good encoder is much harder.
|
|
2024-09-21 01:15:29
|
This
|
|
2024-09-21 01:16:00
|
You can spend indefinite amount of time optimising the encoder for ever more specific niches to get +0.01% on benchmarks
|
|
|
Suigintou
|
|
Demiurge
It's literally just one guy and his team and his fragile ego and pet project feeling threatened.
|
|
2024-09-21 01:16:01
|
is there any public source for this
|
|
|
|
Demiurge
|
|
Suigintou
is there any public source for this
|
|
2024-09-21 01:16:47
|
Just the chromium bug tracker and some research into the history of on2 technologies.
|
|
2024-09-21 01:18:10
|
it's literally just him telling the entire planet "there just isn't enough support from the wider community. Trust me bros. I have sources."
|
|
|
Tirr
|
2024-09-21 01:18:55
|
jxl-oxide was my first attempt writing a decoder of modern image format, it has lots of spaghetti code
|
|
|
|
CrushedAsian255
|
2024-09-21 01:19:02
|
How to make a really simple lossless encoder
Only use Set 0 context (only 1 context)
Use huffman instead of ANS
Simple hybrid uint (just store bit count, data bits are stored raw)
No patches splines squeeze whatever
Write headers
Done (I think)
|
|
|
|
Demiurge
|
|
|
Tirr
|
2024-09-21 01:19:55
|
and improving those code to be performant enough needs so much work that a rewrite would be better
|
|
|
|
CrushedAsian255
|
|
Tirr
jxl-oxide was my first attempt writing a decoder of modern image format, it has lots of spaghetti code
|
|
2024-09-21 01:20:17
|
I’m writing decoders for other formats as a “warm up” to writing a JXL decoder (not for public use, just to learn about formats)
|
|
2024-09-21 01:21:18
|
I really should stop putting off learning Rust, but I kinda just prefer the raw nature of C, I don’t know why
|
|
|
|
lonjil
|
2024-09-21 01:21:55
|
I'm writing a partial JXL decoder to help me understand the format well enough for me to write some very specialized encoders.
I'm quite busy with school, so idk when I'll have time for it, but I'd like to make a graphical jxl-art authoring tool.
|
|
|
|
CrushedAsian255
|
2024-09-21 01:22:15
|
University or high school?
|
|
|
|
Demiurge
|
|
lonjil
Writing *an* encoder is easier. Writing a good encoder is much harder.
|
|
2024-09-21 01:22:16
|
I mean, it depends on what your goals are. You can get very decent results while keeping the encoder fast and simple.
|
|
2024-09-21 01:22:41
|
Like how qoi gets decent results for lossless or jpeg gets decent results for lossy
|
|
2024-09-21 01:22:50
|
while still being simple and fast
|
|
|
|
CrushedAsian255
|
2024-09-21 01:22:53
|
Basically e1?
|
|
|
|
lonjil
|
|
CrushedAsian255
University or high school?
|
|
2024-09-21 01:23:02
|
vocational tertiary. Sort of like university except more practical than theoretical, and also I won't get a degree.
|
|
|
|
Foxtrot
|
2024-09-21 01:23:11
|
I think pure C decoder still has very much purpose for all the architectures not targeted by LLVM
|
|
|
|
Demiurge
|
2024-09-21 01:23:38
|
C is not going out of style for the next 100 years
|
|
|
|
lonjil
|
|
lonjil
vocational tertiary. Sort of like university except more practical than theoretical, and also I won't get a degree.
|
|
2024-09-21 01:23:58
|
and I'm studying FPGA engineering. Maybe I could design a JXL hardware accelerator 😄
|
|
|
|
CrushedAsian255
|
2024-09-21 01:24:08
|
Have you looked at libjxl tiny?
|
|
|
|
lonjil
|
2024-09-21 01:24:24
|
I know of it but I haven't looked at the code
|
|
|
|
CrushedAsian255
|
2024-09-21 01:24:52
|
Also isn’t the whole point of JXL to be fast enough to not need hwaccel?
|
|
2024-09-21 01:25:13
|
\*cough cough* AVIF <:avif:1280859209751334913>
|
|
|
|
lonjil
|
2024-09-21 01:25:43
|
cameras might want hw encoding
|
|
|
|
CrushedAsian255
|
2024-09-21 01:25:51
|
Oh yeah,
Forgot about that
|
|
|
|
lonjil
|
2024-09-21 01:26:02
|
So you can snap 120 photos in 1 second
|
|
|
|
Foxtrot
|
2024-09-21 01:26:12
|
nikon z9 jpeg 😄
|
|
|
|
CrushedAsian255
|
2024-09-21 01:26:13
|
Maybe a good hw encoder could make -e 9 practical
|
|
|
lonjil
So you can snap 120 photos in 1 second
|
|
2024-09-21 01:26:26
|
Motion JPEG XL slow motion?
|
|
|
|
lonjil
|
|
CrushedAsian255
Maybe a good hw encoder could make -e 9 practical
|
|
2024-09-21 01:26:45
|
I don't think any hw encoder would do anything like -e 9
|
|
|
|
CrushedAsian255
|
2024-09-21 01:26:57
|
Too much brute forcing?
|
|
|
|
lonjil
|
2024-09-21 01:26:57
|
too complicated
|
|
2024-09-21 01:27:01
|
yeah
|
|
2024-09-21 01:27:53
|
but there isn't much benefit to the higher effort levels for high fidelity compression
|
|
|
|
CrushedAsian255
|
2024-09-21 01:28:03
|
Idea: accelerate certain parts with ASIC and hook it up to a RISC-V processor that handles the less ASICable logic
|
|
|
|
lonjil
|
2024-09-21 01:28:23
|
like do d0.2 and all the effort levels are basically equivalent
|
|
|
|
CrushedAsian255
|
2024-09-21 01:28:26
|
Like the heavy calculations can go in ASIC and the decision making can still be done in software
|
|
|
|
lonjil
|
2024-09-21 01:29:48
|
look at this
|
|
|
|
CrushedAsian255
|
|
lonjil
like do d0.2 and all the effort levels are basically equivalent
|
|
2024-09-21 01:29:53
|
I was thinking lossless but now I think about it camera won’t need lossless
|
|
|
|
lonjil
|
2024-09-21 01:30:06
|
it's d1 and the effort levels basically don't improve the compression ratio at all
|
|
|
|
CrushedAsian255
|
2024-09-21 01:31:04
|
Still Pareto fronting so 👍
|
|
|
|
lonjil
|
|
CrushedAsian255
I was thinking lossless but now I think about it camera won’t need lossless
|
|
2024-09-21 01:31:12
|
tbf the low e's for lossless are pretty good compared to other lossless formats
|
|
|
|
CrushedAsian255
|
2024-09-21 01:31:17
|
Does lossy support e1/e2?
|
|
|
|
lonjil
|
|
|
CrushedAsian255
|
2024-09-21 01:31:50
|
Why is it not on the graph then? Or am I blind
|
|
|
|
lonjil
|
2024-09-21 01:32:00
|
idk i didn't make the graph
|
|
|
lonjil
tbf the low e's for lossless are pretty good compared to other lossless formats
|
|
2024-09-21 01:32:28
|
like right now L-JPEG and J2K are the most popular forms of lossless compression for raws
|
|
2024-09-21 01:32:42
|
So fast lossless jxl is a big improvement
|
|
|
|
CrushedAsian255
|
2024-09-21 01:32:54
|
And we saw what happened at e3 Apple ProRAW
|
|
2024-09-21 01:33:19
|
Could something like e4 be implemented in hardware?
|
|
|
|
lonjil
|
2024-09-21 01:34:00
|
no clue
|
|
2024-09-21 01:34:12
|
i don't know what all libjxl does at its various effort settings
|
|
|
|
veluca
|
|
CrushedAsian255
Does lossy support e1/e2?
|
|
2024-09-21 01:34:45
|
uhm no? I mean they do the same thing as e3 iirc
|
|
|
|
lonjil
|
2024-09-21 01:35:19
|
I got different sized results when I compressed photos with d0.1 and e1,2,3
|
|
|
|
CrushedAsian255
|
2024-09-21 01:35:52
|
Maybe it’s the modular sub bitstream changing
|
|
|
|
lonjil
|
2024-09-21 01:36:44
|
e1 and e2 got the same result but e3 a different one ```
186M jxld0.1e1
186M jxld0.1e2
175M jxld0.1e3
139M jxld0.2e1
139M jxld0.2e2
131M jxld0.2e3
```
|
|
|
Oleksii Matiash
|
|
veluca
uhm no? I mean they do the same thing as e3 iirc
|
|
2024-09-21 01:37:03
|
No, e1\e2 produces significantly larger files, especially noticeable on small files
|
|
|
|
veluca
|
2024-09-21 01:37:24
|
uh, I don't think they should be used ever then
|
|
|
|
Oleksii Matiash
|
|
lonjil
it's d1 and the effort levels basically don't improve the compression ratio at all
|
|
2024-09-21 01:37:45
|
It does change how artefacts looks
|
|
2024-09-21 01:38:02
|
Esp. between e4 and e5
|
|
|
|
CrushedAsian255
|
2024-09-21 01:45:51
|
What about speed though
|
|
|
|
HCrikki
|
2024-09-21 09:11:34
|
Fossify Gallery now includes the preliminary jxl read support in its freshly released stable **1.2.0** - get it now from github or later fdroid/play store
https://github.com/FossifyOrg/Gallery/releases/tag/1.2.0
|
|
|
VcSaJen
|
2024-09-23 03:29:59
|
It does not open JXL files directly from the file manager, looks like it's not registered as able to open jxl files. It only opens them when navigated from inside the app itself
|
|
|
|
Quackdoc
|
|
VcSaJen
It does not open JXL files directly from the file manager, looks like it's not registered as able to open jxl files. It only opens them when navigated from inside the app itself
|
|
2024-09-23 03:43:07
|
it is, your file manager is doing something funky
|
|
2024-09-23 03:43:52
|
|
|
2024-09-23 03:44:10
|
as you can see, gallery properly shows up with mime image/jxl
|
|
|
|
VcSaJen
|
2024-09-23 04:03:04
|
oupson's jxlviewer shows up fine, T8RIN's ImageToolbox also shows up. Tried rebooting, no change. HONOR phone with Android 14
|
|
2024-09-23 04:05:30
|
Wait, jxlviewer also shows up for apng, so I dunno.
|
|
|
|
HCrikki
|
2024-09-23 04:09:10
|
samsung file manager lists almost nothing, fossify file manager missing gallery, Material Files shows all gallery apps (even those lacking jxl support)
is that something file managers are the ones supposed to implement or part of the preliminary support in need of updating?
|
|
|
|
VcSaJen
|
|
Quackdoc
|
|
2024-09-23 04:13:39
|
Interceptor lists MIME Type as application/octet-stream
|
|
|
|
Quackdoc
|
2024-09-23 04:14:29
|
yeah that's an fm mess up.
|
|
|
|
VcSaJen
|
2024-09-23 04:14:52
|
It's standard android Files, tho
|
|
2024-09-23 04:16:46
|
intent://com.android.providers.downloads.documents/document/...
|
|
|
|
Quackdoc
|
2024-09-23 04:17:05
|
yeah AOSP's provider is really basic
|
|
2024-09-23 04:17:14
|
I personally use material files
|
|
|
|
VcSaJen
|
2024-09-23 04:25:07
|
MiXplorer shows correct MIME Type and displays Fossify Gallery, but other gallery apps without support also show up
|
|
|
Meow
|
2024-09-23 04:27:55
|
I have many quick actions for converting image formats
|
|
|
|
VcSaJen
|
2024-09-23 04:30:40
|
Is support for animated JXL planned? I see that GIF and APNG are supported.
|
|
|
|
Quackdoc
|
|
VcSaJen
Is support for animated JXL planned? I see that GIF and APNG are supported.
|
|
2024-09-23 04:38:15
|
as far as I know, the plugin does not plan on supporting it
|
|
|
|
CrushedAsian255
|
|
Meow
I have many quick actions for converting image formats
|
|
2024-09-23 07:37:51
|
怎么做？
|
|
|
|
Meow
|
|
CrushedAsian255
怎么做？
|
|
2024-09-23 08:04:55
|
Like this
`for f in "$@"
do
/usr/local/bin/cjxl "$f" "${f%.*}.jxl" -d 1.0 -a 1.0
done`
|
|
2024-09-23 08:05:52
|
That JPEG one is cjpegli
|
|
2024-09-23 08:07:19
|
It can be created via Automator and any quick action should be placed in /Users/(user)/Library/Services/
|
|
|
|
CrushedAsian255
|
2024-09-23 08:07:50
|
哦，在用Automator
|
|
|
|
Meow
|
2024-09-23 08:09:24
|
Then you don't need any third-party app to convert to JXL on macOS
|
|
2024-09-24 03:49:37
|
I made it as I found that the quality of AVIF could be more different with/without Alpha
|
|
|
|
CrushedAsian255
|
2024-09-24 08:12:37
|
I think that’s an Apple native thing
|
|
|
|
Meow
|
2024-09-24 09:24:20
|
Simply an exclusive quick action for AVIF images with no background. No need for others
|
|
2024-09-24 09:26:11
|
The codes are slightly different from the JPEG one as Homebrew currently doesn't include Jpegli
`for f in "$@"
do
/(some path)/jpegli/build/tools/cjpegli "$f" "${f%.*}.jpg" -q 92
done`
|
|
|
cutename
|
2024-09-25 12:19:16
|
cw: reference to nsfw
|
|
|
|
lonjil
|
2024-09-25 12:29:42
|
is there a way to contact the author of that? Because it was not created in 2017.
|
|
|
w
|
2024-09-25 12:36:45
|
is that just motbob
|
|
|
|
Meow
|
|
cutename
cw: reference to nsfw
|
|
2024-09-25 12:53:56
|
Onion needed?
|
|
|
|
lonjil
|
2024-09-25 12:58:22
|
I2P needed, presumably
|
|
|
|
cutename
|
|
Meow
Onion needed?
|
|
2024-09-25 02:04:43
|
https://geti2p.net
|
|
|
lonjil
is there a way to contact the author of that? Because it was not created in 2017.
|
|
2024-09-25 02:05:01
|
the site has comments, http://notbob.i2p/cgi-bin/blog.cgi?page=738
|
|
2024-09-25 02:15:03
|
mr beast
|
|
|
|
Quackdoc
|
2024-09-25 03:06:07
|
man, i2p, still slow as balls, tbh i2p might just be the best showcase for jxl [av1_omegalul](https://cdn.discordapp.com/emojis/885026577618980904.webp?size=48&quality=lossless&name=av1_omegalul)
|
|
|
|
Meow
|
2024-09-25 03:33:33
|
Not sure about if trying it would cause troubles
|
|
|
|
Quackdoc
|
2024-09-25 03:37:15
|
I suppose in some countries I2P could be illegal
|
|
|
|
CrushedAsian255
|
2024-09-25 03:45:17
|
What is I2P
|
|
2024-09-25 03:45:22
|
Is it like Tor?
|
|
|
|
Quackdoc
|
2024-09-25 03:46:41
|
kinda
|
|
|
|
CrushedAsian255
|
|
Quackdoc
man, i2p, still slow as balls, tbh i2p might just be the best showcase for jxl [av1_omegalul](https://cdn.discordapp.com/emojis/885026577618980904.webp?size=48&quality=lossless&name=av1_omegalul)
|
|
2024-09-25 03:55:18
|
Didn’t it switch to UDP for fast?
|
|
|
|
Foxtrot
|
2024-09-25 04:10:31
|
interesting, from what I read I2P should be even more anonymous/private than Tor, but harder to use
|
|
|
|
Quackdoc
|
|
CrushedAsian255
Didn’t it switch to UDP for fast?
|
|
2024-09-25 04:12:14
|
even if they did or not, I dunno, but remeber that it's relatively faster, does not mean it is fast
|
|
|
|
Meow
|
2024-09-25 06:48:46
|
Interesting that I got to know I2P from an image format channel
|
|
|
drkt
|
2024-09-25 10:42:28
|
I2P is Tor with the 2 main caveats that you're supposed to stay within the network and not leave it (Tor cam do this too but it's not what people do) and it's truly decentralized unlike Tor which relies on a central directory to keep track of relays and exits
|
|
2024-09-25 10:44:05
|
I guess also unlike Tor if you use i2p then you're kind of forced to participate as a relay. It's kind of hard to be a freeloader on i2p
|
|
|
|
lonjil
|
2024-09-25 10:55:26
|
> stay within the network and not leave it (Tor cam do this too but it's not what people do)
Facebook's onion service has over a million monthly users!
|
|
|
|
drkt
|
2024-09-25 11:44:11
|
That's true. Bulk traffic probably goes to SoMe that also exists outside of Tor
|
|
|
|
jonnyawsom3
|
2024-09-26 10:20:49
|
Probably a bit rough around the edges, but no one had made an issue for it yet https://github.com/aseprite/aseprite/issues/4682
|
|
|
monad
|
2024-09-26 10:43:37
|
does the upsampling trick allow jxl to compete with webp at usable speeds? maybe with enough threads, but intuitions says webp still has a big advantage.
|
|
|
|
jonnyawsom3
|
2024-09-26 10:56:58
|
A rough test shows jxl being 4x faster at e10 than cwebp with z9 while being 30% smaller with 87% less memory
|
|
|
|
monad
|
2024-09-26 10:57:22
|
I mean at usable speeds
|
|
|
|
jonnyawsom3
|
2024-09-26 10:58:11
|
Well the upsampling is only really good for pixel art, which will be of a limited size. This test was 1 second
|
|
|
|
monad
|
2024-09-26 11:00:24
|
I will set something up
|
|
|
|
jonnyawsom3
|
2024-09-26 11:00:28
|
At default lossless settings (no -z or -e) it's 0.15 seconds vs 0.09 for jxl, same memory use and 20% smaller
|
|
|
|
monad
|
2024-09-26 11:01:35
|
sounds promising, but I will try more images and more settings
|
|
|
|
jonnyawsom3
|
2024-09-26 11:02:16
|
But yeah, with your test suites you'd get much better and consistent results. This was 1:1 scaled pixel art, encoded with 8x upsampling in cjxl, decoded to png and then encoded to webp to get the same output image for both
|
|
2024-09-26 11:03:17
|
`cjxl -d 0 -e 10 --already_downsampled --resampling=8 --upsampling_mode=0 Test.png Test.jxl`
|
|
|
|
monad
|
2024-09-26 11:08:36
|
mm, 8x is worst-case comparison against webp. I wonder what is most common. but also, it's an important note that there is a lot of stuff published outside 2x,4x,8x
|
|
|
|
jonnyawsom3
|
2024-09-26 11:10:25
|
Yeah, although for pixel art scaling generally too large is better than too small, assuming it can reach the 'original' resized resolution, but I doubt many are resizing by more than 8x the original anyway.
|
|
|
|
monad
|
2024-09-26 11:10:59
|
there definitely is stuff published above 8x
|
|
|
|
jonnyawsom3
|
2024-09-26 11:12:00
|
I tend to see a lot of 5x5, sometimes 4x4 and rarely 3x3 or 6x6, so 4x or 8x if it's not legible is what I've tried in the past
|
|
2024-09-26 11:12:54
|
If I recall, it should be possible to 'stack' upsampling, but it's not been tried/implimented yet
|
|
|
|
monad
|
2024-09-27 12:08:25
|
from the larger items in Scope's set (some of which may not be upscaled) plus 93 items in my collection which are known to be upscaled:
scale 2: 508 files (23%)
scale 4: 199 files (9%)
scale 8: 224 files (10%)
scale other: 1211 files (56%)
(if it's a multiple of 8x, it's bucketed into 8x)
|
|
2024-09-27 12:13:03
|
actually, I thought I had taken the smaller items out previously, but no, that happens to be everything from Scope's set
|
|
|
TheBigBadBoy - 𝙸𝚛
|
2024-09-27 12:18:13
|
also, why resampling is only 1, 2, 4 and 8 ?
I can understand the limitation to powers of 2, but why stopping at 8 ?
|
|
|
|
monad
|
2024-09-27 01:11:32
|
more buckets:
scale 2: 202 files (9%)
scale 3: 135 files (6%)
scale 4: 172 files (8%)
scale 5: 116 files (5%)
scale 6: 73 files (3%)
scale 7: 16 files (0%)
scale 8: 122 files (5%)
scale 9: 16 files (0%)
scale 10: 235 files (10%)
scale 11: 1 files (0%)
scale 12: 11 files (0%)
scale 13: 2 files (0%)
scale 14: 2 files (0%)
scale 15: 18 files (0%)
scale 16: 100 files (4%)
scale other: 921 files (42%)
|
|
|
|
VcSaJen
|
2024-09-27 01:24:00
|
> scale other
Does this refer to non-uniform pixels? Nyan cat uses those
|
|
|
|
monad
|
2024-09-27 01:29:21
|
the test is, scale the image down, then scale it up and see if it exactly matches the original. 'other' catches any situation where that condition doesn't hold. here, it's probably a lot of 1:1 stuff
|
|
2024-09-27 01:31:15
|
I noticed there is some stuff in there which isn't pixel art in the purest sense, like ... a minecraft screenshot
|
|
|
|
jonnyawsom3
|
|
TheBigBadBoy - 𝙸𝚛
also, why resampling is only 1, 2, 4 and 8 ?
I can understand the limitation to powers of 2, but why stopping at 8 ?
|
|
2024-09-27 02:33:13
|
https://discord.com/channels/794206087879852103/794206170445119489/1222266586564526171
|
|
2024-09-27 02:33:23
|
Dug up the awnser from when I asked the same question
|
|
2024-09-27 02:37:47
|
So assuming the image set is at least somewhat representative, the 2, 4 and 8 upsampling covers around half of pixel art
|
|
|
|
monad
|
2024-09-27 02:39:36
|
I think Scope's set is a pretty good representation of widely distributed stuff
|
|
2024-09-27 02:43:06
|
192 images. I boosted cjxl's measured speed by 4x. this test includes png decode time, so presumably cwebp is at a disadvantage
|
|
2024-09-27 02:47:03
|
(and I guess I forgot about compensating for bpp, so have to look at B instead)
|
|
|
monad
I noticed there is some stuff in there which isn't pixel art in the purest sense, like ... a minecraft screenshot
|
|
2024-09-27 03:13:50
|
"pixel art"
|
|
|
|
jonnyawsom3
|
2024-09-27 03:14:47
|
I mean... Technically not wrong, but completely wrong for image sets
|
|
|
|
monad
|
2024-09-27 03:27:21
|
IMO, there is some justification for tagging vanilla Minecraft in general as pixel art, similar to Stardew, Kingdom, etc, etc. But I see different behavior between modern game screens and images designed to stand alone. That's why I typically represent both groups in my results. In my curated set I decided Minecraft was a step too far and I did not tag it, but much of this set was scraped from Reddit, so it is categorized by the common person.
|
|
|
|
VcSaJen
|
2024-09-27 03:32:31
|
Some artists manually draw "pixels" with a Rectangle tool, so it's not uniform or even square pixels. Some have padding, so grid wouldn't align. Some have HD artist signatures in otherwise uniform and aligned pixel art. Some re-scaled image after the fact, so it would have anti-aliasing and non-integer-sized pixels.
|
|
|
|
jonnyawsom3
|
|
monad
IMO, there is some justification for tagging vanilla Minecraft in general as pixel art, similar to Stardew, Kingdom, etc, etc. But I see different behavior between modern game screens and images designed to stand alone. That's why I typically represent both groups in my results. In my curated set I decided Minecraft was a step too far and I did not tag it, but much of this set was scraped from Reddit, so it is categorized by the common person.
|
|
2024-09-27 03:48:01
|
That specific image, and I'd assume most Minecraft images in that set, *is* actually called pixel art in the game. People just use 1 block per pixel and then zoom out to blend the colors. I'd assume someone just tagged it as "Pixel art" without differentating between 'real' pixel art and pixel art being made in a game
|
|
|
|
VcSaJen
|
2024-09-27 04:06:51
|
There's also photography
|
|
|
|
monad
|
|
That specific image, and I'd assume most Minecraft images in that set, *is* actually called pixel art in the game. People just use 1 block per pixel and then zoom out to blend the colors. I'd assume someone just tagged it as "Pixel art" without differentating between 'real' pixel art and pixel art being made in a game
|
|
2024-09-27 04:08:43
|
yes, the in-universe pixel art is the reason it was shared to a pixel art sub, but my point was the game has pixel art textures inherently, so it's justified in that sense as far as characteristic image content
|
|
2024-09-27 04:10:35
|
photos I would classify as photo, but Jon did classify a photo of text as text in his analysis and he's smarter than me
|
|
|
|
jonnyawsom3
|
2024-09-27 04:14:16
|
The textures *are* pixel art, but it's extremely rare to be at an exact axis aligned viewing angle, or with 1:1 pixel scaling. Then add things like particles, UI, transparency, water... There's not a lot in the average Minecraft screenshot that has the same characteristics as pixel art, however much I wish that were true
|
|
|
|
VcSaJen
|
2024-09-27 04:14:52
|
Technically textures have texels, not pixels
|
|
|
|
jonnyawsom3
|
2024-09-27 04:14:56
|
In a perfect world, we could just use the Minecraft texture atlas PNG as a patches reference frame
|
|
|
|
VcSaJen
|
2024-09-27 04:23:49
|
Is CMYK jxl quickly becoming arithmetic jpeg? Basically nothing supports it, programs either crash or ignore K channel.
|
|
2024-09-27 06:46:37
|
Krita also loads it, AFAIR. Not much else, tho
|
|
|
|
_wb_
|
2024-09-27 07:05:05
|
Does the new decode color management in libjxl handle it properly? If it doesn't, we need to change that. If it does, we need to get more applications to use it so they get a properly converted RGB image out of CMYK jxls.
|
|
|
|
Demiurge
|
2024-09-27 08:02:48
|
I wonder if mozilla's qcms rust lib is adequate for the purposes of jxl-rs
|
|
2024-09-27 08:05:19
|
Probably not, I imagine
|
|
|
|
Tirr
|
2024-09-27 08:07:21
|
it works for 8-bit samples only
|
|
|
|
Demiurge
|
2024-09-27 08:37:19
|
Yeah. But that could be fixed with a patch.
|
|
2024-09-27 08:37:27
|
or a pull request
|
|
|
|
CrushedAsian255
|
|
_wb_
Does the new decode color management in libjxl handle it properly? If it doesn't, we need to change that. If it does, we need to get more applications to use it so they get a properly converted RGB image out of CMYK jxls.
|
|
2024-09-27 08:38:51
|
Shouldn’t jxl automatically colour manage cmyk to rgb without having to do anything ?
|
|
2024-09-27 08:39:05
|
And only return cmyk when required/requesred?
|
|
|
|
_wb_
|
2024-09-27 09:20:13
|
I think many applications are requesting the image data in its original color space, so if that's CMYK then libjxl doesn't really have a choice.
|
|
|
|
Meow
|
|
cutename
cw: reference to nsfw
|
|
2024-09-27 11:48:16
|
Unfortunately this ||hentai||.i2p site is down now that I can't check
|
|
|
|
cutename
|
2024-09-27 11:48:44
|
yeah uptime's weird
|
|
|
|
Meow
|
2024-09-27 12:10:41
|
Also found that the I2P extension breaks the JPEG XL extension on Firefox
|
|
2024-09-27 12:24:40
|
Downloaded Waterfox for I2P + JXL
|
|
|
|
lonjil
|
2024-09-27 12:31:58
|
I just run a local proxy for I2P
|
|
|
|
VcSaJen
|
|
_wb_
I think many applications are requesting the image data in its original color space, so if that's CMYK then libjxl doesn't really have a choice.
|
|
2024-09-27 02:36:57
|
Maybe make an optional parameter that specifies a list of preferred numbers of color channels? Which would be [1, 3] by default (if it's omitted). Then it would convert all 4 channel images into default 3 channel color space, unless app indicated that it supports four channels. My opinion as a layperson, I dunno if it's an antipattern or something.
|
|
|
|
Meow
|
2024-09-27 04:35:02
|
Having hundreds of JXL images on the main page is cool
|
|
|
|
jonnyawsom3
|
2024-09-27 04:53:16
|
Maybe not for my RAM
|
|
|
novomesk
|
2024-09-27 06:40:07
|
https://devtalk.blender.org/t/2024-09-17-render-cycles-meeting/36668/10
|
|
|
|
jonnyawsom3
|
2024-09-27 08:59:53
|
Not the best start... But promising
|
|
|
|
Demiurge
|
|
Meow
Downloaded Waterfox for I2P + JXL
|
|
2024-09-27 09:31:38
|
Down with Firefox
|
|
2024-09-27 09:31:54
|
Long live Waterfox
|
|
|
|
drkt
|
|
Demiurge
Long live Waterfox
|
|
2024-09-28 04:38:30
|
What is Waterfox' gimmick? I don't keep up with the 4325 firefox forks after Librewolf came out
|
|
|
|
Meow
|
2024-09-28 05:11:47
|
Does LibreWolf support JXL?
|
|
|
|
drkt
|
2024-09-28 05:18:28
|
Yes but weirdly
|
|
2024-09-28 05:19:08
|
https://u.drkt.eu/2N0ycX.png
|
|
|
|
username
|
2024-09-28 05:19:09
|
ehh it barely supports JXL. it's just the broken Firefox nightly support and it's disabled by default
|
|
|
|
drkt
|
2024-09-28 05:19:21
|
note animation is not animating either
|
|
|
|
username
|
2024-09-28 05:19:58
|
all Librewolf did was set JXL to not require nightly to compile, that's it
|
|
|
|
drkt
|
2024-09-28 05:20:09
|
Makes sense
|
|
|
|
username
|
|
drkt
What is Waterfox' gimmick? I don't keep up with the 4325 firefox forks after Librewolf came out
|
|
2024-09-28 05:28:56
|
https://www.reddit.com/r/waterfox/comments/1ff0kzz/comment/lmr2wq6/
note that Waterfox is based on the Firefox ESR branch.
also history wise Waterfox started out like 12 years ago just as 64-bit release binaries for Firefox because back then Mozilla used to only shipped 32-bit binaries.
|
|
|
|
drkt
|
2024-09-28 05:32:04
|
> Ability to have tabs above address bar, below address bar, or at the bottom of the browser UI.
Oh man I'd switch today if they made an inline option https://u.drkt.eu/tHiUz9.png
|
|
|
|
Demiurge
|
|
drkt
What is Waterfox' gimmick? I don't keep up with the 4325 firefox forks after Librewolf came out
|
|
2024-09-28 06:51:03
|
Speed. And decent jxl support I guess. But I think they are using ESR, which is bleh
|
|
|
username
ehh it barely supports JXL. it's just the broken Firefox nightly support and it's disabled by default
|
|
2024-09-28 06:52:04
|
But I see the jxl fixes in librewolf's source repo. I wonder why they aren't working?
|
|
|
|
username
|
|
Demiurge
But I see the jxl fixes in librewolf's source repo. I wonder why they aren't working?
|
|
2024-09-28 06:54:31
|
they where added (via a pull request) and then immediately turned off and have since bit-rotted over time
|
|
2024-09-28 06:55:17
|
Librewolf only tests if the patches merge but doesn't test if they compile
|
|
|
|
Demiurge
|
2024-09-28 07:00:43
|
Why turned off? >:/ I wanna switch away from waterESR but with broken JXL support that's off the table
|
|
|
|
HCrikki
|
2024-09-28 07:27:12
|
no jxl is a reason i cant recommend librewolf.
important for those derivatives to experiment with the stuff mozilla doesnt ship yet, theyre actually keeping an eye on those and their reception
|
|
|
|
drkt
|
2024-09-28 07:33:53
|
didn't mozilla already commit to shipping a rust decoder?
|
|
|
|
username
|
2024-09-28 07:36:57
|
they aren't making it and the time when it will be done is probably going to be quite a while as it's kinda just started development
|
|
|
|
drkt
|
2024-09-28 07:37:24
|
Yes, but the committed to shipping it when it's done and working, right?
|
|
|
|
username
|
2024-09-28 07:37:25
|
also it depends on features they aren't in Rust stable yet either
|
|
2024-09-28 07:38:45
|
if it fits their requirements of which are not fully known to the public
|
|
|
|
HCrikki
|
2024-09-28 07:39:25
|
would a rust decoder be performant enough compared to say native mozjpg?
|
|
|
|
username
|
2024-09-28 07:39:58
|
mozjpeg just changes the encoding side of libjpeg turbo, decoding is unchanged
|
|
|
|
drkt
|
2024-09-28 07:40:00
|
Well, if they're serious about it, my point is that why would they patch up the current decoder if they have to rip it all out once a rust decoder is available anyway
|
|
|
|
username
|
2024-09-28 07:40:59
|
who? Librewolf or Mozilla?
|
|
|
|
drkt
|
2024-09-28 07:41:04
|
Mozilla
|
|
|
|
username
|
2024-09-28 07:41:23
|
Mozilla doesn't care about the current decoder and they haven't for years
|
|
|
|
drkt
|
|
|
HCrikki
|
2024-09-28 07:41:41
|
tbh id rather if they shipped refreshed libjxl initially in nightly and developper edition. its safe and help webdevs until it can be swapped with a rust decoder
|
|
|
|
drkt
|
2024-09-28 07:41:50
|
Why would they begin now, if they've committed to implementing the rust decoder once it is available?
|
|
|
|
Quackdoc
|
2024-09-28 07:42:16
|
The stuff I really want to know is why has Mozilla not removed the legacy C decoders of which there are plenty in Firefox still?
|
|
2024-09-28 07:42:29
|
We can't really pretend that there are no good rusty coders for stuff like this, so...
|
|
|
|
drkt
|
2024-09-28 07:47:34
|
Do wonder how different all this would be today if Chromium hadn't said no 2 years ago
|
|
|
|
username
|
|
drkt
Do wonder how different all this would be today if Chromium hadn't said no 2 years ago
|
|
2024-09-28 07:49:07
|
Mozilla love following Chrome so pretty much every browser would have supported JXL by now as Opera and Edge would automatically get support as well
|
|
2024-09-28 07:49:56
|
It's the whole reason Firefox has a partial JXL decoder is because they where preparing for Chrome to support JXL
|
|
|
|
HCrikki
|
2024-09-28 07:50:35
|
upstreaming was never the only way forward - just ideal but shouldnt have prevented the release of jxl-enabled builds for early adopters
|
|
|
|
Demiurge
|
|
username
they aren't making it and the time when it will be done is probably going to be quite a while as it's kinda just started development
|
|
2024-09-28 08:09:22
|
It might not take that long... Luca is a scary mad genius
|
|
|
HCrikki
would a rust decoder be performant enough compared to say native mozjpg?
|
|
2024-09-28 08:10:16
|
mozjpg is not very fast.
|
|
2024-09-28 08:10:37
|
And he's really writing it in assembly with some rust glue.
|
|
|
|
username
|
2024-09-28 08:11:05
|
mozjpeg is not a decoder..
|
|
2024-09-28 08:11:29
|
it's a fork of libjpeg turbo that changes the encoder, decoding is untouched iirc
|
|
|
|
Demiurge
|
2024-09-28 08:12:32
|
I'm not certain either, if decoding is completely untouched. As a libjpeg fork, it certainly comes with a decoder though.
|
|
|
|
Meow
|
2024-09-28 10:56:39
|
You know Mozilla can't live without Google
|
|
|
|
drkt
|
|
Meow
You know Mozilla can't live without Google
|
|
2024-09-28 11:02:44
|
They probably could if they trimmed the fat and actually cared about their browser, the one project under their wing that people actually use
|
|
|
|
CrushedAsian255
|
2024-09-28 11:03:37
|
Could Google… ehrm I mean the Codec Team just say “Mozilla if you add jpeg xl we cut your funding”?
|
|
|
|
Meow
|
2024-09-28 11:04:20
|
If JXL is more important than the search engine
|
|
|
|
CrushedAsian255
|
2024-09-28 11:06:01
|
So technically could but would be really stupid
|
|
|
|
Meow
|
2024-09-28 11:09:02
|
Keeping the default search engine is a big deal
|
|
|
|
lonjil
|
|
CrushedAsian255
Could Google… ehrm I mean the Codec Team just say “Mozilla if you add jpeg xl we cut your funding”?
|
|
2024-09-28 11:25:56
|
why would Google do that?
|
|
|
|
Foxtrot
|
2024-09-28 11:32:18
|
i dont think some small codec team have authority to do something like this
|
|
2024-09-28 11:33:26
|
google pays mozilla for placing google as default and also kinda so they dont look like monopoly so much... they dont care what codecs firefox implements or not
|
|
2024-09-28 11:34:58
|
and who knows, maybe google will stop funding mozilla because of the lawsuit https://news.itsfoss.com/google-mozilla-firefox-threat/
|
|
|
|
Demiurge
|
2024-09-28 11:53:02
|
I hope mozilla loses ALL their funding so the vampires and vultures that sucked it dry can lose interest in it and move on to the next fresh source of blood. Maybe then it can actually become an open source project
|
|
|
|
lonjil
|
2024-09-28 11:54:37
|
I mean there's what, a couple hundred people who work on Firefox? Mozilla corp's single biggest expense. As a community run project it would have like, 10 part time volunteers, which, good luck.
|
|
|
|
Demiurge
|
2024-09-28 12:00:05
|
But here's the thing though, once when it's totally destroyed and there's absolutely no way to make any money anymore, then there's a chance that people that actually CARE about firefox could step in and reboot it.
|
|
2024-09-28 12:00:34
|
Once when there's no financial/power motive
|
|
2024-09-28 12:01:05
|
Then only someone who doesn't crave money or power would step in and want to breathe new life into it.
|
|
|
RaveSteel
|
|
lonjil
I mean there's what, a couple hundred people who work on Firefox? Mozilla corp's single biggest expense. As a community run project it would have like, 10 part time volunteers, which, good luck.
|
|
2024-09-28 12:40:25
|
https://lunduke.locals.com/post/4387539/firefox-money-investigating-the-bizarre-finances-of-mozilla
|
|
|
|
lonjil
|
|
RaveSteel
https://lunduke.locals.com/post/4387539/firefox-money-investigating-the-bizarre-finances-of-mozilla
|
|
2024-09-28 12:42:10
|
>lunduke
rejecting for being the ramblings of a fascist troll
|
|
|
damian101
|
|
Demiurge
Once when there's no financial/power motive
|
|
2024-09-28 01:10:36
|
Firefox income is pretty much proportional to the number of people using it, so I don't quite see how interests are unaligned here...
|
|
|
|
Demiurge
|
2024-09-28 01:11:59
|
I don't know who Lunduke is, but it's kind of weird to use the word fascist so casually without any context, especially since that word has a specific meaning and is often carelessly thrown around to describe anyone from the opposite side of the political compass as the person employing the term.
|
|
|
|
damian101
|
2024-09-28 01:12:32
|
he's definitely not a fascist in any sense of the word
|
|
|
|
Demiurge
|
2024-09-28 01:13:01
|
Especially when it's someone who isn't here or even capable of responding in their defense
|
|
|
|
damian101
|
2024-09-28 01:14:41
|
some of his political positions are pretty cringe I guess, somewhat aligned with the new American right, MAGA movement stuff
|
|
2024-09-28 01:15:14
|
nothing too extreme, though
|
|
|
|
Demiurge
|
2024-09-28 01:16:33
|
Like I can understand wanting to avoid someone for their views but just dropping a "fascist" on someone without any context seems like a bad way to do it.
|
|
|
|
damian101
|
2024-09-28 01:17:50
|
Was done with the word fascist from the beginning btw.
In the original sense of the word, the German Nazis are not fascists.
Fascism was Mussolini's ideology, and it's very distinct from Nazism.
|
|
|
|
Demiurge
|
2024-09-28 01:20:23
|
Eh, all these ideologies are all the same to me... At the end of the day, it's "do what I say or I torture you and then I kill you." Wait a minute, it's actually "Do what I say AND I also torture and kill you."
|
|
2024-09-28 01:21:02
|
Every system of government ever invented is the same exact thing in my eyes.
|
|
2024-09-28 01:21:31
|
Yeah 😂
|
|
|
|
VcSaJen
|
|
drkt
What is Waterfox' gimmick? I don't keep up with the 4325 firefox forks after Librewolf came out
|
|
2024-09-28 01:24:17
|
Support for native x64. Firefox was 32bit at the time
|
|
|
|
drkt
|
2024-09-28 01:26:24
|
I'm up to speed :p
|
|
|
|
damian101
|
|
Demiurge
Every system of government ever invented is the same exact thing in my eyes.
|
|
2024-09-28 01:26:49
|
bruh
|
|
|
|
Demiurge
|
2024-09-28 01:37:39
|
It's just a con to manufacture legitimacy over the right for someone to rule you and screw everyone else over.
|
|
|
MSLP
|
|
Demiurge
Why turned off? >:/ I wanna switch away from waterESR but with broken JXL support that's off the table
|
|
2024-09-28 03:39:07
|
That kinda leaves you with Floorp and Midori on the table, Zen has enabled-by-default but partial (firefox upstream) support.
|
|
|
|
HCrikki
|
2024-09-29 04:54:09
|
Fossify gallery updated its support with 1.2.1, fixing some memory leak in its jxl integration - get it now from github or later from google play/fdroid
https://github.com/FossifyOrg/Gallery/releases/tag/1.2.1
|
|
|
|
novomesk
|
|
_wb_
I think many applications are requesting the image data in its original color space, so if that's CMYK then libjxl doesn't really have a choice.
|
|
2024-09-29 03:58:45
|
When I tried in the past, There was no conversion from CMYK to RGB
https://github.com/libjxl/libjxl/issues/3280
|
|
|
|
Squid Baron
|
2024-09-29 05:55:33
|
So about that rust decoder for Mozilla, is it being developed? Is there a repo?
|
|
2024-09-29 05:56:20
|
Will it be written from scratch or a fork of one of the existing implementations?
|
|
|
|
lonjil
|
|
Squid Baron
So about that rust decoder for Mozilla, is it being developed? Is there a repo?
|
|
2024-09-29 06:00:51
|
https://github.com/libjxl/jxl-rs
|
|
|
|
Tirr
|
2024-09-29 06:03:47
|
it's like "almost write from scratch, but copy existing code as much as we can"
|
|
|
|
Squid Baron
|
2024-09-29 06:06:00
|
thanks
|
|
|
|
veluca
|
|
Tirr
it's like "almost write from scratch, but copy existing code as much as we can"
|
|
2024-09-29 06:10:20
|
"and where we can't, copy the design" 😛
|
|
|
|
Tirr
|
2024-09-29 06:10:57
|
basically we copy code from jxl-oxide and design from libjxl
|
|
|
|
lonjil
|
|
cutename
the site has comments, http://notbob.i2p/cgi-bin/blog.cgi?page=738
|
|
2024-10-01 08:51:18
|
I submitted a comment shortly after you posted that link, but it never showed up :(
|
|
|
|
HCrikki
|
2024-10-02 02:13:11
|
seems wordpress added some kind of server support tracking. what are the implications, is this big or requires further ecosystem changes to be usable ? https://github.com/WordPress/wordpress-develop/pull/7355
|
|
2024-10-02 02:13:30
|
"Upgrade/Install: Indicate JPEG XL support when checking upgrades.
This adds tracking of the JPEG XL image type support alongside WebP, HEIC, and AVIF image types when requesting an upgrade from WordPress.org.
This will check for JPEG XL support in both ImageMagick and GD, even though GD technically does not yet have support for JPEG XL."
|
|
|
Kleis Auke
|
|
HCrikki
seems wordpress added some kind of server support tracking. what are the implications, is this big or requires further ecosystem changes to be usable ? https://github.com/WordPress/wordpress-develop/pull/7355
|
|
2024-10-02 09:05:10
|
AFAIK, WordPress is bringing (parts of) <https://github.com/swissspidy/media-experiments> to Gutenberg, the WordPress editor. This would mean that JPEG XL images would be processed client-side via <https://github.com/kleisauke/wasm-vips>. See the roadmap ticket at <https://github.com/WordPress/gutenberg/issues/61447> for details.
|
|
|
|
MSLP
|
2024-10-02 05:00:33
|
On account of Ladybird browser selecting Swift as the language of choice https://x.com/awesomekling/status/1822236888188498031 I wonder if there will be a Swift implementation of jxl decoder <:Thonk:805904896879493180>
|
|
|
|
Lucas Chollet
|
2024-10-02 05:04:37
|
Decoders are not developed in house anymore. So Ladybird is now using libjxl, and I guess will adopt the rust decoder when it's ready.
|
|
|
|
MSLP
|
2024-10-02 05:07:50
|
So ideally rust decoder could use bindings for C language?
|
|
2024-10-02 05:08:23
|
or rather "provide"
|
|
|
|
HCrikki
|
2024-10-02 05:54:21
|
I doubt theyd go rust for jxl. Makes far better sense to stick to a shallow integration of decoder-only libjxl
|
|
|
|
Quackdoc
|
|
HCrikki
I doubt theyd go rust for jxl. Makes far better sense to stick to a shallow integration of decoder-only libjxl
|
|
2024-10-02 07:32:08
|
no it doesn't security matters, which is one of the reasons why they went swift. it makes sense to avoid libjxl since it's not a memory safe language
|
|
|
MSLP
So ideally rust decoder could use bindings for C language?
|
|
2024-10-02 07:32:35
|
yes, that's why I asked if jxl-rs will provide c bindings (that and it can be easier to setup build envs for some)
|
|
|
spider-mario
|
2024-10-02 09:26:30
|
for some reason, it seems that when exporting from Lightroom to “quality 90” JXL, it uses VarDCT if sRGB is picked as colour space, but modular for ProPhoto?
|
|
|
|
Quackdoc
|
2024-10-02 11:59:23
|
that's an interesting choice
|
|
|
|
jonnyawsom3
|
2024-10-03 05:50:25
|
Probably a misunderstanding that lossy goes to XYB and lossless keeps the original, so they used modular thinking it's required to keep the color space
|
|
|
|
Kleis Auke
|
|
spider-mario
isn’t the open-source community switching to freenginx?
|
|
2024-10-04 12:31:04
|
I think I'm going probably switch to freenginx if they are landing PR <https://github.com/nginx/nginx/pull/231> as-is. That whole nginx -> NGINX rebrand is weird.
|
|
2024-10-04 12:32:19
|
They even landed PR <https://github.com/nginx/nginx/pull/165> as-is and ignored any feedback from Sergey Kandaurov.
|
|
|
|
CrushedAsian255
|
|
Kleis Auke
I think I'm going probably switch to freenginx if they are landing PR <https://github.com/nginx/nginx/pull/231> as-is. That whole nginx -> NGINX rebrand is weird.
|
|
2024-10-04 12:38:17
|
Why are they rebranding over capitalisation? This feels like changes for changes’ sake
|
|
|
|
Kleis Auke
|
|
CrushedAsian255
Why are they rebranding over capitalisation? This feels like changes for changes’ sake
|
|
2024-10-04 12:40:28
|
Without guessing, I'm not sure. Hopefully they (F5) will provide a doc about this (<https://github.com/nginx/nginx/pull/231#discussion_r1783692909>).
|
|
|
|
CrushedAsian255
|
2024-10-04 12:40:47
|
Who is F5? The keyboard key?
|
|
|
|
Kleis Auke
|
|
CrushedAsian255
Who is F5? The keyboard key?
|
|
2024-10-04 12:41:49
|
<https://en.wikipedia.org/wiki/F5,_Inc.>
|
|
|
|
Quackdoc
|
2024-10-05 10:12:10
|
czkawka added jxl but its via pixbuf loader. so expect really bad perf
|
|
|
|
jonnyawsom3
|
2024-10-05 11:49:42
|
For some reason that reminded me to check for any updates on this...
If I'm reading this right, they've made the default JXL quality 99 now?
https://github.com/SpecialKO/SpecialK/commit/a56a32dbce074f42ff70f0bfd0df94098ec05e31
|
|
|
|
CrushedAsian255
|
|
For some reason that reminded me to check for any updates on this...
If I'm reading this right, they've made the default JXL quality 99 now?
https://github.com/SpecialKO/SpecialK/commit/a56a32dbce074f42ff70f0bfd0df94098ec05e31
|
|
2024-10-05 11:50:07
|
So lossless just doesn’t exist?
|
|
|
|
jonnyawsom3
|
2024-10-05 11:54:38
|
I'm not sure, but this still stands
>>> Default quality level is 99%, this is primarily a lossy format.
* JXL lossless compression ratio is poor, but not as poor as PNG.
* AVIF or PNG are better choices for sharing lossless reference images
|
|
|
|
CrushedAsian255
|
2024-10-05 12:01:12
|
“AVIF [compared to JXL is a] better choice for sharing lossless images”
Wat
|
|
|
|
lonjil
|
2024-10-05 12:09:49
|
They're probably accidentally using lossy (but very high quality) AVIF 🙂
|
|
|
|
jonnyawsom3
|
2024-10-05 12:23:42
|
YUV Dx
|
|
2024-10-05 12:24:10
|
<@245794734788837387> did you ever see much on their Discord about it?
|
|
|
|
Meow
|
|
cutename
cw: reference to nsfw
|
|
2024-10-05 12:35:25
|
It's online now
|
|
2024-10-05 12:39:50
|
Looks like there are over 10 thousand .jxl on the main page
|
|
2024-10-05 12:44:57
|
A full comic is often a 768 * >20k pixels JXL
|
|
|
|
jonnyawsom3
|
2024-10-05 12:45:36
|
RAM go brrrr
|
|
|
|
Meow
|
2024-10-05 12:46:46
|
A JXL thumbnail links to a JXL full comic, below 1 MB each
|
|
2024-10-05 12:47:12
|
Oh some are still over 1 MB
|
|
|
|
CrushedAsian255
|
|
Meow
A full comic is often a 768 * >20k pixels JXL
|
|
2024-10-05 12:47:14
|
The entire comic in a single file?
|
|
|
|
Meow
|
2024-10-05 12:47:53
|
Yeah each JXL thumbnail links to one single very long JXL
|
|
|
|
CrushedAsian255
|
|
Meow
Yeah each JXL thumbnail links to one single very long JXL
|
|
2024-10-05 12:48:49
|
How big is the long jxl ?
|
|
|
|
Meow
|
2024-10-05 12:49:20
|
It varies but about 1 MB
|
|
2024-10-05 12:49:54
|
The quality is definitely not that good
|
|
2024-10-05 12:51:35
|
They are all translated to Russian however
|
|
2024-10-05 12:52:32
|
Example
|
|
|
|
HCrikki
|
2024-10-05 01:33:03
|
jxl would be ideal for webtoons since its always progressive and progressively decodes from the top unless a more interesting region exists
|
|
|
|
Meow
|
2024-10-05 01:33:13
|
Its height reaches 40k px
|
|
|
|
HCrikki
|
2024-10-05 01:33:38
|
ideal for creators who generate em from their lossless originals naturally (webcomic creators, illustrators)
|
|
2024-10-05 01:35:12
|
for practical reasons, webtoons should still be split to accomodate caching, preloading and memory constraints (ie first part is short and encoded more lossily so it can be quickly preloaded at little cost compared to rest of chapter)
|
|
|
|
Meow
|
2024-10-05 01:37:01
|
Hmm JXLs from that site are progressive too
|
|
2024-10-05 01:38:41
|
Although comics are not understandable when loading
|
|
|
|
CrushedAsian255
|
|
Meow
Although comics are not understandable when loading
|
|
2024-10-05 01:41:02
|
might be helpful for if you zoom out to get an overview
|
|
2024-10-05 01:41:14
|
also what's the website URL?
|
|
|
|
Meow
|
2024-10-05 01:42:04
|
That's ||hentai.i2p|| that someone mentioned last month. It requires I2P installed
|
|
|
|
CrushedAsian255
|
2024-10-05 01:44:12
|
/Applications/i2p/i2prouter;
|
|
2024-10-05 01:44:18
|
oops that's not my terminal
|
|
2024-10-05 01:45:33
|
can it work through a vpn?
|
|
|
|
Meow
|
2024-10-05 01:48:02
|
For some countries it may be a requirement
|
|
|
|
CrushedAsian255
|
2024-10-05 01:50:52
|
how do i access a site, i have the i2p router settings open
|
|
2024-10-05 01:56:57
|
nevermind i got in
|
|
2024-10-05 01:57:12
|
hangon <@277378565304090636> im moving to <#806898911091753051>
|
|
|
|
HCrikki
|
2024-10-05 03:59:03
|
czkawka (duplicate file scanner) 'partially added' jxl support https://github.com/qarmin/czkawka/issues/1051
|
|
|
|
jonnyawsom3
|
|
Quackdoc
czkawka added jxl but its via pixbuf loader. so expect really bad perf
|
|
2024-10-05 04:02:14
|
a
|
|
|
|
username
|
|
<@245794734788837387> did you ever see much on their Discord about it?
|
|
2024-10-05 04:08:56
|
the Discord server is filled with confusing statements about JXL and AVIF and when I tried questioning some of the statements around JXL I didn't get any helpful/useful answers
|
|
2024-10-05 04:10:32
|
also apparently the main dev is known to be hard to work with so I kinda just gave up
|
|
|
|
jonnyawsom3
|
|
|
CrushedAsian255
|
2024-10-05 04:23:21
|
Some random person sent me this
|
|
|
|
jonnyawsom3
|
2024-10-05 04:25:34
|
> Small file size (It's plaintext
Hmm
|
|
2024-10-05 04:26:40
|
Also could've replied with the Petapixel iPhone video
|
|
|
|
CrushedAsian255
|
|
Orum
|
2024-10-06 01:18:32
|
"better" really depends on the use case
|
|
|
|
HCrikki
|
2024-10-06 01:33:32
|
sqoosh misleads a lot of people. its code should really be updated with no delay
|
|
|
|
CrushedAsian255
|
|
Orum
"better" really depends on the use case
|
|
2024-10-06 01:39:16
|
On average
|
|
|
|
Orum
|
2024-10-06 01:39:50
|
...ehh, all depends
|
|
|
|
Rega
|
|
I'm not sure, but this still stands
>>> Default quality level is 99%, this is primarily a lossy format.
* JXL lossless compression ratio is poor, but not as poor as PNG.
* AVIF or PNG are better choices for sharing lossless reference images
|
|
2024-10-06 05:33:57
|
Someone should tell them💀
|
|
|
|
Meow
|
2024-10-06 05:37:22
|
People want bigger
|
|
|
|
CrushedAsian255
|
2024-10-06 05:38:22
|
they probably saw 99 has a bigger filesize and assume it's better
|
|
|
|
Meow
|
2024-10-06 05:40:48
|
The largest artwork in lossless JXL I have is 95.5 MB. It's 184 MB in lossless AVIF
|
|
|
|
CrushedAsian255
|
2024-10-06 05:41:09
|
what -e / -z settings were you using?
|
|
|
|
Meow
|
2024-10-06 05:41:23
|
-e 7
|
|
2024-10-06 05:41:55
|
It's 10500 * 10500 px with film grains so hence the file size
|
|
|
|
Rega
|
|
Meow
People want bigger
|
|
2024-10-06 05:42:06
|
That's what she said
|
|
|
|
Meow
|
2024-10-06 05:43:14
|
|
|
2024-10-06 05:43:15
|
From the quote earlier in <#822105409312653333>
|
|
2024-10-06 05:45:11
|
The hated Apple also agrees with "storage is cheap"
|
|
|
|
Orum
|
2024-10-06 05:48:23
|
I have one that's 111.7 MiB in xz, and larger in <:JXL:805850130203934781>
|
|
|
|
CrushedAsian255
|
|
Orum
I have one that's 111.7 MiB in xz, and larger in <:JXL:805850130203934781>
|
|
2024-10-06 06:11:15
|
What encode settings
|
|
|
|
Orum
|
2024-10-06 06:12:48
|
In JXL? Uhhh, the usual: `-e $1 -d 0 --quiet --streaming_input --streaming_output` ($1 is used here as I sweep the effort scale when encoding, and then take the smallest)
|
|
|
|
CrushedAsian255
|
2024-10-06 06:13:46
|
Try -g 3 -I 100
|
|
|
|
Orum
|
2024-10-06 06:14:09
|
ugh, I don't know that I have the RAM to spare for that RN
|
|
|
|
CrushedAsian255
|
2024-10-06 06:14:27
|
Use swap
|
|
|
|
Orum
|
2024-10-06 06:15:39
|
I haven't even created a swap partition in ages
|
|
|
|
Meow
|
2024-10-06 07:03:45
|
Randomly tested a platform that can support JXL (even for avatars) on I2P http://gyt5ktdyt5mrjaqzb63jro77bvc5rifq3dxtktvxrqgml6qjl6ma.b32.i2p/
|
|
2024-10-06 07:05:59
|
Completely JXL
|
|
2024-10-06 11:26:16
|
I moved my I2P to the spare 24/7 device
|
|
|
|
Orum
|
2024-10-06 05:41:48
|
alright, finally had enough RAM (and CPU) available to test it out with -g 3 and -I 100:
```
117113480 src.ppm.xz
279765905 e8.jxl
280176189 e10.jxl
280372228 e9.jxl
358541731 e7.jxl
```
still doesn't even come close to `.ppm.xz` <:SadOrange:806131742636507177>
|
|
|
|
jonnyawsom3
|
2024-10-06 07:05:44
|
So Factorio, OpenTTD(?) and whatever that is all compress >50% better as xz than JXL for whatever reason...
|
|
|
|
username
|
2024-10-06 07:12:53
|
what was that cjxl setting that re-enabled some form of global optimization that isn't compatible with streaming?
|
|
|
|
Orum
|
2024-10-06 07:13:04
|
yeah, I was talking about it with Jon in the other channel back when I first discovered it: https://discord.com/channels/794206087879852103/794206170445119489/1213140969369632778
|
|
2024-10-06 07:14:10
|
that's the "small" (copped) version of the image though
|
|
2024-10-06 07:18:18
|
that might have also been with texture compression on in-game; I've since disabled that but the problem still persists
|
|
|
|
jonnyawsom3
|
|
username
what was that cjxl setting that re-enabled some form of global optimization that isn't compatible with streaming?
|
|
2024-10-06 07:19:39
|
e10, Patches, Progressive DC... Those are the only ones that come to mind
|
|
|
Orum
that might have also been with texture compression on in-game; I've since disabled that but the problem still persists
|
|
2024-10-06 07:20:58
|
Wouldn't make much of a difference. The only 'real' solution here would be referencing the spritesheet for patches and then layering the shading, ect over top
|
|
|
|
Orum
|
2024-10-06 07:21:44
|
or just good pattern recognition over a wide area, which is what LZMA appears to do very well here, but <:JXL:805850130203934781> does not
|
|
|
|
jonnyawsom3
|
2024-10-06 07:39:24
|
Just pattern recognition doesn't work here, there's different shading, lighting, overlapping tiles/sprites and particle effects. Wider searching for matches mitigates it but JXL is limited to 1024 x 1024 at once without clean patches
|
|
|
|
Orum
|
2024-10-06 07:41:48
|
but if pattern recognition alone doesn't work, then why would LZMA do so well?
|
|
|
|
jonnyawsom3
|
2024-10-06 07:49:14
|
Because while the pixels aren't exact matches due to all of the above, they are close. So LZMA can still put them together, and use less bits for the differences per sprite (Completely guessing)
To do the same in JXL would essentially be the problem with spline encoding currently. Finding matches, removing from the image, and then encoding the 'overlay' of different lighting/pixels/ect with normal tools to put on top of the patches
|
|
|
|
VcSaJen
|
|
Orum
alright, finally had enough RAM (and CPU) available to test it out with -g 3 and -I 100:
```
117113480 src.ppm.xz
279765905 e8.jxl
280176189 e10.jxl
280372228 e9.jxl
358541731 e7.jxl
```
still doesn't even come close to `.ppm.xz` <:SadOrange:806131742636507177>
|
|
2024-10-07 04:34:37
|
Why ppm instead of bmp? does xz react poorly to non-printable characters?
|
|
|
|
Orum
|
2024-10-07 05:05:44
|
why use bmp when ppm exists?
|
|
|
|
A homosapien
|
2024-10-07 05:26:50
|
BMP compresses better with lzma bruh
|
|
2024-10-07 05:27:07
|
Try it out and see for yourself
|
|
|
|
Orum
|
2024-10-07 05:45:28
|
it doesn't for me:
```117305280 factorio.bmp.xz
117113480 factorio.ppm.xz```
|
|
2024-10-07 05:46:43
|
BMP is worse by ~0.1638% 😁
|
|
|
|
w
|
2024-10-07 05:51:22
|
use bmp with lossy jpeg
|
|
|
|
A homosapien
|
2024-10-07 11:39:49
|
I usually get smaller results with bmp: https://discord.com/channels/794206087879852103/803645746661425173/1281011179556175914
|
|
2024-10-07 11:40:07
|
Anyways this disscussion should carry over to https://discord.com/channels/794206087879852103/794206087879852106
|
|
|
|
Orum
|
2024-10-08 02:18:46
|
well in any case the difference should be negligible
|
|
|
|
AccessViolation_
|
|
Meow
Completely JXL
|
|
2024-10-08 07:43:46
|
One of the things I still want to do is make a website that only allows recent technologies. So JPEG XL for images, HTTP 3 with QUIC instead of TCP, post quantum encryption only, IPv6 only, etc
|
|
|
|
_wb_
|
2024-10-08 09:56:08
|
https://dicom.nema.org/medical/dicom/current/output/html/part05.html#sect_8.2.15
|
|
2024-10-08 10:06:12
|
New DICOM standard includes jxl as a payload codec option!
|
|
2024-10-08 10:06:45
|
This is good news for medical imaging.
|
|
|
|
jonnyawsom3
|
2024-10-08 10:06:52
|
Huh, it's actually recommended as a universal replacement too, so better than just being supported
https://ieeexplore.ieee.org/document/10205928
> Hence, this paper suggests an emerging Lossless compression algorithm for a universal replacement for medical file size reduction.
|
|
|
|
Demiurge
|
2024-10-09 03:03:11
|
Nice. That's tremendously cool
|
|
|
|
lonjil
|
2024-10-09 09:58:48
|
I noticed this in Annex F.5 "Encapsulated JPEG XL Encoded Images":
> A JPEG XL stream allows for bit depths up to 24 bits and up to 8192 components. Components do not need to all be the same type or bit depth. The color space of the image is specified in the JPEG XL encoding.
But the maximum is 3 color channels and 4096 extra channels, isn't it?
|
|
|
|
jonnyawsom3
|
|
_wb_
New DICOM standard includes jxl as a payload codec option!
|
|
2024-10-09 10:03:37
|
Could make use of <#803379415106584626> more often ;P
|
|
|
|
CrushedAsian255
|
|
lonjil
I noticed this in Annex F.5 "Encapsulated JPEG XL Encoded Images":
> A JPEG XL stream allows for bit depths up to 24 bits and up to 8192 components. Components do not need to all be the same type or bit depth. The color space of the image is specified in the JPEG XL encoding.
But the maximum is 3 color channels and 4096 extra channels, isn't it?
|
|
2024-10-09 10:35:30
|
thats' what i thought as well
|
|
|
|
_wb_
|
|
lonjil
I noticed this in Annex F.5 "Encapsulated JPEG XL Encoded Images":
> A JPEG XL stream allows for bit depths up to 24 bits and up to 8192 components. Components do not need to all be the same type or bit depth. The color space of the image is specified in the JPEG XL encoding.
But the maximum is 3 color channels and 4096 extra channels, isn't it?
|
|
2024-10-09 12:13:49
|
Yes it is. No idea where they got that. Not that it really matters: it's effectively unlimited.
|
|
|
|
jonnyawsom3
|
2024-10-09 12:17:34
|
Just wait until the first thing someone does is try to store a full CT scan in a single JXL
|
|
|
|
Quackdoc
|
2024-10-09 12:45:19
|
> In Fedora, we are considering and leaning toward using JPEG XL for our default background images going forward, and it would be great if there was a way for cosmic-bg to support JPEG XL as well, so that we don't need an alternative file format for COSMIC to be able to load it.
|
|
2024-10-09 12:45:22
|
neat
|
|
|
|
Demiurge
|
2024-10-09 01:18:30
|
The momentum behind jxl's eventual world domination swells to unstoppable levels.
|
|
2024-10-09 01:19:42
|
It's similar to the momentum driving the steadily increasing adoption of other new file formats like zstd
|
|
|
|
Quackdoc
|
2024-10-09 01:21:31
|
so it looks like cosmic folk might want jxl-oxide to support dynamicimage? it's not hard to do tho
|
|
|
|
Demiurge
|
2024-10-09 01:22:08
|
When something is just plain cool and well designed it will eventually take over... as long as there are good tools available that let people use it
|
|
|
|
Quackdoc
|
2024-10-09 02:24:47
|
https://github.com/pop-os/cosmic-bg/issues/44
|
|
2024-10-09 02:25:14
|
whether they choose to go with jpegxl-rs or jxl-oxide I dunno, I need to sleep, but at least I have them another option
|
|
|
|
CrushedAsian255
|
|
Quackdoc
whether they choose to go with jpegxl-rs or jxl-oxide I dunno, I need to sleep, but at least I have them another option
|
|
2024-10-09 02:28:44
|
Is jpegxl-rs just Rust libjxl bindings?
|
|
|
|
Quackdoc
|
2024-10-09 02:31:13
|
yeah
|
|
2024-10-09 02:31:17
|
gpl'd lol
|
|
|
|
jonnyawsom3
|
|
Huh, it's actually recommended as a universal replacement too, so better than just being supported
https://ieeexplore.ieee.org/document/10205928
> Hence, this paper suggests an emerging Lossless compression algorithm for a universal replacement for medical file size reduction.
|
|
2024-10-09 02:42:51
|
Some more info https://www.dicomstandard.org/news-dir/current/docs/sups/sup232-slides.pdf
|
|
|
|
Foxtrot
|
2024-10-09 03:07:33
|
i still dont understand what problem image-rs has with adopting jxl... if they want specs for free they can just come here and grab drafts
|
|
|
|
jonnyawsom3
|
2024-10-09 03:23:43
|
I was tempted to mention that, seeing as their last reply was "I posted a link to the TIFF Spec so it's okay", but there's a reason it's in this Discord and not on jpeg.org
|
|
|
|
Quackdoc
|
|
Foxtrot
i still dont understand what problem image-rs has with adopting jxl... if they want specs for free they can just come here and grab drafts
|
|
2024-10-09 03:25:00
|
its just sad that we have no real alternatives yet
|
|
2024-10-09 03:25:06
|
Im hoping RIL takes off
|
|