|
_wb_
|
2021-01-25 08:13:31
|
Hi all
|
|
2021-01-25 08:13:44
|
Nothing to see here... Yet!
|
|
|
raysar
|
2021-01-25 08:19:55
|
hello, who have a link to binaries of jxl windows encoder? there is no release of the git ^^ https://gitlab.com/wg1/jpeg-xl
|
|
2021-01-25 08:21:01
|
it's important to share easy ways to download and use it.
|
|
|
|
_wb_
|
2021-01-25 08:24:23
|
Yes. I think there should be binary releases of ImageMagick for windows that you can use, the latest ones should be able to encode/decode jxl
|
|
2021-01-25 08:26:06
|
https://encode.su/threads/3544-JXL-reference-software-version-0-2-released?p=67989&viewfull=1#post67989
|
|
2021-01-25 08:26:26
|
I think there's a binary version there
|
|
2021-01-25 08:32:53
|
Hi <@111445179587624960>, did I point to the right thing?
|
|
|
Scope
|
|
|
_wb_
|
2021-01-25 08:33:57
|
I haven't used Windows since 1997 so I cannot really help with that (well I guess I could crosscompile but meh)
|
|
|
BlueSwordM
|
|
raysar
hello, who have a link to binaries of jxl windows encoder? there is no release of the git ^^ https://gitlab.com/wg1/jpeg-xl
|
|
2021-01-25 08:47:33
|
I think Scope compiled one recently for the latest version: https://cdn.discordapp.com/attachments/673202643916816384/802503439867314196/jpeg-xl-mingw64-945ad0ce.7z
|
|
2021-01-25 08:47:45
|
Perhaps I could look into how I can cross compile with clang and mingw-w64.
|
|
|
|
Scope
|
2021-01-25 08:49:43
|
Well, Windows is still the most popular OS for ordinary users, although almost anyone can compile Jpeg XL with m-ab-s, but the problem is that with GCC (the default compiler) it can work correctly only in Scalar mode
|
|
|
|
_wb_
|
2021-01-25 08:50:22
|
Do your builds support proper simd?
|
|
|
|
Scope
|
2021-01-25 08:50:35
|
Yes, I compile with Clang
|
|
|
|
_wb_
|
2021-01-25 08:50:45
|
Nice
|
|
2021-01-25 08:52:38
|
Being faster than avif is one of our strengths so have to avoid giving bad impressions with slower-than-necessary binaries floating around
|
|
|
|
Scope
|
2021-01-25 09:00:45
|
It would also be nice to have a third-party WIC decoder for system-wide support (but as I understand none of the JXL developers use Windows at all)
|
|
|
|
_wb_
|
2021-01-25 09:07:15
|
I think Jan uses Windows sometimes
|
|
2021-01-25 09:08:48
|
It would be even nicer to have native jxl support in Windows, but I don't know how easy it is to convince Microsoft of that
|
|
|
|
Scope
|
2021-01-25 09:14:52
|
Yes, but it could be a long time before that happens, and even third-party decoders would also help wider use
|
|
|
|
_wb_
|
2021-01-25 09:16:57
|
Agreed
|
|
|
|
veluca
|
2021-01-25 09:36:14
|
I use windows sometimes (mostly for games), but I'm definitely not an expert
|
|
|
Gilor🥀
|
2021-01-25 09:52:38
|
Will there be a different file extension for lossless JPEG XL? I really hope that this can finally replace animated GIF since the last version of that format dates back to the 80s and it doesn't support over 256 colors. But one problem I see with having both lossy and lossy compression in the same image format is that it will blur the lines between those two compressions.
|
|
|
|
_wb_
|
2021-01-25 09:54:50
|
That line is blurred anyway. Lots of pngs are ex-jpegs...
|
|
2021-01-25 09:57:06
|
You are of course free to use whatever filename extension convention you want, if you want jxll for lossless that is fine for me
|
|
|
|
Gilor🥀
|
2021-01-25 09:58:50
|
Well, in that case it's usually not the original image. What I'm thinking more of is digital artists switching from PNG to JPEG XL and not knowing what lossless is, making the situation worse than before.
|
|
2021-01-25 09:59:07
|
If there's a different extension it kinda has to be official from the specification, otherwise it just won't work.
|
|
|
|
BlueSwordM
|
2021-01-25 10:05:33
|
.jxll sounds like a good official name, I don't know why.
|
|
|
Dr. Taco
|
2021-01-25 10:08:28
|
better than `LJXL` which sounds like an open source license
|
|
2021-01-25 10:08:35
|
Do you use LGPL or LJXL?
|
|
|
|
_wb_
|
2021-01-25 10:08:52
|
We could make cjxl do lossless by default if the output extension is .jxll
|
|
2021-01-25 10:09:53
|
We don't spec filename extensions though, decoders don't care what name you pick for your files
|
|
|
|
Dr. Taco
|
2021-01-25 10:10:01
|
but ultimately lossless `.jxl` files will still work the same as if they were `.jxll` they would still be decoded
|
|
2021-01-25 10:10:23
|
so you just end up with `.jpg` and `.jpeg` and people not knowing if there is a difference
|
|
2021-01-25 10:12:22
|
also you can have layers in JXL and one be lossless and one be lossy. like you could have a lossy animation with a layer on top of lossless text
|
|
|
|
_wb_
|
|
|
Dr. Taco
|
2021-01-25 10:12:56
|
we live in a brave new world
|
|
|
|
_wb_
|
2021-01-25 10:13:21
|
Recompressed jpeg with a lossless alpha channel and a lossless text overlay, can be done
|
|
2021-01-25 10:15:59
|
The output of `pngquant` is a PNG, but it's not lossless. I think it's not a good idea to associate losslessness with an extension or a codec. It is a property of a workflow, not of a codec.
|
|
|
|
Dr. Taco
|
2021-01-25 10:16:33
|
so like, are you gonna make 40 different file extensions for every combination of lossy/lossless/animated/still/layered/alpha/etc
|
|
|
|
_wb_
|
2021-01-25 10:17:30
|
Reminds me of .heif, .heic, .heix, .heics
|
|
2021-01-25 10:18:29
|
.heic is supposed to be only 8-bit 4:2:0 still images with hevc payload
|
|
2021-01-25 10:19:13
|
Though MacOS also decodes higher bit depth ones... But not 4:4:4
|
|
|
|
raysar
|
|
Gilor🥀
Well, in that case it's usually not the original image. What I'm thinking more of is digital artists switching from PNG to JPEG XL and not knowing what lossless is, making the situation worse than before.
|
|
2021-01-25 10:31:35
|
i'm agree, it's important to force ALL to use a an other name for lossless jxl. (although we can use a lossless file in .jxl)
|
|
2021-01-25 10:39:47
|
i say that because we need a good psychological information to replace this horrible tiff format always used in photography and with photoshop.
|
|
|
|
_wb_
|
2021-01-25 10:44:22
|
I made sure jxl can do everything that tiff can do, but actually compressed
|
|
|
|
Dr. Taco
|
2021-01-26 03:15:08
|
<:24Rip:567491904179142678> TIF
|
|
|
matrix-t2bot
|
2021-01-26 09:32:50
|
@jonsneyers:matrix.org on matrix would like to bridge this channel. Someone with permission to manage webhooks please reply with `!matrix approve` or `!matrix deny` in the next 5 minutes
|
|
|
|
_wb_
|
|
@jonsneyers:matrix.org on matrix would like to bridge this channel. Someone with permission to manage webhooks please reply with `!matrix approve` or `!matrix deny` in the next 5 minutes
|
|
2021-01-26 09:33:28
|
!matrix approve
|
|
|
|
matrix-t2bot
|
2021-01-26 09:33:29
|
Thanks for your response! The matrix bridge has been approved
|
|
|
OkyDooky
|
2021-01-26 09:34:51
|
ok so there is now also a jxl matrix room
|
|
|
|
_wb_
|
2021-01-26 09:35:43
|
and it's supposed to be bridged to this channel
|
|
2021-01-26 09:35:47
|
https://matrix.to/#/#jxl:matrix.org?via=matrix.org&via=t2bot.io
|
|
|
|
OkyDooky
|
2021-01-26 09:38:46
|
hm
|
|
2021-01-26 09:38:46
|
bridge doesn't work anymore?
|
|
2021-01-26 09:38:47
|
bridge works in this direction
|
|
2021-01-26 09:39:50
|
ah it does work in both directions, just rather slow it seems
|
|
|
|
Scope
|
2021-01-26 09:39:52
|
Bridges often have a very large delay
|
|
|
|
_wb_
|
2021-01-26 09:40:36
|
yes, I was somehow expecting it to be lower latency than that, lol
|
|
|
|
OkyDooky
|
2021-01-26 09:41:07
|
seems to be quite variable in latency
(<@794205442175402004>)
|
|
|
|
Deleted User
|
2021-01-26 09:46:18
|
I think what jxl needs to help with adoption is a library for quick decoding like david is for av1
|
|
|
|
_wb_
|
2021-01-26 09:47:22
|
libjxl does that
|
|
2021-01-26 09:48:00
|
just need to get the api stable so we don't keep breaking early adopters that use it
|
|
|
|
Deleted User
|
2021-01-26 09:48:50
|
Yeah, I think the browsers and other adopters want to know everything is stable until they add support
|
|
|
|
_wb_
|
2021-01-26 09:52:40
|
the bitstream is stable. the library api hopefully soon. You can of course link statically with a specific version, but I agree we need a stable api so you can link dynamically (and update without worries)
|
|
|
|
Deleted User
|
2021-01-26 10:53:26
|
Also I watched many of the jxl presentations but one thing was not clear to me. Is the progresive mode available when saving with the PIK based compression for photographic images?
|
|
|
|
_wb_
|
2021-01-26 10:56:12
|
yes
|
|
2021-01-26 10:56:45
|
`cjxl --progressive` will be progressive whether it's lossy or lossless, VarDCT or modular mode
|
|
|
|
Deleted User
|
2021-01-26 10:56:58
|
cool, thanks
|
|
2021-01-26 10:57:02
|
and is it the default mode?
|
|
|
|
_wb_
|
2021-01-26 10:57:48
|
not atm, for lossless it comes at a cost in density, for lossy the default is simple progressive with a 1:8 preview and then the full detail
|
|
2021-01-26 10:58:18
|
with `--progressive` you also get ..., 1:32, 1:16, and 1:4, 1:2 previews
|
|
|
|
Deleted User
|
2021-01-26 10:59:25
|
I think it should be the default for all modes. It's a good thing to know that by default jxl offers progressive mode. And it was a big selling point for FLIF/FUIF
|
|
2021-01-26 10:59:47
|
I don't think the space savings outweigh the usefullness of the feature
|
|
2021-01-26 11:00:14
|
Do you have some data of how big of a difference it makes on the losless pictures?
|
|
|
|
_wb_
|
2021-01-26 11:17:14
|
For lossless the amount of difference is highly image-dependent, it can be 5% larger and it can be 3 times larger. Some non-photographic images can compress ridiculously well (to like 0.1 bpp losslessly) but not when doing it progressively
|
|
2021-01-26 11:20:29
|
it probably makes more sense to use a lossy preview frame for most use cases where you want to have lossless+progressive
|
|
|
|
Deleted User
|
2021-01-26 11:23:42
|
I think you guys should take special care of what features are selected as default when launching jxl to the masses. It has many options but not everyone will be familiar with the features available.
|
|
2021-01-26 11:24:11
|
Like jpeg has 10 bit support but no one use it because it was not included in the default libraries
|
|
|
|
_wb_
|
2021-01-26 12:03:33
|
The important thing is that the decoder that gets deployed can decode anything. That's what didn't happen with the original jpeg 12-bit and other non-implemented features, and that's how you end up with a crippled de facto standard
|
|
2021-01-26 12:04:02
|
Making default encoding do good stuff is of course also nice, but less critical
|
|
|
spider-mario
|
2021-01-26 12:24:54
|
yes, same with arithmetic JPEG, AFAIK practically no one supports that
|
|
2021-01-26 12:27:31
|
as for 12-bit, with libjpeg-turbo, from what I understand, you have to choose it at build-time, and then you can’t have it at the same time as 8-bit support
|
|
|
Master Of Zen
|
|
|
_wb_
|
2021-01-26 12:27:47
|
hi
|
|
|
spider-mario
as for 12-bit, with libjpeg-turbo, from what I understand, you have to choose it at build-time, and then you can’t have it at the same time as 8-bit support
|
|
2021-01-26 12:31:40
|
Not sure, you can build for 12-bit but not sure if that breaks 8-bit decode or not. But all deployed decoders only support 8-bit so it's just going to produce JPEGs that seem broken. You could also define a variant of JFIF that supports alpha (the JPEG bitstream is perfectly capable of representing 4 components), but existing deployed decoders will either ignore alpha, freak out, or assume it's CMYK and not RGBA. So there's a reason why 12-bit JPEG with alpha never happened – it would break too much stuff.
|
|
2021-01-26 12:33:37
|
JPEG XT tried to do higher bit depth and alpha channels and everything in a backwards-compatible way, with a somewhat graceful degradation for legacy decoders. But that doesn't work either: nobody upgrades their decoders to handle the extensions, and people just assume the "graceful degradation" _is_ the full image.
|
|
|
lithium
|
2021-01-26 12:33:50
|
Hello 🙂
|
|
2021-01-26 12:36:36
|
A little curious, vardct mode probably have a plan or patch to improvement non-photographic fidelity(quality) in this month?
|
|
2021-01-26 12:37:28
|
Issue post: https://gitlab.com/wg1/jpeg-xl/-/issues/121 and https://encode.su/threads/3544-JXL-reference-software-version-0-2-released
|
|
|
|
_wb_
|
2021-01-26 12:38:52
|
I expect lots of encoder-side improvements to still happen in the coming months and years
|
|
2021-01-26 12:39:50
|
There is still a lot that can be improved, e.g. using more Modular patches for non-photographic elements even when doing a VarDCT encode – the heuristics there are still quite limited
|
|
|
Orum
|
2021-01-26 12:40:06
|
Ah, this is the Lee that responded to my bug 😄
|
|
|
|
lithium
|
|
|
_wb_
|
2021-01-26 12:40:52
|
but for now I think we should focus on getting libjxl stable and getting it integrated in image viewers, image editors and browsers
|
|
2021-01-26 12:42:03
|
improving the encoder can always be done, but it's already pretty good for many use cases, and without software support there is little point in having a great encoder
|
|
|
|
Orum
|
2021-01-26 12:42:05
|
Anyway, I've not had a chance to look for the ringing, but I have scope's image set somewhere still
|
|
|
|
lithium
|
2021-01-26 12:58:35
|
In my test, image type non-photographic(synthetic),
lossy modular mode(-m -Q 95)(YCoCg, reversible Haar-like squeezing), can get good result(maxButteraugli 0.6),
in -Q 90 still can't see any tiny artifacts, but probably have some error(maxButteraugli),
vardct mode can produce smaller file, but have tiny artifacts issue...
|
|
2021-01-26 01:01:47
|
xnviewmp use older version libJPEGXL.dll(20200924)
|
|
|
|
Orum
|
2021-01-26 01:20:41
|
Is there a way to get encoding time in seconds instead of MP/s?
|
|
2021-01-26 01:25:38
|
I suppose it's not a huge deal, just I can get more resolution with webp's output
|
|
|
|
Deleted User
|
2021-01-26 01:25:43
|
The input size would also be nice to have in bytes
|
|
|
|
Orum
|
2021-01-26 01:26:04
|
stat or du can give you that, or are you talking about depth?
|
|
|
|
Deleted User
|
2021-01-26 01:27:12
|
Read 1000x1000 image, 29.3 MP/s
|
|
2021-01-26 01:27:34
|
But the file size is not reported
|
|
|
|
Orum
|
2021-01-26 01:27:51
|
you want the size of the decompressed original?
|
|
2021-01-26 01:28:31
|
one way or another you can get that from other utilities 🤷
|
|
|
|
Deleted User
|
2021-01-26 01:29:21
|
I was thinking at the input file size vs the jxl compressed size
|
|
2021-01-26 01:29:49
|
So you can make a comparison at first glance: I had a 100Kb jpg and now I have a 90kb jxl
|
|
|
|
Orum
|
2021-01-26 01:29:56
|
yeah, that'd be nice, though you can work around it with a script
|
|
|
|
Deleted User
|
2021-01-26 01:30:22
|
yeah, but it would be nice to have included
|
|
2021-01-26 01:30:26
|
for lazy people 🙂
|
|
|
|
Orum
|
2021-01-26 01:33:10
|
argh, MP/s is going to cause issues with low resolution at the slower speeds
|
|
|
|
Master Of Zen
|
2021-01-26 01:34:10
|
It's strange that jxl reports speed of opening file, like that's matters
|
|
|
|
Orum
|
2021-01-26 01:34:34
|
webp does as well, and it's nice to have both
|
|
2021-01-26 01:37:28
|
okay, so webp *does* actually support ppm input, so I'm just going to use that for both and go back to timing with `/bin/time` to compare them
|
|
|
|
Master Of Zen
|
|
Orum
okay, so webp *does* actually support ppm input, so I'm just going to use that for both and go back to timing with `/bin/time` to compare them
|
|
2021-01-26 01:47:25
|
ppm from ram disk
|
|
|
|
Orum
|
2021-01-26 01:58:07
|
it is
|
|
2021-01-26 01:59:07
|
even trying to precache the executable, as I'm not sure if that load time is counted by time
|
|
|
|
Deleted User
|
|
_wb_
I made sure jxl can do everything that tiff can do, but actually compressed
|
|
2021-01-26 02:47:51
|
Nice, so JXL supports multiple pages? How can this be done with the encoder? APNG can be passed for animations but none of the valid input formats can be used for multipages.
|
|
|
|
_wb_
|
2021-01-26 02:56:21
|
well it supports multiple frames – the distinction between animations, sequences, layers and pages is a bit blurry, but frames can have a nonzero duration (rendered as animation) or a zero duration (rendered as layers in a still image, blended together).
|
|
2021-01-26 03:03:24
|
pages could be done as zero duration frames without alpha that update the whole canvas, or as an "animation" with e.g. the maximum duration per frame (which is ~146 billion years)
|
|
2021-01-26 03:04:20
|
(so flipping between pages would technically be implemented as 'seeking' in the animation)
|
|
|
|
Deleted User
|
2021-01-26 03:27:27
|
ok, then let's hope image viewers add seeking
|
|
|
diskorduser
|
2021-01-26 03:29:10
|
Anyone had success on compiling imagemagick with jxl support?
|
|
|
|
_wb_
|
2021-01-26 03:32:43
|
I haven't tried yet
|
|
|
|
diskorduser
|
|
_wb_
I haven't tried yet
|
|
2021-01-26 03:34:39
|
I'm the same guy who asked for imagemagick support on sub-reddit few day ago. Ha Ha.
|
|
|
fab
|
2021-01-26 03:38:35
|
many people, novomesk with nomacs has complete jxl supporrt
|
|
2021-01-26 03:43:23
|
also imageglass
|
|
2021-01-26 03:43:31
|
ultra7z jxl viewer
|
|
2021-01-26 03:44:01
|
https://imageglass.org/moon
|
|
2021-01-26 03:44:10
|
https://supercompression.ru/ultra7z-jxl-converter-eng/
|
|
2021-01-26 03:44:38
|
https://www.reddit.com/r/jpegxl/comments/l4nwb2/how_to_view_jpeg_xl_images_in_nomacs_for_windows/
|
|
2021-01-26 03:45:13
|
nomacs is multicore and the only one who does good implementation scope said
|
|
2021-01-26 03:46:00
|
still i don't know the progressive support, like this thing that it does a better enlargement of image like advanced progressive 1:6 pixel❓
|
|
2021-01-26 03:46:05
|
or maybe 1:6 bits
|
|
2021-01-26 03:47:04
|
some photos stuck loading in the thumbnail explorer
|
|
2021-01-26 03:47:07
|
shift + t
|
|
2021-01-26 03:47:18
|
like 18 photos
|
|
2021-01-26 03:47:51
|
i have only two core, the program regularly goes to 620.818 720.740 kb of ram
|
|
2021-01-26 03:48:22
|
no nomacs is only a single exe is all packed in the same exe I think
|
|
2021-01-26 03:50:03
|
like the program who opens do not opens multi process
|
|
2021-01-26 03:50:13
|
i didn't checked how much nomacs.exe weights
|
|
|
|
Deleted User
|
|
fab
many people, novomesk with nomacs has complete jxl supporrt
|
|
2021-01-26 06:05:15
|
I wouldn't say that. Neither this nor Imageglass support animated JXLs.
|
|
|
|
_wb_
|
2021-01-26 06:32:19
|
tbh animation is something annoying for applications to have to take into account, and in most non-professional use cases using a video codec will almost always be a better idea for compression...
|
|
2021-01-26 06:33:38
|
Browsers should just accept h264, vp9 and av1 in an <img> tag, play it muted and looped by default, and call it a day.
|
|
|
|
OkyDooky
|
2021-01-26 06:35:34
|
<@794205442175402004>\: I remember seeing you gave a talk somewhere and had a couple of "technical details slides" (about coding tools) but the 30 minutes was already up. Have you uploaded these slides by any chance anywhere?
|
|
|
|
_wb_
|
2021-01-26 06:36:21
|
Currently Safari accepts h264 in an img tag, and Chrome accepts av1, as long as you wrap it in an avif container (producing a non-spec-compliant avif file). I wish they would at least both just accept h264, so we can kill gif already.
|
|
|
<@794205442175402004>\: I remember seeing you gave a talk somewhere and had a couple of "technical details slides" (about coding tools) but the 30 minutes was already up. Have you uploaded these slides by any chance anywhere?
|
|
2021-01-26 06:37:23
|
Here is an up to date version of those slides: https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit?usp=sharing
|
|
|
|
OkyDooky
|
2021-01-26 06:37:51
|
Awesome! Thanks
|
|
|
|
Deleted User
|
2021-01-26 06:38:09
|
hmm.. wouldn’t using full video codecs for many concurrent streams, as is a common use case for gif, come at a performance hit?
|
|
|
|
Orum
|
2021-01-26 06:41:05
|
Depends what kind of performance we're talking about. It'll be smaller (for a given quality), so network performance will be faster. H.264 is easily accelerated by most GPUs and has very efficient SW implementations, so it should be plenty fast.
|
|
|
|
lithium
|
2021-01-26 06:45:08
|
Look like in cjxl -d 0.1~0.2 -s 9 can fix my tiny ringing artefacts issue...,
but in lossy modular(lossy fuif, YCoCg, reversible Haar-like squeezing),
use -Q 90 didn't get tiny ringing artefacts issue,
if my target image is non-photographic, probably disable Loop filters(adaptive reconstruction)
or enable some flag?, can let vardct work better in non-photographic?
|
|
|
|
spider-mario
|
2021-01-26 06:50:46
|
depending on your image, you may also want to consider the delta palette
|
|
2021-01-26 06:51:24
|
though I don’t remember if we expose it through cjxl
|
|
|
|
_wb_
|
2021-01-26 06:54:21
|
I think there is an option in cjxl for it
|
|
2021-01-26 06:55:38
|
Spider-mario who are you btw? 😅
|
|
|
|
lithium
|
2021-01-26 06:57:10
|
--palette=K can use in vardct mode?
|
|
|
|
_wb_
|
2021-01-26 06:59:15
|
`cjxl -m --lossy-palette --palette=0` is the way to try delta palette I think
|
|
2021-01-26 07:01:19
|
--palette=K is only for modular mode, and it only selects the threshold of how many colors are few enough to put them in a palette — it is still lossless regardless of the value of K
|
|
|
|
lithium
|
2021-01-26 07:01:20
|
here is some image detail:
Image: 480x720 pixels | 8 bits/sample | RGB & Alpha | 35665 color(s)
Delta filter: Mixed, Chunks: iTXt, tEXt
|
|
|
|
_wb_
|
2021-01-26 07:03:16
|
That's probably too many colors to do effective exact palette, but delta palette might work well, depending on the image content (delta palette is lossy but without dct)
|
|
|
|
spider-mario
|
|
_wb_
Spider-mario who are you btw? 😅
|
|
2021-01-26 07:06:06
|
I’m Sami 😄
|
|
|
|
_wb_
|
2021-01-26 07:06:32
|
Ah ok lol
|
|
2021-01-26 07:07:08
|
I'm Jon in case you hadn't guessed by my avatar
|
|
2021-01-26 07:08:08
|
Funny how we have been working together for two years now but I still don't know nicknames
|
|
|
|
lithium
|
2021-01-26 07:11:06
|
--lossy-palette break alpha channel...
|
|
2021-01-26 07:11:41
|
cjxl -m --lossy-palette --palette=0 -s 9
|
|
|
|
spider-mario
|
|
_wb_
Funny how we have been working together for two years now but I still don't know nicknames
|
|
2021-01-26 07:12:12
|
in all fairness, I usually don’t use this one at work
|
|
|
lithium
--lossy-palette break alpha channel...
|
|
2021-01-26 07:12:29
|
oh, right, I don’t think we account for alpha in that mode
|
|
2021-01-26 07:13:01
|
the breakage is in the alpha channel itself, right?
|
|
|
|
lithium
|
2021-01-26 07:13:41
|
yes, image is fine
|
|
2021-01-26 07:14:00
|
only alpha channel break
|
|
|
|
_wb_
|
2021-01-26 07:16:41
|
Should be an easy fix - have to make sure we only do delta palette on channels 0-2 and leave other channels alone
|
|
2021-01-26 07:16:59
|
(or also do it on alpha but properly then)
|
|
|
|
spider-mario
|
2021-01-26 07:17:24
|
it seems we have a branch for this (enc_modular.cc:545 or thereabouts) that is supposed to do that, but also another branch before that that does it on everything
|
|
|
|
lithium
|
2021-01-26 07:17:55
|
probably we can use lossy fuif in -d flag in next jpeg xl?
|
|
|
|
_wb_
|
2021-01-26 07:18:41
|
Lossy fuif is e.g. -m -Q 80
|
|
2021-01-26 07:19:50
|
Or I guess -m -Q 80 -c 1, since by default lossy modular now uses XYB which didn't exist in fuif
|
|
|
|
lithium
|
2021-01-26 07:27:58
|
lossy modular is very well, but in comic type(black and white) image, vardct work better
|
|
|
|
_wb_
|
2021-01-26 07:36:35
|
There is a lot of stuff the encoder could potentially do that is not yet implemented. Like use a mix of splines, modular patches, and vardct for such images. Just kind of hard to make an encoder that fully uses the bitstream capabilities...
|
|
|
|
OkyDooky
|
2021-01-26 08:06:06
|
Is it OK if I ask about technical details on JXLs inner workings?
|
|
|
|
_wb_
|
|
|
OkyDooky
|
2021-01-26 08:08:22
|
Thanks. I've gatherd bits and pieces here and there (the Applications of Digital Image Processing proceedings papers is somewhat informative but apparently dated?). The way I understand it, the purpose of the "modular" mode is to offer a "progressive" mode as well as lossless coding, right?
|
|
2021-01-26 08:08:56
|
But does the "lossy mode" (the one for photos) also offer a "progressive feature"?
|
|
2021-01-26 08:09:34
|
AFAIU, it does based on transmitting first DC levels and then refinement layers with more and more ACs
|
|
2021-01-26 08:09:38
|
(at least optionally?)
|
|
|
|
_wb_
|
2021-01-26 08:09:40
|
Yes
|
|
2021-01-26 08:09:55
|
Both modes can do progressive
|
|
|
|
OkyDooky
|
2021-01-26 08:10:46
|
OK. is the lossy mode restricted to 1\:8 or is the squeeze transform applied on the lossy mode's DCs to further reduce the amount of data/resolution ?
|
|
|
|
_wb_
|
2021-01-26 08:10:49
|
VarDCT is even always somewhat progressive because DC (or rather 1:8, which is not quite the same if not all blocks are 8x8) is always signalled first
|
|
2021-01-26 08:11:17
|
Squeeze can be applied to DC, that's what cjxl --progressive_dc does
|
|
|
|
OkyDooky
|
2021-01-26 08:11:47
|
OK, Cool ... and that at the lowest layer I guess these backward-adaptive predictors come into play?
|
|
2021-01-26 08:11:55
|
at the lowest level
|
|
2021-01-26 08:11:59
|
(resolution)
|
|
|
|
_wb_
|
2021-01-26 08:12:17
|
Yes, or if you do non-progressive lossless
|
|
|
|
OkyDooky
|
2021-01-26 08:12:47
|
Sure, then, it's applied on the 1\:8 DC levels, I guess?
|
|
|
|
_wb_
|
2021-01-26 08:12:53
|
If you do squeeze, the best predictor is actually usually just the zero predictor since the residuals tend to be mostly zetoes
|
|
2021-01-26 08:13:13
|
Lossless doesn't use VarDCT
|
|
|
|
OkyDooky
|
2021-01-26 08:13:46
|
uhm, predictor for what exactly? the "residuals" or the low-frequency band?
|
|
|
|
_wb_
|
2021-01-26 08:14:12
|
Default VarDCT just encodes the 1:8 in a non-progressive way with fancy predictors
|
|
|
|
OkyDooky
|
2021-01-26 08:14:22
|
asking because the squeeze gives you two and one is just a low res version
|
|
|
|
_wb_
|
2021-01-26 08:15:16
|
If you do squeeze on the 1:8, the squeeze residuals don't require fancy prediction since 0 is the best prediction for them
|
|
|
|
OkyDooky
|
2021-01-26 08:15:32
|
yeah, OK, I seem to have missed the word "residual" in your squeeze answer....
|
|
2021-01-26 08:15:52
|
of course, makes total sense... that's why you made it "nonlinear" ;) to get a lot of zeros, I guess
|
|
|
|
_wb_
|
2021-01-26 08:15:53
|
Squeeze is applied recursively on the low res versions, until basically everything is residuals
|
|
|
|
OkyDooky
|
2021-01-26 08:16:43
|
Oh, really? OK, that is news to me. I thought maybe it stops at some level and that level is encoded using "fancy predictors"
|
|
|
|
_wb_
|
2021-01-26 08:16:47
|
You have at most 8x8 pixels total that are NOT residuals but a low res version
|
|
2021-01-26 08:17:03
|
Yes, it stops there - at least by default
|
|
2021-01-26 08:17:08
|
Can make it stop earlier
|
|
2021-01-26 08:18:05
|
Modular can do quite a lot
|
|
|
|
OkyDooky
|
2021-01-26 08:18:54
|
...and when you say "Modular" mode, you basically mean this squeeze thing?
|
|
|
|
_wb_
|
2021-01-26 08:19:16
|
It's everything that is not VarDCT, basically
|
|
2021-01-26 08:19:26
|
Squeeze is optional
|
|
|
|
OkyDooky
|
2021-01-26 08:19:41
|
OK, then I guess, I don't understand what the modular mode is.
|
|
|
|
_wb_
|
2021-01-26 08:19:54
|
Palette can also be done, and it is a pretty generic palette transform
|
|
2021-01-26 08:20:00
|
And there are RCTs
|
|
2021-01-26 08:20:21
|
These can be combined in various ways
|
|
2021-01-26 08:20:42
|
The chain of transforms to be applied is signaled
|
|
2021-01-26 08:20:49
|
Hence "modular"
|
|
|
|
OkyDooky
|
2021-01-26 08:21:04
|
ah.. I see
|
|
2021-01-26 08:21:23
|
which transforms does this cover besides color transforms and squeeze?
|
|
|
|
_wb_
|
2021-01-26 08:22:17
|
Palette, which includes a delta palette option
|
|
2021-01-26 08:22:42
|
Can also be used for channel palettes
|
|
|
|
OkyDooky
|
2021-01-26 08:22:52
|
"generic palette transform" is another, I guess ... (but I don't really know what it does, lol)
|
|
|
|
_wb_
|
2021-01-26 08:24:43
|
It's like the usual GIF/PNG8, except not limited to 256 colors, can be done on an arbitrary number of channels, and palette 'colors' can also be a difference vector w.r.t. a predictor instead of an absolute color
|
|
2021-01-26 08:26:07
|
The main power of modular mode though is its very flexible context model and entropy coder
|
|
|
|
OkyDooky
|
2021-01-26 08:29:24
|
I see ... this difference vector palette sounds complicated ... has this been implemented?
|
|
2021-01-26 08:29:44
|
(for lossy, lossless or both?)
|
|
2021-01-26 08:31:31
|
anyways, not important. I think I have a reasonably good idea of what's going on within JXL. Thank you for the explanations!
|
|
|
|
_wb_
|
2021-01-26 08:41:35
|
Delta palette is implemented, yes. It's a form of lossy modular without squeeze.
|
|
|
|
OkyDooky
|
2021-01-26 08:43:03
|
OK. Your "without squeeze" comment makes me thing that this transform is not applicable for "palette images", right?
|
|
2021-01-26 08:43:23
|
(At least, I wouldn't know how this should work)
|
|
2021-01-26 08:43:38
|
[Edit](https://discordapp.com/channels/794206087879852103/794206170445119489/803726723598123038): OK. Your "without squeeze" comment makes me think that this transform is not applicable for "palette images", right?
|
|
|
|
_wb_
|
2021-01-26 08:48:34
|
It's useful to do full-color images in a near-lossless way, like 5bpp for a typical photo which would be 10bpp losslessly.
|
|
|
lonjil
|
2021-01-26 09:53:29
|
Hm, what exactly is AFV in VarDCT?
|
|
|
|
_wb_
|
2021-01-26 10:27:45
|
it's a DCT with a special handling of one of the four corners
|
|
|
|
Deleted User
|
|
_wb_
tbh animation is something annoying for applications to have to take into account, and in most non-professional use cases using a video codec will almost always be a better idea for compression...
|
|
2021-01-27 12:10:12
|
Well, but not for me and my "screenshots" ;)
|
|
2021-01-27 12:10:45
|
|
|
2021-01-27 12:10:54
|
Almost three times as big (both lossless RGB with highest compression):
|
|
2021-01-27 12:11:28
|
<@!794205442175402004> btw, even Cloudinary won't allow uploading animated JXLs.
|
|
|
_wb_
Browsers should just accept h264, vp9 and av1 in an <img> tag, play it muted and looped by default, and call it a day.
|
|
2021-01-27 12:11:53
|
This would be rad!
|
|
|
|
lonjil
|
2021-01-27 12:48:03
|
does it?
|
|
|
Artoria2e5
|
|
_wb_
Browsers should just accept h264, vp9 and av1 in an <img> tag, play it muted and looped by default, and call it a day.
|
|
2021-01-27 12:49:04
|
I opened an issue on MDN. I might write a PR for that. (If it was the old days when MDN was still a wiki, I would've done it right away.) https://github.com/mdn/content/issues/1777
|
|
2021-01-27 12:53:16
|
There is one on `video`. The issue with `video` is that autoplay is (for reasons we all know) often suppressed, the preloading isn't done, and that it might do other weird things like stopping the computer from sleeping.
|
|
|
_wb_
Currently Safari accepts h264 in an img tag, and Chrome accepts av1, as long as you wrap it in an avif container (producing a non-spec-compliant avif file). I wish they would at least both just accept h264, so we can kill gif already.
|
|
2021-01-27 12:56:38
|
Wait, does AVIF not have interframe compression or…?
|
|
|
|
Master Of Zen
|
2021-01-27 02:58:23
|
btw, that's strange that `cjxl` doesn't give any type of prompt if you don't specify output file
|
|
2021-01-27 02:58:38
|
it's just transcodes to nothing)
|
|
|
|
Orum
|
2021-01-27 05:06:36
|
fine by me
|
|
2021-01-27 05:08:07
|
might be a bit nicer if it just output to the same base name with a .jxl extension though
|
|
|
Nova Aurora
|
2021-01-27 05:32:12
|
Is there a way to tell if an image was losslessly encoded after the fact?
|
|
|
|
Orum
|
2021-01-27 05:37:09
|
you mean lossless recompression or using pure lossless?
|
|
|
|
Nova Aurora
|
2021-01-27 05:38:07
|
either really
|
|
2021-01-27 05:38:28
|
mostly transcoding in these early days though
|
|
|
|
Orum
|
2021-01-27 05:40:59
|
well you can look for modular encoding, but since lossy modular exists, it's hard to say
|
|
2021-01-27 05:42:21
|
as for recompression, that's still DCT, so you could probably tell if it was a jpg based on the methods used to compress (though maybe not from `cjxl -s 3`)
|
|
2021-01-27 05:44:23
|
hopefully -s 3 won't be used in practice though, as the other speeds are still quite fast until you get past squirrel
|
|
|
|
Nova Aurora
|
2021-01-27 05:44:48
|
So there's no simple way to do it and a hacky way to say *its probably this but we don't know*
|
|
|
|
Orum
|
2021-01-27 05:45:37
|
well, even lossy PNG exists, so you can never truly say "this is lossless" or "this isn't" unless you can trace the image from creation to present
|
|
2021-01-27 05:46:06
|
you can look for hints that it was lossily compressed at one point by looking for artifacts
|
|
|
|
Nova Aurora
|
|
|
Orum
|
2021-01-27 05:50:34
|
the artifacts will look different depending on the lossy compression used though, so it's non-trivial to look for all of them, and it's somewhat content-dependent
|
|
|
|
Nova Aurora
|
2021-01-27 05:56:14
|
Jpeg artifacts are obvious, while webp, being a video codec originally tends to smooth things out, what do jxl artifacts look like?
|
|
|
|
Orum
|
2021-01-27 05:59:02
|
Webp can still be blocky, similar to jpg, but it looks a bit different. JXL artifacts depend on which method of lossy was used (VarDCT or lossy modular).
|
|
2021-01-27 06:02:17
|
VarDCT tends to block like jpg, while lossy modular tends to oversmooth like avif
|
|
|
|
Nova Aurora
|
2021-01-27 06:04:46
|
ok, thanks for your time listening to my inane questions
|
|
|
|
_wb_
|
|
Master Of Zen
btw, that's strange that `cjxl` doesn't give any type of prompt if you don't specify output file
|
|
2021-01-27 06:34:50
|
That's for benchmarking encode speed without counting disk writing
|
|
|
Nova Aurora
Is there a way to tell if an image was losslessly encoded after the fact?
|
|
2021-01-27 06:36:42
|
No. You can always make an image as lossy as you want, turn it into a PNG, and pretend that *that* is the original image you are losslessly encoding.
|
|
2021-01-27 06:41:25
|
There is something new called the content authenticity initiative, which might one day give a way to tell an image is truly lossless (it involves authenticated cameras that cryptographically sign pixels at capture time). But the short answer right now is "no".
|
|
|
Artoria2e5
Wait, does AVIF not have interframe compression or…?
|
|
2021-01-27 06:43:28
|
I think the avif spec says the "still image" bit has to be set in the av1 bitstream header.
|
|
|
<@!794205442175402004> btw, even Cloudinary won't allow uploading animated JXLs.
|
|
2021-01-27 06:47:55
|
Correct, and we also don't produce animated jxl yet. We will add that, but it's not a high priority. I don't expect there to be any browser that supports jxl but not some other codec that is better for video. GIF should not be replaced by animated jxl imo, but by video.
|
|
2021-01-27 06:52:58
|
It's a bit late for that, the web already supports animation in <img> for more than two decades now. It's just that you have to use an "image" codec for it (GIF, animated WebP, animated PNG). And that is silly, they should also support video codecs and video container formats where the audio track just gets ignored.
|
|
2021-01-27 08:10:12
|
those sizes are after decoding to PNG, I assume – is the jxl the same size as the jpeg here?
|
|
2021-01-27 08:20:50
|
yes, that's `cjxl -j`
|
|
2021-01-27 08:26:13
|
try verbose help
|
|
2021-01-27 08:26:17
|
-v -v -v -h
|
|
|
|
Master Of Zen
|
2021-01-27 09:20:01
|
Resize first
|
|
|
improver
|
|
_wb_
Correct, and we also don't produce animated jxl yet. We will add that, but it's not a high priority. I don't expect there to be any browser that supports jxl but not some other codec that is better for video. GIF should not be replaced by animated jxl imo, but by video.
|
|
2021-01-27 12:31:12
|
for videos-encoded-as-gif I agree, but I don't like that idea for lossless vector-like / pixelart kind of gifs
|
|
2021-01-27 12:33:08
|
current video codecs are just not very suited for lossless vector-like kind of stuff I think, and it always bothers me when some sites re-encode these to something like mp4 anyway
|
|
|
|
_wb_
|
2021-01-27 12:37:36
|
Agreed
|
|
2021-01-27 12:38:22
|
Animated svg or css animations might be best for that, but not always possible
|
|
|
|
improver
|
2021-01-27 12:41:20
|
image formats are more performant to decode/render though. maybe if we had something like lightsvg which didn't involve xml/css...
|
|
|
|
_wb_
|
2021-01-27 12:43:49
|
Well, we do have splines in jxl, currently unused in the encoder but implemented in the decoder
|
|
2021-01-27 12:45:08
|
So some kinds of vector graphics can actually be represented in jxl, quite limited though to basically bezier curves of variable thickness and color without fill
|
|
|
|
improver
|
2021-01-27 12:45:51
|
limited svg2jxl converter would be interesting
|
|
2021-01-27 12:46:18
|
i suspect fill wouldn't be hard to be added in different way
|
|
2021-01-27 12:46:53
|
though these wouldn't be very vector-ish..
|
|
|
|
_wb_
|
2021-01-27 12:47:46
|
Rough solid blob shapes are cheap with modular, add sufficiently thick splines to get the edges right...
|
|
2021-01-27 12:48:34
|
Solid or gradient
|
|
|
|
Deleted User
|
2021-01-27 12:49:12
|
Basic vector graphics with jxl would be so cool
|
|
|
|
improver
|
2021-01-27 12:51:44
|
it would lose part of what makes vector graphics useful in some situations (resolution independence), but if that's not needed it does sound kinda like very efficient way to render svg to jxl
|
|
2021-01-27 12:52:18
|
though in some situations it's possible that it'd end up being less efficient
|
|
|
|
_wb_
|
2021-01-27 01:07:24
|
well the splines could probably be rendered at other resolutions too, right <@!604964375924834314> ?
|
|
|
|
spider-mario
|
2021-01-27 01:15:24
|
yes, in fact I think we already implemented that at some point
|
|
2021-01-27 01:19:14
|
the spline data is just control points (interpolated with catmull-rom) + DCT of color and thickness
|
|
|
|
_wb_
|
2021-01-27 01:21:20
|
yes, when zooming in on the original, the blocks and dct base patterns are quite clear
|
|
2021-01-27 01:22:24
|
probably not even a very high quality one, maybe libjpeg q75 or so
|
|
2021-01-27 01:22:59
|
so jxl is probably spending some bits on trying to preserve those artifacts
|
|
2021-01-27 01:26:24
|
or maybe a bit higher than libjpeg q75, but it does look like it has been 4:2:0 and certainly some significant dct quantization
|
|
2021-01-27 01:26:53
|
i'd estimate q80 or so
|
|
|
|
Master Of Zen
|
2021-01-27 01:35:14
|
It's photoshops jpeg btw
|
|
2021-01-27 01:35:41
|
and back in a day when newest one was cs6
|
|
2021-01-27 01:37:06
|
By the way, VVC
|
|
2021-01-27 01:38:17
|
it have still picture mode and from my test have ~10% bit rate save in PSRN/SSIM over av1
|
|
2021-01-27 01:47:40
|
Running the frog pic, and it's ... interesting
|
|
2021-01-27 01:47:57
|
over 30 min of cpu time on single frame with slower preset
|
|
|
|
Deleted User
|
2021-01-27 01:55:51
|
how is the size vs jpg and vs jxl?
|
|
|
|
Master Of Zen
|
2021-01-27 01:57:51
|
Running right now
|
|
2021-01-27 01:58:36
|
PNG's are HUGE
|
|
2021-01-27 01:58:49
|
**Faster**
~4 sec
|
|
2021-01-27 01:58:57
|
|
|
2021-01-27 01:59:37
|
vvc doesn't even support y4m or pipes, so I run everything with yuv's
|
|
2021-01-27 02:01:05
|
```
POC 0 TId: 0 ( I-SLICE, QP 29 ) 1496056 bits [Y 40.1813 dB U 42.8403 dB V 46.6483 dB] [ET 4 ] [L0 ] [L1 ]
Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR YUV-PSNR
1 a 89763.3600 40.1813 42.8403 46.6483 41.1797```
|
|
2021-01-27 02:02:41
|
**Medium**
23.573 sec
```POC 0 TId: 0 ( I-SLICE, QP 29 ) 1494552 bits [Y 40.5661 dB U 43.1376 dB V 47.0532 dB] [ET 23 ] [L0 ] [L1 ]
Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR YUV-PSNR
1 a 89673.1200 40.5661 43.1376 47.0532 41.5554```
|
|
2021-01-27 02:04:06
|
|
|
2021-01-27 02:04:15
|
|
|
2021-01-27 02:08:52
|
**Slower**
127.622 sec
```
POC 0 TId: 0 ( I-SLICE, QP 29 ) 1493512 bits [Y 40.6433 dB U 43.0980 dB V 47.0685 dB] [ET 127 ] [L0 ] [L1 ]
Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR YUV-PSNR
1 a 89610.7200 40.6433 43.0980 47.0685 41.6160
finished @ Wed Jan 27 16:07:15 2021```
|
|
2021-01-27 02:08:56
|
|
|
2021-01-27 02:10:03
|
|
|
|
|
Deleted User
|
2021-01-27 02:10:08
|
so around 182KB
|
|
|
|
Master Of Zen
|
2021-01-27 02:11:05
|
For jxl, it's ~`cjxl frog.jpeg frog.jxl -s 9 -d 8.3 -j`
|
|
2021-01-27 02:23:07
|
```
> cjxl frog.jpeg frog.jxl -s 8 -d 7.3 -j
J P E G \/ |
/\ |_ e n c o d e r [v0.2.0 | SIMD supported: AVX2,SSE4,Scalar]
Read 3072x2048 image, 88.4 MP/s
Encoding [VarDCT, d7.300, kitten], 6 threads.
Compressed to 188502 bytes (0.240 bpp).
3072 x 2048, 0.47 MP/s [0.47, 0.47], 1 reps, 6 threads.
> cjxl frog.jpeg frog.jxl -s 9 -d 7.3 -j
J P E G \/ |
/\ |_ e n c o d e r [v0.2.0 | SIMD supported: AVX2,SSE4,Scalar]
Read 3072x2048 image, 88.9 MP/s
Encoding [VarDCT, d7.300, tortoise], 6 threads.
Compressed to 285530 bytes (0.363 bpp).
3072 x 2048, 0.05 MP/s [0.05, 0.05], 1 reps, 6 threads.```
-s 8 and -s 9 result in big size difference with same -d 🤔
|
|
2021-01-27 02:24:06
|
https://slow.pics/c/iZ2nJPoF
|
|
2021-01-27 02:25:56
|
It's not vvc, but fact of multiple file conversions, which don't keep color profile etc
|
|
2021-01-27 02:26:45
|
IMO VVC really really good
|
|
2021-01-27 02:28:14
|
disagree
|
|
2021-01-27 02:30:40
|
jxl have better blur, little bit, but all high detail stuff is way better on vvc
|
|
2021-01-27 02:33:00
|
Btw all commands
```
vvencapp --profile main10_stillpic --tier high --preset slower --qpa 0 -i frog.yuv --qp 32 -f 1 -s 3072x2048 -o img.h266 -c yuv420_10
vvdecapp -b img.h266 -o img.yuv
ffmpeg -s 3072x2048 -pix_fmt yuv420p10le -i img.yuv img.png ```
|
|
|
|
OkyDooky
|
2021-01-27 02:33:37
|
I just looked at the frog image (your jpeg xl vs VVC comparison) and to me, apart from the obvious color conversion error (wrong primaries?) the VVC image looks really good
|
|
|
|
Master Of Zen
|
2021-01-27 02:37:56
|
Without patch of blur (and looking only at the frog) I would assume they are same image, one just washed out
|
|
2021-01-27 02:38:13
|
|
|
|
|
_wb_
|
2021-01-27 02:40:33
|
I don't know much about VVC but I suppose it will be very much not royalty-free
|
|
|
|
Master Of Zen
|
|
_wb_
I don't know much about VVC but I suppose it will be very much not royalty-free
|
|
2021-01-27 02:41:22
|
if you nice enough, they will allow you to read high profile spec
|
|
|
|
OkyDooky
|
2021-01-27 02:41:33
|
there are already four companies trying to work as a patent pool for VVC.
|
|
|
|
_wb_
|
2021-01-27 02:42:40
|
yes, it is. For some use cases that may be what you want
|
|
|
|
Master Of Zen
|
2021-01-27 02:42:52
|
I used -d 7 to have equal sizes
|
|
|
|
_wb_
|
2021-01-27 02:43:04
|
I personally like -d 2-3 for the web and -d 1 or below for archival
|
|
|
|
Master Of Zen
|
2021-01-27 02:43:36
|
so images are 182 kb vvc and 184 jxl
|
|
|
|
_wb_
|
2021-01-27 02:43:36
|
video codecs are designed to make low bitrate look nice
|
|
|
|
Master Of Zen
|
2021-01-27 02:43:40
|
right
|
|
|
_wb_
video codecs are designed to make low bitrate look nice
|
|
2021-01-27 02:44:43
|
yep yep, read your appeal/fidelity post, amount of blur that video codes introduce is abnormal
|
|
|
|
_wb_
|
2021-01-27 02:45:05
|
did you like that blogpost?
|
|
|
|
Master Of Zen
|
|
_wb_
did you like that blogpost?
|
|
2021-01-27 02:47:43
|
yes, it was good.
And for me, I never distinct quality to appeal and fidelity, never though about visual perception in that way tbh
|
|
|
|
_wb_
|
2021-01-27 02:50:27
|
low-fidelity is interesting and has its use cases, but it's easy to make the mistake of comparing codecs at low-fidelity and then extrapolating too much – codec A can beat codec B at low-fidelity, but it can be the other way around at high-fidelity bitrates
|
|
|
|
Master Of Zen
|
2021-01-27 02:54:50
|
Giving VVC vs JXL a second look, I now noticed how much VVC blurs everything that is not high frequency data, while JXL distribute bits across the whole image
|
|
2021-01-27 02:56:31
|
Appeal bias is strong(
|
|
|
|
_wb_
|
2021-01-27 02:56:57
|
appeal is, you know, appealing 🙂
|
|
|
|
lonjil
|
2021-01-27 02:57:43
|
Last year, when the `cbrunsli` utility was still included, I tried and failed to successfully verify that it would actually give me the same pixels again.
|
|
2021-01-27 02:58:31
|
Could someone tell me a series of commands that should losslessly recompress a jpeg, and then re-produce the same jpeg, so that I can test how well it works?
|
|
|
|
spider-mario
|
|
lonjil
Could someone tell me a series of commands that should losslessly recompress a jpeg, and then re-produce the same jpeg, so that I can test how well it works?
|
|
2021-01-27 02:59:21
|
cjxl input.jpeg compressed.jxl
djxl --jpeg compressed.jxl decompressed.jpg
|
|
2021-01-27 02:59:26
|
that should do it
|
|
|
|
lonjil
|
2021-01-27 02:59:33
|
alright
|
|
2021-01-27 03:10:40
|
eyy it works woo
|
|
|
march
|
2021-01-27 03:26:56
|
Does anyone here know if there is something like flifcrush (a bruteforce flif optimiser) but for JPEG XL?
|
|
|
|
_wb_
|
2021-01-27 03:27:49
|
not afaik
|
|
2021-01-27 03:28:27
|
but if someone wants to do that, I'd like to just have that as `-s 10` or `-s 11` 🙂
|
|
2021-01-27 03:28:48
|
https://tenor.com/view/spinal-tap-numbers-go-to11-gif-4660832
|
|
|
|
march
|
2021-01-27 03:29:25
|
Because I currently achieve better results with FLIF for pixelart
|
|
2021-01-27 03:31:42
|
The FLIF version is 5.1KB and the JPEG XL one is 6.5KB
|
|
|
|
lonjil
|
2021-01-27 03:32:03
|
what options did you use for JXL?
|
|
|
|
_wb_
|
2021-01-27 03:32:56
|
here's a simple jxlcrush you can try: `for i in 0 1 2 3; do cjxl -q 100 -s 9 -E 3 -g $i input.png output-$i.jxl; done`
|
|
|
|
march
|
|
lonjil
what options did you use for JXL?
|
|
2021-01-27 03:33:29
|
Good Question...I have tried the CLI and the squoosh web app
|
|
|
_wb_
here's a simple jxlcrush you can try: `for i in 0 1 2 3; do cjxl -q 100 -s 9 -E 3 -g $i input.png output-$i.jxl; done`
|
|
2021-01-27 03:36:53
|
Ok, now it's only 5.8KB
|
|
|
|
_wb_
|
2021-01-27 03:43:01
|
hm, still bigger than flif? can happen, but can you send me the image and let me try?
|
|
|
|
march
|
2021-01-27 03:44:35
|
The FLIF file or the original PNG file?
|
|
|
|
_wb_
|
2021-01-27 03:45:02
|
whatever 🙂
|
|
|
|
march
|
2021-01-27 03:45:58
|
Context: I am trying to embed several Minecraft skins into one
|
|
|
|
_wb_
|
2021-01-27 03:46:43
|
this is not the 5.1 KB image though?
|
|
|
|
march
|
2021-01-27 03:46:55
|
Oh wait
|
|
2021-01-27 03:47:02
|
It's the wrong one
|
|
2021-01-27 03:47:20
|
|
|
|
|
_wb_
|
2021-01-27 03:50:02
|
adding `-I 1` also helps btw
|
|
|
|
march
|
|
_wb_
adding `-I 1` also helps btw
|
|
2021-01-27 03:53:26
|
What does it do?
|
|
|
|
_wb_
|
2021-01-27 03:56:29
|
looking at all data to learn a Meta-Adaptive tree
|
|
2021-01-27 03:57:22
|
basically `-I` in cjxl is the same as `-R` in flif, except we use a different tree learning method
|
|
2021-01-27 04:05:51
|
the palette order probably makes most of the difference here
|
|
2021-01-27 04:06:13
|
we don't try to optimize that yet
|
|
|
|
lithium
|
2021-01-27 04:31:22
|
-i flag not in cjxl -h -v -v?
|
|
|
|
Scope
|
2021-01-27 04:33:58
|
``` -I F, --iterations=F
[modular encoding] fraction of pixels used to learn MA trees (default=0.5, try 0 for no MA and fast decode)```
|
|
|
|
lithium
|
2021-01-27 04:36:52
|
oh, sorry this my mistake... -h -v -v and -h -v is different
|
|
2021-01-27 04:37:19
|
thanks you 🙂
|
|
2021-01-27 04:48:17
|
About non-photographic image tiny ringing artefacts and noise issue in vardct mode,
use --epf=3 can reduce tiny ringing artefacts, but some image still have noise issue,
probably need enable or disable some flag can reduce noise in vardct mode?
|
|
2021-01-27 05:00:36
|
cjxl -d 0.8 -s 9 --epf=3
|
|
|
|
Orum
|
2021-01-27 06:37:28
|
is there a way to specify output format to djxl when decoding to stdout?
|
|
|
|
_wb_
|
2021-01-27 06:40:07
|
How do you decode to stdout?
|
|
|
|
Orum
|
2021-01-27 06:40:48
|
oh, I guess it doesn't let me
|
|
2021-01-27 06:41:05
|
I was hoping `djxl foo.jxl -` would
|
|
|
|
_wb_
|
2021-01-27 06:41:33
|
We should probably add that, and some way to choose the format
|
|
2021-01-27 06:42:24
|
That's just a boring thing to do so nobody bothered yet 😅
|
|
|
|
Orum
|
2021-01-27 06:43:36
|
Just trying to benchmark decode, so it's somewhat useful. I suppose I can just use no output, but I'm also trying to compare it to webp and I'm not sure if giving no output to dwebp actually does decoding of the image.
|
|
2021-01-27 06:43:59
|
I guess I'll look through webp's code again to see what it actually does.
|
|
|
|
fab
|
2021-01-27 06:45:32
|
how is -q 84.4 -s 7
in jxl
|
|
|
|
Orum
|
2021-01-27 06:46:09
|
What do you mean? It's what speed 7 quality 84.4 looks like...
|
|
|
|
fab
|
2021-01-27 06:48:46
|
the current state
|
|
2021-01-27 06:48:59
|
what i can expect with next release...
|
|
|
|
lithium
|
2021-01-27 06:49:08
|
probably like jpeg quality 84?
(Positive quality values roughly match libjpeg quality)
|
|
|
|
fab
|
2021-01-27 06:49:26
|
yes
|
|
2021-01-27 06:49:37
|
but i mean in quality
|
|
2021-01-27 06:49:49
|
not difference to the photo
|
|
2021-01-27 06:49:58
|
like butteraugli distortions
|
|
2021-01-27 06:50:01
|
but normal quality
|
|
2021-01-27 06:50:21
|
does it look better than the same jpg or wp2 encoded at that quality?
|
|
|
|
_wb_
|
2021-01-27 06:50:36
|
Depends on the image
|
|
|
|
fab
|
2021-01-27 06:50:42
|
are there improvements with next release, what is the current state
|
|
2021-01-27 06:50:45
|
ok
|
|
|
|
_wb_
|
2021-01-27 06:51:14
|
In jxl, quality refers to perceptual distance so it is quite consistent
|
|
2021-01-27 06:52:20
|
But in jpeg, avif, webp, webp2, etc, "quality" is just amount of quantization or at best psnr/ssim target, which perceptually gives inconsistent results
|
|
|
|
Orum
|
2021-01-27 06:52:33
|
yeah, use -d instead of -q
|
|
|
|
_wb_
|
2021-01-27 06:52:59
|
In some images, q60 jpeg is fine, while in others, q85 has visible artifacts
|
|
|
|
fab
|
2021-01-27 06:53:06
|
like i mean is high enough
|
|
2021-01-27 06:53:10
|
q 84.4
|
|
2021-01-27 06:53:19
|
i know that is similar to q84 no difference
|
|
|
|
Orum
|
2021-01-27 06:53:28
|
depends on the image
|
|
|
|
lithium
|
2021-01-27 06:53:32
|
you can use ssimulacra and dssim to compare image
|
|
|
|
fab
|
2021-01-27 06:53:47
|
are there improvements?
|
|
|
|
Orum
|
2021-01-27 06:54:05
|
you probably don't need that sort of precision for quality though (1000 levels)
|
|
|
|
_wb_
|
2021-01-27 06:54:36
|
Depends on what kind of fidelity you want. -q 90 or -d 1 is roughly one unit of just-noticable difference in the worst areas
|
|
|
|
fab
|
2021-01-27 06:54:53
|
not faces
|
|
|
|
_wb_
|
2021-01-27 06:55:07
|
When viewed at a distance of 900 pixels
|
|
|
|
fab
|
2021-01-27 06:55:07
|
i accept butteraugli distortion
|
|
|
|
_wb_
|
|
|
fab
|
2021-01-27 06:55:12
|
as long the image looks better
|
|
2021-01-27 06:55:21
|
with next releases
|
|
|
|
_wb_
|
2021-01-27 06:56:27
|
If you want the image to look better than -q 84.4, try -q 90 -s 8
|
|
|
|
fab
|
2021-01-27 06:56:41
|
ok
|
|
2021-01-27 06:57:02
|
but i'm interested in better quality than other encoders at -q 84.4 -s 7
|
|
2021-01-27 06:57:07
|
or -q 84
|
|
2021-01-27 06:57:11
|
improvements
|
|
|
|
lithium
|
2021-01-27 07:00:02
|
about compare other encoder, you can see this post
|
|
2021-01-27 07:00:04
|
https://kornel.ski/en/faircomparison
|
|
|
|
fab
|
2021-01-27 07:00:18
|
are you jxl developer?
|
|
|
|
lithium
|
|
|
fab
|
|
|
lithium
|
2021-01-27 07:00:46
|
i'm jxl fan 🙂
|
|
|
|
_wb_
|
2021-01-27 07:01:31
|
Comparing at same file size is best
|
|
|
|
lithium
|
2021-01-27 07:08:32
|
<@!794205442175402004> Could you teach me about Edge preserving filter?
|
|
|
|
Orum
|
2021-01-27 07:10:10
|
Hrm, it also seems a bit inconsistent when printing output from djxl. For example, `Allocations: 1422 (max bytes in use: 3.950375E+08)` is printed to stdout while everything else is printed to stderr
|
|
|
|
BlueSwordM
|
|
lithium
<@!794205442175402004> Could you teach me about Edge preserving filter?
|
|
2021-01-27 07:11:01
|
I know you're not the one you're talking to, but if you want to learn about a very powerful filter, you can read this article about CDEF in AV1: https://hacks.mozilla.org/2018/06/av1-next-generation-video-the-constrained-directional-enhancement-filter/
|
|
2021-01-27 07:11:21
|
It talks about edge filtering, loop filtering, and the CDEF directional filter. Not exactly related to JPEG-XL, but it should help a bit.
|
|
|
|
lithium
|
|
BlueSwordM
It talks about edge filtering, loop filtering, and the CDEF directional filter. Not exactly related to JPEG-XL, but it should help a bit.
|
|
2021-01-27 07:12:25
|
thanks you very much 🙂
|
|
|
|
_wb_
|
2021-01-27 07:45:17
|
CDEF is different from epf
|
|
2021-01-27 07:45:35
|
Epf is more like a bilateral filter
|
|
2021-01-27 07:46:07
|
But I didn't design it so I am not the best one to explain how it works
|
|
2021-01-27 07:51:40
|
<@179701849576833024> can you explain epf?
|
|
|
|
veluca
|
2021-01-27 07:59:02
|
in the simplest terms, you can think of it as a sort of selective gaussian filter with a threshold that depends on local quality
|
|
2021-01-27 08:00:22
|
it's not really a selective gaussian filter (the weight of each pixel depends on the color distance, rather than pixel distance), and it operates in multiple stages, but that's approximatively what is going on
|
|
|
|
_wb_
|
2021-01-27 08:03:58
|
I wonder if it would make sense to run it as a preprocessing step as a denoising filter
|
|
2021-01-27 08:04:53
|
In the encoder, or even just as an image manipulation in general
|
|
|
|
Deleted User
|
2021-01-27 08:44:45
|
<@&803357352664891472> Speaking of pixelart, is there any (hidden) way to tell cjxl that the input is integer upscaled by a given factor, so that the encoder can utilize this property? Such pixel art files would see quite a size improvement.
|
|
|
|
march
|
|
<@&803357352664891472> Speaking of pixelart, is there any (hidden) way to tell cjxl that the input is integer upscaled by a given factor, so that the encoder can utilize this property? Such pixel art files would see quite a size improvement.
|
|
2021-01-27 08:52:02
|
I think it would just be easier to disable texture filtering
|
|
|
|
_wb_
|
2021-01-27 08:53:31
|
There is no such thing
|
|
2021-01-27 08:53:50
|
We do have a configurable upsampling filter in the bitstream though
|
|
2021-01-27 08:54:35
|
By default it does nice upsampling but I'm pretty sure you can configure it to do nearest neighbor instead
|
|
|
|
march
|
|
_wb_
There is no such thing
|
|
2021-01-27 08:55:30
|
For example you can use the css property `image-rendering` to disable the texture filtering/image scaling algorithm
|
|
|
|
_wb_
|
2021-01-27 08:55:39
|
That would give you a way to encode pixel art as pixels and upscale them 2x, 4x or 8x for basically free
|
|
|
march
For example you can use the css property `image-rendering` to disable the texture filtering/image scaling algorithm
|
|
2021-01-27 08:56:50
|
Ah yes, you can do that. I was answering Matt's question though, you just were a bit quicker :)
|
|
|
|
march
|
2021-01-27 08:58:08
|
But unfortunately you still have to upscale stuff if you want to post pixel art on social media/plattforms where you can't set the texture filter/image scaling algorithm
|
|
|
|
_wb_
|
2021-01-27 08:58:16
|
If you do the upscaling in the codec, it's more guaranteed to always look the same, e.g. if you right click the css-upscaled image and do "save as", it will look small
|
|
|
|
Deleted User
|
|
march
But unfortunately you still have to upscale stuff if you want to post pixel art on social media/plattforms where you can't set the texture filter/image scaling algorithm
|
|
2021-01-27 09:01:41
|
Yes, that's why I asked. I can only configure image-rendering on my own web pages.
|
|
|
|
_wb_
|
2021-01-27 09:02:58
|
So 2x, 4x, 8x can be done as a bitstream option, other factors are trickier (but could probably design a specific modular context model for them that sets the predictor choice in such a way that the duplicated pixels are perfectly predicted and become literally free)
|
|
2021-01-27 09:03:43
|
There is no cjxl option yet though to do such cleverness automatically
|
|
|
|
Deleted User
|
|
_wb_
So 2x, 4x, 8x can be done as a bitstream option, other factors are trickier (but could probably design a specific modular context model for them that sets the predictor choice in such a way that the duplicated pixels are perfectly predicted and become literally free)
|
|
2021-01-27 09:06:00
|
I guess that's what --resampling uses for color?
|
|
|
|
_wb_
|
2021-01-27 09:10:35
|
Yes, except it uses nice downsampling/upsampling now, while for pixel art you want just nearest neighbor
|
|
|
|
Deleted User
|
2021-01-27 09:16:07
|
Just as motivation what percentual size reductions could be achieved:
|
|
2021-01-27 09:16:55
|
oh
|
|
2021-01-27 09:19:21
|
https://res.cloudinary.com/mattgore/snatcher.webp 7106 Bytes
https://res.cloudinary.com/mattgore/snatcherx10.webp 14,5 KB
|
|
2021-01-27 09:20:32
|
jxl is a few bytes larger in both cases
|
|
|
|
lonjil
|
2021-01-27 09:21:43
|
Seems like cloudinary doesn't like Discord's caching bot, or Discord is having problems on their end, cuz it's not embedding for me.
|
|
|
|
_wb_
|
2021-01-27 09:22:21
|
Same here
|
|
2021-01-27 09:22:42
|
https://res.cloudinary.com/mattgore/snatcherx10.gif
|
|
|
|
lonjil
|
2021-01-27 09:23:00
|
oh, but that worked
|
|
|
|
_wb_
|
2021-01-27 09:23:13
|
With gif it works fine, probably just does not properly support webp
|
|
|
|
Deleted User
|
2021-01-27 09:23:18
|
Discord doesn't like animated webp
|
|
|
|
Master Of Zen
|
2021-01-27 09:23:21
|
Ok, just *copy image* and ctrl+v
|
|
2021-01-27 09:23:27
|
don't post image links
|
|
2021-01-27 09:23:36
|
|
|
|
|
_wb_
|
2021-01-27 09:23:49
|
Aaand the animation is gone lol
|
|
|
|
lonjil
|
2021-01-27 09:23:55
|
<@!258670228819410944> keep in mind: ctrl-c ctrl-v doesn't handle animation
|
|
|
|
Master Of Zen
|
|
_wb_
Aaand the animation is gone lol
|
|
2021-01-27 09:23:56
|
yep
|
|
|
|
_wb_
|
2021-01-27 09:24:38
|
This sort of thing is going to happen a lot in the future I am afraid
|
|
|
|
lonjil
|
2021-01-27 09:24:57
|
Discord aren't big on supporting stuff for some reason. I asked for SVG support over 4 years ago and they felt it was too spooky.
|
|
2021-01-27 09:25:21
|
Actually, I'm going to try something..
|
|
|
|
_wb_
|
2021-01-27 09:25:26
|
Apple supports webp but randomly decides not to display some of them and I have no clue why
|
|
2021-01-27 09:25:36
|
SVG _is_ spooky actually
|
|
2021-01-27 09:25:55
|
You can run javascript in svg and fetch stuff from anywhere
|
|
|
|
lonjil
|
2021-01-27 09:26:11
|
Not if it's in an image tag
|
|
|
|
_wb_
|
2021-01-27 09:26:36
|
Yes, they could support a restricted svg I guess
|
|
2021-01-27 09:27:02
|
Still tricky to screen them in a reliable way
|
|
|
|
raysar
|
2021-01-27 09:27:12
|
Hello, where do you find the cjpexl.exe binary? You compile it? I don't find any website sharing it. There is only sources on the gitlab. :/
|
|
|
|
Master Of Zen
|
|
raysar
Hello, where do you find the cjpexl.exe binary? You compile it? I don't find any website sharing it. There is only sources on the gitlab. :/
|
|
2021-01-27 09:27:47
|
follow build instructions and compile 👍
|
|
|
|
lonjil
|
2021-01-27 09:27:54
|
Any JS shouldn't be able to execute if the SVG is displayed with an img element, so I don't think screening would be necessary. The JS would simply not execute.
|
|
|
|
march
|
|
_wb_
Yes, they could support a restricted svg I guess
|
|
2021-01-27 09:28:05
|
It's really strange that they don't support SVG and WebP properly even though they use Chromium (electron)
|
|
|
|
lonjil
|
2021-01-27 09:29:54
|
Another much lamer one: Opus is supported for embedded audio on all Discord platforms, as Opus is used for voice chat. But, Discord doesn't show the music player for the .opus extension. If you upload an Opus file with the name as .mp3, it always works.
|
|
|
|
Master Of Zen
|
|
lonjil
Another much lamer one: Opus is supported for embedded audio on all Discord platforms, as Opus is used for voice chat. But, Discord doesn't show the music player for the .opus extension. If you upload an Opus file with the name as .mp3, it always works.
|
|
2021-01-27 09:30:30
|
or ogg
|
|
|
|
lonjil
|
2021-01-27 09:30:38
|
yeah, any whitelisted extension
|
|
|
|
Master Of Zen
|
2021-01-27 09:30:57
|
and flac is ok
|
|
|
|
spider-mario
|
2021-01-27 10:06:00
|
I’ve had a very little bit of experience with combining svg and js from when I wrote this little clock, 10-ish years ago: https://spider-mar.io/horloge.svg
|
|
2021-01-27 10:06:08
|
visually, I tried to replicate the one we had on Moodle (which was in Flash)
|
|
2021-01-27 10:06:23
|
not sure why I wrote the recursive requestAnimationFrame in this way though
|
|