|
lithium
|
2021-06-19 09:23:23
|
I think we extremely passionate about image quality 🙂
|
|
|
|
Deleted User
|
2021-06-19 12:02:53
|
<@!794205442175402004> or <@!532010383041363969> How are ISO and JPEG connected to you guys? Couldn't you just have worked together on Cloogle XL without both of them? Would have made things easier with Chrome and AOM, and publishing of the spec.
|
|
|
_wb_
|
2021-06-19 12:54:31
|
ISO/JPEG brought us together, we both submitted a proposal to the jpeg XL call for proposals which was what got the collaboration started.
|
|
2021-06-19 12:56:36
|
The JPEG committee also had some useful feedback during the development process, it helped to make the bitstream/spec better. We could probably also have done it without them, but they did help.
|
|
2021-06-19 12:58:02
|
ISO is mostly bureaucracy, but there is value in making an international standard that get approved by all the national standardization bodies, and having a structured process.
|
|
2021-06-19 01:03:28
|
Ad hoc industry alliances like AOM have the benefit of lower bureaucratic overhead and not having to deal with annoying things like ISO's paywall, but maybe also more risk of not having a clearly defined process, ending up with a 'never really final' spec and all the potential interoperability issues that can cause.
|
|
2021-06-19 01:12:27
|
JPEG brings experts together from software industry, hardware industry, and academia. The meetings do help to broaden perspective and consider the various use cases.
|
|
|
|
Deleted User
|
2021-06-19 03:09:22
|
JPEG XL being an ISO standard would also help with integrating it with other ISO standards, like PDF (ISO 32000).
|
|
|
fab
|
2021-06-19 06:30:42
|
do any of jpeg xl dev or pascal massimino use special glass to see more colors or range?
|
|
|
_wb_
ISO/JPEG brought us together, we both submitted a proposal to the jpeg XL call for proposals which was what got the collaboration started.
|
|
2021-06-19 06:31:23
|
this comment is too complex for me, but i agree
|
|
|
|
_wb_
|
|
fab
do any of jpeg xl dev or pascal massimino use special glass to see more colors or range?
|
|
2021-06-19 06:33:59
|
I don't think it's very useful to artificially see more than what normal vision can see, besides zooming in on an image. The point of lossy is that it's ok if something changes but you cannot see it.
|
|
|
|
fab
|
2021-06-19 06:34:48
|
so you don't do commonly
|
|
|
|
_wb_
|
2021-06-19 06:43:21
|
I don't even know about special glasses to see more, is that a real thing?
|
|
2021-06-19 06:43:46
|
Would be easier to just enhance contrast or whatever in software
|
|
|
improver
|
2021-06-19 06:45:44
|
ultraviolet range compression when
|
|
2021-06-19 06:49:38
|
(also yeah perceptual optimizations don't make sense if you can't see stuff without special means, and i know one could encode that stuff as separate modular channels, but it still felt right to ask that question)
|
|
|
|
fab
|
2021-06-20 01:02:17
|
probably even the commit of libwebp2 that will be out today or tomorrow can do good at smoothing instagram photos
|
|
2021-06-20 01:02:42
|
jpeg xl does better on libjpeg photos
|
|
2021-06-20 01:02:55
|
on mozjpeg isn't that accurate
|
|
2021-06-20 01:04:38
|
webp2 it needs speed 9
|
|
2021-06-20 01:04:41
|
is slow
|
|
2021-06-20 01:04:51
|
and anyway it will change
|
|
2021-06-20 01:04:57
|
encoder will change
|
|
2021-06-20 01:11:28
|
the bad thing isn't that there are no real comparison doing by experts
|
|
2021-06-20 01:11:39
|
because low bpp performance= MARKETING isn't ready
|
|
|
|
_wb_
|
2021-06-20 01:13:30
|
We need more people to do evaluations at the qualities they actually want to use
|
|
2021-06-20 01:14:30
|
And have more public evaluation results
|
|
|
|
fab
|
2021-06-20 01:14:54
|
so you can claim raw photos are good with jxl
|
|
|
|
_wb_
|
2021-06-20 01:15:18
|
Currently it's too much anecdotal evidence plus some metrics that we all know mean very little
|
|
|
|
fab
|
2021-06-20 01:19:26
|
do you think jpeg xl will be discontinued as some point
|
|
2021-06-20 01:19:41
|
and JPEG ISO will remain without a jpeg xl congress
|
|
2021-06-20 01:19:49
|
so you will lose work
|
|
2021-06-20 01:19:54
|
can it happen?
|
|
2021-06-20 01:30:22
|
like webp2 next commit for this type of jpg (instagram) i bet it will do well
|
|
2021-06-20 01:30:23
|
https://www.instagram.com/p/CQUC1VNselN/
|
|
2021-06-20 01:31:07
|
because it clears the green
|
|
|
|
_wb_
|
|
fab
do you think jpeg xl will be discontinued as some point
|
|
2021-06-20 01:53:10
|
Everything becomes obsolete at some point, I hope that will take a while for jxl though
|
|
2021-06-20 01:53:47
|
I don't work for JPEG or ISO, jxl is also only part of my job
|
|
|
Orum
|
2021-06-20 03:56:49
|
Well if jpeg is anything to go by....
|
|
|
Scientia
|
|
fab
do you think jpeg xl will be discontinued as some point
|
|
2021-06-20 05:55:06
|
Everything dies
|
|
2021-06-20 05:55:28
|
In 50 years I'm almost certain jpeg will have died
|
|
|
diskorduser
|
2021-06-20 05:57:53
|
After 20 years jpeg xxl or xxxl will come. :p I hope fabian would be the developer of the image format.
|
|
|
|
Scientia
|
|
diskorduser
After 20 years jpeg xxl or xxxl will come. :p I hope fabian would be the developer of the image format.
|
|
2021-06-20 06:02:30
|
It would have a distance setting from 0 to 10, 1.38457535 would be lossless and 3.4647647 would be visually lossless
|
|
2021-06-20 06:02:39
|
<:kekw:808717074305122316>
|
|
|
Cool Doggo
|
|
Scientia
It would have a distance setting from 0 to 10, 1.38457535 would be lossless and 3.4647647 would be visually lossless
|
|
2021-06-20 06:03:16
|
then what would 0 be <:MonkaU:739712711583203381>
|
|
|
|
Scientia
|
2021-06-20 06:03:27
|
ask fabian
|
|
|
Crixis
|
2021-06-20 06:04:02
|
0 is original enhancement
|
|
|
BlueSwordM
|
|
Scientia
In 50 years I'm almost certain jpeg will have died
|
|
2021-06-20 06:05:21
|
Nah, JPEG will live forever 🐬
|
|
|
|
Cool Doggo
|
2021-06-20 06:15:15
|
https://www.youtube.com/watch?v=es21Ia2DiWs butteraugli distmap from -d 0.01 to -d 5 (other settings default) 👍
|
|
|
|
_wb_
|
|
BlueSwordM
Nah, JPEG will live forever 🐬
|
|
2021-06-20 06:17:12
|
Yes, jpeg will be like the ancient greek of image formats. Archeologists from the future will know how to read it.
|
|
2021-06-20 06:17:23
|
I hope jxl can reach that kind of adoption too.
|
|
|
Cool Doggo
https://www.youtube.com/watch?v=es21Ia2DiWs butteraugli distmap from -d 0.01 to -d 5 (other settings default) 👍
|
|
2021-06-20 06:20:26
|
Is that a superposition of heatmap and compressed image? Might be nicer to put those side by side (and also maybe a zoomed in part where you can clearly see what happens, even after youtube recompression)
|
|
|
|
Cool Doggo
|
2021-06-20 06:22:08
|
its the heatmap overlayed on the original image, but because of the dimensions it was kinda hard to show the compressed one in a side by side comparison
|
|
2021-06-20 06:22:27
|
i might try it again with something that can fit better in that format, or maybe just have 3 different clips showing different parts 🤔
|
|
|
|
lithium
|
2021-06-20 07:43:47
|
JPEG 2077: Time to Dethrone JPEG XL! 😛
|
|
|
Jyrki Alakuijala
|
|
Cool Doggo
https://www.youtube.com/watch?v=es21Ia2DiWs butteraugli distmap from -d 0.01 to -d 5 (other settings default) 👍
|
|
2021-06-20 08:05:23
|
Thank you for doing this. This kind of visualization inspires new ideas for encoding strategies 😄
|
|
|
BlueSwordM
Nah, JPEG will live forever 🐬
|
|
2021-06-20 08:25:23
|
7 bit ascii and its 8 bit national extensions have been replaced by utf-8 to a large extent -- there can be progress in things that seem relatively fixed
|
|
|
|
Scientia
|
|
Cool Doggo
https://www.youtube.com/watch?v=es21Ia2DiWs butteraugli distmap from -d 0.01 to -d 5 (other settings default) 👍
|
|
2021-06-20 09:14:37
|
I never realized that butteraugli would do that to the color
|
|
|
|
Jyrki Alakuijala
|
2021-06-20 09:15:46
|
before Google I worked with radiation therapy treatment planning
|
|
2021-06-20 09:16:06
|
there we always show radiation as pseudocolor overlay on ct images
|
|
2021-06-20 09:16:46
|
butteraugli's pseudocolor map follows the same idea (with some extensions)
|
|
|
|
_wb_
|
2021-06-21 07:55:31
|
I just realized that if we really want to do interleaved RGB like PNG/lossless WebP instead of the planar jxl does, we could, kind of. You could simply make a palette of all 2^24 RGB colors and it wouldn't be pretty nor efficient but that palette itself can be compressed down to nothing (it's a 'jxl art' type thing with zero residual entropy), and then encode RGB pixels directly. Only direct predictors (`W`, `N`, `WW`, `NW` etc) would be useful then, and I doubt it would ever be a good idea.
|
|
2021-06-21 09:48:55
|
yes
|
|
2021-06-21 09:49:16
|
modular does things in a planar way
|
|
2021-06-21 09:49:50
|
(that makes it easier to do arbitrary number of channels and also things like having some channels subsampled)
|
|
2021-06-21 09:51:27
|
interleaved has the advantage in the context of lz77 matches that you can copy series of whole pixels, in planar you would have to encode the lz77 match itself 3 (or nb_channels) times
|
|
|
|
Jyrki Alakuijala
|
2021-06-21 10:44:06
|
we checked that in an internship in 2017 or so
|
|
2021-06-21 10:45:09
|
I wanted to understand if our lz77 in WebP lossless is producing savings or not compared to a modern general purpose approach (brotli), and if brotli-based WebP lossless would be actually more efficient
|
|
2021-06-21 10:45:36
|
we even tried tweaking the context modeling of brotli a little to accomodate that idea (to use 2d context)
|
|
2021-06-21 10:46:20
|
lz77 benefitted a lot from channels being coded separately, and separate channels got relatively close to coding pixels instead of channels
|
|
2021-06-21 10:46:32
|
the difference was around 3 % and there were ways to further reduce it (that we didn't explore)
|
|
2021-06-21 10:47:47
|
those results and the additional flexibility that a great palette model gives made it possible for me not to insist on having the same kind of lz77 like we I implemented in WebP lossless
|
|
2021-06-21 10:48:24
|
for me the WebP lossless type of LZ77 is the most natural and fits my thinking best -- but it turned out that it doesn't matter that much which model is used
|
|
2021-06-21 10:48:58
|
(as long as it is not what PNG does, i.e., interleaved and byte based)
|
|
2021-06-21 10:56:42
|
In that test we took 1000 png images from the internet randomly (possibly with the requirement of having 1 % or more of transparency, don't remember any more)
|
|
2021-06-21 10:57:51
|
first test was with deflate as a compression format and just looking at png filters vs. webp lossless filters:
|
|
2021-06-21 10:58:45
|
pngout produced 871890 bytes, webp lossless filters zopfli compressed was 855762 bytes (for images with 256 colors or less part of the corpus)
|
|
2021-06-21 11:00:26
|
for the whole corpus including non-index-color images 25942082 bytes and 22506013 bytes (png filtering vs. webp filtering using deflate)
|
|
2021-06-21 11:01:07
|
... however, deflate got better if we transposed RGBA separately before compressing: 20496062 bytes for WebP filters (not tested with png filters)
|
|
2021-06-21 11:03:24
|
changing deflate to LZMA (xz) wasn't a success, it gave 20711492 bytes, possibly because many of the files were small enough for deflate or correlations had in general short distances
|
|
2021-06-21 11:04:37
|
changing deflate to brotli (-11) improved: we got 19702002 bytes with WebP lossless filters
|
|
2021-06-21 11:07:41
|
WebP lossless with its LZ77 and the 'color cache' system got down to 19169032 bytes
|
|
2021-06-21 11:09:14
|
Conclusion of that part of the internship was "WebP LZ77 compression is superior to zlib and LZMA. Brotli's LZ77 is comparable to WebP in images that can be palettized, but slightly worse on RGBA images."
|
|
2021-06-21 11:11:04
|
I brought one of the key elements from WebP lossless's LZ77 into JPEG XL, i.e., its 2d look-up table. That, and the powerful context modeling we have, will in my best understanding make JPEG XL's LZ77 approach most future proof and a good balanced design.
|
|
2021-06-21 01:32:09
|
hacker news discussion about jpeg xl can be interesting https://news.ycombinator.com/item?id=27577328
|
|
|
incredible_eagle_68175
|
2021-06-21 05:29:24
|
I’m not a big fan of hacker news (Reddit is better IMO) but will check out.
|
|
|
|
Jyrki Alakuijala
|
2021-06-21 09:26:44
|
at early look at next round of optimization ... it seems like the tree reversal has unblocked another 3.7 % improvement to VarDCT
|
|
2021-06-21 09:27:15
|
3.7 % in BPP * pnorm sense, and confirmed at the first look at results
|
|
2021-06-21 09:27:34
|
If every day was like today, we could soon deliver many images in a single bit 😄
|
|
|
|
Crixis
|
2021-06-21 09:29:05
|
any example?
|
|
|
|
Deleted User
|
|
Jyrki Alakuijala
If every day was like today, we could soon deliver many images in a single bit 😄
|
|
2021-06-21 09:29:39
|
You know that LenPEG exists?
|
|
2021-06-21 09:34:11
|
https://www.dangermouse.net/esoteric/lenpeg.html
|
|
|
|
Crixis
|
2021-06-21 09:43:26
|
LenPEG 4 is cool!
|
|
|
|
Jyrki Alakuijala
|
2021-06-21 09:55:08
|
we are working on supergravity modeling to improve on the final solution of compression
|
|
|
Crixis
any example?
|
|
2021-06-21 09:56:07
|
I'll try to make it a bit more conservative in some of its decisions first
|
|
2021-06-21 10:28:13
|
I'm trying to redirect the generic savings a bit everywhere to address ringing more
|
|
2021-06-21 10:35:48
|
it is a weakness in butteraugli that it doesn't emphasize "no ringing close to high contrast boundaries at high levels of distortion"
|
|
2021-06-21 10:43:49
|
Crixis, here an example at 0.32 bpp (both look bad):
|
|
2021-06-21 10:44:05
|
Before:
|
|
2021-06-21 10:44:25
|
After:
|
|
|
|
Crixis
|
2021-06-21 10:46:50
|
Seem good!
|
|
|
|
Jyrki Alakuijala
|
2021-06-21 11:05:19
|
(it still has issues that I'd like to fix or mitigate -- not visible in this image, but in others, some ringing can get slightly worse in places)
|
|
|
raysar
|
|
Jyrki Alakuijala
(it still has issues that I'd like to fix or mitigate -- not visible in this image, but in others, some ringing can get slightly worse in places)
|
|
2021-06-21 11:24:50
|
Great ! in this example artifacts is less visible.
|
|
|
retr0id
|
2021-06-22 01:21:40
|
How big is the smallest valid jxl file?
|
|
|
monad
|
2021-06-22 01:26:45
|
<https://github.com/mathiasbynens/small/blob/master/jxl.jxl>
|
|
|
|
Cool Doggo
|
2021-06-22 01:27:10
|
i was about to say 17 bytes but i guess not
|
|
2021-06-22 01:27:14
|
<:thonkang:265487232083689473>
|
|
|
|
retr0id
|
2021-06-22 01:27:32
|
noice
|
|
|
|
Jyrki Alakuijala
|
|
raysar
Great ! in this example artifacts is less visible.
|
|
2021-06-22 02:11:22
|
it is small, important, but also risky steps 🙂
|
|
|
|
_wb_
|
|
retr0id
How big is the smallest valid jxl file?
|
|
2021-06-22 05:15:55
|
I think 17 bytes
|
|
|
|
monad
|
2021-06-22 08:10:46
|
So the 16 byte JXL is invalid?
|
|
|
|
_wb_
|
|
monad
So the 16 byte JXL is invalid?
|
|
2021-06-22 08:27:22
|
ah lol no it is valid
|
|
2021-06-22 08:29:02
|
surprisingly, a black 256x256 image can be done in 16 bytes, while a black 1x1 image requires at least 17 bytes
|
|
2021-06-22 08:29:58
|
this is because the size header has a short code for small images with dimensions that are a multiple of 8 (and the largest you can express with that is 256x256)
|
|
2021-06-22 08:33:51
|
lossy does have some things to do that lossless doesn't have to do (DC, quant factors, quant weight map, chroma from luma map, AC, etc). For something as trivial as a 1x1 image, even if all of those things are trivial, it does add a few bytes each so you end up with something larger than the lossless thing.
|
|
2021-06-22 08:34:02
|
you can see where the bits are going if you do cjxl -v
|
|
|
|
Jyrki Alakuijala
|
2021-06-22 09:03:56
|
the first opensourced version of WebP lossless could do a single black pixel in six bytes 🙂
|
|
2021-06-22 09:04:41
|
later, header bloat was added to match with webp lossy, so it is likely 30 bytes or so
|
|
|
|
_wb_
|
2021-06-22 09:04:44
|
|
|
2021-06-22 09:05:30
|
sigh, that's a 1 pixel gif I uploaded
|
|
2021-06-22 09:05:40
|
```
$ cjxl black.gif black.gif.jxl -m -P 0
JPEG XL encoder v0.3.7 [SSE4,Scalar]
Read 1x1 image, 0.0 MP/s
Encoding [Modular, lossless, squirrel], 4 threads.
Compressed to 17 bytes (136.000 bpp).
```
|
|
|
|
Jyrki Alakuijala
|
2021-06-22 09:08:50
|
makes me wonder what the 4 threads were doing
|
|
2021-06-22 09:09:37
|
each thread taking one of the four edges of the pixel 🙂 ?
|
|
|
|
_wb_
|
2021-06-22 09:14:07
|
https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.gde87dfbe27_0_43
|
|
2021-06-22 09:14:23
|
|
|
2021-06-22 09:15:13
|
that's my best effort 1-pixel image in various formats, probably you could shave off a few bytes in some of them
|
|
2021-06-22 09:15:53
|
(in particular for HEIC I didn't try much, I just took what Apple Preview produced when I did "export to HEIC")
|
|
2021-06-22 09:17:39
|
|
|
2021-06-22 09:24:01
|
i'm ridiculing the avif header verbosity a bit, and in general it probably doesn't matter that much, but I wouldn't say it doesn't matter at all — people are doing things like this: https://www.w3schools.com/css/css_image_sprites.asp (putting multiple images in one spritesheet and using CSS to show the individual subimages) and this: https://engineering.fb.com/2015/08/06/android/the-technology-behind-preview-photos/ (using a fixed JPEG header that gets slapped on using javascript so only the actual payloads have to be sent)
|
|
2021-06-22 09:25:01
|
Those approaches are done **only** to avoid header overhead (in the past it was also to reduce the number of http/1 requests, but with http/2 that is no longer a real problem)
|
|
|
|
Jyrki Alakuijala
|
2021-06-22 09:27:04
|
I consider spriting is also a consequence of header overhead
|
|
|
|
_wb_
|
2021-06-22 09:27:36
|
yes, css sprites was the first link above (discord didn't make a preview for it)
|
|
2021-06-22 09:28:57
|
such approaches are an operational/maintenance nightmare
|
|
|
|
Jyrki Alakuijala
|
2021-06-22 09:29:12
|
did you do the WebP image size with lossy or lossless?
|
|
|
|
_wb_
|
2021-06-22 09:29:28
|
lossless I think gave the smallest size
|
|
|
|
Jyrki Alakuijala
|
2021-06-22 09:29:38
|
no surprise 😄
|
|
|
|
_wb_
|
2021-06-22 09:32:26
|
distributing the semantics of "what is an image" over the image codec itself, CSS, HTML, Javascript is a bad idea imo. Keeping things self-contained and atomic is much easier to work with.
|
|
2021-06-22 09:32:49
|
same thing for "icon fonts" instead of using one svg per icon
|
|
2021-06-22 09:37:20
|
For the "LQIP" problem (where now things like blurhash are used) and the "responsive images" problem (both resolution-based – different file for the 1x, 2x, 3x image – and 'artistic' responsive images – different crop/aspect ratio for different website layouts) we are currently still in a state where you do need to mix HTML, CSS and make several image variants to get what you want.
|
|
2021-06-22 09:40:39
|
I think the jxl bitstream might be flexible enough to bring a 'good enough' single-file solution. We can use group ordering to signal the smaller crop first, we can use progressive to make a partial bitstream act like a lower res version, we can use DC as LQIP (or a bit earlier than DC, with progressive DC, a blurry-upscaled 1:16 or 1:32 image).
|
|
2021-06-22 09:43:52
|
It will require a very significant amount of work to make that work, including probably some new HTML syntax to specify things and making browsers smart enough (e.g. fetch TOC part of the bitstream first, then make an appropriate range request based on what layout says will be needed), and it is unlikely to happen anytime soon.
|
|
2021-06-22 09:48:34
|
But I do still think that this is the future to simplify the operational/maintenance aspects of responsive images on the web. In the end, it might be possible to have just a single <img> tag, where CSS will decide what the desired aspect ratio and resolution is for the image, and the browser figures out how much of the bitstream it needs to fetch to get enough to render that. That would be an incredible simplification from a web dev point of view.
|
|
|
|
Jyrki Alakuijala
|
2021-06-22 10:30:23
|
I have observed quite a few engineers who feel dirty if there is code or function that does something directly
|
|
2021-06-22 10:30:44
|
they need a wrapper or two before they are comfortable actually doing work in the code
|
|
2021-06-22 10:31:13
|
for this category of engineers unnecessary wrappers makes things more manageable
|
|
2021-06-22 10:31:44
|
for me any non-functional unnecessary part is dirty, and I see cleanliness of design from another more minimalistic lense
|
|
2021-06-22 10:36:45
|
for someone a file format that just does its thing without a bloaty header that includes all kinds of flags (like gzip header adding a flag if compression happened in Amiga) is like handling raw meat, too direct contact with actual engineering and math
|
|
|
|
lithium
|
2021-06-22 10:43:50
|
How to avoid over-engineering on program structural or program process design?
|
|
|
|
_wb_
|
2021-06-22 10:46:17
|
Wrappers and layers of abstractions do have their place in software engineering, and they can be a good thing when used in the right spot, for the right purpose, in the right way, without necessarily causing any real overhead. They're also generally the main cause of all sorts of performance problems.
|
|
|
lithium
How to avoid over-engineering on program structural or program process design?
|
|
2021-06-22 10:48:51
|
In my experience, you cannot really make a good design from just abstract thinking. It requires the hard work of actually implementing stuff and reimplementing it better when lessons have been learned.
|
|
2021-06-22 10:52:07
|
It's better to fail 3 times, learn each time, and then make a good thing on the fourth attempt, then to spend the same amount of time in perfectly designing a great thing from the top down, then spending a lot of time on implementing it, and then end up with something close to that second failed attempt.
|
|
|
|
Jyrki Alakuijala
|
2021-06-22 10:54:30
|
I have seen both approaches to be successful
|
|
2021-06-22 10:55:44
|
pure top down architects (diagram and requirements first), pure bottom up architects (algorithms and data structures first, finalizing requirements once understanding what is easily possible)
|
|
2021-06-22 10:56:00
|
monolithic design vs. modular design, both work
|
|
2021-06-22 10:56:42
|
a lot of passion about the differences, smaller differences in real life
|
|
2021-06-22 10:57:01
|
sometimes people want to bring the abstractions they are used to to another programming environment
|
|
2021-06-22 10:57:17
|
for example to make C++ look like lisp or java
|
|
2021-06-22 10:57:48
|
even they will succeed roughly equally often than doing things the easy way
|
|
2021-06-22 10:58:43
|
like in one project they removed the type safety of C++ and the transactional safety of the sql database (because the architect was not comfortable with either concept)
|
|
2021-06-22 10:59:00
|
still, the project launched and 'worked' well enough
|
|
2021-06-22 10:59:39
|
eventually they put the transactional safety back (since it creates too many limitations and quite some weird behaviour)
|
|
2021-06-22 11:00:28
|
but having no type safety was ok for them, and they have been casting objects and if'ing with the object type now for 25 years successfully
|
|
2021-06-22 11:04:02
|
I personally like to think of software architecture not just something to observe and to have an easy mental access to the construction, but as protection of assets
|
|
2021-06-22 11:04:20
|
this is why I like to start from the most risky and difficult problems, solve them first
|
|
2021-06-22 11:04:46
|
that makes sure that they are not depending on a lot of other shaky and buggy abstractions that are built later in the project
|
|
2021-06-22 11:05:26
|
also I believe it reduces project management risk if the most difficult/risky parts are done first
|
|
2021-06-22 11:06:45
|
often data structures have many different options on how data is modeled, in a very simple example like if an image is represented rgbrgbrgbrgb in the memory or rrrrggggbbbb
|
|
2021-06-22 11:07:45
|
if the data representation is chosen such that the most complex computational requirements are satisfied, it can help with having less copying and shuffling the data -- or having to adapt to an suboptimal representation in the most time consuming algorithms
|
|
2021-06-22 11:10:17
|
for one engineer minimalism means to write 50 lines of their own code so that project can depend on language specification only, for another it is better to include a million line library and increase binary footprint by 3 MB to write the same in one line -- and for some engineers these can feel like life-and-death questions that lead to surprisingly passionate discussions
|
|
|
|
lithium
|
2021-06-22 12:03:21
|
I understand, Thank you for teaching me 🙂
|
|
|
|
Jyrki Alakuijala
|
2021-06-22 12:05:10
|
These are very personal opinions, not much 'truth' in it 😄
|
|
|
|
_wb_
|
2021-06-22 07:40:51
|
<@!532010383041363969> I'm giving floating blocks ac_strategy a try... it's a bit tricky but I got something working
|
|
2021-06-22 08:05:05
|
<@!415302089523331092> currently we select DCT block sizes in a 'naturally aligned' way, e.g. a 16x32 block always starts at a position (x0,y0) where x0 is a multiple of 16 and y0 is a multiple of 32.
|
|
2021-06-22 08:05:54
|
But the bitstream actually allows them to be 'floating', in the sense that the only constraint is that x0 and y0 are a multiple of 8 (and also the block doesn't cross a 256x256 boundary)
|
|
2021-06-22 08:11:09
|
I don't have any actual improvements yet, at least not consistently
|
|
2021-06-22 08:11:32
|
current block selection
|
|
2021-06-22 08:11:52
|
floating block selection
|
|
|
|
Cool Doggo
|
2021-06-22 08:19:57
|
🤔 interesting
|
|
|
Scope
|
2021-06-22 08:20:51
|
Hmm, I wonder if this is implemented in the current Webp2 encoder and gives any noticeable gains?
Also, if doing a comparison on an image where there is a pure single-color area along with more complex parts?
|
|
|
|
fab
|
2021-06-22 08:21:26
|
wp2 has them
|
|
|
|
Scope
|
2021-06-22 08:26:34
|
Something like this:
|
|
2021-06-22 08:26:48
|
or CLIC Photos
|
|
2021-06-22 08:28:32
|
|
|
2021-06-22 08:29:38
|
|
|
|
|
fab
|
2021-06-22 08:30:38
|
i think d 1.49 and up floating blocks after looks good
|
|
2021-06-22 08:31:12
|
less it looks a bit worse
|
|
|
|
_wb_
|
2021-06-22 08:31:49
|
there's tons of ways to do it, just at the point where it's about as good as what we had before 🙂
|
|
|
|
paperboyo
|
|
fab
i think d 1.49 and up floating blocks after looks good
|
|
2021-06-22 08:39:04
|
Looking at both at 200% zoom, video compression notwithstanding, last acceptable and OK is d3.5. Can’t see much difference between before and after, though :-(. First thing that brakes for me beyond d3.5 is the right hand side light… (viewer’s left)
|
|
2021-06-22 08:43:40
|
^ “acceptable” of course in the web context, forgot to add, sorry
|
|
|
|
_wb_
|
2021-06-22 08:49:07
|
no results to see here yet, just trying to explain what "floating blocks" mean
|
|
2021-06-22 08:57:47
|
|
|
2021-06-22 08:58:35
|
you can see how those blocks are a bit more free to move (they still cannot cross 64x64 boundaries atm though)
|
|
2021-06-22 09:04:10
|
(that's after above, before below there)
|
|
2021-06-22 09:05:48
|
It's doing it greedy though, just putting in the bigger blocks wherever is the first spot they fit well enough in.
|
|
2021-06-22 09:06:45
|
While the aligned one is a bit more optimal within its restrictions, since it effectively tries everything that is allowed by the restrictions
|
|
|
|
Scope
|
2021-06-22 09:56:08
|
Also, about similar floating blocks from the Wp2 presentation (for more details, but I don't know if this is used and gives any benefits in the current Wp2 encoder):
https://youtu.be/zogxpP2lm-o?t=452
|
|
|
|
Jyrki Alakuijala
|
|
_wb_
<@!532010383041363969> I'm giving floating blocks ac_strategy a try... it's a bit tricky but I got something working
|
|
2021-06-23 09:18:39
|
I have a complex on-going change right now to ac strategy and would appreciate no parallel efforts there, please wait a week or so before deploying them 🙂
|
|
2021-06-23 09:20:30
|
I don't measure success with ac strategy using butteraugli, but my own eyes -- butteraugli is not sufficiently sensitive to ringing
|
|
|
|
_wb_
|
|
Jyrki Alakuijala
I have a complex on-going change right now to ac strategy and would appreciate no parallel efforts there, please wait a week or so before deploying them 🙂
|
|
2021-06-23 09:25:57
|
Sure, I was just playing with it a bit, not planning to submit any pull request. Also I don't have much time the rest of this week, so I'll wait until you're done 🙂
|
|
2021-06-23 09:30:53
|
There does seem to be a large unexplored region in the ac strategy search space, and greedy approaches (either top-down as before or bottom-up as it is now) might miss a lot. It's a tricky tetris game though, playing with those blocks...
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 09:31:57
|
yes, there is room for improvement
|
|
2021-06-23 09:32:33
|
we unfortunately don't have a working quantitative methodology there so making progress cannot be automated
|
|
2021-06-23 09:33:18
|
perhaps having a separate 'metric' that would only tell if a block is ringing or not (or to what extent it is ringing) would be helpful/practical
|
|
2021-06-23 09:34:36
|
I believe that the non-floating division may be actually optimal (for the heuristics it uses) as it is implemented right now with reversal
|
|
2021-06-23 09:35:04
|
allowing floating divisions would of course increase the search space and allow better solutions
|
|
2021-06-23 09:35:33
|
calling the current search greedy is possibly not the most representative word
|
|
2021-06-23 09:36:14
|
it finds the best combination of 8x8s, then compares the best combos against increasingly better combos in an exhaustive non-floating manner
|
|
2021-06-23 09:37:40
|
trying out 'off-by-one' 16x8s to replace whatever 8x8 are remaining after the current split could be great
|
|
2021-06-23 09:38:43
|
there is some level of non-optimality in trying out 16x8 in one order without considering which order would be the best, but that heuristic is just a fixed order, not greedy
|
|
2021-06-23 09:38:57
|
the same for 32x16 and 64x32
|
|
2021-06-23 09:39:14
|
4x8 and 8x4 are tried both and the better is chosen
|
|
2021-06-23 09:41:03
|
Thank you for kind help Mai! I'm a discord noobie, and often forget how large the JPEG XL discord is.
|
|
2021-06-23 09:49:17
|
Others can read the devs-only, too, or it becomes a secret if I write there?
|
|
|
|
_wb_
|
|
Jyrki Alakuijala
calling the current search greedy is possibly not the most representative word
|
|
2021-06-23 10:10:52
|
Yeah it is not greedy, it is optimal within its constraints, but those constraints could be quite limiting.
|
|
2021-06-23 10:13:45
|
Those entropy multipliers are quite tricky too, since multipliers for small blocks also influence what is done for larger ones
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 10:13:54
|
the next improvement gives this ad d2:epf3
|
|
2021-06-23 10:13:55
|
before:
|
|
2021-06-23 10:14:00
|
|
|
2021-06-23 10:14:18
|
after:
|
|
2021-06-23 10:14:22
|
|
|
2021-06-23 10:15:22
|
around 0.91 bpp
|
|
2021-06-23 10:15:56
|
I consider this a big improvement even if it may look subtle to an occasional viewer 😄
|
|
2021-06-23 10:16:16
|
and this is on top of the acs reversal improvement
|
|
2021-06-23 10:17:46
|
Mai, thank you for pointing it out, that gives me inspiration to work on that in a future improvement 😄
|
|
2021-06-23 10:18:06
|
It is common for image quality improvements not to solve all problems at once 😛
|
|
2021-06-23 10:18:32
|
and if we solved, then there is only temporary happiness and more problems at higher distance values 😄
|
|
|
|
improver
|
|
Jyrki Alakuijala
I consider this a big improvement even if it may look subtle to an occasional viewer 😄
|
|
2021-06-23 10:18:49
|
this legit looks like big improvement
|
|
2021-06-23 10:19:23
|
all the white dots between small chars are gone
|
|
2021-06-23 10:20:25
|
well not all but this is quite an improvement
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 10:20:38
|
Thank you!!
|
|
2021-06-23 10:21:45
|
I'll wrap it up, submit and get to next idea... I think we can still make three changes of this caliber without making things slower (at least at default setting)
|
|
|
|
improver
|
2021-06-23 10:23:05
|
some places close between 2 do get worse
|
|
2021-06-23 10:23:23
|
like if theres small space between 2 whites it gets worse
|
|
2021-06-23 10:23:51
|
but in other places (much more of these) it's legit better
|
|
|
|
paperboyo
|
2021-06-23 10:24:35
|
Pixel-peeping on 300%, it looks better to me. Definitely less artifacts both there and elsewhere. Lot less around small pink letters 😍 . But small pink `g` looses definition.
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 10:24:48
|
It tends to opt for slightly smaller integral transforms now, those ring less, but interpolate geometry worse
|
|
|
|
improver
|
2021-06-23 10:24:51
|
it looks overall cleaner
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 10:25:50
|
I didn't observe a worsening on the blue dot between the letters b/c, but these can depend on brightness, zoom-level, eyes, monitor, etc.
|
|
|
Ringo
|
2021-06-23 10:26:06
|
aside from what's already mentioned above, there's a barely-noticeable gray dot between the "c" and "d" on the first line near the yellow curve
|
|
2021-06-23 10:26:16
|
the pink line at the bottom does look cleaner
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 10:26:21
|
I observed worsenings on other images, but for every degradation there are 5 places where it got better similarly
|
|
|
|
improver
|
2021-06-23 10:26:40
|
yeah that's how I'd describe this
|
|
2021-06-23 10:27:24
|
it also depends on upscaler, some upscalers actually can obscure it
|
|
2021-06-23 10:28:01
|
o. ive not tried that
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 10:40:09
|
I open gallery of images in one tab, another similar gallery in another tab, then I swap them furiously with control-tab
|
|
2021-06-23 10:40:21
|
I try to review d0.8 to d32
|
|
2021-06-23 10:40:39
|
up to d3 or d4 I use 200 % zoom
|
|
2021-06-23 10:41:25
|
at d8 100 %, at d16 and above I lean back a little to have a higher pixel density (otherwise there is no concept of image quality with those distances :-D)
|
|
2021-06-23 10:42:17
|
I use the gallery autogenerated by the banchmark_xl tool
|
|
2021-06-23 10:42:41
|
then I can use 'h' key to activate the butteraugli heatmaps which can hint where to look for differences
|
|
|
|
improver
|
2021-06-23 10:42:52
|
on chromium scrolling when on tabs can also switch them. though I use firefox mostly
|
|
|
eddie.zato
|
2021-06-23 10:45:15
|
Can't wait for this improvement. It looks very promising for some of my images.
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 10:46:32
|
for me the tab switching thing works, so I use it, I can switch a gallery of 50 images in 10 ms or so... with tools I often need to wait or I can only switch one image
|
|
2021-06-23 10:47:34
|
I haven't used the compare_images, although if it is the tool from Sami, I believe it is the best tool around -- does it show a strip of original image in between of the two degraded images?
|
|
|
spider-mario
|
2021-06-23 10:47:50
|
yes, that’s the one
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 10:48:13
|
if I didn't have a process that I'm already happy with, I'd use that tool
|
|
2021-06-23 10:48:27
|
I consider it is the state-of-the-art in image comparison tools 😄
|
|
2021-06-23 10:48:58
|
with my current comparison approach I don't have access to the original in most comparisons
|
|
2021-06-23 10:49:42
|
when I believe I need to know how the original looks, I just add a third tab on Chrome with 0.5 distance
|
|
|
|
_wb_
|
2021-06-23 10:49:44
|
I wonder why dct2x2 is used so heavily at the ridiculous high distance settings
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 10:50:24
|
it is false reporting
|
|
2021-06-23 10:50:40
|
I report 64x64 as 2x2 in the benchmark, I was too lazy to add new column
|
|
2021-06-23 10:50:51
|
or something like that
|
|
|
|
spider-mario
|
2021-06-23 10:50:56
|
iirc it should be the original last
|
|
2021-06-23 10:51:08
|
since it’s optional and I didn’t want an optional parameter in the middle
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 10:51:38
|
the comparison tool was Sami's 20 % project before he joined our team
|
|
|
|
spider-mario
|
2021-06-23 10:52:48
|
thinking about it now, maybe it would have made sense with your order
|
|
2021-06-23 10:52:55
|
but maybe it would be more confusion if we changed it now 😄
|
|
|
|
_wb_
|
|
Jyrki Alakuijala
I report 64x64 as 2x2 in the benchmark, I was too lazy to add new column
|
|
2021-06-23 10:54:11
|
Oh, that explains things, lol. I'll make a PR to add the extra two columns for 32x64 and 64x64, that will be less confusing than reusing 2x2 to also include the big ones
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 11:16:34
|
that would likely be less confusing 😄
|
|
2021-06-23 11:16:44
|
also we don't have a column for identity
|
|
2021-06-23 11:17:49
|
also here for these changes, wait until my current stuff lands, I'm quite a bit wobbly with git -- like right now I have a 'detached head' problem
|
|
2021-06-23 11:32:30
|
Google has 'piper', a centralized version control, it is simpler to think about but possibly less flexible
|
|
2021-06-23 11:32:36
|
https://github.com/libjxl/libjxl/pull/214
|
|
2021-06-23 11:32:46
|
I managed to attach the head and create a pull request
|
|
|
|
retr0id
|
2021-06-23 11:53:38
|
If I wanted to write my own JXL decoder from scratch, just for fun, where should I start, in terms of spec/docs?
|
|
2021-06-23 12:10:28
|
Maybe I should start with a standard jpeg decoder
|
|
2021-06-23 12:12:47
|
Is there a functionally equivalent "draft spec"?
|
|
2021-06-23 12:12:59
|
as with most other paywalled standards
|
|
2021-06-23 12:17:33
|
rip
|
|
2021-06-23 12:18:14
|
I found this, https://arxiv.org/abs/1908.03565, how much has it diverged since then?
|
|
|
|
_wb_
|
|
retr0id
I found this, https://arxiv.org/abs/1908.03565, how much has it diverged since then?
|
|
2021-06-23 12:18:55
|
a huge amount
|
|
|
|
retr0id
|
2021-06-23 12:19:22
|
I sure hope nobody DMs me the leaked FDIS, that would be really annoying
|
|
|
|
_wb_
|
2021-06-23 12:19:51
|
how much time do you have to write a decoder from scratch?
|
|
2021-06-23 12:20:33
|
it's probably quite a bit of work, even if you don't try to make it fast or anything like that
|
|
2021-06-23 12:20:59
|
it would be great though to have other decoders, even if they're only toy projects
|
|
|
|
retr0id
|
2021-06-23 12:21:34
|
I'd probably only have time to implement a subset of features, yeah
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 12:37:12
|
RetrOid -- probably it would be the benefit of the JPEG group to have such a second decoder, and there could be a private agreement with the group and you to get your hands on the FDIS for free
|
|
2021-06-23 12:39:28
|
I would advice against using the summer 2019 committee draft as a starting place for a JPEG XL decoder
|
|
2021-06-23 12:39:48
|
description of the delta would be likely 77 % of the size of the spec
|
|
2021-06-23 12:40:12
|
IIRC, the CD was 180 pages + appendices, while the FDIS is 99 pages or so
|
|
|
|
retr0id
|
|
Jyrki Alakuijala
I would advice against using the summer 2019 committee draft as a starting place for a JPEG XL decoder
|
|
2021-06-23 12:42:36
|
yeah, not planning on it
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 12:45:19
|
RetrOid, did you mention which language you'd be using? Luca was considering of a partial Rust decoder rewrite...
|
|
2021-06-23 12:46:00
|
Luca is just already 'poisoned' by knowing every single detail in how the C++ decoder works, so it wouldn't be testing the spec for completeness
|
|
|
|
retr0id
|
2021-06-23 12:47:10
|
I'm going to be using python, most likely (obviously, performance will not be a goal)
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 12:47:27
|
interesting
|
|
2021-06-23 12:56:18
|
should 'reimplementing' be its own channel here?
|
|
|
|
retr0id
|
2021-06-23 12:57:01
|
I think first, I'm going to try implementing the features required for the tiny files in <#824000991891554375>
|
|
2021-06-23 12:57:10
|
I think those are really neat
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 12:57:50
|
I think many people would be interested in those experiences -- definitely us devs
|
|
|
|
_wb_
|
2021-06-23 12:59:02
|
you'll need modular decoding (the thing jxl-art uses) anyway for all the other stuff, everything except the AC coefficients is compressed using modular subimages
|
|
2021-06-23 12:59:50
|
(well and except patch locations, noise params and splines data, but you get the point)
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 05:16:59
|
https://github.com/libjxl/libjxl/pull/214 merged 😄
|
|
2021-06-23 05:17:23
|
next image quality improvement is already being dreamed on 😄
|
|
2021-06-23 05:18:38
|
next up, I'll be smarter about 16x8, 8x8 and 8x16 combos -- currently it is quite stupid actually (and similarly all rectangle splits: 32x16 and 64x32)
|
|
2021-06-23 05:19:20
|
I anticipate a 0.4 % bpp*pnorm improvement with less ringing again, particularly long distance low amplitude ringing
|
|
|
|
Deleted User
|
2021-06-23 05:19:27
|
What about 128x128 and 256x256?
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 05:19:49
|
I don't have images in my test corpus that would have such stable areas 🙂
|
|
2021-06-23 05:19:57
|
I would need to have a new corpus first 😄
|
|
2021-06-23 05:20:27
|
with the current optimization I'm not even using the 64x32, it only goes up to 32x32 with very few exceptions
|
|
2021-06-23 05:20:54
|
in optimization I geometrically weight the range of 0.5 to 16
|
|
2021-06-23 05:21:05
|
in visual verification I check the range 0.8 to 32
|
|
2021-06-23 05:21:54
|
distance 16 doesn't yet benefit fo much from very large transforms, at least not with my relatively visually dense corpus (photos subsampled 4x4)
|
|
|
|
Deleted User
|
2021-06-23 05:29:04
|
I may be wrong, but I think that decision tree reversal should make using bigger transforms much easier. You can use my photo for testing, you've probably seen it before. This is the original version, without denoising.
|
|
2021-06-23 05:29:08
|
https://cdn.discordapp.com/attachments/794206087879852106/823939658785226762/20210119_235105_-_20210119_235237.jpg
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 05:36:12
|
I have a few smaller ideas that I can work with first, these should be just mathematically better and lead to no additional computation, ... strictly better things
|
|
2021-06-23 05:36:30
|
I can look into larger transforms in two weeks I believe
|
|
2021-06-23 05:37:09
|
I'd love to get feedback on the quality of any changes that I'm deploying so that I don't accidentally go into a wrong direction -- Image quality is complicated
|
|
2021-06-23 05:38:17
|
(I think you are correct with the thinking that the decision tree reversal helps in choosing larger transforms, too)
|
|
|
|
Deleted User
|
|
Jyrki Alakuijala
I can look into larger transforms in two weeks I believe
|
|
2021-06-23 05:50:05
|
Thanks! 😃
|
|
2021-06-23 05:50:48
|
By the way, here's the same image as above, but selectively manually denoised with Topaz DeNoise AI and reencoded to a high quality JXL file (since the original JPG from Topaz is 14.8 MB, too big for Discord Free). Might be useful for further testing.
|
|
|
|
fab
|
2021-06-23 05:57:03
|
cavif rs is great but it changes the thickness of the texture
|
|
2021-06-23 05:57:20
|
new version is good
|
|
2021-06-23 05:57:26
|
speed seems about the same
|
|
2021-06-23 05:57:39
|
but at least you don't wait more than 4, 5 minute for a 12 mpx image
|
|
2021-06-23 05:57:47
|
and smaller images are 448 kb
|
|
2021-06-23 05:58:12
|
and they load in 6 seconds and not progressively decoded
|
|
2021-06-23 05:58:25
|
even if they are small
|
|
2021-06-23 05:59:08
|
the quantizer idea is great, it doesn't distort screenshots and it gives an impression of adaptive quantization
|
|
2021-06-23 05:59:25
|
but i think adaptive quantization isn't even on the reference libaom encoder
|
|
2021-06-23 05:59:27
|
libavif
|
|
2021-06-23 05:59:38
|
AV1 hasn't adaptive quantization
|
|
2021-06-23 06:00:04
|
could you say if VP8, VP9, AV1, WEBP2 have all adaptive quantization in intra or inter?
|
|
|
|
Deleted User
|
2021-06-23 06:00:09
|
<@!416586441058025472> <#805176455658733570>
|
|
|
|
fab
|
2021-06-23 06:00:16
|
is an inter thing or intra thing
|
|
2021-06-23 06:00:51
|
i want jyrki to view those messages so i write here
|
|
|
|
Cool Doggo
|
|
By the way, here's the same image as above, but selectively manually denoised with Topaz DeNoise AI and reencoded to a high quality JXL file (since the original JPG from Topaz is 14.8 MB, too big for Discord Free). Might be useful for further testing.
|
|
2021-06-23 06:01:12
|
heres a png so discord embeds 👍
|
|
|
|
lithium
|
2021-06-23 06:19:03
|
Thank you for your work 🙂
I still can see some tiny ringing on smooth gradient and sharp lines detail for anime(ligne claire) content,
(test on cjxl -d 0.5 ~ -d 1.45 -s 7)
this comment from Hacker News also mention this situation.
> https://discord.com/channels/794206087879852103/803645746661425173/856807773375692831
> https://news.ycombinator.com/item?id=27577328
|
|
|
|
Jyrki Alakuijala
|
|
fab
i want jyrki to view those messages so i write here
|
|
2021-06-23 06:31:57
|
My belief is that AVIF can do adaptive quantization into 8 different values in each 64x64 block, it just isn't done yet. None of my 'AVIF knowledge' is first hand.
|
|
|
fab
could you say if VP8, VP9, AV1, WEBP2 have all adaptive quantization in intra or inter?
|
|
2021-06-23 06:32:45
|
I don't know the internals of VP8, VP9, AV1 and WebP2.
|
|
|
|
raysar
|
|
Jyrki Alakuijala
I consider this a big improvement even if it may look subtle to an occasional viewer 😄
|
|
2021-06-23 09:07:24
|
I compile your last commit, cjxl.exe for windows, you are the best ! 😍
Ringing is dying ! <:PepeOK:805388754545934396>
https://1drv.ms/u/s!Aui4LBt66-MmkEzl9A-wgyOJAaxT?e=GWvbcs
|
|
|
|
Jyrki Alakuijala
|
2021-06-23 11:14:55
|
❤️ ❤️ ❤️
|
|
2021-06-23 11:15:38
|
Thank you for such encouragement!
|
|
|
ishitatsuyuki
|
2021-06-24 04:05:36
|
How do you use JXL frames as a analogue to PSD layers? In particular, I wonder if libjxl will expose the crop coordinates in an upcoming version
|
|
2021-06-24 04:05:55
|
In the current version the decoder just outputs merged layers if I understand it correctly
|
|
2021-06-24 04:08:32
|
lmao it just crashed when I feeded a psd into cjxl then djxl
|
|
2021-06-24 04:08:38
|
bug report incoming
|
|
2021-06-24 04:10:02
|
apparently that bug was already fixed in master nvm
|
|
2021-06-24 04:11:48
|
still unsure about the layers tho
|
|
|
|
_wb_
|
|
ishitatsuyuki
How do you use JXL frames as a analogue to PSD layers? In particular, I wonder if libjxl will expose the crop coordinates in an upcoming version
|
|
2021-06-24 05:27:50
|
Please open a github issue if you want that.
|
|
|
|
ishitatsuyuki
|
2021-06-24 05:28:30
|
will do it later, I still have some confusions that I want to clear up
|
|
|
|
_wb_
|
2021-06-24 05:29:17
|
In browsers we only need the merged frames, but I agree that it would be useful to have an api to get layers and crop coords
|
|
|
|
ishitatsuyuki
|
2021-06-24 05:30:21
|
my confusion was primarily that "what is the blend operator supposed to do?" but yeah that makes sense for browsers or image viewers
|
|
|
|
_wb_
|
2021-06-24 05:38:14
|
By outputting full-sized merged frames in the decoder api, we hope to make things easier for browsers/viewers who might otherwise get the blending wrong
|
|
2021-06-24 05:40:33
|
(It's quite nontrivial if you take into account color conversion and edge cases)
|
|
|
|
ishitatsuyuki
|
2021-06-24 06:59:46
|
https://github.com/libjxl/libjxl/issues/217
|
|
|
VEG
|
2021-06-24 08:09:36
|
Is it possible, in theory, to choose between lossy and lossless compression for different parts of the same image?
|
|
|
|
Crixis
|
|
|
_wb_
|
2021-06-24 10:33:56
|
yes, frames can be mixed
|
|
|
|
Jyrki Alakuijala
|
|
VEG
Is it possible, in theory, to choose between lossy and lossless compression for different parts of the same image?
|
|
2021-06-24 11:38:39
|
lossy VarDCT, lossy modular, lossy palettization, lossless palettization, lossy delta palettization, near lossless, true lossless, VarDCT with 256x256 dcts only, generative art can all be mixed and a single image can be composed from them -- all with or without using patches and splines
|
|
|
|
VEG
|
2021-06-24 11:39:07
|
Thanks for the info 🙂
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 11:39:44
|
choosing can be done using alpha maps or rgb blending maps which can be interpolated using better than lanczos quality algorithm
|
|
2021-06-24 11:40:38
|
I anticipate that machine learning methods can be used to find reasonable solutions
|
|
2021-06-24 11:41:00
|
it gets quickly bit too complicated to do by heuristics 😄
|
|
|
|
VEG
|
2021-06-24 11:44:53
|
Sounds great 🙂
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 12:33:49
|
there are many options for future -- not very different from AVIF which leaves a lot of options open
|
|
2021-06-24 12:34:06
|
however, actually using the options slows down decoding
|
|
2021-06-24 12:34:56
|
decoding speed on slow mobile phones seems to be more of an issue than the bandwidth savings
|
|
2021-06-24 12:35:26
|
I don't anticipate multi-layered super-creative encodings to start emerging anytime soon
|
|
|
|
fab
|
2021-06-24 12:37:28
|
ok, it's ok for me.
|
|
|
|
Deleted User
|
|
Jyrki Alakuijala
I anticipate that machine learning methods can be used to find reasonable solutions
|
|
2021-06-24 01:19:25
|
Something like the neural network they use in Opus? 😃
https://jmvalin.ca/opus/opus-1.3/
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 01:39:25
|
I don't know what they do, but probably it will be simpler for images 😛
|
|
2021-06-24 01:39:34
|
...
|
|
2021-06-24 01:39:46
|
I consider audio technology still an unsolved problem for humanity
|
|
2021-06-24 01:40:22
|
if I sit at my piano, the experience is just 100x better than with a digital piano or listening to recorded music, even when my plaing skills are pretty bad
|
|
2021-06-24 01:40:41
|
we are somehow destroying music in the recording and playback process
|
|
2021-06-24 01:40:52
|
taking the spirit and liveliness away
|
|
2021-06-24 01:41:31
|
(it can also be one of my friends sitting at the piano and it is still more interesting to listen :-D)
|
|
2021-06-24 01:42:38
|
also I can say that I tried to go to an extreme with hifi equipment, and it improved the situation, but didn't really solve it
|
|
2021-06-24 01:42:49
|
recorded music is like 80 % of the experience, somehow dullified
|
|
2021-06-24 01:44:17
|
a bit like there is a beautiful concert happening in the next room and you are listening to it when the sound is transported through the sewage pipes to your listening space 😛
|
|
2021-06-24 01:44:42
|
it seems to me that it should be a solvable problem given all wonders of modern technology
|
|
2021-06-24 01:45:25
|
it seems likely to me that they are using faulty quality metrics in that field which has stopped its development
|
|
2021-06-24 01:46:48
|
intermodulation and spatial coherence don't get enough attention I believe
|
|
|
|
improver
|
2021-06-24 02:18:43
|
how extreme you actually went with hifi
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 02:21:33
|
I bought used stuff but spent still more than $10000 on it
|
|
2021-06-24 02:22:13
|
I got the B&W N800s and monoblocks nearly heavier than I can lift (not a good idea)
|
|
2021-06-24 02:24:17
|
the monoblocks are called 'sovereign eternity' and they sound very relaxed but still precise, a weird combination
|
|
2021-06-24 02:25:21
|
ricardo.ch is a marvelous place to buy used luxury goods -- lots of rich people in Switzerland and they don't want to keep old stuff in their palace
|
|
2021-06-24 02:25:25
|
...
|
|
2021-06-24 02:25:38
|
I have good news about JPEG XL -- next ringing reduction is also effective
|
|
|
|
improver
|
2021-06-24 02:25:51
|
i assume you used good dac and quality mastered flacs too
|
|
2021-06-24 02:26:00
|
otherwise it sounds a bit pointless lol
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 02:26:17
|
I see about 5-10 % further reduction in ringing when I consider 16x8 vs. 8x16 more fairly and completely than in the current head
|
|
|
|
improver
|
2021-06-24 02:26:29
|
also yay for less ringing
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 02:26:44
|
I used a cd player ... it is a weird choise nowadays, but that's something I already had
|
|
|
|
improver
|
2021-06-24 02:27:16
|
CDs have max of 44100Hz and 16bit so not really that good tbh
|
|
2021-06-24 02:27:32
|
also it depends on what DAC is used
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 02:27:33
|
I doubt that I hear much above 13 kHz or so
|
|
|
|
fab
|
2021-06-24 02:27:37
|
youtube music on pc is free
|
|
2021-06-24 02:27:58
|
but you have to switch to youtube to watch av1 videos
|
|
|
|
improver
|
2021-06-24 02:28:19
|
it depends on mastering but 24bit flacs do give some more character sometimes
|
|
2021-06-24 02:29:26
|
I dont think going above 48kHz 24bit is worth it but CD quality aint holy grail especially with really good equipment
|
|
2021-06-24 02:30:39
|
also i was able to hear upto around 18kHz or so back when i tried. going more up than that was still audible but it didn't felt like it had any color
|
|
|
|
Deleted User
|
|
improver
CDs have max of 44100Hz and 16bit so not really that good tbh
|
|
2021-06-24 02:31:02
|
Actually Red Book is perfectly enough for high quality music distribution...
|
|
2021-06-24 02:31:05
|
https://web.archive.org/web/20200308054407/https://people.xiph.org/~xiphmont/demo/neil-young.html
|
|
2021-06-24 02:31:38
|
The first thing that should matter is the gear, then proper audio mastering
|
|
|
|
improver
|
2021-06-24 02:32:33
|
it's somewhat okay and I wouldn't go much higher than that but it CAN be improved upon
|
|
|
|
fab
|
2021-06-24 02:32:48
|
latin electro is the only good genre of music
|
|
2021-06-24 02:32:51
|
metal isn't music
|
|
|
|
improver
|
2021-06-24 02:33:12
|
I'd look more suspiciously into DACs used in audio players
|
|
|
|
fab
|
|
improver
I'd look more suspiciously into DACs used in audio players
|
|
2021-06-24 02:33:30
|
listen to latin electro
|
|
|
|
improver
|
2021-06-24 02:33:49
|
I listen to IDM mostly
|
|
2021-06-24 02:34:32
|
im dragging this into offtopic aint i lol
|
|
|
|
fab
|
|
|
Jyrki Alakuijala
|
2021-06-24 02:36:12
|
(I like the record company called telarc, how they master the music, also I like philips for classical music -- I'm not on expert on this)
|
|
|
|
spider-mario
|
|
improver
it depends on mastering but 24bit flacs do give some more character sometimes
|
|
2021-06-24 02:37:38
|
the only point of using more than 16 bits per sample is that you don’t need as much dither noise to eliminate distortion
|
|
2021-06-24 02:37:47
|
but even with 16 bits and without any noise shaping, it’s at -96 dBFS
|
|
|
|
improver
|
2021-06-24 02:39:06
|
that's assuming sine wave. we know that music is much more complex than that
|
|
|
|
spider-mario
|
2021-06-24 02:39:30
|
no, there is no need for this assumption
|
|
2021-06-24 02:39:55
|
wait, there was a nice video about this, let me find it again
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 02:41:35
|
on one of my perfectly fine sounding sibelius recording the record company did a volume readjust after 16 bit mastering, making some integer values being completely missing, effectively destroying one bit of precision ... and it still works very well
|
|
2021-06-24 02:41:52
|
the noise shaping is an option for cds, but it may not be that important?
|
|
|
|
spider-mario
|
2021-06-24 02:43:03
|
true, and noise shaping should be avoided if there is going to be any further processing and requantization
|
|
2021-06-24 02:43:24
|
simple triangular dither withstands that better
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 02:44:05
|
current head:
|
|
2021-06-24 02:44:33
|
after better 16x8/8x16 selection:
|
|
|
|
improver
|
2021-06-24 02:45:29
|
barely noticeable but some noise is eliminated
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 02:45:40
|
this is d3:epf0
|
|
2021-06-24 02:46:03
|
normally at d3 we would have some epf on
|
|
|
|
improver
|
2021-06-24 02:46:28
|
actually quite noticeable if you know what to look for
|
|
2021-06-24 02:50:27
|
i wanna electrostatic headphones
|
|
|
|
spider-mario
|
|
improver
that's assuming sine wave. we know that music is much more complex than that
|
|
2021-06-24 02:51:17
|
ah, here was the video: https://youtu.be/Rc_-eavKptY
|
|
2021-06-24 02:51:32
|
the demonstration with the subtraction is quite nice
|
|
2021-06-24 02:52:18
|
around 2:20
|
|
|
|
BlueSwordM
|
|
improver
i wanna electrostatic headphones
|
|
2021-06-24 02:53:26
|
Electrostatic headphones are absolutely mental.
|
|
|
|
improver
|
|
spider-mario
around 2:20
|
|
2021-06-24 02:54:39
|
i mean if you subtracted 16bit image and 8bit render of that you'd get the same kind of noise
|
|
|
|
spider-mario
|
2021-06-24 02:54:46
|
yes
|
|
2021-06-24 02:55:29
|
(if the 8-bit image is dithered)
|
|
|
|
improver
|
2021-06-24 02:56:30
|
even if it's not it'd still have differences. doesn't mean that 8bit image is the image and 16bit one is only additional noise
|
|
|
|
Deleted User
|
|
BlueSwordM
Electrostatic headphones are absolutely mental.
|
|
2021-06-24 02:56:57
|
I could only afford dynamic Sony WH-CH700N...
|
|
2021-06-24 02:57:13
|
You know, broke student
|
|
|
|
improver
|
2021-06-24 02:57:28
|
koss esp 950s are actually somewhat affordable
|
|
|
|
spider-mario
|
|
improver
even if it's not it'd still have differences. doesn't mean that 8bit image is the image and 16bit one is only additional noise
|
|
2021-06-24 02:57:43
|
right, if we don’t know which one is the original, technically it could be that the 16-bit image is the altered one
|
|
2021-06-24 02:58:09
|
but if you know that the 24-bit recording is the original, and that the only difference between it and a 16-bit dithered version is noise, then it seems quite clear that the 16-bit version is identical with noise added
|
|
|
|
Deleted User
|
|
improver
koss esp 950s are actually somewhat affordable
|
|
2021-06-24 02:58:29
|
Still way too much money for me
|
|
|
|
improver
|
2021-06-24 02:59:31
|
like I said it depends on mastering. if it's done whatever then yeah it's probably not worth 24 bits
|
|
|
|
spider-mario
|
2021-06-24 02:59:54
|
right, but so good mastering is more important than it being to 24 bits
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 02:59:58
|
I used audio dithering in the Senaatintorin Aani composition 😛
|
|
|
|
improver
|
2021-06-24 03:00:25
|
yes, absolutely true, good mastering is more important
|
|
|
|
spider-mario
|
2021-06-24 03:00:50
|
if the mastering is good, then 16 bits seems fine
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 03:00:52
|
I did the whole composition with doubles and the final version with error diffusion dither
|
|
|
|
spider-mario
|
2021-06-24 03:00:59
|
if it’s bad, then 24 bits won’t salvage it
|
|
2021-06-24 03:01:33
|
well, it will if it’s good at everything except using dither
|
|
|
|
improver
|
2021-06-24 03:01:36
|
correct. id say importance goes like this: speakers/headphones, mastering > DAC > encoding quality
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 03:02:02
|
I think power amplifiers are very important 🙂
|
|
|
|
improver
|
2021-06-24 03:02:33
|
that's more of part of speakers / headphones, as AMPs are different for all of them
|
|
|
|
Deleted User
|
|
improver
that's assuming sine wave. we know that music is much more complex than that
|
|
2021-06-24 03:02:38
|
Every sound/music is a combination of sine waves. And your ear cannot hear anything different than sine waves.
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 03:02:55
|
I'd put the amplifiers at the same level to speakers from my personal experience
|
|
|
|
improver
|
|
|
Jyrki Alakuijala
|
2021-06-24 03:03:07
|
amplifiers affect my listening fatique the most
|
|
|
|
improver
|
2021-06-24 03:04:04
|
I didn't include that as I assumed that's part of speaker/headphone setup. some headphones wont sound good at all with too weak amps, same for speakers
|
|
2021-06-24 03:04:22
|
then theres quality of them too
|
|
|
Every sound/music is a combination of sine waves. And your ear cannot hear anything different than sine waves.
|
|
2021-06-24 03:06:18
|
combination is the key word here. only combination is encoded, not how it was produced, so idk why I should trust upsamplers to do the right kind of shape
|
|
|
|
Deleted User
|
|
improver
combination is the key word here. only combination is encoded, not how it was produced, so idk why I should trust upsamplers to do the right kind of shape
|
|
2021-06-24 03:13:26
|
since there is only one bandlimited possibility.
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 03:15:25
|
Matt, there has been so many quality improvements that you might want to consider -q 92 --noise=1 already 😄
|
|
|
|
spider-mario
|
|
improver
combination is the key word here. only combination is encoded, not how it was produced, so idk why I should trust upsamplers to do the right kind of shape
|
|
2021-06-24 03:25:22
|
I think you might find this video interesting (from the author of the article that <@456226577798135808> linked to): https://youtu.be/cIQ9IXSUzuM
|
|
|
|
improver
|
2021-06-24 03:30:45
|
lol yes you certainly don't need 192kHz (haven't watched it but that part I agree with)
|
|
|
|
retr0id
|
2021-06-24 06:12:54
|
It would be fun to write a JIT for the modular predictor decision tree
|
|
|
|
improver
|
2021-06-24 06:18:44
|
or just compiler
|
|
2021-06-24 06:19:39
|
JIT is interpreter+compiler with estimator on whether it's worth it to compile, but usage is already predictable (1024x1024 max)
|
|
2021-06-24 06:20:35
|
so i guess if you chose to compile only for bigger tiles you could call it JIT...
|
|
|
|
retr0id
|
2021-06-24 06:20:49
|
Well, that's just semantics. I call it JIT whenever a program generates new executable pages, and jumps into them
|
|
|
|
_wb_
|
|
retr0id
It would be fun to write a JIT for the modular predictor decision tree
|
|
2021-06-24 06:26:05
|
Yes, could help a bit with speed. We haven't tried it yet because security-wise, JIT raises lots of eyebrows 😅
|
|
|
|
retr0id
|
2021-06-24 06:26:44
|
it does, but given the constrained nature of the format, it should be doable in a provably-secure way
|
|
|
|
_wb_
|
2021-06-24 06:26:51
|
Certainly
|
|
|
|
retr0id
|
2021-06-24 06:27:27
|
but yes, I'm not sure how happy the chromium people would be, with another JIT inside chromium 😂
|
|
|
|
_wb_
|
2021-06-24 06:28:30
|
It also probably doesn't help hugely if you just replace the branching with data dependencies
|
|
2021-06-24 06:29:36
|
Depending on the platform, I guess
|
|
|
|
Jyrki Alakuijala
|
|
retr0id
It would be fun to write a JIT for the modular predictor decision tree
|
|
2021-06-24 06:32:55
|
it might be more practical to figure out what kind of context trees that would be practical in image compression could still be modeled as a simple LUT or two instead of code
|
|
2021-06-24 06:33:08
|
that would allow a more simple (and likely faster) decoder time implementation
|
|
|
|
retr0id
|
2021-06-24 06:35:08
|
even if you had a predictor that, say, just looked at the upper and leftwards pixels, you'd need a 64k LUT, which is already bigger than L1 cache
|
|
2021-06-24 06:35:16
|
so I don't really see how a LUT would be practical
|
|
2021-06-24 06:35:38
|
you can do a lot of arithmetic in the time an L1 cache miss takes
|
|
2021-06-24 06:36:42
|
if there was a predictor that only looked at the previous row (i.e. never looks at the leftwards pixels on the current line), you could parallelise it with SIMD
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 06:37:00
|
it could be in the direction of LUTs on the log + one highest bit of top and left
|
|
2021-06-24 06:38:35
|
both sides can be complicated -- the decision tree and the decoder side implementation
|
|
|
|
_wb_
|
2021-06-24 06:38:56
|
We do use some fixed trees for -e 2 and -e 3
|
|
2021-06-24 06:39:19
|
Basically just one property with a LUT
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 06:39:24
|
there can be secondary LUTs, like one that goes from a few thousand integer values down to 64 or so, each denoting a possibility to have a separate entropy code
|
|
|
|
fab
|
2021-06-24 06:39:32
|
can an image like that look better in jxl at the same size
|
|
2021-06-24 06:39:33
|
https://discord.com/channels/794206087879852103/805007255061790730/857673344042926110
|
|
|
|
Jyrki Alakuijala
|
2021-06-24 06:39:34
|
we do that kind of things in brotli
|
|
|
|
fab
|
2021-06-24 06:39:38
|
jon answers is excellent
|
|
|
|
_wb_
|
|
retr0id
if there was a predictor that only looked at the previous row (i.e. never looks at the leftwards pixels on the current line), you could parallelise it with SIMD
|
|
2021-06-24 06:39:54
|
The predictor yes, but the entropy decode is the bottleneck
|
|
|
|
retr0id
|
2021-06-24 06:40:09
|
ah
|
|
2021-06-24 06:40:24
|
I've yet to look at the entropy coding stuff
|
|
|
|
_wb_
|
2021-06-24 06:40:59
|
Well it doesn't simdify, as you might expect :)
|
|
|
|
lithium
|
2021-06-24 07:29:39
|
A little curious, new vardct improve also can affect -d 0.5 and -d 1.0 quality?
I still can see some tiny ringing on those distance for anime content image,
(Those tiny ringing like white sugar spread on smooth gradient and sharp lines detail area,
not easy to notable, but feel little annoying.)
> Tuning ac strategy heuristics
> https://github.com/libjxl/libjxl/commit/45692670c6d414e8ec60eb2ed0ba2c4b948ca617
> Reversing the decision tree
> https://github.com/libjxl/libjxl/commit/32594679eddab5578922b0e20064a6a3dc2d3fde
|
|
|
|
_wb_
|
2021-06-24 07:41:02
|
It could, the different block selection heuristics are for all distance targets so it will do something different for all targets - if it's also better, I dunno
|
|