|
Jyrki Alakuijala
|
2021-07-04 11:32:26
|
(or almost once)
|
|
2021-07-04 11:33:13
|
I don't know what is done in JXL lossless, but we didn't think much of the encoding speed yet -- at least not to the level that I was thinking on in webp lossless
|
|
2021-07-04 11:33:58
|
also, I believe we could specialize some modes where the context tree has a very specific shape and use LUTs at decoding time to get closer to webp lossless decode speeds
|
|
2021-07-04 11:35:17
|
also, in webp lossless I wanted to create a replacement for PNG, so I wanted to 'win' PNG in more use cases
|
|
2021-07-04 11:35:29
|
that lead into decisions like pixel packing being implemented there
|
|
2021-07-04 11:36:00
|
it is a bit non-sensical compression method, but helps with very specific cases -- possibly with the coding speed of the image you show
|
|
2021-07-04 11:38:47
|
well, webp lossless is a good format and a good compressor ๐
|
|
2021-07-04 11:39:03
|
no shame to lose for it in 2 % of the cases
|
|
2021-07-04 11:39:15
|
webp lossless also loses to PNG in 2 % of the cases
|
|
2021-07-04 11:41:06
|
of course we should still take a look and improve
|
|
2021-07-04 11:41:34
|
and we shouldn't lose 4x, but perhaps 5-20 % in the worst case
|
|
2021-07-04 11:42:09
|
WebP2 tried to create a better webp lossless as its lossless option
|
|
2021-07-04 11:42:47
|
when I originally positioned the lossless coding in pik-based lossless, I didn't want to compete with it, but to be better in lossless photography compression
|
|
2021-07-04 11:43:07
|
webp lossless is not particularly good at photo compression, and there a 10 % win seemed very easy
|
|
2021-07-04 11:43:31
|
when we joined forces with Jon, then of course we had more options on going to lower densities
|
|
2021-07-04 11:44:15
|
FUIF had more expression in context modeling than what we had (but also caused a lower decoding speed)
|
|
2021-07-04 11:45:08
|
I don't want to give practical advise about it, I haven't tested that use case much
|
|
2021-07-04 11:45:32
|
I believe that delta palettization and d0.8 will be more practical than true lossless
|
|
2021-07-04 11:46:28
|
I of course like webp lossless -- if I didn't, I would have built something else
|
|
2021-07-04 11:47:21
|
the improvements that webp team made into webp2 were all solid as far as I could see -- (I proposed at least one of them giving about 1 % more -- fixing my old mistake in webp lossless)
|
|
2021-07-04 11:47:45
|
but webp2 lossless is not available and is only marginally better than webp lossless
|
|
2021-07-04 11:47:56
|
not worth a generation of new codecs, I believe
|
|
|
Scope
|
2021-07-04 11:53:58
|
Yes, WebP2 is almost consistently better than WebP where it shows good results, but by a noticeably smaller percentage than JXL overall, and as far as I understood in JXL if needed it is possible to do WebP "emulation" (with about the same speeds and results, maybe except for the infinite group sizes)
|
|
|
|
Jyrki Alakuijala
|
2021-07-04 11:57:55
|
WebP2 lossless has the same architecture as my original design for WebP lossless, just incremental improvements here and there
|
|
2021-07-04 11:58:07
|
JXL lossless is a full new design
|
|
2021-07-04 11:58:41
|
we can make decisions that are closer to those of WebP
|
|
2021-07-04 11:59:24
|
https://github.com/libjxl/libjxl/pull/276 has the latest quality improvement (for distance 16+++ --- SIGH)
|
|
2021-07-04 12:14:11
|
before:
|
|
2021-07-04 12:14:37
|
after:
|
|
2021-07-04 12:15:04
|
0.071 bpp, jxl:d32:epf3
|
|
2021-07-04 12:17:26
|
subtle stuff... one step at a time
|
|
|
Cool Doggo
|
2021-07-05 12:38:03
|
with -e 9 cjxl does better and faster for me
|
|
|
OkyDooky
|
2021-07-05 07:06:00
|
<@532010383041363969>\: with respect to ringing reduction... are you aware of https://ieeexplore.ieee.org/document/1006398 ? Basically, by making the quantization errors (in the DCT domain) correlated in a certain way, its spatial shape can be controlled.
|
|
|
raysar
|
2021-07-05 07:32:35
|
link to the paper: https://sci-hub.st/https://ieeexplore.ieee.org/document/1006398
|
|
|
|
Jyrki Alakuijala
|
|
<@532010383041363969>\: with respect to ringing reduction... are you aware of https://ieeexplore.ieee.org/document/1006398 ? Basically, by making the quantization errors (in the DCT domain) correlated in a certain way, its spatial shape can be controlled.
|
|
2021-07-05 08:25:18
|
I use some of my own quantization tricks that I learned from guetzli experiments but they are for keeping textures' characteristics, not antiringing
|
|
2021-07-05 08:26:17
|
I have avoided developing antiringing quantization tricks since I believe that it would require one more dct to be done for the analysis, and there have been computationally cheaper ways to improve
|
|
|
fab
|
2021-07-05 08:31:06
|
jpeg xl still do not get great gains for explicit content that aren't transcoded in jpeg q 90 or original png
|
|
2021-07-05 08:31:11
|
it can get only 30%
|
|
2021-07-05 08:31:19
|
with average only good rate control
|
|
2021-07-05 08:31:47
|
and it reduces 1,1 mb - 800 kb high resolution to 800 kb - 500 kb
|
|
2021-07-05 08:32:09
|
if the image is compressed is a big problem
|
|
2021-07-05 08:32:43
|
if the image is compressed but jpg at more that most cases it doesn't require deblocking or less orange saturation
|
|
2021-07-05 08:33:07
|
so no
|
|
2021-07-05 08:33:08
|
maybe you could use libjxl v0.3.7-171-gc12aec2 win_x64 2021.06.28
for %i in (C:\Users\User\Documents\deblocking5*.png) do cjxldeblocking -I 0.881 -s 1 -q 91.732 --gaborish=0 --use_new_heuristics %i %i.jxl
|
|
2021-07-05 08:33:10
|
needed
|
|
2021-07-05 08:33:35
|
those average images in webp are 44,9 kb and 99,8 kb and have great appeal
|
|
2021-07-05 08:33:49
|
but some are bloated to the 1,1 mb 800 kb
|
|
2021-07-05 08:34:07
|
but in jpeg if you keep the details they could weight more or be more blocked
|
|
2021-07-05 08:34:28
|
webp don't they seem with less colors but they are
|
|
2021-07-05 08:35:35
|
usually those images other than face, smile, body ex. there is grass, sand, car, sky and all sort of things that are hard to compress
|
|
2021-07-05 08:36:25
|
and the photo are send through whatsapp and photoshopped
|
|
2021-07-05 08:36:54
|
....W
|
|
2021-07-05 08:37:31
|
the AVIF codec doesn't recognize if a blocking or ringing is pleasant, it blurs the blue as in video codec frame to save space, is configured for that.
|
|
|
eclipseo
|
2021-07-05 10:15:18
|
Webp2 seems better than JXL on that specific image, more details are kept on the branch: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_07_01/index.html#fruits-oranges-jardin-japonais-2*3:1&JXL=s&WEBP2=s&subset1
|
|
|
Crixis
|
|
eclipseo
Webp2 seems better than JXL on that specific image, more details are kept on the branch: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_07_01/index.html#fruits-oranges-jardin-japonais-2*3:1&JXL=s&WEBP2=s&subset1
|
|
2021-07-05 10:25:11
|
seem the target bpp in this image are so low!
|
|
|
|
eclipseo
|
2021-07-05 10:28:17
|
try it with medium too
|
|
|
|
Crixis
|
2021-07-05 10:30:57
|
also medium, high, big are lower then 0.5 bppb
|
|
|
|
Jyrki Alakuijala
|
|
eclipseo
Webp2 seems better than JXL on that specific image, more details are kept on the branch: https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2021_07_01/index.html#fruits-oranges-jardin-japonais-2*3:1&JXL=s&WEBP2=s&subset1
|
|
2021-07-05 11:18:23
|
I agree. I am working on it ๐
|
|
2021-07-05 11:19:43
|
there is a huge difference between WebP/WebP2/AVIF/BPG and JXL in philosophy
|
|
2021-07-05 11:20:05
|
the video coding based codecs use prediction, JXL uses more context modeling
|
|
2021-07-05 11:20:26
|
prediction degrades into smoothness, context modeling degrades into artefacts
|
|
2021-07-05 11:21:06
|
prediction performs badly for complex stuff (becomes completely useless), context modeling remains somewhat useful (but increasingly less useful the more noise there is)
|
|
2021-07-05 11:21:48
|
because of this, some difference may remain in the 0.16 bpp range no matter how much I try to improve there -- but I'm still making progress
|
|
|
|
raysar
|
2021-07-05 11:41:39
|
Proposing by the encoder a file size resolution reduction for ultra low quality is the best visual solution for me. I need to test the butteraugly distance when i prefer the lower resolution. I'm not sure bpp is a good indicator when the are many blurr in image.
But i know, like the noise reduction, resolution is not an encoder tweek ๐
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 01:13:59
|
any ideas/opinions on us prioritizing our development work:
|
|
2021-07-05 01:14:12
|
1. encoder optimizations for high bpp
|
|
2021-07-05 01:14:17
|
2. encoder optimizations for mid bpp
|
|
2021-07-05 01:14:23
|
3. encoder optimizations for low bpp
|
|
2021-07-05 01:14:36
|
4. C++ code cleanliness
|
|
2021-07-05 01:14:51
|
5. production cleanliness (security issues in decoding)
|
|
2021-07-05 01:15:21
|
6. production cleanliness (make simd/non-simd/msan/without msan -- to produce exact same results)
|
|
2021-07-05 01:16:02
|
7. encoding speed for lossless (WebP lossless like strategies for lossless)
|
|
2021-07-05 01:16:09
|
8. encoding speed
|
|
2021-07-05 01:16:13
|
9. decoding speed
|
|
2021-07-05 01:16:17
|
10. decoding memory use
|
|
2021-07-05 01:16:26
|
11. Other
|
|
|
|
Crixis
|
2021-07-05 01:27:03
|
11. chrome and firefox stable defoult
|
|
|
|
raysar
|
|
Jyrki Alakuijala
11. Other
|
|
2021-07-05 01:28:18
|
Encoder always create a useless copy of the jpeg input in temp folder in windows. I think you need to find how to avoid it. The last discussion explain that it's libjpeg turbo doing that.
|
|
|
improver
|
2021-07-05 01:35:14
|
maybe mid bpp, security, but also decoder memory use may be important for evaluations (not really sure though)
|
|
|
|
paperboyo
|
|
Jyrki Alakuijala
3. encoder optimizations for low bpp
|
|
2021-07-05 01:35:27
|
I wouldnโt ever say anything else than no. 3. And then, number 3. Next in line would be pt. 3. For multiple reasons, but mostly because I think most of the success of the whole JXL proposition will hang on web use case. And most of web use case will hang off the low bpp comparisons with AVIF.
|
|
|
|
improver
|
2021-07-05 01:35:27
|
also decoding speed
|
|
2021-07-05 01:36:56
|
low-mid quality would be helpful, yes. high is probably already p good and improvements of low would mostly carry over to high too, no?
|
|
|
|
fab
|
2021-07-05 01:39:55
|
high quality screenshots are important
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 01:40:04
|
perhaps click a thumbs up at the respective line item to help with prioritization ๐
|
|
|
|
fab
|
|
|
improver
|
2021-07-05 01:40:09
|
but yes I'd want better firefox integration apparently it's not even doing alpha properly yet
|
|
2021-07-05 01:40:14
|
and animation
|
|
|
|
fab
|
2021-07-05 01:40:19
|
for example having many screenshots at that size
|
|
2021-07-05 01:40:25
|
even higher resolution
|
|
2021-07-05 01:40:41
|
also do not forget people use internet for expl images
|
|
|
|
Diamondragon
|
2021-07-05 01:41:11
|
My number one priority would be decoding speed. Number two would be decoding memory use reductions. Number three would be encoding speed improvements for lossless. Though I know that my priorities are not going to be other people's.
|
|
|
|
fab
|
2021-07-05 01:41:27
|
i see jxl don't use too much battery on multi core
|
|
2021-07-05 01:41:43
|
decoding speed is fast
|
|
|
Jyrki Alakuijala
11. Other
|
|
2021-07-05 01:42:18
|
improvement in lossless compression 42% isn't enough, while also having good speed, no more than 2 minute for a full hd image on a garbage cpu
|
|
|
|
Diamondragon
|
|
fab
decoding speed is fast
|
|
2021-07-05 01:43:03
|
It is in general, but it could always benefit from more speed (particularly for lossless decoding.)
|
|
|
|
fab
|
2021-07-05 01:43:29
|
i said for nsfw images what's the problem
|
|
2021-07-05 01:43:30
|
https://discord.com/channels/794206087879852103/794206170445119489/861524579255713802
|
|
2021-07-05 01:43:56
|
people won't just switch to a format if the photo in high resolution weight 500 kb
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 01:43:58
|
https://github.com/libjxl/libjxl/pull/276 was integrated an hour ago -- now possibility to enjoy low bpp (around less than 0.25 bpp) images with less ringing
|
|
|
|
raysar
|
|
Jyrki Alakuijala
11. Other
|
|
2021-07-05 01:43:59
|
Helping dev software (chrome/xnviewMP) to implement fast progressive decoding.
|
|
|
|
fab
|
|
Jyrki Alakuijala
https://github.com/libjxl/libjxl/pull/276 was integrated an hour ago -- now possibility to enjoy low bpp (around less than 0.25 bpp) images with less ringing
|
|
2021-07-05 01:45:16
|
i'd say an optional v0.3.7-171-gc12aec2 for deblocking when cjxl can read input as jxl
|
|
2021-07-05 01:45:28
|
it will bloat encoder size
|
|
2021-07-05 01:45:45
|
i'd like more integration in apps
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 01:46:22
|
Fabian, could you file the optional deblocking of input jpegs as an issue to github?
|
|
|
|
fab
|
2021-07-05 01:47:19
|
not now as there are lot of other priorities
|
|
2021-07-05 01:47:29
|
and cjxl can't read jxl
|
|
2021-07-05 01:47:34
|
so i don't know how you can do
|
|
2021-07-05 01:48:18
|
a for jpg
|
|
2021-07-05 01:48:28
|
jpg i think they can be read
|
|
2021-07-05 01:49:05
|
but is worth it to integrate an extra 3 mb only to destroy quality of jpeg
|
|
2021-07-05 01:49:14
|
in most cases cjxl does well without it
|
|
2021-07-05 01:49:25
|
as is tuned with jpg in mind
|
|
|
raysar
Helping dev software (chrome/xnviewMP) to implement fast progressive decoding.
|
|
2021-07-05 01:50:15
|
๐
|
|
|
eddie.zato
|
2021-07-05 01:50:26
|
Personally, I care about mid-bpp quality and decoding speed.
|
|
2021-07-05 01:50:33
|
I dunno how valuable the decoding speed tests are if it is done by decoding avif/jxl to png on ram-disk with avifdec/djxl tools. But some food for thought I did get. The current avifdec wins over djxl on art images and loses on photos.
|
|
|
|
fab
|
2021-07-05 01:51:12
|
personally i think q90 is enough on jxl, i don't see issues
|
|
|
monad
|
2021-07-05 01:51:14
|
I'm personally looking forward to any improvements in lossless encoding. If possible, a reduced-memory mode would be nice for encoding very large images. But I think JXL still needs to focus on web-quality lossy use-cases to win adoption, then others will follow.
|
|
|
|
fab
|
2021-07-05 01:53:29
|
personally an auto deblocking is needed if the input is mozjpeg as instagram images
|
|
2021-07-05 01:53:55
|
people often repost photo that have in their gallery
|
|
2021-07-05 01:53:58
|
folder instagram
|
|
2021-07-05 01:54:08
|
it can happen
|
|
2021-07-05 01:54:36
|
even if someone could prefer full quality
|
|
2021-07-05 01:54:41
|
if the input is jpeg
|
|
|
|
Scope
|
2021-07-05 01:54:48
|
Low bpp may be a good idea as so far this is the most noticeable weakness of JXL, which may also be the reason for the slow acceptance and demonstration advantages over other formats, also the decoding speed for lossy and lossless (most noticeable, especially since browsers are not enabled multithreading, which may be a problem for large images)
|
|
|
|
fab
|
2021-07-05 01:54:53
|
or could say is instagram that should do
|
|
2021-07-05 01:55:09
|
also instagram i think it converts all to png before convrrting to output
|
|
2021-07-05 01:55:15
|
it has a pipeline
|
|
2021-07-05 01:55:22
|
as most sites
|
|
2021-07-05 01:55:44
|
and jyrki/jon know what's better for the web
|
|
2021-07-05 01:55:57
|
probably every site will convert to png before encoding to jxl
|
|
|
Scope
Low bpp may be a good idea as so far this is the most noticeable weakness of JXL, which may also be the reason for the slow acceptance and demonstration advantages over other formats, also the decoding speed for lossy and lossless (most noticeable, especially since browsers are not enabled multithreading, which may be a problem for large images)
|
|
2021-07-05 01:56:41
|
no i have multithreading in firefox nightly
|
|
|
|
improver
|
|
fab
no i have multithreading in firefox nightly
|
|
2021-07-05 02:00:21
|
what being talked about is multithreading for image decoding (single image - multiple threads)
|
|
|
|
fab
|
2021-07-05 02:01:34
|
i'd say last step should be integrating in windows 11
|
|
2021-07-05 02:01:43
|
since windows 11 would be out in 2022
|
|
|
|
improver
|
2021-07-05 02:01:57
|
I doubt that's something what jxl devs can even do
|
|
|
|
fab
|
2021-07-05 02:02:58
|
so office integration, pdf integration, windows photos integration, wallpaper (No animated) integration
|
|
|
|
improver
|
2021-07-05 02:03:36
|
up to microsoft
|
|
2021-07-05 02:04:23
|
and pdf integration will probably be gatekeeped by standartization for quite a while too, yet to be seen whether there will be enough interest for that
|
|
|
|
fab
|
2021-07-05 02:04:34
|
then it should replace webp as firefox extension
|
|
2021-07-05 02:04:58
|
the firefox themes should be using jpeg xl instead
|
|
|
|
improver
|
2021-07-05 02:05:06
|
no they shouldn't
|
|
|
|
fab
|
|
improver
no they shouldn't
|
|
2021-07-05 02:05:36
|
if you want to install themes you should execute djxl
|
|
2021-07-05 02:05:46
|
new themes in firefox stores
|
|
|
|
improver
|
2021-07-05 02:05:50
|
that's not how it works
|
|
|
|
Scope
|
2021-07-05 02:06:21
|
FF may have multi-threading for a single image because it has a different implementation, but all Chromium-based browsers do not
But in general I think it would be better to prioritize Web usage and the most important needs for it, since this is the main initial push for widespread adoption of the format (all other applications only as most people request, like JXL WIC decoder)
|
|
|
|
monad
|
|
improver
and pdf integration will probably be gatekeeped by standartization for quite a while too, yet to be seen whether there will be enough interest for that
|
|
2021-07-05 02:08:48
|
Well, there was this: <https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c38>
|
|
|
|
eddie.zato
|
2021-07-05 02:09:59
|
The maintained WIC plugin will make a big deal of adoption on Windows.
|
|
|
|
fab
|
|
eddie.zato
The maintained WIC plugin will make a big deal of adoption on Windows.
|
|
2021-07-05 02:10:19
|
no official by microsoft only for windows 11
|
|
2021-07-05 02:10:28
|
it should be clear or people won't adopt
|
|
2021-07-05 02:11:09
|
people shouldn't know that veluca helped to the plugin
|
|
|
|
Jyrki Alakuijala
|
|
eddie.zato
The maintained WIC plugin will make a big deal of adoption on Windows.
|
|
2021-07-05 02:11:10
|
It certainly improved my experience with Chromebook when jxl was suddenly working at OS level :-]
|
|
|
|
improver
|
|
monad
Well, there was this: <https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c38>
|
|
2021-07-05 02:11:49
|
for photoshop it makes sense yeah but i wonder whether that will include pdf that soon
|
|
|
BlueSwordM
|
2021-07-05 02:12:11
|
To me, decoding speed optimizations, security optimizations, and native OS integrations should be the priority.
|
|
2021-07-05 02:12:43
|
I would still be surprised if A12 did not include JXL support into the OS. That would have been rad.
|
|
|
|
Scope
|
2021-07-05 02:15:00
|
Native OS integration rather depends on other companies than JXL developers, especially if take Windows and MacOS
|
|
|
|
raysar
|
|
fab
personally an auto deblocking is needed if the input is mozjpeg as instagram images
|
|
2021-07-05 02:15:35
|
Yes a good deblocking (maybe deringing?) filter for jpeg input source could be very cool for removing all horrible artifact from internet pictures.
Like this trainned neural network ๐ https://www.mathworks.com/help/images/jpeg-image-deblocking-using-deep-learning.html
<@!532010383041363969> This code is used in jxl? https://github.com/google/knusperli
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 02:16:37
|
no, knusperli is not used right now
|
|
2021-07-05 02:16:44
|
we had similar ideas earlier in pik
|
|
2021-07-05 02:17:29
|
we mostly removed all of them and the current JPEG XL is not benefitting from such thinking
|
|
|
|
improver
|
2021-07-05 02:17:46
|
knusperli is a bit biased tbh
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 02:18:07
|
I'm pondering about the possibility of productionizing knusperli (and few other improvements) and putting it into browsers, too
|
|
2021-07-05 02:18:47
|
the current opensourced knusperli only works in a rather narrow band of qualities (like 60-75)
|
|
2021-07-05 02:18:55
|
it would be possible to do better than that
|
|
|
|
fab
|
|
Jyrki Alakuijala
I'm pondering about the possibility of productionizing knusperli (and few other improvements) and putting it into browsers, too
|
|
2021-07-05 02:18:57
|
https://github.com/libjxl/libjxl/issues/279
|
|
|
|
Jyrki Alakuijala
|
|
|
fab
|
2021-07-05 02:19:11
|
just integrate libjxl v0.3.7-171-gc12aec2
|
|
2021-07-05 02:19:14
|
in browsers
|
|
2021-07-05 02:19:20
|
and make it optional
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 02:19:29
|
yes, that too
|
|
|
|
fab
|
2021-07-05 02:19:33
|
it slow decoding by half
|
|
2021-07-05 02:19:36
|
but is effective
|
|
2021-07-05 02:19:51
|
and 6 mpx/s a core is very fast
|
|
2021-07-05 02:19:54
|
is feasible
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 02:19:58
|
perhaps we find a way to take that part only, tune and tweak it and make it fast again
|
|
|
|
improver
|
2021-07-05 02:20:12
|
> for %i in (C:\Users\User\Documents\deblocking*.jpg) do cjxl -j -I 0.881 -s 1 -q 91.732 --gaborish=0 --use_new_heuristics %i %i.jxl
new heuristic pro
|
|
|
|
fab
|
|
Jyrki Alakuijala
perhaps we find a way to take that part only, tune and tweak it and make it fast again
|
|
2021-07-05 02:20:15
|
and i think jxl knows if a image is encoded in q90
|
|
2021-07-05 02:20:17
|
right?
|
|
2021-07-05 02:20:22
|
or is stupid
|
|
2021-07-05 02:20:35
|
does the decoder signal what qualities the input is encoded in?
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 02:21:00
|
it is possible to understand the quantization compromises from existing jpeg files
|
|
2021-07-05 02:21:09
|
by looking into quantization matrices
|
|
|
|
raysar
|
|
Jyrki Alakuijala
the current opensourced knusperli only works in a rather narrow band of qualities (like 60-75)
|
|
2021-07-05 02:23:20
|
Ah that's why it's not added, i suppose. what do think about the Image Deblocking Using Deep Learning that i link previously?
For now, is there a software doing good jpeg deblocking to use it before jxl encoding?
|
|
|
|
fab
|
2021-07-05 02:24:06
|
but i think these should require a 0.5.0 decoder
|
|
2021-07-05 02:24:17
|
so a new decoder to be shipped in chrome
|
|
2021-07-05 02:24:40
|
or it can be done without changing anything else
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 02:26:58
|
I like the idea of deblocking with deep learning
|
|
2021-07-05 02:27:18
|
I believe it can be much more effecive than humans inventing algorithms
|
|
2021-07-05 02:27:55
|
it can have weird things to happen, like if the original is 90/180 degrees rotated etc. the trees and bushes can "grow" to a wrong direction etc.
|
|
2021-07-05 02:28:29
|
productionizing a deep learning reconstruction is more complex than that for normal algorithms
|
|
2021-07-05 02:28:48
|
also, something like knusperli can be done on the fly in a streaming manner without much more computational needs
|
|
2021-07-05 02:28:58
|
i.e., can be integrated into a normal every-day-use decoder
|
|
|
|
BlueSwordM
|
2021-07-05 02:33:54
|
Honestly, with the AV1 and JXL standards, doing bruteforce deblocking is actually possible relatively computationally cheaply.
|
|
2021-07-05 02:34:51
|
What I've been doing to cheat banding and blocking artifacts is to use a dithering+debanding algo alongside noise/grain synthesis in scenes where blocking is more prominent due to low light/high compression ratios.
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 02:35:31
|
<@!321486891079696385> could you tell more about that with visual examples?
|
|
|
|
fab
|
2021-07-05 02:43:27
|
I guess that also creates a bigger jxl in your ROM
|
|
2021-07-05 02:43:33
|
so it slow down decoding also
|
|
|
|
BlueSwordM
|
|
Jyrki Alakuijala
<@!321486891079696385> could you tell more about that with visual examples?
|
|
2021-07-05 02:54:53
|
Some old examples I've finally found:
Extreme: https://slow.pics/c/040i13Jk
Sublte: https://slow.pics/c/S7HJbvyl
|
|
|
|
fab
|
2021-07-05 03:12:15
|
bloating file size by 6% isn't a problem
|
|
2021-07-05 03:12:22
|
why don't make it optional
|
|
2021-07-05 03:15:23
|
the problem is when the original is a jxl and then the image generates a heavier jxl
|
|
2021-07-05 03:36:03
|
at least someone making an extension for browser
|
|
2021-07-05 03:36:09
|
but it will be even slower
|
|
2021-07-05 03:36:15
|
so i hope for native support
|
|
|
|
Jyrki Alakuijala
|
|
BlueSwordM
Some old examples I've finally found:
Extreme: https://slow.pics/c/040i13Jk
Sublte: https://slow.pics/c/S7HJbvyl
|
|
2021-07-05 03:42:14
|
The extreme case is about hiding banding that was introduced by quantization in JXL's dc coding mostly
|
|
2021-07-05 03:42:40
|
The subtle case is hiding banding that originated from representing the final image in an 8-bit-per-channel framebuffer
|
|
2021-07-05 03:43:06
|
both work well -- the noise synth does what it is designed to do
|
|
2021-07-05 03:43:45
|
I like the noise synth of jxl very much, but I envy the flexibility of AVIF noise synth, but it almost seems too flexible and it makes me wonder if they will ever be able to make it work well because of that
|
|
2021-07-05 03:44:09
|
the examples I have seen so far haven't been exciting -- I would be interested seeing more if someone got the noisesynth in av1/avif working well
|
|
2021-07-05 03:44:55
|
in JXL I decided for a simple 'laplacian' style noise with a simple tweak (of having more midband noise energy than a simple laplacian)
|
|
|
|
fab
|
2021-07-05 03:45:15
|
so is a chance you will implement deblocking natively
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 03:45:17
|
in AV1 they have a full-blown grain synthesis system with configurable grain pattern sources
|
|
|
|
fab
|
2021-07-05 03:45:27
|
or we need a firefox extension
|
|
2021-07-05 03:45:29
|
or something
|
|
|
|
BlueSwordM
|
|
Jyrki Alakuijala
I like the noise synth of jxl very much, but I envy the flexibility of AVIF noise synth, but it almost seems too flexible and it makes me wonder if they will ever be able to make it work well because of that
|
|
2021-07-05 03:45:29
|
The main problem is that the AV1 spec authorizes lots of operations regarding grain synthesis, but all but one encoder tries to reproduce one important parameter: noise/grain **size**.
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 03:46:11
|
yes, the grain size in jxl is fixed
|
|
2021-07-05 03:46:34
|
but I believe in jxl we can modulate the amplitude based on intensity and likely in AV1 they cannot
|
|
2021-07-05 03:47:01
|
personally I dislike it much when white areas have as much noise as dark areas, it looks synthetic
|
|
2021-07-05 03:47:25
|
while having less noise in bright areas just looks more organic and authentic to me
|
|
2021-07-05 03:47:44
|
I don't know if anyone else sees it ๐
|
|
2021-07-05 03:48:06
|
but when noise is constant I immediately think of photoshop
|
|
2021-07-05 03:48:32
|
when the noise varies with intensity logically, I think of fragility, smoke, someone doing a photograph in a dark room, etc.
|
|
|
|
BlueSwordM
|
|
Jyrki Alakuijala
but I believe in jxl we can modulate the amplitude based on intensity and likely in AV1 they cannot
|
|
2021-07-05 03:49:15
|
In AV1, you can modulate noise intensity.
Otherwise, it wouldn't be called "grain synthesis" and it would be called "grain synthesis generation" ๐
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 03:49:30
|
oh, that's great news
|
|
2021-07-05 03:49:38
|
how do they do it?
|
|
|
|
BlueSwordM
|
|
Jyrki Alakuijala
how do they do it?
|
|
2021-07-05 03:49:56
|
Here's an excellent paper detailing how it is done:
https://norkin.org/pdf/DCC_2018_AV1_film_grain.pdf
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 03:53:02
|
"film grain strength ฯ with a piece-wise linear function for each of Y, Cb, and Cr color components"
|
|
2021-07-05 03:53:07
|
that's very very nice
|
|
2021-07-05 03:53:45
|
they just need to build an encoder that does a nice implementation of this (as do we for jxl, our current noise synth is broken at encoder side)
|
|
2021-07-05 03:54:59
|
I considered that an algorithmic noise synth would be better for gpu implementations
|
|
2021-07-05 03:55:15
|
gpu with large LUTs doesn't work very well
|
|
2021-07-05 03:55:51
|
my famous protographer friend uses 128x128 tile of film grain to blend with their digital photos
|
|
2021-07-05 03:56:28
|
he literally took a photo of a developed film to get his tile of film grain
|
|
2021-07-05 03:57:30
|
he was a software engineer before becoming a successful fashion photographer, stayed in that profession for 5 years, then converted back to engineering
|
|
|
|
paperboyo
|
|
Jyrki Alakuijala
personally I dislike it much when white areas have as much noise as dark areas, it looks synthetic
|
|
2021-07-05 04:16:11
|
> personally I dislike it much when white areas have as much noise as dark areas, it looks synthetic
Digital photography made it so, I think? Analog was either equally noisy or, coz negative scanning, had more noise in bright areas :-).
|
|
|
Jyrki Alakuijala
he literally took a photo of a developed film to get his tile of film grain
|
|
2021-07-05 04:17:42
|
Extracting and tiling specific grain is useful to match foreign elements in composites.
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 04:23:28
|
no, analog has normal noise from the shot noise process
|
|
2021-07-05 04:23:37
|
shot noise relates to sqrt(I)
|
|
2021-07-05 04:23:49
|
but that is in linear intensity
|
|
2021-07-05 04:24:04
|
gamma compression makes it flip the other way around, where there is less noise in high intensity
|
|
2021-07-05 04:24:28
|
this originates from the physics of photography (counting photons) and is the same for analog and digital
|
|
|
|
paperboyo
|
2021-07-05 04:36:53
|
Thanks for a correction, makes sense!
|
|
|
lithium
|
2021-07-05 04:46:13
|
Current jxl noise synth is broken at encoder side,
So current vardct mode is without grain synthesis features?
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 04:47:09
|
I believe there is 'grain' just that it is not guaranteed to have more noise in dark areas
|
|
|
|
fab
|
2021-07-05 04:47:43
|
No news about jpeg xl today
|
|
|
|
lithium
|
2021-07-05 04:50:07
|
I don't really understand grain synthesis features,
I only know include this features can let encoder keep image quality better(loyalty) .
|
|
2021-07-05 05:01:35
|
https://github.com/libjxl/libjxl/commit/f29f3d0a893d3d5badb48dbdcd480f21c6cea815
libjxl f29f3d0
cjxl -d 0.5 -s 7, 8, 9
> I do some quick test for my issue image,
> cjxl d0.5 s7 and s8 still have some tiny ringing on red and blue area,
> cjxl d0.5 s9 can reduce that tiny ringing,
> Looks like things are getting better, but I not sure use s9 is a good idea or bad idea.
|
|
|
|
Jyrki Alakuijala
|
|
lithium
https://github.com/libjxl/libjxl/commit/f29f3d0a893d3d5badb48dbdcd480f21c6cea815
libjxl f29f3d0
cjxl -d 0.5 -s 7, 8, 9
> I do some quick test for my issue image,
> cjxl d0.5 s7 and s8 still have some tiny ringing on red and blue area,
> cjxl d0.5 s9 can reduce that tiny ringing,
> Looks like things are getting better, but I not sure use s9 is a good idea or bad idea.
|
|
2021-07-05 06:35:59
|
I'm doing all the testing with s7 myself.
|
|
|
_wb_
|
2021-07-05 07:24:24
|
For semi-random patterned grain, we could consider modular cellular automata to produce it, alpha modulated. Could be very effective, just need to come up with good families of automata and methods to figure out how to choose which ones to apply.
|
|
|
|
raysar
|
|
Jyrki Alakuijala
I believe there is 'grain' just that it is not guaranteed to have more noise in dark areas
|
|
2021-07-05 08:26:04
|
You can not add for now a "--noise 2" to have more noise? the --noise 1 is homeopathic noise in picture, it's useless ๐
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 08:26:44
|
๐
|
|
2021-07-05 08:27:23
|
we didn't pay much attention to its encoding side in the last two years
|
|
|
spider-mario
|
2021-07-05 08:28:18
|
Iโm sort of looking into it
|
|
2021-07-05 08:29:08
|
not so much the derivation from the image, but something like Jyrki suggested the other day, along the lines of `--noise_equiv=ISO3200`
|
|
2021-07-05 08:29:58
|
which could assume a 35mm sensor by default or something like that
|
|
2021-07-05 08:30:42
|
not sure that I like reinforcing the popular idea that ISO is what โcreatesโ noise, but at least it seems like an interface that users could intuitively relate to
|
|
|
|
raysar
|
2021-07-05 08:37:00
|
For high compression, noise synthesis is a very good option for visual comparison against avif and win the battle :p
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 08:54:55
|
one level of comparison without noise, another with noise -- I think
|
|
2021-07-05 08:55:10
|
at highest fidelity I don't think people want much added noise
|
|
|
|
raysar
|
|
Jyrki Alakuijala
at highest fidelity I don't think people want much added noise
|
|
2021-07-05 10:25:48
|
jxl is also a denoiser at high compression. Restauring noise (or adding more) is good for visual comparison. and enable by default at higher than -d 3 for beating avif !
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 10:27:16
|
yes, enable by default would be great -- file an issue about it?
|
|
|
|
raysar
|
|
Jyrki Alakuijala
yes, enable by default would be great -- file an issue about it?
|
|
2021-07-05 10:49:57
|
Look at the homeopathic noise ! it's visually better but it's homeopathic ! (look at 200%)
https://slow.pics/c/5xksbh3r
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 10:51:34
|
yes, that is worth nothing and not functioning as designed
|
|
|
|
raysar
|
|
Jyrki Alakuijala
yes, that is worth nothing and not functioning as designed
|
|
2021-07-05 10:56:52
|
Do you think it's a lot of work to correct it?
|
|
|
|
Jyrki Alakuijala
|
2021-07-05 11:39:26
|
no
|
|
2021-07-05 11:39:41
|
the problem is to think how to make it so that it doesn't create surprises to users
|
|
2021-07-05 11:39:54
|
if it is image adaptive, there will be surprises
|
|
2021-07-05 11:40:17
|
if it is purely based on distance, also it can create surprises if fully glossy images become noisy
|
|
2021-07-05 11:41:24
|
I'm thinking it should be purely based on distance
|
|
|
|
eclipseo
|
|
Jyrki Alakuijala
he was a software engineer before becoming a successful fashion photographer, stayed in that profession for 5 years, then converted back to engineering
|
|
2021-07-06 06:12:09
|
M J Ranum?
|
|
|
Orum
|
2021-07-06 06:19:11
|
Is there any way to reduce cjxl's memory footprint?
|
|
2021-07-06 06:21:58
|
it's using >10GB of memory while the same image encoded with webp uses only a fraction of the memory for the same image (~1.5GB)
|
|
|
|
_wb_
|
2021-07-06 06:24:36
|
Faster speed settings use less memory
|
|
|
|
Orum
|
2021-07-06 06:25:10
|
Ah, I assume that's the only way?
|
|
|
|
_wb_
|
2021-07-06 06:27:43
|
Until we work on encoder memory footprint improvement... For now, mostly decoder memory has been prioritized
|
|
|
|
Orum
|
2021-07-06 06:31:54
|
Yeah, even at effort 3 it's still using ~10GB
|
|
|
|
raysar
|
|
Jyrki Alakuijala
I'm thinking it should be purely based on distance
|
|
2021-07-06 09:55:35
|
Uh, detecting the amond of noise in the original file is way smarter. A combination of distance and mesure.
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 10:09:06
|
our noise model is either on or off, detecting it from the image will be very surprising when there is a composition including flat graphics and a photo (for example screenshot compression)
|
|
|
Orum
Is there any way to reduce cjxl's memory footprint?
|
|
2021-07-06 10:11:01
|
it may be possible to get it to a constant, in theory tiles (with some margins) could be compressed separately
|
|
|
|
Orum
|
2021-07-06 10:12:43
|
That would be nice, but then you have the downsides of tiles. That said, it might be the only option in some cases, so it's better than nothing.
|
|
|
|
monad
|
2021-07-06 10:13:59
|
JXL uses tiles anyway.
|
|
|
|
raysar
|
|
Orum
Yeah, even at effort 3 it's still using ~10GB
|
|
2021-07-06 10:14:04
|
for my 24mpx file, i have around 6GB @-s9, 5.9GB @-s8, 1.6GB @-s7, 1GB @-s6, 1GB @-s5, 1GB @-s4, 1GB @-s3, 0.65GB @-s2, 0.8GB @-s1.
|
|
|
|
Orum
|
2021-07-06 10:15:22
|
this was ~75 mpixels
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 10:16:59
|
JXL VarDCT is always with 256x256 tiles, that is 510 (30x17) tiles for 8k
|
|
|
|
Orum
|
2021-07-06 10:17:34
|
ah, I was doing lossless, maybe that increased the memory usage too?
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 10:17:53
|
lossless didn't see much love in that regard
|
|
|
|
monad
|
2021-07-06 10:18:12
|
modular does use more memory in general
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 10:18:13
|
there are infinitely many possible compromises for lossless
|
|
|
|
Orum
|
2021-07-06 10:19:03
|
for this particular image, webp ended up making smaller files anyway (and was faster at doing so)
|
|
2021-07-06 10:19:21
|
the bigger concern is memory though, and webp used less than half of JXL even at its peak
|
|
|
|
monad
|
2021-07-06 10:20:45
|
Yeah, depending on content, WebP can perform much better than JXL.
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 10:20:50
|
WebP lossless is a good solution for many files ๐
|
|
2021-07-06 10:21:54
|
I developed WebP lossless against a transparent PNG benchmark
|
|
|
|
monad
|
2021-07-06 10:22:17
|
Unfortunately, I have some very large files that are too big for WebP and use too much memory with cjxl (I only have 8 GB RAM ...)
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 10:22:18
|
JXL lossless is developed a bit more against a photography benchmark or diverse benchmarks
|
|
|
|
Orum
|
2021-07-06 10:22:35
|
that makes sense
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 10:23:27
|
when I made decisions about WebP lossless I left 10 % density on the table for photography compression
|
|
2021-07-06 10:23:57
|
I just decided that it is not the primary use case and didn't complicate the format and slow down the worst case decoding speed
|
|
2021-07-06 10:24:27
|
expanding the predictors by one more pixel row would have given roughly 10 % more on photography compression
|
|
|
|
Orum
|
2021-07-06 10:24:49
|
well seeing as JXL can potentially replace raw formats, it seems more important that it has good lossless for photographic content
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 10:24:50
|
particularly so when the images are directly after debayering
|
|
2021-07-06 10:25:18
|
yes, that was exactly my thinking in focusing JXL lossless originally to that area
|
|
2021-07-06 10:25:39
|
(-: and luckily we were able to throw away all of that code and replace it with more flexible FUIF-based lossless ๐
|
|
|
|
raysar
|
|
Jyrki Alakuijala
particularly so when the images are directly after debayering
|
|
2021-07-06 10:33:14
|
Uh, lossless debayered picture is much bigger than "bayered" picture. varDCT @-d0.1 is the best solution.
|
|
|
|
fab
|
2021-07-06 10:38:37
|
honestly i would want photo to compress easily likely you do
|
|
2021-07-06 10:38:38
|
for %i in (C:\Users\User\Documents\oi2\*.png) do cjxl -q 85.167 --faster_decoding=4 -s 4 -p --epf=3 --use_new_heuristics %i %i.jxl
|
|
2021-07-06 10:38:41
|
and it compress
|
|
2021-07-06 10:38:47
|
and look good at every resolution
|
|
2021-07-06 10:39:22
|
like next encoder would be good if it worked easily
|
|
2021-07-06 10:40:05
|
the good about jpeg xl is that users shouldn't decide
|
|
|
|
Crixis
|
2021-07-06 10:40:15
|
why you want use -s 4 and --use_new_heuristics ?
|
|
|
|
fab
|
2021-07-06 10:40:40
|
i have libjxl v0.3.7-210-gdf9a355 win_x64 2021.07.06
|
|
2021-07-06 10:40:50
|
would want a similar improvement
|
|
|
|
Crixis
|
2021-07-06 10:41:05
|
what improvement?
|
|
|
|
raysar
|
2021-07-06 10:41:14
|
for my 64mpx file in varDCT, i have around 15.6GB @-s9, 15.7GB @-s8, 5GB @-s7, 2.4GB @-s6, 2.4GB @-s5, 2.4GB @-s4, 2.4GB @-s3, 2.5GB @-s2, 2.5GB @-s1.
|
|
|
|
fab
|
2021-07-06 10:41:31
|
that i digit this settings and photo look good at every resolution
|
|
|
|
Crixis
|
|
fab
that i digit this settings and photo look good at every resolution
|
|
2021-07-06 10:41:57
|
but why this specific setting?
|
|
|
|
fab
|
|
Crixis
but why this specific setting?
|
|
2021-07-06 10:42:37
|
the first i tried with this encoder was for %i in (C:\Users\User\Documents\oi\*.png) do cjxl -d 2.311 -s 7 -p --epf=2 --use_new_heuristics %i %i.jxl
|
|
2021-07-06 10:42:52
|
but the resolution don't look good
|
|
2021-07-06 10:43:08
|
to me a good heuristic is important
|
|
2021-07-06 10:43:12
|
i don't need better psnr
|
|
2021-07-06 10:43:26
|
because i need to encode expl images
|
|
2021-07-06 10:43:34
|
different resolutions fast speed is a need
|
|
2021-07-06 10:43:42
|
low ram usage
|
|
|
|
Crixis
|
2021-07-06 10:44:06
|
you have tried:
```
for %i in (C:\Users\User\Documents\oi2*.png) do cjxl -q 85.167 --epf=3 %i %i.jxl
```
|
|
2021-07-06 10:44:52
|
for fast speed
|
|
2021-07-06 10:44:58
|
try:
|
|
2021-07-06 10:45:28
|
```
for %i in (C:\Users\User\Documents\oi2*.png) do cjxl -q 85.167 -s 4 --epf=3 %i %i.jxl
```
|
|
2021-07-06 10:46:54
|
new heuristic is better on psnr but not visualy
|
|
|
|
fab
|
2021-07-06 10:47:03
|
i don't want visually
|
|
2021-07-06 10:47:10
|
like i don't need perfect geometry
|
|
2021-07-06 10:47:17
|
i'm not encoding faces
|
|
|
|
lithium
|
2021-07-06 10:47:37
|
I don't really understand noise and grain synthesis,
If I have already lossy DCT webp or jpeg image, I should use some denoise tool before jxl encode?
or direct use jxl encode?
which method is best practice for keep quality?
|
|
|
|
fab
|
2021-07-06 10:47:56
|
i care more about lossy expl images looking good at different resolution that's why i want that improvement in next build
|
|
|
|
Crixis
|
|
lithium
I don't really understand noise and grain synthesis,
If I have already lossy DCT webp or jpeg image, I should use some denoise tool before jxl encode?
or direct use jxl encode?
which method is best practice for keep quality?
|
|
2021-07-06 10:48:01
|
direct use
|
|
|
|
fab
|
2021-07-06 10:48:28
|
anyway i do copy paste
|
|
2021-07-06 10:48:32
|
i do not digit commands
|
|
|
|
Crixis
|
|
fab
i care more about lossy expl images looking good at different resolution that's why i want that improvement in next build
|
|
2021-07-06 10:48:39
|
they are not doing any improvement on new heuristic, is only a test
|
|
|
|
lithium
|
|
Crixis
direct use
|
|
2021-07-06 10:49:11
|
ok, I understand, thank you ๐
|
|
|
|
Crixis
|
|
fab
anyway i do copy paste
|
|
2021-07-06 10:50:16
|
you can try my command by copy paste
|
|
2021-07-06 10:50:49
|
all improvements are on standard heuristics
|
|
|
|
eddie.zato
|
2021-07-06 10:51:34
|
`%i.jxl` can be improved to `%~ni.jxl` ๐
|
|
|
|
fab
|
|
eddie.zato
`%i.jxl` can be improved to `%~ni.jxl` ๐
|
|
2021-07-06 11:11:36
|
hahahah
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 11:16:44
|
next improvement on ringing, example at d16
|
|
2021-07-06 11:16:50
|
before
|
|
2021-07-06 11:17:05
|
after
|
|
|
|
Crixis
|
2021-07-06 11:17:57
|
Uh I like this smooth gradient!
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 11:20:41
|
I wish there was a 'do what I mean' magic wand to use here ๐
|
|
2021-07-06 11:20:50
|
it would be so easy to get rid of all the artefacts ๐
|
|
2021-07-06 12:11:21
|
https://github.com/libjxl/libjxl/pull/282
|
|
2021-07-06 12:13:05
|
before:
|
|
2021-07-06 12:13:19
|
after:
|
|
2021-07-06 12:13:52
|
it is the same as always, better here, worse there -- hopefully more better than worse
|
|
2021-07-06 12:14:35
|
before:
|
|
2021-07-06 12:14:50
|
after:
|
|
2021-07-06 12:17:03
|
before:
|
|
2021-07-06 12:17:18
|
after:
|
|
2021-07-06 12:18:35
|
it feels a bit like mother asks to clean the room, and then you carry only one pair of dirty socks in the washing room and report back about success ๐ ... still lot of work to do ๐
|
|
2021-07-06 12:22:17
|
... but still, it looks and smells better without that pair of old socks ๐
|
|
|
|
eddie.zato
|
2021-07-06 12:23:28
|
Seems slightly better ๐
|
|
|
|
raysar
|
2021-07-06 12:28:16
|
for my 64mpx landscape in lossless Modular, i have around peak memory: 6.9GB @-s9, 5.1GB @-s8, 4.9GB @-s7, 4.5GB @-s6, 4.5GB @-s5, 2.6GB @-s4, 3.8GB @-s3, 3.8GB @-s2, 3.8GB @-s1.
Near all the encoding time at all speed i have only one thread working :/
|
|
|
|
fab
|
2021-07-06 12:49:34
|
3,8 gb is super good for good effort
|
|
2021-07-06 12:49:44
|
i think for s 1
|
|
2021-07-06 12:49:59
|
but you're doing lossless so is gonna use more memory
|
|
2021-07-06 01:43:36
|
recent version of jpeg xl look in this way when you have a jpg input
|
|
2021-07-06 01:43:50
|
they mantain quality and they distort less
|
|
2021-07-06 01:44:05
|
but an image that looks like this is considered fake
|
|
2021-07-06 01:44:58
|
sharp edges are necessary
|
|
2021-07-06 01:45:28
|
so you could convert your jpg to lower quality but that would be the result with jxl
|
|
2021-07-06 01:46:15
|
P.S. sorry for showing people without head protection
|
|
|
|
Crixis
|
2021-07-06 01:46:52
|
it is losless transcode?
|
|
2021-07-06 01:47:02
|
from jpg input?
|
|
|
|
fab
|
2021-07-06 01:47:25
|
no this is a new screenshot from youtube
|
|
2021-07-06 01:47:30
|
bitrate 1400-7000 kb
|
|
2021-07-06 01:47:35
|
new vp9 average bitrate
|
|
2021-07-06 01:47:41
|
i hate this fake jxl look
|
|
2021-07-06 01:48:09
|
is not suitable to this type of videoclip
|
|
2021-07-06 01:48:26
|
maybe for kpop looks amazing but not for this type of video
|
|
2021-07-06 01:49:10
|
i need sharper edges
|
|
2021-07-06 01:49:14
|
super sharp edges
|
|
|
|
Crixis
|
2021-07-06 01:49:14
|
what comand have you used?
|
|
|
|
fab
|
2021-07-06 01:49:22
|
no is original png
|
|
2021-07-06 01:49:26
|
no command, bitrate the one youtube is using now for vp9 1400-7000 kb
|
|
2021-07-06 01:49:54
|
max 10000 4k vp9
|
|
|
Crixis
what comand have you used?
|
|
2021-07-06 01:50:20
|
is just that i hate this fake jxl look
|
|
2021-07-06 01:50:30
|
don't look good for what i like to watch
|
|
|
|
Crixis
|
2021-07-06 01:50:46
|
what comand you used to get the fake look?
|
|
|
|
fab
|
2021-07-06 01:50:54
|
is original
|
|
2021-07-06 01:51:32
|
youtube use algorithms
|
|
2021-07-06 01:51:39
|
to limit the bitrate
|
|
2021-07-06 01:51:51
|
and it does trial
|
|
|
|
Crixis
|
2021-07-06 01:53:59
|
so is a effect of the youtube codec not a jxl effect
|
|
|
|
fab
|
|
Crixis
so is a effect of the youtube codec not a jxl effect
|
|
2021-07-06 02:03:34
|
this is the effect of tuning video codecs with butteraugli
|
|
2021-07-06 02:03:49
|
cleaner images but they don't transmit the illegality of the song
|
|
2021-07-06 02:04:02
|
graffiti, walls
|
|
2021-07-06 02:04:06
|
all poor represented
|
|
2021-07-06 02:05:10
|
do not publish the photo there is a logo of the channel
|
|
2021-07-06 02:09:22
|
jpeg xl i'll use when is more ready
|
|
|
|
Crixis
|
|
fab
this is the effect of tuning video codecs with butteraugli
|
|
2021-07-06 02:09:32
|
There isn't any video codec tuned with butteragli for now
|
|
|
|
fab
|
|
Crixis
There isn't any video codec tuned with butteragli for now
|
|
2021-07-06 02:10:21
|
i do not think a wall could be so soft in this type of videos
|
|
|
|
Crixis
|
|
fab
i do not think a wall could be so soft in this type of videos
|
|
2021-07-06 02:11:05
|
nether I but it don't have any link with jxl
|
|
|
|
fab
|
2021-07-06 02:11:13
|
ok
|
|
2021-07-06 02:11:43
|
so one person has to be careful when compressing but a encoder helps
|
|
|
|
Crixis
|
2021-07-06 02:13:14
|
the bigger point of jxl vs avif is that the image codec derivate from video codec smooth the image too much
|
|
|
|
fab
|
2021-07-06 02:17:38
|
picture quality looks clearer like jxl but the sharp edges are not present
|
|
2021-07-06 02:18:03
|
that is because youtube don't put much effort and vp9 is a bad codec
|
|
2021-07-06 02:18:12
|
also is run in hardware
|
|
2021-07-06 02:18:24
|
but do not think the situation can't be improved
|
|
|
|
Cool Doggo
|
2021-07-06 02:18:37
|
Vp9 isn't bad
|
|
|
|
fab
|
2021-07-06 02:18:42
|
if they want they can improve
|
|
|
|
Cool Doggo
|
2021-07-06 02:18:53
|
It depends on settings
|
|
|
|
fab
|
2021-07-06 02:18:57
|
but what i'm seeing is like a bad copy of jxl
|
|
2021-07-06 02:19:02
|
no sharp edges at all
|
|
2021-07-06 02:19:08
|
in this bitrate
|
|
|
|
Cool Doggo
|
2021-07-06 02:19:58
|
Yeah but the smoothing isn't like jxl
|
|
2021-07-06 02:20:09
|
It's like vp9, lol
|
|
|
|
fab
|
2021-07-06 02:20:40
|
that sure
|
|
2021-07-06 02:21:16
|
video codecs should do video codecs
|
|
|
|
Crixis
|
2021-07-06 02:34:53
|
smoothing is for sharp edges, no smoothing is for good texture
|
|
|
|
Jyrki Alakuijala
|
|
fab
sharp edges are necessary
|
|
2021-07-06 02:43:53
|
if I look at that image, I see a lot of sharp edges, but not much subtle textures -- perhaps I'm missing something on the interpretation
|
|
|
|
fab
|
2021-07-06 02:45:00
|
not the edges the countors
|
|
2021-07-06 02:46:01
|
it looks to blurred
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 03:51:06
|
I don't see it
|
|
2021-07-06 03:51:25
|
https://github.com/libjxl/libjxl/pull/282 is merged -- another round of less ringing
|
|
2021-07-06 03:52:25
|
I have at least three more ideas on how to reduce (better handling of large transforms, more aggressive smoothing, flatter quantization matrices), one of them will likely land this week
|
|
|
|
fab
|
2021-07-06 03:56:21
|
that's an old encoding for comparison in av1
|
|
2021-07-06 03:56:24
|
even if is av1
|
|
2021-07-06 03:56:28
|
edges looks smooth
|
|
|
diskorduser
|
2021-07-06 03:56:35
|
Do these improvements improve quality on d .5- 1?
|
|
|
|
fab
|
2021-07-06 03:57:09
|
like there is more contrast in the borders
|
|
2021-07-06 03:57:36
|
av1 used to have more of this artifact before jpeg xl existed
|
|
2021-07-06 03:58:37
|
This is higher bitrate 1621 kbps and also av1
|
|
2021-07-06 03:58:43
|
so is unfair comparison
|
|
2021-07-06 03:59:08
|
but vp9 could be better even if is hardware
|
|
2021-07-06 04:00:33
|
like the vp9 it just looks too clean
|
|
2021-07-06 04:00:39
|
av1 is good even if blurs
|
|
2021-07-06 04:00:56
|
the image convey to me
|
|
2021-07-06 04:01:08
|
they are diffent videos
|
|
2021-07-06 04:01:11
|
ok i'll stop
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 04:01:13
|
I liked vp9 better on contour sharpness, perhaps I didn't understand what is going on
|
|
|
|
fab
|
2021-07-06 04:01:44
|
the graffiti don't look like graffiti
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 04:01:46
|
it is very difficult to judge compression from a single image without knowing what the source looked like
|
|
|
|
fab
|
2021-07-06 04:01:50
|
wall don't look like wall
|
|
2021-07-06 04:02:08
|
av1 don't have this problem in a 2 year old video
|
|
2021-07-06 04:02:38
|
like sharper edges in this case would help
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 04:02:40
|
what bothers me is that vp9 looks like someone recently painted the road and the house (between the dirty areas)
|
|
2021-07-06 04:03:29
|
AV1 example I suspect that there was a problem in the source video
|
|
2021-07-06 04:03:44
|
it does look a bit blurry
|
|
2021-07-06 04:03:50
|
like 1.5x upsampled
|
|
|
|
fab
|
2021-07-06 04:05:10
|
graffiti should look sharp
|
|
2021-07-06 04:05:39
|
should convey the street criminality emotions that is present on original png
|
|
2021-07-06 04:05:59
|
blurring is good but not doing at this level
|
|
|
|
diskorduser
|
|
Jyrki Alakuijala
https://github.com/libjxl/libjxl/pull/282 is merged -- another round of less ringing
|
|
2021-07-06 04:35:10
|
I can see these improvements even in d 0.73. Great!
|
|
|
|
fab
|
2021-07-06 04:47:02
|
ok
|
|
2021-07-06 04:48:06
|
i want to make an app to sharpen/deblock with jxl
|
|
2021-07-06 04:48:13
|
i installed sharpdevelop how to do
|
|
2021-07-06 04:50:19
|
|
|
2021-07-06 05:02:36
|
can sharpdevelop add a font?
|
|
2021-07-06 05:04:02
|
|
|
2021-07-06 05:04:34
|
now i need to figure how to integrate browsing in a folder
|
|
2021-07-06 05:05:54
|
i though were 16:44 they are 19:05
|
|
2021-07-06 05:06:25
|
|
|
2021-07-06 05:20:56
|
please help me
|
|
2021-07-06 05:22:26
|
sharpdevelop is not loading anything
|
|
2021-07-06 05:22:32
|
and i zipped this file
|
|
2021-07-06 05:24:38
|
it doesn't seem to load i just clicked open solution .sln and opened the .sln file created 50 minutes ago
|
|
2021-07-06 05:24:56
|
i want this program now
|
|
|
|
Jyrki Alakuijala
|
|
diskorduser
I can see these improvements even in d 0.73. Great!
|
|
2021-07-06 05:39:48
|
Thank you!
|
|
|
fab
graffiti should look sharp
|
|
2021-07-06 06:02:58
|
I didn't see a graffiti on the VP9 image
|
|
|
|
fab
|
2021-07-06 06:03:12
|
neither i
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 06:10:17
|
so, where in the VP9 image contours are not sharp?
|
|
|
|
diskorduser
|
2021-07-06 06:18:35
|
I see those some numbers in code reduces artifacts. I hope fabian finds some magical numbers to reduce artifacts even more ๐น
|
|
|
|
fab
|
|
Jyrki Alakuijala
so, where in the VP9 image contours are not sharp?
|
|
2021-07-06 06:26:47
|
in that type of image the wall should look sharp like graffiti
|
|
2021-07-06 06:26:56
|
i deleted it
|
|
2021-07-06 06:27:07
|
anyway is a simple wall
|
|
2021-07-06 06:28:51
|
how to embed cjxl in a sharpdevelop project?
|
|
|
|
Jyrki Alakuijala
|
2021-07-06 08:04:41
|
what is sharpdevelop -- "SharpDevelop is a discontinued free and open source integrated development environment for the .NET Framework, Mono, Gtk# and Glade# platforms. It supports development in C#, Visual Basic .NET, Boo, F#, IronPython and IronRuby programming languages."
why worry about something that is discontinued? move on to the next thing?
|
|
|
diskorduser
I see those some numbers in code reduces artifacts. I hope fabian finds some magical numbers to reduce artifacts even more ๐น
|
|
2021-07-06 08:05:13
|
LOL
|
|
2021-07-06 08:05:39
|
that is why I feel so much sympathy with Fabian!!
|
|
|
|
lithium
|
2021-07-06 08:19:29
|
If you want develop a jxl gui,
Use visual studio or visual studio code, probably a better choose,
> C++: Qt5,
> C#: asp.net core,
> python: pyqt5 or wxPython,
> javascript: electron
|
|
|
|
fab
|
2021-07-07 05:09:08
|
i want to make my app compatible with windows 7
|
|
2021-07-07 05:09:22
|
so even framework 4.0 or 4.5 is good
|
|
|
lithium
If you want develop a jxl gui,
Use visual studio or visual studio code, probably a better choose,
> C++: Qt5,
> C#: asp.net core,
> python: pyqt5 or wxPython,
> javascript: electron
|
|
2021-07-07 05:12:01
|
so one of the two knows how to embed an exe in those program and call it
|
|
2021-07-07 05:12:20
|
i found yesterday three pakistan tutorials but they don't explain this
|
|
2021-07-07 05:12:25
|
maybe i searched wrong
|
|
2021-07-07 05:13:06
|
i'm developing in visual studio solution net framework 4.0
|
|
|
|
Jyrki Alakuijala
|
2021-07-07 11:04:14
|
I never tried .NET so far
|
|
2021-07-07 11:04:40
|
I'm too slow in learning for it
|
|
2021-07-07 11:05:00
|
if I learn something I want to have some probability of using it in 10 years
|
|
2021-07-07 11:05:41
|
I don't think a vendor specific environment can be as stable over time than a free and standardized environment
|
|
|
|
fab
|
2021-07-07 11:11:41
|
i think i just start to create a script for visual studio in cmd
|
|
2021-07-07 11:12:31
|
ziemek can use python so probably he knows or is very easy to him to make a similar program in visual studio i attempted something in development av1
|
|
2021-07-07 11:13:01
|
|
|
2021-07-07 11:13:31
|
please fix it for me i want to use label 1 as a text for browsefiledialog
|
|
2021-07-07 11:14:07
|
i want to make it only for windows then one person could translate to linux
|
|
2021-07-07 11:14:24
|
not a unique program translator or how is called
|
|
2021-07-07 11:14:32
|
just to start with a IDE
|
|
2021-07-07 11:38:22
|
..........
|
|
2021-07-07 11:38:24
|
i used for %i in (C:\Users\User\Documents\kki9*.png) do cjxl -s 6 -q 29.341 --faster_decoding=1 %i %i.jxl
|
|
2021-07-07 11:38:36
|
libjxl v0.3.7-214-g6e08452 win_x64 2021.07.07
|
|
2021-07-07 11:59:32
|
ok i don't see quality until
|
|