|
Meow
|
2025-02-10 03:26:48
|
Unfortunately not the latest version
|
|
|
Demiurge
|
2025-02-10 08:13:29
|
Timestomp? ๐
|
|
|
|
Meow
|
|
Demiurge
Timestomp? ๐
|
|
2025-02-11 01:38:32
|
https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?name=Trojan%3APowerShell%2FTimestomp.A&threatid=2147777453
|
|
|
|
Demiurge
|
2025-02-11 01:52:42
|
Who makes these up lol
|
|
2025-02-11 01:52:50
|
I guess some employee at microsoft
|
|
2025-02-11 01:52:59
|
Timestomp trojan ๐
|
|
|
|
Meow
|
2025-02-11 02:15:42
|
Even ChatGPT told more about it
> You're right! The PowerShell approach still has a risk of being flagged by Microsoft Defender due to the Timestomp behavior (modifying file timestamps), which is why we need a safer approach that avoids using PowerShell.
|
|
|
|
Demiurge
|
2025-02-11 04:17:07
|
You guys realize you're asking a random number generator for information right?
|
|
|
Quackdoc
|
2025-02-11 04:18:45
|
b{ru,a}sh avoids power shell :D
|
|
|
|
Demiurge
|
2025-02-11 04:19:22
|
I wish Korn shell was more well known
|
|
|
|
Quackdoc
|
2025-02-11 04:42:04
|
I was personally never really a massive fan of ksh
|
|
|
|
Demiurge
|
2025-02-11 05:07:38
|
If you are a fan of bash you're a fan of ksh.
|
|
2025-02-11 05:08:04
|
A slower, more bloated, less permissively licensed version of ksh
|
|
2025-02-11 05:08:34
|
Most people aren't aware of ksh and don't know that bash is basically the gnu version
|
|
2025-02-11 05:09:02
|
All of the so called "bashisms" originate from ksh
|
|
2025-02-11 05:10:06
|
So most bash scripts work just fine with /bin/ksh
|
|
2025-02-11 05:10:19
|
With no changes
|
|
2025-02-11 05:13:21
|
Same exact syntax copied exactly
|
|
|
|
Meow
|
2025-02-11 06:06:36
|
macOS has switched to Zsh
|
|
|
|
Demiurge
|
2025-02-11 06:24:09
|
zsh has its own unique and incompatible syntax and I think it might be even slower and less efficient than bash
|
|
2025-02-11 06:24:43
|
Off the top of my head I don't know what the advantages are of zsh other than permissive licensing.
|
|
2025-02-11 06:25:02
|
But ksh is public domain
|
|
2025-02-11 06:28:37
|
It's too bad it's not very well known despite being the basis and inspiration for most of bash's features and extensions
|
|
2025-02-11 06:31:13
|
It's basically a faster more compact bash with more permissive licensing
|
|
2025-02-11 06:36:14
|
ksh is based on the standard posix Bourne shell with some convenient extensions, and bash is the same thing rewritten with the infamously terrible GNU coding style, with compatible ksh syntax extensions
|
|
|
spider-mario
|
2025-02-11 10:24:14
|
my Fortran teacher tried to have us use tcsh
|
|
2025-02-11 10:24:35
|
and vi (not vim)
|
|
|
|
Meow
|
2025-02-12 02:34:09
|
Found that Newgrounds may be the largest platform for lossless WebP
|
|
2025-02-12 02:34:46
|
The original PNG is still downloadable by changing URL
|
|
2025-02-12 02:37:29
|
You could check by yourself too and the score would be 0 in DSSIM and 100 in SSIMULACRA2
|
|
|
TheBigBadBoy - ๐ธ๐
|
2025-02-12 10:29:59
|
https://github.com/xiph/flac/releases/tag/1.5.0
|
|
2025-02-12 10:30:01
|
[โ ](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&name=av1_woag)
|
|
|
Fox Wizard
|
2025-02-12 11:04:17
|
Heh, a minute of encode time resulted in a smaller file for me than an older encode that took half a day to finish <:KekDog:884736660376535040>
|
|
2025-02-12 11:24:01
|
~~Now I feel like re encoding my entire music library~~
|
|
|
RaveSteel
|
2025-02-12 11:29:08
|
At this rate we'll hit 2.0 before 2050
|
|
|
dogelition
|
2025-02-12 11:34:15
|
any idea how it compares to flaccl now?
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
dogelition
any idea how it compares to flaccl now?
|
|
2025-02-12 12:12:07
|
eh, flaccl is ran on GPU and fucking fast
the only way for libFLAC to beat flaccl's speed, is to compress a small file because flaccl's init will take more time
|
|
2025-02-12 12:12:18
|
some numbers:```ps
$ hyperfine -r5 "flac -f -8 a.wav a.flac" "flac -j16 -f -8 a.wav a.flac"
Benchmark 1: flac -f -8 a.wav a.flac
Time (mean ยฑ ฯ): 13.148 s ยฑ 0.194 s [User: 12.758 s, System: 0.361 s]
Range (min โฆ max): 12.934 s โฆ 13.318 s 5 runs
Benchmark 2: flac -j16 -f -8 a.wav a.flac
Time (mean ยฑ ฯ): 2.404 s ยฑ 0.012 s [User: 14.126 s, System: 1.355 s]
Range (min โฆ max): 2.395 s โฆ 2.425 s 5 runs
Summary
flac -j16 -f -8 a.wav a.flac ran
5.47 ยฑ 0.09 times faster than flac -f -8 a.wav a.flac
```
|
|
|
|
Meow
|
2025-02-12 03:16:56
|
Newgrounds doesn't use the highest compression rate for lossless WebP
|
|
|
|
Fox Wizard
|
|
Fox Wizard
Heh, a minute of encode time resulted in a smaller file for me than an older encode that took half a day to finish <:KekDog:884736660376535040>
|
|
2025-02-12 04:55:48
|
Sad, seems there's less of a difference with 16b 44.1kHz ~~didn't realize my test files were 24b <:KekDog:884736660376535040>~~
|
|
2025-02-12 04:55:58
|
At least it's a whole lot faster
|
|
2025-02-12 04:58:03
|
Sad that I still can't use flaccid since Samsung still can't play them. Hoped it would have been fixed over the years but they can't even be played on a fully up to date S25 Ultra lmao
|
|
|
|
Meow
|
2025-02-14 06:44:14
|
Why can **lossless** WebP reduce over 80% for this image?
|
|
2025-02-14 06:45:07
|
From 4.6 MB to only about 850 KB
|
|
2025-02-14 06:45:47
|
I haven't tried JXL on that yet
|
|
2025-02-14 06:54:54
|
This makes me wonder if such anomaly should stay in a benchmark
|
|
2025-02-14 07:01:19
|
`oxipng -o 4` reduced only about 5% however
|
|
|
A homosapien
|
|
Meow
Why can **lossless** WebP reduce over 80% for this image?
|
|
2025-02-14 07:03:21
|
16-bit PNG -> 8-bit WebP
|
|
|
jonnyawsom3
|
2025-02-14 07:05:43
|
Oh, is it meant to be an actual HDR image? Or just lost in conversion
|
|
|
|
Meow
|
2025-02-14 07:13:13
|
Wow I didn't notice that's a 16-bit image
|
|
2025-02-14 07:14:59
|
almost non-existent in this field
|
|
2025-02-14 07:26:22
|
Then a benchmark including lossless WebP shouldn't use a 16-bit PNG as a source image
|
|
2025-02-14 07:27:06
|
It's definitely lossy
|
|
|
|
A homosapien
|
2025-02-14 08:01:20
|
Lossy transformations should be benchmarked
|
|
2025-02-14 08:02:16
|
Unless they were claiming it's lossless ๐
|
|
|
|
Meow
|
2025-02-14 08:33:35
|
I'm testing a lossless WebP function so being lossless for lossless is required
|
|
2025-02-14 11:50:16
|
Yeah JXL remains 16-bit
|
|
2025-02-14 03:42:46
|
Early results of WebP near-lossless benchmark
https://docs.google.com/spreadsheets/d/1vq0VLsB580yGS9LXAuxf6LTv8CVM_Jv-tBln5ruQ5do/edit?usp=sharing
|
|
2025-02-14 04:05:06
|
To add more info like ssimulacra2 and Jpegli later
|
|
|
|
jonnyawsom3
|
2025-02-18 02:45:00
|
Really wish there was an open source equivalent of this. I just wanna see block choices and frame types without spending a few hundred bucks :P
https://www.interrasystems.com/video-codec-analyzer.php
|
|
|
|
dogelition
|
|
Really wish there was an open source equivalent of this. I just wanna see block choices and frame types without spending a few hundred bucks :P
https://www.interrasystems.com/video-codec-analyzer.php
|
|
2025-02-18 03:52:06
|
https://github.com/xiph/aomanalyzer
|
|
|
|
jonnyawsom3
|
2025-02-18 03:53:11
|
Ah, only AV1 and VP9 so nothing I can use, but thanks
|
|
|
|
RaveSteel
|
2025-02-18 03:54:14
|
Simply transcode all your media ๐ง
|
|
|
|
Meow
|
2025-02-19 05:53:07
|
`winget` being so stupid that I have to reinstall oxipng just after updating it for using it
|
|
|
CrushedAsian255
|
|
Really wish there was an open source equivalent of this. I just wanna see block choices and frame types without spending a few hundred bucks :P
https://www.interrasystems.com/video-codec-analyzer.php
|
|
2025-02-19 06:12:37
|
I have been thinking of making something like that for a while; only thing is i absolutely suck at frontend
|
|
|
|
dogelition
|
2025-02-20 08:30:42
|
the latest android beta can now take hdr screenshots, as png + gain map in this format https://skia.googlesource.com/skia.git/+show/0d94e966268bbc200ea57e074f33afca6321e483
|
|
|
|
jonnyawsom3
|
2025-02-20 09:07:36
|
Oh god it got even worse
|
|
|
|
CrushedAsian255
|
2025-02-20 09:26:03
|
UltraHDR PNG ๐คฎ
|
|
|
|
Quackdoc
|
|
CrushedAsian255
UltraHDR PNG ๐คฎ
|
|
2025-02-20 09:41:03
|
at least that makes more sense then jpeg considering png at least has enough bits to make it look ok
|
|
2025-02-20 09:41:25
|
imo this is a (minor) win
|
|
|
|
RaveSteel
|
2025-02-20 10:12:50
|
I would be surprised if the screenshots are more than 8bit
|
|
|
|
Quackdoc
|
2025-02-20 10:15:31
|
I mean, if you are running HDR they better as fuck be lol
|
|
2025-02-20 10:15:53
|
I know mine are since I have a 10bit display
|
|
|
|
CrushedAsian255
|
2025-02-20 10:20:53
|
although: why can't they just store it as an actual HDR image, instead of a gainmap?
|
|
|
|
Quackdoc
|
2025-02-20 10:30:12
|
because then people on SDR phones can't see it nicely
|
|
|
username
|
2025-02-20 10:32:01
|
software skill issue
|
|
|
|
Quackdoc
|
2025-02-20 10:36:15
|
indeed, well, not if you use gainmaps [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=av1_dogelol)
|
|
|
|
Meow
|
|
dogelition
the latest android beta can now take hdr screenshots, as png + gain map in this format https://skia.googlesource.com/skia.git/+show/0d94e966268bbc200ea57e074f33afca6321e483
|
|
2025-02-21 02:04:45
|
Can JXL do this as well?
|
|
|
|
jonnyawsom3
|
2025-02-21 02:18:42
|
Yes, but there's no reason it should
|
|
|
|
username
|
2025-02-21 02:23:55
|
gainmaps are incredibly wasteful. inverse gainmaps I would say are way less wasteful but as of yet no one uses inverse ones probably because they ruin what i see as one of the main points of gainmaps which is to allow images to look fine in dumb or old software
|
|
|
|
Quackdoc
|
|
Meow
Can JXL do this as well?
|
|
2025-02-21 02:37:14
|
any software that can handle jxl would likely be capable of at least to some extent tonemapping, it wont be as good as gainmaps, but good enough that it doesn't make too much sense most likely. at least not enough sense to invest in
|
|
|
|
CrushedAsian255
|
2025-02-21 04:54:36
|
Arenโt gainmaps supported in the next version of JXL ?
|
|
|
|
jonnyawsom3
|
2025-02-21 05:10:07
|
0.11 added the Gainmap API
|
|
|
_wb_
|
2025-02-21 10:07:14
|
Gain maps are supported mostly because otherwise some people will consider it a feature gap, but there is no real reason to use it since the best way to do HDR in jxl is to just encode an actual HDR image; libjxl will even do some tone mapping to SDR if you ask it to, though the best approach is to handle tone mapping not as part of image decode but in the application/OS-level color management, since you'll want to adjust the tone mapping as the display settings change (which can be basically all the time if you have automatic brightness adjustment enabled).
|
|
|
|
Quackdoc
|
|
_wb_
Gain maps are supported mostly because otherwise some people will consider it a feature gap, but there is no real reason to use it since the best way to do HDR in jxl is to just encode an actual HDR image; libjxl will even do some tone mapping to SDR if you ask it to, though the best approach is to handle tone mapping not as part of image decode but in the application/OS-level color management, since you'll want to adjust the tone mapping as the display settings change (which can be basically all the time if you have automatic brightness adjustment enabled).
|
|
2025-02-21 10:19:37
|
> though the best approach is to handle tone mapping not as part of image decode but in the application/OS-level color management,
sadly, this will almost always universally suck. I know of a whopping 2 applications that manage to do tonemapping OK. on a "platform" level, none have acceptable results
|
|
2025-02-21 10:19:47
|
perhaps KDE gets the closest
|
|
|
|
_wb_
|
2025-02-21 10:31:25
|
Chrome does OK...
|
|
|
|
Demiurge
|
2025-02-21 04:05:51
|
New! Deprecated! Gainmaps!
|
|
2025-02-21 04:06:11
|
Now in 0.11! Please do not use!
|
|
|
|
_wb_
|
2025-02-21 04:32:52
|
lol well I am not going to tell people what to use or not use, it's just my personal preference to keep images simple and have just one image per image
|
|
|
|
jonnyawsom3
|
2025-02-21 04:38:16
|
Animated, Layered, Paged, Gainmapped JPEG XL files ๐
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
Animated, Layered, Paged, Gainmapped JPEG XL files ๐
|
|
2025-02-21 07:42:00
|
*in a comic book archive
|
|
|
|
_wb_
|
2025-02-21 09:05:14
|
Seriously has someone counted how many lines of C++ code the whole gain maps thing has been adding to Chrome?
|
|
|
|
Quackdoc
|
2025-02-21 09:39:25
|
is it not done in rust?
|
|
2025-02-21 09:39:43
|
oh I guess not since it will depend on the decoder
|
|
|
|
Demiurge
|
|
_wb_
lol well I am not going to tell people what to use or not use, it's just my personal preference to keep images simple and have just one image per image
|
|
2025-02-21 11:26:42
|
What? Nah, you should totally tell people not to use dumb ideas if there are better alternatives available
|
|
|
|
CrushedAsian255
|
|
Demiurge
New! Deprecated! Gainmaps!
|
|
2025-02-22 02:33:03
|
Itโs more like gainmap support was added as a legacy feature and for backwards compatibility. Itโs there to help support older files, but itโs not recommended for newer files
|
|
|
|
_wb_
|
2025-02-22 08:05:13
|
The only niche use case where I think gain maps can be nice, is if you want to store a manually created custom local tone mapping together with your HDR image. For the bulk of the HDR use cases though, I think all we need is some standardization of tone mapping, e.g. depending on the Rendering Intent field, a specific tone mapping algorithm should be used (where "Perceptual" and maybe "Saturation" can leave room for implementation-specific choices).
|
|
|
|
colli
|
2025-02-22 06:47:28
|
Anyone here that converts their manga to some other codec? If yes which codec, and what settings? I got a couple GB's of manga that I want to reduce and I am not too informed about codecs are the best for that nowadays, thanks in advance.
|
|
|
|
jonnyawsom3
|
2025-02-22 08:11:46
|
I recall people saying AVIF did very well for lossy, and naturally JXL wins for lossless (possibly with some optimised settings)
But I'll let the others weigh in
|
|
|
|
RaveSteel
|
2025-02-22 08:25:26
|
WebP does very well for lossless greyscale
|
|
|
AccessViolation_
|
|
_wb_
Seriously has someone counted how many lines of C++ code the whole gain maps thing has been adding to Chrome?
|
|
2025-02-22 08:31:31
|
i was thinking about this in terms of potential for vulnerabilities but i almost forgot google described chrome's internals as "a giant interconnected system of (mutable) pointers" and now nothing really looks that bad in comparison
|
|
|
|
Quackdoc
|
|
colli
Anyone here that converts their manga to some other codec? If yes which codec, and what settings? I got a couple GB's of manga that I want to reduce and I am not too informed about codecs are the best for that nowadays, thanks in advance.
|
|
2025-02-22 08:59:56
|
I convert directly to jxl, avif kills color pages which sucks and I don't have time to do per page encoding
|
|
|
|
colli
|
2025-02-22 09:00:27
|
do you convert losslessly or?
|
|
|
|
RaveSteel
|
2025-02-22 09:00:48
|
Let me run some short tests on manga I have
|
|
|
|
colli
|
2025-02-22 09:01:08
|
thank you RaveSteel I appreciate that
|
|
|
|
RaveSteel
|
2025-02-22 09:01:13
|
Are your files mostly lossy or lossless btw?
|
|
|
|
Quackdoc
|
2025-02-22 09:01:14
|
I do lossless on my PC, lossy on my phone
|
|
|
|
colli
|
2025-02-22 09:01:33
|
lossless
|
|
|
Quackdoc
I do lossless on my PC, lossy on my phone
|
|
2025-02-22 09:02:03
|
makes sense
|
|
|
|
Quackdoc
|
2025-02-22 09:02:30
|
I need to explore using pngquant + jxl vs avif for b&w pages
|
|
|
|
colli
|
2025-02-22 09:02:42
|
AVIF and JXL are both more recent than WebP, correct?
|
|
|
|
RaveSteel
|
|
|
colli
|
2025-02-22 09:03:09
|
I use Linux and an iPhone so I imagine compatibility isn't an issue by the way
|
|
|
|
RaveSteel
|
|
Quackdoc
I need to explore using pngquant + jxl vs avif for b&w pages
|
|
2025-02-22 09:03:51
|
WebP is in my experience either comparable or better than JXL for greyscale. I am currently converting 1000 images to test
|
|
2025-02-22 09:04:14
|
A threadripper would be nice lol
|
|
|
|
colli
|
2025-02-22 09:05:38
|
I imagine for normal comics JXL would be better than WebP, is that correct?
|
|
|
|
RaveSteel
|
2025-02-22 09:05:59
|
JXL is normally better than WebP, but not always
|
|
|
|
Quackdoc
|
2025-02-22 09:09:08
|
1000 images won't take too long
|
|
|
|
RaveSteel
|
2025-02-22 09:13:08
|
I am also benchmarking converting to AVIF, which makes this a good bit slower
|
|
2025-02-22 09:13:29
|
lossless of course
|
|
2025-02-22 09:14:00
|
It's never in the same ballpark, but for completeness sake
|
|
|
|
colli
|
2025-02-22 09:15:03
|
Also, I wonder at what % quality I can notice the degradation, say would I be able to notice anything at 90% quality?
|
|
|
|
RaveSteel
|
2025-02-22 09:15:31
|
Question is, do you plan to discard the originals?
|
|
|
|
colli
|
2025-02-22 09:15:42
|
Probably not
|
|
2025-02-22 09:16:01
|
Tho if I could have them in a more efficient codec I could just keep those and delete the "originals"
|
|
|
|
RaveSteel
|
|
|
Quackdoc
|
|
colli
Also, I wonder at what % quality I can notice the degradation, say would I be able to notice anything at 90% quality?
|
|
2025-02-22 09:23:09
|
depends on the image, manga tone can sometimes get crushed pretty bad depending on which it is
|
|
|
|
colli
|
2025-02-22 09:23:54
|
I see, I guess I'd have to test and see..
|
|
|
|
RaveSteel
|
2025-02-22 09:24:32
|
```
PNG 957M
AVIF 1,2G
JXL 838M
WebP 638M
```
|
|
2025-02-22 09:24:54
|
969 images tested
|
|
|
|
colli
|
2025-02-22 09:24:56
|
Oh wow is that lossless?
|
|
|
|
RaveSteel
|
|
|
colli
|
2025-02-22 09:25:15
|
I didn't expect WebP to be honest
|
|
|
|
RaveSteel
|
2025-02-22 09:25:25
|
I used default effort for JXL, but more savings at higher efforts are possible
|
|
2025-02-22 09:25:41
|
Lossless WebP is not to be underestimated in some cases, this being one of them
|
|
|
|
colli
|
2025-02-22 09:25:57
|
Interesting, thank you for testing it!
|
|
|
|
RaveSteel
|
2025-02-22 09:26:07
|
No problem!
|
|
|
|
colli
|
2025-02-22 09:26:33
|
It seems XL Converter mentions a method, what method did you use?
|
|
|
|
RaveSteel
|
2025-02-22 09:26:53
|
i used cjxl via a script, never used XL Converter
|
|
2025-02-22 09:27:01
|
But others can chime in regarding that software
|
|
|
|
colli
|
2025-02-22 09:27:23
|
Alright, I appreciate the help once again
|
|
|
|
RaveSteel
|
2025-02-22 09:27:54
|
Oh wait, I tested something earlier, my JXL test wasn't quite fair: I still had --faster_decoding 4 set
Let me retry again real quick
|
|
2025-02-22 09:28:43
|
luckily just converting JXL is much faster than my previous test with WebP and AVIF
|
|
|
|
Quackdoc
|
|
RaveSteel
```
PNG 957M
AVIF 1,2G
JXL 838M
WebP 638M
```
|
|
2025-02-22 09:28:48
|
did you verify all the inputs are 8 bit?
|
|
|
|
RaveSteel
|
2025-02-22 09:29:32
|
I did not, but I would be surprised if there were any above 8bit. Manga is greyscale after all
|
|
2025-02-22 09:29:35
|
But let me verify
|
|
|
|
Quackdoc
|
2025-02-22 09:30:38
|
grayscale actually needs more bits to represent subtle differences because its a single channel
|
|
|
|
RaveSteel
|
2025-02-22 09:31:21
|
```
JXL 582M
```
|
|
2025-02-22 09:31:28
|
Sorry for my earlier misshap
|
|
2025-02-22 09:31:43
|
JXL is actually best, but WebP still compares quite nicely!
|
|
2025-02-22 09:31:57
|
And as I mentioned, more savings are possible using higher efforts
|
|
|
Quackdoc
grayscale actually needs more bits to represent subtle differences because its a single channel
|
|
2025-02-22 09:32:49
|
Every image is 8 bit
|
|
|
|
Quackdoc
|
|
RaveSteel
```
JXL 582M
```
|
|
2025-02-22 09:33:35
|
0.0
|
|
|
|
colli
|
2025-02-22 09:34:59
|
Oh wow that's nuts
|
|
|
|
RaveSteel
|
2025-02-22 09:35:44
|
Let me do another test, at effort 8 this time
|
|
|
|
colli
|
2025-02-22 09:35:48
|
What arguments did you use, it seems XL converter uses cjxl
|
|
|
|
RaveSteel
|
2025-02-22 09:36:04
|
Just -d 0 and -e 7
|
|
2025-02-22 09:36:12
|
the latter one being the default effort
|
|
|
|
Quackdoc
|
2025-02-22 09:36:28
|
PNG input ?
|
|
|
|
RaveSteel
|
2025-02-22 09:36:50
|
I didn't optimise the PNGs before, if that is what you're asking
|
|
|
|
Quackdoc
|
2025-02-22 09:36:51
|
probably worth using ect or oxipng
|
|
|
|
colli
|
2025-02-22 09:37:20
|
Oh you can optimise them beforehand?
|
|
|
|
RaveSteel
|
2025-02-22 09:37:34
|
Yes, using oxipng for example
|
|
|
|
colli
|
2025-02-22 09:38:05
|
I'll have to do that
|
|
|
|
RaveSteel
|
2025-02-22 09:39:50
|
You will likely find some recommendations for options with oxipng if you are searching this discord
|
|
|
|
colli
|
2025-02-22 09:40:38
|
I'll give it a look, thank you so much for the help
|
|
|
|
RaveSteel
|
2025-02-22 09:41:09
|
Glad to help, my effort 8 JXL benchmark is also almost done
|
|
|
RaveSteel
```
JXL 582M
```
|
|
2025-02-22 09:43:12
|
e8:
```
JXL 565M
```
A bit smaller , but not by much
|
|
2025-02-22 09:43:39
|
e9/10 will reduce filesizes further, but take very long to encode
|
|
|
|
colli
|
2025-02-22 09:44:45
|
Would e8 be worth it then?
|
|
|
|
Quackdoc
|
2025-02-22 09:45:39
|
entirely up to you
|
|
|
|
RaveSteel
|
2025-02-22 09:46:30
|
I would suggest you take a few images and compare e7-10 yourself and then decide if time vs. filesize is worth it for you
|
|
|
|
colli
|
2025-02-22 09:46:44
|
Yeah that's what I'll do, thank you
|
|
|
|
RaveSteel
|
2025-02-22 09:50:29
|
Do report back, if you'd like of course
|
|
|
|
colli
|
2025-02-22 09:59:28
|
I compressed some volumes, seems to be fast enough, and I am seeing some gains here and there, seems pretty worth it
|
|
|
|
RaveSteel
|
|
|
jonnyawsom3
|
|
RaveSteel
e8:
```
JXL 565M
```
A bit smaller , but not by much
|
|
2025-02-22 10:19:01
|
I'd try group size instead of effort, might scale better
|
|
|
|
RaveSteel
|
2025-02-22 10:34:23
|
```
g3 571M
g2 576M
g1 582M
g0 590M
```
|
|
2025-02-22 10:34:43
|
Indeed
|
|
|
damian101
|
|
colli
Anyone here that converts their manga to some other codec? If yes which codec, and what settings? I got a couple GB's of manga that I want to reduce and I am not too informed about codecs are the best for that nowadays, thanks in advance.
|
|
2025-02-22 10:36:20
|
AVIF should work very well for that purpose, probably better than JXL even, at least if chroma isn't very demanding or the targeted quality not extremely high.
|
|
|
|
RaveSteel
|
2025-02-22 10:36:43
|
For lossy, yes
|
|
|
|
A homosapien
|
|
RaveSteel
e8:
```
JXL 565M
```
A bit smaller , but not by much
|
|
2025-02-22 11:10:51
|
Are your manga PNG inputs black and white or palleted?
|
|
|
|
RaveSteel
|
2025-02-22 11:26:16
|
Most are sRGB, which is commonly so
|
|
2025-02-22 11:32:34
|
A few are palleted, but all of them are 8bit
|
|
|
|
A homosapien
|
2025-02-22 11:40:57
|
Grayscale PNGs compress better, although idk how much better
|
|
|
|
RaveSteel
|
2025-02-22 11:42:57
|
Most scanlation groups publish chapters as 8bit sRGB PNGs or JPGs
Around 180 of the 969 images I tested with are greyscale, sometimes with palette
|
|
|
|
A homosapien
|
2025-02-22 11:43:45
|
Most pages *should* be greyscale
|
|
2025-02-22 11:44:06
|
Smh wasting bits on nothing
|
|
|
|
RaveSteel
|
|
|
Meow
|
2025-02-23 05:47:21
|
Try `cjxl -d 0 -e 10 -E 4 -I 100 -g 3` ๐ซก
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2025-02-23 08:30:07
|
`--brotli_effort=11` too
but what about `--patches=0` ?
|
|
|
|
CrushedAsian255
|
2025-02-23 09:14:23
|
Why would you not want patches?
|
|
|
|
A homosapien
|
2025-02-23 09:41:41
|
In some edge-cases patches makes filesize bigger lol
|
|
|
|
Meow
|
2025-02-23 10:01:36
|
News about Xiaomi can't implement Ultra HDR correctly https://m.ithome.com/html/833019.htm
|
|
2025-02-23 10:03:35
|
Something JXL can work flawlessly
|
|
|
BlueSwordM
|
|
Meow
News about Xiaomi can't implement Ultra HDR correctly https://m.ithome.com/html/833019.htm
|
|
2025-02-24 06:11:40
|
This seems incompetent AF.
|
|
|
|
Quackdoc
|
|
Meow
News about Xiaomi can't implement Ultra HDR correctly https://m.ithome.com/html/833019.htm
|
|
2025-02-24 06:29:41
|
translate is failing for me, what's the issue here?
|
|
|
|
Meow
|
2025-02-24 06:31:33
|
ChatGPT translation of the official response
> The local brightness enhancement function for regular HDR photos is supported starting from version 13, which achieves screen brightness enhancement combined with GPU local area dimming. Ultra HDR photo enhancement is supported starting from the 14 Ultra, relying on HWC hardware dimming, and additionally requires the camera to output photos with a Gainmap. The 14 / Pro models do not support HWC hardware dimming, and the camera does not capture photos with a Gainmap, so they do not support Ultra HDR enhancement.
|
|
2025-02-24 06:34:12
|
That's not "version 13". It's the phone Xiaomi 13
|
|
|
|
Quackdoc
|
2025-02-24 06:34:14
|
that's just a plain old hdr issue then, not a gainmap issue
|
|
2025-02-24 06:35:00
|
HWC hardware dimming isn't *strictly* necessary, it can be done otherwise, but I guess xiaomi just didn't want to
|
|
|
|
Meow
|
2025-02-24 06:36:37
|
aka cost efficiency
|
|
|
|
Quackdoc
|
2025-02-24 06:37:37
|
but yeah, the HWC is android's hardware composer (compositor) It uses hardware planes to stack pretty much everything. It want's the hardware plane to dim the SDR content which is likely overlays and stuff.
this is needed for SDR and HDR to co-exist which is needed for android's always on HDR stuff
|
|
2025-02-24 06:38:40
|
HWC can request that the GPU itself does diming
> HWC implementations must request that the SurfaceFlinger apply dimming and dithering on the GPU if they are unable to dither the image at the proper point in the color pipeline.
|
|
2025-02-24 06:39:05
|
this is important distinction because on arm devices, GPU's and Display blocks are completely seperate unlike desktop gpus in which they are both integral
|
|
2025-02-24 06:39:23
|
so basically "do it in shader if you can't in hardware"
|
|
2025-02-24 06:40:32
|
so yeah, weird article, it should be "xioami devices can't do HDR + SDR" which is likely actually necessary for many apps to properly display gainmap content, but not all
|
|
|
|
Meow
|
2025-02-24 06:50:33
|
That's just the journalist like me not able to understand those complicated Ultra HDR stuff
|
|
|
novomesk
|
2025-02-25 11:04:54
|
https://blog.ansi.org/2018/07/why-jpeg-2000-never-used-standard-iso-iec/
Interesting opinion:
"With JPEG 2000โs arrival stunted, camera manufacturers and websites were hesitant to accept the format and waited until it was widely adopted. Of course, with so many manufacturers awaiting the spread of the format, they had effectively suppressed its growth."
|
|
|
|
CrushedAsian255
|
2025-02-25 11:08:37
|
So basically: donโt wait for adoption to adopt it yourself, adopt it yourself so people can start using it now
|
|
|
|
jonnyawsom3
|
2025-02-25 03:09:47
|
That's pretty much the state of JXL right now. All the companies and vendors are ready for it, they just don't want to be first (Or in the case of Apple, they went first but forgot to say it)
|
|
|
|
spider-mario
|
2025-02-25 03:38:37
|
> JPEG serves as a great example of how standardization shapes the world.
does it? sure, โMany people know .jpeg or .jpg as the common file extension for imagesโ, but they also know .gif, which is not (really) standardized, except to the extent that itโs a _de facto_ standard, but then causation goes the other way around (the way that it shaped the world makes us call it a standard)
|
|
2025-02-25 03:38:57
|
and then they cite JPEG 2000 which is arguably a good example of how standardization can fail to shape the world
|
|
|
|
jonnyawsom3
|
2025-02-25 04:07:55
|
Not to mention, JPEG isn't *fully* standardized (Decoding)... Or implemented fully in almost all examples (The De-facto web standard)
|
|
2025-02-25 04:11:34
|
Also, can someone sanity check me in Blender. I tried doing a quick test render but the 32bit EXR file had identical content to the 16bit EXR. I can't tell if I have a setting wrong somewhere or if their documentation/UI is wrong
|
|
|
|
RaveSteel
|
2025-02-25 04:12:59
|
I think someoneentioned this before on here or in the libjxl github issues?
|
|
|
|
spider-mario
|
2025-02-25 11:17:01
|
what does `exrheader` say about it?
|
|
2025-02-25 11:17:23
|
it should output something like this:
```console
$ exrheader test.exr
file test.exr:
file format version: 2, flags 0x0
channels (type chlist):
B, 16-bit floating-point, sampling 1 1
G, 16-bit floating-point, sampling 1 1
R, 16-bit floating-point, sampling 1 1
[โฆ]
```
|
|
2025-02-25 11:17:29
|
so youโll at least know which one is wrong
|
|
|
DZgas ะ
|
2025-02-28 03:05:13
|
finally! avc and h264 encode <:galaxybrain:821831336372338729> in amd
|
|
2025-02-28 03:06:36
|
|
|
2025-02-28 03:06:56
|
so laugh
|
|
|
|
dogelition
|
2025-02-28 03:34:21
|
reminds me of intel's "SSC Encode" https://cdn.discordapp.com/attachments/888419604014170112/1294417156523425993/media.jpg?ex=67c2d8ab&is=67c1872b&hm=16de3deeef9eee00f525cb5fef8fea398e4e4739ee9a2758a8dfd28d5889ba9f&
i *think* that's supposed to refer to https://hevc.hhi.fraunhofer.de/scc
|
|
|
|
Meow
|
|
DZgas ะ
|
|
2025-02-28 04:27:57
|
A common response for those complaining about Nvidia here: you want AMD?
|
|
|
|
DZgas ะ
|
2025-02-28 04:30:51
|
there is nothing better than a videocard that encodes AV1 worse in quality than AVC on the same videocard <:Stonks:806137886726553651>
|
|
|
|
AccessViolation_
|
2025-02-28 04:36:15
|
clearly H.264 is the future
|
|
|
|
_wb_
|
2025-02-28 04:37:03
|
Motion Jpegli is the future ๐
|
|
|
|
jonnyawsom3
|
2025-02-28 05:53:22
|
Motion Jpegli transcoded Animated JPEG XL
|
|
2025-02-28 05:53:30
|
<:Stonks:806137886726553651>
|
|
|
|
AccessViolation_
|
2025-02-28 06:02:51
|
& KNUCKLES
|
|
|
|
jonnyawsom3
|
2025-02-28 10:54:04
|
<@274048677851430913> I'm not sure where I'd bring this up to other Krita devs, but doing some light testing it seems like the LFZ compression on the bitmaps inside KRA files is actually worse than just letting the ZIP work with raw pixels. With uncompressed/fast PNG being next and of course JXL being the smallest (At effort 2 for fast decode).
I put them all inside the same KRA file for comparison, `layer2` being what Krita saved
|
|
|
Kampidh
|
|
<@274048677851430913> I'm not sure where I'd bring this up to other Krita devs, but doing some light testing it seems like the LFZ compression on the bitmaps inside KRA files is actually worse than just letting the ZIP work with raw pixels. With uncompressed/fast PNG being next and of course JXL being the smallest (At effort 2 for fast decode).
I put them all inside the same KRA file for comparison, `layer2` being what Krita saved
|
|
2025-02-28 11:03:43
|
maybe to the bugtracker https://bugs.kde.org/buglist.cgi?quicksearch=product%3Akrita
though the severity should be marked as minor or below (or even a wishlist), since I think changing that would break a lot of compatibility for old files...
|
|
|
|
jonnyawsom3
|
2025-03-01 01:23:43
|
https://bugs.kde.org/show_bug.cgi?id=500877
|
|
2025-03-01 11:58:42
|
Well that was unexpected. They've already tested using JXL internally instead
|
|
2025-03-01 11:59:27
|
And raised the severity
|
|
|
|
CrushedAsian255
|
|
<@274048677851430913> I'm not sure where I'd bring this up to other Krita devs, but doing some light testing it seems like the LFZ compression on the bitmaps inside KRA files is actually worse than just letting the ZIP work with raw pixels. With uncompressed/fast PNG being next and of course JXL being the smallest (At effort 2 for fast decode).
I put them all inside the same KRA file for comparison, `layer2` being what Krita saved
|
|
2025-03-01 12:00:16
|
I wonder why PPM and PNGUncomprssed is so different
|
|
|
|
jonnyawsom3
|
2025-03-01 12:00:40
|
Uncompressed was using filters
|
|
|
|
CrushedAsian255
|
2025-03-01 12:01:11
|
So then putting it in a ZIP effectively just makes a standard PNG?
|
|
2025-03-01 12:01:52
|
As PNG and ZIP both use DEFLATE
|
|
|
|
jonnyawsom3
|
|
|
CrushedAsian255
|
2025-03-01 12:06:00
|
I wonder why they donโt just use uncompressed PNGs then
|
|
2025-03-01 12:06:09
|
Is LFZ some fancy internal thing?
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
Is LFZ some fancy internal thing?
|
|
2025-03-01 12:58:43
|
Turns out I've been saying LFZ and LZF, with the latter being correct. https://oldhome.schmorp.de/marc/liblzf.html
|
|
2025-03-01 01:00:35
|
Krita has a faster implementation of that
|
|
|
|
Kampidh
|
|
Well that was unexpected. They've already tested using JXL internally instead
|
|
2025-03-02 07:10:23
|
Ooh this seems promising
|
|
|
|
jonnyawsom3
|
|
Kampidh
Ooh this seems promising
|
|
2025-03-02 07:17:47
|
They've not mentioned breaking backwards compatibility at all, and actually seem to be thinking of moving to OpenRaster format instead of OpenDocument, which uses PNG internally instead of binary blobs (Or in this case, JXL using the existing export code). I'd be surprised if they made such a bold move, but it'd be a welcome change, assuming the 32bit density regression doesn't sour it.
|
|
|
|
Kampidh
|
2025-03-02 07:23:57
|
Glad they're still eager with jxl, at the very least we still can lay down the groundwork for it~
|
|
2025-03-02 07:25:32
|
*I'm still a bit scared to touch the code for .kra/.krz part* =p
|
|
|
|
DZgas ะ
|
2025-03-02 09:33:33
|
https://www.youtube.com/watch?v=rb-Fh10ipEs <:Thonk:805904896879493180> This is similar to what to do in Webp
|
|
2025-03-02 09:37:55
|
Even despite the doubts and skepticism regarding this method, it seems better than correcting artifacts with a neural network or some other external tools
|
|
2025-03-02 09:54:15
|
there is something to this, especially if the original image is compressed in a low compression. The resulting image looks exactly like the original, without any artifacts other. A really great filter for jpeg that works very deep. Ensuring minimal filter-related losses. Very similar to Webp
|
|
|
|
jonnyawsom3
|
|
DZgas ะ
https://www.youtube.com/watch?v=rb-Fh10ipEs <:Thonk:805904896879493180> This is similar to what to do in Webp
|
|
2025-03-02 10:01:14
|
"It's not a filter, it uses existing information"
Well, jpeg2png does just iteratively smoothen, albeit with knowledge of how DCT works... Quantsmooth does use existing data, but simply tries to lower the quantization in a 'new' JPEG file. Neither like jpegli does, only using the existing data and otherwise quantized values instead of guessing what the rounded values were
|
|
2025-03-02 10:02:00
|
I will download his fork of jpeg2png though, I'm still using the OG one
|
|
|
Jyrki Alakuijala
|
2025-03-02 10:05:10
|
I wanted to integrate this approach in JPEG XL decoding time, but it slowed down decoding by ~2-3x and we dropped it eventually
|
|
|
|
username
|
|
Jyrki Alakuijala
I wanted to integrate this approach in JPEG XL decoding time, but it slowed down decoding by ~2-3x and we dropped it eventually
|
|
2025-03-02 10:12:08
|
why not implement it as something optional? unless you are speaking within the spec realm of things
|
|
|
|
jonnyawsom3
|
2025-03-02 10:13:46
|
Someone in the comments mentioned parallelising based on the 8x8 blocks, since they're isolated from each other. Unless you mean JPEG XL itself and not just JPEG transcoding
|
|
|
|
Jyrki Alakuijala
|
|
username
why not implement it as something optional? unless you are speaking within the spec realm of things
|
|
2025-03-02 10:16:37
|
that was for the spec, it didn't make it
|
|
|
|
DZgas ะ
|
|
Jyrki Alakuijala
I wanted to integrate this approach in JPEG XL decoding time, but it slowed down decoding by ~2-3x and we dropped it eventually
|
|
2025-03-02 10:17:42
|
yes, that's the first thing I noticed. even with standard parameters a small picture is decoded in a few seconds, on a clearly not weak processor. In this case the original Jpeg remains untouched. And this is only decoding in an external program, this is a good option. But if it was built into the into the decoders by default, it really would be too ineffective
|
|
|
|
Jyrki Alakuijala
|
2025-03-02 10:19:36
|
knusperli does similar things but only for the low freq coefficients, so it is much faster
|
|
|
DZgas ะ
yes, that's the first thing I noticed. even with standard parameters a small picture is decoded in a few seconds, on a clearly not weak processor. In this case the original Jpeg remains untouched. And this is only decoding in an external program, this is a good option. But if it was built into the into the decoders by default, it really would be too ineffective
|
|
2025-03-02 10:20:45
|
it doesn't need to be that slow -- a more reasonable speed/quality compromise that goes 98 % the way is possible in 2-3x slowdown
|
|
|
|
DZgas ะ
|
2025-03-02 10:20:58
|
For me, all this became an unexpected gift from the future. Never before have I seen a jpeg picture from 2007 as clearly as now
|
|
|
Jyrki Alakuijala
it doesn't need to be that slow -- a more reasonable speed/quality compromise that goes 98 % the way is possible in 2-3x slowdown
|
|
2025-03-02 10:22:03
|
Do I understand correctly that as a possibility for the jpeg xl decoder. is it possible to implement?
|
|
2025-03-02 10:23:39
|
can jpeg xl really be better just because <:Thonk:805904896879493180>
|
|
|
|
Jyrki Alakuijala
|
2025-03-02 10:26:56
|
it wouldn't be a compliant decoder, jpeg xl decoder specifies the way more exactly -- such a decoder can be a compliant jpeg decoder, but I suspect not a jpeg xl decoder
|
|
2025-03-02 10:27:46
|
it could make a lot of sense nonetheless, especially for the jpeg recompression case
|
|
|
|
DZgas ะ
|
2025-03-02 10:28:05
|
we continue to live in a world in which jpeg xl is the last codec in the history of mankind
|
|
|
Jyrki Alakuijala
it could make a lot of sense nonetheless, especially for the jpeg recompression case
|
|
2025-03-02 10:30:02
|
this could be a great bonus in cases where jpeg is not transcoding but is recompressed from jpeg to jpeg xl. Since jpeg xl itself will also impose compression smoothing. But jpeg artifacts will only create the same unnecessary jpeg xl artifacts
|
|
|
|
Jyrki Alakuijala
|
2025-03-02 10:30:46
|
yes, there is huge potential in jpeg smoothing (or more appropriate dequantization)
|
|
2025-03-02 10:31:17
|
it ended out not to be in the scope of JPEG XL so that we could get something out
|
|
|
|
jonnyawsom3
|
2025-03-02 10:43:09
|
Considering we already have a few complaining that image hashes don't match between JPEG and JPEG XL, maybe it's for the best such a drastic change, even as an improvement, didn't make it into spec. Better left as something for the user to decide, pre-processing or as an 'enhanced' decoder. Extensions are always possible
|
|
|
|
Jyrki Alakuijala
|
2025-03-02 10:44:42
|
yes, the spec is what it is, and it is not that bad -- now the next step with it is to deploy it universally and move on from old JPEG ๐
|
|
|
|
DZgas ะ
|
2025-03-02 10:47:32
|
uhh ooh I'll have to buy a smartphone for 1000$ to use it everywhere <:SadCheems:890866831047417898> av1 and jpeg xl are in the progressive pit of dead moore's law
|
|
|
|
jonnyawsom3
|
2025-03-02 10:48:51
|
ImageToolbox and FossifyGallery cover my mobile needs. We do need a JXL capable camera app though
|
|
|
|
DZgas ะ
|
2025-03-02 10:50:52
|
in android smartphones, the screenshot was always made in png format... before. but since ~2017 it began to be made in jpeg. the reason...
|
|
|
HCrikki
|
2025-03-02 11:11:12
|
upstreaming would be good but honestly unofficial builds adding jxl support shouldve been preferred so as to speedrun adoption, demonstrate viability and workout any kinks
|
|
|
|
jonnyawsom3
|
2025-03-02 11:21:56
|
My phone takes JPEG unless I use the 'cropped' screenshot function, then it's PNG and even with transparency for non-cuboid shapes
|
|
|
|
HCrikki
|
2025-03-02 11:27:44
|
jxl-coder supports encoding, not just decoding so maybe worth looking into for camera apps, as long as theyre not limited to the device's hw-accelerated jpg encoder
|
|
|
|
jonnyawsom3
|
2025-03-03 12:29:29
|
The best they can do is a quality 100 4:2:0 JPEG, otherwise it requires RAW processing too
|
|
|
|
HCrikki
|
2025-03-03 12:38:43
|
is that a device-bound limitation? i thought hw codecs covered 4:4:4 jpeg with higher bits
|
|
|
|
jonnyawsom3
|
2025-03-03 12:59:28
|
Well, that's the best my phone does
|
|
|
|
AccessViolation_
|
|
ImageToolbox and FossifyGallery cover my mobile needs. We do need a JXL capable camera app though
|
|
2025-03-03 09:47:27
|
it would be nice if it was an option in Open Camera. currently it just supports JPEG and PNG. probably the best shot we have at getting many android phones to support it. it's a popular camera app for people that use a custom Android variant
|
|
2025-03-03 09:48:49
|
as a side note, the PNG option is quite nice for taking lossless photos, i haven't seen other camera apps that have that as an option
|
|
|
|
jonnyawsom3
|
|
AccessViolation_
as a side note, the PNG option is quite nice for taking lossless photos, i haven't seen other camera apps that have that as an option
|
|
2025-03-03 10:33:12
|
That's because it's not lossless. It says in the app, it's a quality 100 jpeg re-encoded as PNG
|
|
2025-03-03 10:33:40
|
Webp is lossless at quality 100, but I don't know if it's also from the JPEG
|
|
|
|
AccessViolation_
|
2025-03-03 10:34:34
|
...oh
|
|
2025-03-03 10:34:37
|
i wonder why they do that
|
|
2025-03-03 10:37:53
|
maybe it uses the JPEG camera output as exposed by an android API or something, so they best thing they can do is request a quality 100 JPEG
|
|
|
|
jonnyawsom3
|
|
The best they can do is a quality 100 4:2:0 JPEG, otherwise it requires RAW processing too
|
|
2025-03-03 10:56:11
|
Pretty much
|
|
|
|
AccessViolation_
|
2025-03-03 11:00:17
|
oh sorry I read over that. that sucks
|
|
2025-03-03 11:01:55
|
I've said it before, it's surprising to me that cameras usually don't have *any* way to export a lossless image that's actually been processed. you either get a raw or the highest quality jpeg/hevc/whatever that they let you pick
|
|
2025-03-03 11:04:40
|
it would be like no effort to have an option that just plops out a PNG. they wouldn't even need to spend much time compressing it, just go with the 'up' predictor always for a fast export. then at least you can get lossless, processed images *at all*. they could even do 16 bit per component
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
DZgas ะ
https://www.youtube.com/watch?v=rb-Fh10ipEs <:Thonk:805904896879493180> This is similar to what to do in Webp
|
|
2025-03-03 11:41:02
|
well, from my experience Waifu2x is better for that kind of stuff
|
|
|
|
Meow
|
|
TheBigBadBoy - ๐ธ๐
well, from my experience Waifu2x is better for that kind of stuff
|
|
2025-03-03 12:12:35
|
That's something related to machine learning
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
2025-03-03 12:37:03
|
yeah
|
|
2025-03-03 12:38:32
|
but still better
on many examples, I saw that jpeg2png output is too smooth, and some details disappeared
|
|
|
monad
|
2025-03-03 01:19:03
|
you have to use low iterations, and even then the result is dubious for photos. I did compare libjpeg, jpegli, libjxl and knusperli decode recently with objective metrics and they really disliked knusperli. knusperli discards colorspace metadata, but in other cases I wonder if the scores are justified. it certainly behaves very differently than those other decoders. the objective metrics preferred libjxl above all.
|
|
|
|
jonnyawsom3
|
|
Kampidh
Glad they're still eager with jxl, at the very least we still can lay down the groundwork for it~
|
|
2025-03-03 03:55:11
|
I mentioned [this](https://github.com/libjxl/libjxl/issues/3511) (again) since it was actually effecting the tests. I got [this](https://bugs.kde.org/show_bug.cgi?id=500877#c7) in response
> Yes, I am kinda afraid of depending on an external library for that reason.
|
|
2025-03-03 03:56:01
|
So they're hesitant about possible regressions, ect. Though I did suggest running a test against files of each type to catch any issues before release
|
|
|
couleur
|
2025-03-03 05:04:15
|
was exporting this picture in paint.net, was checking which quality level to choose,
then I ticked lossless and it was smaller than 100 ..??
|
|
|
|
jonnyawsom3
|
2025-03-03 05:23:28
|
For images with few colors or repeating areas, Lossless can be much smaller than lossy
|
|
|
|
A homosapien
|
2025-03-03 05:27:20
|
Pixel art and screenshots especially
|
|
|
|
monad
|
2025-03-03 06:19:10
|
similar to the reason PNG coexists with JPEG
|
|
|
|
jonnyawsom3
|
2025-03-04 06:24:27
|
Hey <@146411656174501888>, I don't suppose you could share your script for converting VRChat photos to WebP without loosing the metadata?
|
|
|
Demez
|
2025-03-04 06:24:58
|
yeah give me a minute
|
|
|
Hey <@146411656174501888>, I don't suppose you could share your script for converting VRChat photos to WebP without loosing the metadata?
|
|
2025-03-04 06:47:51
|
it is a little messy, and requires cwebp, exiftool, and webpmux
adding `-noexif` skips the copying of exif data
adding `-mt` runs multiple cwebp processes at the same time, a lot faster to convert a folder, set to 6 internally, since cwebp uses like 3 threads at most or something
|
|
|
|
jonnyawsom3
|
2025-03-04 07:25:29
|
I'll probably cook up a batch version using exiftool and either cjxl or oxipng at some point
|
|
|
|
Demez
|
2025-03-04 07:51:05
|
will the batch one be multi process?
|
|
|
|
jonnyawsom3
|
2025-03-04 08:39:05
|
I wasn't gonna bother, but probably could
|
|
|
|
Demez
|
2025-03-04 09:45:37
|
it really helps when you have a few hundred images to convert
|
|
2025-03-04 09:46:12
|
6x speedup probably since its 6 processes i have set
|
|
|
|
jonnyawsom3
|
2025-03-04 11:06:04
|
I've got a few thousand, around 6K IIRC
|
|
2025-03-04 11:06:47
|
I've been taking more exponentially. A folder from a year ago has maybe 100, 200 photos. Last month is 900
|
|
|
|
couleur
|
2025-03-06 08:22:42
|
whats jpegli in noob terms
|
|
|
|
username
|
|
couleur
whats jpegli in noob terms
|
|
2025-03-06 08:24:43
|
an encoder for regular old JPEG that produces the best results out of any other JPEG encoder
|
|
|
|
couleur
|
2025-03-06 08:25:16
|
cool
|
|
2025-03-06 08:25:23
|
does paint.net beta use it
|
|
|
|
username
|
2025-03-06 08:25:29
|
no
|
|
2025-03-06 08:26:45
|
PDN just uses whatever the Windows/.NET JPEG encoder is
|
|
2025-03-06 08:27:39
|
you can get better results with this plugin that uses MozJPEG which is considered the second best JPEG encoder: https://forums.getpaint.net/topic/118213-mozjpeg-filetype-2022-08-28/
|
|
|
|
Meow
|
2025-03-06 08:28:22
|
The name itself means "small JPEG"
|
|
|
|
couleur
|
2025-03-06 08:57:42
|
would exporting as a png then using the jpegli cli be an optimal option? (except on the convenience side of course)
|
|
|
|
A homosapien
|
2025-03-06 09:10:17
|
Yeah, thats what I do
|
|
|
|
Meow
|
2025-03-06 09:21:37
|
XnConvert's Jpegli currently exports the identical JPEG
|
|
2025-03-06 09:22:51
|
When the settings are like this
|
|
2025-03-06 09:24:02
|
Don't be scared by "slowest" as Jpegli itself is pretty fast
|
|
2025-03-07 08:22:52
|
Uh the Quite OK family got a new child last year "QOP" https://phoboslab.org/log/2024/09/qop
|
|
2025-03-07 08:23:46
|
Now we have QOI, QOA, and QOP
|
|
|
|
spider-mario
|
2025-03-07 09:38:09
|
is this another attempt at AppImage?
|
|
|
|
Demiurge
|
2025-03-07 11:19:40
|
Reinventing static linking...
|
|
|
|
CrushedAsian255
|
2025-03-07 11:23:33
|
Does Linux have something where you can embed resources in the binary?
|
|
2025-03-07 11:23:39
|
Like I know windows lets you
|
|
2025-03-07 11:23:49
|
And Mac has its whole app bundle by default thing
|
|
|
|
Demiurge
|
2025-03-07 11:45:18
|
Oh, I was thinking of appimage. Reading this article on qop it seems kinda neat maybe...
|
|
|
|
TheBigBadBoy - ๐ธ๐
|
|
CrushedAsian255
Does Linux have something where you can embed resources in the binary?
|
|
2025-03-07 11:51:36
|
for shell scripts, embedding resources by `cat res > script.sh` is quite known
otherwise you typically use appimage
for binaries/executable though, I don't really know (except e.g. Ryujinx accesses them using its own path, so if you UPX it then it crashes)
|
|
|
|
spider-mario
|
2025-03-07 12:01:42
|
Qt has QRC
|
|
|
lonjil
|
|
CrushedAsian255
Does Linux have something where you can embed resources in the binary?
|
|
2025-03-07 12:36:48
|
`#embed`
|
|
|
|
JKUser4592
|
2025-03-09 02:35:56
|
Anyone know any tools or software that can play this animated heic file?
|
|
|
|
CrushedAsian255
|
2025-03-09 02:38:13
|
macOS plays it
|
|
|
|
JKUser4592
|
2025-03-09 02:38:41
|
For Windows, I mean
|
|
|
|
Demiurge
|
2025-03-09 03:19:49
|
You tried mpv?
|
|
|
|
JKUser4592
|
2025-03-09 03:38:16
|
Didn't work
|
|
|
|
jonnyawsom3
|
2025-03-09 06:55:05
|
Unsurprisingly, ffplay works
|
|
|
|
A homosapien
|
2025-03-09 06:59:59
|
at first mpv didn't work, after updating it works fine
|
|
|
|
Demiurge
|
2025-03-09 07:04:53
|
When I'm forced to eat shit and use windows I like using scoop to install things like mpv
|
|
2025-03-09 07:05:19
|
Ah who am I kidding, windows isn't special. All software sucks :)
|
|
2025-03-09 07:06:02
|
But scoop is nice
|
|
2025-03-09 07:06:46
|
Certainly better than choco or winget or whatever
|
|
|
|
A homosapien
|
2025-03-09 07:07:55
|
Wait a second, why are there two video streams in the heic?!
|
|
2025-03-09 07:08:31
|
```
Duration: 00:00:04.80, start: 0.000000, bitrate: 635 kb/s
Stream #0:0[0x3eb]: Video: hevc (Main) (hvc1 / 0x31637668), yuv420p(tv), 256x144, 1 fps, 1 tbr, 1 tbn (default)
Metadata:
title : HEVC Image
Stream #0:1[0x1](eng): Video: hevc (Main) (hvc1 / 0x31637668), yuv420p(tv), 256x144, 632 kb/s, 25 fps, 25 tbr, 1k tbn (default)
Metadata:
creation_time : 2018-03-09T14:16:50.000000Z
handler_name : HEIF/ImageSequence/PictureHandler
vendor_id : [0][0][0][0]
encoder : HEVC Coding
```
|
|
2025-03-09 07:09:57
|
It looks like image viewers only pick up on the first stream, which is a still image. While video players pick up on the second stream, which is animated.
|
|
|
|
jonnyawsom3
|
2025-03-09 07:14:04
|
A HEIF with a HEVC payload like Apple's live photos?
|
|
|
|
Demiurge
|
2025-03-09 07:16:39
|
Because one is animated and one is a single frame
|
|
2025-03-09 07:19:12
|
heif/heic is typically hevc
|
|
|
|
A homosapien
|
2025-03-09 07:25:24
|
The solution is to remux it without the preview image as a `.mov` now it plays fine in most apps
|
|
2025-03-09 07:25:53
|
I feel like I'm repeating myself
|
|
2025-03-09 07:27:05
|
As is turns out I said the same thing months ago: https://discord.com/channels/794206087879852103/805176455658733570/1316511067773472889
|
|
|
JKUser4592
Didn't work
|
|
2025-03-09 07:31:29
|
How did you install mpv? It should work fine since it uses ffmpeg as a base
|
|
|
|
RaveSteel
|
2025-03-09 09:54:49
|
The video stream selection in mpv can be changed using `Shift+_`, use that to properly play files that contain a static frame as the first stream and video on another
|
|
|
|
Demiurge
|
2025-03-09 10:36:33
|
Ahem... `scoop install ffmpeg`
|
|
|
|
JKUser4592
|
2025-03-09 02:09:12
|
What are some tools or image viewers for Windows that can support playing animated AVIF files? What are some Android apps that support playing them on mobile devices?
Also, does anyone know how to use this: https://github.com/penfeizhou/APNG4Android
|
|
|
|
Demiurge
|
|
JKUser4592
What are some tools or image viewers for Windows that can support playing animated AVIF files? What are some Android apps that support playing them on mobile devices?
Also, does anyone know how to use this: https://github.com/penfeizhou/APNG4Android
|
|
2025-03-09 07:46:29
|
Chromium?
|
|
2025-03-10 12:57:50
|
Chromium has the best animated avif support since the maker of avif is in a leadership position on the chromium project.
|
|
|
|
HCrikki
|
2025-03-10 01:22:57
|
wasnt it vlc that had the best? so good (accordingly to themselves, at least 3x better) they trashed their own code for vlc's decoder.
assuming animated avif means basically lossy av1 videos identifying as avif instead of image-only animations (for img-only animations, jxl mostly gives me better results esp losslessly)
|
|
|
|
Demiurge
|
2025-03-10 01:46:17
|
You are thinking of dav1d
|
|
|
|
A homosapien
|
|
JKUser4592
What are some tools or image viewers for Windows that can support playing animated AVIF files? What are some Android apps that support playing them on mobile devices?
Also, does anyone know how to use this: https://github.com/penfeizhou/APNG4Android
|
|
2025-03-10 02:05:21
|
jpegview, qimgv, most modern browsers, and Mpv all work well. I don't know of any android apps that can play animated AVIFs.
|
|
|
|
JKUser4592
|
2025-03-10 03:10:35
|
What are some Android apps that can play animated JXL files?
|
|
|
|
HCrikki
|
2025-03-10 03:16:28
|
ImageToolbox can display jxl animations but its not a gallery app. poor quality though and slow afaik but its supposed to be just a preview for full conversion/edit operations
|
|
|
|
Demiurge
|
2025-03-10 03:29:38
|
Last I checked, jxl on Android is pretty bad
|
|
2025-03-10 03:29:50
|
But maybe it's improved
|
|
2025-03-10 03:30:12
|
Meanwhile apple has universal support across the board, for still image jxl
|
|
|
|
A homosapien
|
|
JKUser4592
What are some Android apps that can play animated JXL files?
|
|
2025-03-10 05:16:42
|
https://github.com/oupson/jxlviewer
|
|
|
|
Meow
|
2025-03-10 06:40:41
|
This may be the only properly working **free and open-source** QOI viewer on macOS
https://github.com/jdpurcell/qView
(the official release hasn't updated yet)
|
|
|
|
JKUser4592
|
|
Demiurge
Chromium?
|
|
2025-03-10 12:56:51
|
You mean regular Google Chrome or something else?
|
|
|
|
Demiurge
|
2025-03-10 12:57:56
|
Any version of chromium will work for viewing animated avif.
|
|
|
|
username
|
2025-03-10 01:10:47
|
*Any modern version
|
|
|
|
novomesk
|
|
Meow
This may be the only properly working **free and open-source** QOI viewer on macOS
https://github.com/jdpurcell/qView
(the official release hasn't updated yet)
|
|
2025-03-10 01:23:20
|
Do you have macOS?
Can you try
https://cdn.kde.org/ci-builds/graphics/kolourpaint/master/
?
|
|
|
|
Meow
|
|
novomesk
Do you have macOS?
Can you try
https://cdn.kde.org/ci-builds/graphics/kolourpaint/master/
?
|
|
2025-03-10 01:32:58
|
Yeah it can although the icon is crap
|
|
2025-03-10 01:34:59
|
Unfortunately it can't open images via dragging to Dock
|
|
2025-03-10 01:35:11
|
|
|
|
|
novomesk
|
2025-03-10 01:44:51
|
And the GIMP on macOS?
Does it open QOI?
|
|
|
|
Meow
|
2025-03-10 01:48:14
|
I haven't installed GIMP after reinstallation of macOS
|
|
2025-03-10 01:48:26
|
Last year it couldn't open when I tested
|
|
|
|
novomesk
|
2025-03-10 02:45:16
|
gimp-3.0.0-RC3-x86_64.dmg contains file-qoi plug-in so QOI should work now.
|
|
|
|
Quackdoc
|
|
Demiurge
Last I checked, jxl on Android is pretty bad
|
|
2025-03-10 03:07:59
|
nope, still bad
|
|
|
|
Demiurge
|
2025-03-10 03:16:31
|
Android remains the eternal disappointment it always was meant to be
|
|
|
|
JKUser4592
|
2025-03-13 08:11:13
|
When I installed jxlviewer on Android, it just showed this screen. It also wouldn't open any of my animated JXL files. How do I fix that?
|
|
|
|
RaveSteel
|
2025-03-13 08:20:37
|
jxlviewer does not offer a file picker function, it can only be used if the file can be "shared" to jxlviewer
|
|
2025-03-13 08:21:19
|
Which is a problem on android, because for me it doesn't show as an option if I want to view an existing JXL
|
|
2025-03-13 08:21:38
|
You may be able to make it available in the share menu depending on your phone
|
|
|
|
CrushedAsian255
|
2025-03-13 08:26:41
|
Infinite splash screen
|
|
|
|
A homosapien
|
|
JKUser4592
When I installed jxlviewer on Android, it just showed this screen. It also wouldn't open any of my animated JXL files. How do I fix that?
|
|
2025-03-13 08:32:06
|
Using the file manger
|
|
|
|
JKUser4592
|
2025-03-13 08:34:58
|
<@167354761270525953> How do I share it to jxlviewer?
|
|
|
|
RaveSteel
|
|
JKUser4592
<@167354761270525953> How do I share it to jxlviewer?
|
|
2025-03-13 08:37:05
|
Try doing what <@207980494892040194> has posted above, note that this may not work if you are a samsung user
|
|
|
|
JKUser4592
|
2025-03-13 09:42:44
|
<@167354761270525953> I have a samsung phone and it didn't work. Anything else I could try?
|
|
|
|
RaveSteel
|
2025-03-13 09:43:12
|
Depending on your image Fossify Gallery should work
|
|
2025-03-13 09:43:26
|
https://github.com/FossifyOrg/Gallery/releases/tag/1.2.1
|
|
|
|
JKUser4592
|
|
RaveSteel
Depending on your image Fossify Gallery should work
|
|
2025-03-13 09:46:15
|
That didn't work, either. https://github.com/FossifyOrg/Gallery/discussions/422
|
|
|
|
RaveSteel
|
2025-03-13 09:49:13
|
Sadly I know of no other app
|
|
2025-03-13 09:49:36
|
jxlviewer can play animated files, but the problem is samsung's implementation of the app selection menu
|
|
|
|
A homosapien
|
2025-03-13 09:56:06
|
that's one of the reasons I don't like samsung
|
|
2025-03-13 09:57:01
|
idk why they needlessly change things from stock android and stack on their bloatware on top
|
|
2025-03-13 09:57:48
|
overall just a clunky and awkward experience
|
|
|
|
RaveSteel
|
2025-03-13 10:01:12
|
I like the experince in general, but this is one of the real downsides
|
|
2025-03-13 10:01:22
|
Although most people will never experience it
|
|
|
|
HCrikki
|
2025-03-13 10:40:07
|
on android, animated jxl plays best in some browsers (firefox nightly, cromite *127* unless you use debug build).
limited to websites naturally
|
|
2025-03-13 10:43:35
|
reminds me cromite ought to have reenabled the patch by now. was there any submarine blocker since the temporary disable or dev just forgot?
|
|
|
|
Quackdoc
|
2025-03-13 10:48:12
|
maybe dev forgot?
|
|
|
|
RaveSteel
|
2025-03-13 11:55:55
|
https://github.com/oupson/jxlviewer/issues/26
|
|
2025-03-13 11:56:07
|
"As of android 15, the mime type of a jxl image is now is image/jxl.
The app is already declared to open this mime type so this issue is fixed in recent android release."
|
|
2025-03-13 11:56:26
|
<@1259949633195737132> just wait for Android 15 and it'll work :^)
|
|
|
|
Demiurge
|
2025-03-14 12:17:00
|
So in other words never because that would require a firmware reflash
|
|
2025-03-14 12:17:15
|
Nice Android
|
|
2025-03-14 12:17:23
|
Nice
|
|
|
|
RaveSteel
|
2025-03-14 12:19:02
|
At least any recent samsung phones will get android 15
|
|
2025-03-14 12:19:48
|
Some other manufacturers have also increased their device lifetime
|
|
|
|
A homosapien
|
2025-03-14 12:31:55
|
Why do companies deviate from stock android? Removing features and piling on bloat? I dusted off my Pixel 3A and got it to work with jxl viewer perfectly fine on Android 12.
|
|
|
|
Demiurge
|
2025-03-14 12:32:04
|
That's the definition of "planned obsolescence"
|
|
|
|
A homosapien
|
|
JKUser4592
<@167354761270525953> I have a samsung phone and it didn't work. Anything else I could try?
|
|
2025-03-14 12:37:44
|
Most likely Samsung's file manager is terrible, try X-plore or anything else. See if it allows you to open .jxl files in jxl viewer
|
|
|
|
BlueSwordM
|
2025-03-14 05:17:31
|
Very nice: https://github.com/kspalaiologos/bzip3
|
|
|
|
A homosapien
|
2025-03-14 05:32:15
|
bzip3 is very good at compressing bitmap images
|
|
|
BlueSwordM
Very nice: https://github.com/kspalaiologos/bzip3
|
|
2025-03-14 05:32:52
|
https://discord.com/channels/794206087879852103/803645746661425173/1281011179556175914
|
|
|
|
Meow
|
2025-03-14 05:34:09
|
The combination of QOI + bzip2 is the default choice for GameMaker
|
|
|
|
BlueSwordM
|
|
A homosapien
bzip3 is very good at compressing bitmap images
|
|
2025-03-14 05:50:03
|
Wait really?
-# โ AV1 is the best image codec; JPEG-XL is absolute trash. Learn More
|
|
|
|
jonnyawsom3
|
|
RaveSteel
Sadly I know of no other app
|
|
2025-03-14 06:32:53
|
ImageToolbox is mainly an editor, but it allows opening animated JXL and does JPEG transcoding too
|
|
|
MSLP
|
|
BlueSwordM
Wait really?
-# โ AV1 is the best image codec; JPEG-XL is absolute trash. Learn More
|
|
2025-03-14 11:21:48
|
shouldn't "Learn More" be clicable a link?
|
|
|
A homosapien
bzip3 is very good at compressing bitmap images
|
|
2025-03-14 11:27:49
|
Any predictions when someone develops bzip4, with ANS entropy coding?
|
|
|
|
RaveSteel
|
2025-03-14 02:28:29
|
https://discord.com/blog/modern-image-formats-at-discord-supporting-webp-and-avif
|
|
|
|
Meow
|
2025-03-14 02:52:53
|
and no JXL
|
|
|
|
jonnyawsom3
|
2025-03-14 02:55:54
|
Cool to see after Scott joined here a while back, though if it took that long to get those two working, JXL could take a fair bit longer given the higher capabilities
|
|
|
|
Meow
|
2025-03-14 03:12:54
|
Yes GIMP 3 supports QOI and its new icon for macOS looks cute
|
|
2025-03-14 03:16:39
|
Following the current macOS app icon rule, they turned the plain white background into a drawing board
|
|
|
|
RaveSteel
|
2025-03-14 03:31:29
|
I like it
|
|
|
|
novomesk
|
2025-03-14 03:34:24
|
QOI works on Telegram Desktop too.
|
|
|
|
AccessViolation_
|
|
RaveSteel
https://discord.com/blog/modern-image-formats-at-discord-supporting-webp-and-avif
|
|
2025-03-14 04:49:20
|
this is neat. I hope they'll support JPEG XL eventually when it lands in the major browsers
|
|
2025-03-14 04:53:44
|
this made me chuckle though
> WebP provides 8 bits per color channel equating to a staggering 16 million colors
someone probably said this in the 1990's ๐
today it just tells me there's going to be color banding in slow gradients
|
|
|
|
Demiurge
|
2025-03-14 05:00:26
|
8 bits? Woooow! 16 million colors! Amazing!
|
|
2025-03-14 05:00:37
|
Staggering!
|
|
|
AccessViolation_
this is neat. I hope they'll support JPEG XL eventually when it lands in the major browsers
|
|
2025-03-14 05:02:30
|
It can support jxl uploads by generating webp thumbnails first
|
|
2025-03-14 05:02:46
|
Someone just needs to add the support to https://github.com/discord/lilliput first
|
|
|
|
spider-mario
|
2025-03-14 05:24:15
|
a staggering 256 shades of grey
|
|
|
|
AccessViolation_
|
2025-03-14 05:30:51
|
me screaming into the void that higher bit depth video would lead to smaller files and less banding meanwhile youtube insists on 8 bit per channel video and my compositor insists on not knowing how to automatically dither higher bit depths anyway so it would all look 8 bpc regardless
|
|
|
|
A homosapien
|
2025-03-14 05:42:02
|
Technically 7.5 bits if we are talking about lossy WebP
|
|
2025-03-14 05:43:50
|
I guess limited YUV is revolutionary when compared to GIF I suppose <:kekw:808717074305122316>
|
|
2025-03-14 05:45:36
|
Not the full 16.7 million colors, but I guess 10.9 million is good enough to be called """modern"""
|
|
|
|
_wb_
|
|
Demiurge
Staggering!
|
|
2025-03-14 05:56:08
|
"Staggering" as in, the colors are staggered into nice bands?
|
|
|
A homosapien
Not the full 16.7 million colors, but I guess 10.9 million is good enough to be called """modern"""
|
|
2025-03-14 05:59:34
|
More like 3 million with tv range yuv
|
|
2025-03-14 06:01:29
|
Full range yuv uses about 1/4th of the available cube of 256^3 colors, since Cb and Cr are constrained. Tv range trims off some more.
|
|
2025-03-14 06:02:34
|
Also the chroma subsampling does not help to get gradients right where the change involves chroma too
|
|
|
|
A homosapien
|
2025-03-14 06:04:58
|
Yikes ๐ฌ it's worse than I thought
|
|
|
|
AccessViolation_
|
|
_wb_
Also the chroma subsampling does not help to get gradients right where the change involves chroma too
|
|
2025-03-14 06:11:28
|
could that explain weird color artifacts where colors appear to change on gradients that are supposed to be just a single color? I've seen that happen on gray-ish gradients around a few specific brightness values
|
|
|
|
_wb_
|
2025-03-14 06:14:42
|
Colors close to gray can indeed get quite noticeably different with lossy webp, an off by one in Cb/Cr can make a pretty large difference when they're around zero...
|
|
|
|
Demiurge
|
2025-03-14 06:41:22
|
But the output of jpegli looks good and is high bit depth...
|
|
|
|
_wb_
|
2025-03-14 07:03:44
|
JPEG is internally 12-bit due to how it scales the DCT coeffs. Actually I am not sure what the internal precision of WebP is. In any case if you do things the simple way and have intermediate 8-bit yuv values, you are throwing away potential precision.
|
|
2025-03-14 07:06:35
|
I haven't read the vp8 spec in enough detail to know what the range of the dequanted DCT coeffs is, but iirc it has a minimum chroma quantization factor of 4 (not 1), so I think even a "webpli" would run into precision limitations faster than what is possible with jpeg
|
|
2025-03-14 07:06:47
|
(also the obligatory 4:2:0 of course)
|
|
|
|
Demiurge
|
2025-03-14 07:11:17
|
JPEG is beautiful now thanks to Jyrki...
|
|
2025-03-14 07:11:42
|
๐ฟ brings a tear to my eye
|
|
|
|
jonnyawsom3
|
2025-03-14 07:25:33
|
Unfortunately "Modern image formats, replacing WebP with JPEG" probably doesn't pitch as well to the team
|
|
|
_wb_
JPEG is internally 12-bit due to how it scales the DCT coeffs. Actually I am not sure what the internal precision of WebP is. In any case if you do things the simple way and have intermediate 8-bit yuv values, you are throwing away potential precision.
|
|
2025-03-14 07:27:45
|
Given the existence of `sharp_yuv` in cwebp, the default might not even be the actual capability of the quite limited format
|
|
|
AccessViolation_
me screaming into the void that higher bit depth video would lead to smaller files and less banding meanwhile youtube insists on 8 bit per channel video and my compositor insists on not knowing how to automatically dither higher bit depths anyway so it would all look 8 bpc regardless
|
|
2025-03-14 07:31:02
|
I was thinking about that earlier today, how JXL could theoretically be smaller at higher bitdepths, but the issue is finding a clean enough source that the values match the gradient predictor, ect. Encoding an 8 bit image has fairly steep steps between each band, but higher bitdepth add more noise at lower amplitude, as far as I'd guess
|
|
|
|
AccessViolation_
|
2025-03-14 07:37:58
|
iirc some study showed that at least for h.264 (?) video it resulted in a slightly smaller file size. not a lot smaller, but not larger at all, so there's little reason to not just do it which is nice
|
|
|
|
jonnyawsom3
|
|
AccessViolation_
this made me chuckle though
> WebP provides 8 bits per color channel equating to a staggering 16 million colors
someone probably said this in the 1990's ๐
today it just tells me there's going to be color banding in slow gradients
|
|
2025-03-14 07:39:17
|
With how often they boasted the color increase, it reminded me of <@604964375924834314>'s 'optimized ICC encoding', shifting the image so that the full range is focused where relevant. So, as far as I'm aware, you could encode a dark image as a far brighter one to use the full range, then decode it and dither to get a much smoother output, ect. At least, assuming I haven't completely misunderstood it
|
|
|
|
MSLP
|
|
AccessViolation_
this is neat. I hope they'll support JPEG XL eventually when it lands in the major browsers
|
|
2025-03-14 08:32:59
|
That would specifically mean chrome, since the discord desktop client is electron-based.
|
|
2025-03-14 08:33:41
|
Unfortunately I suspect it will be the last browser that gets JXL support.
|
|
|
|
_wb_
|
2025-03-14 08:54:28
|
It's weird how the browser with the largest market share somehow always turns into a kind of Internet Explorer
|
|
|
|
AccessViolation_
|
2025-03-14 09:03:39
|
I wonder if at some point it would be more cost efficient for CDNs to polyfill JXL support with Wasm for browsers that still don't support it
|
|
2025-03-14 09:04:18
|
If decoding can be is fast enough, at least. regardless, I don't think they'd bother
|
|
|
With how often they boasted the color increase, it reminded me of <@604964375924834314>'s 'optimized ICC encoding', shifting the image so that the full range is focused where relevant. So, as far as I'm aware, you could encode a dark image as a far brighter one to use the full range, then decode it and dither to get a much smoother output, ect. At least, assuming I haven't completely misunderstood it
|
|
2025-03-14 09:06:02
|
yeah I think remember that. I thought that's also what the "intensity target" was for but I never bothered to check what it actually is
|
|
|
|
HCrikki
|
2025-03-14 09:10:34
|
image hosts focused on displaying only one image should benefit most from wasm for non-apple platforms where native jxl isnt yet available (ie photobucket, deviantart, flickr/smugmug)
|
|
2025-03-14 09:11:14
|
format adoption wise, cdns would need to make jxl their default served format, or the highest priority one to change the status quo. nobody paying cdns demanded webp only or im taking my $ elsewhere
|
|
|
|
jonnyawsom3
|
|
HCrikki
image hosts focused on displaying only one image should benefit most from wasm for non-apple platforms where native jxl isnt yet available (ie photobucket, deviantart, flickr/smugmug)
|
|
2025-03-14 09:14:19
|
I would've thought it'd be the other way around. Download the WASM once, used for many images on a site to make up for the extra download
|
|
|
|
HCrikki
|
2025-03-14 09:21:45
|
least cumbersome adoption would be making the jxl files downloadable, even if browser/site shows a reduced resolution jpeg of the original image (ie if browser doesnt display jxls or wasm decoder is not available or working)
|
|
|
|
AccessViolation_
|
2025-03-14 09:23:09
|
I think for my own site I'd do that anyway: show an image with a reasonable resolution for web use with a tiny "open original" link under it that just takes you to the full original file
|
|
2025-03-14 09:37:35
|
I wonder if a web server can see whether the image was loaded on its own or embedded in another page. if it could, I'd probably even make it load the original when people try to save or open the image in a new tab. though it'd be a bit cursed to have multiple resources behind the same URL like that
|
|
2025-03-14 09:37:58
|
browser caching might interfere with that too
|
|
2025-03-14 09:41:13
|
or you could do `?load-orignal=false` in the URL and it would be pretty obvious to people that they can change it to true to or remove the parameter to get the original, and would fix the caching issue
|
|
|
|
Demiurge
|
|
AccessViolation_
I wonder if at some point it would be more cost efficient for CDNs to polyfill JXL support with Wasm for browsers that still don't support it
|
|
2025-03-14 09:57:17
|
Yeah, it's something that ought to happen yesterday...
|
|
|
|
damian101
|
|
Meow
and no JXL
|
|
2025-03-14 10:00:08
|
won't happen before it's in Chromium
|
|
|
|
HCrikki
|
2025-03-14 10:11:31
|
perhaps "Supporters of chromium-based browsers" could help speed up adoption there? its existence is supposed to show google isnt gatekeeping what the group and broader collective wants (there's linux foundation, ms...)
|
|
2025-03-14 10:12:37
|
code maintained at negligible costs upstream drastically would simplify activation of jxl by default by chromium derivatives even if base chromium and google chrome keep it disabled for their own builds (but otherwise enablable using about:flags)
|
|
|
|
JKUser4592
|
|
A homosapien
How did you install mpv? It should work fine since it uses ffmpeg as a base
|
|
2025-03-15 12:48:09
|
How did you install it?
|
|
|
gb82
|
|
_wb_
JPEG is internally 12-bit due to how it scales the DCT coeffs. Actually I am not sure what the internal precision of WebP is. In any case if you do things the simple way and have intermediate 8-bit yuv values, you are throwing away potential precision.
|
|
2025-03-15 02:15:07
|
considering its a video codec, id guess the internal pipeline to be largely 8-bit for performance reasons. but that's a guess
|
|
|
|
Demiurge
|
|
JKUser4592
How did you install it?
|
|
2025-03-15 04:23:46
|
On windows? scoop install mpv
|
|
2025-03-15 04:24:00
|
On mac? brew install --cask mpv
|
|
|
|
A homosapien
|
|
JKUser4592
How did you install it?
|
|
2025-03-15 06:03:42
|
https://mpv.io/installation/
While scoop is nice. I personally like using Windows builds by zhongfly. It comes with a updater script which I find to be handy.
|
|
|
|
Demiurge
|
2025-03-15 06:09:22
|
That does sound cool but I use scoop for everything
|
|
2025-03-15 06:09:35
|
Not just for mpv
|
|
2025-03-15 06:09:50
|
It's good for other command line tools too including libjxl
|
|
|
|
_wb_
|
|
gb82
considering its a video codec, id guess the internal pipeline to be largely 8-bit for performance reasons. but that's a guess
|
|
2025-03-15 07:44:42
|
Yes, if buffers have to be kept around for inter prediction, then it would make sense to keep those 8-bit yuv420 to keep costs low for hw decode, and to avoid error accumulation you would need to make it fully normatively specified. This is imo one of the things that makes video codecs inherently not so great for high-fidelity: if you want hw decode, and you want it cost-effectively in consumer devices, then the codec has to be designed to fit the lowest common denominator...
|
|
|
|
Demiurge
|
2025-03-15 09:01:48
|
We are lucky to have jxl, and the talented engineers that made it possible.
|
|
2025-03-15 09:02:48
|
With very thoughtful considerations in mind when specifying the bitstream.
|
|
2025-03-15 09:03:19
|
:)
|
|
|
|
gb82
|
|
_wb_
Yes, if buffers have to be kept around for inter prediction, then it would make sense to keep those 8-bit yuv420 to keep costs low for hw decode, and to avoid error accumulation you would need to make it fully normatively specified. This is imo one of the things that makes video codecs inherently not so great for high-fidelity: if you want hw decode, and you want it cost-effectively in consumer devices, then the codec has to be designed to fit the lowest common denominator...
|
|
2025-03-15 04:13:52
|
yeah, and think about how much faster SIMD is when your data sizes are much smaller โ vector registers become much more powerful
|
|
|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
|
2025-03-15 09:37:52
|
is there an image codec that's low latency with high quality that's not JPEG XS? as long as there is size reduction
|
|
|
|
Quackdoc
|
2025-03-15 09:39:10
|
define low latency
|
|
|
|
๐๐ฆ๐๐ฃ๐ธ๐ฅ๐ฉ๐ฏ๐ฆ | ๆไธ่ชฟๅใฎไผๆญ่
| ็ฐ่ญฐใฎๅ
็ด
|
2025-03-15 09:40:18
|
encode time below 20ms
|
|
2025-03-15 09:41:24
|
thinking of which image codec would be the best for remote access/screen sharing, like for virtual machines
|
|
2025-03-15 09:42:39
|
JPEG XS looks really good on paper, but haven't found open-source codecs for it yet, and seems like it's riddled with patents
|
|
|
|
Quackdoc
|
2025-03-15 09:44:24
|
jxl should be able to do that, I dunno if libjxl currently can, perhaps fjxl can
|
|