|
fab
|
2021-03-26 04:29:14
|
yes even with thin person i get like blurs
|
|
2021-03-26 04:29:25
|
is just that the encoder at lower qualities can't figure it
|
|
2021-03-26 04:29:30
|
and i'm searching for a fix
|
|
2021-03-26 04:29:41
|
even to do double re encoding on 40% images
|
|
2021-03-26 04:30:08
|
but -X 8 likely won't work
|
|
2021-03-26 04:30:48
|
basically i did like an avif with modular at 86.6
|
|
2021-03-26 04:31:39
|
and i do lowest possible but good amount of faster decoding option
|
|
2021-03-26 04:31:51
|
so the ISSUE ARE TWO:
|
|
2021-03-26 04:32:11
|
CAN'T re encode JPG, JPG not supported in 0.3.6, neither the bugged 0.3.5
|
|
2021-03-26 04:32:16
|
0.3.4 was ok
|
|
2021-03-26 04:32:24
|
2) thin people get blurred
|
|
2021-03-26 04:32:41
|
maybe this is a different issue
|
|
|
_wb_
|
2021-03-26 04:43:13
|
how do you mean, can't re-encode jpeg?
|
|
|
BlueSwordM
|
|
fab
CAN'T re encode JPG, JPG not supported in 0.3.6, neither the bugged 0.3.5
|
|
2021-03-26 04:43:47
|
Are you sure you don't mean you can't reencode JXLs?
|
|
2021-03-26 04:43:58
|
Not being able to transcode JPG files would be... problematic.
|
|
|
|
Deleted User
|
|
fab
2) thin people get blurred
|
|
2021-03-26 05:30:44
|
As a skinny person myself, I find this quite discriminating and hope this will be fixed in the next release or asap!
|
|
|
|
_wb_
|
2021-03-26 05:33:54
|
I would like to see an example of thin people who get blurred
|
|
2021-03-26 05:39:32
|
https://tenor.com/view/strong-tough-beefy-mighty-manly-gif-12829597
|
|
|
|
fab
|
2021-03-26 07:18:17
|
for %i in (C:\Users\User\Documents\png\*.png) do cjxl "%i" "%i.jxl" -I 1.8 -X 60 -C 1 -P 9 -Q 57.6 -m -s 8 --num_threads=2
|
|
2021-03-26 07:18:26
|
this was the exact settings with 0.3.6
|
|
2021-03-26 07:18:46
|
https://discord.com/channels/794206087879852103/803645746661425173/825042949586681886
|
|
2021-03-26 07:19:06
|
the re encoding on benchmark it's getting me perceived quality
|
|
|
|
_wb_
|
2021-03-26 07:21:21
|
Lossy modular is not very good for such fidelity targets. Better just do `cjxl -q 50` or whatever.
|
|
|
|
fab
|
|
Scope
|
2021-03-27 01:00:51
|
<https://github.com/m-ab-s/media-autobuild_suite/issues/1950>
|
|
2021-03-27 01:01:51
|
> I had the same problem.
> Cause: asciidoc missing
> Or, there should be an option in upstream to disable man page so that asciidoc is not required. Less dependency less headache.
|
|
|
|
BlueSwordM
|
|
Scope
> I had the same problem.
> Cause: asciidoc missing
> Or, there should be an option in upstream to disable man page so that asciidoc is not required. Less dependency less headache.
|
|
2021-03-27 01:04:35
|
That's odd.
|
|
2021-03-27 01:04:43
|
It doesn't prevent compilation on my end. 🤔
|
|
|
Jyrki Alakuijala
|
|
_wb_
https://tenor.com/view/strong-tough-beefy-mighty-manly-gif-12829597
|
|
2021-03-28 03:10:56
|
if a colorful swimsuit is so small that it covers only one pixel, it will be auto-blurred by yuv420
|
|
|
surma
|
2021-03-28 06:28:36
|
anyone succeeded at building jxl on an M1? I’m getting errors I can’t seem to be able to disable
|
|
|
|
_wb_
|
2021-03-28 06:31:49
|
Ah interesting
|
|
2021-03-28 06:33:04
|
What errors do you get?
|
|
|
|
surma
|
2021-03-28 06:37:31
|
Following the README directly, I get a whole bunch of these:
```
clang: error: argument unused during compilation: '-mfpu=neon-vfpv4' [-Werror,-Wunused-command-line-argument]
clang: error: argument unused during compilation: '-mfloat-abi=hard' [-Werror,-Wunused-command-line-argument]
```
|
|
2021-03-28 06:38:54
|
Then did a _very professional_ `export CXXFLAGS="-Wno-unused-command-line-argument"` and started over
|
|
2021-03-28 06:39:25
|
Then I get
```
/Users/surma/src/gitlab.com/wg1/jpeg-xl/lib/extras/tone_mapping.cc:122:24: error: loop variable 'val' of type 'const V' (aka 'const Vec128<float, 4UL>') creates a copy from type
'const V' [-Werror,-Wrange-loop-analysis]
for (const V val : {red, green, blue}) {
^
/Users/surma/src/gitlab.com/wg1/jpeg-xl/lib/extras/tone_mapping.cc:122:16: note: use reference type 'const V &' (aka 'const Vec128<float, 4UL> &') to prevent copying
for (const V val : {red, green, blue}) {
^~~~~~~~~~~~~
&
/Users/surma/src/gitlab.com/wg1/jpeg-xl/lib/jxl/base/status.h:211:49: note: expanded from macro 'JXL_RETURN_IF_ERROR'
::jxl::Status jxl_return_if_error_status = (status); \
^~~~~~
```
|
|
2021-03-28 06:39:36
|
and can’t seem to be able to work around that warning/error
|
|
2021-03-28 06:41:58
|
( <@!794205442175402004> )
|
|
|
|
_wb_
|
2021-03-28 06:50:42
|
Looks like it is something that needs to be fixed
|
|
2021-03-28 06:51:13
|
Probably you could do a non-SIMD build, but that would be rather slow
|
|
|
|
surma
|
2021-03-28 06:52:36
|
Eh, I just wanna play with the `jxl_from_tree` 😉
|
|
2021-03-28 06:53:22
|
<@!794205442175402004> How do I disable SIMD? I can’t find anything in the CMake file
|
|
|
|
_wb_
|
2021-03-28 06:54:04
|
Good question, I dunno tbh
|
|
|
|
surma
|
|
|
_wb_
|
2021-03-28 06:56:57
|
Maybe open a gitlab issue about it?
|
|
2021-03-28 06:57:33
|
I suppose you could try with gcc instead of clang and see if that helps
|
|
|
|
veluca
|
2021-03-28 06:58:30
|
nah, it's better if you compile without -Werror
|
|
2021-03-28 06:58:35
|
we have a cmake flag for that
|
|
2021-03-28 06:59:38
|
should be enough to use `cmake -DCMAKE_BUILD_TYPE=Release -DJPEGXL_WARNINGS_AS_ERRORS=Off` or some equivalent
|
|
|
|
surma
|
2021-03-28 07:11:03
|
<@!179701849576833024> I did try `CXXFLAGS="-Wno-error"`, but to no avail
|
|
2021-03-28 07:11:06
|
I’ll try your way!
|
|
|
|
veluca
|
2021-03-28 07:12:24
|
possibly you need to clear the build directory when you change CXX flags
|
|
|
|
surma
|
2021-03-28 07:12:40
|
I did
|
|
2021-03-28 07:12:46
|
always started fresh 😄
|
|
|
|
veluca
|
2021-03-28 07:13:04
|
curious...
|
|
|
|
surma
|
2021-03-28 07:13:34
|
got about a million linker warnings at the end
|
|
2021-03-28 07:13:37
|
but it _did_ build
|
|
2021-03-28 07:13:45
|
(`jxl_from_tree` is missing tho 🙄 )
|
|
2021-03-28 07:14:35
|
Maybe `jxl_from_tree` falls under `JPEGXL_ENABLE_DEVTOOLS`?
|
|
|
|
veluca
|
2021-03-28 07:15:02
|
it does
|
|
|
|
surma
|
2021-03-28 07:15:39
|
Great, I’ll try again
|
|
2021-03-28 07:18:18
|
```
Undefined symbols for architecture arm64:
"jxl::EncodeImageJPG(jxl::CodecInOut const*, jxl::JpegEncoder, unsigned long, jxl::YCbCrChromaSubsampling, jxl::ThreadPool*, jxl::PaddedBytes*, jxl::DecodeTarget)", referenced from:
jxl::ThreadPool::RunCallState<jxl::Status (unsigned long), main::$_0>::CallDataFunc(void*, unsigned int, unsigned long) in fuzzer_corpus.cc.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
|
|
|
|
veluca
|
2021-03-28 07:20:06
|
ahhh, yes, that
|
|
2021-03-28 07:20:32
|
try commenting out fuzzer_corpus in tools/CMakeLists.txt
|
|
2021-03-28 07:21:58
|
(another possibility IIRC is to pass `-DPKG_CONFIG_EXECUTABLE=/dev/null` to cmake)
|
|
|
|
surma
|
2021-03-28 07:24:06
|
great that worked
|
|
2021-03-28 07:24:07
|
thank you
|
|
2021-03-28 07:27:45
|
🎉
|
|
|
|
_wb_
|
2021-03-28 07:40:02
|
What is that image? It's a meme, right? But I must have missed it
|
|
|
|
surma
|
2021-03-28 07:41:31
|
It’s from the <#824000991891554375> channel
|
|
2021-03-28 07:41:32
|
it’s loss
|
|
2021-03-28 07:41:35
|
an older meme 😉
|
|
2021-03-28 07:42:02
|
https://knowyourmeme.com/memes/loss
|
|
|
|
_wb_
|
2021-03-28 07:44:35
|
Ah, now I get it
|
|
|
|
Deleted User
|
2021-03-28 07:59:13
|
<@!228116142185512960> the man of culture 😄
Thanks for appreciating my masterpiece 😉
|
|
|
|
_wb_
|
|
Jyrki Alakuijala
if a colorful swimsuit is so small that it covers only one pixel, it will be auto-blurred by yuv420
|
|
2021-03-28 08:05:39
|
```
if x > 0
if c > 0
if c > 1
if W > 200
- Set 22
if W > 0
- W - 1
- Set 255
- Set 0
if N > 200
- Set 24
if N > 0
- N - 1
- Set 255
- Set 0
```
|
|
2021-03-28 08:05:48
|
|
|
2021-03-28 08:28:21
|
|
|
2021-03-28 08:28:28
|
|
|
|
|
Jyrki Alakuijala
|
|
surma
https://knowyourmeme.com/memes/loss
|
|
2021-03-29 08:38:06
|
Why is it politically correct to make a mockery/art/memes/etc of a comic about miscarriage? This is an honest question. It seems like a sensitive topic to me.
|
|
|
|
Deleted User
|
|
Jyrki Alakuijala
Why is it politically correct to make a mockery/art/memes/etc of a comic about miscarriage? This is an honest question. It seems like a sensitive topic to me.
|
|
2021-03-29 08:49:07
|
If I recall correctly, there were some controversies about the author, using stolen photo as background or something
|
|
|
lithium
|
2021-03-29 09:32:47
|
jpeg xl 0.3.7 probably implement vardct improvement?(reverse the order of dct size selection to merge instead of split)
|
|
|
|
surma
|
2021-03-29 09:34:33
|
<@!532010383041363969> It’s a valid question. It _is_ a sensitive topic, and the author of the original comic was being ingenuine about it to gain internet points/fame, which is why it got so much backlash and turned into a meme.
But you are right that without that context, it’s only the insensitivity that remains and I probably should have used a different <#824000991891554375> picture. It was just the most recent one in the channel, so that was just lazy of me.
|
|
|
|
Jyrki Alakuijala
|
2021-03-29 09:35:43
|
yes, let's stay away from that meme until we understand its implications better
|
|
|
monad
|
2021-03-29 10:36:50
|
I guess no prequel memes either
|
|
|
Master Of Zen
|
2021-03-29 10:47:32
|
<@!794205442175402004> how does jxl recognize that file indeed jxl, and can be bare-bone pixel in 20 bytes without 500+ words ASCII essay in header about how it's an image type?)
|
|
2021-03-29 10:54:00
|
is there papers on how to design bytestream?
|
|
|
|
_wb_
|
2021-03-29 10:59:25
|
a jxl codestream starts with `0xFF0A`, not more is needed to make it sufficiently unambiguous that it's a jxl codestream
|
|
2021-03-29 11:00:43
|
JPEG keeps track of which 'JPEG markers' (0xFF followed by some byte) are in use, and we got that one for "start of jxl codestream"
|
|
|
Master Of Zen
is there papers on how to design bytestream?
|
|
2021-03-29 11:02:01
|
no idea, actually
|
|
|
|
Master Of Zen
|
|
_wb_
JPEG keeps track of which 'JPEG markers' (0xFF followed by some byte) are in use, and we got that one for "start of jxl codestream"
|
|
2021-03-29 11:03:36
|
yeah, that's good
|
|
2021-03-29 11:05:21
|
So, I have that impression, that everything codec related is in constant "state of the art", and it's on quite handful of people to make decisions/figure out stuff, and everyone just runs with it 🤔
|
|
|
|
Scope
|
2021-03-29 11:36:34
|
```* Bump JPEG XL version to 0.3.7.
* Fix a rounding issue in 8-bit decoding.```
<https://encode.su/threads/3564-JXL-version-0-3-released?p=69282&viewfull=1#post69282>
|
|
|
|
_wb_
|
2021-03-29 11:52:47
|
Yes, lossless wasn't quite lossless when decoding via the api, so that needed a fix 😅
|
|
|
Dr. Taco
|
2021-03-29 12:20:48
|
<@!532010383041363969> if you want an actual deep dive into the context as to why "Loss" has always been made fun of, https://www.youtube.com/watch?v=TebCHHCw9rY
|
|
|
|
fab
|
2021-03-29 01:21:45
|
this command don't work in jxl 0.3.6/0.3.7
|
|
2021-03-29 01:29:50
|
ah colors go max on =2
|
|
2021-03-29 01:29:53
|
for %i in (C:\Users\User\Downloads\ps1\*.png) do cjxl "%i" "%i.jxl" -s 4 -m -C 2 -P 7 -I 3.53 -E 3 -Q 89.6 -X 45.6 -Y 24 -g 1 --num_threads=2
|
|
2021-03-29 01:30:00
|
trying this should be better
|
|
2021-03-29 01:30:14
|
maybe i will try also with speed 8
|
|
|
Crixis
|
2021-03-29 01:31:48
|
1. -E 3 work only with -s 9 (not -s 4)
2. -I 3.3 not make sense, the max is 1
|
|
|
Troc
|
2021-03-29 10:09:17
|
Testing JXL on 5950x
|
|
|
|
veluca
|
2021-03-29 10:10:43
|
hah, what are the flags?
|
|
2021-03-29 10:11:08
|
(I have a trx 3970x myself)
|
|
|
|
Troc
|
2021-03-29 10:12:04
|
Nice! This is one of my most expensive personal purchases to date and I couldn't really dream of getting top TRX.
|
|
2021-03-29 10:12:22
|
I'm using MegaPixel QT, actually. Would there be a benefit to using a different thing?
|
|
2021-03-29 10:17:40
|
At this point, I prefer Webp since it has more support.
|
|
2021-03-29 10:17:59
|
I still haven't found an Android JXL viewer.
|
|
2021-03-29 10:24:47
|
<@!179701849576833024> How hard is the 3970x to cool?
|
|
|
|
veluca
|
2021-03-29 10:41:24
|
Very hard 🤣 I still don't have temperatures where I like them, and I'm not even overclocking...
|
|
|
|
Master Of Zen
|
|
veluca
Very hard 🤣 I still don't have temperatures where I like them, and I'm not even overclocking...
|
|
2021-03-29 10:43:14
|
As I know they really sensitive to mounting. One owner I know had huge issues because of that
|
|
|
|
Troc
|
2021-03-29 10:43:16
|
I'm using TPU 2, running every core at 4.1 GHz and still temps haven't exceeded 70 celsius.
|
|
|
|
veluca
|
|
Master Of Zen
As I know they really sensitive to mounting. One owner I know had huge issues because of that
|
|
2021-03-29 10:44:25
|
Might explain things, although I did re-mount it once or twice (didn't seem to make a big difference, and it looks like it was mostly correct, but what do I know...)
|
|
|
|
Troc
|
2021-03-29 10:45:53
|
Are you using paste or pads?
|
|
|
|
veluca
|
2021-03-30 12:48:50
|
paste
|
|
|
HellMood
|
2021-03-30 03:37:58
|
Now the JXL really made me curious. Recently, i did a small (tiny intro / demoscene) "wild" production. It's a meta-joke, displaying the logo of the 256 bytes category, in 256x256 pixels, with a filesize of 256 bytes. https://www.pouet.net/prod.php?which=86547 It's a WEBP file. The "squoosh" web app doesnt do too well with JXL, so i was wondering how JXL(dev) with "the best" parameters would perform on the image 🙂
|
|
|
|
Scope
|
2021-03-30 03:41:54
|
|
|
2021-03-30 03:42:42
|
`-q 100 -s 9 -E 3 -I 1`
|
|
|
|
HellMood
|
2021-03-30 03:43:02
|
Nice 🙂 Is the online implementation that much behind? Are parameters missing? Or would it in fact be possible to achieve that on "squoosh"?
|
|
|
|
Scope
|
2021-03-30 03:45:37
|
Because the WebAsm version is much slower than the native encoder and it can be a problem for large images, also some options are hidden for common use
|
|
|
|
veluca
|
2021-03-30 03:45:40
|
IIRC it doesn't have all the flags that would be needed to achieve that (in particular, no -E 3 or -I 1)
|
|
|
|
HellMood
|
2021-03-30 03:50:26
|
Ok, i see. Beating a tight webp, and being hackable for demoscenish art. Pretty convincing 🙂
|
|
|
|
Scope
|
2021-03-30 03:54:27
|
Yes, also as previously discussed when I made comparisons, for PixelArt-like and small images there is still room for improvement and encoding is not always optimal
<https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/edit#gid=0>
|
|
2021-03-30 04:00:47
|
But overall, JXL has a pretty good efficiency gain over past formats
|
|
|
|
HellMood
|
|
Scope
But overall, JXL has a pretty good efficiency gain over past formats
|
|
2021-03-30 04:05:19
|
It looks like BMF, EMMA are a bit better though. I've never heard of these, and these also seem not that known in general. What's the deal here? (they are grayed out for a reason i guess 😉 )
|
|
|
|
Scope
|
2021-03-30 04:08:48
|
Yep, but they are experimental (closed-source) formats without standardization with very slow decoding with minimal features compared to JXL
They are added to understand the compression potential
|
|
|
|
HellMood
|
2021-03-30 04:14:25
|
Sad that it's closed source. One can only hope these guys join the communities in the future 🙂 Very thoughtful and transparent comparison. My TIL list has a lot of facts today 🙂
|
|
|
|
Scope
|
2021-03-30 04:20:41
|
And WebP/WebP2/FLIF are more effective on Emoji because they remove invisible alpha by default, while JXL does not (I am also waiting this feature, as well as premultiplied alpha)
|
|
|
Pieter
|
2021-03-30 04:21:57
|
<@436097739391107072> Important to note that these aren't intended to be actually usable as image formats. They're just experiments to figure out the limits of compression, with no regard for performance or practicality.
|
|
|
|
Scope
|
2021-03-30 04:27:33
|
Yes, they are also formats/compressors with symmetric compression speed and a bit different usage than JXL and even having open sources it is not a guarantee that they would help improve or make another better format with the use case like WebP/JXL (where decoding speed and support of many features besides maximum compression is important)
However, I know that BMF is quite used and time-tested (the format is more than 20 years old), and the developer of EMMA may someday open the sources and he also makes various improvements to the open PAQ/CMIX compressors
|
|
|
spider-mario
|
|
Scope
And WebP/WebP2/FLIF are more effective on Emoji because they remove invisible alpha by default, while JXL does not (I am also waiting this feature, as well as premultiplied alpha)
|
|
2021-03-30 04:32:41
|
premultiplied alpha is already supported, but for now only used for EXR input
|
|
|
|
Scope
|
2021-03-30 04:34:21
|
Yes, but I mean as options for lossless compression (to remove invisible alpha and for premultiplied alpha)
|
|
|
Scope
`-q 100 -s 9 -E 3 -I 1`
|
|
2021-03-30 05:29:53
|
Also WebP2
|
|
|
|
_wb_
|
|
Scope
`-q 100 -s 9 -E 3 -I 1`
|
|
2021-03-30 05:38:35
|
How does it look with --subsampling=8?
|
|
|
|
Scope
|
2021-03-30 05:42:20
|
Is this option available for lossless cjxl?
|
|
|
|
veluca
|
2021-03-30 05:56:18
|
in theory yes, but IIRC we never tried it
|
|
|
|
_wb_
|
2021-03-30 06:00:43
|
Just curious what upsampling would do to it. Putting kids in bed so hard to try myself right now
|
|
|
|
Scope
|
2021-03-30 06:03:52
|
--subsampling=8
```Unknown argument: --subsampling=8```
--resampling=8
```../lib/jxl/fields.cc:677: JXL_ABORT: AllDefault should never fail```
|
|
|
|
veluca
|
2021-03-30 06:13:55
|
right, that's not good
|
|
2021-03-30 06:14:02
|
can you compile in non-release mode?
|
|
|
|
_wb_
|
2021-03-30 06:32:09
|
../lib/jxl/frame_header.cc:227: JXL_FAILURE: Alpha upsampling != color upsampling
|
|
2021-03-30 06:32:49
|
Right. We need to implement resampling also for alpha.
|
|
|
|
Scope
|
2021-03-30 06:36:01
|
```../lib/jxl/frame_header.cc:227: JXL_FAILURE: Alpha upsampling != color upsampling
../lib/jxl/fields.cc:677: JXL_ABORT: AllDefault should never fail```
|
|
|
|
_wb_
|
2021-03-30 06:39:13
|
It works if you remove the alpha channel first
|
|
2021-03-30 06:39:18
|
But it looks ugly
|
|
2021-03-30 06:39:39
|
Probably because the downsampling is no good for this
|
|
|
|
Scope
|
2021-03-30 06:39:42
|
And also upsampling algorithms variations, because:
|
|
2021-03-30 06:39:48
|
|
|
|
|
_wb_
|
2021-03-30 06:46:38
|
Yeah no
|
|
2021-03-30 06:47:22
|
You could signal a custom upscaling that is just NN, but it would be too costly
|
|
|
|
veluca
|
2021-03-30 06:52:41
|
it looks a bit weird as a result of the upscaling algo
|
|
2021-03-30 06:53:10
|
anyway, one *could* cheat and send this as the DC of an image that has all-0 DCT coefficients, DCT8 only (and some appropriately-set flags)
|
|
2021-03-30 06:53:55
|
that's effectively NN 8x upscaling
|
|
|
|
_wb_
|
2021-03-30 06:57:47
|
Yes
|
|
2021-03-30 06:58:28
|
We just don't try to do palette etc on DC right now, because that would rarely make any sense
|
|
|
|
Scope
|
2021-03-30 07:00:55
|
Hmm, that would be nice, because NN is also quite important for certain types of images and especially Pixel Art (I thought this was also included in `--resampling` from the beginning)
|
|
|
|
_wb_
|
2021-03-30 07:01:54
|
Resampling is much fancier by default
|
|
2021-03-30 07:02:25
|
It can be customized but that requires signalling a bunch of weights at 2 bytes per weight
|
|
2021-03-30 07:03:03
|
For 8x upsampling it's 420 bytes to not do the default thing
|
|
|
|
il1kesonic
|
2021-03-31 03:22:21
|
jay pig sex l
|
|
|
|
Deleted User
|
|
Nova Aurora
|
2021-03-31 05:16:03
|
Server's usually dead around now - Europe and US it's still night
|
|
|
|
_wb_
|
2021-03-31 05:32:15
|
I just woke up
|
|
|
Orum
|
2021-03-31 06:42:29
|
why would there be any scaling within jxl at all?
|
|
2021-03-31 06:43:58
|
I guess for backwards compat with JPEG you need to upscale the chroma
|
|
2021-03-31 06:44:29
|
not sure why alpha wouldn't be 1:1 though
|
|
|
diskorduser
|
|
jay pig sex l
|
|
2021-03-31 07:01:33
|
Your profile picture bad. 😡
|
|
|
|
_wb_
|
|
Orum
I guess for backwards compat with JPEG you need to upscale the chroma
|
|
2021-03-31 07:16:39
|
Yes, and also to progressively show a preview from the 1:8 image. Since we wanted that upscaling code in the decoder anyway, we allowed it in the bitstream too. For very low bpp encoding, it can be better to just downscale the whole image instead of reducing quality.
|
|
|
|
Orum
|
2021-03-31 07:25:14
|
ah, makes sense
|
|
|
|
HellMood
|
2021-03-31 08:53:58
|
Oh, i almost forgot. My interest for very small images sparked already a good while back. I was wondering if i ever could get my pouet profile picture smaller than 49 bytes. There were articles about really small GIFs/PNGs, but these hacks weren't always stable in every environment. So what about this in JXL? https://content.pouet.net/avatars/dot_opt.gif
|
|
|
|
_wb_
|
2021-03-31 09:05:44
|
|
|
2021-03-31 09:05:47
|
that's the best I can do
|
|
|
|
HellMood
|
2021-03-31 09:13:17
|
I will *soo* use this, once it's generally supported 🙂 Another one below 32 bytes 🙂
|
|
|
|
_wb_
|
2021-03-31 11:46:03
|
ugh I am trying to upload something
|
|
2021-03-31 11:46:04
|
https://commons.wikimedia.org/wiki/File:JPEG_XL_codec_architecture.svg
|
|
2021-03-31 11:46:14
|
https://upload.wikimedia.org/wikipedia/commons/5/55/JPEG_XL_codec_architecture.svg svg looks fine
|
|
2021-03-31 11:46:32
|
png previews are glitched
|
|
2021-03-31 11:50:41
|
oh well, uploaded a non-optimized SVG and now it works
|
|
|
Lastrosade
|
2021-03-31 12:30:10
|
The pngs look ok
|
|
|
|
_wb_
|
2021-03-31 12:30:40
|
yes I fixed it
|
|
|
|
Lastrosade
|
2021-03-31 12:30:43
|
oh
|
|
2021-03-31 12:30:57
|
https://upload.wikimedia.org/wikipedia/commons/thumb/5/55/JPEG_XL_codec_architecture.svg/2000px-JPEG_XL_codec_architecture.svg.png
Oh
|
|
|
NeRd
|
2021-03-31 12:41:13
|
tbh it's more coherent than most of my graphs
|
|
|
|
_wb_
|
2021-04-01 06:34:04
|
https://twitter.com/jonsneyers/status/1377508854024523778?s=19
|
|
2021-04-01 06:34:15
|
😭
|
|
|
|
Pieter
|
2021-04-01 06:35:13
|
I suspect they may reconsider tomorrow?
|
|
|
190n
|
|
Some1NamedNate
|
2021-04-01 07:52:34
|
It's an April Fools joke, you guys. It has to be!
|
|
|
Petr
|
|
_wb_
https://commons.wikimedia.org/wiki/File:JPEG_XL_codec_architecture.svg
|
|
2021-04-01 08:00:40
|
It's great to have it there, Jon! The only thing currently missing there is the logo. 😉
|
|
|
|
diskorduser
|
2021-04-01 08:10:21
|
It's the time to make jpeg-xz format.
|
|
|
|
monad
|
|
_wb_
https://twitter.com/jonsneyers/status/1377508854024523778?s=19
|
|
2021-04-01 08:26:05
|
Sad news, but keep iterating. JPEG 41 can be even better than JPEG 40.
|
|
|
|
Jyrki Alakuijala
|
2021-04-01 11:35:38
|
https://tools.ietf.org/html/draft-alakuijala-brotli-00 Was sent on April 1st
|
|
2021-04-01 11:36:34
|
2014-04-01
|
|
2021-04-01 11:37:54
|
We started that project somewhere around August 2013 and opensourced the first version in October 2013 -- everything went faster than with JPEG XL 🙂
|
|
|
_wb_
https://twitter.com/jonsneyers/status/1377508854024523778?s=19
|
|
2021-04-01 11:40:07
|
not sure if this tweet is good marketing
|
|
|
|
_wb_
|
|
Jyrki Alakuijala
not sure if this tweet is good marketing
|
|
2021-04-01 12:52:41
|
It is lousy marketing and a mediocre joke
|
|
|
|
Scope
|
2021-04-01 12:59:01
|
Quite a good scary joke
|
|
|
|
lithium
|
2021-04-01 03:17:09
|
Hello <@!532010383041363969> I take some discuss on AV1 discord,
av1 can handle images which have lines and sharp textures,
and (dct hates high contrast, and cdef in av1 helps with edges a lot),
jpeg xl don't have cdef, jpeg xl will use which method to handle those features images?
|
|
|
|
Scope
|
2021-04-01 03:19:21
|
https://discord.com/channels/794206087879852103/803645746661425173/815245155791405086
|
|
|
|
lithium
|
|
Scope
https://discord.com/channels/794206087879852103/803645746661425173/815245155791405086
|
|
2021-04-01 03:25:18
|
thanks <@!111445179587624960> 🙂 , look like not CDEF reason, but i still curious av1 use what magic on those features images
|
|
|
|
Deleted User
|
|
lithium
thanks <@!111445179587624960> 🙂 , look like not CDEF reason, but i still curious av1 use what magic on those features images
|
|
2021-04-01 06:22:39
|
I'd like to solve it, too. I still wonder how do they do that? We need to disable more and more AV1's coding tools until the image breaks down. If it still doesn't deteriorate enough... I don't know how did they achieved that.
|
|
|
|
Jyrki Alakuijala
|
|
lithium
Hello <@!532010383041363969> I take some discuss on AV1 discord,
av1 can handle images which have lines and sharp textures,
and (dct hates high contrast, and cdef in av1 helps with edges a lot),
jpeg xl don't have cdef, jpeg xl will use which method to handle those features images?
|
|
2021-04-02 11:10:28
|
I don't know why it works in AV1/AVIF
|
|
2021-04-02 11:10:53
|
it could be one of three different things or something else
|
|
2021-04-02 11:11:22
|
1. 8-color palette transform
|
|
2021-04-02 11:11:54
|
2. linear directional prediction
|
|
2021-04-02 11:13:38
|
3. non-rectangular (trapezoid) DCT block splitting
|
|
2021-04-02 11:14:09
|
those are my highest candidates why it works in AVIF
|
|
2021-04-02 11:15:14
|
I considered all of them for JPEG XL and decided to leave them out
|
|
2021-04-02 11:16:27
|
I wanted to have something similar to linear directional prediction, but decided to leave it out after three failed experiments in that general area by two different engineers
|
|
2021-04-02 11:18:00
|
I didn't think we get great quality from non-rectangular block splits -- it is only useful at (<0.3 bpp) -- and I didn't want to complicate the format, slow down the encoding and decoding by adding features that are only useful at bitrates that people don't care about
|
|
2021-04-02 11:19:37
|
The same for mixing a palette transform with the DCTs, I just thought it is good enough if we have the identity transform, 2x2 dct and the 4x4 dcts for these uses -- and those have smoother degradation models (smaller maximum error/higher fidelity)
|
|
2021-04-02 11:21:11
|
I added the AFV and the 4x8 dcts to compensate for the lack of palette transform and non-rectangular block splitting -- but they are mostly useful at a relatively high quailty
|
|
2021-04-02 11:23:16
|
I didn't want to add linear directional prediction as a copy from AVIF because it wouldn't work on 256x256 aligned grid boundary possibly raising global artefacts in the image and its encoding cost seemed excessive, and I did an ablation test on it and the best help I found on a photograph was in the range of 10-15 % reduction (on the photo where it helped the most)
|
|
2021-04-02 11:23:59
|
I didn't include anime at that stage because I considered it to be well compressed in any case and the bulk of the entropy in images to be from the natural photographs
|
|
2021-04-02 11:24:31
|
Also, once your fidelity requirements increase for anime, they become very similar to photographs -- none of those three techniques help any more
|
|
2021-04-02 11:26:43
|
We implemented CDEF in JPEG XL (by adding a directional correction to gaborish filtering). The experiment showed the gains are marginal, the result doesn't look great to human eyes, and we consequently removed the additional complexity. This prepped my suspicion (expressed earlier on this chat) about ineffectiveness of CDEF in AVIF.
|
|
2021-04-02 11:27:14
|
If you observe CDEF from Mozilla's blog post the text reads that it is an amazing invention.
|
|
2021-04-02 11:27:27
|
If you look at the images they provide, it is already less exciting.
|
|
2021-04-02 11:29:02
|
CDEF
|
|
2021-04-02 11:30:03
|
our experiments created artefacts that were in the same category as this image (although much smaller in amplitude since we only used a 5 pixel long segment with some tapering in ends)
|
|
2021-04-02 11:31:33
|
I consider that the most promising experiment (for fast decoding and low system complexity) that we had was to transform every 64x64 square by perspective sampling it from an arbitrary geometry in the source image
|
|
2021-04-02 11:32:06
|
It gave fidelity/quality savings ad d12, and some comfort at slightly lower distances
|
|
2021-04-02 11:33:47
|
I decided not to include it in the end as I didn't expect JPEG XL to be useful there and it did add to the system complexity (for example progressive viewing would become more "interesting" or we would need to do 2x DCTs for that area)
|
|
2021-04-02 11:34:37
|
if someone does an ablation study of the three features in the top of this long single-person chat -- I'd be happy to learn about what in AVIF creates the difference
|
|
2021-04-02 11:34:40
|
...
|
|
2021-04-02 11:35:17
|
when I eventually get into reversing the order of integral transform selection, I suspect that we will get half way between what JPEG XL is today and what AVIF can deliver for anime at low bpp
|
|
2021-04-02 11:38:59
|
I suspect that one reason why CDEF didn't help at all for JPEG XL is because we have Gaborish that probably does 90 % of it with much less computation (for mid and high fidelity at least)
|
|
2021-04-02 11:41:56
|
CDEF paper talks about subjective testing and 5-10 % win in density there -- we observed a similar win for the simpler Gaborish filtering for subjective testing
|
|
2021-04-02 11:46:33
|
(I believe that AVIF's 8-color palette is per channel, i.e., different palette of values for Y, U and V -- if it is a thick drawn line, there would only be one color for background, one color for the line and a few colors for the values in between -- since there are two major values (background and foreground) with some context modeling not a lot of overall entropy is needed for this transform)
|
|
|
|
_wb_
|
2021-04-02 11:48:56
|
I suspect AVIF's chroma from luma might also play a role. I don't think they do it in the same way as jxl, I think they do it in the pixel domain (after upsampling).
|
|
|
|
Deleted User
|
|
Jyrki Alakuijala
CDEF
|
|
2021-04-02 12:01:24
|
This is **not** CDEF, it's their previous "intra-paint" predictor (that was *obviously* scrapped), which dates back to Daala (which I was playing with at the similar time as FLIF).
|
|
2021-04-02 12:06:54
|
Even using it as a deringing filter instead of predictor...
|
|
2021-04-02 12:06:56
|
https://jmvalin.ca/daala/paint_demo/fruits_nopf_luma.jpg
|
|
2021-04-02 12:07:32
|
...was **way** too computationally expensive (despite giving nice visual effects)...
|
|
2021-04-02 12:07:36
|
https://jmvalin.ca/daala/paint_demo/fruits_pf_luma.jpg
|
|
2021-04-02 12:11:41
|
...which they admitted themselves.
> **The verdict:** Nice try, better luck next time. There may be uses for intra paint as a photo filter, or even (who knows) as a stand-alone codec for certain types of images, __but not as an intra predictor or as a deringing filter in a video codec__.
|
|
|
|
Crixis
|
|
...which they admitted themselves.
> **The verdict:** Nice try, better luck next time. There may be uses for intra paint as a photo filter, or even (who knows) as a stand-alone codec for certain types of images, __but not as an intra predictor or as a deringing filter in a video codec__.
|
|
2021-04-02 12:12:33
|
I remember this in Daala time
|
|
|
|
Deleted User
|
2021-04-02 12:14:10
|
Then Conditional Replacement Filter (CRF) came to life (demo at the bottom of the page):
https://jmvalin.ca/daala/deringing_demo/
|
|
2021-04-02 12:15:49
|
It performed well, both visually and computationally.
|
|
2021-04-02 12:15:51
|
https://jmvalin.ca/daala/deringing_demo/dering_off.jpg
|
|
2021-04-02 12:15:59
|
https://jmvalin.ca/daala/deringing_demo/dering_on.jpg
|
|
2021-04-02 12:16:34
|
> The intra-paint-based deringing filter came close to succeeding... but didn't. Its replacement, the Daala directional deringing filter is still a bit new to "revisit", but it looks like it's going to succeed. Its complexity is far lower than the paint deringing filter, it's easy to vectorize, and — most importantly — it's providing a big improvement to both Daala and AV1.
>
> **The verdict:** Success — so far anyway.
|
|
|
|
Jyrki Alakuijala
|
2021-04-02 12:16:39
|
I believe AV1 has a directional predictor carried over from 'VP10'
|
|
2021-04-02 12:16:48
|
but not sure about it
|
|
|
|
_wb_
|
2021-04-02 12:17:51
|
There are lots of directions to choose from
|
|
|
|
Jyrki Alakuijala
|
2021-04-02 12:18:11
|
from wikipedia: Directional predictors extrapolate these neighboring pixels according to a specified angle. In AV1, 8 main directional modes can be chosen. These modes start at an angle of 45 degrees and increase by a step size of 22.5 degrees up until 203 degrees. Furthermore, for each directional mode, six offsets of 3 degree can be signaled for bigger blocks, three above the main angle and three below it, resulting in a total of 56 angles (ext_intra).
|
|
|
|
_wb_
|
2021-04-02 12:18:26
|
56 angles, yes
|
|
2021-04-02 12:18:34
|
That's a lot
|
|
|
|
Jyrki Alakuijala
|
2021-04-02 12:18:39
|
56 angles with some hierarchy in selection
|
|
2021-04-02 12:19:03
|
you need many angles -- otherwise the artefacts will be disgusting and often more entropy is produced than reduced
|
|
2021-04-02 12:19:14
|
searching for many angles is likely slow
|
|
|
|
Deleted User
|
2021-04-02 12:19:33
|
Xiph.org Daala's CRF was then merged with Cisco Thor's constrained low-pass filter (CLPF) and that's how CDEF was created, which is better than sum of its parts.
|
|
|
|
Jyrki Alakuijala
|
2021-04-02 12:19:53
|
CDEF paper discusses that other features in AV1 reduce the effect of CDEF
|
|
2021-04-02 12:19:59
|
possibly it means the directional prediction
|
|
2021-04-02 12:20:28
|
in my experience the directional prediction is the feature that actually works and CDEF is almost as good (but possibly cheaper to encode for)
|
|
2021-04-02 12:20:52
|
but I never read the codebase of AV1 -- I only have phenomenological experience of it
|
|
|
|
Deleted User
|
2021-04-02 12:20:55
|
I know, I've seen the test images with CDEF disabled (not so much difference). I just wanted to end Daala's CRF history.
|
|
|
|
Jyrki Alakuijala
|
2021-04-02 12:20:59
|
also most of my experience is more than 2 years old
|
|
|
|
Deleted User
|
2021-04-02 12:21:25
|
But probably not everyone there even knows about Daala
|
|
|
|
_wb_
|
2021-04-02 12:21:47
|
Searching for angles is slow, and relying a lot on directional causes the kind of smearing/'vectorization' artifacts you often see in low bpp avif
|
|
2021-04-02 12:22:47
|
For manga, such artifacts just happen to be pretty consistent with the image style
|
|
2021-04-02 12:27:53
|
Smearing artifacts are fine for oil paintings or hard edge / clean drawings. DCT artifacts are likely fine for charcoal sketches and other kinds of 'textured' / nonclean drawings...
|
|
|
|
Deleted User
|
2021-04-02 01:09:31
|
By the way, I've just loaded source code to Dev-C++ (my only lightweight enough IDE that supports multi-file projects, I'll compile with WSL2 anyway)
|
|
2021-04-02 01:09:54
|
Where does the code check for palette in source PNGs?
|
|
|
|
_wb_
|
2021-04-02 01:12:34
|
it doesn't
|
|
2021-04-02 01:12:55
|
it just loads the PNG as full color
|
|
2021-04-02 01:13:43
|
the modular encoder tries to make a palette in lossless mode, but it does that regardless of whether the PNG had a palette or not
|
|
|
|
Deleted User
|
|
_wb_
it just loads the PNG as full color
|
|
2021-04-02 01:16:33
|
But if the source PNG was palettized, how can you get full-color image? Does LodePNG "de-palettize" the image to full-color before passing it to cjxl?
|
|
|
|
_wb_
|
2021-04-02 01:16:52
|
yes
|
|
2021-04-02 01:18:10
|
we are doing quite a lot of redundant things in that flow atm 🙂
|
|
|
|
Deleted User
|
2021-04-02 01:19:10
|
Is there any way to "force" LodePNG to check for palettization and, if there is a palette, forward it and the image as series of palette color-codes?
|
|
|
|
_wb_
|
2021-04-02 01:19:27
|
the palette png is first converted to 8-bit full-color, then converted to 32-bit floats, then to 32-bit ints, and then a palette is made again 🙂
|
|
2021-04-02 01:20:47
|
we currently don't have a way to pass an image that already has a modular transform applied to it, which is what you'd need here (palette is seen as an optional transform, not a different kind of image)
|
|
2021-04-02 01:21:31
|
encode time is dominated by other things, but I suppose it would make sense to have a more direct path
|
|
|
|
Deleted User
|
|
_wb_
we currently don't have a way to pass an image that already has a modular transform applied to it, which is what you'd need here (palette is seen as an optional transform, not a different kind of image)
|
|
2021-04-02 01:22:28
|
> palette is seen as an optional transform, not a different kind of image
the... WHAT
|
|
|
|
_wb_
|
2021-04-02 01:24:28
|
conceptually, there is no distinction between an RGB image and a palette image – the latter is just an RGB image that happens to apply a palette transform at the global level
|
|
|
|
Deleted User
|
2021-04-02 01:26:37
|
How does the palette transform work in JPEG XL? I'm too much used to the "usual", PNG way (as a completely different color mode).
|
|
|
|
_wb_
|
2021-04-02 01:31:14
|
it replaces N channels with 1 same-sized channel and 1 auxiliary image that contains the colors for each palette index
|
|
2021-04-02 01:31:48
|
the aux image is a nb_colors x N image that also gets compressed
|
|
2021-04-02 01:32:44
|
for N=1 this can also be useful, e.g. if you have an 8-bit image but only 50 different values are used in every channel
|
|
2021-04-02 01:32:54
|
for N=3 or N=4 it is the usual RGB or RGBA palette
|
|
2021-04-02 01:33:32
|
but there is no limit to nb_colors, there is no reason why 2^8 would be a special number
|
|
2021-04-02 01:35:38
|
also, a palette transform has extra powers: the first K (a number that you can choose) palette colors are interpreted as "delta" entries, meaning they are not a color, but a difference w.r.t. a predictor (you can choose which predictor)
|
|
2021-04-02 01:36:11
|
and there is also a defined behavior for what happens if you use out-of-bounds palette indices
|
|
2021-04-02 01:36:50
|
if you signal an index that is larger than nb_colors, it corresponds to default colors
|
|
2021-04-02 01:37:08
|
if you signal an index that is below zero, it corresponds to default delta entries
|
|
2021-04-02 01:37:40
|
so a zero-sized palette actually makes sense and can be used for near-lossless encoding
|
|
|
|
Deleted User
|
|
_wb_
so a zero-sized palette actually makes sense and can be used for near-lossless encoding
|
|
2021-04-02 01:39:11
|
Ah, so that's where the current `--lossy-palette` option description in `cjxl` came from...
|
|
2021-04-02 01:42:02
|
Thanks for the explanation, JPEG XL's palettization is really crazy (and that's a good thing actually)
|
|
|
|
_wb_
|
2021-04-02 01:42:05
|
yes, normally palette is only used in a lossless way in the encoder, but with that option, when the palette is full, it instead picks the nearest color that can be obtained with a default delta entry or a default color
|
|
2021-04-02 01:42:28
|
it is a very powerful palette transform
|
|
2021-04-02 01:43:09
|
it would be fun to have jxl-art that makes use of it
|
|
|
|
Deleted User
|
2021-04-02 01:45:52
|
With all that knowledge I'm reworking my question: is it possible for LodePNG to forward not the palette itself, but just the info if the original PNG had one (and optionally how big it was) so `cjxl` applies the palette transform to the full color image it currently gets from LodePNG?
|
|
2021-04-02 01:51:47
|
And if the original PNG didn't have any palette, is it possible to do color counting for the first e.g. 1024 colors and if there's more of them than a threshold (e.g. 512), assume it's a photo and encode with VarDCT? Of course higher effort presets (e.g. `-s 9`) could count not just the first 1024 colors, but the whole image (quite expensive for bigger images, but counting is simple operation and can be multithreaded).
|
|
|
|
_wb_
|
2021-04-02 02:09:37
|
counting colors is not so simple, but yes, some kind of heuristic to select between vardct and modular would be good
|
|
|
|
lithium
|
|
Jyrki Alakuijala
when I eventually get into reversing the order of integral transform selection, I suspect that we will get half way between what JPEG XL is today and what AVIF can deliver for anime at low bpp
|
|
2021-04-02 02:23:11
|
<@!532010383041363969> Thank you very much for your help 🙂
So we just wait vardct implement reversing the order of integral transform selection improvement,
this issue should be fixed?
|
|
|
|
Deleted User
|
|
_wb_
counting colors is not so simple, but yes, some kind of heuristic to select between vardct and modular would be good
|
|
2021-04-02 03:41:15
|
If we assume that `image` is a 2D list and `palette` is a 1D list, both operating on `(r, g, b)` tuples, then this quick'n'dirty Python code should do the job:
```py
for x in range(x):
for y in range(y):
if image[x][y] not in palette:
palette.append(image[x][y])```
|
|
|
|
_wb_
|
2021-04-02 03:42:17
|
sure, it's simple to write, but that code is O(n^2) which is kind of expensive 🙂
|
|
|
|
Deleted User
|
2021-04-02 03:43:45
|
I know it's O(n^2), that's exactly why I reserved it for `-s 9` and want to make it parallel 😉
|
|
2021-04-02 03:45:26
|
What else can you suggest if you want to losslessly palettize the whole image? For example, OptiPNG? It has to palettize the whole image. What else can you do (except accessing every single pixel)?
|
|
|
|
_wb_
|
2021-04-02 04:18:48
|
We do exactly the above, except by default we stop if there are more than 1000 distinct colors
|
|
|
|
Deleted User
|
|
_wb_
We do exactly the above, except by default we stop if there are more than 1000 distinct colors
|
|
2021-04-02 04:33:20
|
Ok, that's a nice thing.
|
|
|
|
Jyrki Alakuijala
|
|
lithium
<@!532010383041363969> Thank you very much for your help 🙂
So we just wait vardct implement reversing the order of integral transform selection improvement,
this issue should be fixed?
|
|
2021-04-02 05:05:07
|
the issue will be improved to some extent -- probably not fixed
|
|
2021-04-02 05:05:55
|
the no-surprises quality will be better in JPEG XL, but the 'it looks ok except there if you happen to look there' quality will likely be better in AVIF
|
|
|
|
lithium
|
|
Jyrki Alakuijala
the no-surprises quality will be better in JPEG XL, but the 'it looks ok except there if you happen to look there' quality will likely be better in AVIF
|
|
2021-04-02 05:43:39
|
oh, sorry I mean cjxl -d 0.5, 1.0 and -q 80~85, I hope compressed quality like webp near-lossless 40~60 🙂
my target is high bbp and medium bbp, not low bbp
|
|
|
|
Jyrki Alakuijala
|
2021-04-03 01:53:46
|
yes, I will make d0.5 to d1.0 much better
|
|
|
|
Crixis
|
2021-04-03 04:41:19
|
so... when the new version?
|
|
|
|
_wb_
|
2021-04-03 04:53:41
|
https://c.tenor.com/NMLAWSo-mqIAAAAM/yoda-patience.gif
|
|
|
|
fab
|
2021-04-03 05:15:45
|
i heard 18 th April or after
|
|
2021-04-03 05:16:05
|
because there is a new meeting or things to be done
|
|
2021-04-03 05:16:18
|
i don't remember but wb posted
|
|
|
|
BlueSwordM
|
|
Crixis
so... when the new version?
|
|
2021-04-03 05:28:30
|
Patience boi, patience.
|
|
2021-04-03 05:28:48
|
It'll be released when it is ready to release.
|
|
|
|
fab
|
|
BlueSwordM
Patience boi, patience.
|
|
2021-04-03 05:33:44
|
updated the tricks i used to compress some images better
|
|
2021-04-03 05:33:53
|
see <#803645746661425173>
|
|
|
|
Scope
|
2021-04-03 05:37:57
|
And the frequency of releases does not matter, it is more important what changes and improvements will be there, there is nothing hard to do a new release at least every hour, correcting a few typos in the documentation
|
|
|
|
fab
|
2021-04-03 05:46:04
|
MORE EDGES (1); actually makes the image bigger
|
|
2021-04-03 05:46:10
|
so this is i lied
|
|
|
|
Jyrki Alakuijala
|
|
Crixis
so... when the new version?
|
|
2021-04-03 05:46:13
|
I was hoping to do it roughly now, but got assigned an eng review (to present our project for more senior people in the company) -- this is something that I cannot ignore and go ahead with coding instead 😛 ... I will likely be able to start in three days
|
|
2021-04-03 05:46:35
|
I believe the next effort for VarDCT improvements will last about three weeks
|
|
|
|
fab
|
2021-04-03 05:47:04
|
so 0.4.0 end of month or 18th april
|
|
2021-04-03 05:47:07
|
does it matter
|
|
|
|
Jyrki Alakuijala
|
2021-04-03 05:47:09
|
I need to be somewhat conservative not to create production issues or quality degradations there since it is done at a time when facebook and chrome are trying out our code
|
|
|
|
fab
|
2021-04-03 05:47:13
|
for companie
|
|
2021-04-03 05:47:26
|
in fact this i was thinking
|
|
2021-04-03 05:47:29
|
of facebook
|
|
|
|
Jyrki Alakuijala
|
2021-04-03 05:48:11
|
facebook has been a great partner on getting our priorities correct for actual launches
|
|
|
|
fab
|
2021-04-03 05:48:16
|
adding modular tricks is useful for encoding or automatic encoding
|
|
2021-04-03 05:48:18
|
?
|
|
2021-04-03 05:48:29
|
or is not a priority to use such heuristicds
|
|
|
|
Jyrki Alakuijala
|
2021-04-03 05:48:33
|
modular tricks likely come in a year or two
|
|
|
|
fab
|
2021-04-03 05:48:47
|
so at the moment natural images is the focus
|
|
|
|
Jyrki Alakuijala
|
2021-04-03 05:48:53
|
what I'm thinking that might help at lower quality could be a delta palettized DC
|
|
|
|
fab
|
2021-04-03 05:48:55
|
not re encoding and this
|
|
2021-04-03 05:49:03
|
like what i did
|
|
|
|
Jyrki Alakuijala
|
2021-04-03 05:49:31
|
I will be looking at anime and at all kinds of images/rates where we don't do well and mostly focus on those
|
|
|
|
fab
|
2021-04-03 05:49:32
|
like using the most thrustworthy metrics
|
|
|
|
Scope
|
2021-04-03 05:49:35
|
Is Facebook also interested in Jpeg XL or is this a personal initiative of some internal teams?
|
|
|
|
Jyrki Alakuijala
|
2021-04-03 05:49:47
|
It will include the use cases from Lee
|
|
2021-04-03 05:50:19
|
facebook eng has been advising us on how to make JPEG XL more appealing to them
|
|
2021-04-03 05:51:05
|
if they want to make statements on their interest or support, I suspect that they will make it in their blog posts
|
|
2021-04-03 05:53:44
|
from our viewpoint it was a great experience -- they showed where some of our oversights were and that allowed us to prioritize them and us (90+ % Luca) to work on them
|
|
|
|
Deleted User
|
2021-04-03 05:55:20
|
<@!532010383041363969> do you know if Google Photos team is considering integrating JPEG XL?
|
|
|
|
_wb_
|
2021-04-03 05:58:19
|
Up to end of 2020 our main focus was to define the best possible bitstream. Of course you need an encoder to see if what you define makes sense, and a decoder to see if it can be implemented with good speed, but the main focus was to just make a solid spec for jxl, and especially for modular this often meant only a proof of concept slow encoder.
|
|
2021-04-03 05:59:31
|
We are now where JPEG was in 1992. We know it works, we know it's great, but adoption still needs to get traction and there is still a lot of room for encoder improvements.
|
|
|
|
Pieter
|
2021-04-03 08:28:21
|
If you convert a JPEG to JPEG-XL, but don't choose lossless transcoding... will it use YUV colorspace?
|
|
|
|
Crixis
|
|
|
_wb_
|
2021-04-03 08:56:24
|
No, it will use XYB. We don't currently have a good lossy encoder for non-XYB.
|
|
|
|
Pieter
|
2021-04-03 08:56:47
|
What if you want lossless, but YUV?
|
|
|
|
_wb_
|
2021-04-03 08:56:54
|
Both vardct and modular _can_ use ycbcr though
|
|
2021-04-03 08:58:16
|
If you put yuv data in a ppm or png and call cjxl -m -c 2, it will losslessly encode the data and the decoder will know it is ycbcr
|
|
|
Viscid[NPL]
|
2021-04-03 09:43:33
|
Is it true that Chrome will never support JPEG XL?
|
|
|
|
190n
|
2021-04-03 09:43:51
|
no that was april fools by wb
|
|
|
|
Viscid[NPL]
|
2021-04-03 09:44:00
|
YEAH. Nice, thank you
|
|
|
|
190n
|
2021-04-03 09:45:52
|
it really got me for a sec <:PepeHands:808829977608323112>
|
|
|
|
Viscid[NPL]
|
2021-04-03 10:38:47
|
me too
|
|
|
|
Some1NamedNate
|
2021-04-03 11:08:04
|
Everyone, download Chrome Canary and Firefox Nightly
|
|
2021-04-03 11:08:19
|
There might be a build with JXL support on either browser
|
|
|
|
Pieter
|
2021-04-03 11:19:33
|
I believe libjxl support was recently merged into chromium's build system, but it isn't used yet or something.
|
|
2021-04-03 11:20:10
|
https://chromium.googlesource.com/chromium/src/+/6980917f414387c968a94b4ee1feb4fdf654b157
|
|
|
|
Some1NamedNate
|
|
|
Scope
|
2021-04-03 11:30:01
|
Yep and Firefox devs haven't even decided on JXL integration, so there is no point in downloading Nightly yet
|
|
|
|
Deleted User
|
2021-04-04 03:22:41
|
<@!795684063032901642> probably has his own JXL-enabled Chromium build, can we somehow get it, please?
|
|
|
|
diskorduser
|
2021-04-04 11:38:22
|
Hmm what
|
|
|
|
fab
|
2021-04-04 12:43:16
|
|
|
2021-04-04 02:14:59
|
https://it.wikipedia.org/wiki/JPEG_XL
|
|
2021-04-04 02:15:02
|
tried to update
|
|
2021-04-04 03:55:34
|
|
|
2021-04-04 03:55:34
|
|
|
2021-04-04 03:56:18
|
|
|
2021-04-04 03:56:21
|
also Codifica entropica should be codifica entropica
wikipedia wiki jpeg xl state
(as 04.04.2021)
Honestly is a bad translation from English
even the part from an user with c frm there it needs to be rewritten, see the second point in features
|
|
2021-04-04 06:07:15
|
i corrected all but still bad
|
|
2021-04-04 06:07:22
|
54 minutes to do it
|
|
2021-04-04 06:07:23
|
https://es.wikipedia.org/wiki/JPEG_XL
|
|
2021-04-04 06:41:10
|
someone fix the table in spanish here's the source code
|
|
2021-04-04 06:42:11
|
{{Ficha de formato de archivo
|nombre = JPEG XL
|extensión = .jxl (contenedores)
|MIME = image/jxl
|número_mágico = <code>FF 0A</code> o <code>00 00 00 0C 4A 58 4C 20 0D 0A 87 0A</code>}}
|desarrollador = Joint Photographic Experts Group, Google, Cloudinary
|género = [[Formatos gráficos|Gráficos]]
|extendido_de = PIK, FLIF, FUIF
|Compresión = [[Algoritmo de compresión con pérdida|con pérdida]] (por lo general) y [[Algoritmo de compresión sin pérdida|sin pérdida de qualidad]]
|estándar = ISO/IEC 18181
|formato abierto= si
}}
|
|
|
|
Jyrki Alakuijala
|
|
<@!795684063032901642> probably has his own JXL-enabled Chromium build, can we somehow get it, please?
|
|
2021-04-04 09:57:56
|
Let's wait that it surfaces from the main Chrome repository -- should be soon hopefully
|
|
|
<@!532010383041363969> do you know if Google Photos team is considering integrating JPEG XL?
|
|
2021-04-04 10:00:55
|
Google photos will speak for themselves most likely on their own blog
|
|
2021-04-04 10:04:02
|
We received feedback from them earlier in JPEG XL development and implemented corrections for that feedback in the codec
|
|
|
|
fab
|
2021-04-05 08:01:45
|
still the file in IT isn't deleted
|
|
2021-04-05 08:01:46
|
https://it.wikipedia.org/wiki/File:Struttura_Codec_JPEG_XL.png#file
|
|
2021-04-05 08:03:30
|
|
|
2021-04-05 08:03:36
|
https://commons.wikimedia.org/wiki/File:Struttura_Codec_JPEG_XL.png#/media/File:Struttura_Codec_JPEG_XL.png
|
|
2021-04-05 08:03:47
|
this is the url
|
|
2021-04-05 08:03:49
|
https://discord.com/channels/794206087879852103/794206170445119489/828540366516256809
|
|
2021-04-05 08:04:11
|
and we should use the english version with thumb
|
|
2021-04-05 08:04:17
|
not other versions
|
|
2021-04-05 08:06:49
|
|
|
|
|
Troc
|
2021-04-05 11:48:17
|
Does there exist a way to view JXL in android at this point?
|
|
|
|
Crixis
|
2021-04-05 12:13:15
|
Not in this moment
|
|
|
|
Deleted User
|
2021-04-05 12:14:47
|
You can use https://squoosh.app and "install" it as a PWA.
|
|
|
|
fab
|
2021-04-05 12:19:05
|
squoosh support only one image no t a gallery
|
|
|
|
Deleted User
|
2021-04-05 12:19:59
|
At least it opens...
|
|
|
|
fab
|
2021-04-05 06:24:08
|
what's the state of jxl?
|
|
|
|
Pieter
|
|
|
fab
|
2021-04-05 06:25:59
|
has modular become useless and jpeg xl automatically creates the best image?
|
|
|
|
Pieter
|
2021-04-05 06:26:05
|
??
|
|
2021-04-05 06:26:46
|
jpeg-xl wouldn't be all that interesting without modular
|
|
|
|
fab
|
2021-04-05 06:29:06
|
like if it can distribute pixels automatically
|
|
2021-04-05 06:29:15
|
without inserting two commands
|
|
2021-04-05 06:29:18
|
in cmd
|
|
2021-04-05 06:30:10
|
to me 0.3.7 is good enough
|
|
2021-04-05 06:31:19
|
but if more images can look better and without copying two commands in cmd or thinking what to use if faster mode if normal if N 1 to not ruin the 2 pass
|
|
|
|
Pieter
|
2021-04-05 06:32:54
|
you're talking about cjxl, not jpeg-xl itself?
|
|
|
|
fab
|
2021-04-05 06:32:56
|
WebP compression without loss works thanks to a prediction technique where each pixel block is generated mathematically based on others that surround it.
|
|
2021-04-05 06:33:20
|
that's what does the magic.
|
|
2021-04-05 06:33:31
|
in modular i have not read manuals
|
|
2021-04-05 06:33:58
|
but i guess one of the most important feature is the squeeze transform
|
|
2021-04-05 06:34:13
|
https://nicholasmarmonti.com/tutorial/webp-immagini/
|
|
2021-04-05 06:34:35
|
don't know where he found this information
|
|
|
|
BlueSwordM
|
|
Pieter
you're talking about cjxl, not jpeg-xl itself?
|
|
2021-04-05 06:49:55
|
He's talking about an encoder that has good enough heuristics to decide which compression mode to use in which parts of the image.
|
|
|
|
Deleted User
|
|
BlueSwordM
He's talking about an encoder that has good enough heuristics to decide which compression mode to use in which parts of the image.
|
|
2021-04-05 06:57:01
|
No way. Not yet. It still can't decide automatically between VarDCT and palettized Modular and <@416586441058025472> is talking about more advanced heuristics? The only scenario where `cjxl` picks Modular automatically is where `-q` is below 7, otherwise it just always picks VarDCT. We have to wait. You can use my `cjxl_auto.sh` bash script (and edit it, of course) before that happens.
|
|
|
|
BlueSwordM
|
|
No way. Not yet. It still can't decide automatically between VarDCT and palettized Modular and <@416586441058025472> is talking about more advanced heuristics? The only scenario where `cjxl` picks Modular automatically is where `-q` is below 7, otherwise it just always picks VarDCT. We have to wait. You can use my `cjxl_auto.sh` bash script (and edit it, of course) before that happens.
|
|
2021-04-05 07:00:54
|
I never specified that it was actually done/working <:kekw:808717074305122316>
|
|
|
|
fab
|
2021-04-05 07:07:49
|
for example if you want quality 70
|
|
2021-04-05 07:08:13
|
you can choose n 2 and n3 near lossless 3
|
|
2021-04-05 07:08:41
|
2. it remains modular so slow decoding
|
|
2021-04-05 07:08:58
|
i have to test faster encoding with near lossless does it work
|
|
2021-04-05 07:09:16
|
but anyway nobody will do that so why worry
|
|
2021-04-05 07:09:53
|
at very high percentual web browsers will re convert my files or don't accept or they will remain unreadable by chrome/firefox
|
|
2021-04-05 07:11:32
|
the issue is the slow decoding
|
|
|
|
Pieter
|
2021-04-05 07:11:58
|
I don't understand what you're trying to say. Why would browsers ever reconvert, or be unable to read your files?
|
|
2021-04-05 07:12:07
|
If they support jxl, they hopefully support all of it.
|
|
2021-04-05 07:12:43
|
Browsers generally don't encode or convert images.
|
|
2021-04-05 07:14:33
|
I really can't follow.
|
|
|
|
fab
|
|
Pieter
I really can't follow.
|
|
2021-04-05 07:15:13
|
basically what i did in benchmarks allow to convert like to d 5.2
|
|
2021-04-05 07:15:23
|
but is not automatic
|
|
|
|
Pieter
|
2021-04-05 07:16:07
|
Once browsers support jxl, you won't need to convert to png.
|
|
|
|
fab
|
2021-04-05 07:16:15
|
basically i converted to modular q 86.6 before faster decoding
|
|
2021-04-05 07:16:35
|
to redistribute the pixels
|
|
2021-04-05 07:16:58
|
and the encoder reconstructed better the image
|
|
2021-04-05 07:17:06
|
with that
|
|
2021-04-05 07:17:07
|
https://discord.com/channels/794206087879852103/794206170445119489/828708849481285663
|
|
2021-04-05 07:17:45
|
but i cannot do 4 steps to have better encoding quality at d 5.2 faster decoding 2 d 5.9 faster decoding 4
|
|
2021-04-05 07:18:45
|
WebP compression without loss works thanks to a prediction technique where each pixel block is generated mathematically based on others that surround it.
|
|
2021-04-05 07:19:10
|
this can be done to enhance appeal and visual quality
|
|
2021-04-05 07:20:20
|
like the best of 0.3.7 could be taken to enhance appeal and visual quality
|
|
|
Pieter
Once browsers support jxl, you won't need to convert to png.
|
|
2021-04-05 07:21:05
|
does jpeg xl has a dedicated ssimulacra in the encoding or that you can compile?
|
|
|
|
BlueSwordM
|
|
fab
does jpeg xl has a dedicated ssimulacra in the encoding or that you can compile?
|
|
2021-04-05 07:22:04
|
No, but you can compile butteraugli_main if you want.
|
|
|
|
Deleted User
|
|
fab
does jpeg xl has a dedicated ssimulacra in the encoding or that you can compile?
|
|
2021-04-05 07:22:13
|
JPEG XL already uses internally another metric, Butteraugli.
|
|
|
|
fab
|
2021-04-05 07:22:16
|
so ssimulacra is from another author
|
|
2021-04-05 07:22:27
|
when it was latest build of ssimulacra?
|
|
|
|
Deleted User
|
|
fab
so ssimulacra is from another author
|
|
2021-04-05 07:22:29
|
Yes, from Jon.
|
|
|
|
fab
|
2021-04-05 07:22:38
|
and is there a specific version for jpeg xl?
|
|
2021-04-05 07:24:21
|
this was the original text
|
|
2021-04-05 07:24:22
|
La compressione WebP senza perdita funziona grazie ad una tecnica di previsione dove ciascun blocco di pixel viene generato matematicamente in base ad altri che lo circondano.
|
|
2021-04-05 07:27:51
|
near lossless honestly is useless (in most cases)
|
|
2021-04-05 07:28:02
|
because q 86.6 modular file with those settings and 0.3.7 is big and the file needs to be reduced by 60%
|
|
|
No way. Not yet. It still can't decide automatically between VarDCT and palettized Modular and <@416586441058025472> is talking about more advanced heuristics? The only scenario where `cjxl` picks Modular automatically is where `-q` is below 7, otherwise it just always picks VarDCT. We have to wait. You can use my `cjxl_auto.sh` bash script (and edit it, of course) before that happens.
|
|
2021-04-05 07:30:38
|
right
|
|
2021-04-05 07:31:39
|
i was thinking in the fantasy. like it can't do q 70 vardct after that q 86.6 settings without looking an upscaled mess without any visual quality and feelings
|
|
2021-04-05 07:32:06
|
how it can choose N 2 N3 near lossless 2 near lossless 3 automatically based on a heuristic?
|
|
|
|
_wb_
|
|
fab
when it was latest build of ssimulacra?
|
|
2021-04-05 07:36:28
|
there's a ssimulacra_main tool in the jxl repo too - might be practical since the original one depends on opencv, which is a bit of a heavy dependency
|
|
|
|
BlueSwordM
|
2021-04-05 07:37:52
|
Oh yeah, it is available.
|
|
|
|
_wb_
|
2021-04-05 07:37:58
|
in practice, the goal is that you can just do `cjxl input.whatever output.jxl` without options and it does something good
|
|
2021-04-05 07:38:11
|
for most images that is already kind of the case
|
|
2021-04-05 07:40:11
|
only for non-photographic images we could do more to detect that it's non-photographic and try modular (or segment it into modular and vardct parts)
|
|
2021-04-05 07:40:46
|
lossy modular is not that useful
|
|
2021-04-05 07:42:12
|
lossy modular is not perceptually based, it just quantizes squeeze residuals and you get what you get, which is usually quite a lot worse than what VarDCT can do
|
|
|
|
fab
|
|
_wb_
lossy modular is not perceptually based, it just quantizes squeeze residuals and you get what you get, which is usually quite a lot worse than what VarDCT can do
|
|
2021-04-05 07:42:31
|
this was the answers i was searching
|
|
|
|
_wb_
|
2021-04-05 07:42:42
|
sacrifice quality to have good fidelity? that does not make sense to me 🙂
|
|
|
|
BlueSwordM
|
|
_wb_
sacrifice quality to have good fidelity? that does not make sense to me 🙂
|
|
2021-04-05 07:44:35
|
I think what he wants is a very powerful encoder that is the absolute master of all.
|
|
2021-04-05 07:44:52
|
Best lossless encoder, best lossy encoder in all situations. 😛
|
|
|
|
fab
|
2021-04-05 07:44:58
|
If i remember the distance with that 60.4 fd2 was like d 5t.2
|
|
|
BlueSwordM
I think what he wants is a very powerful encoder that is the absolute master of all.
|
|
2021-04-05 07:45:23
|
like even to encode grass when there is the bible easter
|
|
2021-04-05 07:46:09
|
and to be better than AV1 and you can choose fidelity appeal like with more options
|
|
2021-04-05 07:47:32
|
Here's are the ANSWERS they made to me plus other things
|
|
2021-04-05 07:47:34
|
ME: La compressione WebP senza perdita funziona grazie ad una tecnica di previsione dove ciascun blocco di pixel viene generato matematicamente in base ad altri che lo circondano.
WebP compression without loss works thanks to a prediction technique where each pixel block is generated mathematically based on others that surround it.
OTHERS: so ssimulacra is from another author Yes, from Jon.
JPEG XL already uses internally another metric, Butteraugli.
JON SNEYERS core dev of jpeg xl:. lossy modular is not perceptually based, it just quantizes squeeze residuals and you get what you get, which is usually quite a lot worse than what VarDCT can do
there's a ssimulacra_main tool in the jxl repo too - might be practical since the original one depends on opencv, which is a bit of a heavy dependency
ME: near lossless honestly is useless (in most cases)
because q 86.6 modular file with those settings and 0.3.7 is big and the file needs to be reduced by 60%
|
|
|
|
BlueSwordM
|
2021-04-05 07:47:54
|
What do you want Fabian?
|
|
2021-04-05 07:48:03
|
Do you want a better near_lossless mode or a better lossy mode?
|
|
|
|
_wb_
|
|
BlueSwordM
Best lossless encoder, best lossy encoder in all situations. 😛
|
|
2021-04-05 07:50:20
|
That is what we're aiming for too. Encoders can always be improved though.
|
|
|
|
BlueSwordM
|
2021-04-05 07:57:46
|
Indeed. CJXL is just the beginning.
|
|
|
|
Jyrki Alakuijala
|
2021-04-06 01:25:29
|
modular will likely never be quite as good in quality like vardct
|
|
2021-04-06 01:26:17
|
JPEG XL's vardct and modular are both fidelity optimized vs. comfort optimized in other codecs
|
|
|
fab
ME: La compressione WebP senza perdita funziona grazie ad una tecnica di previsione dove ciascun blocco di pixel viene generato matematicamente in base ad altri che lo circondano.
WebP compression without loss works thanks to a prediction technique where each pixel block is generated mathematically based on others that surround it.
OTHERS: so ssimulacra is from another author Yes, from Jon.
JPEG XL already uses internally another metric, Butteraugli.
JON SNEYERS core dev of jpeg xl:. lossy modular is not perceptually based, it just quantizes squeeze residuals and you get what you get, which is usually quite a lot worse than what VarDCT can do
there's a ssimulacra_main tool in the jxl repo too - might be practical since the original one depends on opencv, which is a bit of a heavy dependency
ME: near lossless honestly is useless (in most cases)
because q 86.6 modular file with those settings and 0.3.7 is big and the file needs to be reduced by 60%
|
|
2021-04-06 01:35:32
|
I wrote the WebP near-lossless encoder and designed its operational principle -- and it uses primitive psychovisual modeling, not optimizing psnr or 'math'. The idea there was to throw away some bits of the value if it is part if the surrounding values have more changes than that value.
|
|
2021-04-06 01:36:22
|
JPEG XL near-lossless is more for feature parity than for actual use -- the VarDCT is just a better value for less cost
|
|
|
|
_wb_
|
2021-04-06 01:50:25
|
For any natural image, the DCT is great and VarDCT mode is a well-oiled machine to give good perceptual results. Modular mode is a generic approach that doesn't have any perceptual modeling in the encoder. It is useful to encode non-perceptual data, like alpha channels and control fields, or for lossless or non-perceptually-driven lossy encoding (like for the DC).
|
|
|
|
Jyrki Alakuijala
|
2021-04-06 02:16:45
|
I suspect we can reduce the gap between modular and vardct eventually -- it just hasn't been a priority so I never butteraugli-optimized the scalings there even though Luca requested it a few times
|
|
|
Moritz Firsching
|
2021-04-06 02:17:04
|
right now the only way to get it is to compile chrome on your own patching in the change here: https://chromium-review.googlesource.com/c/chromium/src/+/2749318/
However we hope to get this submitted soon, and then it should trickle in the canary and devs build https://www.chromium.org/getting-involved/dev-channel
|
|
|
|
Jyrki Alakuijala
|
2021-04-06 02:17:19
|
the contrast sensitivity curve mapping is whatever happened to come out of the fingertips of Luca at a time
|
|
2021-04-06 02:17:47
|
Go Moritz!!!
|
|
|
|
Moritz Firsching
|
|
<@!795684063032901642> probably has his own JXL-enabled Chromium build, can we somehow get it, please?
|
|
2021-04-06 02:18:41
|
(in reply to this..)
|
|
|
|
Jyrki Alakuijala
|
2021-04-06 02:28:25
|
but better to wait until it is in the repository
|
|
|
|
_wb_
|
2021-04-06 04:07:17
|
<@!795684063032901642> exciting that the first canary with jxl support is getting close!
|
|
2021-04-06 04:07:51
|
Has work already started on adding support for progressive decode or animation?
|
|
2021-04-06 04:12:18
|
In my opinion we need that before the flag can be default-on, otherwise things get complicated for content providers: if browsers are saying they accept `image/jxl` , but some mean "any jxl" while others mean "only still-image jxl", we'll have to resort to user agent version to know whether we can send an animated jxl or not
|
|
|
|
Pieter
|
2021-04-06 04:13:00
|
_guesses: nobody is seriously going to use animated jxl_
|
|
|
|
monad
|
2021-04-06 04:54:19
|
Not even losslessly converting from animated GIF?
|
|
|
|
Pieter
|
2021-04-06 05:08:28
|
do animated gifs really still exist?
|
|
2021-04-06 05:08:42
|
aren't those all secretly mpeg4 videos with .gif extension?
|
|
|
|
BlueSwordM
|
|
Pieter
do animated gifs really still exist?
|
|
2021-04-06 05:08:53
|
No sadly.
|
|
2021-04-06 05:09:07
|
Otherwise, Giphy and other website's videos would load in less than a second.
|
|
2021-04-06 05:11:40
|
Currently, on a 15mbps connection, larger videos take a lot of time to load.
|
|
|
|
monad
|
2021-04-06 05:28:02
|
Well, Giphy for example still hosts source GIFs and provides UI to download them. IIRC, you can also get GIFs from Imgur even when they serve a video by default, but it's been a while since I tried.
|
|
2021-04-06 05:29:23
|
In this case, it might not be compelling, I just know I run into animated GIFs regularly ... my media hoard is a testament.
|
|
2021-04-06 05:34:07
|
Mm, tumblr serves GIFs.
|
|
|
|
Deleted User
|
2021-04-06 06:29:55
|
Is it possible to move the canvas of jxl and treat this movement as animation frames? I.e. a 100x100 image with a 400x100 canvas that moves by 100 pixel each frame?
|
|
|
|
_wb_
|
2021-04-06 06:49:16
|
kind of, yes. You can have invisible oversized frames, and patch them to real frames with a moving patch offset
|
|
|
lonjil
|
|
Pieter
aren't those all secretly mpeg4 videos with .gif extension?
|
|
2021-04-07 04:35:19
|
every time someone uploads a gif to Discord, rather than link to giphy or elsewhere, it is a real gif
|
|
|
|
fab
|
2021-04-07 12:13:59
|
https://renewedtab.rubenwardy.com/
|
|
2021-04-07 12:14:09
|
and use jpeg xl
|
|
|
|
_wb_
|
2021-04-07 01:03:26
|
once chrome has native jxl support: 1
|
|
|
|
fab
|
2021-04-07 01:45:22
|
Date: April 19, 2021 - April 23, 2021
|
|