|
_wb_
|
2023-07-06 08:46:04
|
(first do 3-channel Palette to make a 4-bit index channel, then do one horizontal Squeeze step that makes two channels of half the width, then do a 2-channel Palette on that to get a single channel that is roughly 8-bit — not quite because of the tendency term in Squeeze, but probably close enough)
|
|
|
username
|
|
monad
add `--brotli_effort 11` to beat e10, and beat WebP for second image
|
|
2023-07-06 03:24:28
|
the original image does not have metadata however Discord adds garbage metadata to the file causing JXL to lose a bit of size since cjxl tries to store the metadata while WebP with cwebp discards it unless you go through a bunch of steps to preserve it
|
|
|
|
jxl
|
2023-07-06 05:13:14
|
if firefox was truly "neutral" wouldnt they add jxl support behind a flag though
|
|
|
elfeïn
|
2023-07-06 05:13:48
|
ohhh you mean like
|
|
2023-07-06 05:14:24
|
I thought they had it and you were saying, "They have it, but neutral would mean putting it behind a flag instead of allowing it by default >:C"
|
|
2023-07-06 05:14:34
|
I was like, whaaa
|
|
|
|
jxl
|
2023-07-06 05:15:02
|
wait
|
|
2023-07-06 05:15:07
|
there's `image.jxl.enabled` in nightly
|
|
|
derberg
|
2023-07-06 05:15:27
|
Yeah but only nightly
|
|
|
|
elfeïn
|
2023-07-06 05:15:36
|
also how petty do they have to be to be neutral about a free image standard
|
|
|
w
|
2023-07-06 05:15:57
|
Firefox is google
|
|
|
|
derberg
|
2023-07-06 05:19:29
|
They are that neutral that there is no obvious way to discuss adding the format to Firefox
|
|
2023-07-06 05:19:40
|
What I found got closed.
|
|
2023-07-06 05:19:59
|
Are discussions supposed to happen in some random Matrix room or mailing list nobody knows about?
|
|
|
|
username
|
2023-07-06 05:20:42
|
the closest place I can think of is here: https://connect.mozilla.org/t5/ideas/support-jpeg-xl/idi-p/18433
|
|
|
|
w
|
2023-07-06 05:21:05
|
there's a chatroom
|
|
|
|
derberg
|
2023-07-06 05:21:44
|
Ah, okay. That thing is still open. I see.
But who from Mozilla checks that place?
|
|
|
Quackdoc
|
|
elfeïn
also how petty do they have to be to be neutral about a free image standard
|
|
2023-07-06 05:23:59
|
they claim to be neutral, but only because comming out and saying they cant be arsed to implement it is worse
|
|
|
|
derberg
|
2023-07-06 05:24:15
|
Like yeah... that Jon guy but how to see any discussion from other Mozilla people then?
|
|
|
|
Quackdoc
|
2023-07-06 05:25:12
|
firefox has jxl behind nightly but they refuse to merge patches sitting in their tracker that bring JXL to a really good state, becaue they cant afford to maintain a feature, that is locked behind a flag, only enabled on nightly, because they will prioritize AVIF
|
|
2023-07-06 05:25:30
|
seems very "neutral" to me
|
|
|
|
w
|
2023-07-06 05:25:34
|
because Mozilla is funded by Google so they must do what Google does
|
|
|
|
Quackdoc
|
2023-07-06 05:25:58
|
well, its more like mozilla cant be arsed to fund firefox to any meaningful degree
|
|
2023-07-06 05:26:11
|
firefox is somehow understaffed xD
|
|
|
|
elfeïn
|
2023-07-06 05:26:21
|
They fired all the firefox devs
|
|
2023-07-06 05:26:33
|
Right when they gave their ceos raises
|
|
|
|
Quackdoc
|
2023-07-06 05:26:42
|
they are anti-anything that needs somewhat remotely close to dev effort
|
|
2023-07-06 05:26:50
|
unless they get forced into it ofc
|
|
|
|
elfeïn
|
2023-07-06 05:27:04
|
firefox was good until it stopped receiving bug fixes
|
|
2023-07-06 05:27:21
|
then it quickly became unusable :C
|
|
|
|
Quackdoc
|
2023-07-06 05:27:42
|
firefox was fine until baker took over, people hated whats his name, but at least firefox was progressing
|
|
|
|
elfeïn
|
2023-07-06 05:28:03
|
this is obviously an anticompetitive campaign by google and should be investigated by the ftc
|
|
|
|
w
|
2023-07-06 05:28:36
|
it's not a monopoly there's still safari
|
|
|
|
derberg
|
|
Quackdoc
well, its more like mozilla cant be arsed to fund firefox to any meaningful degree
|
|
2023-07-06 05:29:04
|
Imagine if they just did not cancel good projects.
Like FirefoxOS
|
|
2023-07-06 05:29:16
|
They could have money now
|
|
|
|
w
|
2023-07-06 05:29:47
|
wdym they got great projects
|
|
|
|
elfeïn
|
|
w
it's not a monopoly there's still safari
|
|
2023-07-06 05:29:47
|
i don't know the law but this doesn't feel right
|
|
|
|
Quackdoc
|
|
elfeïn
this is obviously an anticompetitive campaign by google and should be investigated by the ftc
|
|
2023-07-06 05:29:48
|
I disagree, I dont see it as anti-competitve, it's not like they are suppressing other browsers, firefox are just lazy twats which leads to a psuedo monopoly. what we need is more real 3rd party browsers
|
|
|
|
w
|
2023-07-06 05:29:50
|
like Mozilla hubs
|
|
|
|
derberg
|
|
w
wdym they got great projects
|
|
2023-07-06 05:30:11
|
They had
|
|
|
|
elfeïn
|
|
Quackdoc
I disagree, I dont see it as anti-competitve, it's not like they are suppressing other browsers, firefox are just lazy twats which leads to a psuedo monopoly. what we need is more real 3rd party browsers
|
|
2023-07-06 05:30:12
|
hmmmmmmm
|
|
|
lonjil
|
|
elfeïn
They fired all the firefox devs
|
|
2023-07-06 05:30:18
|
a majority of the few hundred people employed at Mozilla Corp work on Firefox, as far as I know
|
|
|
|
derberg
|
|
w
like Mozilla hubs
|
|
2023-07-06 05:30:28
|
Missed opportunity as well tbh
|
|
|
|
w
|
2023-07-06 05:30:40
|
I was joking hubs was always awful
|
|
|
|
derberg
|
2023-07-06 05:30:49
|
It looks really business looking to me
|
|
|
|
Quackdoc
|
2023-07-06 05:30:51
|
heres to hoping servo progresses at the speed of light now
|
|
|
|
derberg
|
2023-07-06 05:31:19
|
In fact, I took part in a free tour they offered when that Hubs thing was new
|
|
2023-07-06 05:31:25
|
It looked good but yeah
|
|
2023-07-06 05:31:35
|
Imagine if they just took on VRChat
|
|
|
|
w
|
2023-07-06 05:32:00
|
it's like metaverse but infinitely worse
|
|
|
|
derberg
|
2023-07-06 05:32:14
|
I have more hopes for Thirdroom
|
|
|
|
elfeïn
|
|
lonjil
a majority of the few hundred people employed at Mozilla Corp work on Firefox, as far as I know
|
|
2023-07-06 05:32:17
|
oh, what were those layoffs 3 years ago about?
|
|
|
|
w
|
2023-07-06 05:32:35
|
wow has it really been 3 years
|
|
|
|
elfeïn
|
2023-07-06 05:32:50
|
yaaa
|
|
2023-07-06 05:33:04
|
Time flies when you're having fun hahaha
|
|
|
|
Quackdoc
|
2023-07-06 05:33:22
|
firefox layed off a lot of various projects, things like rust/ servo, rav1e and some firefox devs.
|
|
|
|
derberg
|
|
elfeïn
firefox was good until it stopped receiving bug fixes
|
|
2023-07-06 05:33:38
|
Firefox was fine when it was Firefox 3.
|
|
2023-07-06 05:34:01
|
When the web wasn't that bloated as well
|
|
2023-07-06 05:34:24
|
When I could open 1000s of tabs on a low resource computer to get virtual currency to level up some online pets
|
|
|
|
elfeïn
|
2023-07-06 05:34:30
|
It was weird- my history wouldn't record lol
|
|
|
|
w
|
2023-07-06 05:34:46
|
it was good before rust
|
|
2023-07-06 05:34:50
|
hmmm
|
|
|
|
elfeïn
|
|
w
it was good before rust
|
|
2023-07-06 05:35:00
|
🔥
|
|
|
|
Quackdoc
|
|
|
elfeïn
|
2023-07-06 05:35:32
|
that is a hot take
|
|
2023-07-06 05:35:55
|
yet it's technically true
|
|
|
|
Quackdoc
|
2023-07-06 05:36:03
|
it would have been nice if they had actually commited to rust
|
|
2023-07-06 05:36:11
|
maybe firefox could be semi-decent
|
|
|
|
elfeïn
|
2023-07-06 05:36:22
|
corpos work in mysterious ways
|
|
|
|
Quackdoc
|
2023-07-06 05:37:01
|
well, its pretty open in the case of firefox, I actually have a copy pasta somewhere for this
|
|
|
|
elfeïn
|
2023-07-06 05:37:18
|
wait really?
|
|
|
|
Quackdoc
|
2023-07-06 05:37:40
|
```
Attention all firefox users:
Mozilla "30m in revenue" firefox is in danger, and it needs to developers to work on it, but to do this, it needs funding now, to help Mozilla "mitchell baker 5.59m bonus" firefox, all they need is your credit card number, the three digits on the back, and the expiration month and year. but you gotta be quick so mozilla "total income of 497m" firefox can prevent the chrome monopoly
```
|
|
|
|
elfeïn
|
2023-07-06 05:37:41
|
i assumed they just got greedy
|
|
|
|
jxl
|
2023-07-06 05:38:00
|
yes
|
|
2023-07-06 05:38:09
|
Wikipedia "220m endowment" is in danger
|
|
|
|
elfeïn
|
2023-07-06 05:38:22
|
😂😂😂<:kekw:808717074305122316> <:kekw:808717074305122316> <:kekw:808717074305122316> <:kekw:808717074305122316> <:kekw:808717074305122316>
|
|
|
|
Quackdoc
|
|
elfeïn
i assumed they just got greedy
|
|
2023-07-06 05:38:23
|
that is exacty what they did, and they dont even bother to hide it
|
|
|
|
elfeïn
|
|
|
derberg
|
|
Quackdoc
I disagree, I dont see it as anti-competitve, it's not like they are suppressing other browsers, firefox are just lazy twats which leads to a psuedo monopoly. what we need is more real 3rd party browsers
|
|
2023-07-06 05:39:58
|
Yeah like netsurf, dillo, ladybird
|
|
|
|
elfeïn
|
|
derberg
Yeah like netsurf, dillo, ladybird
|
|
2023-07-06 05:40:36
|
dil*o? 😳
|
|
|
|
derberg
|
2023-07-06 05:41:37
|
https://cdn.discordapp.com/emojis/862338679981080606.webp?size=48&name=FeelsThinkingMan&quality=lossless
|
|
|
|
Quackdoc
|
2023-07-06 05:46:00
|
well at least servo should hopefully support jxl at some point lol
|
|
|
|
derberg
|
|
elfeïn
dil*o? 😳
|
|
2023-07-06 05:46:38
|
Here your possible fork name: Digital Interactive Link Discovery Object
Or something like that. Nonsense name but it's hard to find a good name, lol
|
|
|
|
elfeïn
|
|
|
derberg
|
2023-07-06 05:51:34
|
~~Considering that the internet is for .... as we all know it would actually be a funny name.~~
|
|
2023-07-06 05:52:37
|
Fork dillo, use that name and add JXL support <:KekDog:805390049033191445>
|
|
2023-07-06 05:58:51
|
The existence of src/png.c, src/jpeg.c and src/gif.c and the overall small size of ~75k lines of code (cloned the dillo-plus repo) make me hope it might actually not be that hard to do
|
|
|
gb82
|
2023-07-06 06:20:49
|
Waterfox is worth using, IMO
|
|
|
jonnyawsom3
|
|
_wb_
(first do 3-channel Palette to make a 4-bit index channel, then do one horizontal Squeeze step that makes two channels of half the width, then do a 2-channel Palette on that to get a single channel that is roughly 8-bit — not quite because of the tendency term in Squeeze, but probably close enough)
|
|
2023-07-06 08:27:18
|
Assuming it works as well as it sounds, could be quite a nice PR for libjxl and cjxl when the color pallete/input bitdepth is low enough
|
|
2023-07-06 08:43:18
|
Also, in cjxl is `--already_downsampled` only used for files that have a resampling flag already? I tried combining it with `--resampling=8` on a low resolution PNG assuming it would then create an output scaled to the new size, but it fails instead
|
|
|
Traneptora
|
|
Also, in cjxl is `--already_downsampled` only used for files that have a resampling flag already? I tried combining it with `--resampling=8` on a low resolution PNG assuming it would then create an output scaled to the new size, but it fails instead
|
|
2023-07-06 10:16:41
|
sounds like a bug, tbh
|
|
2023-07-06 10:16:51
|
how did it fail?
|
|
|
|
jonnyawsom3
|
2023-07-06 10:22:45
|
> JPEG XL encoder v0.9.0 32c1644 [AVX2,SSE4,SSSE3,SSE2]
> Read 910x461 image, 27593 bytes, 709.7 MP/s
> Encoding [Modular, lossless, effort: 7],
> JxlEncoderAddImageFrame() failed.
> EncodeImageJXL() failed.
|
|
|
VcSaJen
|
|
username
the closest place I can think of is here: https://connect.mozilla.org/t5/ideas/support-jpeg-xl/idi-p/18433
|
|
2023-07-06 10:56:47
|
They never changed status to "In Review", so looks like that post was there just to placate people. (Are they waiting until Windows OS default support?)
|
|
|
fab
|
2023-07-07 08:12:56
|
Jxl in d 0.346 e9 and three build after could have potentiality for screenshots but is a dead format
|
|
2023-07-07 08:13:10
|
People prefer AVM CPU 4
|
|
2023-07-07 08:13:23
|
Whatever quantizer
|
|
2023-07-07 08:13:43
|
60min max 138isveryflexible
|
|
2023-07-07 08:13:48
|
Why need jxl
|
|
2023-07-07 08:14:14
|
Jxl taken 22.1sat e8 on i3 330m
|
|
2023-07-07 08:14:27
|
Avm 157300.6ms
|
|
2023-07-07 08:14:41
|
157.6s
|
|
2023-07-07 08:15:00
|
Jxl makes the font look like a bitmap font
|
|
2023-07-07 08:16:22
|
Nobody use futura font anymore
|
|
2023-07-07 08:17:07
|
The f letter is usually better in AVM
|
|
2023-07-07 08:17:20
|
At cost of all glyphs
|
|
2023-07-07 08:17:46
|
They become tall and open
|
|
|
|
Traneptora
|
2023-07-07 08:17:56
|
are any boxes permitted after `jxlc` or the final `jxlp` box?
|
|
|
|
fab
|
2023-07-07 08:20:45
|
The o and r become esagonal especially in esme simple
|
|
2023-07-07 08:21:05
|
I use a lot that font because is included in xiaomi store
|
|
2023-07-07 08:21:25
|
And is one of the best for Reading far
|
|
2023-07-07 08:21:33
|
Is made for that
|
|
2023-07-07 08:21:46
|
Nouveaba Plate was also made for that
|
|
2023-07-07 08:22:03
|
|
|
2023-07-07 08:22:18
|
But with jpg dct artifacts lost readability
|
|
2023-07-07 08:22:46
|
This even AVM would struggle with
|
|
2023-07-07 08:23:29
|
The t and V Also they're larger in AVM
|
|
2023-07-07 08:24:21
|
The low mechanical short height lowercase c get impacted
|
|
2023-07-07 08:24:35
|
But anyway you don't notice
|
|
2023-07-07 08:25:45
|
Words like ira are an exception
|
|
2023-07-07 08:25:54
|
They become more readable
|
|
2023-07-07 08:26:44
|
TheM Is more curvier and G slightly narrower
|
|
2023-07-07 08:30:16
|
|
|
2023-07-07 08:39:11
|
|
|
2023-07-07 08:39:22
|
I m beginning to lose eyesight
|
|
|
|
jonnyawsom3
|
2023-07-07 09:12:17
|
One day, I'll have any idea what you're saying
|
|
|
|
Traneptora
|
2023-07-08 12:17:31
|
fab of text
|
|
|
|
jonnyawsom3
|
|
Quackdoc
sorry for brevity, on phone can add jxl to riff bmp tags to get ffmpeg to mux jxl into mkv, mov mp4 etc.
the decode speed is a little low for my system (400fps in mpv) sounds like a lot but in reality need around 600fps for really good scrubbing still usable, don't get me wrong.
biggest issue is that ffmpeg seems to be messing up some conversions, so some videos get really mangled (happens with png and even raw video, no idea why)
```patch
diff --git a/libavformat/riff.c b/libavformat/riff.c
index df7e9df31b..16e37fb557 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -34,6 +34,7 @@
* files use it as well.
*/
const AVCodecTag ff_codec_bmp_tags[] = {
+ { AV_CODEC_ID_JPEGXL, MKTAG('J', 'X', 'L', ' ') },
{ AV_CODEC_ID_H264, MKTAG('H', '2', '6', '4') },
{ AV_CODEC_ID_H264, MKTAG('h', '2', '6', '4') },
{ AV_CODEC_ID_H264, MKTAG('X', '2', '6', '4') },
```
|
|
2023-07-08 06:23:44
|
I don't suppose you could still tweak ffmpeg and upload a windows binary somewhere? Remembered about that experiment and wanted to try some things, but not really in a state to build myself and just want a 10 second video rather than a 3GB 6 minute one like you made before
I'd ping Traneptora about merging the patch into main too, but I know it needed extra work to separate it into a packet per frame first
|
|
|
|
Quackdoc
|
2023-07-08 06:24:35
|
sadly I need to rework the patch since adding animated jxl decode to ffmpeg broke it, and I have yet to get around to doing so
|
|
2023-07-08 06:25:01
|
currently you can still export to an imagesequence, and if you want, punt that directly into a tar though
|
|
2023-07-08 06:25:12
|
not as convient tho
|
|
|
|
jonnyawsom3
|
2023-07-08 06:25:29
|
I thought tar was just a archive format?
|
|
|
|
Quackdoc
|
2023-07-08 06:26:38
|
tar is an uncompressed archive format yes, you can think of it as a super simple container, I only use it so that I don't dump 10k+ files directly to my FS since that makes indexing a pita
|
|
|
|
jonnyawsom3
|
2023-07-08 06:27:53
|
I did make a sequence of 540 frames at 18fps, so 30 seconds, but no way to read them all as a video, especially with audio synced
|
|
|
|
Quackdoc
|
2023-07-08 06:29:46
|
mpv supports it kinda? last I checked it only worked with a couple formats tho, what I do when I need to test video sequences real quickly is
`ffmpeg -i frames-04%d.jxl -i input.audio -map 0:v:0 -map 1:a:0 -c:v rawvideo -c:a copy -f nut - | mpv --cache=no -`
|
|
|
|
jonnyawsom3
|
2023-07-08 06:32:39
|
Ah, converting to raw data? Was hoping to keep it as JXL internally
|
|
|
|
Quackdoc
|
2023-07-08 06:33:52
|
yeah eventially I hope it will work, whether it's I who do it or not, but either way this is the best rn
|
|
2023-07-08 06:37:42
|
it may be possible to use mpv's mf:// with some modifications tho
|
|
2023-07-08 06:38:34
|
probably just needs added to the extension->name map but im on windows rn so i aint doing it
|
|
|
|
VcSaJen
|
2023-07-08 01:19:53
|
How can I strip EXIF/XMP/etc metadata from jxl without re-encoding? After 4 hours of encoding I realized my mistake: images with EXIF are 10-100 times bigger than normal images. I don't really intend to start from scratch.
|
|
2023-07-08 01:23:48
|
I need to somehow "de-containerize" JXL, so that it's a raw stream instead (or leave it as-is, if it's already raw stream).
|
|
|
|
Traneptora
|
2023-07-08 01:26:06
|
At the moment there is no tool to do that
|
|
|
|
VcSaJen
|
|
|
_wb_
|
2023-07-08 01:47:28
|
Should be easy to make a tool to manipulate jxl containers. Maybe exiftool/exiv2 can already do it?
|
|
|
MSLP
|
2023-07-08 01:49:03
|
exiv2 seems to only support "read" on BMFF container for AVIF/JXL/HEIF
|
|
2023-07-08 01:49:55
|
exiftool has "r/w" on the support table for "JXL" tho
|
|
2023-07-08 01:50:40
|
dunno if it can extract only jxl codestream from bmff tho, as that would be the best option
|
|
2023-07-08 02:00:51
|
thinking about that - wouldn't
exiv2 -pS image.jxl
```
Exiv2::BmffImage::boxHandler: JXL 0->12
Exiv2::BmffImage::boxHandler: ftyp 12->20 brand: jxl
Exiv2::BmffImage::boxHandler: jxlp 32->20
Exiv2::BmffImage::boxHandler: jbrd 52->460
Exiv2::BmffImage::boxHandler: Exif 512->62094
Exiv2::BmffImage::boxHandler: jxlp 62606->7145174
```
and then cutting out 7145174 bytes at offset 62606 do the trick?
|
|
|
|
Traneptora
|
|
MSLP
thinking about that - wouldn't
exiv2 -pS image.jxl
```
Exiv2::BmffImage::boxHandler: JXL 0->12
Exiv2::BmffImage::boxHandler: ftyp 12->20 brand: jxl
Exiv2::BmffImage::boxHandler: jxlp 32->20
Exiv2::BmffImage::boxHandler: jbrd 52->460
Exiv2::BmffImage::boxHandler: Exif 512->62094
Exiv2::BmffImage::boxHandler: jxlp 62606->7145174
```
and then cutting out 7145174 bytes at offset 62606 do the trick?
|
|
2023-07-08 02:06:30
|
there's a `jxlp` box right after ftyp, that contains part of the codestream
|
|
|
|
MSLP
|
2023-07-08 02:09:52
|
ah, so it's no good
|
|
|
Foxtrot
|
2023-07-08 02:14:52
|
I have a question. Let's say I download some JXL from internet and want to do some simple editing. How do I find out if the original is lossy or lossless?
I mean, if it's lossless I would likely want to edit and save as lossless to prevent quality loss. The size would stay roughly the same.
But if it's already lossy I would be more likely to just use lossy again. Because if I used lossless the size would be much larger.
So it makes me think if JPEG XL shouldnt have two different suffixes. One for lossy and one for lossless. Similar how now people just know that .jpg is lossy and .png is lossless.
So people know easily if the image they have is lossless or already lossy.
What do you think?
|
|
|
|
VcSaJen
|
2023-07-08 02:17:19
|
If you find jxl in the internet, assume it's lossy. There are two modes: "lossy for sure" mode and "maybe lossless, maybe lossy" mode.
|
|
|
|
username
|
2023-07-08 02:18:11
|
I have seen many heavily lossy PNGs in the wild so I don't think it's all that necessary to have different suffixes/names
|
|
|
|
VcSaJen
|
2023-07-08 02:18:59
|
Dither or banding is pretty obvious sign for PNGs.
|
|
|
|
username
|
2023-07-08 02:19:41
|
in platforms like discord I have seen very commonly JPEGs that have been converted to PNGs
|
|
|
|
VcSaJen
|
2023-07-08 02:19:54
|
That's lossless.
|
|
|
Jim
|
|
Foxtrot
I have a question. Let's say I download some JXL from internet and want to do some simple editing. How do I find out if the original is lossy or lossless?
I mean, if it's lossless I would likely want to edit and save as lossless to prevent quality loss. The size would stay roughly the same.
But if it's already lossy I would be more likely to just use lossy again. Because if I used lossless the size would be much larger.
So it makes me think if JPEG XL shouldnt have two different suffixes. One for lossy and one for lossless. Similar how now people just know that .jpg is lossy and .png is lossless.
So people know easily if the image they have is lossless or already lossy.
What do you think?
|
|
2023-07-08 02:20:20
|
This has been asked before. As far as I know, there is no way to determine lossy/lossless without decoding the image first. I don't think there is a header flag but I think it's been talked about. <@794205442175402004> would know more on this.
https://discord.com/channels/794206087879852103/794206170445119489/915730747711696937
|
|
|
|
username
|
2023-07-08 02:20:42
|
in a lot of cases that also have cropping however even if they where not cropped I would not consider that lossless
|
|
|
|
_wb_
|
|
MSLP
thinking about that - wouldn't
exiv2 -pS image.jxl
```
Exiv2::BmffImage::boxHandler: JXL 0->12
Exiv2::BmffImage::boxHandler: ftyp 12->20 brand: jxl
Exiv2::BmffImage::boxHandler: jxlp 32->20
Exiv2::BmffImage::boxHandler: jbrd 52->460
Exiv2::BmffImage::boxHandler: Exif 512->62094
Exiv2::BmffImage::boxHandler: jxlp 62606->7145174
```
and then cutting out 7145174 bytes at offset 62606 do the trick?
|
|
2023-07-08 02:20:55
|
This is a recompressed jpeg. You can try first removing the exif from the jpeg before recompressing it...
|
|
|
|
username
|
2023-07-08 02:20:55
|
converting a JPEG to PNG is always lossy
|
|
|
|
VcSaJen
|
2023-07-08 02:21:05
|
That's outright editing. Kinda reaching at this point.
|
|
|
|
username
|
2023-07-08 02:22:08
|
most of the time the conversions does happen from someone editing a JPEG however I have seen a lot of cases where the conversion comes from how the person uploads the file
|
|
|
|
VcSaJen
|
|
_wb_
This is a recompressed jpeg. You can try first removing the exif from the jpeg before recompressing it...
|
|
2023-07-08 02:22:14
|
For my case it's converted PNGs and GIFs
|
|
|
|
MSLP
|
|
_wb_
This is a recompressed jpeg. You can try first removing the exif from the jpeg before recompressing it...
|
|
2023-07-08 02:22:51
|
just gave a bad example file
|
|
|
|
username
|
|
username
most of the time the conversions does happen from someone editing a JPEG however I have seen a lot of cases where the conversion comes from how the person uploads the file
|
|
2023-07-08 02:22:53
|
someone taking a JPEG and unintentionally having it end up as a PNG when they try to copy/share it
|
|
|
|
VcSaJen
|
2023-07-08 02:23:42
|
But when color profiles are involved, sometimes "losses" happen, yes. Many, many services and programs silently convert image to sRGB (if not outright break image by stripping profile).
|
|
|
|
Traneptora
|
|
Foxtrot
I have a question. Let's say I download some JXL from internet and want to do some simple editing. How do I find out if the original is lossy or lossless?
I mean, if it's lossless I would likely want to edit and save as lossless to prevent quality loss. The size would stay roughly the same.
But if it's already lossy I would be more likely to just use lossy again. Because if I used lossless the size would be much larger.
So it makes me think if JPEG XL shouldnt have two different suffixes. One for lossy and one for lossless. Similar how now people just know that .jpg is lossy and .png is lossless.
So people know easily if the image they have is lossless or already lossy.
What do you think?
|
|
2023-07-08 03:18:34
|
`jxlinfo -v` will report whether it's XYB encoded
|
|
2023-07-08 03:18:38
|
which is a good indicator
|
|
2023-07-08 03:18:47
|
XYB-encoded is always lossy, not-xyb-encoded is usually lossless
|
|
2023-07-08 03:19:22
|
the only exception to this is losless-jpeg-recompression which was lossily comprssed to JPEG first
|
|
2023-07-08 03:19:55
|
also again depends on what you mean by "lossy" but if you're referring to the final JXL compression step only, then a solid indicator is if XYB is used
|
|
2023-07-08 03:21:07
|
generally speaking you have three indicators
(1) XYB -> lossy
(2) VarDCT -> lossy
(3) Squeeze Transform -> probably lossy
|
|
2023-07-08 03:21:36
|
strictly speaking you can't tell if a modular squeezeless that isn't xyb encoded is lossy but
|
|
2023-07-08 03:21:37
|
well
|
|
2023-07-08 03:21:45
|
that's lossless in like 99% of cases
|
|
2023-07-08 03:22:10
|
note that jxlinfo won't report frame types, but jxlatte will
|
|
|
VcSaJen
\:(
|
|
2023-07-08 03:31:25
|
something you *can* do is print box boundaries with `jxlinfo -v` and then do it by hand, although if you want to do it with many images it will be simpler to write something to do it for you
|
|
|
Oleksii Matiash
|
2023-07-08 04:01:28
|
That's why I decided to use .png.jxl, jpg.jxl and .jxl for lossless, jpeg-to-jxl and lossy jxl respectively 😔
|
|
|
joppuyo
|
|
username
converting a JPEG to PNG is always lossy
|
|
2023-07-08 04:40:49
|
Not really. If I take a source file, heavily compress it to a JPEG and then take that JPEG and convert that to a PNG, that PNG is still losslessly compressed, even if that data has JPEG artifacts in it
|
|
2023-07-08 04:41:24
|
Unless I use a PNG8 with dithering or something like that
|
|
|
DZgas Ж
|
2023-07-08 04:43:25
|
What is the smallest jxl decoder at the moment?
|
|
|
|
_wb_
|
2023-07-08 04:55:03
|
"lossless" is a hard to define concept - everything is in lossy in one way or another except creation of vector art.
|
|
2023-07-08 04:55:21
|
Or I guess pixel art
|
|
2023-07-08 04:56:57
|
Anything else is doing some kind of sampling and color quantization, with or without sensor artifacts, so it's already lossy in a way, even when storing as a 16-bit PNG.
|
|
|
|
jonnyawsom3
|
|
username
someone taking a JPEG and unintentionally having it end up as a PNG when they try to copy/share it
|
|
2023-07-08 05:52:09
|
I think most cases are from using 'copy image' on browsers which stores it as a png no matter the source format
|
|
|
_wb_
Or I guess pixel art
|
|
2023-07-08 05:55:48
|
Even pixel art usually gets scaled in a way that blurs and smooths unfortunately
|
|
|
VcSaJen
How can I strip EXIF/XMP/etc metadata from jxl without re-encoding? After 4 hours of encoding I realized my mistake: images with EXIF are 10-100 times bigger than normal images. I don't really intend to start from scratch.
|
|
2023-07-08 05:58:51
|
Is brotli compression on for the container? That seems like a lot for what should be raw text
|
|
|
|
Traneptora
|
2023-07-08 06:15:06
|
Was there ever a 0.9.0 release?
|
|
|
|
username
|
|
Traneptora
Was there ever a 0.9.0 release?
|
|
2023-07-08 06:23:38
|
there hasn't been a 0.9.0 release yet but hopefully there will be one at some point after the "libjxl uses abort()" issue is solved
|
|
|
|
_wb_
|
2023-07-08 06:23:49
|
Not yet, next one will be 0.9
|
|
2023-07-08 06:24:43
|
Yes, first have to get the aborts fixed, and also the decode cms thing
|
|
|
|
jonnyawsom3
|
2023-07-08 06:27:32
|
Huh, last I heard 0.9 was getting skipped to aim for 1.0
|
|
|
|
username
|
2023-07-08 06:29:22
|
I think that was the old plan but due to the scope of things planned for 1.0 theres gonna be a 0.9 release in the meantime
|
|
|
|
Traneptora
|
|
_wb_
Not yet, next one will be 0.9
|
|
2023-07-08 06:30:12
|
I ask cause you broke the API/ABI on git master when you changed the function signatures so I'm trying to figure out a macro to check to use the new or the old versions
|
|
2023-07-08 06:30:28
|
does git master at the moment already #define itself as 0.9?
|
|
|
|
_wb_
|
2023-07-08 06:47:24
|
Yeah I think so
|
|
|
|
Traneptora
|
2023-07-08 06:47:38
|
might be easier to just check for the existence of one of the functions removed in the same commit
|
|
2023-07-08 06:49:31
|
ah, looks like it does
|
|
2023-07-08 06:49:47
|
so I'll just #ifdef for 0.9 and use the new signature if it's found and use the old signature if a 0.8 or lower is found
|
|
|
prick
|
|
DZgas Ж
What is the smallest jxl decoder at the moment?
|
|
2023-07-08 09:23:03
|
Smallest as in what?
|
|
|
|
DZgas Ж
|
|
prick
Smallest as in what?
|
|
2023-07-08 09:52:30
|
*Well, the less code is written, the smaller the executable file. *Therefore, very specifically "less than all the others"
|
|
|
|
Traneptora
|
2023-07-08 09:54:18
|
smallest as in size of executable code
|
|
2023-07-08 09:54:24
|
atm it's probably j40 although it's incomplete
|
|
|
|
prick
|
2023-07-08 09:54:29
|
You can do various things to reduce the size of the generated binaries, regardless of the code. You can also look through and see if there are fast or slow paths, code only relevant for APIs not commonly called, etc
|
|
|
|
Traneptora
|
2023-07-08 09:55:04
|
I was considering adding a lightweight decoder to libhydrium
|
|
|
|
VcSaJen
|
2023-07-09 12:48:55
|
```cjxl -e 9 -d 0 --container=0 2174903.png ../jxl/2174903.jxl
JPEG XL encoder v0.9.0 c3a4f9c [AVX2,SSE4,SSSE3,SSE2]
Encoding [Container | Modular, lossless, effort: 9 | 4602-byte Exif]
Compressed to 1130.6 kB including container (9.758 bpp).
504 x 1839, 0.024 MP/s [0.02, 0.02], 1 reps, 12 threads.```
Am I doing something wrong? "--container=0" parameter is here, but it still says "[Container | Modular, lossless, effort: 9 | 4602-byte Exif]"
|
|
|
|
MSLP
|
2023-07-09 02:09:25
|
looks like a bug
you cat't force container off in presence of exif et. al. - it needs to be changed in 2 places:
<https://github.com/libjxl/libjxl/blob/main/tools/cjxl_main.cc#L989>
<https://github.com/libjxl/libjxl/blob/main/lib/extras/enc/jxl.cc#L66>
|
|
|
VcSaJen
```cjxl -e 9 -d 0 --container=0 2174903.png ../jxl/2174903.jxl
JPEG XL encoder v0.9.0 c3a4f9c [AVX2,SSE4,SSSE3,SSE2]
Encoding [Container | Modular, lossless, effort: 9 | 4602-byte Exif]
Compressed to 1130.6 kB including container (9.758 bpp).
504 x 1839, 0.024 MP/s [0.02, 0.02], 1 reps, 12 threads.```
Am I doing something wrong? "--container=0" parameter is here, but it still says "[Container | Modular, lossless, effort: 9 | 4602-byte Exif]"
|
|
2023-07-09 02:15:37
|
Seems for now you'll have to remove exif from pngs beforehand or apply some changes to libjxl source
|
|
|
Fraetor
|
2023-07-09 11:35:07
|
Will the level box in the container be written with the minimal level required for that image, or is it possible that level 10 will be there for an image that would be fine at level 5?
|
|
|
|
_wb_
|
2023-07-09 11:39:11
|
iirc the way the api is now, an application will get an error if it doesn't set the level to 10 before trying to do stuff that requires level 10, but if you set the level to 10 and only do stuff that's fine for level 5, that also works
|
|
|
|
Fraetor
|
|
VcSaJen
How can I strip EXIF/XMP/etc metadata from jxl without re-encoding? After 4 hours of encoding I realized my mistake: images with EXIF are 10-100 times bigger than normal images. I don't really intend to start from scratch.
|
|
2023-07-09 12:04:25
|
I've just created a tool to strip the container from a jxl file. It requires python 3, but no other dependencies.
https://github.com/Fraetor/jxl_decode/blob/main/src/jxl-strip.py
Usage is just `python3 jxl-strip.py myfile.jxl`, so you can easily wrap it in a loop to do a whole directory.
E.g: On Linux/WSL the following command will do all files below the current directory.
`find . -iname *.jxl -exec python jxl-strip.py -v {} \;`
|
|
|
|
VcSaJen
|
|
Fraetor
I've just created a tool to strip the container from a jxl file. It requires python 3, but no other dependencies.
https://github.com/Fraetor/jxl_decode/blob/main/src/jxl-strip.py
Usage is just `python3 jxl-strip.py myfile.jxl`, so you can easily wrap it in a loop to do a whole directory.
E.g: On Linux/WSL the following command will do all files below the current directory.
`find . -iname *.jxl -exec python jxl-strip.py -v {} \;`
|
|
2023-07-09 12:38:51
|
Thanks
|
|
|
Jyrki Alakuijala
|
|
Is brotli compression on for the container? That seems like a lot for what should be raw text
|
|
2023-07-09 06:02:56
|
there is a brob -- brotli box -- which contains another ISOBMFF box compressed with brotli
|
|
|
|
jonnyawsom3
|
2023-07-09 06:38:39
|
Interesting, although 10-100x size difference from only metadata *while* compressed makes me wonder what on earth was being stored
|
|
|
|
_wb_
|
2023-07-09 07:21:14
|
Could be there's a whole other image or even short video in the "metadata"
|
|
2023-07-09 07:22:31
|
I've seen files where the main jpeg has a fake-bokeh background, and in the "metadata" there's the original image with the more detailed background.
|
|
2023-07-09 07:23:15
|
Add to that that the metadata only gets general-purpose compression, not image-specific, and it can easily end up quite largw
|
|
|
|
jonnyawsom3
|
2023-07-09 07:27:11
|
Hmm, odd but an interesting way to do it
|
|
|
|
Fraetor
|
2023-07-09 08:07:02
|
Alternitively I know some images have an uncompressed image in exif for thumbnail purposes, which for small images could be a significant part of the size.
|
|
|
|
VcSaJen
|
2023-07-09 11:03:20
|
It's a small pixel-art, and compresses very well even with png. I think metadata is mostly thumbnails and color profiles (sRGB color profiles, weirdly).
|
|
|
|
jonnyawsom3
|
2023-07-09 11:06:11
|
Ah, fair enough
|
|
|
yurume
|
|
_wb_
I've seen files where the main jpeg has a fake-bokeh background, and in the "metadata" there's the original image with the more detailed background.
|
|
2023-07-10 12:59:58
|
as an jfif thumbnail? I've also seen APNG files intended to produce a different thumbnail from the original.
|
|
|
MysteriousJ
|
2023-07-10 01:33:48
|
Are there encoding settings one can tweak that will effect decoding speed?
|
|
|
|
jonnyawsom3
|
2023-07-10 01:56:31
|
`--faster_decoding` is one
|
|
|
|
Traneptora
|
2023-07-10 02:59:22
|
using VarDCT instead of modular is a good one, it decodes much faster
|
|
|
|
MysteriousJ
|
2023-07-10 03:37:19
|
Thanks, I'll try them!
|
|
|
|
Traneptora
|
2023-07-11 12:01:09
|
and finally sent my full jxl parser to the FFmpeg ml
|
|
2023-07-11 12:01:13
|
took a bunch of work on that one
|
|
|
|
Quackdoc
|
2023-07-11 12:47:47
|
Nice! guess ill finally start seeing if I can make riff image sequences work again
|
|
|
OkyDooky
|
2023-07-11 01:07:38
|
Hi <@794205442175402004>, I have no idea what sJPEG is, would you like to confirm if it's not needed / recommended for a web browser engine like WebKitGTK to offer support for JPEG XL? See https://gitlab.gnome.org/GNOME/gnome-build-meta/-/merge_requests/1622#note_1780272
|
|
|
|
elfeïn
|
|
Hi <@794205442175402004>, I have no idea what sJPEG is, would you like to confirm if it's not needed / recommended for a web browser engine like WebKitGTK to offer support for JPEG XL? See https://gitlab.gnome.org/GNOME/gnome-build-meta/-/merge_requests/1622#note_1780272
|
|
2023-07-11 01:08:31
|
https://tenor.com/view/king-of-the-hill-jpeg-gif-20226849
|
|
|
|
_wb_
|
|
Hi <@794205442175402004>, I have no idea what sJPEG is, would you like to confirm if it's not needed / recommended for a web browser engine like WebKitGTK to offer support for JPEG XL? See https://gitlab.gnome.org/GNOME/gnome-build-meta/-/merge_requests/1622#note_1780272
|
|
2023-07-11 05:05:07
|
It's not needed for jxl.
|
|
|
diskorduser
|
|
elfeïn
https://tenor.com/view/king-of-the-hill-jpeg-gif-20226849
|
|
2023-07-11 02:17:25
|
Yes
|
|
|
yoochan
|
2023-07-11 03:01:31
|
would it be possible for -e 10 to spit out the settings used eventually ? the ones we could have used via the command line for the same result (if I understood correctly, e 10 brute force parameters...)
|
|
|
username
I was looking at random github repos and I found a random issue page showing lossless JXL performing noticeably worse then lossless WebP: https://github.com/diasurgical/devilutionX/issues/6309
|
|
2023-07-11 03:04:15
|
I tried this palettized diablo screenshot with e 10 and could squeeze it to only 405 kb (whereas webp could reach 376 kb) after hours of processing 😄
|
|
|
|
username
|
2023-07-11 03:06:43
|
don't forget to strip the metadata if you used the PNG i posted in Discord
|
|
2023-07-11 03:06:52
|
discord adds garbage metadata to the file
|
|
|
|
yoochan
|
2023-07-11 03:07:22
|
I downloaded the original pcx and converted it with gimp (keeping the palette if I haven't screwed it)
|
|
|
|
jonnyawsom3
|
|
Traneptora
and finally sent my full jxl parser to the FFmpeg ml
|
|
2023-07-11 03:27:49
|
Got a link to that? Curious what it looks like
|
|
|
|
afed
|
2023-07-11 03:36:35
|
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=9282
|
|
2023-07-11 03:39:19
|
so jpeg recompression will also be possible?
|
|
|
|
jonnyawsom3
|
2023-07-11 04:01:38
|
Built-in MJPEG to 'MJXL' would be neat, although with no container just MKV probably
|
|
|
|
Traneptora
|
|
afed
so jpeg recompression will also be possible?
|
|
2023-07-11 05:41:37
|
no, that would require a bitstream filter
|
|
2023-07-11 05:41:44
|
which tend not to be based on external libraries
|
|
|
|
_wb_
|
|
yoochan
I tried this palettized diablo screenshot with e 10 and could squeeze it to only 405 kb (whereas webp could reach 376 kb) after hours of processing 😄
|
|
2023-07-12 08:01:20
|
could you share the image? always useful to have cases where we can do better
|
|
|
|
yoochan
|
|
yoochan
would it be possible for -e 10 to spit out the settings used eventually ? the ones we could have used via the command line for the same result (if I understood correctly, e 10 brute force parameters...)
|
|
2023-07-12 08:29:33
|
if I put it on discord, will the png be distorded ? (<@794205442175402004> do you have an answer for the question in this self-quote ?)
|
|
|
|
_wb_
|
|
yoochan
if I put it on discord, will the png be distorded ? (<@794205442175402004> do you have an answer for the question in this self-quote ?)
|
|
2023-07-12 08:30:03
|
I think discord might add some bogus metadata, but the pixels themselves should be fine
|
|
|
|
yoochan
|
2023-07-12 08:30:28
|
|
|
2023-07-12 08:31:45
|
so many souvenirs with this screenshot
|
|
|
|
jonnyawsom3
|
2023-07-12 10:58:50
|
That github issue is slightly confusing. They uploaded PCX there, but in a linked issue they sent webp while comparing PCX to PNG. Different resolutions and bit depths too if I recall, but that could just be misreporting
|
|
|
spider-mario
|
|
yoochan
so many souvenirs with this screenshot
|
|
2023-07-12 12:28:16
|
(I think you mean memories — my understanding is that “souvenir” in English is more specific than in French and refers to more tangible items)
|
|
|
|
_wb_
|
2023-07-12 12:36:13
|
palette is such a tricky thing — how it is ordered makes a big difference, and I think we're not doing a very good job with that on this image
|
|
|
|
yoochan
|
|
spider-mario
(I think you mean memories — my understanding is that “souvenir” in English is more specific than in French and refers to more tangible items)
|
|
2023-07-12 12:36:13
|
you're right... french speaker exposed 😄 https://imgflip.com/i/7sblep
|
|
|
|
_wb_
|
2023-07-12 12:38:09
|
looks like webp has good stuff for palette ordering: https://github.com/webmproject/libwebp/blob/main/src/utils/palette.c
|
|
2023-07-12 12:38:46
|
we currently just sort on luma, which is probably too simplistic
|
|
|
|
yoochan
|
2023-07-12 12:39:54
|
I didn't though just the ordering could have such an impact but yes, it would be nice to be able to improve this blind spot of jxl 🙂
|
|
|
|
jonnyawsom3
|
|
_wb_
looks like webp has good stuff for palette ordering: https://github.com/webmproject/libwebp/blob/main/src/utils/palette.c
|
|
2023-07-12 12:54:19
|
Well at least there's a decent starting point
|
|
|
|
Traneptora
|
2023-07-12 04:37:41
|
I'm considering adding a JXL decoder to libhydrium
|
|
2023-07-12 04:38:03
|
that way we could have a full independent implementation from libjxl
|
|
|
|
_wb_
|
2023-07-12 04:45:13
|
That would be cool!
|
|
|
|
afed
|
2023-07-12 05:02:00
|
<@794205442175402004> as already discussed, it would also be nice to use the methods from e1-e2 (or even some simplified and fast ones from e4) for e3 for non-photos, because the difference in compression is still very significant
https://github.com/libjxl/libjxl/pull/2653
|
|
|
|
jonnyawsom3
|
2023-07-12 05:10:41
|
Are you sure you're looking at the right metrics? The main difference is encode speed, compression is only 0.050 bpp difference at e4
You also could be on an old version, lossless would only use palllete on e1, and 4+ or something similar
|
|
|
|
Traneptora
|
2023-07-12 05:21:58
|
libhydrium, as an encoder, uses far less memory than libjxl and is much more portable
|
|
|
|
afed
|
|
Are you sure you're looking at the right metrics? The main difference is encode speed, compression is only 0.050 bpp difference at e4
You also could be on an old version, lossless would only use palllete on e1, and 4+ or something similar
|
|
2023-07-12 05:24:20
|
this pr is just an example that changes are happening and I'm talking that it would be nice to also add some additional predictors to e3 or something that would be good for non-photos
|
|
|
|
Traneptora
|
|
Traneptora
libhydrium, as an encoder, uses far less memory than libjxl and is much more portable
|
|
2023-07-12 05:48:51
|
but it's slower and uses no simd as a result
|
|
2023-07-12 05:48:55
|
cause no threading
|
|
2023-07-12 05:49:11
|
also in terms of quality it's just far worse
|
|
2023-07-12 05:49:20
|
quality per bpp that is
|
|
2023-07-12 05:49:43
|
I could spend a bunch of time improving the encoder's heuristics
|
|
2023-07-12 05:49:45
|
or adding threading ig
|
|
2023-07-12 05:49:54
|
but I'm not sure if that's worth it over adding a decoder
|
|
|
|
_wb_
|
2023-07-12 05:50:22
|
Encoder tweaking is a never ending story
|
|
2023-07-12 05:51:04
|
I'd go for feature completeness before trying to be particularly good
|
|
|
|
Traneptora
|
2023-07-12 05:59:33
|
There's just so much to support on the decoder end
|
|
2023-07-12 05:59:58
|
I'm also not sure how much cms I want to implement myself
|
|
|
|
_wb_
|
2023-07-12 06:55:01
|
Just depend on lcms2 or something, why implement that stuff yourself?
|
|
|
|
OkyDooky
|
2023-07-13 10:22:03
|
https://old.reddit.com/r/jpegxl/comments/14y2uh6/killing_jpg_by_converting_to_jxl/
OP (/u/dbtsai), who is a Senior Engineering Manager at Apple (Source\: https://www.dbtsai.com/), says he is highly optimistic about the future of JPEG XL.
|
|
|
|
jonnyawsom3
|
2023-07-13 11:33:59
|
Huh, I read that to a friend last night when it was posted, but didn't know who it was. Nice
|
|
|
|
Quackdoc
|
2023-07-13 11:36:58
|
are you sure this is his account and not just a weird coincidence?
> **pleasantly surprised** to find that I could import JXL images into the Photo app on my Mac...
> **Even more astonishingly**, I discovered that I could view these JXL images on my iPhone running iOS 16
I understand that there would be a disconnect to a degree, but this seems like a large degree
|
|
|
|
jonnyawsom3
|
2023-07-13 11:45:34
|
Yeahh
|
|
|
|
_wb_
|
2023-07-13 12:50:16
|
modular decoding is pretty slow, but this is making it slightly less slow: https://github.com/libjxl/libjxl/pull/2664
|
|
2023-07-13 12:51:30
|
going from 4 MPx/s to 4.5 Mpx/s for an image encoded with default effort, it's not much but it's something
|
|
|
|
spider-mario
|
2023-07-13 02:36:49
|
https://tenor.com/view/honest-word-its-honest-work-it-aint-much-it-aint-much-but-its-honest-work-gif-13763573
|
|
|
|
jonnyawsom3
|
2023-07-13 03:37:46
|
1/8th faster ain't bad
|
|
|
Gizus
|
2023-07-13 08:54:31
|
Does JPEG XL have 3 types of bitstream? What is the bitstream in between? Is it possible to losslessly transcode that bitstream into JPEG? Does that bitstream affects compression efficiency?
|
|
|
|
Fraetor
|
|
Gizus
Does JPEG XL have 3 types of bitstream? What is the bitstream in between? Is it possible to losslessly transcode that bitstream into JPEG? Does that bitstream affects compression efficiency?
|
|
2023-07-13 09:50:45
|
I think it would be a theoretical encoder profile that only used things that exist in legacy JPEG, with the difference from the reencode case being that you can strip off any unnecessary bits of the reconstruction data.
It might also represent efforts lke jpegli, where some of the techniques from JXL are applied to traditional JPEG.
|
|
|
|
Traneptora
|
|
_wb_
Just depend on lcms2 or something, why implement that stuff yourself?
|
|
2023-07-13 10:31:44
|
portability
|
|
2023-07-13 10:31:52
|
lcms2 also deals with floats
|
|
2023-07-13 10:31:57
|
if I do it myself I'd do it in fixed-point
|
|
2023-07-13 10:33:27
|
(probably)
|
|
|
|
spider-mario
|
|
Gizus
Does JPEG XL have 3 types of bitstream? What is the bitstream in between? Is it possible to losslessly transcode that bitstream into JPEG? Does that bitstream affects compression efficiency?
|
|
2023-07-13 11:56:20
|
jpegli -> cjxl should get you at least some of the way there
|
|
|
|
VcSaJen
|
|
VcSaJen
ICC status:
IrfanView+Plugin: not supported (jpg works, jxl does not)
XnVIew MP: not supported (jpg works, jxl does not)
ImageGlass: not supported (jpg works, jxl does not) + wrong orientation
Paint.Net+Plugin: not supported (not color managed)
PaleMoon: not supported (not color managed)
Basilisk: not supported (not color managed)
WaterFox: supported only for red bench, not supported for other examples
darktable: works (except for CMYK, also not sure if orientation was supposed to be ignored)
Krita (pre-alpha): works
GIMP (development build): works
|
|
2023-07-14 02:33:06
|
XnView MP 1.5 now supports ICC profiles for JPEG XL, when color management is turned on in settings. (CMYK is not yet supported)
|
|
|
|
OkyDooky
|
2023-07-14 04:13:11
|
Slightly off-topic, but does anyone have some documentation they can point to on using ffmpeg to convert images via command line?
I'm trying to use Termux+ffmpeg on some anon's recommendation so I can convert using the MozJPEG encoder on my Android phone, but all the guides I've found, so far, are focused on audio or video. Even the image ones are about extracting images from video or turning a Jpeg sequence into a video file.
|
|
|
|
elfeïn
|
|
Slightly off-topic, but does anyone have some documentation they can point to on using ffmpeg to convert images via command line?
I'm trying to use Termux+ffmpeg on some anon's recommendation so I can convert using the MozJPEG encoder on my Android phone, but all the guides I've found, so far, are focused on audio or video. Even the image ones are about extracting images from video or turning a Jpeg sequence into a video file.
|
|
2023-07-14 04:34:27
|
`ffmpeg -i img.png -o img.jpg`
|
|
2023-07-14 04:35:10
|
Should just be that simple. Now for options, idk, you're on your own.
|
|
|
190n
|
2023-07-14 04:47:09
|
if you get mozjpeg installed, it might be easier to use its `cjpeg` executable
|
|
2023-07-14 04:48:05
|
and that should have a help menu too with more image-relevant CLI options than ffmpeg
|
|
|
|
gb82
|
|
https://old.reddit.com/r/jpegxl/comments/14y2uh6/killing_jpg_by_converting_to_jxl/
OP (/u/dbtsai), who is a Senior Engineering Manager at Apple (Source\: https://www.dbtsai.com/), says he is highly optimistic about the future of JPEG XL.
|
|
2023-07-14 01:08:47
|
> At this point xl just seems like a jpeg sqeezer which is really not all that useful..
> Using a simple high quality raw JPEG deblocker followed by upscaling and then encoding at low bitrate gives you a vastly better looking image at a vastly smaller file size.
<:kekw:808717074305122316>
|
|
|
|
spider-mario
|
|
Quackdoc
are you sure this is his account and not just a weird coincidence?
> **pleasantly surprised** to find that I could import JXL images into the Photo app on my Mac...
> **Even more astonishingly**, I discovered that I could view these JXL images on my iPhone running iOS 16
I understand that there would be a disconnect to a degree, but this seems like a large degree
|
|
2023-07-14 01:20:13
|
one of the comments has a link to a gist under his github account
|
|
|
|
Quackdoc
|
2023-07-14 01:21:20
|
0.0
|
|
2023-07-14 01:21:24
|
I stand corrected then
|
|
|
|
_wb_
|
2023-07-14 01:39:39
|
> AVIF performs excellently at low bit rates xl does not. Gralic is able to outperform all other algorithms for lossless compression and xl is not even close.
Gralic is a Windows binary and that's alll you can find. I need an emulator to even run it. And yes, for some images it outperforms jxl in compression density — but it doesn't do parallel decoding, has limited pixel format options, etc...
|
|
2023-07-14 01:40:47
|
Image formats are not just about compression itself. Features and standardization matter too. People still use PNG for a reason.
|
|
|
|
w
|
2023-07-14 01:41:01
|
they obviously have a very specific use case so whatever
|
|
|
|
_wb_
|
2023-07-14 01:44:03
|
As for lossy: the crossover point where avif is better on average than jxl is at much lower quality than what anyone would use in real use cases. But it's image dependent: for some (mostly non-photographic) images, avif is quite good, for some images, there is no crossover point and jxl is just better at all bitrates.
|
|
2023-07-14 01:45:58
|
First time I see someone write "jpXL"
|
|
|
|
jonnyawsom3
|
2023-07-14 01:47:53
|
Jpexl
|
|
|
|
spider-mario
|
|
_wb_
Image formats are not just about compression itself. Features and standardization matter too. People still use PNG for a reason.
|
|
2023-07-14 01:52:09
|
> Your insinuated argument amounts to a common logical fallacy, an appeal in this case to argumentum ad populum.
>
> By your logic I could ask:
>
> When was the last time you heard a common person say something intelligent? so maybe it's just not worth being intelligent.. ಠ_ಠ
|
|
|
nec
|
2023-07-14 02:25:26
|
I heard that avif is better than jpeg xl in pixel art and drawings, so I was testing it for a while and speaking honestly I'm not sure. If we talk about higher quality like 80-90 ssimulacra score, avif indeed quite often produces ~10% smaller size, but if we zoom, jxl usually has better fidelity. If image is initially on lower side like 1 bpp, we are literally comparing lossless transcoding against visually lossless avif with 5-10% size advantage. So I feel like we are kinda trading slighly smaller size for slightly worse quality. I've also noticed some weird defects avif produces every ~30 images even at 88 ssimulacra score and once image becomes more complex, avif just stays behind. When avif wins are mostly situations when we are fine with image distortions and details lose, if we simply want very small size image that decently resembles original, avif indeed would win, because jpeg xl prefers to preserve details even at lower quality settings and it's going to cost space. I'm actually curious would jpeg xl produce a similar result or not, if we simply deleted jpeg artifacts and blured image a bit.
|
|
|
|
VcSaJen
|
2023-07-14 02:25:28
|
I wonder if .bmp.gz is a thing in *nix.
|
|
|
nec
I heard that avif is better than jpeg xl in pixel art and drawings, so I was testing it for a while and speaking honestly I'm not sure. If we talk about higher quality like 80-90 ssimulacra score, avif indeed quite often produces ~10% smaller size, but if we zoom, jxl usually has better fidelity. If image is initially on lower side like 1 bpp, we are literally comparing lossless transcoding against visually lossless avif with 5-10% size advantage. So I feel like we are kinda trading slighly smaller size for slightly worse quality. I've also noticed some weird defects avif produces every ~30 images even at 88 ssimulacra score and once image becomes more complex, avif just stays behind. When avif wins are mostly situations when we are fine with image distortions and details lose, if we simply want very small size image that decently resembles original, avif indeed would win, because jpeg xl prefers to preserve details even at lower quality settings and it's going to cost space. I'm actually curious would jpeg xl produce a similar result or not, if we simply deleted jpeg artifacts and blured image a bit.
|
|
2023-07-14 02:27:02
|
>pixel art
>ssimulacra
Why would you use lossy for pixel art? Even PNG compresses it to 0.1 bpp losslessly.
|
|
|
|
nec
|
2023-07-14 02:28:57
|
Because people say it's very good for avif. If we throw something more realistic like pixar animation, jpeg xl would be better at both size and quality.
|
|
|
|
VcSaJen
|
2023-07-14 02:31:37
|
How does JPEG XL fare for dithered images?
|
|
|
|
spider-mario
|
2023-07-14 02:43:06
|
you mean the coarse dithering that is sometimes seen in grayscale printed content?
|
|
2023-07-14 02:43:58
|
or the more “pokémon gen 2” style of dithering?
|
|
|
|
nec
|
2023-07-14 02:44:02
|
Depends on image, I guess. I've tested several dithered images. One was advantageous for avif, another slightly for jpeg xl.
|
|
|
|
spider-mario
|
2023-07-14 02:44:34
|
|
|
2023-07-14 02:44:39
|
this sort of dithering?
|
|
2023-07-14 02:55:33
|
(maybe more visible here)
|
|
|
|
VcSaJen
|
2023-07-14 02:58:52
|
I mean more like in GIF images and flipnote studio and similar.
|
|
2023-07-14 03:00:07
|
|
|
|
|
nec
|
2023-07-14 03:13:52
|
Jpeg xl lossy doesn't like it. Image looks fine, but small variation in pixel colors do not produce good ssimulacra scores. Lossless produces in 1.5-2 times smaller size than lossy here. Avif on the other hand is decent at lossy, 82 ssimu both are 3 and 25 kb, 86-88 ssimu 4 and 71. For comparison lossless jpeg xl are 11 and 36 and originals are 37 and 144.
|
|
|
|
Traneptora
|
|
VcSaJen
I wonder if .bmp.gz is a thing in *nix.
|
|
2023-07-14 04:41:01
|
.xpm.gz is a thing
|
|
2023-07-14 04:42:57
|
also, it ocurred to me that there's no command-line tool like tweakpng to analyze PNG chunks, strip unnecessary ones (by unnecessary I mean like zTXt, pHYs, etc.), etc.
|
|
2023-07-14 04:43:06
|
that leaves necessary ones (iCCP, etc.) intact
|
|
2023-07-14 04:44:08
|
so I decided I'd create a minimal tool to scan a PNG file, strip unnecessary chunks, and also possibly add an sRGB chunk if no color information is already present
|
|
2023-07-14 04:44:41
|
since most software assumes untagged PNGs are already sRGB, it makes sense to an add sRGB chunk to make it explicit
|
|
|
|
jonnyawsom3
|
|
nec
Jpeg xl lossy doesn't like it. Image looks fine, but small variation in pixel colors do not produce good ssimulacra scores. Lossless produces in 1.5-2 times smaller size than lossy here. Avif on the other hand is decent at lossy, 82 ssimu both are 3 and 25 kb, 86-88 ssimu 4 and 71. For comparison lossless jpeg xl are 11 and 36 and originals are 37 and 144.
|
|
2023-07-14 04:51:34
|
JXL lossy will rarely be better than lossless on pixel art or artifical images, also bear in mind those images are already converted to jpeg, so JXL could do better lossless with a clean source file
|
|
|
|
spider-mario
|
|
Traneptora
also, it ocurred to me that there's no command-line tool like tweakpng to analyze PNG chunks, strip unnecessary ones (by unnecessary I mean like zTXt, pHYs, etc.), etc.
|
|
2023-07-14 05:03:50
|
to inspect them, `pngcheck -v` is better than nothing
|
|
|
|
Traneptora
|
2023-07-14 05:11:28
|
unfamiliar with that tool
|
|
2023-07-14 05:11:36
|
the quickie thing I threw together appaers to work tho
|
|
2023-07-14 05:11:52
|
```
$ ./umbrielpng ~/Pictures/Sync/test_images/image-magick-logo.png
PNG signature found
Chunk: IHDR, Size: 25, Offset: 0, CRC32: 020f2cd6
Chunk: gAMA, Size: 16, Offset: 25, CRC32: 0bfc6105
Chunk: cHRM, Size: 44, Offset: 41, CRC32: 9cba513c
Chunk: PLTE, Size: 780, Offset: 85, CRC32: 8698809d
Chunk: bKGD, Size: 13, Offset: 865, CRC32: 18ba00d9
Chunk: tIME, Size: 19, Offset: 878, CRC32: df467f77
Chunk: IDAT, Size: 26383, Offset: 897, CRC32: c9c8d354
Chunk: tEXt, Size: 49, Offset: 27280, CRC32: 01d0604a
Chunk: tEXt, Size: 49, Offset: 27329, CRC32: 708dd8f6
Chunk: IEND, Size: 12, Offset: 27378, CRC32: ae426082
```
|
|
2023-07-14 05:18:51
|
the next question is a decision, which chunks are "unnecessary"
|
|
2023-07-14 05:19:31
|
critical chunks, animation control/data, cICP, iCCP, and sRGB are all clearly necessary
|
|
2023-07-14 05:20:30
|
I'm thinking of stripping tEXt, iTXt, zTXt, eXIf, mASt, pHYs, tIME, bKGD
|
|
2023-07-14 05:21:25
|
and keeping cHRM and gAMA if and only if there's no cICP, iCCP, or sRGB chunk
|
|
2023-07-14 05:21:53
|
and for tRNS and sBIT I have to read it and see if it's necessary
|
|
2023-07-14 05:21:58
|
thoughts?
|
|
|
|
spider-mario
|
2023-07-14 05:32:38
|
isn’t bKGD theoretically necessary?
|
|
2023-07-14 05:32:44
|
(though I doubt that a lot of software supports it)
|
|
|
|
Traneptora
|
2023-07-14 06:50:49
|
I don't know, is it?
|
|
|
|
_wb_
|
2023-07-14 07:08:49
|
I think nearly everything ignores it and shows a checkerboard pattern or something instead
|
|
|
|
fab
|
|
Traneptora
critical chunks, animation control/data, cICP, iCCP, and sRGB are all clearly necessary
|
|
2023-07-14 08:22:42
|
Why you don't optimize your own encoder
|
|
2023-07-14 08:22:54
|
Also make to decode rapid
|
|
2023-07-14 08:35:53
|
Jxl is good about 6%betterthan main avm
|
|
2023-07-14 08:36:05
|
And 14% better ssinulacra 2
|
|
2023-07-14 08:36:13
|
E9 d 1.668
|
|
2023-07-14 08:37:07
|
Contrast and blurring problems all solved
|
|
2023-07-14 08:37:27
|
Even when saw rapidly the Image is good
|
|
|
|
_wb_
|
|
spider-mario
https://tenor.com/view/honest-word-its-honest-work-it-aint-much-it-aint-much-but-its-honest-work-gif-13763573
|
|
2023-07-14 08:59:34
|
some more of that stuff: https://github.com/libjxl/libjxl/pull/2665
|
|
|
|
Traneptora
|
|
fab
Why you don't optimize your own encoder
|
|
2023-07-14 10:51:49
|
because this is a very simple tool, it's like ~300 LOC
|
|
|
|
username
|
2023-07-15 03:57:16
|
I found a user on archive.org that seems to do all of their recent uploads as JXL: https://archive.org/details/@bigmanjapan
|
|
2023-07-15 03:57:38
|
their uploads from before JXL was around are in tiff
|
|
|
|
OkyDooky
|
2023-07-15 04:48:22
|
https://av.watch.impress.co.jp/docs/news/1515354.html
New camera α6700 by Sony adopts HEIF, which is the first in the α6000 series.
When will we finally see a camera which supports JXL?
|
|
|
|
jonnyawsom3
|
2023-07-15 05:06:08
|
Bear in mind HEIF has been around almost 10 years, and took 2 years after finalisation for Apple to pick up and make widespread. It's been about 1 year for JXL, Apple is already adding support in the OS at least (We'll see about the camera) and the hardware implimentation is still being worked on, so there's still a while to go but it's looking promising
|
|
|
|
Traneptora
|
2023-07-15 10:00:16
|
How do you tell if an ICC profile is just an sRGB profile?
|
|
2023-07-15 10:02:22
|
in case I'd like to potentially detect an ICC profile and replace it with an sRGB tag
|
|
|
|
_wb_
|
2023-07-15 10:47:27
|
libjxl has code for that
|
|
2023-07-15 10:47:58
|
it depends a bit on how tolerant you want to be, since there are many different "sRGB" profiles that are subtly different
|
|
|
|
Traneptora
|
2023-07-15 10:52:20
|
how would they be subtly different? rounding?
|
|
2023-07-15 10:52:59
|
cause rendering intent is controllable in the sRGB chunk itself
|
|
|
|
spider-mario
|
|
Traneptora
how would they be subtly different? rounding?
|
|
2023-07-15 11:08:38
|
https://ninedegreesbelow.com/photography/srgb-profile-comparison.html
|
|
|
|
Traneptora
|
2023-07-15 11:13:17
|
I see
|
|
2023-07-15 11:13:31
|
seems like it's safer to leave an ICC as ICC in the PNG case
|
|
2023-07-15 11:13:41
|
or in the `uses_original_profile = true` case
|
|
2023-07-15 11:14:04
|
I could have a list of *known* sRGB ICC profiles though
|
|
|
|
_wb_
|
2023-07-15 11:38:20
|
the thing is, probably none of these flavors of sRGB are actually _meant_ to be different from "actual sRGB"
|
|
2023-07-15 11:38:55
|
cjxl currently keeps the icc intact when doing lossless and only replaces it with an Enum when doing lossy
|
|
2023-07-15 11:39:54
|
but I think that's probably a bit unnecessary, I think those rounding differences will very rarely make any visual difference but certainly never an _intended_ difference
|
|
2023-07-15 11:40:50
|
so I think it would be better if we never write explicit icc profiles if they describe a space that can also be described in the enum
|
|
2023-07-15 11:42:40
|
there's even a kind of privacy/security argument to be made for that: keeping the icc profile may allow people to know what editing software was used, which may be undesirable
|
|
2023-07-15 11:43:05
|
only for JPEG recompression we do need to always keep the exact icc profile, otherwise the bitstream reconstruction cannot be exact
|
|
|
|
Traneptora
|
|
_wb_
so I think it would be better if we never write explicit icc profiles if they describe a space that can also be described in the enum
|
|
2023-07-15 08:48:33
|
in either case, where's the code to detect if a profile is sRGB?
|
|
|
|
_wb_
|
2023-07-15 08:50:19
|
https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_color_management.cc
|
|
|
|
spider-mario
|
2023-07-15 08:52:32
|
`IdentifyPrimaries` / `DetectTransferFunction` / `UnadaptedWhitePoint` are first used to construct an enum-based color profile, then `ProfileEquivalentToICC` is used to check that it’s roughly equivalent to the ICC version
|
|
|
|
Traneptora
|
2023-07-15 08:52:43
|
ah so you call the CMS for that
|
|
2023-07-15 08:52:56
|
I was hoping there was an easier way to it without calling a cms engine
|
|
2023-07-15 08:53:03
|
just by parsing the profiles
|
|
|
|
spider-mario
|
2023-07-15 08:53:39
|
if sRGB is the only colorspace that needs to be detected then probably some shortcuts can be taken
|
|
2023-07-15 08:54:14
|
(maybe even if not)
|
|
|
|
Traneptora
|
2023-07-15 08:54:25
|
that's the only one I care about mostly because it's really really common to have an embedded sRGB profile
|
|
|
|
username
|
2023-07-15 08:57:37
|
also probably P3 is somewhat common since I think if you export work from a Apple device it usually has a P3 profile attached
|
|
|
|
Traneptora
|
2023-07-15 08:57:54
|
this is specifically for replacing with an sRGB chunk tho
|
|
|
|
username
|
2023-07-15 08:58:07
|
ah I didn't realize this was related to the PNG project project you are making
|
|
|
|
Traneptora
|
2023-07-16 04:39:36
|
I ended up throwing a quick parser and I match sRGB if and only if the rTRC, gTRC, and bTRC tags all match the parametric curve
|
|
2023-07-16 04:40:20
|
now it works much more robustly
|
|
2023-07-16 04:40:38
|
(also I match `wtpt` and `rXYZ`, `gXYZ`, and `bXYZ`)
|
|
2023-07-16 04:40:49
|
```
$ ./umbrielpng Seance.png{,}
PNG signature found
Chunk: IHDR, Size: 25, Offset: 8, CRC32: 32146733
Chunk: eXIf, Size: 190, Offset: 33, CRC32: 26442f2a
Chunk: iCCP, Size: 7270, Offset: 223, CRC32: a20dc500
Chunk: iTXt, Size: 3460, Offset: 7493, CRC32: 3177baee
Chunk: bKGD, Size: 18, Offset: 10953, CRC32: a0bda793
Chunk: pHYs, Size: 21, Offset: 10971, CRC32: 009a9c18
Chunk: tIME, Size: 19, Offset: 10992, CRC32: b6876721
Chunk: IDAT, Size: 8204, Offset: 11011, CRC32: 76c1ddb9
Chunk: 17 more IDAT chunks
Chunk: IEND, Size: 12, Offset: 156890, CRC32: ae426082
Size: 328x328, Color: 8-bit RGB + Alpha
ICC Profile Length: 20420
ICC profile matches sRGB profile
Writing chunk: IHDR
Inserting default sRGB chunk
Stripping chunk: eXIf
Stripping chunk: iCCP
Stripping chunk: iTXt
Stripping chunk: bKGD
Stripping chunk: pHYs
Stripping chunk: tIME
Writing chunk: IDAT
Writing chunk: IEND
```
|
|
2023-07-16 04:41:30
|
if there's ever a parse error or other illegal scenario it just immediately aborts and treats it as a negative
|
|
|
|
spider-mario
|
2023-07-17 07:46:50
|
only the parametric? the article with the comparison seemed to show that 1D-LUT-based was quite common
|
|
|
|
Traneptora
|
2023-07-17 01:05:30
|
for now yes
|
|
2023-07-17 01:05:38
|
I might add `curv` later
|
|
2023-07-17 01:06:02
|
I'd rather have false negatives than false positives, as there's no damage dealt by leaving the iCCP as-is
|
|
2023-07-17 02:59:19
|
how does `PassesInfo.downsample` interact with passes and passgroups?
|
|
2023-07-17 02:59:23
|
the spec is very much not clear on this
|
|
|
CrushedAsian255
|
2023-07-18 02:06:57
|
is there any good resources on the bitstream format for JPEG XL?
|
|
|
|
w
|
2023-07-18 02:07:20
|
this discord server
|
|
|
|
CrushedAsian255
|
2023-07-18 02:07:40
|
like a PDF or something? or JPEG XL screenshots of a pdf?
|
|
|
|
w
|
2023-07-18 02:08:50
|
`in:#jxl has:file from: _wb_ pdf`
|
|
|
|
yoochan
|
|
CrushedAsian255
like a PDF or something? or JPEG XL screenshots of a pdf?
|
|
2023-07-18 07:21:01
|
you can have a look on the sub forum image-compression-forum/specification issues and scroll back until you find the last draft (some iso1818-1 like here https://discord.com/channels/794206087879852103/1021189485960114198/1101072554837409853)
|
|
|
|
VcSaJen
|
2023-07-18 08:20:17
|
CONTRIBUTING.md:
> If your are refactoring code
*you
|
|
|
|
username
|
2023-07-20 01:37:56
|
maybe this is a dumb question but since JXL by default assumes/processes/encodes/tags non-tagged image data as sRGB then what is a recommended way to encode/tag RGB data that inherently doesn't have any specific intended look or color space to it?
|
|
2023-07-20 01:40:51
|
say for example image data that isn't really authored by any sort of artist or photographer but instead stuff like artificial image data where the RGB values might not even be seen displayed out on a screen before being encoded
|
|
2023-07-20 01:51:39
|
maybe this is a question that would be something more appropriate for https://discord.com/channels/794206087879852103/794206087879852106 since it's not specifically about JXL but more so about what to do with a format that enforces color space tagging by default in a scenario where the image data isn't really meant to be interpreted as any specific display range
|
|
|
|
VcSaJen
|
2023-07-20 02:01:19
|
You mean linear RGB? Also if data is not meant to be displayed, why not just store them in a .bin file?
|
|
|
|
Traneptora
|
|
username
maybe this is a question that would be something more appropriate for https://discord.com/channels/794206087879852103/794206087879852106 since it's not specifically about JXL but more so about what to do with a format that enforces color space tagging by default in a scenario where the image data isn't really meant to be interpreted as any specific display range
|
|
2023-07-20 02:47:36
|
if you encode losslessly it doesn't do an XYB transform so it'll preserve the original space, whatever that is
|
|
2023-07-20 02:47:45
|
but otherwise, JXL is designed a perceptual image codec
|
|
2023-07-20 02:47:57
|
for non-perceptual data you're better off with just Zstd
|
|
2023-07-20 02:48:03
|
and not making it an image at all
|
|
|
|
_wb_
|
2023-07-20 07:18:55
|
Technically you can tag a jxl image to be in "Unknown" space
|
|
2023-07-20 07:20:02
|
You should be able to take a ppm or pfm and manually tag it to be in "Unknown" space
|
|
2023-07-20 07:20:15
|
Not sure if cjxl/djxl will allow that though
|
|
2023-07-20 07:20:59
|
I don't think it's a good idea because there then is no way to show the image
|
|
|
Demiurge
|
2023-07-21 08:39:54
|
lol well of course. If it's unknown what the pixel data represents, then it logically follows that it is unknown how it's supposed to be viewed
|
|
|
|
_wb_
|
2023-07-21 08:43:15
|
yes, but it will be pretty confusing to have jxl files that cannot show any image — I think it's nicer to still make them contain a viewable image that somehow represents the data, and use extra channels to store anything that is really non-visual
|
|
|
|
Demiurge
|
2023-07-22 12:55:01
|
Well, a binary file is often called an image...
|
|
2023-07-22 01:03:25
|
Well, guys, I think it's probably time to say it official: We've won. Safari + iOS 17 has JXL, the only way this could be any better is if the iPhone starts using the format for the camera app as well :)
|
|
2023-07-22 01:03:46
|
https://caniuse.com/jpegxl
|
|
2023-07-22 01:11:16
|
The attempted sabotage of the "no ecosystem interest" Bankowski team is utterly failing and is currently hilariously swirling the toilet bowl.
|
|
2023-07-22 01:12:58
|
Their attempt to unilaterally stunt the momentum of JXL through their commanding role over "le open web"
|
|
2023-07-22 01:14:07
|
Now it will be a lot harder for them to justify if they stubbornly refuse to change their position.
|
|
2023-07-22 01:18:18
|
Apple has enough devices out there that if all of them suddenly support JXL that's going to be a pretty big deal if Chrome still refuses to support it.
|
|
|
|
_wb_
|
2023-07-22 02:23:17
|
I hope so. Question is how long are they going to drag their feet...
|
|
|
novomesk
|
2023-07-22 02:33:48
|
Older iPhones will not get iOS 17.
|
|
|
|
Foxtrot
|
2023-07-22 04:17:55
|
now we have to wait cca 1 year until Apple users upgrade and JXL will have cca 10% - 15% adoption rate
|
|
|
|
spider-mario
|
2023-07-22 04:31:56
|
the iPhone XR/XS are the oldest that will get iOS 17
|
|
2023-07-22 04:32:02
|
(2018)
|
|
|
|
OkyDooky
|
2023-07-23 12:51:34
|
It's not over until you can convince Mozilla to flip the switch.
(<@1028567873007927297>)
|
|
2023-07-23 12:54:14
|
also WordPress. Because that's basically 50% of websites out there.
|
|
2023-07-23 12:54:59
|
once that platform-independent browser can support it out of the box, and ideally that biggest website CMS in the world, then I'm pretty sure it's checkmate
|
|
2023-07-23 12:55:26
|
but even just with Safari + Epiphany + Firefox, I guess the most hardcore chaotic-good folks could switch their websites to use JXL images everywhere and put an obnoxious banner to tell Chrome users to upgrade to a browser that isn't b.s., like in the IE6 days
|
|
|
|
Demiurge
|
2023-07-23 12:55:26
|
Well good luck with that, because it seems like there's "orders from the top," whoever the hell Mozilla's top brass are, that are preventing extremely basic bugfix patches from being merged into Firefox to improve JXL decoding
|
|
|
|
OkyDooky
|
2023-07-23 12:56:09
|
I don't see how you can convince the biased Chrome team with only 1 out of 3 major browser engines
|
|
|
|
Demiurge
|
2023-07-23 12:56:39
|
Isn't it funny how the people in power who are responsible for making decisions that affect everyone, have zero accountability and no one even knows who they are? Ahhh, gotta love le open web
|
|
|
|
username
|
2023-07-23 12:57:38
|
yeah I'm worried that mozilla is just gonna continue to do nothing which would be bad because firefox having JXL support is going to play a big part/role in adoption
|
|
|
|
OkyDooky
|
2023-07-23 01:00:47
|
Maybe [this](https://mastodon.social/@nekohayo/110752509126031436) and [that](https://twitter.com/nekohayo/status/1682397418875236352) needs extra visibility somehow but the cynical me isn't convinced the decision makers at Mozilla are going to get influenced by this, unless it goes viral like some backlashes they've experienced previously
|
|
2023-07-23 01:02:25
|
I wonder if Epiphany could be listed in CanIUse, but it's such a niche (Linux-only) browser that... well, who's going to maintain all the features info in that website
|
|
|
|
username
|
2023-07-23 01:03:27
|
speaking of webkit, does it still not support jxl animations?
|
|
2023-07-23 01:04:15
|
it seems like in part apple might not be aware that jpeg xl supports animation but i'm not sure
|
|
|
|
OkyDooky
|
2023-07-23 01:05:33
|
I have tested now, and Epiphany renders the animated JXL logo in https://jpegxl.info/art/
|
|
2023-07-23 01:05:34
|
so that works on WebKitGTK, I would presume WebKit too
|
|
2023-07-23 01:05:43
|
Epiphany Tech Preview, that is (not version 44)
|
|
|
|
username
|
2023-07-23 01:06:21
|
even the animated image at the bottom of this page? https://jpegxl.info/test-page/
|
|
|
|
OkyDooky
|
2023-07-23 01:06:55
|
yes sir (or madam)
|
|
|
|
username
|
2023-07-23 01:07:29
|
ah well that is very good to hear
|
|
|
|
OkyDooky
|
2023-07-23 01:07:43
|
I am pleasantly surprised too
|
|
2023-07-23 01:09:57
|
apparently this was implemented a long time ago\: https://bugs.webkit.org/show_bug.cgi?id=233545
|
|
|
|
username
|
2023-07-23 01:11:57
|
huh well it seemingly wasn't working here: https://discord.com/channels/794206087879852103/803574970180829194/1115419814257766440
|
|
2023-07-23 01:12:38
|
I don't have the proper devices/setup to test myself
|
|
2023-07-23 01:14:13
|
while you have the time could you test a simulatied throttled connection to this site to see if progressive decoding works? https://sneyers.info/progressive/
|
|
|
|
OkyDooky
|
2023-07-23 01:21:47
|
image.png
|
|
2023-07-23 01:21:55
|
the problem I have is, it loads too damned fast 👆️
|
|
2023-07-23 01:22:14
|
the JXL version just appears instantly in one shot
|
|
2023-07-23 01:23:25
|
and WebKit / WebKitGTK's inspector [doesn't support throttling](https://bugs.webkit.org/show_bug.cgi?id=254607)
|
|
|
|
Quackdoc
|
|
Demiurge
Well good luck with that, because it seems like there's "orders from the top," whoever the hell Mozilla's top brass are, that are preventing extremely basic bugfix patches from being merged into Firefox to improve JXL decoding
|
|
2023-07-23 01:34:33
|
I dont think it has anything to do with corruption, firefox in general has been on a large downwards spiral for a long time, just check their bug tracker and you can see plenty of issues that should have been fixed ages ago
|
|
2023-07-23 01:35:39
|
obligatory copypasta time
```
Attention all firefox users:
Mozilla "30m in revenue" firefox is in danger, and it needs to developers to work on it, but to do this, it needs funding now, to help Mozilla "mitchell baker 5.59m bonus" firefox, all they need is your credit card number, the three digits on the back, and the expiration month and year. but you gotta be quick so mozilla "total income of 497m" firefox can prevent the chrome monopoly
```
|
|
|
|
OkyDooky
|
2023-07-23 01:38:55
|
I for one have been seeing massive improvements in Firefox with each release since 2017, particularly on the performance front; those who do not run Linux may not notice as much
|
|
2023-07-23 01:40:11
|
Who-dared-change-the-tab's-appearance UI changes concern me not; I am appreciative of the work that happens elsewhere.
|
|
2023-07-23 01:40:43
|
while very far from perfect, I hope they can continue to exist especially as an independent engine, because that's all we've got left
|
|
2023-07-23 01:47:35
|
for those who have a bugzilla account, y'all can use the votes count feature to add your votes to https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 at least, though I don't know if Mozilla ever takes that metric into account
|
|
|
|
username
|
|
the problem I have is, it loads too damned fast 👆️
|
|
2023-07-23 01:48:09
|
in that case this should be a better site to test with if throttling is not a option: https://people.csail.mit.edu/ericchan/hdr/hdr-jxl.php
|
|
|
|
OkyDooky
|
2023-07-23 01:58:11
|
still loads them too fast in one single block
|
|
2023-07-23 01:58:37
|
unless that's proof that progressive decoding doesn't work, but I mean it all happens in something like less than 1 second for the 1st image
|
|
2023-07-23 01:59:12
|
I need you to come up with a ridiculously heavy, like 50 megabytes, progressively-encoded JXL on a webpage
|
|
2023-07-23 02:00:27
|
(also that page doesn't use img lazy-loading so it loads all the images beyond my scrollable view)
|
|
|
|
username
|
2023-07-23 02:01:13
|
I could probably get a large JXL problem is I don't know where I would host it and also my upload speed is very very slow.
|
|
|
|
OkyDooky
|
2023-07-23 02:02:19
|
I don't even have a "fast" connection to most people's standards here, 30-35 mbits/s (\~4 mbytes/s)
|
|
|
|
Demiurge
|
|
Quackdoc
I dont think it has anything to do with corruption, firefox in general has been on a large downwards spiral for a long time, just check their bug tracker and you can see plenty of issues that should have been fixed ages ago
|
|
2023-07-23 02:03:13
|
When the patches have been available for years, with a vague excuse/apology for not merging it, with no one specifically taking credit for being the one accountable for making the decision, then that by itself is corruption
|
|
|
|
OkyDooky
|
2023-07-23 02:04:28
|
Not necessarily. It took *20 years* for GTK to have a "perfect" patchset to accept and merge to have thumbnails in the FileChooser, because it was technologically impossible before that.
|
|
2023-07-23 02:04:37
|
(also because it was a massive amount of work for everybody involved)
|
|
|
|
Demiurge
|
2023-07-23 02:06:15
|
This has nothing in common with that. The work is already done. The patches are not merged for literally no reason ("Sorry, we can't right now, the top brass is focused on other things")
|
|
2023-07-23 02:06:37
|
That's literally the apology/explanation given
|
|
2023-07-23 02:07:07
|
They are simple bug fix patches that improve the existing implementation
|
|
|
|
OkyDooky
|
2023-07-23 02:07:24
|
link please?
|
|
|
|
Demiurge
|
2023-07-23 02:07:27
|
No one knows who these shadowy Firefox overlords are
|
|
|
|
username
|
2023-07-23 02:08:10
|
https://phabricator.services.mozilla.com/D119700
https://phabricator.services.mozilla.com/D122158
https://phabricator.services.mozilla.com/D122159
|
|
|
|
Demiurge
|
2023-07-23 02:08:34
|
That itself is the very definition of corruption. The link is to the merge request for the patches that Waterfox and Mercury already use.
|
|
2023-07-23 02:10:22
|
The time it took to write that explanation/excuse/apology the patch could have been reviewed and merged by the very same person
|
|
2023-07-23 02:10:41
|
Unless they don't want to for political reasons or are being ordered not to
|
|
2023-07-23 02:11:16
|
It literally fixes severe bugs with the existing Firefox code
|
|
2023-07-23 02:12:30
|
The patches are already reviewed and field tested for a long time now by other developers maintaining forks of firefox
|
|
2023-07-23 02:13:04
|
This isn't a situation where it makes sense to give them the benefit of the doubt or assume good faith anymore. This is beyond good faith
|
|
2023-07-23 02:13:37
|
It's lack of accountability, with shadowy overlords, and it's not open source.
|
|
|
|
OkyDooky
|
2023-07-23 02:15:46
|
It was relatively clear to me that Kagami must have been told to focus on other work last year as one of the surviving employees, and the blame then is with those overlords you speak of for halting such work, but I would not call Kagami corrupt.
|
|
|
|
Demiurge
|
2023-07-23 02:17:43
|
Well it's like I said: Based on the information we have here, either he doesn't want to or he is being ordered not to. And yes I agree in this case he is probably being ordered not to, by someone who is an unknown and unaccountable shadowy overlord
|
|
2023-07-23 02:18:17
|
Which is really convenient
|
|
|
|
w
|
2023-07-23 02:18:28
|
It's pretty typical. The devs have to work on what's assigned to them. And it's always related to something important to the company down the line
|
|
|
|
Demiurge
|
2023-07-23 02:18:38
|
If no one knows who's making the decisions then no one owes anyone an explanation.
|
|
2023-07-23 02:18:47
|
And no one is to blame for mistakes
|
|
2023-07-23 02:19:19
|
That flies in the face of a so-called open source project
|
|
|
|
w
|
2023-07-23 02:21:45
|
it's open source but that's it
|
|
|
|
OkyDooky
|
2023-07-23 02:26:20
|
most open source projects that have a company paying people to work on them don't have 100% full transparency on every business decision happening behind everything, no
|
|
|
|
Demiurge
|
2023-07-23 02:26:24
|
It's "here's the source bitch now buzz off"
|
|
2023-07-23 02:26:30
|
lol
|
|
2023-07-23 02:27:28
|
Yeah well there is a whole lot of pretentiousness built around how "open" and community driven mozilla supposedly is and "muh open web standards"
|
|
2023-07-23 02:28:24
|
Honestly the "web" needs to be thrown entirely in the trash and reinvented from scratch without this "javascript is on by default" assumption.
|
|
|
|
OkyDooky
|
2023-07-23 02:30:53
|
I'm glad there are paid professionals at all to maintain that 26 million lines of code monster that is Firefox at least, because if it depended only on indie volunteers in an anarcho-syndicalist commune in Spain, it would never stand a chance ;)
|
|
2023-07-23 02:33:05
|
and before any of you say "26 M LoC OMFG bloat!", WebKit has 24 M, Chromium has 29 M
|
|
|
|
Quackdoc
|
2023-07-23 03:57:01
|
the difference is that chromium and webkit serve as actually beneficial projects xD.
firefox only exists to be "not chrome" and they don't even do a good job at that
|
|
2023-07-23 03:57:27
|
heres to hoping servo goes places, I already had JXL running in it thanks to jxl-oxide
|
|