|
DNFrozen
|
2024-08-23 09:25:11
|
and the question if programm x can handle jxl files can also be quite complicated
|
|
|
username
|
2024-08-23 09:25:40
|
I've seen lossy PNGs before and also GIFs weren't really intended to be used for animation
|
|
2024-08-23 09:27:45
|
I mean the PNG format/codec itself is all lossless up to the limits of the spec but you can kinda just put whatever you want in them such as a lossy source or there are websites and other places (like Photoshop) that will reduce the colors of a PNG to improve compression so you can't be certain they are *always* lossless
|
|
|
HCrikki
|
2024-08-23 09:28:10
|
gif isnt always animated, its animations that had to be gifs
|
|
|
|
username
|
2024-08-23 09:29:03
|
GIFs where intended for still images and interlaced GIFs are neat for progressive loading but pretty much don't work at all for animated ones
|
|
2024-08-23 09:32:14
|
though for JPEGs yeah they are all lossy which makes it easy to tell what they are at a glance since they can't be lossless with the defacto standard of them
|
|
|
|
DNFrozen
|
2024-08-23 09:33:18
|
when i start converting png files to jxl I'll give them another file extension so that i know what I'm dealing with in the explorer
and if i ever need to convert them to something else i can select the files based on their properties
|
|
|
|
HCrikki
|
2024-08-23 09:35:35
|
id recommend against fiddling with file extensions. rename files if you want but imo thats unnecessary
|
|
|
|
username
|
2024-08-23 09:35:56
|
is there an issue with going the route of just having something "-lossy"/"-lossless" at the end of the file name? I keep seeing people who want to tell the two apart use custom file extensions rather then names and I don't understand why exactly
|
|
|
|
HCrikki
|
2024-08-23 09:36:43
|
maybe its because library managers havent supported recent exif versions or jxl ?
|
|
|
|
username
|
|
username
is there an issue with going the route of just having something "-lossy"/"-lossless" at the end of the file name? I keep seeing people who want to tell the two apart use custom file extensions rather then names and I don't understand why exactly
|
|
2024-08-23 09:38:27
|
like I assume most programs and especially command-line scripting langs allow doing masks/filters by text in the file name and aren't just limited to file extension right?
|
|
|
|
HCrikki
|
2024-08-23 09:39:00
|
converters also dont seem to extend metadata with additional info like effort or encoder software used - its only keep or wipe
|
|
|
|
DNFrozen
|
2024-08-23 09:39:45
|
if i convert jpg via recompression and png files to a lossless format and they are in the same folder i can't really reverse it if i don't seperate them with own file extensions. XLConverter won't treat them differernt and i will also have no idea what thee image were originally
|
|
|
jonnyawsom3
|
|
HCrikki
converters also dont seem to extend metadata with additional info like effort or encoder software used - its only keep or wipe
|
|
2024-08-23 09:40:50
|
Ironically, that's the one thing Adobe actually did right in JXL DNGs. They record the effort, decode speed and distance of the files
|
|
|
|
DNFrozen
|
2024-08-23 09:41:39
|
mmh distance of files? what does that mean?
|
|
|
Oleksii Matiash
|
|
HCrikki
reconstructible jpg->jxl seems can be decoded as either format almost instantly
|
|
2024-08-23 09:41:55
|
jpg-in-jxl decodes faster than original jpg, probably because of multi- and singlethread decoding, idk
|
|
|
|
jonnyawsom3
|
2024-08-23 09:41:56
|
Another way of setting the quality
|
|
|
|
HCrikki
|
2024-08-23 09:42:41
|
preserving metadata should be preferred to extension tinkering
|
|
|
|
username
|
|
DNFrozen
mmh distance of files? what does that mean?
|
|
2024-08-23 09:43:17
|
different way of talking about quality level, and as <@238552565619359744> mentioned it's also a different way to set the quality level in libjxl
|
|
|
|
HCrikki
|
2024-08-23 09:43:42
|
scouring the metadata of a hundred thou images can be super quick without decoding imgs or generating thumbnails
|
|
|
|
DNFrozen
|
2024-08-23 09:44:22
|
well but metadata only matters if the programm you use seperates the files based on their metadata the way you want it to. and that will probably not be the case unless you wrote that software yourself
|
|
|
|
jonnyawsom3
|
|
HCrikki
scouring the metadata of a hundred thou images can be super quick without decoding imgs or generating thumbnails
|
|
2024-08-23 09:44:36
|
Well if you just want to tell a reconstructable jpeg JXL from anything else, you could search for the `jbrd` box
|
|
|
|
DNFrozen
|
2024-08-23 09:45:52
|
mmh how would i do that?
|
|
2024-08-23 09:46:47
|
is jbrd something in the metadata?
|
|
2024-08-23 09:52:53
|
any idea why google prevents jxl from getting adopted? the arguments they listed for removing jxl support in chrome are stupid
do they have a way to make money with webp or are there metadata in webp images that can be abused for tracking or serving more targeted ads?
i can't really make sense of this situation
|
|
|
|
username
|
2024-08-23 09:56:11
|
https://discord.com/channels/794206087879852103/822105409312653333/1235130612910788668
|
|
2024-08-23 09:57:34
|
pretty much just boils down to AVIF people having final say
|
|
|
|
jonnyawsom3
|
2024-08-24 07:06:19
|
<@625718249262284800> how did you create the file?
|
|
|
CrushedAsian255
|
|
<@625718249262284800> how did you create the file?
|
|
2024-08-24 07:14:06
|
what file?
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
what file?
|
|
2024-08-24 07:14:31
|
https://discord.com/channels/794206087879852103/848189884614705192/1276798074555072677
|
|
|
|
CrushedAsian255
|
2024-08-24 07:14:48
|
oh, continuing that convo here
|
|
2024-08-24 07:17:48
|
<@1102876331986927627> continuing this conversation here to not deal with the 5m cooldown
|
|
|
|
Oleksii Matiash
|
2024-08-24 07:30:28
|
Also it is quite interesting that cjxl -d 0 -e 10 original.jxl opt.jxl produces 6420 bytes file, while original is 4275
|
|
|
|
jonnyawsom3
|
2024-08-24 07:30:50
|
I think this is just an issue with displaying 32bit colors on a lower bitdepth screen
I made a new 128 x 8192 Green gradient, and this is mathematically a smooth gradient, even though it has very obvious banding when viewing on a display
|
|
|
|
Oleksii Matiash
|
|
Oleksii Matiash
Also it is quite interesting that cjxl -d 0 -e 10 original.jxl opt.jxl produces 6420 bytes file, while original is 4275
|
|
2024-08-24 07:33:49
|
But e6 and e7 produce 4275 bytes <:YEP:808828808127971399>
|
|
|
I think this is just an issue with displaying 32bit colors on a lower bitdepth screen
I made a new 128 x 8192 Green gradient, and this is mathematically a smooth gradient, even though it has very obvious banding when viewing on a display
|
|
2024-08-24 07:36:18
|
There are only 249 unique colors in the discussed file
|
|
|
|
CrushedAsian255
|
|
Oleksii Matiash
But e6 and e7 produce 4275 bytes <:YEP:808828808127971399>
|
|
2024-08-24 07:36:33
|
`-e 10 -g 3` gives a filesize of 1741
|
|
|
|
jonnyawsom3
|
|
Oleksii Matiash
There are only 249 unique colors in the discussed file
|
|
2024-08-24 07:36:58
|
That's because Irfanview is rendering it as 24bit, it says directly above the counted colors
|
|
|
I think this is just an issue with displaying 32bit colors on a lower bitdepth screen
I made a new 128 x 8192 Green gradient, and this is mathematically a smooth gradient, even though it has very obvious banding when viewing on a display
|
|
2024-08-24 07:37:29
|
|
|
2024-08-24 07:37:46
|
That's the 8K file, Irfaview also says it has only a handful of colors
|
|
|
|
CrushedAsian255
|
|
|
|
2024-08-24 07:38:18
|
opening this in Waterfox shows banding but opening it in Preview shows no banding
|
|
|
|
Oleksii Matiash
|
|
That's because Irfanview is rendering it as 24bit, it says directly above the counted colors
|
|
2024-08-24 07:38:19
|
Optimizers also reduce it to 8bpp file with the same 249 colors. So I believe no
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
opening this in Waterfox shows banding but opening it in Preview shows no banding
|
|
2024-08-24 07:38:35
|
HDR versus normal rendering, probably
|
|
|
Oleksii Matiash
Optimizers also reduce it to 8bpp file with the same 249 colors. So I believe no
|
|
2024-08-24 07:39:21
|
Try opening it in something like Krita and use the color picker
|
|
|
|
CrushedAsian255
|
2024-08-24 07:39:31
|
i think OP's image is actually banding, as your image shows none in Preview however OP's does show banding even in Preview
|
|
|
|
jonnyawsom3
|
2024-08-24 07:39:39
|
I'm going out for a while, be back in an hour
|
|
|
|
CrushedAsian255
|
|
I'm going out for a while, be back in an hour
|
|
2024-08-24 07:39:46
|
cya
|
|
|
|
Oleksii Matiash
|
|
CrushedAsian255
`-e 10 -g 3` gives a filesize of 1741
|
|
2024-08-24 07:41:39
|
-e11 gave 1736 <:Hypers:808826266060193874> ๐
|
|
|
qdwang
|
2024-08-24 07:41:54
|
I wrote a loop. The color of the file is float32 values from `(0, row_index / height, 0)`
|
|
|
|
CrushedAsian255
|
|
Oleksii Matiash
-e11 gave 1736 <:Hypers:808826266060193874> ๐
|
|
2024-08-24 07:41:57
|
so does `-e 10 -g 3 -I 100`
|
|
2024-08-24 07:42:15
|
which is probably what `-e 11` decided on
|
|
|
I wrote a loop. The color of the file is float32 values from `(0, row_index / height, 0)`
|
|
2024-08-24 07:42:20
|
can you share the original output
|
|
2024-08-24 07:42:25
|
before being converted to JXL?
|
|
|
|
qdwang
|
2024-08-24 07:43:28
|
I encode the RGB data directly with the C API... so I don't have the original file
|
|
|
|
CrushedAsian255
|
|
I encode the RGB data directly with the C API... so I don't have the original file
|
|
2024-08-24 07:43:53
|
try exporting to PFM or something and then convert using `cjxl`
|
|
2024-08-24 07:43:53
|
and see if the same thing happens
|
|
|
Tirr
|
2024-08-24 07:46:39
|
maybe color encoding info is not set properly if you directly used libjxl
|
|
|
|
Oleksii Matiash
|
|
Try opening it in something like Krita and use the color picker
|
|
2024-08-24 07:47:42
|
You are right. I clearly see banding in your file while Krita says it is smooth. And it is on 10 bpc monitor ๐คฆโโ๏ธ Also OP's file does not show banding when opened in Krita
|
|
|
|
qdwang
|
|
CrushedAsian255
try exporting to PFM or something and then convert using `cjxl`
|
|
2024-08-24 07:48:21
|
Ok I'll try to export a PFM file
|
|
|
|
Tirr
|
2024-08-24 07:52:57
|
`jxl-oxide gradient.jxl -f png16 -o output.png` gives smooth gradient. maybe decode buffer is set to 8bpc
|
|
2024-08-24 07:57:31
|
no, banding is not that awful even with png8. I guess it's color management issue, losing precision of linear f32 somewhere in the pipeline
|
|
|
|
qdwang
|
2024-08-24 08:05:10
|
I created the PFM file with the same data, but why it's vertically flipped?
|
|
2024-08-24 08:05:43
|
|
|
|
|
CrushedAsian255
|
|
|
qdwang
|
2024-08-24 08:18:44
|
My tests here:
1. 32bit-lossless-jxl generated from C API: smooth in macos, HEAVY color banding on iPhone, HEAVY color banding in Lightroom on iOS
2. 32bit-lossless-jxl generated from PFM with `cjxl -d 0`: smooth in macos, light color banding on iPhone, light color banding in Lightroom on iOS
3. 32bit-lossless-jxl generated from C API -> `djxl` to 16bit PNG: smooth in macos, smooth on iPhone, smooth in Lightroom on iOS
|
|
|
|
CrushedAsian255
|
2024-08-24 08:20:16
|
could be issues with MacOS / iOS's implementation of JXL
|
|
|
|
qdwang
|
2024-08-24 08:24:30
|
It could be. It seems the 32bit JXL cannot be easily rendered correctly for these viewers.
|
|
|
|
CrushedAsian255
|
2024-08-24 08:24:47
|
can you send the jxl generated from the PFM?
|
|
2024-08-24 08:24:53
|
it could be buggy colour management
|
|
|
|
qdwang
|
|
|
CrushedAsian255
|
2024-08-24 08:26:22
|
the one from PFM uses sRGB transfer while the one from the API has Linear transfer
|
|
2024-08-24 08:27:20
|
so probably buggy colour management systems
|
|
2024-08-24 08:27:43
|
although it's weird that a PNG decoded from the banding JXL doesn't have the banding issue
|
|
2024-08-24 08:27:56
|
PNG colour management is probably more mature
|
|
2024-08-24 08:29:33
|
also JXL support by Apple still has some weird issues, namely not supporting animation at all
|
|
2024-08-24 08:29:54
|
so could just be jxl not being fully / properly implemented / not tested properly
|
|
|
|
qdwang
|
2024-08-24 08:36:01
|
I agree. I'll keep using unsigned integer in jxl for better compatibility for now...
|
|
2024-08-24 08:37:00
|
Can jxl support 32bit unsigned integer?
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
`-e 10 -g 3` gives a filesize of 1741
|
|
2024-08-24 08:39:03
|
Also you want `-I 0` for these gradient tests
|
|
|
|
CrushedAsian255
|
|
Also you want `-I 0` for these gradient tests
|
|
2024-08-24 08:39:25
|
`-I 100` saved 5 bytes
|
|
|
|
Tirr
|
2024-08-24 08:39:32
|
integer samples are limited to 24bit per channel
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
`-I 100` saved 5 bytes
|
|
2024-08-24 08:46:30
|
Realised I was using my 8K file instead of the original, seems the smoother the gradient the better `-I 0` works
|
|
|
|
qdwang
|
|
Tirr
integer samples are limited to 24bit per channel
|
|
2024-08-24 08:47:02
|
Thank you.
|
|
|
I agree. I'll keep using unsigned integer in jxl for better compatibility for now...
|
|
2024-08-24 08:50:06
|
I was wrong. Unsigned 16bit int JXL also can cause the color banding issue on iOS. So there is nothing wrong with the 32bit input data type. It could be the color management issue according to <@386612331288723469>
|
|
|
|
jonnyawsom3
|
|
My tests here:
1. 32bit-lossless-jxl generated from C API: smooth in macos, HEAVY color banding on iPhone, HEAVY color banding in Lightroom on iOS
2. 32bit-lossless-jxl generated from PFM with `cjxl -d 0`: smooth in macos, light color banding on iPhone, light color banding in Lightroom on iOS
3. 32bit-lossless-jxl generated from C API -> `djxl` to 16bit PNG: smooth in macos, smooth on iPhone, smooth in Lightroom on iOS
|
|
2024-08-24 08:50:24
|
I think it's a combination of the 1024 resolution making the 'steps' between pixels relatively large near the black area (I went from 0 to 0.25 G in my gradient to try and test this), along with the 32float not being dithered down for the 8 or 10 bit displays. The PNG decoding is more mature, so likely does it automatically while only certain JXL implementations do.
Or, more likely, they use outdated libjxl versions, which also didn't dither when 8 bit output was requested from higher bitdepth files
This is my amateur opinion though, others here are much more qualified
|
|
2024-08-24 08:51:52
|
https://github.com/libjxl/libjxl/pull/3090
|
|
|
|
CrushedAsian255
|
|
I think it's a combination of the 1024 resolution making the 'steps' between pixels relatively large near the black area (I went from 0 to 0.25 G in my gradient to try and test this), along with the 32float not being dithered down for the 8 or 10 bit displays. The PNG decoding is more mature, so likely does it automatically while only certain JXL implementations do.
Or, more likely, they use outdated libjxl versions, which also didn't dither when 8 bit output was requested from higher bitdepth files
This is my amateur opinion though, others here are much more qualified
|
|
2024-08-24 08:52:58
|
the difference between mac and iOS could also be because of iOS being OLED and macOS being LCD / MiniLED so colour handling is probably coded differently
|
|
|
|
qdwang
|
|
CrushedAsian255
the difference between mac and iOS could also be because of iOS being OLED and macOS being LCD / MiniLED so colour handling is probably coded differently
|
|
2024-08-24 08:54:43
|
I tested on a legacy iPad mini5(LCD based) also. Same issue as it's on iPhone.
|
|
|
https://github.com/libjxl/libjxl/pull/3090
|
|
2024-08-24 08:56:19
|
Thanks for pointing this out.
|
|
2024-08-24 08:57:55
|
Maybe the libjxl on iOS is a little outdated.
|
|
|
|
jonnyawsom3
|
2024-08-24 08:59:30
|
A lot of implementations are still on 0.7 or 0.8, I seem to recall being able to narrow down the IOS version by what files failed to decode a few months ago
|
|
|
|
CrushedAsian255
|
|
A lot of implementations are still on 0.7 or 0.8, I seem to recall being able to narrow down the IOS version by what files failed to decode a few months ago
|
|
2024-08-24 09:01:35
|
how do you do this test? i have iOS 18.0 beta 7 on my phone so could check if they have updated it
|
|
|
|
qdwang
|
2024-08-24 09:03:22
|
Another one interesting thing is the JXLs' filesizes of encoding `uint16` random noise image vs `float32` random noise image are almost the same.
Why? Shouldn't the second one contains more entropy in it?
|
|
|
|
CrushedAsian255
|
2024-08-24 09:03:59
|
well, if it's random noise from 0-1, the exponent won't be uniform
|
|
|
_wb_
|
2024-08-24 09:05:19
|
Lossy or lossless? For lossless, noise should be basically the same filesize as uncompressed.
|
|
|
|
CrushedAsian255
|
|
_wb_
Lossy or lossless? For lossless, noise should be basically the same filesize as uncompressed.
|
|
2024-08-24 09:06:20
|
that makes sense for int16, but wouldn't float32 be able to shrink a bit because the entire range isn't being used so each symbol has less than 32bits of raw entropy?
|
|
2024-08-24 09:06:57
|
Like for uniform float 0-1 noise, it will never have the sign bit
|
|
|
|
_wb_
|
2024-08-24 09:07:16
|
How do you generate random float32 numbers? If it's just 32 random bits, then you can get all floats including NaNs etc
|
|
|
|
qdwang
|
|
_wb_
Lossy or lossless? For lossless, noise should be basically the same filesize as uncompressed.
|
|
2024-08-24 09:08:06
|
lossless
|
|
|
|
CrushedAsian255
|
|
_wb_
How do you generate random float32 numbers? If it's just 32 random bits, then you can get all floats including NaNs etc
|
|
2024-08-24 09:08:13
|
Im thinking more about 1+rand()/randmax - 1 float noise
|
|
2024-08-24 09:08:24
|
But I donโt know what <@625718249262284800> is using
|
|
|
|
qdwang
|
|
_wb_
How do you generate random float32 numbers? If it's just 32 random bits, then you can get all floats including NaNs etc
|
|
2024-08-24 09:08:28
|
I generated float32 ranges from 0 to 1
|
|
|
|
CrushedAsian255
|
2024-08-24 09:08:43
|
Does JXL lossless even support storing NaNs?
|
|
|
|
_wb_
|
2024-08-24 09:08:57
|
Yes, it should.
|
|
|
|
CrushedAsian255
|
2024-08-24 09:09:10
|
Does it just hit cast the floats to ints?
|
|
2024-08-24 09:09:16
|
Bitcast *
|
|
|
|
_wb_
|
2024-08-24 09:09:26
|
Yes, floats are just bitcast to int32_t
|
|
|
|
CrushedAsian255
|
2024-08-24 09:09:34
|
Huh
|
|
2024-08-24 09:10:10
|
wait, with floats if a is bigger than b is bit_cast<int>(a) always bigger than bit_cast<int>(b)?
|
|
|
|
_wb_
|
2024-08-24 09:10:24
|
Yes
|
|
2024-08-24 09:11:22
|
Of course predictors get a bit wonky, but they still do something somewhat useful.
|
|
|
|
Oleksii Matiash
|
|
CrushedAsian255
which is probably what `-e 11` decided on
|
|
2024-08-24 09:12:11
|
Btw, it would be nice for -e11 not only print progress, but also what settings were finally chosen
|
|
|
|
qdwang
|
2024-08-24 09:14:01
|
The float32 version is even smaller than the uint16 version
|
|
|
|
_wb_
|
2024-08-24 09:14:12
|
It's easy to hack a libjxl to do that, but we don't want libjxl itself to just print stuff to stdout, so it would require adding some new kind of API to report progress and other info to the application, which can then show it in some way.
|
|
2024-08-24 09:18:56
|
Float arithmetic is funky. Picking values between 0 and 1 randomly with a uniform distribution and then rounding them to the nearest float32 is not the same thing as selecting a random float32 that is between 0 and 1 randomly with a uniform distribution.
|
|
|
|
qdwang
|
2024-08-24 09:18:57
|
I compressed two new samples with the same noise data.
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
how do you do this test? i have iOS 18.0 beta 7 on my phone so could check if they have updated it
|
|
2024-08-24 09:20:59
|
Try opening this, it should fail on anything before 0.9 <https://github.com/libjxl/libjxl/pull/2958>
|
|
|
|
CrushedAsian255
|
|
Try opening this, it should fail on anything before 0.9 <https://github.com/libjxl/libjxl/pull/2958>
|
|
2024-08-24 09:45:21
|
|
|
2024-08-24 09:45:43
|
Files app
|
|
|
|
qdwang
|
|
_wb_
Float arithmetic is funky. Picking values between 0 and 1 randomly with a uniform distribution and then rounding them to the nearest float32 is not the same thing as selecting a random float32 that is between 0 and 1 randomly with a uniform distribution.
|
|
2024-08-24 09:46:27
|
I get your point. But the interesting thing is with the same data, why the compressed JXL with float32 input is smaller than the uint16 input? (The uint16 data is generated from `(f32_value * 65535) as uint16`)
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
|
|
2024-08-24 09:47:17
|
This was the most recent patch, non-e1 RLE only files. Since it's a beta IOS version it *might* have the patch
|
|
|
|
CrushedAsian255
|
|
This was the most recent patch, non-e1 RLE only files. Since it's a beta IOS version it *might* have the patch
|
|
2024-08-24 09:47:53
|
Whatโs it meant to look like?
|
|
|
|
qdwang
|
2024-08-24 09:48:40
|
|
|
2024-08-24 09:48:57
|
MacOS 14.5 cannot display this
|
|
|
|
CrushedAsian255
|
2024-08-24 09:49:45
|
Just gives blank image
|
|
2024-08-24 09:49:50
|
I donโt think it has that patch
|
|
|
|
_wb_
|
|
I get your point. But the interesting thing is with the same data, why the compressed JXL with float32 input is smaller than the uint16 input? (The uint16 data is generated from `(f32_value * 65535) as uint16`)
|
|
2024-08-24 09:53:47
|
Good question. Is this consistently happening for different random seeds?
Could be some silly reason like channel palette being applied to the u16 data but not the f32 data, causing signaling overhead, or something like that.
|
|
|
|
qdwang
|
2024-08-24 10:00:27
|
"Is this consistently happening for different random seeds?" - Yes
They used the same settings expect the `bits_per_sample` and `exponent_bits_per_sample` in basic_info. Same color space.
|
|
|
|
CrushedAsian255
|
2024-08-24 10:01:27
|
maybe different predictors?
|
|
|
|
qdwang
|
2024-08-24 10:01:34
|
I'll have a try by generating a PFM and a PPM with the same data. And encoding them with jxl command line tools.
|
|
|
|
Oleksii Matiash
|
|
This was the most recent patch, non-e1 RLE only files. Since it's a beta IOS version it *might* have the patch
|
|
2024-08-24 10:04:41
|
Latest IrfanView plugin expectedly fails to open it
|
|
|
|
jonnyawsom3
|
|
Oleksii Matiash
Latest IrfanView plugin expectedly fails to open it
|
|
2024-08-24 10:05:43
|
It fails on the 0.9 file too
|
|
|
|
Oleksii Matiash
|
|
It fails on the 0.9 file too
|
|
2024-08-24 10:07:25
|
Yes -_-
|
|
|
|
qdwang
|
2024-08-24 10:09:39
|
still the same. The f32 version is smaller than the u16 version.
|
|
2024-08-24 10:09:58
|
By using, `cjxl -d 0`
|
|
|
|
jonnyawsom3
|
2024-08-24 10:10:14
|
What about comparing u16 and f16?
|
|
|
|
qdwang
|
2024-08-24 10:10:31
|
Don't know, haven't tested yet.
|
|
|
monad
|
|
Oleksii Matiash
Btw, it would be nice for -e11 not only print progress, but also what settings were finally chosen
|
|
2024-08-24 10:15:27
|
What is your use case for e11? or even e10?
|
|
|
|
Oleksii Matiash
|
|
monad
What is your use case for e11? or even e10?
|
|
2024-08-24 10:16:18
|
e11 - curiosity, e10 - jpeg recompression
|
|
|
|
monad
|
2024-08-24 10:17:12
|
What precisely are you curious about?
|
|
|
|
Oleksii Matiash
|
|
monad
What precisely are you curious about?
|
|
2024-08-24 10:19:10
|
Smallest size that jxl can achieve, and more precisely - in comparison to lossless webp
|
|
|
|
jonnyawsom3
|
2024-08-24 10:20:21
|
https://discord.com/channels/794206087879852103/803645746661425173/1275369899467735072
|
|
|
|
CrushedAsian255
|
|
Oleksii Matiash
e11 - curiosity, e10 - jpeg recompression
|
|
2024-08-24 10:35:44
|
same
|
|
2024-08-24 11:02:40
|
i can probably save some space by converting my old MJPEG+WAV AVI files into JPEGXL and FLAC files
|
|
2024-08-24 11:02:45
|
without losing any quality
|
|
2024-08-24 11:03:24
|
personally just waiting for JXL to get a FourCC of some kind so I can natively embed it and mpv and stuff read it
i can't get ffmpeg to compile properly on my Mac so I can't use that patch to add one
|
|
|
RaveSteel
|
2024-08-24 11:22:50
|
Except MJPEG sadly cannot be recompressed to JXL yet. Or have I missed something?
|
|
|
|
CrushedAsian255
|
|
RaveSteel
Except MJPEG sadly cannot be recompressed to JXL yet. Or have I missed something?
|
|
2024-08-24 11:23:58
|
can't you just demux into individual JPEGs?
|
|
2024-08-24 11:24:08
|
MJPEG is just a bunch of JPEGs in a file, isn't it?
|
|
|
|
HCrikki
|
2024-08-24 11:25:24
|
i recall someone trying some kind of 'motionjxl' script with differential frames to save data (meant for cctv-like footage) but as long as you keep the originals, you could just recompress from source
|
|
|
|
RaveSteel
|
|
CrushedAsian255
MJPEG is just a bunch of JPEGs in a file, isn't it?
|
|
2024-08-24 11:25:25
|
Yes, but now there are a bunch of jxl files that cannot be muxed into an MKV or similar, because there is no tool to MUX/concatenate them
|
|
|
|
CrushedAsian255
|
|
RaveSteel
Yes, but now there are a bunch of jxl files that cannot be muxed into an MKV or similar, because there is no tool to MUX/concatenate them
|
|
2024-08-24 11:25:37
|
that's what i was saying about FourCC codes
|
|
2024-08-24 11:25:50
|
you can't mux them without a FourCC code
|
|
|
Quackdoc
|
2024-08-24 11:26:49
|
you can easily modify ffmpeg to add ` JXL` to riff tags and mux it into whatever container you want
|
|
|
|
CrushedAsian255
|
|
Quackdoc
you can easily modify ffmpeg to add ` JXL` to riff tags and mux it into whatever container you want
|
|
2024-08-24 11:27:10
|
i tried to but i couldn't get ffmpeg to compile
|
|
|
|
RaveSteel
|
|
Quackdoc
you can easily modify ffmpeg to add ` JXL` to riff tags and mux it into whatever container you want
|
|
2024-08-24 11:27:14
|
Without lossless recompression though, right?
|
|
|
|
Quackdoc
|
|
RaveSteel
Without lossless recompression though, right?
|
|
2024-08-24 11:27:44
|
it's just muxing, you would need to feed the jxl frames to ffmpeg.
|
|
|
|
RaveSteel
|
|
Quackdoc
it's just muxing, you would need to feed the jxl frames to ffmpeg.
|
|
2024-08-24 11:29:18
|
Sounds good, now if only ffmpeg had better jxl support without compiling yourself
|
|
|
|
CrushedAsian255
|
|
RaveSteel
Sounds good, now if only ffmpeg had better jxl support without compiling yourself
|
|
2024-08-24 11:29:45
|
JXL has a few defined ISOBMFF FourCCs
|
|
2024-08-24 11:29:52
|
so that shouldn't be a problem
|
|
|
|
Quackdoc
|
|
RaveSteel
Sounds good, now if only ffmpeg had better jxl support without compiling yourself
|
|
2024-08-24 11:30:19
|
well someone could submit the patch upstream, im not gonna bother myself.
|
|
|
|
RaveSteel
|
|
Quackdoc
well someone could submit the patch upstream, im not gonna bother myself.
|
|
2024-08-24 11:31:03
|
There is a patch for a jxl_anim Encoder, but there has been no movement on that front
|
|
|
|
Quackdoc
|
2024-08-24 11:31:05
|
actually <@853026420792360980> wasn't lynne working on a new container format that would properly support JXL anyways? how's that going?
|
|
|
|
CrushedAsian255
|
|
Quackdoc
actually <@853026420792360980> wasn't lynne working on a new container format that would properly support JXL anyways? how's that going?
|
|
2024-08-24 11:33:55
|
like an mxf but just for JXL?
|
|
|
Traneptora
|
|
Quackdoc
actually <@853026420792360980> wasn't lynne working on a new container format that would properly support JXL anyways? how's that going?
|
|
2024-08-24 11:36:53
|
Yes but I haven't gotten around to reviewing my part
|
|
2024-08-24 11:37:10
|
been busy
|
|
|
|
CrushedAsian255
|
2024-08-24 11:37:56
|
is it open source?
|
|
|
|
Quackdoc
|
2024-08-24 11:39:00
|
neat, best of luck
|
|
|
|
RaveSteel
|
2024-08-24 11:42:15
|
Sounds good, especially if viewable in a normal image viewer, like animated avif/webp
|
|
|
|
CrushedAsian255
|
|
RaveSteel
Sounds good, especially if viewable in a normal image viewer, like animated avif/webp
|
|
2024-08-24 11:49:26
|
if it's a custom container, it would need extra implementation
|
|
2024-08-24 11:49:34
|
unless they mean just using an animated JXL
|
|
2024-08-24 11:49:52
|
hmm, that gives me an idea, could you use JXL boxes to add arbitrary data?
|
|
2024-08-24 11:50:09
|
Im guessing if the JXL decoder sees a box it doesn't understand it skips it?
|
|
2024-08-24 11:51:30
|
so you could theoretically interleave FLAC audio to make a JXL mezzanine format
```
JXL
ftyp
jxll
movi - Custom box storing information about the video
jxlp - JXL animation frame
flac - FLAC audio data
jxlp - JXL animation frame
flac - FLAC audio data
....
```
|
|
2024-08-24 11:54:01
|
a JXL version of ProRes .MOV files?
|
|
|
|
Quackdoc
|
2024-08-24 11:57:28
|
when it comes to using JXL as a mezzanine, the container itself doesnt matter to much as long as seeking works fine, I was using MKV
|
|
|
|
CrushedAsian255
|
|
Quackdoc
when it comes to using JXL as a mezzanine, the container itself doesnt matter to much as long as seeking works fine, I was using MKV
|
|
2024-08-24 11:59:00
|
Ik I was just thinking you could make a polyglot file which contains a FLAC file and an animated JXL file
|
|
2024-08-24 11:59:08
|
Because flac also ignore unknown data
|
|
2024-08-24 11:59:17
|
Unless it gets a sync byte
|
|
|
|
jonnyawsom3
|
2024-08-24 12:02:35
|
Simple, just store an mp4 in the metadata https://github.com/libjxl/libjxl/issues/3502
|
|
|
|
CrushedAsian255
|
|
Simple, just store an mp4 in the metadata https://github.com/libjxl/libjxl/issues/3502
|
|
2024-08-24 12:04:55
|
Thatโs one way to do it
|
|
|
|
RaveSteel
|
|
Simple, just store an mp4 in the metadata https://github.com/libjxl/libjxl/issues/3502
|
|
2024-08-24 12:09:13
|
Does this play in an image viewer?
|
|
|
|
jonnyawsom3
|
2024-08-24 12:10:06
|
I was joking, but no
|
|
|
|
CrushedAsian255
|
2024-08-24 12:13:48
|
How would Apple store Live Photos in a JPEG XL?
|
|
2024-08-24 12:15:31
|
Yeet an MOV in a box?
|
|
|
|
HCrikki
|
2024-08-24 12:17:28
|
do live photos have to be an animated jxl? they could keep using heif if thats what they already do
|
|
|
|
CrushedAsian255
|
|
HCrikki
do live photos have to be an animated jxl? they could keep using heif if thats what they already do
|
|
2024-08-24 12:18:11
|
Currently I think Live Photos are just an MOV sidecar ?
|
|
2024-08-24 12:18:38
|
As in if I extract a HEIF from iPhone it doesnโt contain any video
|
|
|
|
HCrikki
|
2024-08-24 12:19:16
|
afaik its a jpg/heif + an hevc video, both required to be decoded together
|
|
|
|
CrushedAsian255
|
2024-08-24 12:19:51
|
Why would it need to decode the MOV if just showing the image?
|
|
|
|
HCrikki
|
2024-08-24 12:21:11
|
img is basically a thumbnail/preview, its the video youre viewing. for spec compliance gallery apps prob need to be capable of decoding both
|
|
|
|
CrushedAsian255
|
2024-08-24 12:22:55
|
Iโm pretty sure the img is the full image
|
|
2024-08-24 12:22:59
|
At least with Apple
|
|
2024-08-24 12:23:40
|
Thereโs an option to export with or without Live Photo so Iโm pretty sure itโs just a normal image with a video sidecar file
|
|
|
lonjil
|
2024-08-24 01:43:22
|
Yeah, pretty sure it's two files, one regular full size image, and one regular video.
|
|
|
|
CrushedAsian255
|
2024-08-24 01:50:20
|
Just checked, thatโs how itโs handled at least in iMessage
|
|
2024-08-24 01:50:44
|
Since it already works with JPG as well as HEIC itโs probably fine for them to change it to a JXL
|
|
|
Managor
|
|
RaveSteel
Yes, but now there are a bunch of jxl files that cannot be muxed into an MKV or similar, because there is no tool to MUX/concatenate them
|
|
2024-08-24 02:32:02
|
Ah so jxl animations aren't yet backwards compatible?
|
|
|
|
jonnyawsom3
|
2024-08-24 02:33:31
|
Backwards compatible to what?
|
|
|
|
RaveSteel
|
|
Managor
Ah so jxl animations aren't yet backwards compatible?
|
|
2024-08-24 02:47:33
|
Regarding animation the current situation is the following:
- cjxl allows encoding animated jxl, but limited to APNG.
A sequence of jpgs or pngs has to be transcoded to APNG first.
- ffmpeg has no encoder for jxl animations, a patch for adding an encoder exists, but without activity. I cannot comment on that patch since I have not tested it. It is also not possible to MUX or concatenate jxl files together to make an animation.
- ImageMagick is basically the same situation as ffmpeg, sans patch to try out.
Correct me if I missed something, typing this on mobile
|
|
|
|
Managor
|
|
Backwards compatible to what?
|
|
2024-08-24 02:48:24
|
Similar to how you can convert jpg to jxl with no losses you could convert mjpeg to jxl animation with no losses is what I meant
|
|
|
|
RaveSteel
|
|
Managor
Similar to how you can convert jpg to jxl with no losses you could convert mjpeg to jxl animation with no losses is what I meant
|
|
2024-08-24 02:49:06
|
No, since no existing encoder (to my knowledge) supports decoding mjpeg or muxing jxl files to an animated jxl
|
|
|
|
username
|
2024-08-24 02:50:14
|
mjpeg isn't really a format it's just a bunch of JPEGs but you could losslessly transcode each JPEG inside of a MJPEG and I guess end up with a ""MJXL" or something
|
|
|
|
RaveSteel
|
|
username
mjpeg isn't really a format it's just a bunch of JPEGs but you could losslessly transcode each JPEG inside of a MJPEG and I guess end up with a ""MJXL" or something
|
|
2024-08-24 02:51:35
|
Sadly no, there is no way to MUX them together after recompressing then
|
|
2024-08-24 02:52:34
|
Except for reencoding
|
|
|
|
Managor
|
2024-08-24 02:52:40
|
Is it "no way" in theoretical level or "no way" as in there aren't tools for that yet?
|
|
|
|
RaveSteel
|
2024-08-24 02:52:49
|
No tools yet
|
|
2024-08-24 02:53:41
|
The only way is APNG as a mezzanine format and using cjxl to turn it into a jxl animation
|
|
2024-08-24 02:54:12
|
This results in a much larger file depending on the source files though
|
|
2024-08-24 02:56:00
|
You could of course use GIF as a mezzanine format too, but that doesn't really make sense due to the format limitations
|
|
|
|
jonnyawsom3
|
2024-08-24 02:56:11
|
The discussion above was about splitting MJPEG into seperate jpegs, using cjxl on those, then re-combining the JXLs into an MKV using a custom FFMPEG
|
|
|
|
RaveSteel
|
2024-08-24 02:59:03
|
Ideally the resulting file would be a jxl of course, but being able to do both would be nice
|
|
|
|
_wb_
|
2024-08-24 03:17:45
|
Not sure what happens in the current libjxl API if you try to encode multiple frames that are a recompressed jpeg each. We haven't been super clear in the spec either about how to deal with multiple jbrd boxes.
|
|
|
spider-mario
|
2024-08-24 03:33:25
|
does that mean thereโs room for standardising this without too much effort?
|
|
|
|
_wb_
|
2024-08-24 04:22:18
|
Yes, basically we can just make it work in libjxl and make it clear in some future edition of the spec how to do it. The most straightforward way to do it is to just follow box order.
|
|
|
|
spider-mario
|
2024-08-24 04:35:42
|
is it possible to interleave jxl frames and jbrd boxes to enable streaming usage?
|
|
|
|
veluca
|
2024-08-24 05:42:20
|
I don't see why it wouldn't be?
|
|
|
|
jonnyawsom3
|
2024-08-24 05:43:39
|
I was going to mention the TOC
|
|
|
|
veluca
|
2024-08-24 06:06:19
|
TOC is inside each frame anyway
|
|
|
|
_wb_
|
2024-08-24 06:50:42
|
The only somewhat nontrivial thing is: what if there is Exif/XMP/JUMBF metadata that is needed for jpeg bitstream reconstruction? I guess again just box order: first time you need an Exif blob, you take the first one, second time you need one, it's the second one, etc.
|
|
|
|
spider-mario
|
|
veluca
I don't see why it wouldn't be?
|
|
2024-08-24 07:19:36
|
I didnโt remember for sure whether we could split frames across boxes, but I guess I should have a bit more faith in our past selves ๐
|
|
|
|
veluca
|
2024-08-24 07:20:50
|
The jxlp box knows nothing of the contents of the bitstream, it just splits bytes ๐
|
|
|
|
spider-mario
|
2024-08-24 07:21:22
|
right, but I didnโt remember that that was possible either
|
|
|
|
jonnyawsom3
|
2024-08-24 07:30:47
|
This all sounds new to me, mind explaining some more?
|
|
|
|
veluca
|
2024-08-24 07:45:34
|
if you use the container format, you can either put all the codestream in a `jxlc` box or in multiple `jxlp` boxes (which are effectively concatenated)
|
|
|
_wb_
The only somewhat nontrivial thing is: what if there is Exif/XMP/JUMBF metadata that is needed for jpeg bitstream reconstruction? I guess again just box order: first time you need an Exif blob, you take the first one, second time you need one, it's the second one, etc.
|
|
2024-08-24 07:46:05
|
how about always the same? in a MJPEG presumably it's not incredibly relevant
|
|
|
|
_wb_
|
2024-08-24 07:50:45
|
For ICC profiles we have no other choice than always the same. But for exif/xmp it might make sense to have different exif per image, for things like a photo album where each photo can have different timestamps and gps coords and whatnot
|
|
2024-08-24 07:51:08
|
For mjpeg probably there is usually no exif at all
|
|
|
Dexrn ZacAttack
|
2024-08-24 08:00:57
|
Is this just another case of Twitter misinformation?
|
|
|
|
jonnyawsom3
|
2024-08-24 08:01:48
|
<#1256302117379903498>
|
|
|
A homosapien
|
|
Dexrn ZacAttack
Is this just another case of Twitter misinformation?
|
|
2024-08-24 08:21:56
|
The "friend working with jpeg XL" is here https://discord.com/channels/794206087879852103/822105409312653333/1276724252816576614
|
|
|
|
CrushedAsian255
|
|
_wb_
Yes, basically we can just make it work in libjxl and make it clear in some future edition of the spec how to do it. The most straightforward way to do it is to just follow box order.
|
|
2024-08-24 11:53:56
|
Is there any room to add an index to the jbrd?
|
|
|
_wb_
The only somewhat nontrivial thing is: what if there is Exif/XMP/JUMBF metadata that is needed for jpeg bitstream reconstruction? I guess again just box order: first time you need an Exif blob, you take the first one, second time you need one, it's the second one, etc.
|
|
2024-08-24 11:54:50
|
For anomations wouldnโt metadata usually be either the same or very similar or, and for mjpeg there usually isnโt any metadata
|
|
2024-08-25 12:12:20
|
Is it within spec to chuck whatever arbitrary metadata I want in a box as long as it has a different box type?
|
|
|
|
_wb_
|
|
CrushedAsian255
Is it within spec to chuck whatever arbitrary metadata I want in a box as long as it has a different box type?
|
|
2024-08-25 07:05:41
|
Yes, spec says unknown boxes have to be ignored by decoders.
|
|
|
CrushedAsian255
Is there any room to add an index to the jbrd?
|
|
2024-08-25 07:07:12
|
jbrd syntax is frozen, cannot change it now. But just using the convention that the n-th jbrd box corresponds to the n-th frame in the jxl codestream should be good enough, no real need to add indices...
|
|
|
|
CrushedAsian255
|
|
_wb_
jbrd syntax is frozen, cannot change it now. But just using the convention that the n-th jbrd box corresponds to the n-th frame in the jxl codestream should be good enough, no real need to add indices...
|
|
2024-08-25 07:15:55
|
what if one of the frames is not from a jpeg?
|
|
2024-08-25 07:15:57
|
an empty box?
|
|
|
|
_wb_
|
2024-08-25 08:21:21
|
Yes, that could work...
|
|
|
|
veluca
|
2024-08-25 08:39:32
|
could also make a wrapper around the jbrd box or something
|
|
|
|
jonnyawsom3
|
2024-08-25 09:34:28
|
The jbrd box box
|
|
|
|
CrushedAsian255
|
|
The jbrd box box
|
|
2024-08-25 09:38:06
|
This kind of already exists with the brob box
|
|
2024-08-25 09:40:57
|
<@794205442175402004> continuing from <#848189884614705192> due to slow mode
|
|
2024-08-25 09:40:59
|
Can the progressive dc frame itself have progressive dc?
|
|
|
|
_wb_
|
2024-08-25 09:42:23
|
Yes, up to 4 levels of recursion.
|
|
|
|
CrushedAsian255
|
2024-08-25 09:43:15
|
progressive_dc in cjxl goes from -1 to 2 though
|
|
|
|
_wb_
|
2024-08-25 09:45:12
|
Could be we didn't bother to do everything the spec allows, 2 levels is already enough for pretty huge images...
|
|
|
|
CrushedAsian255
|
2024-08-25 09:45:56
|
What is -1 then?
|
|
|
|
jonnyawsom3
|
2024-08-25 09:49:45
|
This is the thread I was thinking of https://discord.com/channels/794206087879852103/805176455658733570/1263418759629111356
|
|
|
|
A homosapien
|
|
CrushedAsian255
What is -1 then?
|
|
2024-08-25 10:06:02
|
-1 means the encoder automatically chooses
|
|
|
|
Quackdoc
|
2024-08-25 10:37:54
|
I just always enable progressive_dc, I have yet to find an image where it makes the file siz go up significantly
|
|
2024-08-25 10:53:38
|
sometimes on some images it just dies tho, ram hurts
|
|
|
|
veluca
|
2024-08-25 12:36:43
|
IIRC we had up to 4, but the encoder had some _issues_ with values >2
|
|
|
|
qdwang
|
|
still the same. The f32 version is smaller than the u16 version.
|
|
2024-08-25 04:39:08
|
This test runs under v0.10.3 and the current nightly main branch has different result on the test. The float32 jxl generated by main branch is much larger(about 3x in size) than the uint16 dump now. So I guess, the float32 compression in v0.10.3 has some issues in it.
|
|
|
|
_wb_
|
2024-08-25 04:41:26
|
Are both really lossless?
|
|
|
|
jonnyawsom3
|
|
This test runs under v0.10.3 and the current nightly main branch has different result on the test. The float32 jxl generated by main branch is much larger(about 3x in size) than the uint16 dump now. So I guess, the float32 compression in v0.10.3 has some issues in it.
|
|
2024-08-25 05:12:41
|
Maybe this? https://github.com/libjxl/libjxl/issues/3511
|
|
2024-08-25 05:15:34
|
Back when you mentioned getting similar filesize for your 16 and 32 files, I was going to suggest it could be getting paletted
|
|
|
|
qdwang
|
|
_wb_
Are both really lossless?
|
|
2024-08-25 05:24:17
|
Iโll check it later by decompressing the compressed lossless file.
|
|
|
Back when you mentioned getting similar filesize for your 16 and 32 files, I was going to suggest it could be getting paletted
|
|
2024-08-25 05:26:19
|
Could be. Iโll check if the 0.10.3 is the correct one
|
|
2024-08-25 06:05:22
|
I've done the test. The 0.10.3 version has the correct implementation.
`a.pfm --cjxl--> lossless.jxl --djxl--> b.pfm`
`a.pfm` and `b.pfm` are identical.
|
|
|
|
_wb_
|
2024-08-25 06:07:20
|
Both are probably correct, but current git head is no longer doing palette due to a security fix that went a bit too far...
|
|
|
|
qdwang
|
2024-08-25 06:09:47
|
All right. It seems a lot of changes since 0.10.3. Will the next version be v0.11?
|
|
|
|
_wb_
|
2024-08-25 06:11:23
|
That means that your RNG is producing a relatively sparse set of values, since the max number of palette colors is something like 70k
|
|
|
All right. It seems a lot of changes since 0.10.3. Will the next version be v0.11?
|
|
2024-08-25 06:12:04
|
Yes, when everyone is back from holidays I guess we will have a 0.11.0
|
|
|
|
jonnyawsom3
|
|
_wb_
That means that your RNG is producing a relatively sparse set of values, since the max number of palette colors is something like 70k
|
|
2024-08-25 06:19:20
|
Could be partially due to using 1024x1024 images, so there's less overall pixels for the values to differ
|
|
|
|
qdwang
|
|
_wb_
That means that your RNG is producing a relatively sparse set of values, since the max number of palette colors is something like 70k
|
|
2024-08-25 06:22:55
|
So can i set `JXL_ENC_FRAME_SETTING_PALETTE_COLORS` to enable the palette for the git-head version?
|
|
2024-08-25 06:24:06
|
I tried 65535, but it's not working.
|
|
|
|
_wb_
|
2024-08-25 06:24:49
|
No, current git version will just not try palette at all when bitdepth > 16, regardless of options
|
|
|
|
qdwang
|
|
_wb_
No, current git version will just not try palette at all when bitdepth > 16, regardless of options
|
|
2024-08-25 06:27:05
|
Will this feature be kept for the security fix in future releases?
|
|
2024-08-25 06:37:12
|
Oh, according to your reply here https://github.com/libjxl/libjxl/commit/27afa5e4c2e66d917746f407674369f19b6fca47
The palette will be back if you guys find a way to do it.
|
|
|
Demiurge
|
|
_wb_
Yes, up to 4 levels of recursion.
|
|
2024-08-25 08:32:00
|
How large can a single progressive DC "pixel"/point be with 4 levels of recursion?
|
|
2024-08-25 08:33:24
|
Iโm thinking of an absolutely massive image with progressive DC 4-level recursion...
|
|
|
|
_wb_
|
2024-08-25 08:33:27
|
First level DC "pixels" are 8x8, second level 64x64, third level 512x512 and fourth level 4096x4096.
|
|
2024-08-25 08:34:46
|
And then you can use progressive modular to encode the highest level, which basically means even if the 1:4096 image is large, you can still show _that_ progressively
|
|
|
|
Demiurge
|
2024-08-25 08:34:59
|
The 512 step is surprising?
|
|
|
|
_wb_
|
2024-08-25 08:35:25
|
It's just x8 at each level
|
|
|
|
Demiurge
|
2024-08-25 08:35:34
|
Progressive modular means squeeze transform right?
|
|
|
|
_wb_
|
|
|
Demiurge
|
2024-08-25 08:36:09
|
I couldn't find any papers about the squeeze transform...
|
|
2024-08-25 08:36:50
|
Is the only paper about it the jxl spec?
|
|
2024-08-25 08:37:22
|
Or book...
|
|
|
|
_wb_
|
2024-08-25 08:38:31
|
It's just a series of steps which consist of halving one dimension, e.g. reducing a W x H image to two W/2 x H images. One is the downsampled image, the other are residuals to reconstruct the original resolution image.
|
|
|
|
Demiurge
|
2024-08-25 08:40:45
|
seems kinda similar to the dwt in jp2k
|
|
|
|
_wb_
|
2024-08-25 08:41:58
|
It is, except the default squeeze script only applies the reduction recursively to the downsampled images, not to the residuals. So you get a laplacian pyramid, basically.
|
|
2024-08-25 08:47:10
|
One difference is that the residuals are defined in a somewhat weird way, with a nonlinearity. They effectively include linear prediction from a local neighborhood, but only if the local neighborhood is monotonic (e.g. a smooth gradient). If it's not monotonic (e.g. an edge), the prediction term gets zeroed. That means you don't get ringing/haloing around edges when quantizing the residuals, unlike J2K where you do get ringing if you quantize the wavelet coefficients...
|
|
|
|
Demiurge
|
2024-08-25 09:45:12
|
That's clever. But I thought the squeeze transform was simpler compared to the j2k one?
|
|
|
|
Traneptora
|
2024-08-25 10:34:39
|
<@386612331288723469> just a note, `truncate --size=foo file.jxl` accoplishes what you want
|
|
|
Demiurge
That's clever. But I thought the squeeze transform was simpler compared to the j2k one?
|
|
2024-08-25 10:35:46
|
it's still wavelet based but it's haar wavelets which is the simplest kind of wavelet
|
|
|
|
CrushedAsian255
|
|
Traneptora
<@386612331288723469> just a note, `truncate --size=foo file.jxl` accoplishes what you want
|
|
2024-08-25 10:40:28
|
im wanting duplicates, not overwrite the original file
|
|
|
|
Traneptora
|
2024-08-25 10:41:02
|
`cp && truncate`
|
|
2024-08-25 10:41:16
|
if you have a COW filesystem it'll be much faster
|
|
2024-08-25 10:41:39
|
if you don't, then, dunno about performance compared to `head -c`
|
|
|
|
CrushedAsian255
|
|
Traneptora
if you have a COW filesystem it'll be much faster
|
|
2024-08-25 10:42:06
|
APFS is COW, i'm gonna go benchmark
|
|
2024-08-25 10:42:19
|
most of the time is spent in `jxl-oxide` though
|
|
|
|
Traneptora
|
2024-08-25 10:42:20
|
provided `cp` can take advantage of the COW features, that is
|
|
2024-08-25 10:42:29
|
it's probably not a big deal, realistically speaking
|
|
|
|
CrushedAsian255
|
2024-08-25 10:43:14
|
nvm `cp` on macOS can't COW
|
|
|
|
Demiurge
|
2024-08-25 10:43:19
|
`head` is great
|
|
|
|
CrushedAsian255
|
|
|
Traneptora
|
2024-08-25 10:43:45
|
so then yea it'll be about the same then most likely
|
|
|
|
CrushedAsian255
|
2024-08-25 10:43:45
|
`cp: tst.mkv: fcopyfile failed: No space left on device`
|
|
|
|
Traneptora
|
|
|
Demiurge
|
2024-08-25 10:44:50
|
Just use `head -c $SIZE <in.jxl >out.jxl`
|
|
|
|
Traneptora
|
2024-08-25 10:45:01
|
that is what they are doing
|
|
2024-08-25 10:45:06
|
I was suggesting an alternative
|
|
2024-08-25 10:45:13
|
also `"$SIZE"`
|
|
2024-08-25 10:45:19
|
QEFS
|
|
2024-08-25 10:45:29
|
Quote Every F Substitution
|
|
|
|
Demiurge
|
2024-08-25 10:45:38
|
yes lol
|
|
|
|
CrushedAsian255
|
2024-08-25 10:46:05
|
i don't think anyone is setting their $SIZE to `3; rm -rf --no-preserve-root / #`
|
|
2024-08-25 10:46:27
|
it's automatically set from `$(wc -c < "$INPUT")`
|
|
|
|
Traneptora
|
2024-08-25 10:46:30
|
always quote every substitution because at some point something will fuck up
|
|
|
|
Demiurge
|
2024-08-25 10:46:39
|
yup lol
|
|
|
|
CrushedAsian255
|
|
Traneptora
always quote every substitution because at some point something will fuck up
|
|
2024-08-25 10:46:47
|
when i'm writing an actual script i do, this is just a quick and dirty test script
|
|
|
|
Demiurge
|
2024-08-25 10:46:49
|
Always quote
|
|
|
|
Traneptora
|
2024-08-25 10:47:00
|
no reason to use bad practices if you are aware of the good ones ยฏ\_(ใ)_/ยฏ
|
|
|
|
CrushedAsian255
|
2024-08-25 10:47:03
|
"Always quote"
\- <@1028567873007927297>, 2024
|
|
|
|
Demiurge
|
2024-08-25 10:47:04
|
I just wasn't thinking about quoting because I wasn't thinking of $SIZE as an actual macro
|
|
2024-08-25 10:47:19
|
I was thinking of it as a placeholder for you typing what you want there
|
|
|
|
Traneptora
|
2024-08-25 10:47:20
|
understandable
|
|
|
|
Demiurge
|
2024-08-25 10:48:48
|
But yeah forgetting to put quote marks is dangerous in Bourne shell
|
|
2024-08-25 10:49:33
|
It's not a really good script/utility language, that's why people made perl :)
|
|
|
|
CrushedAsian255
|
2024-08-25 10:50:48
|
just tested, macOS supports `cp -c` for CoW copy
|
|
2024-08-25 10:50:58
|
and ends up going from `10s` to `1.3s`
|
|
2024-08-25 10:51:09
|
so it does end up helping
|
|
2024-08-25 10:51:25
|
might also help with my SSD's wear levelling
|
|
|
|
Quackdoc
|
2024-08-25 11:28:20
|
team never quote, if I need quotes, i'm just not escaping hard enough
|
|
2024-08-25 11:28:22
|
[chad](https://cdn.discordapp.com/emojis/1070464111114211439.webp?size=48&quality=lossless&name=chad)
|
|
|
|
CrushedAsian255
|
2024-08-26 12:00:07
|
when i was dabbling in webdev, i would store all user inputted data as Base64 to prevent SQL injections :/
|
|
|
|
DNFrozen
|
2024-08-26 10:20:05
|
of cause my code always follows best practices
|
|
2024-08-26 10:20:07
|
https://cdn.discordapp.com/attachments/934832009015078912/941582841093951488/unknown.png?ex=66cd735b&is=66cc21db&hm=5a0f95b120eb48a98ced613701fece0328e004835da8e8138fa674524bbc4503&
|
|
|
|
CrushedAsian255
|
2024-08-26 10:21:01
|
is this like some hella optimised or just obfuscated?
|
|
|
|
DNFrozen
|
2024-08-26 10:21:39
|
i tried to optimize my pacman AI to the limit
|
|
2024-08-26 10:22:42
|
this is actually just a breadth search that finds the closes path to each field
|
|
|
|
CrushedAsian255
|
2024-08-26 10:22:51
|
at this point it would probably just be more readable as inline asm
|
|
2024-08-26 10:23:29
|
unless your language doesn't support that or you want cross-platform
|
|
|
|
DNFrozen
|
2024-08-26 10:24:05
|
i mean do you really have to make multiple variables if you can just use every bit of your ints for different stuff?
|
|
|
|
CrushedAsian255
|
2024-08-26 10:24:56
|
does this actually help with performance?
|
|
2024-08-26 10:25:19
|
like is it really important that your pathfinding runs in 0.4 microseconds instead of 0.9 microseconds?
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
is this like some hella optimised or just obfuscated?
|
|
2024-08-26 10:27:02
|
Gives me flashbacks to a virus me and some people were reverse engineering yesterday
|
|
|
|
DNFrozen
|
2024-08-26 10:27:08
|
it did at my i5 cpu at the time. but now with bigger 3d cache it might not ๐คทโโ๏ธ
and no in the end it wasn't really nessesaary but i got obsessed and spend a lot of time thinking how to make it faster
|
|
2024-08-26 10:28:36
|
oh and it was a team project ๐ but since it worked nobody needed to touch the code
|
|
2024-08-26 10:29:50
|
i doubt anyone could actually reverse engineer that thing without any clues
|
|
|
|
CrushedAsian255
|
|
DNFrozen
oh and it was a team project ๐ but since it worked nobody needed to touch the code
|
|
2024-08-26 10:29:52
|
|
|
|
|
Managor
|
2024-08-26 04:06:45
|
I'm thinking of creating [tldr](https://github.com/tldr-pages/tldr) pages for commands like `cjxl` and the like. What are commonly used commands?
|
|
|
|
jonnyawsom3
|
2024-08-26 04:21:21
|
The most common one is probably `cjxl -d 0 -e 9 -g 3 -E 11 -I 100` for reasonably fast speed with a boost to compression (I think most actually use `-e 10` but that's singlethreaded
|
|
|
|
Managor
|
2024-08-26 04:28:29
|
Dang, that's a lot of options
|
|
2024-08-26 04:32:11
|
What effort level is the default?
|
|
2024-08-26 04:32:23
|
I try to make these commands as newbie friendly as possible
|
|
|
|
jonnyawsom3
|
2024-08-26 04:34:00
|
Default is 7 and lossy, except for jpeg or GIF
|
|
|
|
Managor
|
2024-08-26 04:38:00
|
`-g`, `-E` and `-I` are not documented on the man page
|
|
2024-08-26 04:53:38
|
I made a quick and dirty starting point https://github.com/tldr-pages/tldr/pull/13513
|
|
|
|
jonnyawsom3
|
|
Managor
`-g`, `-E` and `-I` are not documented on the man page
|
|
2024-08-26 05:02:30
|
If you run `cjxl -h -v -v -v -v` (Horrifying I know), there's plenty of info about the arguments you could try and condense down to a useful list, with the help of others suggestions here too
|
|
|
|
Managor
|
2024-08-26 05:03:43
|
What the fuck is that and why does it not accept `-hvvvv`?
|
|
|
|
jonnyawsom3
|
2024-08-26 05:04:46
|
https://github.com/libjxl/libjxl/issues/3742
|
|
2024-08-26 05:05:39
|
I don't entirely remember why combined commands aren't accepted, but I know the v's got added because the help list was far too large for the average user
|
|
|
|
_wb_
|
2024-08-26 05:20:13
|
What you get with `cjxl -h` should be enough for normal users
|
|
|
|
Managor
|
2024-08-26 05:29:24
|
I like to consider tldr as a mix of most commonly used commands and tips and tricks.
`cjxl -h -v -v -v -v` sort of documents `cjxl -h`
|
|
|
Orum
|
2024-08-26 06:40:15
|
I'm glad my argument bundling request was closed over 2 years ago without actually being implemented, "...since it will not be relevant anymore pretty soon."
|
|
|
|
_wb_
|
2024-08-26 06:43:14
|
Can you reopen it?
|
|
2024-08-26 06:43:26
|
Even better would be a pull request that makes it work ๐
|
|
|
|
Orum
|
2024-08-26 06:47:27
|
I don't think I have permission to reopen it? https://github.com/libjxl/libjxl/issues/524
|
|
2024-08-26 06:47:43
|
and I suppose I can make a PR if required
|
|
2024-08-26 06:48:00
|
will take me a bit though since I won't be home for a while
|
|
|
|
_wb_
|
2024-08-26 07:48:21
|
Reopened it.
|
|
|
|
Managor
|
2024-08-26 08:17:21
|
Are there any common or special commands for `djxl`?
|
|
|
|
_wb_
|
2024-08-26 08:23:33
|
--bits_per_sample can be useful, e.g. to decode a nominally 8-bit image to 16-bit.
|
|
|
|
jonnyawsom3
|
|
Quackdoc
sometimes on some images it just dies tho, ram hurts
|
|
2024-08-26 08:42:24
|
I tried using the progressive DC and realised, the DC frames are probably being encoded in the standard way instead of the more recent chunked method since they use Modular, right? Explains turning single threaded and the large memory increase
|
|
|
|
CrushedAsian255
|
|
The most common one is probably `cjxl -d 0 -e 9 -g 3 -E 11 -I 100` for reasonably fast speed with a boost to compression (I think most actually use `-e 10` but that's singlethreaded
|
|
2024-08-26 09:16:30
|
-E 11? Why 11?
|
|
2024-08-26 09:16:57
|
Also for some reason this one image did best with -I 28 ( I brute forced)
|
|
|
|
jonnyawsom3
|
|
CrushedAsian255
-E 11? Why 11?
|
|
2024-08-26 09:19:32
|
Pretty sure it's just the maximum, even though you generally only have 3 or 4 channels anyway
|
|
|
|
Managor
|
|
_wb_
--bits_per_sample can be useful, e.g. to decode a nominally 8-bit image to 16-bit.
|
|
2024-08-26 11:05:05
|
Can you give a full example command?
|
|
|
|
_wb_
|
2024-08-27 06:24:34
|
djxl input.jxl output.png --bits_per_sample=16
|
|
|
|
monad
|
|
_wb_
Reopened it.
|
|
2024-08-27 06:34:57
|
surely we only need one https://github.com/libjxl/libjxl/issues/3742
|
|
2024-08-27 06:36:07
|
and surely it should just be `-h -v`
|
|
|
The most common one is probably `cjxl -d 0 -e 9 -g 3 -E 11 -I 100` for reasonably fast speed with a boost to compression (I think most actually use `-e 10` but that's singlethreaded
|
|
2024-08-27 06:50:36
|
there's no way most people are melting their CPUs to compress images. most just run default, or lower effort if required
|
|
|
|
Demiurge
|
|
https://github.com/libjxl/libjxl/issues/3742
|
|
2024-08-27 07:29:20
|
Because cjxl doesn't use a standard-conforming argument parsing library like getopt, it rolls its own weirdness
|
|
2024-08-27 07:29:37
|
Whoops, replied to the wrong message
|
|
|
Managor
What the fuck is that and why does it not accept `-hvvvv`?
|
|
2024-08-27 07:29:51
|
Meant to reply to this
|
|
2024-08-27 07:30:39
|
imo there should only be one -v to show everything
|
|
2024-08-27 07:31:04
|
or at least a -v 1 or -v 2 -v 3 -v 4 for different levels of -v
|
|
2024-08-27 07:31:13
|
but that's still dumber than just having 1 level
|
|
|
|
_wb_
|
|
monad
there's no way most people are melting their CPUs to compress images. most just run default, or lower effort if required
|
|
2024-08-27 07:31:19
|
In my view, a good codec should not get in your way. It should not take noticeable time to encode/decode and it should be either lossless or visually lossless. Basically you shouldn't have to worry about it, so you can focus on the images and not on the technology behind them.
|
|
|
|
Demiurge
|
2024-08-27 07:32:09
|
100% agreed. But then why does djxl use the slowest libpng settings possible when decoding to png? even oxipng is faster.
|
|
2024-08-27 07:47:55
|
loads of people have the mistaken impression that jxl is extremely slow to decode, and they have no idea that it's libpng taking up all the time... Surely it would be trivial to add a `png_set_compression_level` to `APNGEncoder::EncodePackedPixelFileToAPNG`
|
|
2024-08-27 07:48:23
|
Since I would guess most of the time is spent in zlib.
|
|
|
|
CrushedAsian255
|
2024-08-27 07:52:02
|
What is the best way to edit JPEG XL Exif metadata?
Exiftool just gives `Error decoding 'Exif' brob box`
|
|
|
|
Demiurge
|
2024-08-27 08:14:45
|
You probably need to install the perl brotli module
|
|
|
|
CrushedAsian255
|
2024-08-27 08:22:00
|
where do i put the folder?
|
|
|
Demiurge
You probably need to install the perl brotli module
|
|
2024-08-27 08:25:15
|
does Exiftool let you write tags to JXLs?
|
|
|
|
Demiurge
|
2024-08-27 08:30:05
|
it can definitely view exif tags...
|
|
2024-08-27 08:30:52
|
I haven't tried writing tags
|
|
|
|
_wb_
|
|
Demiurge
loads of people have the mistaken impression that jxl is extremely slow to decode, and they have no idea that it's libpng taking up all the time... Surely it would be trivial to add a `png_set_compression_level` to `APNGEncoder::EncodePackedPixelFileToAPNG`
|
|
2024-08-27 08:30:58
|
Feel free to make a pull request that does that!
|
|
2024-08-27 08:34:56
|
If adoption goes well, most people would not use jxl by means of cjxl/djxl and intermediate PNG files. In fact PNG could become a legacy format at some point. But for now of course PNG is still a very useful interchange format.
|
|
|
|
Demiurge
|
2024-08-27 08:36:18
|
I will, once I have my main PC plugged in again...
|
|
2024-08-27 08:38:15
|
PNG is theoretically a much worse interchange format than JXL. Lacking support for associated alpha for example. It just plain can't store a lot of image data.
|
|
2024-08-27 08:38:43
|
Hopefully JXL will be the new PNG some day
|
|
|
CrushedAsian255
does Exiftool let you write tags to JXLs?
|
|
2024-08-27 08:41:03
|
Found this for you:
https://exiftool.org/forum/index.php?topic=15677.0
|
|
|
CrushedAsian255
where do i put the folder?
|
|
2024-08-27 08:50:07
|
depends on how you installed perl...
|
|
|
|
DNFrozen
|
2024-08-27 08:53:45
|
ok I'm done converting all my jpg and png files to jxl (lossless recompression for jpg and lossless format for png)
overall i saved about 56.5GB disk (files got about 10% smaller on average)
|
|
|
|
monad
|
2024-08-27 08:56:51
|
good work
|
|
|
|
jonnyawsom3
|
2024-08-27 08:57:05
|
That seems surprisingly low... Considering jpegs should be 20% at minimum and PNGs are usually nearer 40%
|
|
|
|
DNFrozen
|
2024-08-27 09:20:13
|
i forgott to check the "delete original" checkbox in the converter
but i thought hey all i need to do is open the folder in explorer search for ".jpg" hit ctrl+a and then delete....
|
|
2024-08-27 09:20:15
|
|
|
2024-08-27 09:20:21
|
|
|
2024-08-27 09:20:45
|
yeah this won't work... i need a script
|
|
|
|
username
|
2024-08-27 09:21:49
|
wait what part of that process is doing that? searching? selecting? or deleting?
|
|
|
|
DNFrozen
|
2024-08-27 09:23:33
|
i managed to reach the point where i hit the delete key
now there should have been a confirmaation windows where i say yes but that never appeared
not sure when ram hit the limit. when i checked it it was already full
|
|
2024-08-27 09:24:34
|
even the search process so so long that i just left it alone and checked again after like 2-3 hours
|
|
|
|
username
|
2024-08-27 09:24:53
|
uhh try this maybe? https://www.voidtools.com/ it's genuinely one of the most useful and well written programs I have ever used in my life
|
|
|
|
DNFrozen
|
2024-08-27 09:25:43
|
afew lines of java code are already working cleaning up the mess
|
|
|
|
monad
|
2024-08-27 09:25:51
|
dude, you remembered to verify the data, yes? libjxl can't recompress all jpgs
|
|
|
|
DNFrozen
|
2024-08-27 09:26:40
|
i did the conversion on a copy of the data on a different drive
|
|
2024-08-27 09:27:16
|
but how can i check if all images are ok? open them one by one is not an option
|
|
|
|
username
|
2024-08-27 09:28:08
|
as long as the count of JXLs matches the count of PNGs + JPEGs that should be enough to confirm that nothing failed to write
|
|
|
|
DNFrozen
|
2024-08-27 09:28:47
|
oh yeah the numbers match
|
|
2024-08-27 09:33:39
|
but is there a programm that can check if a jxl file is a valid working image?
seems like something that could be usefull at some point
|
|
|
|
monad
|
2024-08-27 09:37:03
|
i'm not good at windows, so can't give a specific solution, but for jpgs you can transcode back and do binary compare, for other formats you can decode and do pixel compare
|
|
|
|
Demiurge
|
|
DNFrozen
but how can i check if all images are ok? open them one by one is not an option
|
|
2024-08-27 09:38:24
|
If you are writing a script, you could check the process return code is zero. And then, before deleting the original, you could try decoding the jxl and compare it to the original first. For jpg check if the files match. For other lossless files compare the pixel data.
|
|
|
DNFrozen
but is there a programm that can check if a jxl file is a valid working image?
seems like something that could be usefull at some point
|
|
2024-08-27 09:40:49
|
You could try `djxl --disable_output`
|
|
|
|
DNFrozen
|
2024-08-27 09:40:57
|
actually pixel compare should work for both since all i did with jpgs was lossless recompression
|
|
|
|
Demiurge
|
|
DNFrozen
actually pixel compare should work for both since all i did with jpgs was lossless recompression
|
|
2024-08-27 09:41:16
|
no, you can't, since jpeg doesn't store pixel data
|
|
|
|
monad
|
2024-08-27 09:41:18
|
the decoders will make different decisions
|
|
|
|
Demiurge
|
2024-08-27 09:41:41
|
jpeg stores 8x8 macroblock DCT coefficient data, not pixel data.
|
|
2024-08-27 09:41:55
|
If you compare pixels you will get different results from different decoders.
|
|
|
|
DNFrozen
|
2024-08-27 09:43:57
|
different decoders get different pixel values for the same jpg input?
i did not know that. it seems strange for me that there is room for different interpretations
|
|
|
|
Demiurge
|
2024-08-27 09:44:11
|
if a jxl file can't be decoded then I think djxl will probably return a nonzero exit status
|
|
|
DNFrozen
different decoders get different pixel values for the same jpg input?
i did not know that. it seems strange for me that there is room for different interpretations
|
|
2024-08-27 09:44:23
|
yes
|
|
|
|
_wb_
|
2024-08-27 09:44:40
|
You can do something like `compare -metric psnr original_image decoded.jxl.png null:` and check that it is above 35 or so, that should work for both jpegs and pngs
|
|
|
|
Demiurge
|
2024-08-27 09:45:43
|
JPEG doesn't actually store any pixels. It converts DCT coefficients into 8x8 pixel blocks. And different decoders reconstruct the pixels from the coefficients differently.
|
|
|
dkam
|
2024-08-27 09:45:54
|
Hello, I recently started experimenting with Ubuntu 2404 as my primary desktop. Can anyone recommend a browser and an Image Viewer which supports JXL? It seems FF doesn't work even when setting the flag in about:config
|
|
|
|
_wb_
|
2024-08-27 09:46:14
|
JPEG decoders are allowed to be somewhat inaccurate. Libjpeg-turbo sacrifices some accuracy for speed.
|
|
|
|
Demiurge
|
|
_wb_
You can do something like `compare -metric psnr original_image decoded.jxl.png null:` and check that it is above 35 or so, that should work for both jpegs and pngs
|
|
2024-08-27 09:47:12
|
ideally you could have magick decode the jxl if you do it that way.
|
|
|
dkam
Hello, I recently started experimenting with Ubuntu 2404 as my primary desktop. Can anyone recommend a browser and an Image Viewer which supports JXL? It seems FF doesn't work even when setting the flag in about:config
|
|
2024-08-27 09:47:50
|
Pale moon or waterfox.
|
|
|
|
username
|
|
dkam
Hello, I recently started experimenting with Ubuntu 2404 as my primary desktop. Can anyone recommend a browser and an Image Viewer which supports JXL? It seems FF doesn't work even when setting the flag in about:config
|
|
2024-08-27 09:48:35
|
for FF based forks there is mainly [Waterfox](https://www.waterfox.net/) and [Floorp](https://floorp.app/) and for something Chromium based there is [Thorium](https://thorium.rocks/)
|
|
|
|
monad
|
|
dkam
Hello, I recently started experimenting with Ubuntu 2404 as my primary desktop. Can anyone recommend a browser and an Image Viewer which supports JXL? It seems FF doesn't work even when setting the flag in about:config
|
|
2024-08-27 09:48:55
|
<https://github.com/libjxl/libjxl/blob/main/doc/software_support.md>
I went the Qt route for viewing.
|
|
|
|
Demiurge
|
2024-08-27 09:50:10
|
There is also a gdk-pixbuf plugin for libjxl
|
|
|
|
dkam
|
2024-08-27 09:50:15
|
Awesome - thank you!
|
|
|
|
Demiurge
|
2024-08-27 09:50:58
|
I recommend KDE/Plasma for new linux users for sure. plasma is just getting better and gnome is just stagnating.
|
|
|
|
dkam
|
2024-08-27 09:51:31
|
In the olden days, I used Gentoo as a desktop and I think it was mostly xfce or kde back then.
|
|
|
|
Demiurge
|
2024-08-27 09:51:36
|
but that's just my opinion. speaking of stagnation, I wouldn't recommend debian either.
|
|
2024-08-27 09:52:32
|
gentoo seems nice in theory but I haven't had time to try it yet.
|
|
2024-08-27 09:52:46
|
:)
|
|
|
|
dkam
|
2024-08-27 09:54:24
|
I was a linux admin at the time and even I found it hard work for a desktop environment. Constant recompiling of the ... well, everything! ๐
|
|
2024-08-27 09:54:43
|
So many distros now. Bazzite looks pretty sweet for gaming.
|
|
|
|
Demiurge
|
2024-08-27 09:55:07
|
The reason why you don't have an up to date version of libjxl and gdk-pixbuf-loader etc on your debian/ubuntu system is because of such stagnation and ill conceived ideas... Luckily on ubuntu I think there is a PPA you can use.
|
|
|
|
dkam
|
2024-08-27 09:55:32
|
It drives me crazy that FF are refusing to support it.
|
|
|
|
HCrikki
|
|
dkam
Hello, I recently started experimenting with Ubuntu 2404 as my primary desktop. Can anyone recommend a browser and an Image Viewer which supports JXL? It seems FF doesn't work even when setting the flag in about:config
|
|
2024-08-27 09:56:59
|
the gnome viewers (eye of gnome and its successor loupe) decode jxl as long as libjxl is installed.
ubuntu used to have it out of the box until Full install and Minimal install got swapped and Minimal became the new default
|
|
|
|
dkam
|
2024-08-27 09:57:46
|
Does libjxl need a ppa?
|
|
|
|
HCrikki
|
2024-08-27 09:58:19
|
for firefox you can just use a rebuild or derivative. it'll have better default options out of the box and less frustrating to tweak than mozilla's releases of firefox
|
|
|
|
Demiurge
|
|
dkam
Does libjxl need a ppa?
|
|
2024-08-27 09:58:24
|
I don't know... On ubuntu, almost everything needs a PPA because literally almost everything is out of date.
|
|
2024-08-27 09:58:58
|
because it's debian, and for debian, not being able to update is considered a feature
|
|
|
|
HCrikki
|
2024-08-27 09:58:58
|
word of warning. librewolf does not have proper jxl support, all it ships is the bad jxl support from firefox nightly. floorp is based on esr128 and a really good one if waterfox isnt your thing (iinm waterfox rebased itself on floorp at some point). rebuilds and derivatives deserve more support, thatll show distros that mozilla's releases full of compromises and degraded privacy are disliked and they ought to consider shipped 'firefox but fixed' instead
|
|
|
|
dkam
|
2024-08-27 10:03:14
|
Installed libjxl-devtools and libjxl-tools, but eog still doesn't seem to open jxl.
|
|
2024-08-27 10:03:35
|
I'll give Floorp a go. Sounds like a browser from Rick & Morty.
|
|
|
|
HCrikki
|
2024-08-27 10:04:22
|
check the version numbers for all that
|
|
|
|
username
|
|
HCrikki
word of warning. librewolf does not have proper jxl support, all it ships is the bad jxl support from firefox nightly. floorp is based on esr128 and a really good one if waterfox isnt your thing (iinm waterfox rebased itself on floorp at some point). rebuilds and derivatives deserve more support, thatll show distros that mozilla's releases full of compromises and degraded privacy are disliked and they ought to consider shipped 'firefox but fixed' instead
|
|
2024-08-27 10:04:39
|
waterfox has never been based on floorp, everything else you said is right though.
|
|
|
|
HCrikki
|
2024-08-27 10:05:26
|
i recall some rebuild absolutely considering rebasing on floorp, maybe i got the names fixed
|
|
|
|
DNFrozen
|
|
Demiurge
JPEG doesn't actually store any pixels. It converts DCT coefficients into 8x8 pixel blocks. And different decoders reconstruct the pixels from the coefficients differently.
|
|
2024-08-27 10:05:50
|
so i gues after recompression jpgxl is doing the same something very similar?
and are the decoder differences are essentially just rounding errors because one decoder puts less effort into getting the exact correct value that the other?
|
|
|
|
username
|
|
HCrikki
i recall some rebuild absolutely considering rebasing on floorp, maybe i got the names fixed
|
|
2024-08-27 10:10:02
|
Midori or FireDragon maybe?
|
|
|
|
HCrikki
|
2024-08-27 10:12:19
|
stick to known id say
|
|
2024-08-27 10:14:41
|
some flatpaks have integrated jxl but its hard to track. most of the time its passively obtained from an update to their libraries or just not mentioned in changelogs
|
|
|
|
dkam
|
2024-08-27 10:15:31
|
"Some of Floorp's security features may offer less protection on your current operationg system. How to fix this issue" - which leads to instructions on how to install firefox ๐ฏ
|
|
|
|
username
|
2024-08-27 10:17:22
|
a lot of stuff in Firefox ties back to well Firefox so when there's a fork of Firefox there usually ends up being a bunch of places that still point back to or reference Firefox
|
|
|
|
HCrikki
|
2024-08-27 10:21:00
|
some text messages and links still mention firefox (like when you uninstall) or lead to mozilla links, nothing big. its still firefox with extras and some changes, a difference everyone can handle fine
|
|
2024-08-27 10:24:40
|
afaik that warning message is releated to apparmor/selinux but different distros ship or or the other (other is always missing). fixed in current 11.17.7
|
|
2024-08-27 10:26:35
|
apparmor is pretty much an ubuntu exclusive at this point, thats why snaps lack sandboxing on other distros that use selinux
|
|
|
|
Demiurge
|
|
DNFrozen
so i gues after recompression jpgxl is doing the same something very similar?
and are the decoder differences are essentially just rounding errors because one decoder puts less effort into getting the exact correct value that the other?
|
|
2024-08-27 10:26:55
|
yes
|
|
|
|
monad
|
|
DNFrozen
so i gues after recompression jpgxl is doing the same something very similar?
and are the decoder differences are essentially just rounding errors because one decoder puts less effort into getting the exact correct value that the other?
|
|
2024-08-27 10:27:01
|
lossy jxl works similarly to jpeg, but with more flexibility. it can represent jpeg coefficients exactly, just coding more efficiently. the spec isn't exacting, so there's no exact correct set of decoded pixels. some decoders may do the math more precisely (libjxl for example) or will attempt to make more appealing decisions, but most will do things cheaply.
|
|
|
|
DNFrozen
|
2024-08-27 10:32:20
|
do CPUs on PC or Android have dedicated areas that decode existing standards like png and jpg faster and more efficent so that the existing standards an advatage for now?
|
|
|
|
Demiurge
|
|
DNFrozen
do CPUs on PC or Android have dedicated areas that decode existing standards like png and jpg faster and more efficent so that the existing standards an advatage for now?
|
|
2024-08-27 10:34:04
|
no.
|
|
2024-08-27 10:35:07
|
JPEG is just really really simple to decode and people have written really good decoders that take advantage of vector math and pipelines in modern CPUs
|
|
2024-08-27 10:35:35
|
PNG is a different story. It's a lot harder to decode compared to JPEG.
|
|
2024-08-27 10:37:07
|
It's a pretty simple format but there are a few minor details that are big oversights that prevent it from being as fast as JPEG.
|
|
2024-08-27 10:38:46
|
libjxl is pretty well optimized in some areas, but there's still a little bit of room left for further speed
|
|
|
|
jonnyawsom3
|
2024-08-27 10:39:00
|
NVIDIA did add jpeg acceleration on their datacentre GPUs for AI training, but nothing for consumers because it just isn't worth it
|
|
|
|
DNFrozen
|
2024-08-27 10:42:44
|
speaking of AI i came across this article that mentions stable diffusion image compression and it looked interesting
https://towardsai.net/p/l/stable-diffusion-based-image-compresssion
but as far as i can tell it's just a research project and not something that you can test yourself
|
|
|
|
Demiurge
|
|
DNFrozen
speaking of AI i came across this article that mentions stable diffusion image compression and it looked interesting
https://towardsai.net/p/l/stable-diffusion-based-image-compresssion
but as far as i can tell it's just a research project and not something that you can test yourself
|
|
2024-08-27 10:51:03
|
ML-based compression would be pretty good for extremely low bitrate images... but, if we return to the real world for a moment, everything actually has a cost. the neural network takes up a lot of disk space itself. The decoding process is extremely resource-costly compared to a normal image codec. And the actual reconstructed image is prone to "hallucinations" that were not in the original. You can see it in the camel image if you look carefully at the fence
|
|
2024-08-27 10:52:42
|
Until those problems are completely solved and overcome, ML codecs will be an extremely niche thing.
|
|
2024-08-27 10:56:42
|
Look at the text on the blue polyester harness
|
|
|
|
Traneptora
|
|
DNFrozen
speaking of AI i came across this article that mentions stable diffusion image compression and it looked interesting
https://towardsai.net/p/l/stable-diffusion-based-image-compresssion
but as far as i can tell it's just a research project and not something that you can test yourself
|
|
2024-08-27 11:13:45
|
stable diffusion is basically running an inverse problem on random noise
|
|
|
|
Oleksii Matiash
|
|
DNFrozen
i forgott to check the "delete original" checkbox in the converter
but i thought hey all i need to do is open the folder in explorer search for ".jpg" hit ctrl+a and then delete....
|
|
2024-08-27 11:24:45
|
Discover TotalCommander ๐ Or a script, yes, but in that case make sure it deletes immediately, not moving to recycle bin
|
|
|
|
Demiurge
|
|
DNFrozen
i forgott to check the "delete original" checkbox in the converter
but i thought hey all i need to do is open the folder in explorer search for ".jpg" hit ctrl+a and then delete....
|
|
2024-08-27 11:26:26
|
what converter are you using anyways?
|
|
|
|
DNFrozen
|
2024-08-27 11:26:55
|
XL Converter
|
|
|
|
Demiurge
|
2024-08-27 11:27:15
|
I hear good things about that one
|
|
2024-08-27 11:27:44
|
It looks cool
|
|
|
|
DNFrozen
|
2024-08-27 11:28:54
|
the interface is nice. but the effort values max out at 9 and I've heard here that there is also 10 and 11 option for conversion
|
|
|
|
username
|
2024-08-27 11:29:32
|
also from what I have seen it defaults to stripping metadata by default which I personally think is a very bad idea
|
|
|
|
CrushedAsian255
|
|
DNFrozen
the interface is nice. but the effort values max out at 9 and I've heard here that there is also 10 and 11 option for conversion
|
|
2024-08-27 11:30:04
|
10 and 11 are so slow they're barely worth it unless you're experimenting
|
|
2024-08-27 11:30:16
|
i guess 10 has some purpose but 11 is just silly
|
|
|
|
DNFrozen
|
2024-08-27 11:30:37
|
maybe it's a bad default but my goal was to make it as small as possible so i would have choosen that anyway
|
|
|
|
Oleksii Matiash
|
2024-08-27 11:30:49
|
Here is another GUI https://github.com/kampidh/jxl-batch-converter
|
|
|
|
CrushedAsian255
|
|
DNFrozen
maybe it's a bad default but my goal was to make it as small as possible so i would have choosen that anyway
|
|
2024-08-27 11:30:59
|
-e 11 takes like 10 minutes to compress a single image, it's the "send to Jon Sneyers to hand-compress for you" level
|
|
|
|
Oleksii Matiash
|
|
CrushedAsian255
10 and 11 are so slow they're barely worth it unless you're experimenting
|
|
2024-08-27 11:31:54
|
For jpeg recompression e10 is fast enough to use
|
|
|
|
CrushedAsian255
|
|
Oleksii Matiash
For jpeg recompression e10 is fast enough to use
|
|
2024-08-27 11:32:17
|
for JPEG recompression, yeah
|
|
|
|
DNFrozen
|
2024-08-27 11:32:37
|
mmh 10min*1000000+ images would take a while
|
|
2024-08-27 11:33:32
|
even so a voice in my head is now screaming "do it"
|
|
|
|
CrushedAsian255
|
2024-08-27 11:34:14
|
i have around 30k images, not leaving my computer on for 2/3 of a year
|
|
2024-08-27 11:34:34
|
i haven't actually tested the speed for -e 11 on JPEG recompression,
|
|
2024-08-27 11:34:46
|
guessing it wouldn't be as bad as pixel to jxl compression
|
|