|
Jyrki Alakuijala
|
2023-09-29 03:09:21
|
I think it will be a better basis for new improvements once we understand better where it works and especially where it doesn't
|
|
2023-09-29 03:10:06
|
this change is mostly inspired by all the difficult images that the community has been sending 🙂
|
|
2023-09-29 03:12:07
|
an example improvement
|
|
2023-09-29 03:14:18
|
another example -- such subtle material textures improve the most
|
|
2023-09-29 03:16:18
|
|
|
2023-09-29 03:18:15
|
|
|
|
BlueSwordM
|
|
Jyrki Alakuijala
this change is mostly inspired by all the difficult images that the community has been sending 🙂
|
|
2023-09-29 03:18:44
|
Ah, so you're measuring distortion in the image domain rather than the transform domain.
|
|
|
|
Jyrki Alakuijala
|
2023-09-29 03:19:12
|
yes
|
|
2023-09-29 03:19:22
|
it sounds very simple
|
|
2023-09-29 03:19:40
|
but I fought for making this competitive for 6 weeks (and it is my third attempt to make this work within the last 4 years)
|
|
2023-09-29 03:20:12
|
still it is not always better, the metrics are worse (except PSNR :-D), and its quite a bit slower
|
|
2023-09-29 03:20:21
|
2 MP/s now -- vs 3 MP/s previous approach
|
|
2023-09-29 03:24:17
|
the images above are --distance 3.0 in both versions
|
|
|
Demiurge
|
|
Jyrki Alakuijala
an example improvement
|
|
2023-09-29 04:21:17
|
So it reduces ringing it looks like
|
|
2023-09-29 04:28:56
|
Which makes sense...
|
|
|
DZgas Ж
|
|
DZgas Ж
in fact, right now I'm most concerned about the length of the artifact
|
|
2023-09-29 05:35:23
|
✍️
|
|
|
DZgas Ж
on -q70, the waviness effect of the artifact is perfectly noticeable, which passes through from the red block.. and you can see that it fades to the top, because red gets further
|
|
2023-09-29 05:36:52
|
I wonder if it was fixed after half a year<:Thonk:805904896879493180>
|
|
2023-09-29 05:38:29
|
I should not forget to test all my old test images
|
|
|
Jyrki Alakuijala
|
|
2023-09-29 05:39:48
|
I try to avoid gradients in my images because I know for sure that it is perfect <:JXL:805850130203934781>
|
|
|
|
Jyrki Alakuijala
|
|
Demiurge
So it reduces ringing it looks like
|
|
2023-09-29 05:54:55
|
Sometimes reduces but sometimes it finds that large long-distance ringing is a good idea
|
|
|
DZgas Ж
I try to avoid gradients in my images because I know for sure that it is perfect <:JXL:805850130203934781>
|
|
2023-09-29 05:55:40
|
8x8 dct can create 8x8 blocks
|
|
2023-09-29 05:56:15
|
On slow gradients where every dct value is a zero
|
|
2023-09-29 05:56:54
|
We try to detect it and increase quant or just use other transforms
|
|
|
OkyDooky
|
2023-09-29 06:57:47
|
I took a C++ class and Assembly concepts were the first things the teacher showed us. I already had learned about that on my own, but it was nice havinf someone experienced in programming and computer science explaining it and putting it in context with the language we were learning. It definitely is the way to go. Don't rest on your Gigabytes to make up for your inefficiencies, basically.
(<@1028567873007927297>)
|
|
|
fab
|
2023-09-29 08:12:01
|
87.138 s8 i 1.23 epf 2
|
|
2023-09-29 08:12:15
|
Should solve most of jxl problems
|
|
2023-09-29 08:12:36
|
But the image would be mostly bqd
|
|
2023-09-29 08:20:28
|
<#806898911091753051> <@1028567873007927297>
|
|
2023-09-29 08:20:39
|
Do you have or take Reddit
|
|
|
|
DZgas Ж
|
|
DZgas Ж
I specially made such an image to demonstrate this at e3, the closest red dot goes exactly into the 8x8 block, and creates an artifact, causing a yellow color, but only within the same block. while on e7, due to the large length of the artifact, it is noticeably much further away from the red block itself.
|
|
2023-09-30 01:05:39
|
well, something has changed in six months. now there is no noise here, but quite visible dots... But the bug itself is not fundamentally fixed. -- in an image where there are only white, green, and red colors, there are noticeable artifacts of blue color
|
|
|
DZgas Ж
on -q70, the waviness effect of the artifact is perfectly noticeable, which passes through from the red block.. and you can see that it fades to the top, because red gets further
|
|
2023-09-30 01:10:18
|
Unfortunately, the wave-type artifacts remained identical, are caused directly by a red object that is nearby
|
|
|
|
Demiurge
|
2023-09-30 05:18:53
|
Honestly that looks like an impossible image for a DCT algorithm...
|
|
|
fab
Do you have or take Reddit
|
|
2023-09-30 05:19:51
|
Is that the brand name of some kind of rat poison?
|
|
|
|
fab
|
|
Demiurge
Is that the brand name of some kind of rat poison?
|
|
2023-09-30 05:27:20
|
I don't know
|
|
2023-09-30 05:27:37
|
Sicily lot of heat
|
|
2023-09-30 05:27:52
|
My mother is using washing machine
|
|
2023-09-30 05:28:36
|
But Giorgia Meloni rules where introduced with reddit posts even in Italy
|
|
2023-09-30 05:28:40
|
R Italy
|
|
2023-09-30 05:28:46
|
R seghesuvip
|
|
2023-09-30 05:29:04
|
I'm tired
|
|
2023-09-30 05:29:14
|
But i'm forced
|
|
2023-09-30 05:30:12
|
But i don't want people to see im a mildy with left girls singing
|
|
2023-09-30 05:30:29
|
I don't Know what ukranians votes
|
|
2023-09-30 05:30:41
|
I come there only to a reason
|
|
2023-09-30 05:31:22
|
Reddit to me was another Instagram
|
|
|
|
Demiurge
|
2023-09-30 05:31:59
|
Hmm. I'm going to nod and pretend I understood that
|
|
|
|
fab
|
|
Demiurge
Hmm. I'm going to nod and pretend I understood that
|
|
2023-09-30 06:18:19
|
I understand reddit because Italy is Berlusconi or Meloni
|
|
2023-09-30 06:19:20
|
So to me accepting next rules comes easier
|
|
2023-09-30 06:19:26
|
My problem is internet
|
|
2023-09-30 06:19:47
|
5g now is 10,9mb wifi 5,09mbps
|
|
2023-09-30 06:20:18
|
4g works always but with safely energetic
|
|
2023-09-30 06:20:37
|
And more hotness after August
|
|
2023-09-30 06:21:05
|
|
|
2023-09-30 06:21:31
|
Then Xiaomi can always confuse you when you want to do and they want to do them
|
|
|
Traneptora
|
2023-10-02 11:35:09
|
Is there a cap on the size of the ICC profile? i.e. if the encoded ICC profile uses a prefix code with length=0, it can read the entire ICC profile without consuming any input
|
|
2023-10-02 11:36:06
|
and since the profile size is U64(), that's potentially 18T reads
|
|
2023-10-02 11:44:10
|
of course, the profile won't be valid, but it will still be read
|
|
|
Eugene Vert
|
2023-10-03 12:53:28
|
IIRC in libjxl limit is maximum ICC `output_size`
|
|
2023-10-03 12:53:43
|
https://github.com/libjxl/libjxl/blob/b55725bd5387576d172c92eede6bef3c6003a87b/lib/jxl/icc_codec.cc#L298-L301
|
|
|
_wb_
|
2023-10-03 09:11:12
|
level 5 limit is 4 MB, level 10 limit is 256 MB for the maximum ICC output_size
|
|
|
|
Jyrki Alakuijala
|
|
DZgas Ж
well, something has changed in six months. now there is no noise here, but quite visible dots... But the bug itself is not fundamentally fixed. -- in an image where there are only white, green, and red colors, there are noticeable artifacts of blue color
|
|
2023-10-03 12:14:11
|
if you start from completely artefact free original, the new code will be slightly more careful with it -- than if you start with an original that already has some artefacts -- after the PR that is going to go in soon
|
|
2023-10-03 12:21:20
|
in the new code, I compute pixel by pixel masking and take a logarithm of it (plus one) -- even relatively small differences can make a big difference because of the logarithm -- small differences in the original allow there to be slightly larger differences in the output, whereas no differences leads to more strict decisions
|
|
|
EricTanYingCong
|
2023-10-04 04:28:08
|
may i ask is there any avaialble wrapper for C# .Net
|
|
|
HCrikki
|
2023-10-04 05:00:54
|
jxl.net, but its really wrapping magick.net
|
|
|
obi wan chadnobi
|
2023-10-04 09:27:31
|
Are there any existing libraries that support JXL conversion in Python?
|
|
|
yoochan
|
2023-10-04 09:29:05
|
imagecodecs I think
|
|
2023-10-04 09:29:57
|
it would be nice if pillow could too, but it's not the case yet
|
|
|
|
obi wan chadnobi
|
2023-10-04 09:37:06
|
thanks. i will have a look now
|
|
|
|
yoochan
|
2023-10-04 09:37:19
|
imagecodecs offer a very restricted API if I remember well...
|
|
2023-10-04 09:38:08
|
I would be glad to encapsulate the full C++ api in python but I'll be lacking time to do so until november 😄
|
|
|
|
Traneptora
|
2023-10-04 12:24:16
|
Wand can, iirc
|
|
|
|
Jyrki Alakuijala
|
2023-10-04 12:28:31
|
https://github.com/web-platform-tests/interop/issues/430 is interesting
|
|
2023-10-04 12:29:47
|
consider +1'ing it to show support
|
|
2023-10-04 01:26:59
|
https://github.com/libjxl/libjxl/pull/2836 is now committed -- JPEG XL lossy will have completely different image quality
|
|
2023-10-04 01:27:12
|
somethings better, somethings worse
|
|
2023-10-04 01:27:39
|
it should overall lead to less dips to bad quality for a given quality level
|
|
2023-10-04 01:28:02
|
possibly more so in the range distance 5 and less than in very high distances
|
|
|
|
yoochan
|
2023-10-04 01:28:08
|
regression ! regression ! where is <@226977230121598977> 😄
|
|
|
|
Jyrki Alakuijala
|
2023-10-04 01:28:42
|
I observe textures being better, materials to be more faithfully presented, and image noise to be more likely not to be smoothed away
|
|
|
|
yoochan
|
2023-10-04 01:29:05
|
for the same/similar bpp ?
|
|
|
|
Jyrki Alakuijala
|
2023-10-04 01:29:07
|
some geometry is better too, but there can occasionally be more ringing
|
|
2023-10-04 01:29:35
|
for some corpora same distance will produce lower bpp, for some higher (mostly higher)
|
|
2023-10-04 01:29:47
|
for photographic corpus I'd anticipate roughly same bpp
|
|
2023-10-04 01:29:58
|
for photo+graphics slightly higher perhaps
|
|
|
|
yoochan
|
2023-10-04 01:30:23
|
what is your setup to assess ? no zoom ? in front of your screen ? most of the time I'm unable to see defects without contrast enhancements 😄
|
|
|
|
Jyrki Alakuijala
|
2023-10-04 01:31:32
|
I'm using mostly 200% pixelized zoom
|
|
2023-10-04 01:31:55
|
but currently I'm using an 8k monitor in 4k mode, so pixels are really square to start with -- and then a 200% zoom on top of that
|
|
2023-10-04 01:33:00
|
I use a viewing distance of about 40 cm, and a 32" monitor
|
|
2023-10-04 03:34:23
|
if I'm reviewing distance 0.5 - 1.0 I can sometimes look at 500 % zoom to know where the errors are -- then look at them again at 200 %
|
|
2023-10-04 05:29:12
|
it would be nice if someone tried it and told about experiences... 🙂
|
|
|
|
DZgas Ж
|
|
yoochan
regression ! regression ! where is <@226977230121598977> 😄
|
|
2023-10-04 08:35:11
|
😴
|
|
2023-10-04 08:37:46
|
it just so happens that despite all my attention to this format, at the moment I do not use it absolutely anywhere, neither practically nor for storage. Even for the purposes of transcoding jpeg -> jxl, I have problems with speed, I have hundreds of thousands of images, but the transcoding speed -e 9 is so slow - that I don't even know what to do with it
|
|
|
diskorduser
|
|
DZgas Ж
it just so happens that despite all my attention to this format, at the moment I do not use it absolutely anywhere, neither practically nor for storage. Even for the purposes of transcoding jpeg -> jxl, I have problems with speed, I have hundreds of thousands of images, but the transcoding speed -e 9 is so slow - that I don't even know what to do with it
|
|
2023-10-05 03:40:39
|
you need to upgrade your cpu.
|
|
|
|
_wb_
|
2023-10-05 05:12:39
|
Or not use -e 9
|
|
|
|
yoochan
|
2023-10-05 06:35:52
|
😅 But you have a good eye to spot defects!
|
|
|
monad
|
2023-10-05 06:51:42
|
next gen image codec
|
|
|
nec
|
2023-10-05 07:04:10
|
To be honest, even for transcoding I use -e 7. In my case the difference between -e 7 file and -e 9 -g 3 -E 11 -I 100 is ~0.5%.
|
|
2023-10-05 07:08:23
|
And for lossy I use -e 6, because it has the best ratio between filesize and quality.
|
|
2023-10-05 07:15:30
|
In some meaning even -e 4 lossy is good. If you check ssimulacra, you can see that -e 4 is the most stable and predictable, while -e 5-9 starts to fluctuate quite a lot. But because -e 4 has significantly higher size, sometimes it's more reasonable to use higher -q value with higher effort setting, like -e 4 -q 85 and -e 6 -q 90, where the latter has similar speed, slightly smaller size and more or less the same quality, just less predictable. Some of the images wouldn't benefit much from it, while some would require -q 91-93 and -q 90 would have perceivable changes. In this meaning -e 4 is good, because even -q 85 always produces good quality.
|
|
|
|
Jyrki Alakuijala
|
2023-10-05 01:14:31
|
I have been trying to make -e 7 more robust with less degradation (but didn't check ssimulacra distributions)
|
|
|
|
OkyDooky
|
2023-10-05 06:58:35
|
If anyone has some experience with the technical side of browsers (specifically Chromium) and has a few minutes, could you look over this thread I made asking for JXL support to be included in Cromite browser\: https://github.com/uazo/cromite/issues/351
Uazo also specifically asked for feedback from people who may know more about this.
|
|
2023-10-05 07:00:57
|
The main issue is one of security, but he may have some other concerns that I'm not properly inferring.
If this gets resolved and support added, then it could be requested for other Chromium-based browsers, thus circling the wagons around the main two (Firefox and Chrome), since we'd eventually have a situation where literally every browser based on them *but them* would support the format.
|
|
|
|
_wb_
|
2023-10-05 07:48:47
|
Did you point them to Thorium already?
|
|
|
username
|
2023-10-05 07:54:34
|
they have
|
|
|
|
Demiurge
|
2023-10-05 11:21:14
|
It is kinda annoying how thorium makes Debian packages but not a flatpak that works on every distro...
|
|
|
Quackdoc
|
2023-10-05 11:29:42
|
anti flatpak supremacy
|
|
|
|
OkyDooky
|
2023-10-06 12:05:15
|
Yup. The main issue he had was in the srs/third\_party folder, the README.chromium files for libjxl and Highway (which is supposedly needed for crossplatform stuff, but doesn't seem appear in the original Chromium patches before version 110) both contained a "Security critical\: yes" line.
(<@794205442175402004>)
|
|
2023-10-06 12:10:13
|
I already checked two CVE databases and both showed the current libjxl version to be "safe." Nothing on Highway, though (no entries period — also no clear reason why it is needed, if at all).
He's asked for feedback from anyone else knowledgeable in this and for help setting up `dependabot`. And that seems to be where we are currently at.
|
|
2023-10-06 12:11:27
|
I just wish it was easy to get it running on RaspberryPi. I was hoping it would provide that edge in performance and help make it more usable to watch online videos on.
(<@1028567873007927297>)
|
|
|
|
username
|
2023-10-06 12:11:29
|
highway is needed for libjxl however chromium already has highway because some other library requires it
|
|
2023-10-06 12:12:11
|
originally I think libjxl was the only library in chromium that required highway but that changed at some point in time
|
|
2023-10-06 12:15:09
|
I haven't fully checked but the thorium devs might still be working under the assumption that chromium doesn't come with highway by default, I'm not fully sure though
|
|
|
|
Demiurge
|
|
Quackdoc
anti flatpak supremacy
|
|
2023-10-06 12:17:13
|
I don't remember what the reasoning was, all I remember was that the reasoning didn't make any sense at all. Like "well there's already a Debian package..."
|
|
2023-10-06 12:18:03
|
Maybe he doesn't use Linux
|
|
2023-10-06 12:18:29
|
But flatpak is pretty convenient especially with the steam deck
|
|
2023-10-06 12:18:50
|
Oh he said because there's already an appimage or something...
|
|
2023-10-06 12:19:33
|
But I don't think that it can auto update, so... that's annoying and sucks.
|
|
|
|
HCrikki
|
2023-10-06 12:32:49
|
appimages can autoupdate but thats less userfriendly than flatpak and mainly suitable for ongoing development imo
|
|
|
|
OkyDooky
|
2023-10-06 01:07:11
|
Interesting. Thank you for that. If you wouldn't mind, could you share that in the issue I linked? I could screenshot this, but it might be nicer for Uazo to "hear it directly," so to speak.
(<@245794734788837387>)
|
|
2023-10-06 01:08:42
|
I don't know if I could check reasonably, either. I was already stepping out of my element by looking into the CVE issue. I think I did pretty well for my first time...
(<@245794734788837387>)
|
|
|
|
Quackdoc
|
|
Demiurge
I don't remember what the reasoning was, all I remember was that the reasoning didn't make any sense at all. Like "well there's already a Debian package..."
|
|
2023-10-06 01:09:22
|
Well, it does be like that sometimes. I wonder if open Sussay's build-infon structure could build a flatpack.
|
|
2023-10-06 01:10:01
|
well that didnt coms out well, i am trying futo's new voice input for android
|
|
|
|
OkyDooky
|
2023-10-06 01:12:59
|
Just saw someone mention futo in the FlorisBoard Matrix room, a second ago.
(<@184373105588699137>)
|
|
|
|
Quackdoc
|
2023-10-06 01:14:08
|
It is pretty neat. There are definitely some issues with it, and the licensing for it is, well, quite honestly, trash. However, it does seem to be fairly accurate. It is slow, however.
|
|
|
|
OkyDooky
|
2023-10-06 04:36:11
|
Hmm. Well, Dicio uses Vosk and it looks like, in addition to a virtual assistant, it could be used as a voice input. It also seems to be accurate, but not sure if the speed is comparatively slow or not.
(<@184373105588699137>)
|
|
|
|
yoochan
|
|
_wb_
Did you point them to Thorium already?
|
|
2023-10-06 07:08:11
|
could jxl-oxide be considered more "SAFE" by integrators ?
|
|
|
|
_wb_
|
2023-10-06 09:55:46
|
no idea
|
|
2023-10-06 09:57:34
|
Rust of course has a nice reputation in that regards, but libjxl is getting quite intensively tested and is already integrated in many applications so I think it's pretty safe too
|
|
|
Tirr
|
2023-10-06 10:07:59
|
jxl-oxide is being more and more unsafe-y and would need audit to be used in production
|
|
2023-10-06 10:08:05
|
not as much as C++ but still
|
|
|
|
yoochan
|
2023-10-06 10:49:04
|
because you can only optimize with unsafe stuffs ?
|
|
|
|
Tirr
|
2023-10-06 10:49:19
|
basically yes
|
|
|
|
yoochan
|
2023-10-06 10:49:38
|
do you plan to keep a pristine branch ?
|
|
2023-10-06 10:49:58
|
slow but without sneaky bits ?
|
|
|
|
Tirr
|
2023-10-06 10:51:24
|
well it would be possible, but I'm not going to put too much effort on that
|
|
2023-10-06 10:53:39
|
simd requires unsafe, but currently there are also not-so-simd version of procedures that don't use unsafe blocks
|
|
2023-10-06 10:55:34
|
some parts are fundamentally unsafe, for example splitting mutable framebuffer into smaller ones
|
|
|
|
yoochan
|
2023-10-06 10:59:46
|
with no way to make is safe ?! I guess it concerns every parsing action
|
|
|
lonjil
|
2023-10-06 11:06:16
|
depends on what you mean by that
|
|
2023-10-06 11:09:04
|
splitting a mutable framebuffer could be abstracted, given an interface and then proven to be safe. you'd still have one of more `unsafe` blocks, but since you proved that all possible uses of the interface do not result in unsafe things happening, it'd be safe.
|
|
|
|
yoochan
|
2023-10-06 11:12:09
|
I understand, not safe in the sense of rust but safe because we checked
|
|
|
|
Tirr
|
2023-10-06 11:12:37
|
yep
|
|
2023-10-06 11:12:53
|
and splitting is relatively easy to prove safety
|
|
2023-10-06 11:13:22
|
just make sure regions don't overlap and don't go out of bounds
|
|
2023-10-06 11:13:40
|
and check lifetimes are attached correctly
|
|
|
|
lonjil
|
|
yoochan
I understand, not safe in the sense of rust but safe because we checked
|
|
2023-10-06 11:16:26
|
It's still sort of in the Rust sense since what we're really proving is that there won't be any UB, that all Rust's safety invariants are upheld.
|
|
|
|
veluca
|
2023-10-06 12:29:32
|
as far as I know, 0
|
|
2023-10-06 12:29:33
|
😛
|
|
|
|
_wb_
|
2023-10-06 01:18:45
|
Maybe they're confusing Brunsli with Lepton? I don't think anyone involved in Lepton is involved in JXL...
|
|
|
|
veluca
|
2023-10-06 01:26:01
|
> Lepton does 22% compression at 15MB/s. JXL does better than that-- maybe 30%?-- but much slower, under 1MB/s encode.
this also is not *quite* accurate
|
|
|
|
_wb_
|
2023-10-06 01:40:23
|
yeah not at all actually
|
|
2023-10-06 01:40:45
|
jxl is slightly worse than lepton in compression, and in terms of speed i'm not sure but I think they're not that different
|
|
2023-10-06 01:40:59
|
if anything, jxl is probably faster
|
|
|
|
veluca
|
2023-10-06 01:49:00
|
should be significantly faster at decoding IIRC
|
|
|
perk11
|
2023-10-06 05:27:08
|
Hey I might have made a mistake there, was just retelling something I heard on Reddit before. I'll double-check
|
|
|
|
veluca
|
|
perk11
Hey I might have made a mistake there, was just retelling something I heard on Reddit before. I'll double-check
|
|
2023-10-06 09:48:00
|
No need to double check, I can confirm nobody of us has ever worked on lepton 🤣
|
|
|
|
perk11
|
2023-10-07 03:23:15
|
Haha ok thanks 🙂
|
|
|
|
JendaLinda
|
2023-10-07 07:06:36
|
Is there any straightforward way to tell if an jxl file is progressive?
Also I'm curious, if progressive jpeg is losslessly transcoded to jxl, is that jxl automatically progressive as well?
|
|
|
spider-mario
|
2023-10-07 08:32:21
|
even non-progressive JPEGs become it
|
|
|
|
_wb_
|
2023-10-07 08:40:16
|
JXL always has DC first (well, unless you explicitly reorder it otherwise, but libjxl never does that)
|
|
2023-10-07 08:41:04
|
For AC there can be multiple passes, currently the default is to have just one AC pass
|
|
|
|
Jyrki Alakuijala
|
2023-10-08 06:53:49
|
The 8x8 first is an idea we brought over from brunsli. It gives a slight degradation on compression density, about 0.1 %, but creates system level benefits and makes it more attractive for application/viewer devs to depend on progression
|
|
|
|
lonjil
|
2023-10-08 07:04:51
|
It's nice that it's only two passes total, so it's obvious when an image is done loading, unlike many progressive JPEGs online.
|
|
|
|
_wb_
|
2023-10-08 07:26:37
|
Yes, in progressive JPEG you cannot do just 2 passes iirc - AC passes are one component at a time in JPEG, iirc...
|
|
|
|
JendaLinda
|
2023-10-08 09:39:29
|
I see.
So if I understand correctly, there is no difference if the source jpeg was progressive or not, the transcoded jxl is just one DC pass and one AC pass, right?
|
|
|
|
_wb_
|
2023-10-08 11:30:46
|
I don't think any browser is at the moment showing AC passes progressively. Not sure though.
|
|
2023-10-08 11:31:42
|
I think you should be able to test by decoding truncated files with djxl --allow_partial (or something like that)
|
|
|
|
lonjil
|
2023-10-08 11:32:26
|
Does anyone have the link to the JXL partial decode test page?
|
|
|
jonnyawsom3
|
2023-10-08 12:21:58
|
I assume you mean this
https://google.github.io/attention-center/
|
|
|
|
veluca
|
2023-10-08 02:34:27
|
It does work on Thorium and some other Chromium-derived browsers 😛
|
|
|
|
jonnyawsom3
|
2023-10-08 03:54:51
|
It's old but works fine
|
|
2023-10-08 03:55:21
|
Most test sites still tell you to use Chrome 104 or something
|
|
|
|
JendaLinda
|
2023-10-08 05:02:02
|
Alright so I took two copies of the same jpeg data, one progressive and one baseline, transcoded them losslessly to jxl without jbrd and the resulting jxl files are identical, that answers my question.
|
|
|
Jabster28
|
|
I assume you mean this
https://google.github.io/attention-center/
|
|
2023-10-08 06:02:47
|
is there any reason that the image doesn't prog dec while it loads? i know that's what it's demonstrating but even while it downloads the file, it's just blank
|
|
|
Moritz Firsching
|
2023-10-09 05:41:06
|
Yeah, I should update the text...
|
|
|
|
Jyrki Alakuijala
|
|
lonjil
It's nice that it's only two passes total, so it's obvious when an image is done loading, unlike many progressive JPEGs online.
|
|
2023-10-09 08:13:43
|
it was my original thinking too, but nowadays I think three passes: 8x8, 55 % of data, and then rest -- Moritz studied this and I looked at it in detail -- the last 45-55 % of the data is not visible in 99+ % of internet jpegs
|
|
2023-10-09 08:14:45
|
also, I was more focused on the decoding speed -- I thought that the decoding speed reduction and the additional memory use is minimal if we have only 8x8 without having to do dcts for the first progressive rendering
|
|
|
|
_wb_
|
2023-10-09 08:48:40
|
It's good to have options. For an above-the-fold hero image, probably 3 passes and saliency-based group ordering are a good idea. For a below-the-fold image, probably just the 2 passes is fine.
|
|
|
|
paperboyo
|
|
Jyrki Alakuijala
https://github.com/web-platform-tests/interop/issues/430 is interesting
|
|
2023-10-09 02:50:01
|
Great comment from Eric Chan: https://github.com/web-platform-tests/interop/issues/430#issuecomment-1753109905. I wonder if cited upcoming Adobe support for JPEG XL will include saving these new HDR Gain maps to it that Camera Raw saves now… (his is the spec: https://helpx.adobe.com/content/dam/help/en/camera-raw/using/gain-map/jcr_content/root/content/flex/items/position/position-par/table/row-3u03dx0-column-4a63daf/download_section/download-1/Gain_Map_1_0d12.pdf#page=15&zoom=250,-3,268)
I’ve just learned about them and still not sure what to think. Make more sense in old JPEG, than for HDR-ready formats… But maybe creative control over both renditions is worth it?
|
|
|
|
spider-mario
|
2023-10-09 04:12:59
|
even at the cost of having to 1. store and transmit two images, and especially 2. keeping them in sync when the image is edited?
|
|
2023-10-09 04:13:16
|
do we trust that most tools will do 2?
|
|
|
|
Jyrki Alakuijala
|
2023-10-09 05:43:20
|
Gain maps will just be a temporary thing I think. Local tone mapping will be used eventually I believe. (This opinion is not necessarily broadly shared.)
|
|
2023-10-09 05:45:56
|
I believe terrible hacks will be done with gain maps -- like a different price or return/guarantee conditions are displayed in the HDR version, user prints the SDR version and has different conditions in the agreement they sign
|
|
2023-10-09 05:46:15
|
in my opinion it is a very dangerous idea and I don't think it can be fixed
|
|
2023-10-09 05:47:32
|
forcing the gain map subresolution doesn't quite work: either it will look bad in HDR (or SDR) -- or it is not subresolution enough -- and just providing more pixels will allow the printed and on screen versions to be different
|
|
|
|
paperboyo
|
2023-10-09 05:48:54
|
Yep, pt. 2 is indeed most problematic IMHO. And potentially messy. I get that it’s all just a tiny bit less auxiliary than eg. a depth map (dropping it isn’t a disaster), but still, keeping it in sync will be a huge problem with potentially a long tail (one issue at IM’s git, nothing on vips and I’m entirely not surprised). A bigger problem than keeping a preview out of sync.
Because of pt. 1, I wouldn’t consider it serious mass web delivery “format”. Sharing from Android with friends… kinda OK.
|
|
2023-10-09 05:50:06
|
I haven’t considered legal hacks like the above. Indeed, at least a technical, possibility… 😢
|
|
|
|
Jyrki Alakuijala
|
2023-10-09 06:12:38
|
Gain map concept buys time and shifts responsibility: someone else, at some later time, figures out what should be shown in HDR vs. SDR -- it is their problem
|
|
2023-10-09 06:13:09
|
Taking the responsibility would have been to make a viewer that shows the HDR image well on an SDR display ... and no gain maps at all
|
|
2023-10-09 06:14:52
|
then standardize on possible metadata (or other control) of the parameters of the HDR->SDR (local) tone mapping function
|
|
2023-10-09 06:16:33
|
these could relate to compromises related to preserving saturation vs. intensity or to at what level to start shouldering and how smooth the shouldering should be, how many pixels wide the locality of local tone mapping should be etc.
|
|
2023-10-09 06:16:47
|
like 12 bytes of into or so
|
|
|
joppuyo
|
2023-10-10 10:42:08
|
gain maps sounds like an interesting solution for backwards compatibility in HDR images
|
|
2023-10-10 10:43:50
|
I wonder if there's anything like this for wide color. last time I checked lcms had like four different intents for converting colors between color spaces but all of them simply clipped colors if converted a P3 or adobe RGB image to sRGB
|
|
2023-10-10 10:44:23
|
I mean, clipped those colors that were out of gamut for the smaller color space
|
|
|
w
|
2023-10-10 10:48:53
|
an image being darker or brighter than it should is less offensive than it being over saturated or having the wrong colors
|
|
|
|
spider-mario
|
|
joppuyo
I mean, clipped those colors that were out of gamut for the smaller color space
|
|
2023-10-10 10:59:09
|
the perceptual intent is supposed not to do that but there are odd requirements for it to actually be used which, as far as I know, are hardly ever fulfilled in practice
|
|
2023-10-10 10:59:28
|
so it falls back to relative intent
|
|
|
Halfonso
|
2023-10-13 07:34:05
|
hi, I am trying to convert some jpg images with cjxl and I get this error
|
|
2023-10-13 07:34:52
|
Does anyone know how to fix it?
|
|
|
Cacodemon345
|
2023-10-13 07:38:53
|
Sounds like it has no fallback for this case at all.
|
|
|
|
Halfonso
|
2023-10-13 07:39:18
|
its a normal jpg
|
|
2023-10-13 07:39:27
|
i dont understand
|
|
2023-10-13 07:41:12
|
happens with many images
|
|
2023-10-13 07:41:22
|
|
|
2023-10-13 07:41:34
|
this is the image
|
|
|
|
fab
|
|
Halfonso
|
|
2023-10-13 07:41:51
|
Hahahahaha
|
|
|
|
Halfonso
|
2023-10-13 07:42:26
|
cjxl doesn't like my friend's cat haha
|
|
|
|
Cacodemon345
|
2023-10-13 07:42:40
|
Heh.
|
|
2023-10-13 07:44:08
|
<@958646019325841408> Can you send it zipped?
|
|
|
|
fab
|
2023-10-13 07:44:15
|
Jxl 12000x7000 is bad
|
|
2023-10-13 07:44:23
|
Webp also
|
|
|
|
Halfonso
|
|
Cacodemon345
<@958646019325841408> Can you send it zipped?
|
|
2023-10-13 07:44:48
|
yes but why
|
|
|
|
fab
|
2023-10-13 07:44:51
|
N I C K Nicky Nicky jam
|
|
|
|
Cacodemon345
|
2023-10-13 07:45:49
|
No errors here.
|
|
|
|
Halfonso
|
|
|
Cacodemon345
|
2023-10-13 07:46:10
|
Did you locally build JPEG XL tools?
|
|
|
|
Halfonso
|
2023-10-13 07:46:24
|
i am using 8.1 build for windows
|
|
|
|
Cacodemon345
|
2023-10-13 07:46:31
|
Then no idea.
|
|
|
|
username
|
|
Halfonso
yes but why
|
|
2023-10-13 07:46:44
|
because discord tends to mess with images in certain ways and zipping it up means discord won't get the chance to tamper with it.
|
|
|
|
Cacodemon345
|
2023-10-13 07:47:00
|
I'm using the 0.8.2 build from openSUSE.
|
|
|
|
Halfonso
|
|
username
because discord tends to mess with images in certain ways and zipping it up means discord won't get the chance to tamper with it.
|
|
2023-10-13 07:47:07
|
I thought discord didn't change
|
|
|
|
username
|
|
Halfonso
I thought discord didn't change
|
|
2023-10-13 07:48:00
|
discord messes with stuff like metadata and in the case of animated PNGs it will remove all the frames except for the first one
|
|
|
Halfonso
i am using 8.1 build for windows
|
|
2023-10-13 07:48:15
|
maybe try a build from here? https://artifacts.lucaversari.it/libjxl/libjxl/latest/
|
|
|
|
Halfonso
|
2023-10-13 07:50:03
|
with 8.2 i get this ??????
|
|
|
username
maybe try a build from here? https://artifacts.lucaversari.it/libjxl/libjxl/latest/
|
|
2023-10-13 07:51:57
|
It takes up much more space, does it have more libraries or something?
|
|
|
|
jonnyawsom3
|
2023-10-13 07:52:37
|
If you mean the download, it has a lot of other tools included too
|
|
|
|
Halfonso
|
|
|
username
|
2023-10-13 07:53:37
|
1 out of 64 is a false positive
|
|
|
|
Halfonso
|
2023-10-13 07:53:48
|
maybe false positive?
|
|
2023-10-13 07:54:08
|
okay
|
|
|
|
username
|
|
|
Halfonso
|
2023-10-13 07:59:06
|
i dont understand my pc is trolling me
|
|
|
username
maybe try a build from here? https://artifacts.lucaversari.it/libjxl/libjxl/latest/
|
|
2023-10-13 07:59:29
|
with this
|
|
|
|
username
|
|
Halfonso
i dont understand my pc is trolling me
|
|
2023-10-13 08:00:33
|
try `cjxl IMG_20220304_205810.jpg test.jxl` ?
|
|
|
|
Halfonso
|
2023-10-13 08:01:56
|
wtf the name
|
|
2023-10-13 08:02:02
|
|
|
2023-10-13 08:02:22
|
why cmd autocompletes with other name when i press tab
|
|
2023-10-13 08:02:30
|
|
|
2023-10-13 08:06:09
|
was the name
|
|
2023-10-13 08:07:42
|
Maybe I took the wrong photo when autocomplete and deleted it later, I have been deleting some, and by repeating the command I messed it up
|
|
2023-10-13 08:08:13
|
I guess that's why I didn't get it, but still in 8.1 it didn't work initially for me
|
|
2023-10-13 08:08:31
|
with new version works fine thx
|
|
2023-10-13 08:19:59
|
I want to free up space, what -d 1, 2, 3... or -q 90, 80 do you recommend?
|
|
|
|
jonnyawsom3
|
2023-10-13 08:29:49
|
Best to try them and see what you like best, can also try different `-e` levels since they can end up smaller but worse quality too
|
|
|
|
OkyDooky
|
2023-10-13 11:49:17
|
<@245794734788837387> I got a reply from Alex of Thorium\:
|
|
2023-10-13 11:49:30
|
Screenshot\_2023-10-13\_16-47-42.png
|
|
2023-10-13 11:51:05
|
And, reminder to anyone else reading here, this is what Uazo (Cromite dev) is waiting on, mostly\:
|
|
2023-10-13 11:51:19
|
Screenshot\_2023-10-13\_16-50-12.png
|
|
2023-10-13 11:52:24
|
I think this would be a huge hurdle to cross, not necessarily in terms of labor, but in terms of resutls. If Cromite can accept a patch, then so can any other Chromium browser, whether security-focused or not, and both desktop and mobile, as well.
|
|
|
|
monad
|
|
Halfonso
I want to free up space, what -d 1, 2, 3... or -q 90, 80 do you recommend?
|
|
2023-10-14 05:03:00
|
If you don't have specific requirements, the defaults are safe enough.
|
|
2023-10-14 05:05:04
|
Don't use `-e` to regulate the size/quality tradeoff, it's only designed to regulate computation/accuracy.
|
|
|
|
fab
|
2023-10-14 11:53:50
|
Use e 8 q 87.133
|
|
|
|
yoochan
|
2023-10-14 12:48:30
|
87.133 ? it seems very very precise 😄 what is the rationnale behind this value ?
|
|
|
|
_wb_
|
2023-10-14 12:51:46
|
This is a <@416586441058025472> thing. He always uses very idiosyncratic encode settings.
|
|
|
MSLP
|
2023-10-14 01:01:43
|
out of curiosity - what distance metric does quality 87.133 correspond to?
|
|
|
|
yoochan
|
2023-10-14 01:23:01
|
here was the formula (if it didn't change) https://discord.com/channels/794206087879852103/803645746661425173/1145045525272469575
|
|
2023-10-14 01:24:08
|
q=87.133 is roughly equal to d=1.258
|
|
|
|
MSLP
|
2023-10-14 01:31:22
|
thanks
|
|
|
|
Demiurge
|
|
username
discord messes with stuff like metadata and in the case of animated PNGs it will remove all the frames except for the first one
|
|
2023-10-16 11:42:14
|
Wtf, discord snips animated png?
|
|
|
|
Traneptora
|
|
Demiurge
Wtf, discord snips animated png?
|
|
2023-10-17 02:40:23
|
it used to, a the very least
|
|
2023-10-17 02:42:07
|
|
|
2023-10-17 02:42:14
|
yea, it does
|
|
|
|
jonnyawsom3
|
2023-10-17 03:06:22
|
Odd, I know they wouldn't display in-app but would work in a browser, guess they wanted to cut down on it
|
|
|
190n
|
2023-10-17 06:09:17
|
they use apng for stickers, just not embeds for some reason
|
|
|
|
Cacodemon345
|
2023-10-17 06:11:25
|
I guess they want to make those Nitro-only as well.
|
|
|
|
190n
|
2023-10-17 06:19:25
|
i mean, you can still upload gif attachments instead of using apng stickers
|
|
2023-10-17 06:19:35
|
which will waste more storage, and also has a much higher file size limit
|
|
|
|
jonnyawsom3
|
2023-10-17 06:42:44
|
They support webp and it animates in the upload preview, but gets sent as an attachment instead of embedding
|
|
|
|
lonjil
|
2023-10-17 08:03:34
|
last time I tried sending a webp on discord it worked fine
|
|
|
|
Cacodemon345
|
2023-10-17 08:38:16
|
Only single-image ones work.
|
|
|
|
OkyDooky
|
2023-10-20 07:33:16
|
how do i convert a directory of images with libjxl?
|
|
|
|
190n
|
2023-10-20 07:34:22
|
there isn't a way built into the library (libjxl) or the tools (cjxl to djxl) to do that
|
|
2023-10-20 07:34:36
|
you could write a script which calls cjxl on every file in a directory
|
|
|
|
OkyDooky
|
2023-10-20 07:35:30
|
alright
|
|
|
|
HCrikki
|
2023-10-20 08:12:55
|
https://github.com/kampidh/jxl-batch-converter/ handles folders. give it the location of an uncompressed jxl nightly
|
|
2023-10-20 08:15:15
|
also does lossless conversions from jpg originals with no visual loss
|
|
|
|
runr855
|
|
HCrikki
https://github.com/kampidh/jxl-batch-converter/ handles folders. give it the location of an uncompressed jxl nightly
|
|
2023-10-20 08:37:39
|
This program does not work reliably. If you have a dot (.) in your filename, it stops reading the file name after that when creating the JXL files. It then either overwrites pictures, or won't convert them as it thinks they already exists.
|
|
2023-10-20 08:37:48
|
Tested on Windows
|
|
2023-10-20 08:38:48
|
Te.st1.jpg, Te.st2.jpg, Te.st3.jpg. It will only convert one of the files
|
|
2023-10-20 08:38:58
|
And name it Te.jxl
|
|
|
|
HCrikki
|
2023-10-20 08:41:28
|
good to know then
|
|
2023-10-20 08:41:56
|
theres xl-converter ( https://github.com/JacobDev1/xl-converter ) and another on reddit. thoughts on both ?
|
|
|
|
runr855
|
2023-10-20 09:59:03
|
I like both for different reasons
|
|
|
runr855
This program does not work reliably. If you have a dot (.) in your filename, it stops reading the file name after that when creating the JXL files. It then either overwrites pictures, or won't convert them as it thinks they already exists.
|
|
2023-10-20 10:00:09
|
Hopefully <@274048677851430913> still works on jxl-batch-converter and can fix the bug. It's a great GUI for libjxl
|
|
|
|
Demiurge
|
2023-10-20 11:06:20
|
Filenames on Windows are a joke
|
|
|
Kampidh
|
|
runr855
Hopefully <@274048677851430913> still works on jxl-batch-converter and can fix the bug. It's a great GUI for libjxl
|
|
2023-10-21 03:37:22
|
fixed it~ thanks for the test!
https://github.com/kampidh/jxl-batch-converter/releases/tag/v0.2.4
|
|
|
|
diskorduser
|
|
how do i convert a directory of images with libjxl?
|
|
2023-10-21 04:17:55
|
Magick mogrify
|
|
|
|
runr855
|
|
Kampidh
fixed it~ thanks for the test!
https://github.com/kampidh/jxl-batch-converter/releases/tag/v0.2.4
|
|
2023-10-21 12:00:23
|
Works great! I really like how your GUI exposes a ton of settings and shows the terminal output
|
|
|
Oleksii Matiash
|
|
Kampidh
fixed it~ thanks for the test!
https://github.com/kampidh/jxl-batch-converter/releases/tag/v0.2.4
|
|
2023-10-23 02:58:00
|
May I dm you?
|
|
|
|
Kampidh
|
|
Oleksii Matiash
May I dm you?
|
|
2023-10-23 03:07:14
|
sure
|
|
|
|
Jyrki Alakuijala
|
2023-10-24 09:14:01
|
I promised a Rust implementation for libjxl if JPEG XL makes to interop 2024: https://github.com/web-platform-tests/interop/issues/430#issuecomment-1776762287
|
|
|
|
Quackdoc
|
2023-10-24 10:29:29
|
would this be part of/based on jxl-oxide or something seperate altogether?
|
|
|
|
veluca
|
2023-10-24 10:34:50
|
too early to say, I think
|
|
|
|
Jyrki Alakuijala
|
2023-10-24 10:51:53
|
benefits from basing it on jxl-oxide: good start, easier for community to contribute
benefits from doing it from scratch: team will be more likely to understand the whole and all the challenges, team will possibly learn more, we'd be able to design for parallelism based on our previous challenges in the C++ implementation (the implications of data dependencies are hairy for gaborish and epf)
eventually, if it comes to supporting Rust we'd love to get input from jxl-oxide authors for making the right decisions in getting things started
|
|
2023-10-24 10:54:14
|
I'd think that we would only build the decoder in Rust, just like jxl-oxide
|
|
2023-10-24 10:54:30
|
I haven't looked how complete jxl-oxide is and how they deal with simd and parallelism
|
|
2023-10-24 10:55:58
|
I saw very strong engineers to struggle to meet with JPEG XL's decoding parallelisation needs -- I find it unlikely that a small number of volunteers would be able to solve it quickly, elegantly and efficiently (but I haven't reviewed if there is parallelism in jxl-oxide and how it is used)
|
|
|
|
veluca
|
|
Jyrki Alakuijala
I haven't looked how complete jxl-oxide is and how they deal with simd and parallelism
|
|
2023-10-24 02:15:35
|
afaiu it's a work in progress, and also afaiu it's not nearly as fancy as the rendering pipeline in terms of buffer (re-)use
|
|
|
|
Quackdoc
|
2023-10-24 03:02:15
|
I haven't seen any thing in any of the trackers for android, but considering android uses skia for image decoding, and skia is still using the gitlab.com/wg1/jpeg-xl git repo, I doubt there has been any progress
|
|
|
|
Cacodemon345
|
2023-10-24 03:02:45
|
It's frankly pointless to ask that question since even WebP support is a mess.
|
|
2023-10-24 03:03:06
|
Smartphones are yet to shoot in AVIF as far as I know.
|
|
|
|
Quackdoc
|
2023-10-24 03:03:35
|
I mean, tbf, the webp ecosystem itself is kinda a mess lol
|
|
|
|
lonjil
|
2023-10-24 03:04:08
|
smartphones shoot in HEIC these days
|
|
|
|
Quackdoc
|
2023-10-24 03:06:32
|
it depends on the device
|
|
2023-10-24 03:06:49
|
its still mostly just capturing in JPEG and transcoding it lol
|
|
|
|
jonnyawsom3
|
2023-10-24 03:09:29
|
My phone got a firmware update that actually removed format control... Now my only option is jpeg, or 20MP jpeg and RAW in the Pro mode
|
|
|
|
Cacodemon345
|
2023-10-24 03:10:05
|
Assholes at work of course.
|
|
|
|
Quackdoc
|
|
My phone got a firmware update that actually removed format control... Now my only option is jpeg, or 20MP jpeg and RAW in the Pro mode
|
|
2023-10-24 03:12:30
|
yeah, I still use opencamera which can transcode to png or webp itself, I wish it could do image processing itself using the raw image, but meh, cant win all fights
|
|
|
|
BlueSwordM
|
|
Quackdoc
its still mostly just capturing in JPEG and transcoding it lol
|
|
2023-10-24 07:55:00
|
No.
|
|
2023-10-24 07:55:37
|
Competent phones these days are using JPEG XL or at the minimum JPEF Ultra.
|
|
|
|
Quackdoc
|
2023-10-24 08:00:43
|
I wish T.T maybe ill try and add jxl to bliss :D but I dont think any android camera apps are around that still do in app processing of the raw photo
|
|
|
|
fab
|
2023-10-24 08:04:31
|
How display JPEG XL in a gallery
|
|
2023-10-24 08:04:39
|
Xiaomi mi 11 lite 5g
|
|
2023-10-24 08:04:51
|
Every extension even jpg.jxl
|
|
2023-10-24 08:05:04
|
Or png.jxl
|
|
2023-10-24 08:05:40
|
Jpeg was removed to make space for jxl re encode
|
|
2023-10-24 08:17:13
|
|
|
2023-10-24 08:17:52
|
JPEG XL is great however i don't have an XYB monitor
|
|
2023-10-24 08:18:53
|
Only palemoon displays it
|
|
2023-10-24 08:19:07
|
Is not bad
|
|
2023-10-24 08:19:22
|
You need a good display
|
|
2023-10-24 08:19:52
|
This image is same size as original
|
|
2023-10-24 08:20:36
|
I used e9 d 2.587
|
|
|
|
HCrikki
|
2023-10-24 09:09:35
|
given lossless reversible encoding from jpeg sources, i expect this to not limited to web serving of images but also offline gallery applications to decode such jxls as jpegs since its supposed to be almost instant. something im missing, like this reversal expecting a server signal?
|
|
|
|
Jyrki Alakuijala
|
2023-10-24 10:09:12
|
Android phones are rather fragmented on what comes to images -- camera is one entity there, chrome another, google photos yet another, then many apps -- facebook, instagram, whatsapp, games etc. often come with their own codecs in the APK
Platform level is probably the last to come and most political -- there is however a way to back-port it relatively easily into old versions through compatibility layers (androidx)
|
|
2023-10-24 10:10:20
|
I don't know any major advances in these areas for JPEG XL, but I feel it is likely to happen, perhaps starting from camera, games and educational software
|
|
|
|
w
|
2023-10-24 10:48:59
|
yeah what kind of phone does jxl
|
|
|
|
Quackdoc
|
2023-10-24 11:29:54
|
linux phones :D
|
|
|
|
w
|
2023-10-24 11:50:47
|
what kind of good phone does jxl
|
|
|
|
HCrikki
|
2023-10-25 01:19:05
|
cant confirm but sailfishos and a derivative or 2 seem to have some support passively obtained from updated imaging libraries (imagemagick?)
|
|
|
|
jonnyawsom3
|
|
Quackdoc
yeah, I still use opencamera which can transcode to png or webp itself, I wish it could do image processing itself using the raw image, but meh, cant win all fights
|
|
2023-10-25 01:41:20
|
Hmm, wasn't there a camera app that output JXL?
|
|
|
|
OkyDooky
|
2023-10-25 04:39:17
|
Just put a distro on a SD845 based phone.
(<@288069412857315328>)
|
|
|
|
w
|
|
|
Quackdoc
|
2023-10-26 01:02:41
|
isnt harmonyOS just their android skin?
|
|
|
damian101
|
2023-10-26 01:06:20
|
yeah
|
|
2023-10-26 01:07:17
|
Everything that runs on Android can run on HarmonyOS. They just can't advertise or preistall apps from American companies.
|
|
|
|
OkyDooky
|
2023-10-26 01:15:22
|
Not without modifications.
(<@401816384109150209>)
|
|
2023-10-26 01:15:35
|
That may have been in the early phase.
|
|
2023-10-26 01:16:06
|
And they recently announced a less Android-dependent version
|
|
|
|
damian101
|
2023-10-26 01:16:41
|
have they hard-locked the developer settings or what?
|
|
|
|
OkyDooky
|
2023-10-26 01:16:53
|
They have their own APIs iirc
|
|
|
|
damian101
|
2023-10-26 01:16:59
|
really...
|
|
2023-10-26 01:17:09
|
no mor simple Android clone?
|
|
|
|
OkyDooky
|
2023-10-26 01:17:17
|
DB, national railway provider in Germany, has their own harmonyOS app for example
|
|
2023-10-26 01:19:18
|
(And not cause they want support every platform. They don't have a app for Linux phones/desktops)
|
|
|
|
w
|
2023-10-26 01:21:14
|
simple android clone died when the nexus 6p came out
|
|
|
|
OkyDooky
|
2023-10-26 01:25:13
|
https://www.gizchina.com/2023/09/29/harmonyos-next-huawei-is-ready-to-release-native-harmonyos-app-ecosystem/
|
|
2023-10-26 01:30:09
|
Okay, maybe until now and the main blocker for users might have been just the missing Google Play Store(?).
Can't say it for sure atm cause I kinda read a bit of conflicting information on this earlier.
Howerver, wikipedia says\:
»In the kernel layer, the system applies a multikernel design and selects an appropriate kernel for a device with different resource limitations. For wearables, screenless I/O devices and IoT devices, the system is based on real-time operating system LiteOS; while for smartphones and tablets, the system operates by utilizing a Linux kernel subsystem and executing the AOSP code with a modified EMUI user interface, enabling Android apps and HarmonyOS apps to run seamlessly through a compatibility layer in the userland outside the kernel.[9][10]«
https://en.wikipedia.org/wiki/HarmonyOSAnd the plan is to make it independent from Android.
|
|
|
|
Quackdoc
|
|
Okay, maybe until now and the main blocker for users might have been just the missing Google Play Store(?).
Can't say it for sure atm cause I kinda read a bit of conflicting information on this earlier.
Howerver, wikipedia says\:
»In the kernel layer, the system applies a multikernel design and selects an appropriate kernel for a device with different resource limitations. For wearables, screenless I/O devices and IoT devices, the system is based on real-time operating system LiteOS; while for smartphones and tablets, the system operates by utilizing a Linux kernel subsystem and executing the AOSP code with a modified EMUI user interface, enabling Android apps and HarmonyOS apps to run seamlessly through a compatibility layer in the userland outside the kernel.[9][10]«
https://en.wikipedia.org/wiki/HarmonyOSAnd the plan is to make it independent from Android.
|
|
2023-10-26 01:37:18
|
ngl this sounds like a bunch of mumbojumbo for "we have two operating systems, one for low end hardware and one for higher end hardware, and we can ship both in a single package"
|
|
2023-10-26 01:38:00
|
they likely run Android natively, then run their "Linux subsystem" in a container, I doubt its the other way around (for instance waydroid) since that would make a lot of sacrifices
|
|
|
|
OkyDooky
|
2023-10-26 01:43:20
|
Well, we will see how next year goes
|
|
2023-10-26 01:46:06
|
With enough dominance they can pull in users to a future platform that could be highly incompatible with Android.
|
|
2023-10-26 01:46:16
|
They reported 700M devices running their thing. How much of those are smartphone idk.
|
|
2023-10-26 01:47:01
|
They reported that 700M devices are running their thing. How many of those are smartphone idk.
|
|
2023-10-26 01:47:31
|
(update your bridge, jxl folks)
|
|
2023-10-26 01:50:31
|
We should try to get HarmonyOS apps running on GNU/Linux 🤔
|
|
|
|
Cacodemon345
|
2023-10-26 04:36:14
|
First get the Chinese companies to get their shit to run on Deepin, then we'll talk.
|
|
|
|
OkyDooky
|
2023-10-26 05:31:47
|
OpenKylin\:
|
|
|
|
fab
|
2023-10-26 11:56:32
|
Pashi can you explain this
|
|
2023-10-26 11:56:35
|
|
|
|
|
Demiurge
|
2023-10-26 06:46:46
|
lol wat? Looks like some chinglish Android system font
|
|
|
|
OkyDooky
|
2023-10-26 07:10:40
|
The madlad actually did it. Uazo added JXL support to Cromite\: https://github.com/uazo/cromite/commit/c27f2e5f1dd1f7e00fb4872ea29422eef2438a7a
|
|
2023-10-26 07:10:43
|
If someone could add it to the list of supported software on the libjxl repo, that would be really cool.
|
|
|
|
MSLP
|
2023-10-26 07:52:38
|
cool, cromite even has a f-droid repo for android
|
|
|
|
Posi832
|
2023-10-27 02:32:41
|
About time I move away from Bromite : )
|
|
|
|
w
|
2023-10-27 03:07:26
|
i refuse to use any browser named after elements
|
|
|
|
MSLP
|
2023-10-27 03:11:56
|
are chemical compounds and minerals out of question too?
|
|
|
|
w
|
|
|
MSLP
|
2023-10-27 03:13:19
|
damn, that severly limits options for jxl-capable browsers on android
|
|
|
|
w
|
2023-10-27 03:14:07
|
it's just firefox
|
|
2023-10-27 03:14:13
|
because everybody else is so original
|
|
|
|
Demiurge
|
2023-10-27 03:44:12
|
I want to download a camera app that saves to jxl
|
|
2023-10-27 03:45:58
|
d=1
|
|
|
|
spider-mario
|
2023-10-27 07:19:15
|
what about browser names that conflate the web and the internet?
|
|
|
|
w
|
2023-10-28 01:24:57
|
samsung internet browser
|
|
|
|
OkyDooky
|
2023-10-28 05:23:36
|
Since Cromite, a privacy-focused Chromium browser that highly values security, accepted the JXL patch, there's virtually nothing stopping the rest of the forks from doing the same\:
Mulch (might get it from Cromite)
Vivaldi
Brave
(Anyone else?) I *could* advocate in their spaces like I did with Cromite, but I hope others can feel encouraged enough to do so themselves.
(<@608345430656417867>)
|
|
|
gb82
|
2023-10-28 05:25:13
|
I'd definitely like to join those discussions & support your advocacy as well. I say go for it
|
|
|
|
username
|
|
Since Cromite, a privacy-focused Chromium browser that highly values security, accepted the JXL patch, there's virtually nothing stopping the rest of the forks from doing the same\:
Mulch (might get it from Cromite)
Vivaldi
Brave
(Anyone else?) I *could* advocate in their spaces like I did with Cromite, but I hope others can feel encouraged enough to do so themselves.
(<@608345430656417867>)
|
|
2023-10-28 05:36:30
|
https://github.com/brave/brave-browser/issues/28411
https://forum.vivaldi.net/topic/85153/adding-support-for-jpeg-xl-jxl-images
|
|
2023-10-28 05:37:55
|
getting Brave to support JXL seems quite possible since it seems like they already have some sort of interest however Vivaldi might be a bit tougher since it seems like they aren't even aware of JXL and also development isn't as open as Brave
|
|
|
|
HCrikki
|
|
Since Cromite, a privacy-focused Chromium browser that highly values security, accepted the JXL patch, there's virtually nothing stopping the rest of the forks from doing the same\:
Mulch (might get it from Cromite)
Vivaldi
Brave
(Anyone else?) I *could* advocate in their spaces like I did with Cromite, but I hope others can feel encouraged enough to do so themselves.
(<@608345430656417867>)
|
|
2023-10-28 07:10:18
|
opera ?
|
|
2023-10-28 07:11:20
|
could work really well with their web compression proxy (turbo/vpn) and opera lite/mini, granting even higher compression delivered with lower latency and generating savings in bandwidth. web traffic compression would be big for them and partnered websites
|
|
2023-10-28 07:14:34
|
opera owns Yoyo (makers of game engine 'Gamemaker studio') btw so that could be worth looking into too since applications and games liberally ship all their own necessary libraries and dont need waiting for a market's adoption
|
|
|
|
MSLP
|
|
Since Cromite, a privacy-focused Chromium browser that highly values security, accepted the JXL patch, there's virtually nothing stopping the rest of the forks from doing the same\:
Mulch (might get it from Cromite)
Vivaldi
Brave
(Anyone else?) I *could* advocate in their spaces like I did with Cromite, but I hope others can feel encouraged enough to do so themselves.
(<@608345430656417867>)
|
|
2023-10-28 10:14:09
|
Looking at the landscape of chromium-based browsers, Mulch may not be a good bet, since they have "Included patches must be very simple to minimize maintenance" written in their "Goals" section.
*Chromite* dev uazo seems to respect older *Bromite* approach, which included av1 support before it was mainstream, which may have helped jxl adoption.
Alex313031's *Thorium* seems feature-wise like somwhat bleeding edge/experimental project, and was heavy on supporting multiple codecs, so in terms of the decision on jxl support was easier.
|
|
|
|
BlueSwordM
|
|
gb82
I'd definitely like to join those discussions & support your advocacy as well. I say go for it
|
|
2023-10-28 03:59:51
|
Yes please.
|
|
2023-10-28 04:00:02
|
I want Kiwi Browser to get JXL support.
|
|
|
|
fab
|
2023-10-28 05:31:52
|
I only use Firefox nightly
|
|
2023-10-28 05:32:03
|
And copy bookmarks to TXT
|
|
2023-10-28 05:32:36
|
Because now you can set folders but i have too much and you can't Hide that
|
|
|
|
OkyDooky
|
2023-10-31 05:06:44
|
Is it Chromium-based?
(<@321486891079696385>)
|
|
2023-10-31 05:09:20
|
Yeah, I initially thought Mulch would be good until I saw that line...then I thought it would be potentially easy again, since that oage also mentions pulling patches from Cromite. He might be able to include that one, as well, but I don't know for sure.
(<@608345430656417867>)
|
|
2023-10-31 05:14:13
|
Idk. Opera used to be heavy in the MacOS world. So, maybe they might get some momentum from Apple's wide adoption of the format that seems to be happening.
(<@174118775753408512>)
|
|
2023-10-31 05:18:17
|
And it looks like someone already started work on merging a patch for Brave. Mentioning Cromite's work might give this a nudge, especially since he modified Alex's patch and gave a recommendation back to him. And I see what you mean with Vivaldi. It's a user forum and it doesn't look like that thread has had any interaction from devs (that I could tell). I'm not sure it would matter *that* much, since Brave has a much larger userbase and general sway. So, maybe if they make a big deal about including support, it'll give a push to Vivaldi and others as well.
(<@245794734788837387>)
|
|
|
|
MSLP
|
|
Is it Chromium-based?
(<@321486891079696385>)
|
|
2023-10-31 07:26:44
|
yep, Kiwi is chromium based. One of its outstanding features is extensions support on android.
|
|
|
|
BlueSwordM
|
|
Is it Chromium-based?
(<@321486891079696385>)
|
|
2023-10-31 09:17:38
|
Yes.
|
|
|
|
OkyDooky
|
2023-10-31 10:45:09
|
Then there's hope. 😅
Extension support sounds kewl. I use SmartCookieWeb-Preview (based on GeckoView) because it supports extensions outside of the Mozilla list on mobile. I can sideload stuff like LibRedirect and such.
|
|
2023-10-31 10:48:51
|
Navigating through Kiwi's GitHub repos was a pain, but the currently active one (srs.next) has no issues made re\: JXL. So, that's promising that they haven't at least shut down any attempts to recommend inclusion.
|
|
2023-11-01 01:46:21
|
Agreed. It's just more momentum than other projects get. And they've already been made aware of the details of the Thorium patch, so it might be easy to give them a push to just make it happen.
(<@456226577798135808>)
|
|
2023-11-04 01:14:21
|
OkyDooky\: https://github.com/uazo/cromite/blob/master/build/patches/00Add-support-to-jxl.patch#L160C1-L169C14Should it be Decode instead of Upload?
|
|
2023-11-04 01:30:53
|
I honestly don't know. \:/ Is it just an issue of being a typo or a functionality issue?
|
|
|
|
username
|
2023-11-04 01:59:04
|
seems like a typo, I doubt it really breaks much or maybe even anything, Maybe if someone where trying to measure something with the chromium dev tools then some data point might get messed up?
|
|
2023-11-04 02:00:47
|
the typo doesn't originate from the cromite patch so ill try to report it to the <#848189884614705192> channel in here since the issue comes from the original implementation for chromium
|
|
|
|
Halfonso
|
2023-11-04 08:34:36
|
Hi, I am trying to transition my album to jxl, but I don't like some viewers that I have tested that work with jxl, which one do you recommend that is compatible and the functionality is similar to the Windows photos app (that can see photos and videos)
|
|
|
|
fab
|
2023-11-04 08:57:09
|
Only midori and xnview
|
|
2023-11-04 08:57:27
|
The others still old decoder
|
|
|
Nova Aurora
|
|
Halfonso
Hi, I am trying to transition my album to jxl, but I don't like some viewers that I have tested that work with jxl, which one do you recommend that is compatible and the functionality is similar to the Windows photos app (that can see photos and videos)
|
|
2023-11-05 06:28:43
|
I'm assuming windows, but what OS are you on?
|
|
|
|
Quackdoc
|
2023-11-05 06:52:44
|
huh, ffmpeg is decoding my jxl mkvs again, but it's spamming a bunch of issues and it's slow as molasses because of the issues, and it doesn't keep the right timestamps now. mpv either plays it at super speed or just drops the frames
|
|
|
|
Traneptora
|
|
Quackdoc
huh, ffmpeg is decoding my jxl mkvs again, but it's spamming a bunch of issues and it's slow as molasses because of the issues, and it doesn't keep the right timestamps now. mpv either plays it at super speed or just drops the frames
|
|
2023-11-05 01:59:09
|
what issues?
|
|
|
|
Quackdoc
|
2023-11-05 02:41:25
|
Not on linux atm so I can't grab the exact issue, however when I encode jxl into an mkv `ffmpeg -i video-test.mkv -c:v libjxl -effort 3 -distance 2 out-jxl.mkv` it for some reason messes up the transfer giving something like a gamma 0.0500 or something like that. even when I use -c copy to extract the image sequence.
I plan on encoding an image sequence with cjxl then muxing that afterwards later tonight
|
|
|
|
Halfonso
|
|
Nova Aurora
I'm assuming windows, but what OS are you on?
|
|
2023-11-05 05:22:58
|
windows
|
|
|
|
Nova Aurora
|
2023-11-05 05:41:54
|
There are 2 windows support plugins around, alternatively look at https://github.com/libjxl/libjxl/blob/main/doc/software_support.md#image-viewers
|
|
|
|
Halfonso
|
2023-11-05 06:50:09
|
I tried them but they have incompatibility with the Windows Photos app https://github.com/saschanaz/jxl-winthumb/issues/21
|
|
|
|
fab
|
2023-11-05 07:26:37
|
<@853026420792360980> if I send ssimulacra c file can you compile it for me i want to use for cjxl
|
|
2023-11-05 07:26:50
|
I will send to your inbox
|
|
|
|
Traneptora
|
|
fab
<@853026420792360980> if I send ssimulacra c file can you compile it for me i want to use for cjxl
|
|
2023-11-05 10:17:58
|
no, compile it yourself
|
|
|
|
Quackdoc
|
2023-11-06 02:46:45
|
ok, a bit more investigating done regarding jxl muxed into video containers, it seems like the fps gets seriously mangled. mpv will somewhat manage to play it if you use mkvmerge to mux in proper timestamps, but it still plays way to fast, and mpv will still drop some frames. ffplay seems like it is only playing a single frame but when you play it on loop you see it just plays it really fast and gets to the end
|
|
|
|
damian101
|
2023-11-06 07:04:09
|
Hmm, it seemed to work fine when I last tried it...
|
|
|
|
Quackdoc
|
|
Hmm, it seemed to work fine when I last tried it...
|
|
2023-11-06 07:43:51
|
feel free to try it on ffmpeg-git, patch should still apply cleanly
|
|
|
|
damian101
|
|
Quackdoc
feel free to try it on ffmpeg-git, patch should still apply cleanly
|
|
2023-11-06 08:27:49
|
wait, I don't think I needed a patch back then...
|
|
2023-11-06 08:27:57
|
but I might be wrong...
|
|
|
|
Quackdoc
|
2023-11-06 09:35:54
|
you should have needed one, its the one that adds JXL riff tage
|
|
|
|
damian101
|
2023-11-06 03:58:39
|
oh, maybe I didn't try JXL MKV afterall, and it was just PNG MKV...
|
|
2023-11-06 03:58:59
|
yes, that was probably the case
|
|
|
|
Quackdoc
|
2023-11-06 04:39:36
|
probably, png will work fine since it has had riff tags for ages
|
|
|
|
jonnyawsom3
|
2023-11-06 04:39:56
|
Hmmm, oxipng MKV....
|
|
|
|
Quackdoc
|
|
Hmmm, oxipng MKV....
|
|
2023-11-06 04:50:10
|
any of the formats listed here should work https://github.com/FFmpeg/FFmpeg/blob/44a0148fadc97798acf6c93016a14e7c956f0825/libavformat/riff.c#L36
|
|
|
|
Demiurge
|
2023-11-07 04:32:22
|
Idk much about modular mode and wavelet compression but, DCT by itself does not seem very efficient to rely on alone.
|
|
2023-11-07 04:33:34
|
Combining the strengths of DCT, and making up for its weaknesses with other techniques, would make the most sense.
|
|
2023-11-07 04:34:00
|
Within the same image.
|
|
2023-11-07 04:36:26
|
DCT could be used to efficiently enhance texture, while other techniques like color quantization and dithering could be used to counteract and mask some of the telltale ugliness of DCT
|
|
2023-11-07 04:38:05
|
DCT tends to look blurry and blocky unless it's done really well. Like unless it is Jyrki level quality
|
|
2023-11-07 04:38:43
|
But using some grainy quantization techniques can help mask those blurry and blocky areas
|
|
2023-11-07 04:39:25
|
Like even simply adding photon noise can mask it
|
|
2023-11-07 05:15:18
|
Basically certain lossy and lossless compression techniques are really good at compressing simple, predictable data. But DCT is really bad at that but really good at what those other techniques are bad at. So why not have a jpegxl encoder that takes an image, turns it into a really simplified version that is compressed really well with the other techniques, and then subtract that image from the original image, and encode that residual with DCT to add extra texture?
|
|
2023-11-07 05:15:27
|
Basically a shape layer and a texture layer.
|
|
2023-11-07 05:17:15
|
That way you use the best tools for each job and maybe get significant quality/bitrate improvements
|
|
2023-11-07 05:19:46
|
Same idea behind splines. Subtract from the image any features that are hard for DCT but easy with other techniques
|
|
|
|
fab
|
2023-11-07 07:12:35
|
Because isn't in that way that it works
|
|
|
|
yoochan
|
|
Demiurge
Basically certain lossy and lossless compression techniques are really good at compressing simple, predictable data. But DCT is really bad at that but really good at what those other techniques are bad at. So why not have a jpegxl encoder that takes an image, turns it into a really simplified version that is compressed really well with the other techniques, and then subtract that image from the original image, and encode that residual with DCT to add extra texture?
|
|
2023-11-07 09:16:58
|
that sounds nice ! did you tried to make a mockup to validate it ?
|
|
2023-11-07 10:01:25
|
in fact DCT at it's core already contains what you are trying to do, the first coefficient being the average value of the n×n block, etc.
|
|
|
|
spider-mario
|
2023-11-07 10:10:11
|
I actually tried something like that a while ago, with the “base” image being a palettised version of the input
|
|
2023-11-07 10:10:24
|
tried it on an Astérix panel
|
|
2023-11-07 10:10:26
|
didn’t work so well
|
|
2023-11-07 10:10:51
|
subtracting a palettised version removed some of the original sharp edges but introduced new ones
|
|
|
|
Demiurge
|
2023-11-07 10:49:50
|
The hard part would be figuring out an algorithm to extract simple shapes from the image to subtract
|
|
|
|
_wb_
|
2023-11-07 11:18:35
|
subtracting something will only be effective if the residual actually has lower entropy, like what we do in the current patch detection where the residual is very close to just a solid color background. Generalizing that to other cases than "something on a solid background" is tricky. The separation between the modular or spline encoded part and the DCT encoded part has to be really clean, because as long as one bleeds into the other, you'll end up with _both_ still having most of the entropy and it becomes a compression regression instead of a gain.
|
|
|
|
veluca
|
2023-11-07 12:57:31
|
arguably entropy is not the only (or even most) important part - you want to maximize how easily each residual block is representable with dct coefficients
|
|
|
|
_wb_
|
2023-11-07 01:49:02
|
yeah I meant entropy in the sense of bitstream size after entropy coding (and after converting to whatever representation, whether it's modular prediction residuals, dct coeffs or spline data)
|
|
|
|
Demiurge
|
2023-11-07 09:03:12
|
But, you can lower the entropy using quantization and noise shaping.
|
|
2023-11-07 09:08:59
|
Just like you say, the goal is for each layer to have extremely low entropy. And to be compressed with the algorithm that suits it best. DCT for texture, modular for smooth and sharp shapes.
|
|
2023-11-07 09:10:34
|
The trouble will be writing a kernel that can break down an image into 2 lower entropy images, one suited for DCT and one suitable for modular.
|
|
2023-11-07 09:11:26
|
I think there is a lot of potential, maybe, in that line of thinking.
|
|
2023-11-07 09:14:29
|
I wonder if anyone has ever written an image processing kernel like that.
|
|
2023-11-08 09:30:20
|
You would want one image with no sharp, fine edges, and one image that has no texture.
|
|
2023-11-08 09:31:44
|
So they are each very easy to compress separately, and when added together you get something that looks impossible to distinguish from the original image.
|
|
|
|
lonjil
|
2023-11-09 08:52:18
|
It's already politically correct
|
|
|
|
spider-mario
|
2023-11-09 09:52:17
|
agreed, I contest that “mastering” used in that context has any good reason to offend anyone
|
|
2023-11-09 09:52:31
|
it seems unlikely that shunning that word would actually do anything to combat human slavery
|
|
2023-11-09 09:53:44
|
but maybe this is not the best channel for this conversation
|
|
|
|
jonnyawsom3
|
2023-11-09 10:21:20
|
Yeah, I had some words to say but I'd rather not get into it
|
|
|
|
Oleksii Matiash
|
2023-11-09 12:25:21
|
As I'm by far not native english speaker, this political (in)correctness in computer terminology is very odd for me. I used to treat master\slave in PATA as of main\second, and nothing resembled real slavery. Maybe my 'non-nativeness' is the reason, don't know.. Sorry for offtoping
|
|
|
professional marlboro smoker
|
|
|
Halfonso
|
2023-11-11 01:27:23
|
I am trying to copy metadata from a raw to a jxl, I get this error, do anyone know how to fix it?
Error: [minor] Will wrap JXL codestream in ISO BMFF container for writing - DSC05017.jxl
0 image files updated
1 files weren't updated due to errors
|
|
|
|
jonnyawsom3
|
2023-11-11 01:48:28
|
What program?
|
|
|
|
Halfonso
|
2023-11-11 01:48:39
|
exiftool
|
|
|
|
username
|
2023-11-11 01:59:22
|
are you using the latest version of exiftool? (12.69 currently) if so then maybe report the problem to the exiftool forums https://exiftool.org/forum/index.php?board=6.0
|
|
2023-11-11 02:00:30
|
exiftool's support for jxl is based on attempting to analyze the jxl format since they don't have access to the specs
|
|
|
|
Halfonso
|
2023-11-11 02:03:09
|
From what I have investigated, exiftool only supports reading and writing metadata in jxl using EXIF and JXL, and the SONY ARW source files I think are in IPTC format therefore it won't let me copy it
|
|
2023-11-11 02:04:27
|
If I put '-IPTC:all', '-o' to exclude metadata in that format when copying it does not copy anything
Warning: No writable tags set from DSC05005.ARW
Error: Can't create JXL files from scratch
|
|
|
-Julian-
|
2023-11-11 05:13:29
|
can anyone help me understand how to read metadata from a jxl file? I am trying to make my first OSS contribution where I can get the dimensions of a jxl file but I cannot seem to find online how to read the proper metadata for this
|
|
|
|
monad
|
|
-Julian-
can anyone help me understand how to read metadata from a jxl file? I am trying to make my first OSS contribution where I can get the dimensions of a jxl file but I cannot seem to find online how to read the proper metadata for this
|
|
2023-11-11 08:36:30
|
https://discord.com/channels/794206087879852103/803663417881395200/1162447725342769183
|
|
|
|
Traneptora
|
|
-Julian-
can anyone help me understand how to read metadata from a jxl file? I am trying to make my first OSS contribution where I can get the dimensions of a jxl file but I cannot seem to find online how to read the proper metadata for this
|
|
2023-11-11 04:44:51
|
https://discord.com/channels/794206087879852103/1021189485960114198/1169087534060556339
|
|
2023-11-11 04:44:57
|
check the spec
|
|
|
Dexrn ZacAttack
|
2023-11-13 01:35:53
|
How can I embed a JXL in a website, Firefox and Safari don't seem to embed it
|
|
2023-11-13 01:40:11
|
Is it up to the web browsers to add support or is there some funny workaround I can do
|
|
|
Denshi
|
|
Dexrn ZacAttack
Is it up to the web browsers to add support or is there some funny workaround I can do
|
|
2023-11-13 01:54:43
|
I'm guessing the people here can give better advice but here's a polyfill you could try: https://github.com/niutech/jxl.js
|
|
|
|
Dexrn ZacAttack
|
|
Denshi
I'm guessing the people here can give better advice but here's a polyfill you could try: https://github.com/niutech/jxl.js
|
|
2023-11-13 01:55:32
|
Can I use the script from the github directly or should I download it
|
|
|
|
Denshi
|
2023-11-13 01:56:24
|
I don't think there's a hosted version, so yes you'll have to do that yourself.
|
|
|
|
username
|
|
Dexrn ZacAttack
How can I embed a JXL in a website, Firefox and Safari don't seem to embed it
|
|
2023-11-13 02:01:05
|
it should work in Safari if you are on iOS 17 or macOS 14
|
|
|
|
Dexrn ZacAttack
|
|
username
it should work in Safari if you are on iOS 17 or macOS 14
|
|
2023-11-13 02:02:35
|
I'm updating MacOS right now, I was on macOS 14 but on a beta before release
|
|
2023-11-13 02:02:43
|
also arent you in Omniarchive?
|
|
|
|
username
|
2023-11-13 02:02:53
|
yep
|
|
2023-11-13 02:03:26
|
I saw you where working on a file hosting site for another user
|
|
|
|
Dexrn ZacAttack
|
2023-11-13 02:03:27
|
Thought I knew you from somewhere
|
|
|
username
I saw you where working on a file hosting site for another user
|
|
2023-11-13 02:03:31
|
yes
|
|
2023-11-13 02:04:19
|
<@404585766799278081> was putting JXLs on there and showed me some cool stuff about how small an image can be but still be very detailed (like 53 byte images having a ton of detail), I wanted to try to get it to embed for other browsers as well.
|
|
|
|
username
|
2023-11-13 02:05:35
|
oh huh I was thinking about uploading a jxl file for fun but I guess I got beaten to it lol
|
|
|
|
Dexrn ZacAttack
|
|
username
oh huh I was thinking about uploading a jxl file for fun but I guess I got beaten to it lol
|
|
2023-11-13 02:05:52
|
I mean once I get it working it should preview
|
|
|
|
username
|
|
|
Dexrn ZacAttack
|
|
username
|
|
2023-11-13 02:07:19
|
Did I get it working?
|
|
2023-11-13 02:07:22
|
or is that your browser
|
|
|
|
username
|
2023-11-13 02:07:34
|
the browser I'm using supports JXL
|
|
|
|
Dexrn ZacAttack
|
|
username
the browser I'm using supports JXL
|
|
2023-11-13 02:07:41
|
What one? Safari?
|
|
|
|
username
|
2023-11-13 02:07:53
|
I'm using Waterfox
|
|
|
|
Dexrn ZacAttack
|
2023-11-13 02:08:02
|
uh what the hell just happened
|
|
2023-11-13 02:08:14
|
I just heard a low pitched discord ping sound
|
|
|
|
username
|
2023-11-13 02:09:12
|
probably just discord being broken as always
|
|
|
|
Dexrn ZacAttack
|
|
|
username
|
2023-11-13 02:10:16
|
jxl support in normal firefox is a bit busted
|
|
|
|
Quackdoc
|
2023-11-13 02:10:38
|
firefox can't afford to update a couple PRs and merge them xD
|
|