|
Demiurge
|
2023-02-26 12:55:04
|
Extreme "my baby!" vibes
|
|
2023-02-26 12:57:01
|
"AVIF is so amazing and great, no need for any other format lol, really please don't touch my baby"
|
|
2023-02-26 12:57:20
|
Like all he talks about is how great AVIF is
|
|
2023-02-26 12:57:48
|
No one was even talking about or thinking about AVIF or how this might affect AVIF before he brought it up
|
|
|
improver
|
2023-02-26 12:59:10
|
yeah honestly it's all way too political
|
|
|
|
Demiurge
|
2023-02-26 01:00:18
|
But it just seems extremely outrageous and completely shameless, for him to be the same guy responsible for forcing webp down all our throats and then right afterwards pull this shit?
|
|
2023-02-26 01:01:14
|
And nobody questions this when webp and avif are his precious childen?
|
|
2023-02-26 01:07:08
|
Maybe he's just reaching the age where he's worried about his legacy being forgotten
|
|
2023-02-26 01:07:24
|
Some kind of midlife crisis
|
|
2023-02-26 01:09:53
|
I dunno, I'll stop speculating since I'm going a little crazy here. It's just bonkers though, not having to explain to anyone what's going on and just unilaterally acting on a personal conflict of interest.
|
|
2023-02-26 01:11:30
|
This isn't the right place for me to vent, sorry guys. Cooler heads should always prevail.
|
|
|
gb82
|
2023-02-27 02:50:07
|
I think Jon's assessment was pretty spot-on, with Google wanting to appear like a "good AOM member" by unilaterally pushing AOM formats above all others
|
|
2023-02-27 02:51:22
|
The more I look into JPEG-XL, the more I believe it will take over for professional workflows as, imo, it is the best option. Given some camera manufacturers & maybe popular photographers endorse JXL, I could see it becoming a household name. AVIF has no hope in this field & is not a competitor
|
|
2023-02-27 02:52:52
|
I think the Chromium team doesn't understand that AVIF has, largely, *already succeeded*. The only holdout seems to be Microsoft Edge, & it is not likely to do much better or worse with/without competition in the form of JXL (which I don't think would compete. They have different use cases, & AVIF would still be very popular for low/medium quality web stuff & non-photographic stuff).
|
|
2023-02-27 02:57:26
|
I am personally a fan of AVIF, because it does what it is built for very well, that being low/medium quality compression for images with an emphasis on non-photographic images. I've found that many people enjoy that it smooths out fine detail & noise, as that is what smartphone processing has trained many to see as generally desirable anyway. JPEG-XL is strong when it comes to high-quality & lossless compression with an emphasis on photographic images, which AVIF *is clearly not designed for & is obviously not good at*. When it comes to that stuff, there's nothing wrong with using plain old JPEG right now & it actually looks pretty good. AVIF is simply not much better there, even compared to 4:2:0 JPEG, and JXL shines when it comes to these sources. Personally, my entire lossy photography collection is going to be in JXL because there is simply no better option. The Chromium team *needs* to understand this, and the fact that AVIF simply does not have certain features that JXL does & will never have these features.
|
|
|
OkyDooky
|
2023-02-27 03:59:35
|
Can you point to some examples of images that AVIF would be really good for?
|
|
|
|
gb82
|
2023-02-27 04:20:25
|
https://canary.discord.com/channels/794206087879852103/803645746661425173/1079175789565722684
|
|
2023-02-27 04:20:35
|
Can someone link the Matrix?
|
|
|
|
Demiurge
|
2023-02-27 04:20:57
|
Edge no longer supports JXL either, since they updated the chromium webengine with upstream changes
|
|
|
HLBG007
|
|
Demiurge
The Google codec team is frankly acting like shameless clowns, forcing the half-baked webp format through without addressing any criticism, while outside experts were practically begging them not to introduce a new format that wasn't a clear improvement. Now outside experts from a whole bunch of different companies are all begging Google to enable their excellent and mature JXL support by default and they respond by unilaterally deleting all of the code, with once again no discussion or addressing anyone's concerns. Simply telling us that "AVIF is faster than JXL" (lmao) and that there isn't enough room for both JXL and their own special baby to co-exist, or in other words they don't want their precious child to have to compete with JXL.
|
|
2023-02-27 10:39:53
|
Take an image and compress it with jxl at quality 0 now take the same image and compress it with avif so that it has the same file size as the jxl image created with q 0. It does not matter which image you take. The quality with avif looks better. the fact that jxl looks good at high bitrates does not count as an argument. a lossy compression has the goal that even at the smallest file size the image should still look good. this goal has jxl missed.
|
|
|
|
Demiurge
|
2023-02-27 10:41:58
|
By "better" you mean, both images would still look so poor as to be unusable and worthless
|
|
2023-02-27 10:42:57
|
So it would serve no practical purpose to compare the two.
|
|
2023-02-27 10:46:10
|
Instead, you would compare them at bitrates that people actually use, where you can actually tell what it is you're looking at and it doesn't look like an abstract smear
|
|
|
|
HLBG007
|
|
Demiurge
So it would serve no practical purpose to compare the two.
|
|
2023-02-27 11:30:15
|
Better in unusable but not more unusable than the other image format. there should be more details recognizable.
|
|
|
Demiurge
Instead, you would compare them at bitrates that people actually use, where you can actually tell what it is you're looking at and it doesn't look like an abstract smear
|
|
2023-02-27 11:34:37
|
|
|
|
_wb_
|
2023-02-27 11:42:23
|
that looks like the kind of image that would benefit from reducing palette and using lossless compression
|
|
2023-02-27 11:44:23
|
but I don't really care about quality 0 โ I think the lowest anyone wants to use in practice is quality 50
|
|
|
|
HLBG007
|
|
_wb_
but I don't really care about quality 0 โ I think the lowest anyone wants to use in practice is quality 50
|
|
2023-02-27 02:26:35
|
quality 0 jxl => quality 100/63*15=24% avif at the same filesize
|
|
|
Jyrki Alakuijala
|
|
HLBG007
How did you manage to convince Apple and Microsoft with Brotli? https://caniuse.com/?search=brotli Why did you not succeed with jpegxl? https://caniuse.com/?search=jpegxl
|
|
2023-02-27 04:10:02
|
It took ~5 years with Brotli, I believe with JPEG XL we will be faster. Some big companies will use it first outside of the web delivery, it will propagate to creative tools, then to operating systems and finally web browsers -- I think 2-3 years and it will be supported by web browsers.
|
|
|
HLBG007
I am missing measurements how much watt is needed when encoding and decoding jpegxl/avif/mozjpeg.
|
|
2023-02-27 04:12:17
|
Joule is the unit of energy. Usually they all need about 1-10 mJ including transfer and decoding.
|
|
|
|
HLBG007
|
|
Jyrki Alakuijala
Joule is the unit of energy. Usually they all need about 1-10 mJ including transfer and decoding.
|
|
2023-02-27 04:45:59
|
A comparison diagram in mJ between jxl vs. avif would be good
|
|
|
|
Jyrki Alakuijala
|
2023-02-27 05:52:45
|
it is roughly transfer time + decoding time
|
|
2023-02-27 05:52:57
|
radio takes 500 mW, cpu takes 500 mW
|
|
2023-02-27 05:53:28
|
transfer 15 ms, decoding 5 ms
|
|
2023-02-27 05:53:51
|
0.015*0.5 + 0.005*0.5 = 0.01 J
|
|
2023-02-27 05:54:25
|
if you need higher quality, you need to transfer a lot more bytes in AVIF -> more mJ
|
|
2023-02-27 05:54:42
|
if you need lower quality, you need to transfer a lot less bytes in AVIF -> less mJ
|
|
2023-02-27 05:56:08
|
but in general a 150 kpixel image would be about 10 mJ, something like 66 nJ per pixel
|
|
|
|
HLBG007
|
2023-02-27 06:36:02
|
II found out that with quality 0 effort 8 and 9 puts the ssimulacra2 value to half in effort<7 or in the minus. already at effort 7 the encoding time increases from 200 ms to >2000ms
|
|
|
|
Jyrki Alakuijala
|
2023-02-27 06:48:24
|
why limit to quality 0, you can get much worse quality than that
|
|
2023-02-27 06:48:56
|
you can use something like --distance 128
|
|
2023-02-27 06:49:11
|
it works through benchmark_xl at least if normal UI doesn't allow it
|
|
2023-02-27 06:50:49
|
originally we didn't have a quality mapping at all, only distance -- quality mapping is an after thought, ideally one would use the distance value [0..Inf]
|
|
2023-02-27 06:52:42
|
I wouldn't use squoosh to do quality debugging -- it is slightly further away from the cjxl and benchmark_xl
|
|
2023-02-27 06:53:03
|
just use cjxl
|
|
|
|
HLBG007
|
|
Jyrki Alakuijala
just use cjxl
|
|
2023-02-27 07:11:42
|
yes i use the compiled version of avif / jxl from git yesterday. I do not understanding why jxl have no feature like avif. more encoding time but better ssimulacra2 value
|
|
|
Jyrki Alakuijala
I wouldn't use squoosh to do quality debugging -- it is slightly further away from the cjxl and benchmark_xl
|
|
2023-02-27 07:21:47
|
my version of squoosh is up to date. but it generates in lossless encoding double filesize
|
|
|
Traneptora
|
|
HLBG007
Take an image and compress it with jxl at quality 0 now take the same image and compress it with avif so that it has the same file size as the jxl image created with q 0. It does not matter which image you take. The quality with avif looks better. the fact that jxl looks good at high bitrates does not count as an argument. a lossy compression has the goal that even at the smallest file size the image should still look good. this goal has jxl missed.
|
|
2023-02-27 07:56:12
|
> a lossy compression has the goal that even at the smallest file size the image should still look good
this is not actually the goal of JXL and never was the goal of JXL
|
|
|
|
HLBG007
|
|
Traneptora
> a lossy compression has the goal that even at the smallest file size the image should still look good
this is not actually the goal of JXL and never was the goal of JXL
|
|
2023-02-27 08:02:40
|
what then is the goal of jxl?
|
|
|
|
Traneptora
|
2023-02-27 08:06:34
|
JXL's lossy compression side is designed for primarily photographic images at high fidelity
|
|
2023-02-27 08:06:45
|
that's what it is best at and what it is designed for
|
|
2023-02-27 08:07:01
|
it was never supposed to produce the smallest files at absurdly low qualities
|
|
2023-02-27 08:09:40
|
you'd never want to use a smudge like this on an actual website or an actual workflow, for example
|
|
2023-02-27 08:10:54
|
the fact that AVIF can encode that smudge with fewer bits doesn't particularly matter
|
|
|
|
HLBG007
|
2023-02-27 08:16:23
|
An image format that wants to gain acceptance in web browsers must be able to compress any quality well.
|
|
|
|
Traneptora
|
2023-02-27 08:16:51
|
no it doesn't
|
|
2023-02-27 08:17:05
|
and it's not like this image isn't small, it's 1.5k
|
|
2023-02-27 08:17:10
|
the original PNG was 463k
|
|
2023-02-27 08:17:43
|
qualities this low simply are not useful for anyone for any purpose
|
|
|
yoochan
|
2023-02-27 08:21:36
|
I agree with <@853026420792360980> according to this : https://www.spiedigitallibrary.org/conference-proceedings-of-spie/11137/111370K/JPEG-XL-next-generation-image-compression-architecture-and-coding-tools/10.1117/12.2529237.full?SSO=1 (Figure 1.) Images found online are not of any quality but more on slightly less than 1bbp for large images and around 2bpp for small ones
|
|
2023-02-27 08:22:00
|
quote : "With these considerations in mind, JPEG XL is designed to handle high-quality images particularly well. Its aim is serving the current and future needs of an increasingly rich media experience. Ideally, an image should be compressed up to a point where there is no perceptible loss of quality from the original."
|
|
|
|
HLBG007
|
2023-02-27 09:05:51
|
in benchmarks i posting a bench
|
|
|
|
_wb_
|
|
HLBG007
An image format that wants to gain acceptance in web browsers must be able to compress any quality well.
|
|
2023-02-27 09:05:54
|
All web browsers support PNG, GIF and BMP.
|
|
|
|
improver
|
2023-02-27 09:09:00
|
> An image format that wants to gain acceptance in web browsers must be able to compress any quality well.
why? even levels that people don't normally compress stuff at? why?
|
|
2023-02-27 09:09:34
|
this kind of stubbornness is mystifying
|
|
|
|
_wb_
|
2023-02-27 09:14:15
|
WebP has quite a bit gap between q100 lossy (which is still tv range 4:2:0 so not very high quality) and lossless.
|
|
|
|
HLBG007
|
2023-02-27 09:23:56
|
if jxl compression does not go to quality 0 then everything below 0% (until not supported %) should be removed. So that there is no more misunderstanding and so that no one is tempted to use something at quality setting that is never supported.
|
|
|
|
Demiurge
|
|
HLBG007
An image format that wants to gain acceptance in web browsers must be able to compress any quality well.
|
|
2023-02-27 09:26:54
|
Technically it only needs to compress well at qualities that are actually realistically going to be used in practice. It does not need to be good at producing useless smudges.
|
|
|
HLBG007
if jxl compression does not go to quality 0 then everything below 0% (until not supported %) should be removed. So that there is no more misunderstanding and so that no one is tempted to use something at quality setting that is never supported.
|
|
2023-02-27 09:27:38
|
This is pretty reasonable though.
|
|
2023-02-27 09:28:21
|
If the encoder is not optimized or intended for bitrates below a certain level, then disable it by default and maybe have it behind an experimental setting.
|
|
2023-02-27 09:28:35
|
Until it gets better tuned
|
|
|
|
Traneptora
|
2023-02-27 09:28:42
|
they are disabled by default in cjxl, I produced the above image with d128 using benchmark_xl
|
|
2023-02-27 09:28:47
|
you can't go above 15 in cjxl iirc
|
|
2023-02-27 09:28:51
|
mighta been 25
|
|
|
|
Demiurge
|
2023-02-27 09:29:36
|
Well I heard people say not to bother using jxl beyond d > 3
|
|
2023-02-27 09:30:20
|
Also, something to consider: compressing input images that are already extremely blurry and blown up to begin with.
|
|
2023-02-27 09:30:31
|
Like extremely high resolution, blurry, oversampled images
|
|
|
|
Traneptora
|
2023-02-27 09:30:44
|
very blurry images compress well by default though as they tend to have smooth gradients
|
|
2023-02-27 09:30:56
|
so I'm not sure what special considerations would need to be made in that case
|
|
|
|
Demiurge
|
2023-02-27 09:31:30
|
In situations where an input image contains only extremely-low-frequency signals, it can be acceptable to use extreme lossy compression
|
|
|
|
Traneptora
|
2023-02-27 09:31:42
|
but yes the UI could be updated so distances greater than, say, 5, require an extra --high-distance option or something of that form
|
|
2023-02-27 09:31:59
|
kinda like how the zstd frontend locks 20-22 behind --ultra
|
|
|
|
Demiurge
|
|
Traneptora
but yes the UI could be updated so distances greater than, say, 5, require an extra --high-distance option or something of that form
|
|
2023-02-27 09:32:16
|
how about the newly introduced experimental unlock flag?
|
|
|
|
Traneptora
|
|
Demiurge
In situations where an input image contains only extremely-low-frequency signals, it can be acceptable to use extreme lossy compression
|
|
2023-02-27 09:32:38
|
well tbf in that circumstance low distances will still provide a very solid ratio
|
|
2023-02-27 09:33:17
|
so I wouldn't say you'd be better using a high distance in that sense simply because the low distances will compress much more effectively anyway
|
|
2023-02-27 09:34:02
|
but that particular type of image is still worth optimizing the encoder for, as cameras with high resolution but bad optics (like many phone cameras, for example) could benefit from that sort of encoder optimization
|
|
|
|
Demiurge
|
2023-02-27 09:34:15
|
Yes
|
|
2023-02-27 09:34:42
|
And currently the encoder does not handle that situation as well as it potentially could, and it is a very common situation with cameras that produce large blurry images
|
|
|
|
Traneptora
|
2023-02-27 09:35:14
|
yea, it's definitely got room for improvement
|
|
|
|
Demiurge
|
2023-02-27 09:35:39
|
some of these things would be best solved in hardware in collaboration with camera manufacturers.
|
|
2023-02-27 09:36:33
|
Also high-frequency grain mixed into low-frequency blurred image data
|
|
2023-02-27 09:36:53
|
That tends to look weird after JXL encoding
|
|
|
|
gb82
|
2023-02-27 09:37:22
|
Are there talks with camera manufacturers taking place currently?
|
|
|
|
Demiurge
|
2023-02-27 09:37:30
|
none of these are issues with the format itself of course, just the state of the libjxl encoder
|
|
2023-02-27 09:38:49
|
Don't know... but it would be awesome if android and ios could use it to losslessly crush existing jpeg in the camera roll.
|
|
2023-02-27 09:39:20
|
and hopefully use it as the native picture taking format for their camera apps
|
|
|
|
gb82
|
|
Demiurge
Don't know... but it would be awesome if android and ios could use it to losslessly crush existing jpeg in the camera roll.
|
|
2023-02-27 09:39:24
|
this would be a killer feature
|
|
|
|
Demiurge
|
2023-02-27 09:39:48
|
a lot of phones have a lot of old pictures on them that were taken in JPEG and not HEIC
|
|
|
|
afed
|
2023-02-27 09:39:49
|
quality limits are very specific to the images, there is no static quality value for any existing image and sometime it may need much lower values, there are only some recommendations for photographic images
basically for newbies and who don't understand what they want, the default setting when nothing needs to be changed is pretty much enough
like -d 1 and the default speed is a very balanced option
|
|
|
|
Demiurge
|
2023-02-27 09:41:13
|
yes, -d 1 -e 7 is very balanced. also has anyone ever mentioned that the way that cjxl/djxl parse commandline arguments is very annoying?
|
|
2023-02-27 09:42:06
|
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
|
|
2023-02-27 09:42:41
|
It would be nice if they followed a more conventional style of utility option parsing
|
|
2023-02-27 09:43:06
|
There are many argument-parsing libraries to assist with the task
|
|
|
|
HLBG007
|
2023-02-27 09:44:07
|
Does jxl include everything to replace dng format? https://en.wikipedia.org/wiki/Digital_Negative
|
|
|
|
Demiurge
|
2023-02-27 09:44:35
|
jxl is not a raw format
|
|
2023-02-27 09:45:30
|
as far as I know, it does not have any transforms to efficiently store color mosaic sensor information
|
|
|
|
HLBG007
|
|
Demiurge
as far as I know, it does not have any transforms to efficiently store color mosaic sensor information
|
|
2023-02-27 09:48:24
|
๐
|
|
2023-02-27 09:50:21
|
has anyone used the Camera2 API to develop an app that saves captured images directly to JPEGXL?
|
|
|
|
Demiurge
|
2023-02-27 09:53:32
|
I'm pretty sure someone somehow owns the patent to the "idea" of compressing a raw file
|
|
|
novomesk
|
|
HLBG007
has anyone used the Camera2 API to develop an app that saves captured images directly to JPEGXL?
|
|
2023-02-27 10:38:32
|
We want to have it in this app:
https://github.com/ParticlesDevs/PhotonCamera
Do you want to help with development?
|
|
|
sklwmp
|
|
Demiurge
I'm pretty sure someone somehow owns the patent to the "idea" of compressing a raw file
|
|
2023-02-28 12:51:36
|
That would be RED. (https://youtu.be/WeM2D1-yTzo)
|
|
|
|
Demiurge
|
2023-02-28 01:39:22
|
Yeah lol. Patents are mental illness
|
|
|
diskorduser
|
2023-02-28 01:55:00
|
Android 8
|
|
|
|
novomesk
|
2023-02-28 01:06:04
|
This app is not ready yet. Try it only if you wish to help with development. It may support more cameras than those listed there.
|
|
|
|
Traneptora
|
|
Demiurge
a lot of phones have a lot of old pictures on them that were taken in JPEG and not HEIC
|
|
2023-02-28 04:20:27
|
android phones still take JPEGs and android is almost 80% of the market too
|
|
|
|
novomesk
|
|
Traneptora
android phones still take JPEGs and android is almost 80% of the market too
|
|
2023-02-28 04:29:26
|
We have Samsung Galaxy A33 with Android 13 and it can take photos in HEIC directly when one switch in camera app is turned on.
|
|
|
|
Traneptora
|
2023-02-28 04:31:34
|
huh, must be a new feature
|
|
2023-02-28 04:31:42
|
my Samsung phone from ~2 years ago still takes JPEGs
|
|
|
Demez
|
2023-02-28 04:32:03
|
my Samsung can take heic as well, its a galaxy a50
|
|
2023-02-28 04:32:23
|
and its on android 11
|
|
|
|
Traneptora
|
2023-02-28 04:32:23
|
interesting, I have an A51, didn't know it could take HEICs. It always takes jpegs
|
|
|
|
Demez
|
2023-02-28 04:32:43
|
have you ever looked in the settings for it?
|
|
|
|
Traneptora
|
2023-02-28 04:32:59
|
I have but I must have missed that
|
|
2023-02-28 04:33:04
|
not that I want it to take HEIC photos, tbh.
|
|
2023-02-28 04:33:18
|
you can't do much with them
|
|
|
w
|
2023-02-28 04:33:30
|
they added it in android 10, so 2019+. my s10e had it then
|
|
|
|
Demez
|
2023-02-28 04:33:51
|
I have it on to save space
|
|
|
username
|
2023-02-28 04:34:30
|
aren't they also higher quality?
|
|
|
|
w
|
2023-02-28 04:34:44
|
the hardware spits out the jpeg so i would think it's double encoding
|
|
|
|
username
|
2023-02-28 04:35:26
|
hmm maybe it is I didn't think about that
|
|
|
|
Traneptora
|
2023-02-28 04:35:44
|
I think it might have a hardware HEVC encoder
|
|
|
|
username
|
2023-02-28 04:35:45
|
kinda reminds me of how some scanners natively put out jpegs
|
|
|
|
Traneptora
|
2023-02-28 04:35:58
|
|
|
2023-02-28 04:36:00
|
this is my settings app
|
|
|
|
username
|
|
username
kinda reminds me of how some scanners natively put out jpegs
|
|
2023-02-28 04:36:03
|
or atleast they seem to...
|
|
|
|
Traneptora
|
2023-02-28 04:36:17
|
the "Reduce file size" to me suggests that it can record in HEVC with a hardware encoder
|
|
2023-02-28 04:36:23
|
no idea if that's actually spun up for HEIC photos
|
|
|
|
Demez
|
|
Traneptora
|
|
2023-02-28 04:36:43
|
yup, its right there with high efficiency pictures
|
|
|
|
Traneptora
|
2023-02-28 04:36:48
|
yea, I realize that now
|
|
|
|
w
|
2023-02-28 04:36:49
|
i mean the actual camera module, like the scanners native jpeg
|
|
|
|
Demez
|
2023-02-28 04:37:31
|
I'll have to do some tests, hmm
|
|
|
|
Traneptora
|
2023-02-28 04:37:47
|
even then camera quality JPEGs usually have minimal generation loss. I worry more about the seams along tile boundaries with HEIF
|
|
|
|
username
|
|
Traneptora
no idea if that's actually spun up for HEIC photos
|
|
2023-02-28 04:38:02
|
maybe set the phone up with a tripod and point it at a scene that isn't gonna change and take multiple photos at the same angle as both jpeg and heic/heif?
|
|
|
|
Demez
|
2023-02-28 04:38:07
|
oh yeah I forgot about that
|
|
|
|
Traneptora
|
|
username
maybe set the phone up with a tripod and point it at a scene that isn't gonna change and take multiple photos at the same angle as both jpeg and heic/heif?
|
|
2023-02-28 04:38:37
|
no I meant, if I take an HEIC photo no idea if it does a hardware HEVC encoding directly from the RAW, or if it just recompressed the JPEG in software
|
|
|
|
w
|
2023-02-28 04:38:42
|
in the android camera2 api, there's only two options from a camera sensor, jpeg and raw dng.
|
|
2023-02-28 04:39:31
|
you cant use raw dng if you want a usable photo immediately, and I'm sure they don't recompress the jpeg when you have it not as heif
|
|
|
|
Traneptora
|
2023-02-28 04:39:59
|
very unlikely
|
|
|
|
w
|
2023-02-28 04:42:37
|
it's the same with pc capture devices and webcams. they all provide a jpeg stream
|
|
2023-02-28 04:50:12
|
oh, I completely forgot that phones do a ton of processing on the image before saving it
|
|
2023-02-28 04:50:20
|
so I guess it matters a lot more then
|
|
|
|
OkyDooky
|
2023-02-28 04:54:39
|
Just tried it and it works really well, so far! It says my device is motorola\:ocean, so maybe that could be added to the list. I didn't encounter any issues (but, I also didn't push it *too* hard, either).
Maybe switch to Sentry (or similar) instead of Firebase and get this thing on either IzzyOnDroid or F-Droid proper? \:D
(<@886264098298413078>)
|
|
|
|
afed
|
2023-02-28 04:58:21
|
modern phone cameras are mostly a huge amount of ai pre-processing, upscaling, enhancement, averaging from multiple merged frames, etc., than improvements in the actual hardware, sensors, lenses, etc
|
|
|
|
_wb_
|
2023-02-28 07:22:05
|
If it produces heic files that are more than 20% smaller than the jpegs it makes, I would assume the heics are smaller not just because it's a better codec but also because the quality is lower.
|
|
|
|
Demiurge
|
|
Traneptora
not that I want it to take HEIC photos, tbh.
|
|
2023-02-28 07:25:54
|
nobody asked for it, nobody wanted it.
|
|
2023-02-28 07:26:34
|
honestly the only reason people hate heic is because so many people can't open it and so many programs and web sites won't accept it
|
|
|
|
Demez
|
2023-02-28 07:27:29
|
just like webp
|
|
|
|
Demiurge
|
2023-02-28 07:28:09
|
codec engineers hate webp because it is half baked and arguably worse than jpeg
|
|
|
|
Demez
|
2023-02-28 07:28:47
|
it's only good for something added later down the line, it's lossless mode imo
|
|
2023-02-28 07:29:24
|
i have all my screenshots from sharex set to convert to webp automatically, and i had converted all my old ones to that format as well, saved like 7 GB lol
|
|
|
|
Demiurge
|
2023-02-28 07:29:35
|
the lossless mode is really cool, but tacked onto such a limited and half-baked format is really tragic
|
|
|
|
_wb_
|
2023-02-28 07:30:07
|
The obligatory 4:2:0 in webp is one of its biggest limitations. In heic they had the chance to fix that (hevc can do 4:4:4, unlike vp8), but then Apple made it so 4:4:4 heic doesn't decode on their devices, so the de facto heic is 4:2:0 only just like webp...
|
|
|
|
Demiurge
|
2023-02-28 07:30:37
|
Hopefully JXL can gain lossless speed-efficiency improvements to be more comparable to webp
|
|
2023-02-28 07:31:45
|
what the actual hell? Apple does not support full res chroma?
|
|
2023-02-28 07:31:58
|
Is that only in heic or also for video?
|
|
|
|
Traneptora
|
2023-02-28 07:40:44
|
the hardware decoders don't
|
|
2023-02-28 07:41:01
|
guessing it's also for video as they use the same decoder
|
|
|
|
_wb_
|
2023-02-28 07:46:35
|
Haven't checked recently but last time I checked, I couldn't open 4:4:4 heic in Preview on MacOS
|
|
2023-02-28 07:46:48
|
4:2:0 worked in both 8-bit and 10-bit
|
|
2023-02-28 07:47:13
|
But 4:4:4 didn't work at any bitdepth and 12-bit or higher also didn't work, iirc
|
|
2023-02-28 07:47:56
|
Which strongly suggests that they either use hw decode without software fallback, or enforce the same limitations in sw as in hw...
|
|
|
|
Demiurge
|
2023-02-28 08:06:53
|
by the way <@794205442175402004>, did you ever get a response back from the feedback you left through that "avif feedback" email or does it presumably forward all feedback to /dev/null?
|
|
|
|
_wb_
|
2023-02-28 08:20:41
|
On December 14th I sent my feedback to them. On January 17th I sent another mail to say I didn't get any response, and to ask if they received my original mail, and they responded 3 hours later that indeed they did receive it. But that's all they said. On January 31st I sent another mail asking if I would also get an actual response to my feedback. I haven't received any reply to that one yet.
|
|
2023-02-28 08:22:49
|
I'm not getting the impression that they genuinely want to improve their codec comparison methodology. Or at least not with a high priority.
|
|
|
BlueSwordM
|
|
_wb_
I'm not getting the impression that they genuinely want to improve their codec comparison methodology. Or at least not with a high priority.
|
|
2023-02-28 09:00:54
|
Don't worry. It's the usual way most AOM devs work: they don't tend to respond to outside feedback from non AOM members.
There are a few that are good in this regard, like Wan-Teh? Chang, so perhaps try to contact him directly so perhaps you can get some feedback.
|
|
|
|
_wb_
|
2023-02-28 09:24:35
|
I don't think they really feel like making any update to their comparison page that makes avif look worse
|
|
|
|
Demiurge
|
2023-03-01 12:55:03
|
Basically their comparison page boils down to: Here are some quality comparisons that show AVIF beats JXL at bitrates below 0.5bps and loses to JXL everywhere else... And here are some benchmarks that show is faster than JXL. ...No, really! Believe us, it really is faster! I know it's contrary to literally everyone else's actual experience with both codecs but just believe us okay, AVIF is faster lol!
|
|
|
|
novomesk
|
|
Demiurge
Basically their comparison page boils down to: Here are some quality comparisons that show AVIF beats JXL at bitrates below 0.5bps and loses to JXL everywhere else... And here are some benchmarks that show is faster than JXL. ...No, really! Believe us, it really is faster! I know it's contrary to literally everyone else's actual experience with both codecs but just believe us okay, AVIF is faster lol!
|
|
2023-03-01 03:03:35
|
AVIF decoding worked indeed faster in the browser than JXL.
|
|
|
|
_wb_
|
2023-03-01 03:23:54
|
well it depends a bit, 8-bit 4:2:0 avif in a colorspace that has a fast path yes, otherwise it's a bit less clear. Also avif decoding only starts when the full bitstream is available, so whether it is really faster depends on network speed too (on a slow enough network, a jxl can be almost completely decoded before avif decoding even starts)
|
|
|
|
Demiurge
|
2023-03-01 05:01:15
|
according to <@794205442175402004> the avif decoding speed dropped like a stone for anything other than 8-bit 4:2:0
|
|
2023-03-01 05:04:27
|
But I think what actually matters is that anyone can see for themselves how slow or how fast each format is without having to use Chrome
|
|
2023-03-01 05:04:59
|
And literally everyone who has used both formats walk away with the impression that AVIF is a lot slower
|
|
2023-03-01 05:06:58
|
You can time it with ffmpeg or with djxl/avifdec
|
|
|
|
_wb_
|
2023-03-01 05:20:10
|
decoding is probably quite similar between the two, tbh
|
|
2023-03-01 05:26:51
|
for encoding, both can of course do any speed (fastest setting is very fast, slowest is very slow), but libjxl basically gets as good as it gets at e6 or e7 (and e8/e9 are a tiny bit better and a lot slower) while libaom keeps getting better as you go to slower settings. Even at the slowest settings, it doesn't beat jxl at high quality, but the crossover point does shift. At reasonable encode speeds (which for us means libaom s6+ and libjxl e7-, but for others it may of course mean something somewhat different, though I think everyone agrees that libaom s0 is not reasonable), the crossover point below which avif beats jxl is very low (probably lower than any quality you'd actually want to use).
|
|
|
|
Demiurge
|
2023-03-01 05:30:38
|
I think rav1e looks the best
|
|
2023-03-01 05:30:49
|
in terms of lossy quality
|
|
|
|
_wb_
|
2023-03-01 05:31:29
|
yeah but it's quite slow compared to current libaom
|
|
|
|
Demiurge
|
2023-03-01 05:54:17
|
and libaom is quite slow compared to svtav1 :)
|
|
2023-03-01 05:54:42
|
which is quite slow compared to hardware
|
|
|
|
yoochan
|
2023-03-01 06:04:18
|
Did someone ever tried to (partially?) use webgl/glsl to decode jxl in the browser?
|
|
2023-03-01 06:05:42
|
I saw this attempt for jpeg... But the owner left it seven years ago https://github.com/negge/jpeg_gpu
|
|
|
|
Traneptora
|
|
yoochan
Did someone ever tried to (partially?) use webgl/glsl to decode jxl in the browser?
|
|
2023-03-01 06:18:31
|
it's very hard to accelerate JXL decode with shaders. you're better off using wasm
|
|
|
|
veluca
|
|
Traneptora
it's very hard to accelerate JXL decode with shaders. you're better off using wasm
|
|
2023-03-01 06:21:18
|
why do you say that? I suspect a good chunk *can* be done with shaders (pretty much everything but entropy decoding)
|
|
|
|
Traneptora
|
2023-03-01 06:22:14
|
Modular
|
|
2023-03-01 06:22:21
|
no idea how you'd do Modular with shaders
|
|
2023-03-01 06:22:30
|
and Modular is required for everything, including VarDCT
|
|
|
|
veluca
|
2023-03-01 06:27:59
|
ah, yes, but for VarDCT modular is only 1/64 of the effort (kinda, roughly)
|
|
2023-03-01 06:28:14
|
so do DC on CPU too and then do the rest on shaders
|
|
|
|
yoochan
|
2023-03-01 06:43:24
|
Well... I retain it could be tried but the improvements could be not as much as expected ๐ for the project mentioned above, indeed the data was entropy decoded before being sent to the GPU...
|
|
2023-03-01 06:46:22
|
But it was wegl1, the v2 brought many improvements and flexibility to handle arbitrary data
|
|
|
JayJain
|
2023-03-02 01:16:36
|
Hello guys, Jay here. I want to decode and understand the structure of various latest image formats (namely WebP, JPEG XL, HEIF and AVIF) and compare header information with respect to image data to see which format is header information heavy with respect to image data. Is there any specific way of extracting header information from JPEG XL using Python.
|
|
|
JayJain
Hello guys, Jay here. I want to decode and understand the structure of various latest image formats (namely WebP, JPEG XL, HEIF and AVIF) and compare header information with respect to image data to see which format is header information heavy with respect to image data. Is there any specific way of extracting header information from JPEG XL using Python.
|
|
2023-03-02 01:17:33
|
I also looked up the internet for this but couldn't find a good approach to this yet
|
|
|
|
veluca
|
2023-03-02 01:18:47
|
I think you need to use the C API
|
|
|
|
JayJain
|
2023-03-02 01:21:41
|
Yes it is as per this info on jpegxl.io
|
|
|
veluca
I think you need to use the C API
|
|
2023-03-02 01:23:34
|
Could you please elaborate on this?
|
|
|
|
veluca
|
2023-03-02 01:26:22
|
libjxl exposes a C API that allows you to get header information without actually decoding the image
|
|
2023-03-02 01:27:35
|
you can also call `jxlinfo` IIRC but I am not sure you want to rely on parsing its output
|
|
|
|
_wb_
|
2023-03-02 01:50:18
|
JXL raw codestream (which is a valid jxl file) has a very compact header. Everything is variable sized in it, so can't really say how many bytes it is (like they apparently do on jpegxl.io), but you can have a valid jxl file (header + data) in 12 bytes โ even if for many actual images, the header size could be more than that.
|
|
2023-03-02 01:56:18
|
AVIF and HEIC have much more fixed-size and verbose headers.
|
|
2023-03-02 01:57:15
|
a single transparent pixel can be done in a 23 byte jxl file (probably less if you handcraft it, but that's what cjxl does)
|
|
2023-03-02 01:57:35
|
in avif I'm getting 446 bytes
|
|
2023-03-02 01:57:52
|
Encoded successfully.
* Color AV1 total size: 23 bytes
* Alpha AV1 total size: 18 bytes
|
|
2023-03-02 01:58:16
|
payload data is 23+18 bytes, so about 400 bytes header nonsense
|
|
2023-03-02 01:59:08
|
single transparent pixel in avif:
|
|
2023-03-02 01:59:26
|
```
00000000 00 00 00 1c 66 74 79 70 61 76 69 66 00 00 00 00 |....ftypavif....|
00000010 61 76 69 66 6d 69 66 31 6d 69 61 66 00 00 01 71 |avifmif1miaf...q|
00000020 6d 65 74 61 00 00 00 00 00 00 00 28 68 64 6c 72 |meta.......(hdlr|
00000030 00 00 00 00 00 00 00 00 70 69 63 74 00 00 00 00 |........pict....|
00000040 00 00 00 00 00 00 00 00 6c 69 62 61 76 69 66 00 |........libavif.|
00000050 00 00 00 0e 70 69 74 6d 00 00 00 00 00 01 00 00 |....pitm........|
00000060 00 2c 69 6c 6f 63 00 00 00 00 44 00 00 02 00 01 |.,iloc....D.....|
00000070 00 00 00 01 00 00 01 a7 00 00 00 17 00 02 00 00 |................|
00000080 00 01 00 00 01 95 00 00 00 12 00 00 00 42 69 69 |.............Bii|
00000090 6e 66 00 00 00 00 00 02 00 00 00 1a 69 6e 66 65 |nf..........infe|
000000a0 02 00 00 00 00 01 00 00 61 76 30 31 43 6f 6c 6f |........av01Colo|
000000b0 72 00 00 00 00 1a 69 6e 66 65 02 00 00 00 00 02 |r.....infe......|
000000c0 00 00 61 76 30 31 41 6c 70 68 61 00 00 00 00 1a |..av01Alpha.....|
000000d0 69 72 65 66 00 00 00 00 00 00 00 0e 61 75 78 6c |iref........auxl|
```
|
|
2023-03-02 01:59:30
|
```
000000e0 00 02 00 01 00 01 00 00 00 a7 69 70 72 70 00 00 |..........iprp..|
000000f0 00 81 69 70 63 6f 00 00 00 14 69 73 70 65 00 00 |..ipco....ispe..|
00000100 00 00 00 00 00 01 00 00 00 01 00 00 00 0e 70 69 |..............pi|
00000110 78 69 00 00 00 00 01 08 00 00 00 0c 61 76 31 43 |xi..........av1C|
00000120 81 00 1c 00 00 00 00 13 63 6f 6c 72 6e 63 6c 78 |........colrnclx|
00000130 00 01 00 0d 00 06 80 00 00 00 38 61 75 78 43 00 |..........8auxC.|
00000140 00 00 00 75 72 6e 3a 6d 70 65 67 3a 6d 70 65 67 |...urn:mpeg:mpeg|
00000150 42 3a 63 69 63 70 3a 73 79 73 74 65 6d 73 3a 61 |B:cicp:systems:a|
00000160 75 78 69 6c 69 61 72 79 3a 61 6c 70 68 61 00 00 |uxiliary:alpha..|
00000170 00 00 1e 69 70 6d 61 00 00 00 00 00 00 00 02 00 |...ipma.........|
00000180 01 04 01 02 83 04 00 02 04 01 02 83 05 00 00 00 |................|
00000190 31 6d 64 61 74 12 00 0a 04 18 00 06 15 32 08 10 |1mdat........2..|
000001a0 00 00 18 e1 42 72 10 12 00 0a 07 18 00 06 18 08 |....Br..........|
000001b0 68 35 32 0a 16 40 18 61 00 01 75 54 42 98 |h52..@.a..uTB.|
```
|
|
2023-03-02 01:59:54
|
single transparent pixel in jxl:
```
00000000 ff 0a 00 10 0c 0c 06 00 8a 1b 01 08 08 10 00 18 |................|
00000010 00 4b 18 8b 15 82 01 |.K.....|
```
|
|
2023-03-02 02:00:35
|
in png:
```
00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 |.PNG........IHDR|
00000010 00 00 00 01 00 00 00 01 01 00 00 00 00 37 6e f9 |.............7n.|
00000020 24 00 00 00 02 74 52 4e 53 00 00 76 93 cd 38 00 |$....tRNS..v..8.|
00000030 00 00 0a 49 44 41 54 08 d7 63 60 00 00 00 02 00 |...IDAT..c`.....|
00000040 01 e2 21 bc 33 00 00 00 00 49 45 4e 44 ae 42 60 |..!.3....IEND.B`|
00000050 82 |.|
```
|
|
2023-03-02 02:02:46
|
you can tell by the amount of plaintext stuff and repeated zero bytes how much silly verbosity is going on in avif
|
|
2023-03-02 02:04:11
|
when not using the naked JXL codestream but the ISOBMF container format, 40 bytes of overhead are added:
```
00000000 00 00 00 0c 4a 58 4c 20 0d 0a 87 0a 00 00 00 14 |....JXL ........|
00000010 66 74 79 70 6a 78 6c 20 00 00 00 00 6a 78 6c 20 |ftypjxl ....jxl |
00000020 00 00 00 1f 6a 78 6c 63 ff 0a 00 10 0c 0c 06 00 |....jxlc........|
00000030 8a 1b 01 08 08 10 00 18 00 4b 18 8b 15 82 01 |.........K.....|
```
|
|
2023-03-02 02:06:10
|
HEIF is also ISOBMF based but instead of just using the ISOBMF box structure in a minimal way like we do in jxl, it also specifies pretty verbose ways to signal various things
|
|
2023-03-02 02:08:08
|
like having the plaintext string `urn:mpeg:mpegB:cicp:systems:auxiliary:alpha` right in the bitstream to signal that a particular payload is representing the alpha channel. That's a hilariously "designed by committee" text string that makes me chuckle each time I see it again
|
|
|
|
HLBG007
|
|
_wb_
HEIF is also ISOBMF based but instead of just using the ISOBMF box structure in a minimal way like we do in jxl, it also specifies pretty verbose ways to signal various things
|
|
2023-03-02 02:24:37
|
I want you remember my chat on December 5th 2022 with ChatGPT because you write HEIF:
Is Avif or JPEG XL better?
It is difficult to say whether AVIF or JPEG XL is "better" without knowing the specific context in which they will be used. Both AVIF and JPEG XL are image formats that use modern compression techniques to improve the efficiency of image storage and transmission. AVIF is based on the AV1 video codec and uses intra-frame coding, wavelet transform, and other advanced techniques to achieve high compression ratios. JPEG XL is based on the HEVC video codec and uses prediction, transform, quantization, and entropy coding to achieve high compression ratios. The best choice between AVIF and JPEG XL will depend on the specific requirements and goals of the application in which they will be used.
Sorry, you said jpegxl is based on the HEVC video codecs?
Yes, that is correct. I apologize if my previous response was unclear. JPEG XL is an image format that is based on the HEVC (High Efficiency Video Coding) video codec. HEVC is a modern video codec that uses advanced techniques such as prediction, transform, quantization, and entropy coding to achieve high compression ratios. JPEG XL uses many of the same techniques as HEVC to achieve high compression ratios for still images. I apologize for any confusion I may have caused.
|
|
2023-03-02 02:25:18
|
xD
|
|
|
|
_wb_
|
2023-03-02 02:27:11
|
chatGPT is funny, it says things that sound vaguely plausible but the more you actually know about the topic already, the more you know that it's mostly wrong
|
|
|
|
HLBG007
|
2023-03-02 02:39:34
|
Yes, because I clicked in december the dislike and wrote in the edit field the true answer. I did do this very often. This had helped by training the ai so the answer is now no it is not HEVC.
|
|
|
|
improver
|
2023-03-02 02:45:17
|
the only way is to establish the ministry of truth
|
|
|
|
Demiurge
|
2023-03-02 03:52:32
|
AVIF uses wavelet transformations?
|
|
2023-03-02 03:53:19
|
I heard that chatgpt is gradually becoming dumber as they dumb it down and limit it more
|
|
2023-03-02 03:53:34
|
We should try to teach it that birds aren't real
|
|
|
|
veluca
|
|
Demiurge
AVIF uses wavelet transformations?
|
|
2023-03-02 03:56:25
|
not as far as I know
|
|
|
|
Demiurge
|
2023-03-02 03:57:45
|
Yeah, not as far as I know either.
|
|
2023-03-02 03:57:54
|
But it sounds like something an AI would say.
|
|
|
|
_wb_
|
2023-03-02 04:15:42
|
Basically everything it says is still kind of wrong...
"AVIF is a newer image format" -> no, it's older than JPEG XL
"that is more efficient than JPEG XL" -> whatever you mean with "more efficient" (faster or better compression), I disagree
"AVIF is best for photos and JPEG XL is better for graphics" -> no, I would say it's the other way around, at least with current encoders
"reducing file sizes by up to 70%" -> that's rather optimistic, I would say
"based on the JPEG 2000 standard" -> nope
|
|
|
|
improver
|
2023-03-02 04:43:14
|
what you'd expect from web-spider based info gathering. accurate information, or popular propaganda and misunderstandings?
|
|
|
fab
|
2023-03-02 05:02:21
|
Avif and avm both uses wavelet
|
|
|
|
_wb_
|
2023-03-02 05:11:07
|
What is avm?
|
|
2023-03-02 05:11:20
|
And how does avif use wavelet?
|
|
2023-03-02 05:12:26
|
I think it only has dct, maybe also some variants of it, no?
|
|
2023-03-02 05:13:08
|
It doesn't have j2k style wavelets in any case, otherwise it would probably do progressive
|
|
|
Cool Doggo
|
|
_wb_
What is avm?
|
|
2023-03-02 05:14:11
|
av2 reference software
|
|
|
DZgas ะ
|
2023-03-02 05:16:38
|
<:kekw:808717074305122316>
|
|
|
|
_wb_
|
2023-03-02 05:25:19
|
Oh, that's an implementation, not a codec
|
|
|
|
yoochan
|
|
_wb_
Basically everything it says is still kind of wrong...
"AVIF is a newer image format" -> no, it's older than JPEG XL
"that is more efficient than JPEG XL" -> whatever you mean with "more efficient" (faster or better compression), I disagree
"AVIF is best for photos and JPEG XL is better for graphics" -> no, I would say it's the other way around, at least with current encoders
"reducing file sizes by up to 70%" -> that's rather optimistic, I would say
"based on the JPEG 2000 standard" -> nope
|
|
2023-03-02 06:27:27
|
A french youtuber (Monsieur Phi) did two wonderful videos on ChatGPT where he explains how it is just a giant "next word predictor" and as such it is a wonderful bullshitter (in the sense of Harry Frankfurt). Producing plausible sentences statistically most fit to the previous prompt... but that's all. True of False matter less than "best random pick"
|
|
|
|
_wb_
|
2023-03-02 06:31:08
|
Autocorrect on steroids...
|
|
2023-03-02 06:34:09
|
If I just start typing something and let autocomplete continue, what I get is a bit similar, just a lot worse. It goes like this: the same thing as last time I was there are no longer available for a call later today and I'll be there in about the same thing as last time I was there to help you out of work yet I think I think I have a few things to do in any case you want to do it again soon and I will be there in about the same thing as last time I was there to help you out with the kids to the park and the other one is a bit of a bit of a difference between the two of us
|
|
|
|
afed
|
2023-03-02 06:42:12
|
even image generation works basically like infinite upscalers, but when it doesn't need to achieve a close similarity to the source and variability is much wider
|
|
|
|
Demiurge
|
2023-03-02 08:17:48
|
ENHANCE
|
|
|
|
Jyrki Alakuijala
|
|
_wb_
single transparent pixel in jxl:
```
00000000 ff 0a 00 10 0c 0c 06 00 8a 1b 01 08 08 10 00 18 |................|
00000010 00 4b 18 8b 15 82 01 |.K.....|
```
|
|
2023-03-03 10:24:46
|
my first version of webp lossless had a 5 byte single black pixel stream -- I consider headers overvalued ๐ -- later the stream got compatibility, limitations and bloat from the WebP lossy header
|
|
|
|
gb82
|
2023-03-04 09:04:49
|
Does anyone have any tips on how to create a good photographic dataset for testing different image codecs?
|
|
|
|
_wb_
|
2023-03-04 09:13:07
|
If you want full resolution images, you'll have to make or find raw images. For testing 'web images', you can just take high res images from pexels or wherever, and downscale them. Starting from a high-quality jpeg, downscaling at least 2x should result in an image that can be considered pristine.
|
|
2023-03-04 09:22:00
|
Then I would go for a variety of image contents. If the set is aimed for subjective testing and you don't have budget for testing on many images, it can be a good idea to have only a few images, with different things in the same image (people, sky, trees, water, buildings, etc). If you're aiming to make a big dataset, e.g. meant for objective metrics evaluation, you can just have a variety of images. It can be a good idea to make some categories of images, to be able to investigate behavior per category instead of averaged over everything. E.g. four broad categories for photo could be outdoors/nature, indoors, people/portrait, cars/urban scenes.
|
|
|
|
gb82
|
2023-03-04 10:15:18
|
That's great advice, thanks! I was going to go out & do some shooting to create the dataset on my own, so I'll definitely keep this in mind!
|
|
|
|
Demiurge
|
2023-03-05 12:54:18
|
This is a pretty decent and popular dataset: https://github.com/eclipseo/eclipseo.github.io/tree/2f93d184577d273cac729e778d73fdcc8a93d0a8/image-comparison-web/comparisonfiles/subset1/Original
|
|
2023-03-05 01:25:59
|
It's used here: https://eclipseo.github.io/image-comparison-web/#buenos-aires*1:1&JXL_20210715=s&AOM_20210715=s&subset1
|
|
2023-03-05 01:27:19
|
It's pretty amazing how much uglier AVIF is in that particular picture :)
|
|
|
|
gb82
|
|
Demiurge
This is a pretty decent and popular dataset: https://github.com/eclipseo/eclipseo.github.io/tree/2f93d184577d273cac729e778d73fdcc8a93d0a8/image-comparison-web/comparisonfiles/subset1/Original
|
|
2023-03-05 05:49:53
|
oh that's cool
|
|
2023-03-05 05:50:08
|
I'm still gonna try to put together my own of like ~20 pics
|
|
|
|
Traneptora
|
2023-03-05 03:17:53
|
does anyone have any really obnoxious samples for animated jxl? garbage like, wrapped in a container using terrible box partitioning, weird timebases, or similar nonstandard situations?
|
|
2023-03-05 03:18:08
|
i'm trying to compliance test my parser
|
|
|
|
novomesk
|
2023-03-05 03:45:29
|
I am curious whether if it is possible to have animated JXL-CMYK
|
|
|
|
_wb_
|
2023-03-05 07:08:41
|
Sure, why not
|
|
|
|
Traneptora
|
2023-03-05 07:37:56
|
FFmpeg doesn't support CMYK so that doesn't really concern me
|
|
2023-03-05 07:38:02
|
(this is for FFmpeg)
|
|
2023-03-05 07:38:43
|
though animated JXL CMYK sounds kinda silly as CMYK is something that is specifically designed for print media
|
|
|
|
yoochan
|
|
Traneptora
does anyone have any really obnoxious samples for animated jxl? garbage like, wrapped in a container using terrible box partitioning, weird timebases, or similar nonstandard situations?
|
|
2023-03-05 07:39:29
|
someone should write an encoder from spec to feed your needs ๐
|
|
|
|
Traneptora
|
2023-03-05 07:40:02
|
well spec doesn't actually tell you how to encode
|
|
2023-03-05 07:40:13
|
it just provides a small incomplete informative overview
|
|
2023-03-05 07:40:34
|
spec defines the codestream in terms of its decoding behavior (this is fairly standard practice)
|
|
2023-03-05 07:41:01
|
I could always take a raw codestream and partition it in obnoxious ways by hand
|
|
2023-03-05 07:41:38
|
and then wrap each item one with an ISOBMFF header, and concatenate them all into a container file
|
|
|
|
yoochan
|
2023-03-05 07:41:50
|
cjxl is the only encoder existing ?
|
|
|
|
Traneptora
|
2023-03-05 07:42:04
|
at the moment, libjxl and anything based on libjxl (e.g. cjxl) are
|
|
2023-03-05 07:42:15
|
unless you count jxl_from_tree which produces JXL files based on MA trees
|
|
2023-03-05 07:42:18
|
(i.e. jxl art)
|
|
2023-03-05 07:42:29
|
in terms of producing JXL files from input raster image files then yes currently they're all libjxl-based
|
|
2023-03-05 07:43:06
|
a separate encoder would be a cool but time-consuming project that's on my list to do this summer
|
|
2023-03-05 07:43:51
|
I'm considering writing a pure C decoder as well first, as jxlatte is slow as hell
|
|
2023-03-05 07:44:46
|
Lynne also has on her backburner the goal to write ffmpeg's decoder but it's... kinda on indefinite hold as she's been working on vulkan video decode
|
|
|
|
yoochan
|
2023-03-05 07:45:23
|
based on j40 ?
|
|
|
|
Traneptora
|
2023-03-05 07:46:38
|
from scratch
|
|
2023-03-05 07:46:54
|
I don't particularly like how J40 is organized
|
|
|
|
yoochan
|
2023-03-05 07:47:37
|
cool, I was wondering if our best option for wide adoption wouldn't be to focus on a direct rust + SIMD to WASM optimized decoder
|
|
|
|
Traneptora
|
2023-03-05 07:47:39
|
it'll be *much* faster for me to write it this time as I've already written a decoder, namely jxlatte
|
|
2023-03-05 07:48:15
|
I wrote it for the JVM as I figured it could do things that libjxl didn't
|
|
2023-03-05 07:48:23
|
but I don't particularly like Java compared to C
|
|
|
|
yoochan
|
2023-03-05 07:48:23
|
I guess so, you must be the most knownledgeable now, except the 3 experts who wrote libjxl
|
|
2023-03-05 07:48:43
|
why did you picked java then ?
|
|
|
|
Traneptora
|
2023-03-05 07:49:03
|
well JVM was a target that libjxl didn't have
|
|
2023-03-05 07:49:07
|
it only has JNI bindings
|
|
2023-03-05 07:49:19
|
so that could target platforms that libjxl wasn't currently optimized for, provided that the JVM existed on them
|
|
2023-03-05 07:49:26
|
I figured it could do something "new"
|
|
|
|
yoochan
|
2023-03-05 07:49:27
|
oki
|
|
2023-03-05 07:55:49
|
I tried myself to dive into an implementation... but lacks time to do it properly... I'll have a look at your sources to see
|
|
|
|
_wb_
|
2023-03-05 08:15:40
|
I think we're getting to the point where an independent encoder might be more useful to find spec bugs than an independent decoder.
|
|
|
|
yoochan
|
2023-03-05 08:18:51
|
I'm not talented enough for that but I would happily try to convince thebombzen ๐
|
|
|
|
Traneptora
|
2023-03-05 08:21:37
|
Not entirely sure how to set up an ANS encoder or brotli encoder as used in JXL
|
|
2023-03-05 08:22:34
|
afaik you have to write symbols for ans in the opposite order they are supposed to be read, but I'm not entirely sure how to actually do the actual process
|
|
2023-03-05 08:22:59
|
context clustering
|
|
2023-03-05 08:23:01
|
lz77 searching
|
|
2023-03-05 08:23:33
|
Hubrid Uint Splitting
|
|
|
|
yoochan
|
2023-03-05 08:23:38
|
have fun ! going to bed ! :p
|
|
|
|
Traneptora
|
2023-03-05 08:23:49
|
all systemic on decode but require many choices upon encode
|
|
2023-03-05 08:24:21
|
im thinking of writing a decoder in C first as I'm planning on sharing code between the decoder and encoder
|
|
2023-03-05 08:25:03
|
but things like MA tree learning, patch detection, context clustering, etc. are all nontrivial problems
|
|
2023-03-05 08:25:24
|
doing it intelligently, that is
|
|
2023-03-05 08:25:55
|
generally you need heuristics as exhaustive searches aren't useful
|
|
|
|
_wb_
|
2023-03-05 08:34:00
|
I mean, you can start with huffman encoding only, fixed or trivial MA trees, no patches, etc
|
|
2023-03-05 08:34:30
|
Basically start with a jpeg encoder in jxl syntax and gradually add more stuff
|
|
|
|
Traneptora
|
2023-03-05 08:35:10
|
sure, writing a dumb encoder probably isn't too hard. but making it useful is probably a massive timesink
|
|
2023-03-05 08:35:33
|
something that would be better for me to do after I graduate
|
|
2023-03-05 08:35:44
|
(in a few months)
|
|
|
|
_wb_
|
2023-03-05 08:37:57
|
Beating libjxl on all fronts will be hard, but e.g. a libjxl-tiny style limited scope fast lossy encoder could be quite useful if it has some features libjxl doesn't have yet, like streaming encoding (one stripe or tile at a time instead of one frame at a time) or low-memory encoding
|
|
|
|
Traneptora
|
2023-03-05 08:38:27
|
hm, didn't consider that
|
|
2023-03-05 08:39:26
|
how would you do low-memory ANS? or would you stick to instantaneous codes for that
|
|
|
|
_wb_
|
2023-03-05 08:40:13
|
From my pov as spec editor, I would also be interested in a funky jxl_from_tree style encoder that doesn't encode pixels but that uses splines and patches and all kinds of exotic stuff, say integrated in a jxl-specific image editing tool.
|
|
2023-03-05 08:40:26
|
For low-memory, huffman is by far more convenient
|
|
|
|
Traneptora
|
2023-03-05 08:40:32
|
ah, ok
|
|
2023-03-05 08:41:28
|
how does context clustering work with regard to huffman? that seems like a task one still must solve
|
|
2023-03-05 08:41:52
|
ig with prefix codes you can always use a single cluster
|
|
|
|
_wb_
|
2023-03-05 08:42:26
|
But ANS is not impossible, it would be a matter of encoding groups in the opposite order (bottom right to top left) and writing bitstream from right to left, I think. Just a lot of headache compared to doing it in two passes.
|
|
|
|
Traneptora
|
2023-03-05 08:42:26
|
for things like the Hfctx with like 4000 preclustered dists it seems inefficient tho
|
|
2023-03-05 08:43:16
|
for a single cluster
|
|
|
_wb_
But ANS is not impossible, it would be a matter of encoding groups in the opposite order (bottom right to top left) and writing bitstream from right to left, I think. Just a lot of headache compared to doing it in two passes.
|
|
2023-03-05 08:44:07
|
how would this work? you encode the group in reverse token order? but that seems generally impossible for modular tho ig for vardct it's doable
|
|
|
|
_wb_
|
2023-03-05 08:45:13
|
You could do some static, fixed clustering and get most of the benefits, then either fixed huffman codes per ctx or making actual histograms (could be done by sampling or a full pass if you have the full buffer)
|
|
2023-03-05 08:46:23
|
For modular it's also possible, the encoder knows all pixel values so it can work in any order.
|
|
2023-03-05 08:50:24
|
There are no adaptive chances anywhere in jxl, everything is based on static signalled histograms, so the encoder can do things in a different order than the decoder (unlike flif where everything was adaptive, so the encoder needs to do things exactly in the same order as the decoder to keep the chances in sync; but flif used a range coder, not ANS, so reverse coding was not needed).
|
|
|
|
Traneptora
|
2023-03-05 08:52:14
|
hm, I guess if you do a low-memory streaming group-based encoder that could be doable
|
|
2023-03-05 08:52:54
|
probably would need to be RGB only at first because of lossy alpha
|
|
2023-03-05 08:53:37
|
lossy alpha might just make sense to do losslessly
|
|
2023-03-05 08:53:58
|
using something like gradient only and no WP
|
|
2023-03-05 08:54:06
|
as WP is super memory eating
|
|
2023-03-05 09:00:45
|
doing tile based encoding also makes it so youd ditch the global tree
|
|
2023-03-05 09:00:50
|
probably
|
|
2023-03-05 09:00:56
|
if you want to stream
|
|
|
|
_wb_
|
2023-03-05 09:01:28
|
Yeah squeeze, delta palette and WP are too much of a headache, and probably all aren't useful for low memory encoding
|
|
|
|
Traneptora
|
2023-03-05 09:02:54
|
would I need to encode an entire LF Group at a time or could I do groups?
|
|
|
|
_wb_
|
2023-03-05 09:03:07
|
Yes, local trees and doing everything in group-sized chunks for lossless, or dc-group-sized chunks for lossy (those are 2048x2048), that seems to me the best approach for making an encoder that can handle arbitrary image dimensions
|
|
2023-03-05 09:04:50
|
You can do HF one group at a time, remember the LF coeffs while you do those, and then once an LF group is done, emit it and start at the next one.
|
|
2023-03-05 09:05:30
|
You do need to buffer compressed bitstream sections though, to get the toc right.
|
|
|
|
Traneptora
|
2023-03-05 09:05:41
|
dont think I can get away without keeping a whole LF tile in memory at once
|
|
2023-03-05 09:06:38
|
I wonder if I can cheat that by using one Frame per LF group, with xy and crop
|
|
2023-03-05 09:06:50
|
Er, cheat the TOC
|
|
|
|
_wb_
|
2023-03-05 09:06:56
|
Well the LF tile is only 256x256 too, it's not a huge buffer to keep track of if you want to go minimal
|
|
2023-03-05 09:07:11
|
But doing 4 megapixels at a time should be fine
|
|
|
|
Traneptora
|
2023-03-05 09:08:54
|
hm, but I meant, how do I generate an LF tile and then the HF tiles without, buffering the whole image
|
|
|
|
_wb_
|
2023-03-05 09:09:16
|
Cheating the TOC that way is a nice idea. If you can write bitstream and seek once to fix the toc, that also works I guess
|
|
2023-03-05 09:10:50
|
If you get 256x256 pixels at a time, and store their 32x32 LF until you have processed a full LF group, you can suffice with a buffer of 2x256x256 pixels (one for HF, one for remembering LF)
|
|
|
|
Traneptora
|
2023-03-05 09:11:08
|
Id like to allow the client of said library to pass one tile at a time
|
|
2023-03-05 09:11:31
|
that's not so bad
|
|
2023-03-05 09:11:49
|
but how can I emit a tile without the LF group metadata?
|
|
2023-03-05 09:14:48
|
would I just buffer the output of the LF group until i have a full lf group encoded?
|
|
|
|
_wb_
|
2023-03-05 09:18:14
|
Yes, the lf coeffs and the hf metadata would need to be buffered, but hf metadata is just block types and adaptive quant factors, that's one byte each. So 8 bytes per 8x8 block for hf + lf metadata.
|
|
|
|
Traneptora
|
2023-03-05 09:19:34
|
hm, im thinking about the 4 channel modular stream in the lf group metadata
|
|
2023-03-05 09:20:38
|
for super low memory I probably stay 8x8
|
|
2023-03-05 09:20:59
|
use default qweights
|
|
|
|
afed
|
2023-03-05 09:22:05
|
seems that some simpler methods can also achieve very good lossless results with fast speeds (for large photos especially), even with very little memory consumption, like HALIC based on FSEU16
<https://github.com/Cyan4973/FiniteStateEntropy>
<https://encode.su/threads/4025-HALIC-(High-Availability-Lossless-Image-Compression)>
i wonder if something like this is possible for jxl with ans?
|
|
|
|
Deleted User
|
2023-03-05 11:11:42
|
fse is also ans ( https://github.com/Cyan4973/FiniteStateEntropy/ )
|
|
|
|
afed
|
2023-03-05 11:32:24
|
yeah, but ANS has variations like tANS, rANS
also format limitations
|
|
|
jonnyawsom3
|
2023-03-06 05:37:11
|
Sounds like it'd be an ideal encoder for mobile devices
|
|
|
|
Traneptora
|
2023-03-06 10:39:06
|
I have an initial API design of hydrium
|
|
2023-03-06 10:39:08
|
https://github.com/thebombzen/hydrium/blob/main/libhydrium/hydrium.h
|
|
2023-03-06 10:39:11
|
thoughs?
|
|
|
|
afed
|
2023-03-06 12:12:24
|
also, does jxl_tiny have lossless?
`cjxl_tiny.exe image.pfm image.jxl -d 0`
`Encoding failed.`
`Usage: cjxl_tiny <file in> [<file out>] [-d distance]`
`NOTE: <file in> is a .pfm file in linear SRGB colorspace`
|
|
|
|
_wb_
|
2023-03-06 12:39:20
|
no, it's lossy only
|
|
|
|
diskorduser
|
2023-03-06 03:09:13
|
It does not have comparison with avif ๐ฆ
|
|
|
|
yoochan
|
2023-03-06 03:10:45
|
perhaps because they didn't even think AVIF was a decent image format ๐
|
|
|
|
jonnyawsom3
|
2023-03-06 03:27:39
|
I reads more like the evolution of jpeg than comparing image formats, with scaled PNG as a random baseline
|
|
|
|
_wb_
|
2023-03-06 03:55:57
|
it would be interesting to see how avif, webp and heic do in this particular benchmark. It's an interesting way to test a codec: it's task-oriented (can we still detect the face?), not "aesthetics" oriented (does the image still look good?)
|
|
2023-03-06 03:59:25
|
My gut feeling would be that avif/webp/heic don't do super well on this: they can produce good-looking images at low bpp, but they do it by "rounding" angles to the nearest directional prediction mode, which in the case of faces means they slightly change the shape of facial features. My intuition is that this might be quite bad for face recognition...
|
|
|
|
Traneptora
|
2023-03-06 11:16:49
|
not bad if I do say so myself
|
|
2023-03-06 11:16:55
|
```c
static inline int uint64_log2(uint64_t n) {
#define S(k) if (n >= (UINT64_C(1) << k)) { i += k; n >>= k; }
int i = -(n == 0); S(32); S(16); S(8); S(4); S(2); S(1); return i;
#undef S
}
static int64_t linearize(const int64_t srgb) {
if (srgb <= 2650)
return (srgb * UINT64_C(332427809)) >> 32;
const uint64_t prepow = ((srgb + 3604) * UINT64_C(4071059048));
const uint64_t log = uint64_log2(prepow);
const uint64_t prepow_d = (prepow >> (log - 20)) & ~(~UINT64_C(0) << 20) | ((0x3FE + log - 47) << 20);
const uint64_t postpow_d = ((((prepow_d - INT64_C(1072632447)) * 410) >> 10) + INT64_C(1072632447));
const uint64_t postpow = ((postpow_d & ~(~UINT64_C(0) << 20)) | (UINT64_C(1) << 20))
>> (1027 - ((postpow_d >> 20) & 0x3FF));
const uint64_t prepow_s = prepow >> 32;
return (((prepow_s * prepow_s) >> 16) * postpow) >> 16;
}
```
|
|
2023-03-06 11:17:25
|
all integer arithmetic, no integer divisions
|
|
|
pshufb
|
2023-03-07 06:38:51
|
that is impressive! but have you seen https://libdivide.com/ ?
|
|
2023-03-07 06:41:02
|
in cases where you're doing a lot of integer divisions by known constants, libdivide can do >=1 divide/cycle, which is pretty hard to beat ๐
|
|
|
|
_wb_
|
2023-03-07 07:25:10
|
uint64_log2 can also be done in basically one instruction, see https://github.com/libjxl/libjxl/blob/main/lib/jxl/base/bits.h#L131
|
|
|
|
Traneptora
|
|
_wb_
uint64_log2 can also be done in basically one instruction, see https://github.com/libjxl/libjxl/blob/main/lib/jxl/base/bits.h#L131
|
|
2023-03-07 04:29:20
|
I didn't want to #ifdef for `__builtin_clz` yet
|
|
|
_wb_
uint64_log2 can also be done in basically one instruction, see https://github.com/libjxl/libjxl/blob/main/lib/jxl/base/bits.h#L131
|
|
2023-03-08 01:13:59
|
was trying to avoid this kinda garbo
|
|
2023-03-08 01:14:06
|
```c
#define hyd_fllog2__(n) (__builtin_clzll(1) - __builtin_clzll((n)|1))
#if defined(__GNUC__) || defined(__clang__)
#define hyd_fllog2(n) hyd_fllog2__(n)
#else
#ifdef _MSC_VER
#include <inttrin.h>
static inline int __builtin_clzll(unsigned long long x) {
#ifdef _WIN64
return (int)_lzcnt_u64(x);
#else
return !!unsigned(x >> 32) ? __builtin_clz((unsigned)(x >> 32)) : 32 + __builtin_clz((unsigned)x);
#endif
}
#define hyd_fllog2(n) hyd_fllog2__(n)
#else /* _MSC_VER */
static inline int hyd_fllog2(unsigned long long n) {
#define S(k) if (n >= (1ULL << k)) { i += k; n >>= k; }
int i = -(n == 0ULL); S(32); S(16); S(8); S(4); S(2); S(1); return i;
#undef S
}
#endif /* _MSC_VER */
#endif /* __GNUC__ || __clang__ */
```
|
|
|
|
_wb_
|
2023-03-08 01:38:25
|
yeah it's kind of insane there isn't a nicer solution for making good use of such cpu instructions in a portable way
|
|
|
|
Jyrki Alakuijala
|
|
afed
seems that some simpler methods can also achieve very good lossless results with fast speeds (for large photos especially), even with very little memory consumption, like HALIC based on FSEU16
<https://github.com/Cyan4973/FiniteStateEntropy>
<https://encode.su/threads/4025-HALIC-(High-Availability-Lossless-Image-Compression)>
i wonder if something like this is possible for jxl with ans?
|
|
2023-03-08 04:42:08
|
different entropy codes usually make only 1-2 % difference in density, makes me wonder what is going on here
|
|
|
|
HLBG007
|
2023-03-08 04:42:50
|
```c
static inline int uint64_log2(uint64_t n) {
int log = 0;
if (n & UINT64_C(0xFFFFFFFF00000000)) { log += 32; n >>= 32; }
if (n & UINT64_C(0xFFFF0000)) { log += 16; n >>= 16; }
if (n & UINT64_C(0xFF00)) { log += 8; n >>= 8; }
if (n & UINT64_C(0xF0)) { log += 4; n >>= 4; }
if (n & UINT64_C(0xC)) { log += 2; n >>= 2; }
if (n & UINT64_C(0x2)) { log += 1; }
return log;
}
static int64_t linearize(const int64_t srgb) {
if (srgb <= 2650)
return (srgb * INT64_C(332427809)) >> 32;
const uint64_t x = srgb + UINT64_C(3604);
const uint64_t y = x * INT64_C(1011712319);
const uint64_t z = y >> 32;
const uint64_t log = uint64_log2(z) - 20;
const uint64_t a = x << (43 - log);
const uint64_t b = ((z - UINT64_C(4290772999)) * INT64_C(1165513241)) >> 32;
const uint64_t c = a * (b + INT64_C(858993459));
return (int64_t)(c >> 32);
}
```
|
|
|
|
Traneptora
|
|
HLBG007
```c
static inline int uint64_log2(uint64_t n) {
int log = 0;
if (n & UINT64_C(0xFFFFFFFF00000000)) { log += 32; n >>= 32; }
if (n & UINT64_C(0xFFFF0000)) { log += 16; n >>= 16; }
if (n & UINT64_C(0xFF00)) { log += 8; n >>= 8; }
if (n & UINT64_C(0xF0)) { log += 4; n >>= 4; }
if (n & UINT64_C(0xC)) { log += 2; n >>= 2; }
if (n & UINT64_C(0x2)) { log += 1; }
return log;
}
static int64_t linearize(const int64_t srgb) {
if (srgb <= 2650)
return (srgb * INT64_C(332427809)) >> 32;
const uint64_t x = srgb + UINT64_C(3604);
const uint64_t y = x * INT64_C(1011712319);
const uint64_t z = y >> 32;
const uint64_t log = uint64_log2(z) - 20;
const uint64_t a = x << (43 - log);
const uint64_t b = ((z - UINT64_C(4290772999)) * INT64_C(1165513241)) >> 32;
const uint64_t c = a * (b + INT64_C(858993459));
return (int64_t)(c >> 32);
}
```
|
|
2023-03-08 05:05:59
|
unfortuantely this does not work
|
|
2023-03-08 05:06:24
|
test it by doing this:
|
|
2023-03-08 05:06:27
|
```c
int main(void) {
for (int64_t i = 0; i < 65536; i += 257) {
fprintf(stdout, "%ld: %ld\n", i, linearize(i));
}
return 0;
}
```
|
|
2023-03-08 05:06:55
|
you'll get a lot of seemingly random numbers
|
|
|
|
HLBG007
|
2023-03-08 05:27:42
|
```c
#if defined(_MSC_VER)
#include <intrin.h>
#elif defined(__GNUC__) && !defined(__APPLE__)
#include <x86intrin.h>
#endif
static inline int uint64_log2(uint64_t n) {
#define S(k) if (n >= (UINT64_C(1) << k)) { i += k; n >>= k; }
int i = -(n == 0); S(32); S(16); S(8); S(4); S(2); S(1); return i;
#undef S
}
static int64_t linearize(const int64_t srgb) {
if (srgb <= 2650)
return (srgb * UINT64_C(332427809)) >> 32;
uint64_t prepow = ((srgb + 3604) * UINT64_C(4071059048));
uint64_t logval;
#if defined(_MSC_VER)
unsigned long msb;
_BitScanReverse64(&msb, prepow);
logval = msb + 1;
#elif defined(__GNUC__) && !defined(__APPLE__)
logval = 63 - __builtin_clzll(prepow);
#else
logval = uint64_log2(prepow);
#endif
const uint64_t prepow_d = (prepow >> (logval - 20)) & ~(~UINT64_C(0) << 20) | ((0x3FE + logval - 47) << 20);
uint64_t postpow_d;
#if defined(_MSC_VER)
postpow_d = __umulh(410, prepow_d - INT64_C(1072632447)) + INT64_C(1072632447);
#elif defined(__GNUC__) && !defined(__APPLE__)
postpow_d = (((prepow_d - INT64_C(1072632447)) * 410) >> 10) + INT64_C(1072632447);
#else
postpow_d = ((((prepow_d - INT64_C(1072632447)) * 410) >> 10) + INT64_C(1072632447));
#endif
const uint64_t postpow = ((postpow_d & ~(~UINT64_C(0) << 20)) | (UINT64_C(1) << 20))
>> (1027 - ((postpow_d >> 20) & 0x3FF));
const uint64_t prepow_s = prepow >> 32;
return (((prepow_s * prepow_s) >> 16) * postpow) >> 16;
}
```
|
|
|
katya
|
2023-03-08 06:29:57
|
xyb and oklab are both perceptually uniform, but is there something that makes xyb more suitable for compression?
My intuition is that both are suitable for compression, because quantisation error is less noticeable when perceptually uniform, but oklab never lists compression as an application. I was wondering about how xyb was chosen for jpeg-xl (other than being already proven in pik, which is a very valid reason)
[Also, hi folks!]
|
|
|
|
jonnyawsom3
|
2023-03-08 06:49:16
|
I did a bit of looking around and at the bottom this mentions XYB, something to read until the experts arrive :P
https://raphlinus.github.io/color/2021/01/18/oklab-critique.html
|
|
|
|
katya
|
|
I did a bit of looking around and at the bottom this mentions XYB, something to read until the experts arrive :P
https://raphlinus.github.io/color/2021/01/18/oklab-critique.html
|
|
2023-03-08 07:08:41
|
Thank you! That's the article that motivated me to ask this question! It says at the end that xyb's main motivation is image compression.
Here is another article to add to your arsenal: https://github.com/svgeesus/svgeesus.github.io/blob/master/Color/OKLab-notes.md `:D`
|
|
|
|
yoochan
|
|
I did a bit of looking around and at the bottom this mentions XYB, something to read until the experts arrive :P
https://raphlinus.github.io/color/2021/01/18/oklab-critique.html
|
|
2023-03-08 07:46:45
|
funny videzo liked inside the article : https://www.youtube.com/watch?v=xAoljeRJ3lU
|
|
|
|
Traneptora
|
2023-03-09 12:43:15
|
how much efficiency would you lose if each Group was its own Frame
|
|
2023-03-09 12:44:26
|
im worried about seams along tile boundaries
|
|
|
|
katya
|
|
yoochan
funny videzo liked inside the article : https://www.youtube.com/watch?v=xAoljeRJ3lU
|
|
2023-03-09 03:44:24
|
"by a process involving lightning" ๐ ๐ this is excellent
|
|
|
|
_wb_
|
|
Traneptora
im worried about seams along tile boundaries
|
|
2023-03-09 07:21:43
|
yes, gaborish and epf would stop at group boundaries if you do one frame per group...
|
|
|
|
Demiurge
|
2023-03-09 07:54:26
|
I notice some websites, like wescom.org, are using palette-PNG instead of JPEG for photographics. This seems to be done because the palette method is superior at retaining fine detail and texture and superior at representing colors accurately, ironically enough, when a good dithering algorithm and palette-selection algorithm are used.
|
|
2023-03-09 07:55:10
|
I feel like it's some sort of missed opportunity.
|
|
2023-03-09 07:57:11
|
because something that all lossy formats struggle with, including JXL, is retaining fine details and textures, and retaining the original color without altering and changing the color to something different.
|
|
2023-03-09 07:57:26
|
This rarely happens with pngquant for example
|
|
2023-03-09 07:57:53
|
jxlquant when? :)
|
|
2023-03-09 07:58:55
|
properly applied dithering looks a lot better than smudging and blurring and color-changing.
|
|
2023-03-09 07:59:09
|
a LOT better.
|
|
2023-03-09 08:00:51
|
It is better for details and information to be slightly altered but distinguishable, rather than for them to disappear completely and be completely unintelligible.
|
|
2023-03-09 08:01:16
|
It is better for color to look grainy than for it to be a completely different hue.
|
|
|
|
Traneptora
|
|
_wb_
yes, gaborish and epf would stop at group boundaries if you do one frame per group...
|
|
2023-03-09 02:21:58
|
although my only solution to this is to buffer an entire LF group's output, and even then there'd be seams at the LF group boundaries
|
|
|
|
Jyrki Alakuijala
|
2023-03-09 02:21:58
|
jpeg xl has the delta palettization which tries to answer that problem in a more elegant way
|
|
|
|
Traneptora
|
2023-03-09 02:22:44
|
I'm wondering if I disable gaborish and increase the quality for varblocks along tile boundaries if I can avoid seams
|
|
|
|
Jyrki Alakuijala
|
2023-03-09 02:23:27
|
I'm looking into improving detail preservation right now and it is rather difficult -- we need to make gaborish closer to identity, but making it so will increase ringing in usual situations -- probably making gaborish non-linear would be a good option, but it will be a complex beast to tame at encoding time
|
|
|
|
Traneptora
|
|
Jyrki Alakuijala
I'm looking into improving detail preservation right now and it is rather difficult -- we need to make gaborish closer to identity, but making it so will increase ringing in usual situations -- probably making gaborish non-linear would be a good option, but it will be a complex beast to tame at encoding time
|
|
2023-03-09 02:24:02
|
gaborish is not truly invertible, right? i.e. is the inverse an approximate inverse?
|
|
|
|
Jyrki Alakuijala
|
|
I did a bit of looking around and at the bottom this mentions XYB, something to read until the experts arrive :P
https://raphlinus.github.io/color/2021/01/18/oklab-critique.html
|
|
2023-03-09 02:24:43
|
I worked with Raph on fonts/WOFF2 -- it is fun to now be in the same area again (colorspaces)
|
|
|
|
_wb_
|
|
Traneptora
although my only solution to this is to buffer an entire LF group's output, and even then there'd be seams at the LF group boundaries
|
|
2023-03-09 02:26:36
|
is buffering the bitstream that problematic? at 1 bpp you can do 8 megapixels per megabyte of bitstream...
|
|
|
|
Traneptora
|
2023-03-09 02:28:27
|
I'm trying to stay in very low memory territory
|
|
2023-03-09 02:29:39
|
the goal of libhydrium is to be low-memory high-quality and fast so ideal for use in things like cameras
|
|
2023-03-09 02:29:50
|
or other lightweight devices
|
|
|
|
Jyrki Alakuijala
|
2023-03-09 02:30:33
|
how low memory?
|
|
2023-03-09 02:30:53
|
libjxl-tiny might have some ideas towards that
|
|
|
|
Traneptora
|
2023-03-09 02:31:02
|
less than a megabyte ideally
|
|
2023-03-09 02:31:09
|
including the binary
|
|
2023-03-09 02:31:16
|
although that might not be possible
|
|
|
|
Jyrki Alakuijala
|
2023-03-09 02:31:20
|
is it just low memory or also low complexity (so that it is less transistors)
|
|
|
|
Traneptora
|
2023-03-09 02:31:55
|
well ideally also low-complexity, like I won't be clustering the HF block contexts, I'll be using the default clustering
|
|
2023-03-09 02:32:01
|
a lot of use default options
|
|
2023-03-09 02:32:06
|
and hardcode those in
|
|
|
|
_wb_
|
2023-03-09 02:32:16
|
well you could write a malformed container jxl file which has two `jxlp` boxes in the wrong order (but they have a signaled index field, so it would only be a matter of reshuffling the boxes afterwards to turn it into a conforming container jxl file), where all the data sections go in the first box (with index 1) and the frameheader/toc go in the second box (with index 0)
|
|
|
|
Jyrki Alakuijala
|
2023-03-09 02:32:23
|
for decoding the lowest memory solution would be to write a decoder that decodes a single pixel at one run -- then just repeat ๐
|
|
|
|
Traneptora
|
|
_wb_
well you could write a malformed container jxl file which has two `jxlp` boxes in the wrong order (but they have a signaled index field, so it would only be a matter of reshuffling the boxes afterwards to turn it into a conforming container jxl file), where all the data sections go in the first box (with index 1) and the frameheader/toc go in the second box (with index 0)
|
|
2023-03-09 02:32:40
|
I'd rather not write non-compliant files <:kek:857018203640561677>
|
|
|
|
Jyrki Alakuijala
|
2023-03-09 02:32:58
|
libjxl-tiny seems like a good starting point for low complexity/low memory
|
|
|
|
Traneptora
|
2023-03-09 02:33:11
|
one 256x256 int16 tile in XYB already takes up 400k of ram
|
|
2023-03-09 02:33:17
|
so I have a tight budget
|
|
2023-03-09 02:33:22
|
not sure how big libjxl-tiny is tho
|
|
|
|
Jyrki Alakuijala
|
2023-03-09 02:33:34
|
especially its prefix-only coding with only 8x8 dcts
|
|
2023-03-09 02:33:47
|
libjxl-tiny is tinier than libjxl
|
|
|
|
Traneptora
|
2023-03-09 02:34:02
|
most likely will be 8x8 DCTs, jon suggested that I use ANS but encode the residuals in reverse order
|
|
2023-03-09 02:34:09
|
like bottom to top, right to left
|
|
2023-03-09 02:34:19
|
rather than encode in forward order and reverse them
|
|
|
|
_wb_
|
|
Traneptora
I'd rather not write non-compliant files <:kek:857018203640561677>
|
|
2023-03-09 02:34:29
|
the non-compliant file would be temporary, the final output would have the jxlp boxes swapped or merged into a jxlc box
|
|
|
|
Traneptora
|
2023-03-09 02:34:30
|
it doesn't particularly matter though as the TOC requires me to buffer each passgroup
|
|
|
|
veluca
|
2023-03-09 02:34:44
|
I feel slightly obligated to point you to this: https://github.com/veluca93/libjxl/blob/fmjxl/experimental/fmjxl/fmjxl.cc
|
|
|
Traneptora
it doesn't particularly matter though as the TOC requires me to buffer each passgroup
|
|
2023-03-09 02:35:10
|
also, not really, you can write a blank TOC in advance and then edit in actual sizes afterwards
|
|
2023-03-09 02:35:18
|
at least if you don't multithread
|
|
|
|
Traneptora
|
2023-03-09 02:35:32
|
assuming I'm writing to seekable medium
|
|
|
|
veluca
|
2023-03-09 02:35:39
|
then you can't
|
|
2023-03-09 02:35:41
|
๐
|
|
|
|
Traneptora
|
2023-03-09 02:35:50
|
this encoder is a streaming encoder, I'm writing it with a zlib-like interface
|
|
|
|
veluca
|
2023-03-09 02:35:51
|
or otherwise ๐
|
|
2023-03-09 02:36:01
|
yeah, you can't do that then
|
|
|
|
_wb_
|
2023-03-09 02:36:11
|
i don't think it's very important to be able to encode jxl straight to tape
|
|
|
|
veluca
|
2023-03-09 02:36:16
|
might have been better to prepend each section with its size
|
|
|
|
_wb_
|
2023-03-09 02:36:27
|
or whatever other non-seekable medium
|
|
|
|
Traneptora
|
2023-03-09 02:36:52
|
maybe not, but those are sort of the design restrictions I'm using
|
|
2023-03-09 02:37:11
|
I could ask the caller to provide a buffer that's as large as the input provided
|
|
2023-03-09 02:37:29
|
as iirc vardct images are always smaller than the input
|
|
2023-03-09 02:37:41
|
even at d=0.01 or something
|
|
|
|
_wb_
|
|
veluca
might have been better to prepend each section with its size
|
|
2023-03-09 02:37:51
|
nah, having the toc in the beginning is very nice if we ever want to do responsive images
|
|
|
|
Traneptora
|
2023-03-09 02:38:01
|
^ yea having written a decoder I like having a TOC
|
|
|
|
veluca
|
|
_wb_
nah, having the toc in the beginning is very nice if we ever want to do responsive images
|
|
2023-03-09 02:38:02
|
how so?
|
|
|
|
Traneptora
|
2023-03-09 02:38:29
|
well for example if you want to locate a particular pass group, TOC means you don't need to scan the whole file to find it
|
|
|
|
veluca
|
2023-03-09 02:38:45
|
mh ok yes, makes sense for cropped decode
|
|
|
|
_wb_
|
2023-03-09 02:39:08
|
the toc allows computing the prefix offset needed for lower-res previews or the set of ranges needed for crops
|
|
|
|
Traneptora
|
2023-03-09 02:39:22
|
I might argue that the TOC should have occurred at the end of the frame though
|
|
2023-03-09 02:39:37
|
kinda like how ZIP puts its archive at the end of the file
|
|
2023-03-09 02:39:47
|
or MOOV atom is at the end of a `.mov` file
|
|
|
|
_wb_
|
2023-03-09 02:39:49
|
toc at the end means the decoder needs a seekable medium
|
|
|
|
Traneptora
|
2023-03-09 02:40:03
|
Not necessarily, a straight up decoder can ignore the TOC and decode everything in order
|
|
|
|
_wb_
|
2023-03-09 02:40:05
|
web delivery is by default streaming
|
|
|
|
Traneptora
|
2023-03-09 02:40:22
|
a non-progressive decoder, that is
|
|
|
|
_wb_
|
2023-03-09 02:40:28
|
yeah if you don't care about decoding in parallel you could ignore the toc
|
|
|
|
Traneptora
|
2023-03-09 02:40:38
|
ah right decoding in parallel, forgot about that
|
|
2023-03-09 02:40:54
|
I was just thinking of how ZIP putting the archive index at the end is super useful
|
|
2023-03-09 02:41:25
|
well technically with mov/mp4 the MOOV box is at the end by default but a second pass on a seekable medium can move it to the front of the file
|
|
|
|
_wb_
|
2023-03-09 02:41:36
|
no I think we did the right thing putting the toc where we put it, it's just not convenient for streaming encoders but I think that's a reasonable tradeoff
|
|
|
|
Traneptora
|
2023-03-09 02:41:42
|
that's fair
|
|
|
|
veluca
|
|
_wb_
yeah if you don't care about decoding in parallel you could ignore the toc
|
|
2023-03-09 02:41:43
|
even if you don't, reading the size doesn't take nearly as long as reading the whole group so you can still parallelize
|
|
|
|
Traneptora
|
2023-03-09 02:42:04
|
since placing emphasis on decode convenience seems like a better priority for adoption than encode convenience
|
|
2023-03-09 02:42:38
|
TOC at the front lets you find a frame boundary immediately upon decoding a TOC, which is also nice. so you can read a frame header, skip a frame, etc.
|
|
2023-03-09 02:43:21
|
biggest design weakness of current codestream design is that parsing the file requires an entropy decoder
|
|
2023-03-09 02:43:34
|
ICC/permuted TOC can do that
|
|
|
|
_wb_
|
|
veluca
even if you don't, reading the size doesn't take nearly as long as reading the whole group so you can still parallelize
|
|
2023-03-09 02:44:41
|
yes, but for cropped decode in a huge image, you might need to do lots of seeking, which might be nearly as expensive as reading the whole file considering the block sizes of storage media (could be that sections are not much more than one block)
|
|
|
Traneptora
biggest design weakness of current codestream design is that parsing the file requires an entropy decoder
|
|
2023-03-09 02:46:07
|
yes, I agree, we should have added a size field to the icc encoding so it can be easily skipped, and represent toc permutations in a simpler way
|
|
|
|
Traneptora
|
2023-03-09 02:46:52
|
~~there technically is a size field but it's for the number of tokens, so it doesn't help much~~
|
|
|
|
veluca
|
|
Traneptora
~~there technically is a size field but it's for the number of tokens, so it doesn't help much~~
|
|
2023-03-09 02:47:22
|
yep
|
|
2023-03-09 02:47:33
|
that one was a bit of a mistake
|
|
|
_wb_
yes, but for cropped decode in a huge image, you might need to do lots of seeking, which might be nearly as expensive as reading the whole file considering the block sizes of storage media (could be that sections are not much more than one block)
|
|
2023-03-09 02:48:06
|
haha I remember we had many similar conversations years ago
|
|
|
|
Traneptora
|
2023-03-09 02:48:19
|
ICC is typically prefix coded so it actually is necessary but still
|
|
|
|
_wb_
|
2023-03-09 02:48:59
|
Historically we first had permutations for coeff reordering, so entropy coding it made sense since that is something quite deeply buried in the codestream anyway, and it can be quite some data so entropy coding helps. Then later we decided to allow the toc (or rather the section order) to be permuted too, and just used the permutation encoding we already had.
|
|
|
|
Traneptora
|
2023-03-09 02:50:15
|
hm, makes sense
|
|
|
|
veluca
|
2023-03-09 02:51:51
|
ICC was historically encoded using Brotli
|
|
|
|
_wb_
|
2023-03-09 02:52:02
|
it's still a mistake, having a file structure that can be parsed without a full entropy decoder would have been nice and it would only add a few bytes in the cases with permuted toc or icc (which can be avoided if you care about those few bytes)
|
|
|
|
veluca
|
2023-03-09 02:52:04
|
(which also was self-terminating IIRC)
|
|
|
|
_wb_
|
2023-03-09 02:52:21
|
but it is what it is
|
|
|
|
veluca
|
2023-03-09 02:52:31
|
we decided not to require all decoders to include the brotli static dictionary
|
|
|
|
Traneptora
|
2023-03-09 02:52:40
|
yea, that makes sense
|
|
2023-03-09 02:52:51
|
especially since brotli static dictionary is optimized for text iirc
|
|
|
|
veluca
|
2023-03-09 02:52:56
|
yup
|
|
2023-03-09 02:53:04
|
ICC can contain a fair bit of text but...
|
|
2023-03-09 02:53:18
|
it also used to be that we could use Brotli itself as an entropy coder
|
|
2023-03-09 02:53:34
|
but we replaced that for doing LZ77 directly within ANS/Huffman
|
|
|
|
Traneptora
|
2023-03-09 02:53:58
|
well isn't strictly speaking lz77 not an entropy coder but a deduplicator
|
|
2023-03-09 02:54:12
|
like a more advanced version of RLE
|
|