JPEG XL

2021-02-13 03:27:11	to me -s 4- q 99.2 with 0.3.0 is a minimal change to the original screenshot
2021-02-13 03:27:32	so the applications don't display metadata with current djxl
2021-02-13 03:27:38	or current cjxl?
2021-02-13 03:28:11	with 0.3.1 i used -s 7 -q 15 or another setings wait

Crixis

2021-02-13 03:28:13

are you encoding or trasconding? you cant set quality on trascoding jpg

fab

2021-02-13 03:28:52	png of galaxy s4 old phone
2021-02-13 03:29:15	but with 0.3.2 it inflates less file size
2021-02-13 03:29:29	but i used different settings -s 7 -q 15

Crixis

2021-02-13 03:30:42

idk if now cjxl mantain png metadata on encode. Final version will do it

fab

2021-02-13 03:30:52	i used -s 3 -d 8.08
2021-02-13 03:31:11	on some images
2021-02-13 03:31:25	but all screenshots not web images
2021-02-13 03:31:37	web images need a better encoder
2021-02-13 03:31:45	most images lossless transcoded

Crixis

2021-02-13 03:31:51	-d 8 is very bad quality
2021-02-13 03:31:54	why?
2021-02-13 03:32:41	the max bad quality with good econding is -d 6 for me

fab

2021-02-13 03:33:27	ah fb images mostly advertisement
2021-02-13 03:35:20	like before version i got 4,5 mb to 450 kb with -q 68.8 equivalent
2021-02-13 03:35:31	now i have 112 kb images max 12 mpx
2021-02-13 03:38:03	obviously with 0.3.0 at -s 4 99.2 you get less editing
2021-02-13 03:38:11	way better less color filtering
2021-02-13 03:38:14	more original colors
2021-02-13 03:38:22	but for fb images is ok but you need 0.3.1

_wb_

	Crixis idk if now cjxl mantain png metadata on encode. Final version will do it
2021-02-13 03:38:27	Atm it strips everything from png input except color space info (icc profile or png chunks related to it)
2021-02-13 03:39:21	We have exif and xmp storage defined in the file format, just cjxl is ignoring it for now
2021-02-13 03:39:42	In the end we should have an option to give you a choice in what to keep or strip

Crixis

	fab but for fb images is ok but you need 0.3.1
2021-02-13 03:41:17	on very low quality 0.3.1 encoder is better, the most internet sites go above 1 bpp for images, in this area jxl shine

fab

2021-02-13 03:41:22	thanks
2021-02-13 03:41:54	but -s 4 -q 99.2 works better on 0.3.0
2021-02-13 03:42:03	on 0.3.1 the colour get filtered more
2021-02-13 03:42:30	it looks similar to me as -s 8 -q 96
2021-02-13 03:42:40	for screenshots of galaxy s4
2021-02-13 03:42:53	no better fidelity in the colours
2021-02-13 03:43:24	the problem using 0.3.0 is that i can't use jxl as input

Crixis

2021-02-13 03:43:51	you can use djxl to go png
2021-02-13 03:44:13	then use the png in cjxl

fab

2021-02-13 03:44:30	ok
2021-02-13 03:57:39	will we see a video codec based on butteraugli
2021-02-13 03:57:51	with technologies from MPEG AOM patents
2021-02-13 03:58:24	or nobody would work on that cause they don't want to lose job or hire laywers
2021-02-13 03:58:30	for nothing
2021-02-13 03:58:43	i heard that isn't efficient as VMAF is best for video
2021-02-13 03:58:56	or one of the best
2021-02-13 03:59:06	like a jxv

BlueSwordM

2021-02-13 03:59:48

No, but there have been mentions of butteraugli at daala Watercooler meetings.

fab

2021-02-13 04:00:21	i think they don't want to lose job or tourim ebrahim
2021-02-13 04:00:38	because they said in this group the leaders are both part of MPEG and JPEG ITU
2021-02-13 04:00:43	even if they are open source
2021-02-13 04:00:58	patents is a serious thing

_wb_

2021-02-13 04:01:05

I think you are confusing various things

fab

2021-02-13 04:01:07	and codec is difficult to develop
2021-02-13 04:01:20	and buttruagli isn't efficient for video
2021-02-13 04:01:26	and jxl is a image codec
2021-02-13 04:01:29	not video codec

BlueSwordM

BlueSwordM No, but there have been mentions of butteraugli at daala Watercooler meetings.

2021-02-13 04:02:14

They did say that from their short testing, butteraugli seems to be better suited than VMAF for high quality video comparisons. The trick about VMAF is that it's more sensitive to artifacts than pure quality, and the models that are openly available aren't very sensitive to noise and banding. So, because of this, they'd love to get butteraugli in Rust, but of course, that would require a lot of work and whatnot. In the meantime, some daala devs did say that I should be looking at the strengths/weaknesses of rav1e vs aomenc-av1 by using butteraugli features on intra images and screenshots from video encodes.

fab

2021-02-13 04:02:23	anyway in a image codec i see
2021-02-13 04:02:29	change in color space, noise, colour, image quality
2021-02-13 04:02:54	likely a normal user see similar thing
2021-02-13 04:02:59	or even less
2021-02-13 04:03:21	developers see metrics, fidelity, speed, appeal
2021-02-13 04:03:53	blocking
2021-02-13 04:03:59	artifacts;
2021-02-13 04:04:36	i was just having a conversation with crixis
2021-02-13 04:05:19	not talking about technical details of jpeg xl

_wb_

2021-02-13 04:06:59

VMAF as far as I understand uses statistical approaches similar to no-reference metrics - which might be a good idea if you want to measure appeal, but probably not if you want to measure fidelity. It has that, and then some of the usual simple metrics like psnr and ssim in non-perceptual color spaces, and then basically computes some weighted sum of those submetrics to get something that correlated well with some subjective low bpp experiments that were once performed (using simpler video codecs, most likely mostly h264)

fab

2021-02-13 04:07:53

i don't want too spoilers. good to know

BlueSwordM

2021-02-13 04:12:48

Now, the question is. Rust or Python butteraugli interface when? <:kekw:808717074305122316>

Scope

2021-02-13 04:17:13

Btw, JXL butteraugli is quite different and better tuned than the standalone version

fab

2021-02-13 04:18:38	just use jxl 0.3.0 butteraugli
2021-02-13 04:18:51	i think it could work even for 0.3.1
2021-02-13 04:18:52	or not

member102

2021-02-13 08:58:45

_wb_ The cheap shot at Duda and RANS is disappointing. You should know better.

_wb_

2021-02-13 09:08:13	What cheap shot?
	_wb_ rANS itself is not that revolutionary, it is basically just the LIFO version of range encoding (which is basically the same thing as arithmetic coding), which makes decode faster at the expense of requiring the encoder to buffer.
2021-02-13 09:09:16	This?
2021-02-13 09:10:40	Didn't mean to diminish Duda's contribution, just wanted to bring a bit of nuance to that article
2021-02-13 09:14:23	At least if the translation is somewhat accurate, that article seemed rather hyperbolic: "Currently, computers around the world communicate more and more often thanks to the Polish method of Dr. Jarosław Duda, a scientist from Dębica. ANS coding has become the language of the world electronics today, used by the largest technological giants in the world, including Apple, Facebook, Google. It is also used by the newest image file format - JPEG XL. We are talking about the virtual revolution with the author of this revolution."

Jyrki Alakuijala

2021-02-13 09:18:22	for an exponent division is easy -- it transforms to subtraction
2021-02-13 09:18:45	the more bits are in exponent, the easier multiplication and division become for floating point implementations

Scope

2021-02-13 09:19:40

I guess people also come from the responses in this thread: <https://encode.su/threads/3564-JXL-version-0-3-released> But, yes, in the article it is hyperbolic, although this is the journalism and need to better and brighter present anything to ordinary people, I also think it is a pride that some of their own work is used in many popular things

_wb_

2021-02-13 09:22:34

Ah, hadn't seen that thread yet

member102

2021-02-13 09:23:14

This is a cheap shot: "Anyway, it's a bit weird to see that Duda guy give interviews where he makes it seem like he is the genius behind all the new compression codecs of the past decade.". You should understand that the university he works at would push this kind of article as an advertisement. Of course it is hyperbolic (to the point of being comical), but are those the words of Duda or the reporter ?

_wb_

2021-02-13 09:24:00

Normally when you get interviewed, you get a chance to see if the words they put in your mouth are OK

member102

2021-02-13 09:25:29

Assumptions ... Anyway, attacking the article is fair but going ad hominen is NOT the right approach IMO.

_wb_

2021-02-13 09:25:31

But ok, I don't understand Polish so I may have missed some nuances, and I do understand that there's a trade-off to be made between accuracy and being exciting and encouraging for potential students

member102

2021-02-13 09:25:55

IS NOT the right approach I meant to write ....

_wb_

2021-02-13 09:26:07

Yes, that was wrong of me

member102

2021-02-13 09:26:29

anyway ... moving on to better topics ...

_wb_

2021-02-13 09:27:32	This is just a discord chat though, not something I would say when speaking for a larger audience
2021-02-13 09:29:24	I wonder what is wrong with the comparison of ANS being a LIFO version of range coding though

Pieter

2021-02-13 09:31:39	At least at some level of abstraction, I think that's correct. Range coding is adding entropy into the high bits of a numbers; ANS is adding it to the low bits.
2021-02-13 09:33:23	I may be confusing range coding with arithmetic coding here actually. I always forget which is which (I know they're equivalent).

member102

2021-02-13 09:34:59

First your comparison would only apply to RANS not ANS in general. Second, there is only one state to track instead of 2 range bounds, third the fractional bits are computed differently, fourth it is possible to interleave streams. With all that said, one can write a RANS codec that looks very similar to a range codec. So, yes, there are similarities.

_wb_

2021-02-13 10:10:05	Range coder: https://github.com/FLIF-hub/FLIF/blob/master/src/maniac/rac.hpp#L43
2021-02-13 10:10:33	`return (range * b12 + 0x800) >> 12`
2021-02-13 10:11:10	rANS: https://gitlab.com/wg1/jpeg-xl/-/blob/master/lib/jxl/dec_ans.h#L204
2021-02-13 10:11:40	`state_ = symbol.freq * (state_ >> ANS_LOG_TAB_SIZE) + symbol.offset;`
2021-02-13 10:13:54	Main difference: do you shift first or multiply first

member102

2021-02-13 10:14:55

Yes, this is why I wrote that the fractional bits are computed differently.

_wb_

2021-02-13 10:31:26	It's a small difference code-wise, but for decode speed rANS is better than range coding indeed
2021-02-13 10:32:33	Anyway, didn't mean to diss Jarek Duda, just thought the article was a bit silly.
2021-02-13 10:33:44	Pretty cool that he apparently reads this discord

member102

2021-02-13 11:38:40

FWIW I am not affiliated in any way with Duda or his employer but I think it is cool they did not attempt to patent ANS to oblivion (like IBM did back in the days with arithmetic coding).

Deleted User

2021-02-14 03:47:54

With patents it's actually the opposite: Google wanted to patent ANS behind his back, but fortunately the request was rejected by the patent office.

_wb_

2021-02-14 07:06:06

I don't know what Google's intentions were there, but there's a difference between patenting something with the aim of making it available royalty-free with a defensive license, and patenting something with the aim of extracting royalties from it.

Deleted User

2021-02-14 07:08:20

sometimes the best way to protect your work is to patent it unfortunately otherwise it makes room for others to patent it first and will become much harder to prove you had prior art

Pieter

2021-02-14 07:11:55	sometimes the best way to make sure nobody ever uses your work is to patent it (and license it restrictively)
2021-02-14 07:12:35	plenty of examples in cryptography, were inferior schemes became standards as workarounds for the obvious best solution that was patented

Deleted User

2021-02-14 07:15:23

Only decades later will the patents expire and by that time it may not even be relevant.. it can be really unfortunate to progress

_wb_

2021-02-14 07:21:20

Patents do not enable innovation, they slow down innovation. The main thing they enable, are lawyers and trolls.

lonjil

2021-02-14 07:24:19

Note that you don't have to patent stuff to make it safe.

Pieter

2021-02-14 07:24:31

I do believe using the patent system to protect against itself is sometimes warranted. But that's only necessary because the system exists.

lonjil

2021-02-14 07:25:30

Public prior art makes something unpatentable by other parties. You can also register an innovation with the patent office as something they should know about without it actually being a patent. Then someone else also can't patent it.

Pieter

2021-02-14 07:25:49

E.g. defensive patent licenses that permit free and irrevocable use of a patent, except when you yourself sue the owner for other patents.

lonjil

2021-02-14 07:26:18

Yeah, defensive patents don't defend the innovation, they defend from attacks with patents on other innovations.

Pieter

2021-02-14 07:26:51	@Lonnie Yes, but that doesn't prevent you from being sued for probably dozens of other unrelated patents that you unknowningly violate when developing nontrivial software.
2021-02-14 07:27:14	But I don't think we disagree.

lonjil

2021-02-14 07:27:21

yeah

_wb_

2021-02-14 07:35:54	https://www.april.org/en/rothschild-patent-imaging-vs-gnome-a-particular-patent-dispute-resolved-no-case-law-established-0
2021-02-14 07:36:30	That patent troll just tried to get money from Cloudinary last week
2021-02-14 07:36:45	They're just trying anyone
2021-02-14 07:37:35	The letter they sent still had some occurrences of "Netflix" that hadn't been replaced with "Cloudinary" yet
2021-02-14 07:38:41	But some patent trolls are more effective
2021-02-14 07:38:52	Like Nokia

fab

2021-02-14 08:44:54	webp2 q 37.9 - q 89 - q20 jxl 0.3.0 -s 4 -q 99.2 jxl 0.3.1 -s3 -d 8.08 -s 8 -q 96 -s 7 -d 1 -s 7 -q 15 -s 8 -q 68.8 lossless jpeg recompressor
2021-02-14 08:45:38	like in jpeg xl is difficult to choose appropriate quality
2021-02-14 08:47:23	jpeg xl the good is that it works for range of speeds
2021-02-14 08:47:58	but i haven't looked at phoronix tests <@!111445179587624960>
2021-02-14 08:51:21	webp2 q 37.9 to me it doesn't look that good
2021-02-14 08:51:30	and also efficiency is ba
2021-02-14 08:51:37	40 kb files you get
2021-02-14 08:51:58	with a photo of hamburger from quora
2021-02-14 08:52:23	but q89 and q20 is where webp2 has better appeal
2021-02-14 08:53:03	the software of jpeg xl is stable, quantizer works for every type of image (image indipendent), but wasm encoder is too slow on sse4.1
2021-02-14 08:53:22	still wp2 is faster sometimes
2021-02-14 08:54:18	like wp2 effort 5 is it higher effort than jpeg xl speed 5? <@!111445179587624960>

_wb_

	fab like in jpeg xl is difficult to choose appropriate quality
2021-02-14 09:01:47	Just default should be good

bonnibel

2021-02-14 11:06:38	didn't some of the companies involved in mpeg claim they had like. a thousand patents av1 infringed upon
2021-02-14 11:07:04	and are now selling licenses to anyone who'll believe them while aomedia just ignores them

_wb_

2021-02-14 11:11:09

You mean https://www.sisvel.com/licensing-programs/audio-and-video-coding-decoding/video-coding-platform/license-terms/av1-license-terms ?

bonnibel

2021-02-14 11:11:54

Yeah Ah, apparently it was a bunch of companies involved with mpeg-la, which has no relation(?) to mpeg(?)

lonjil

2021-02-14 11:25:20

correct

Jyrki Alakuijala

	fab but does really beat webp2?
2021-02-14 02:09:41	WebP2 probably needs to beat JPEG XL. Currently WebP2 looks like 10x slower to encoder for and has slightly worse looking results at normally used internet quality.
	fab webp was a revolution
2021-02-14 02:11:56	WebP had three innovations: VP8 format, WebP lossless format and a great photography implementation for VP8 format. People responsible of VP8 format went further and built AVIF, people responsible for WebP lossless format (that's me) went further and built JPEG XL. WebP2 is designed by people who build a great photography encoder for VP8, but have no previous success in designing image formats. It is their first attempt.
2021-02-14 02:16:13	WebP 1 is a pretty good solution, but a bit aged -- it wasn't designed to be future proof. Particularly, it doesn't do progressive, HDR well, high quality images, lossy YUV444, 16 bit lossless, and images of dimension 16384 or more. I don't know which one is a more serious fault -- the lack of HDR or the lack of progression, but both are pretty serious problems. Already today some web consultants recommend staying with progressive JPEG instead of moving to WebP.

fab

2021-02-14 02:16:19	yes as i said only q89 and q20 looks decent
2021-02-14 02:16:22	to me
2021-02-14 02:16:37	at other options i don't see reason why not prefer jpeg xl
2021-02-14 02:16:54	jpeg xl has also floating blocks in the decoding

Jyrki Alakuijala

2021-02-14 02:16:58	are you comparing WebP against modular or vardct jxl ?
2021-02-14 02:17:30	yes for floating blocks -- but they are a very small detail and neither project actually uses them now I think

fab

2021-02-14 02:17:46	like for encoding person
2021-02-14 02:17:54	not photography

Jyrki Alakuijala

2021-02-14 02:17:55	I'm not sure but I believe that fast WebP2 coding just goes for 16x16 dcts
2021-02-14 02:18:12	(based on having seen a cpu profile of it)

fab

2021-02-14 02:18:21	photos of hambuger was only the one i used for photography
2021-02-14 02:18:30	i'm not expert
2021-02-14 02:18:35	sorry
2021-02-14 02:18:54	i like more jpeg xl

Jyrki Alakuijala

2021-02-14 02:18:57

both formats (and AVIF, too) have a lot of options for further optimization

fab

2021-02-14 02:19:13

it works at different qualities

Jyrki Alakuijala

2021-02-14 02:19:16	I'm currently pushing jpeg xl vardct quality in low bpp areas
2021-02-14 02:19:32	it requires some more care because jpeg xl doesn't filter as strongly
2021-02-14 02:19:57	pushing to larger transforms can very easily start to exhibit terrible ringing -- so I need to find the best heuristics for that, not yet quite there ...
2021-02-14 02:20:09	but I have ideas and 77 % working prototypes

Scope

2021-02-14 02:22:26

What is the average bpp of various previews (YouTube, app stores, etc.)? I think first of all WebP v2 is tuned for this (because YouTube, even only with its traffic with preview images, exceeds all traffic from other image hosting sites)

_wb_

2021-02-14 02:23:25

What is this "great photography encoder for VP8"?

Jyrki Alakuijala

2021-02-14 02:25:03	libwebp
2021-02-14 02:25:17	it was terrible in 2010 when initially launched with the vp8 video frame encoder
2021-02-14 02:25:34	Pascal and the team did a good job improving its quality
2021-02-14 02:25:53	from my personal viewpoint they got the quality right around 2017-2018
2021-02-14 02:26:16	I kept comparing it to my own work with pik and webp near-lossless
2021-02-14 02:27:03	also, I wanted to improve it myself, too -- I and Lode contributed to the YUV420 sharpening (eventually they replaced our approach with something else, but what we brought was a significant improvement)
2021-02-14 02:28:10	the initial sharpening was focused on clamping effects -- I and Lode showed that it is more important to do sharpening to counter the chroma blurring effects in practical photography (clamping is more important for graphics)
2021-02-14 02:28:36	as a result I got some feeling about the quality it was producing
2021-02-14 02:28:52	until around 2013 the sky would often be 4x4 blocks
2021-02-14 02:29:21	until 2017-8 the images were quire blurry, great psnr, but didn't look good
2021-02-14 02:29:48	nowadays there is some tendency for oversharpening if features at the threshold are close to disappear due to quantization
2021-02-14 02:30:11	given all the constraints there are in the format, I consider it now a very good balance of image quality
2021-02-14 02:31:27	(terrible in 2010 == often worse than jpeg, and possibly on the average ~10 % better)

_wb_

2021-02-14 02:32:52

Ah, I didn't know there was actually effort spent on tuning vp8 encoding specifically for still images, I assumed it was just vp8 intra with encode effort settings set to max or something like that

Jyrki Alakuijala

2021-02-14 02:33:01	my lossless codec (WebP lossless) was bundled with the lossy codec and failure in quality (I felt) was holding the lossless codec back, and causing Apple to avoid WebP
2021-02-14 02:34:11	libwebp is pretty much nothing else than tuning vp8 specifically for still images -- think that 80 % of the effort went there

Scope

2021-02-14 02:34:47

Btw, as an additional format to JXL for low bpp and some other features, I would prefer WebP v2 instead of AVIF (but AVIF has much more support from different companies, also its integration is easier because it uses the same decoder as AV1) but I do not like the way AVIF was developed and also developed further (main improvements happen in AV1 encoders for video, and development and tuning of something for still images is very slow and residual)

_wb_

2021-02-14 02:34:55	The vp8 constraints are quite harsh: obligatory 420, only tv range YCbCr, minimum quantization of chroma also quite harsh
2021-02-14 02:35:31	There are 8-bit sRGB images that still have noticeable banding at cwebp -q 100
2021-02-14 02:35:57	(and with wider gamut it's of course only worse)
2021-02-14 02:36:51	AV1 does not have such problems though
2021-02-14 02:37:26	I wonder why WebP2 did not use (a subset of) AV1 as a payload codec
2021-02-14 02:38:21	That way you get a decoder for free and only have to focus on making a good AV1 intra encoder for still images

Scope

2021-02-14 02:40:23

Perhaps AV1 is too heavy and complex and can be made something lighter and faster, with the addition features needed only for static images

Deleted User

2021-02-14 02:41:59

Yeah, I remember reading that the complexity was the reason

Scope

2021-02-14 02:42:10

_wb_

2021-02-14 02:42:49	If you just don't use the slowest coding tools, you can still do that
2021-02-14 02:44:32	Defining a new codec just to be able to tune things to a particular use case seems like a recipe for lots of codecs and poor interoperability

Scope

2021-02-14 02:44:37

Also, is floating block-partitioning supported in JXL just not implemented yet?

_wb_

2021-02-14 02:45:04

It is implemented in the decoder, not yet in the encoder

Jyrki Alakuijala

2021-02-14 02:45:15	decoding is implemented, encoding is tested -- the best encoder is not using it
2021-02-14 02:45:52	it is one of those great sounding ideas with very difficult practical implementations and not as much gain as one would think initially

_wb_

2021-02-14 02:47:14

Making an encoder is making trade-offs between what bitstream possibilities you want to explore, and what speed you want to achieve

Jyrki Alakuijala

	Scope
2021-02-14 02:47:21	I am not aware of actual simplifications for AVIF to WebP2 -- it is difficult to say as there is no spec either and the format is not final
2021-02-14 02:47:47	the only simplification that I have heard off is to not to use HEIF, but use a yet another boxing format
2021-02-14 02:48:22	HEIF is rather silly, the PL/1 of boxing formats
2021-02-14 02:48:42	but WebP2 could have chosen to just use the boxing format of JPEG XL
2021-02-14 02:49:20	but it is a 'no', they wanted a yet another boxing format

Nova Aurora

2021-02-14 02:49:24

I go to bed for 7 hours and wake up to this wall of messages to wade through

Jyrki Alakuijala

	Scope
2021-02-14 02:50:23	I think the light animation used to make sense, but nowadays it is better to have just running muted videos in general

_wb_

2021-02-14 02:51:01

The web is of course an important use case, but a format specifically made for the web and _only_ for the web, that is not a good idea imo. People also need a format for photography, for image editing, for printing, for geography, for medical imagery, for game assets, etc etc. Do we really want to design dedicated codecs for each of these use cases?

Jyrki Alakuijala

2021-02-14 02:51:03

video compresses 7x better than an animation, and videos have nowadays many possibilities for great quality

Scope

2021-02-14 02:51:10

As far as I understood the direction of WebP v2 is only the minimum required and the most necessary features for the near future for web images

Nova Aurora

2021-02-14 02:51:33

I love that people created "gifv" which had nothing to do with gif but was just a trick to get people to adopt mp4 video for animations

Jyrki Alakuijala

2021-02-14 02:51:55	I don't yet see anything that differentiates WebP v2 positively from a good implementation of JPEG XL or AVIF formats
2021-02-14 02:52:30	I consider that WebP v2 is closer to AVIF than to JPEG XL
2021-02-14 02:52:42	too close to justify itself as a new format
2021-02-14 02:53:15	the lossless coding improvements (5 %?) there is not a big enough step to justify a new generation
2021-02-14 02:54:09	so if we look at the lossy side, I think of AVIF == WebP2 there (with a better boxing format, which may matter for 32x32 etc. images)

Nova Aurora

2021-02-14 02:54:28

In a vacum, I see where they're coming from, but right now it just looks like duplicated effort

Jyrki Alakuijala

2021-02-14 02:54:33	considering the JPEG XL and AVIF are available, I consider WebP2 an interpolate of their features
2021-02-14 02:55:40	I believe if we would just exactly copy their encoder for JPEG XL without doing anything else, we could get within 3 % of bitrate/quality, the formats are so similar
2021-02-14 02:56:07	the directional prediction is the main difference, but it is not of earth shattering importance

Scope

2021-02-14 02:56:11

Light animation not as a video format can be useful as for example the frequent spamming of animated emoji in messengers (it would be impossible to use hardware decoding for them, there may be less frames per second than usual in video and they may be dynamic, also less memory consumption for decoding, etc.)

Jyrki Alakuijala

2021-02-14 02:56:30	you can do light animation in AV1, too
2021-02-14 02:56:46	just use less stored frames
2021-02-14 02:56:59	you can limit stored frames to 1 -- it can be decided at encoding time
2021-02-14 02:57:14	decoding motion frames tends to be faster (less compute) than decoding full frames
2021-02-14 02:57:32	dropping motion frames as an option is not making things lighter, just the opposite

_wb_

2021-02-14 03:00:55

For animated emoji, you should just decode the whole thing once anyway, not keep actively decoding each frame. A 64x64 emoji with 100 frames is still only 640x640 worth of pixels.

Scope

2021-02-14 03:03:47

I mean, animated emoji have slightly different animation principles than regular video with stable fps, also for example there can be a winking emoticon that is static for 20 seconds, but then one second winks, etc.

_wb_

2021-02-14 03:05:02

Yes, for those things, probably container overhead matters more than the codec itself

Scope

2021-02-14 03:06:38

For large animations or short clips (for which now often still use GIF, which is not very suitable for this) video codecs are better

_wb_

2021-02-14 03:06:47	Agreed
2021-02-14 03:08:15	For things like a cinemagraph that is mostly a nice high res photo except the person winks every 5 seconds, maybe a still image codec is still best
2021-02-14 03:09:08	Or for an animation of a map of roman conquests that updates once every two seconds, or something like that
2021-02-14 03:09:47	For a typical "GIF" though, video is best
2021-02-14 03:10:16	https://c.tenor.com/IycahZMsX7YAAAAM/seth-meyers-right.gif

Deleted User

2021-02-14 03:11:30

"Don't buy our product use video" 😆

_wb_

2021-02-14 03:11:41	Well yes
2021-02-14 03:11:48	Use the best thing for the job
2021-02-14 03:12:20	Kill GIF, and don't replace it with just a better intra-only codec

Scope

2021-02-14 03:13:24

Btw, for animated video previews on YouTube, as far as I know also uses animated WebP, not a chunk of video (but there is a set of consecutive frames, each of very different parts of the video)

_wb_

2021-02-14 03:13:37	Browsers should just accept in an img tag whatever they accept in a video tag, with the only difference being that it gets no player controls, gets muted, autoplays and loops.
2021-02-14 03:15:54	And GIF should become the Adobe Flash of web animation

Scope

2021-02-14 03:16:11	https://i.ytimg.com/an_webp/_bZ-5pFQUpI/mqdefault_6s.webp?du=3000&sqp=CJrspIEG&rs=AOn4CLDYoRYW2dIqiEXvR5OSdcXw2WJZ7w
2021-02-14 03:16:52	But discord still does not support animated WebP <:PepeHands:808829977608323112>

_wb_

2021-02-14 03:21:34	Well, it is a Web Image Codec
2021-02-14 03:22:02	Which means it works in Chrome

Nova Aurora

	Scope But discord still does not support animated WebP <:PepeHands:808829977608323112>
2021-02-14 03:22:05	or apng

Jyrki Alakuijala

	_wb_ For things like a cinemagraph that is mostly a nice high res photo except the person winks every 5 seconds, maybe a still image codec is still best
2021-02-14 03:25:33	why?
2021-02-14 03:26:58	is there a technical reason in video formats that would hinder doing 5 second blinky eye

_wb_

2021-02-14 03:27:29

No, but the still image codec might be better at doing the non-moving part with high fidelity

Jyrki Alakuijala

2021-02-14 03:28:10

I think video encoders by default make incompatible decisions with that (like guaranteeing on having a certain amount of keyframes for easier seeking) and the decoders wouldn't loop it by default, but that's about it

_wb_

2021-02-14 03:28:34

And if no motion is involved in most of the image, motion estimation is overkill - just cropped frames are good enough

Jyrki Alakuijala

2021-02-14 03:28:37	I think technically it could be done with a simple delta frame (and then reversing that delta frame or just recalling the original frame)
2021-02-14 03:28:59	cropped frames are an option there, too

_wb_

2021-02-14 03:31:07

If you have like a 1080x1920 portrait photo of a standing person, and then 10 frames where a 200x100 region gets updated, it's basically more a still image than an animation/video

lonjil

2021-02-14 03:32:46

I think even that Scope meant something like 🙂 transitioning to something like 😉 after some seconds. Basically two small, simple images you probably want lossless.

_wb_

2021-02-14 03:34:43

Yes, for that a video codec is also overhead, it has too much per-frame overhead for things like that

Jyrki Alakuijala

	_wb_ If you have like a 1080x1920 portrait photo of a standing person, and then 10 frames where a 200x100 region gets updated, it's basically more a still image than an animation/video
2021-02-14 03:35:28	I consider that that could be done as an encoder strategy in existing video formats -- doesn't need its own format possibly

Scope

2021-02-14 03:36:03

Maybe not only two frames, but a small number of frames without stable changes for a long animation

Jyrki Alakuijala

2021-02-14 03:36:04

a decoder would not do much work if a tile is unchanged from one frame to next

fab

2021-02-14 03:36:08

does jyri araylla also worked in video encoding?

Jyrki Alakuijala

2021-02-14 03:36:46	I have contributed to AV1
2021-02-14 03:37:19	but I don't work on that, just my psychovisual work was taken into account there
2021-02-14 03:38:23	I looked mostly into their color modeling
2021-02-14 03:38:46	I had a chat with BBC image quality engineers in that effort 🙂
2021-02-14 03:39:40	I recommended them to add XYB in AV1 -- they ignore that, I wasn't too worried as you can still express it in ICC profiles and they had a colorspace code for ICtCp
	fab does jyri araylla also worked in video encoding?
2021-02-14 03:40:00	if you mean me, my name is Jyrki Alakuijala

fab

2021-02-14 03:40:41	thanks
2021-02-14 03:40:47	ok

Jyrki Alakuijala

2021-02-14 03:41:48

you are fabiorug from encode.su ? he also called me by the name Jyri Araylla 🙂

fab

2021-02-14 03:41:59	yes sorry
2021-02-14 03:42:06	i know in italy salvatore aranzulla

Scope

2021-02-14 03:42:09

Btw, I know that Pascal Massimino worked on Xvid at one time and I saw his posts back then on Doom9 and other places about video codecs

_wb_

	Jyrki Alakuijala I consider that that could be done as an encoder strategy in existing video formats -- doesn't need its own format possibly
2021-02-14 03:42:12	Yes, existing codecs are OK for that, but probably both jxl and av1 would be fine for such animated photos

fab

2021-02-14 03:42:17	he's one who does reviews
2021-02-14 03:42:21	articles blog

Jyrki Alakuijala

2021-02-14 03:42:26

I'm always happy if someone tries to say/write my name, getting it right is optional

Nova Aurora

2021-02-14 03:42:49

I think I got it right when I made the civil war meme

Jyrki Alakuijala

2021-02-14 03:43:03

😄

_wb_

2021-02-14 03:43:10	Jyrki I can remember, but Alekujala I get wrong if I don't look it up (like now)
2021-02-14 03:43:42	Alakuijala

Scope

2021-02-14 03:44:04

Yep, Finnish names are difficult to pronounce and remember for most other countries

Jyrki Alakuijala

2021-02-14 03:44:07	it took me a while to learn Sneyers or Snayers
2021-02-14 03:44:20	no, Finnish names are easy, the rest are difficult

fab

2021-02-14 03:44:36	back i compared jpeg xl to nhw codec
2021-02-14 03:44:46	before knowing the paper about jpeg xl
2021-02-14 03:44:51	nhw codec is dead
2021-02-14 03:45:12	i use to do weird comparison about confidence etc.

Jyrki Alakuijala

2021-02-14 03:45:16

look how much symmetry in alakuijala -- in reverse alajiukala, almost the same -- also the post-fix and pre-fix are the same 'ala', you only need to remember 'kuij' and they are just a handy cluster of keys on a qwerty keyboard

Scope

2021-02-14 03:45:32

Jon is also often confused with John

_wb_

2021-02-14 03:45:37

Even here in Belgium there are also people called Smeyers, Snyers, Sneyens, etc - all variations typically exist, because names tend to predate uniform spelling rules

fab

2021-02-14 03:45:58	jon is with one o
2021-02-14 03:46:04	this i get right

_wb_

2021-02-14 03:46:31

Sreyens Alajiukala

Jyrki Alakuijala

2021-02-14 03:46:55

my name would likely be in classic Finnish 'Alakujala', but the i was added as used in the special dialect in Lapland

_wb_

2021-02-14 03:47:26	Does the name mean anything?
2021-02-14 03:47:50	Sneyers is basically the dutch version of Taylors

Jyrki Alakuijala

2021-02-14 03:48:01

hmmm, jxl is somewhat palindromic by rotation and both sneyers and alakuijala are somewhat palindromic

_wb_

2021-02-14 03:48:43

My oldest daughter was born on 21 02 2012

Jyrki Alakuijala

2021-02-14 03:48:57

Alakuijala means: Ala == down the river, kuijala == either safe place to keep a boat or a place with narrow alleys between the fields

_wb_

2021-02-14 03:49:08

We had a date like that again a few days ago

Jyrki Alakuijala

2021-02-14 03:49:19	good aim!
2021-02-14 03:49:39	one of my daughters was born one hour too late

_wb_

2021-02-14 03:49:40

18181 is the ISO number we have for jxl

Jyrki Alakuijala

2021-02-14 03:49:58

it was upsetting to happen in Switzerland

_wb_

2021-02-14 03:50:05

Lol

Jyrki Alakuijala

2021-02-14 03:50:12

but then I understood that it was because of wintertime/summertime difference

_wb_

2021-02-14 03:50:57

So birth was still punctual, if you take that into account?

Jyrki Alakuijala

2021-02-14 03:51:34

yes, just biology had not had time to adapt into the wintertime/summertime change 😄

fab

2021-02-14 03:52:08	jyri alakujyala
2021-02-14 03:52:11	nothing on google

Nova Aurora

2021-02-14 03:52:43

I'm not going to keep my #2 spot for long 😦

Jyrki Alakuijala

	fab jyri alakujyala
2021-02-14 03:52:46	cut and paste it 🙂

fab

2021-02-14 03:53:05

or just think played wing and reverse

bonnibel

	_wb_ Even here in Belgium there are also people called Smeyers, Snyers, Sneyens, etc - all variations typically exist, because names tend to predate uniform spelling rules
2021-02-14 03:54:45	Jon Sneyders justice league

Scope

2021-02-14 03:55:32

Theoretically there could also be a nice palindrome date for ISO JXL (although I don't like fitting anything to dates, it would be better to have it well developed, designed and completed)

bonnibel

2021-02-14 03:55:37

(a 4+ hour long animated black and white jxl)

Nova Aurora

2021-02-14 03:56:28	> Simple animation format, 4 hours long
2021-02-14 03:56:54	https://tenor.com/view/sakurai-excited-happy-this-isnt-how-you-supposed-to-play-the-game-play-the-game-gif-15161132

Jyrki Alakuijala

2021-02-14 05:17:48	this looks interesting superficially https://dougallj.github.io/applegpu/docs.html
2021-02-14 05:18:40	I'd love it if someone would further this on jpeg xl: https://blog.cloudflare.com/parallel-streaming-of-progressive-images/

fab

2021-02-14 05:21:17	https://www.smpte.org/blog/the-future-of-the-jpeg-standard
2021-02-14 05:33:35	this is probably the most simple read about JPEG XL smpte.org

lonjil

2021-02-14 05:34:51

That seems to have a lot of errors in it.

fab

2021-02-14 05:35:09	what this ?
2021-02-14 05:35:10	https://www.smpte.org/blog/the-future-of-the-jpeg-standard

lonjil

2021-02-14 05:35:15

yeah

fab

2021-02-14 05:35:19	why
2021-02-14 05:35:29	where do you see errors?

BlueSwordM

2021-02-14 05:37:54

`The advantage of JPEG XL is that the format is backwardly compatible, meaning that traditional JPEG decoders will still be able to open the image,` 🤔 I don't think this is right. <:kekw:808717074305122316>

lonjil

2021-02-14 05:38:13

The first paragraph has a small error, > The term JPEG is synonymous with digital image file types and billions of JPEGs are now created every year. However, the format is only 18 years old, introduced for the first time in 1992. should of course be 28. In the JPEG XL section: > The advantage of JPEG XL is that the format is backwardly compatible, meaning that traditional JPEG decoders will still be able to open the image, and newer JPEG XL decoders will be able to call on the embedded metadata to view a higher quality version. JPEG XL files cannot be opened by JPEG decoders. I think I heard something somewhere about a feature like this, i.e. an old JPEG with added metadata for improvements, but it is definitely not true of JPEG XL proper.

fab

2021-02-14 05:38:43	yes
2021-02-14 05:38:59	they probably like what jyri said in encode su
2021-02-14 05:39:35	added metadata for improvements re written and different than the worse implementation of Zuckerli from Google
2021-02-14 05:39:45	and legacy decoding
2021-02-14 05:40:40	but the developers simplified in this way because they didn't know which direction jpeg xl was taking

spider-mario

2021-02-14 06:21:43	my name is nowhere near palindromic, but I was born on 4/9 (4 September), and my father on 9/4 (9 April)
2021-02-14 06:21:50	which is also 2²/3²

lithium

2021-02-14 06:29:55

Hello <@!111445179587624960> I find this description in discord discuss, Could you teach me about this situation?, 'butteraugli 1.0 is good quality on most images, but on artificial content sometimes 1.0 is not enough and there are noticeable artifacts or distortions.' My non-photographic image set not like your image set, your image set have different category, i worry missing some error. And in previous discuss, you find some image have sharp lines and ringing error in -d 1.0, Could you tell me those image have what features? I'm investigating what image will get error.

Scope

2021-02-14 06:36:18

Yes, but it was on old builds and a lot not on public images, maybe I can reproduce it on other images, but I'm going to do it after the major changes and tuning from Jurki for lossy mode

lithium

2021-02-14 06:42:29

I find some weird situation, in different metrics. // Butteraugli "original_cut_128x128_01_cavif_Q90_s1.png": { "maxButteraugli": "0.868652", "dssim": "0.000646", "ssimulacra": "0.00484238" } "original_cut_128x128_01_cjxl_d0.5_s3.png": { "maxButteraugli": "0.762193", "dssim": "0.000951", "ssimulacra": "0.00963924" } "original_cut_128x128_01_cjxl_d0.5_s7.png": { "maxButteraugli": "1.026062", "dssim": "0.001299", "ssimulacra": "0.01023229" } // jxl Butteraugli "original_cut_128x128_01_cavif_Q90_s1.png": { "maxButteraugli": "1.7593579292", "6Norm": " 1.052826", "12Norm": " 1.311489", "averageNorm": 1.1821575 } "original_cut_128x128_01_cjxl_d0.5_s3.png": { "maxButteraugli": "0.9201517105", "6Norm": " 0.522840", "12Norm": " 0.632284", "averageNorm": 0.5775619999999999 }, "original_cut_128x128_01_cjxl_d0.5_s7.png": { "maxButteraugli": "0.9077637196", "6Norm": " 0.548203", "12Norm": " 0.644132", "averageNorm": 0.5961675

paperboyo

2021-02-14 08:11:43

Continuing from https://discord.com/channels/794206087879852103/803605943338008586/810508354963111956 and because I can’t find any docs around it (pls point me!), some quick questions: > We don't want to leave it to applications to interpret things correctly (or ignore them) 1. What’s the default when there is no ICC? sRGB? Assumed, like in PNG? 2. I assume there is no metadata-only way of signalling eg. sRGB, AdobeRGB or, more likely, Display-P3?

_wb_

2021-02-14 08:14:00	We have a short representation of common options like sRGB, P3, Rec 2100 PQ, etc
2021-02-14 08:14:16	Those just take a few bits.
2021-02-14 08:15:05	Actual icc profile compression is only done if we get something that doesn't fit a short description.
2021-02-14 08:15:53	We try to avoid having no color space description
2021-02-14 08:16:09	I don't think the current encoder ever produces that
2021-02-14 08:16:46	Color space description is obligatory in the header, though you can set it to "unknown" if you really want to
2021-02-14 08:17:06	But the encoder will assume untagged input like ppm to be sRGB
2021-02-14 08:17:41	Also, the lossy codec actually uses an internal color space that is an absolute color space
2021-02-14 08:18:15	So the encoder knows the interpretation of the pixel values it is encoding, which is crucial if you want to get perceptual encoding right
2021-02-14 08:19:30	The color space indicated in the header is what the decoder will convert it back to by default, but you can also just ignore the header color space, and directly convert to display space
2021-02-14 08:22:22	Since all lossy jxl files use the same internal color space, regardless of the nominal space they are in according to the header, that potentially can simplify color management (applications can keep the transform from internal jxl space to display space loaded, instead of having to load a potentially different transform for each image)

paperboyo

2021-02-14 08:23:54

Thank you. That last bit is very interesting!

spider-mario

2021-02-14 08:29:10	for ppm, the color space can be overridden with -x color_space=(a description of the colorspace in a certain format)
2021-02-14 08:30:06	for example, if you have a PPM with Rec. 2020 primaries and PQ TRC, you can encode it to an HDR JPEG XL file with: ``` cjxl -x color_space=RGB_D65_202_Rel_PeQ input.ppm image.jxl ```

_wb_

2021-02-14 08:42:48

Those color_space strings are not very user-friendly, maybe we need some nicer abbreviations for common ones, and have some --help on it

paperboyo

2021-02-14 08:45:08

Was just looking for when could I find the list of them. Found this only (so: codes, not human-readable names): https://gitlab.com/wg1/jpeg-xl/-/blob/master/lib/include/jxl/color_encoding.h#L32-106 (+1 for `--help`) Was just thinking how a straight-from-camera JPEG with ~~DCT~~ DCF EXIF of AdobeRGB will get encapsulated in JXL.

_wb_

2021-02-14 08:51:37	That is currently not going to do the right thing
2021-02-14 08:51:48	We don't look into exif fields atm
2021-02-14 08:51:58	We should, also for orientation
2021-02-14 08:52:15	Didn't realize we also should for colorspace info
2021-02-14 08:52:44	Typically that is done in an ICC profile, but you're right, it could also be only in the Exif
2021-02-14 08:53:47	Exif primaries and transfer curve are also a way to set the colorspace of a JPEG
2021-02-14 08:55:28	Current cjxl will only look at the icc profile of an input jpeg. It will preserve the exif data in case you want to restore the original jpeg bitstream, but it does not parse it, and it should.

paperboyo

2021-02-14 08:56:06

> Didn't realize we also should for colorspace info Only for AdobeRGB, really (other there can be sRGB, I think). Didin’t even know EXIF has its own cHRM etc, haven’t seen this in the wild. DCF-only, on the other hand: any Canon and Nikon I tried, when set to AdobeRGB.

_wb_

2021-02-14 08:57:00	For orientation it's also quite important to parse the exif
2021-02-14 08:58:22	It's 'only' a matter of tooling, at the bitstream level there is no issue, but we need to get the tooling to do the right thing.

spider-mario

	spider-mario for example, if you have a PPM with Rec. 2020 primaries and PQ TRC, you can encode it to an HDR JPEG XL file with: ``` cjxl -x color_space=RGB_D65_202_Rel_PeQ input.ppm image.jxl ```
2021-02-14 09:23:18	(I have actually experimented a little with this, exporting HDR PPMs from DaVinci Resolve and encoding them to JXL)
2021-02-14 09:23:25	(seems to work well)

Deleted User

2021-02-15 07:25:42

How about adding error correcting sums as an optional feature to jxl files. This could be implemented like 2 tags in EXIF with one specifying the error correcting sum and one specifying the algorithm used to be future proof. What do you thing about this? Does something like this already exists?

_wb_

2021-02-15 07:29:57

You mean an error detection checksum?

Deleted User

2021-02-15 07:30:29	I was thinking like Reed-Solomon codes to be also able to to error correction
2021-02-15 07:31:13	And you could vary the amount of error correcting you want to include

_wb_

2021-02-15 07:32:43

Error correction and compression are kind of incompatible

Deleted User

2021-02-15 07:33:54

why is that?

lonjil

2021-02-15 07:36:39

it should be pretty easy to add like 1% overhead containing data which could correct for up to 1% of bits being flipped.

Deleted User

2021-02-15 07:37:54

Yeah, and having it like an option for storage

Crixis

2021-02-15 07:39:42

what purpose does it serve?

_wb_

2021-02-15 07:42:08

Normally we assume the underlying system layers to already take care of error detection/correction

Deleted User

	Crixis what purpose does it serve?
2021-02-15 07:43:15	if some parts of your file get corrupted you can restore them with the help of the error correcting code

lonjil

2021-02-15 07:43:29

Problem with putting error correcting codes in a general header thingy is that now you need the error to not be in whatever describes what's in the header.

Deleted User

2021-02-15 07:43:38

it's better explained here if you want to read some about it: https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction#Applications

lonjil

2021-02-15 07:44:19

For it to really work properly the error correction codes ought to be stored at a fixed position and their presence signalled in an error-resistant way.

Crixis

	if some parts of your file get corrupted you can restore them with the help of the error correcting code
2021-02-15 07:45:33	but this isn't important in modern tecnology
2021-02-15 07:46:34	hardware and file systems must preserve my files

Deleted User

	lonjil Problem with putting error correcting codes in a general header thingy is that now you need the error to not be in whatever describes what's in the header.
2021-02-15 07:47:15	Yes, you are right. you need to prevent error to the sum also.

lonjil

2021-02-15 07:48:33

No, error codes prevent errors to the whole, including the sum. I actually meant that the header telling you "hey here's some error correction codes" must be resistant to error, or the client won't even know that such codes are in the corrupted file.

Deleted User

	Crixis hardware and file systems must preserve my files
2021-02-15 07:49:03	I had my picture collection stored on an external harddrive. And over the years I noticed that jpeg files started to have errors in them. That is why I moved them to a ZFS Raid1 set-up. So you'd be surprised that some filesystems/storage still can have some errors

lonjil

2021-02-15 07:49:55

All commonly used file systems like NTFS, whatever Apple is doing these days, Ext4, XFS, etc, lack error correction.

Crixis

2021-02-15 07:50:55

this is a fault piece of hardware, if normal storage have such degadratin your OS will have some serius problem

lonjil

2021-02-15 07:51:56

Bit flips happen very often, but go unnoticed.

Deleted User

2021-02-15 07:52:01	No SMART errors on the harddisk and I barely used it, just to copy some files to it and view them from time to time.
	lonjil Bit flips happen very often, but go unnoticed.
2021-02-15 07:52:26	Yeah <@!167023260574154752> is right.

Crixis

	No SMART errors on the harddisk and I barely used it, just to copy some files to it and view them from time to time.
2021-02-15 07:54:00	the big majority of zips is unradable with 1 bit change, i never lost a zip

Deleted User

2021-02-15 07:55:47

I don't know if zips with 1 bit change are unreadable. Are you sure?

lonjil

2021-02-15 07:56:35

not that bit flips happening very often doesn't mean that most files get corrupted often

Deleted User

2021-02-15 07:56:38

But jpegs with 1 bit change can go unnoticed

Crixis

	But jpegs with 1 bit change can go unnoticed
2021-02-15 08:01:36	but are you sure? Is also similiar compressed

Deleted User

2021-02-15 08:05:56	I did a quick test. i opened a jpeg file in an hexeditor and changed one random byte. This is the result:
2021-02-15 08:06:01
2021-02-15 08:06:24	you can't see the error
2021-02-15 08:07:02	Also I opened a zip file and changed one random byte. The archive was open and the contents listed. But I couldn't extract the file.

Crixis

2021-02-15 08:07:49	yep, i did the same i see big black pixel but the rest is good
2021-02-15 08:08:38

Deleted User

2021-02-15 08:09:13	ha, you can clearly see the error in yours 🙂
2021-02-15 08:09:24	is it a jpg or png?

Pieter

2021-02-15 08:10:45	When talking about error correction you must have a model of what kind of errors.
2021-02-15 08:11:18	Hard drives these days generally lose whole sectors at once.
2021-02-15 08:11:48	I suspect that CPU errors are more like bit flips, but they're very rare.

Crixis

	is it a jpg or png?
2021-02-15 08:12:01	jpg. I did the test with zip, now is corrupted
2021-02-15 08:14:17	png is corrupted with 1 bit change

Deleted User

	Pieter When talking about error correction you must have a model of what kind of errors.
2021-02-15 08:16:05	jxl progressive mode is somewhat of an error correction for missing big parts of a file: if you are missing the last half of a file you get only half of the quality of the original file. But it's not really correction
2021-02-15 08:16:20	For bit flips error correcting would help
	Crixis png is corrupted with 1 bit change
2021-02-15 08:18:47	bmp is also vulnerable to bit flips...as expected

Pieter

2021-02-15 08:19:36

you can build error correction for whole blocks of 512 or 4096 bytes too... but I don't think either is really the responsabilty of an image file.

Deleted User

2021-02-15 08:20:46

yeah it's not really. I was thinking more like an container option

_wb_

2021-02-15 08:27:37

Could add a box for that. I think optional error detection might make sense. Error correction seems a bit hard to do in a useful way if you don't know the kind of errors to expect from the underlying storage or transfer medium.

Deleted User

2021-02-15 08:31:42

What do you mean by box?

_wb_

2021-02-15 08:34:01

Isobmff box

Deleted User

2021-02-15 08:38:24

Cool. If you can specify also the name of the algorithm I think error correction could also optionally be implemented. As from what I understand error correcting codes can also be used as error detection

Pieter

2021-02-15 08:41:07	That's correct.
2021-02-15 08:42:11	And if you an error correction code tuned for the type of errors you expect (but purely used for error detection), it can provide better detection than e.g. hash function based checksums.
2021-02-15 08:43:01	Though, if you're talking about substantial errors, anything over 8 bytes of hash-based checksum is basically infinity.
2021-02-15 08:43:36	I have some experience around this.

_wb_

2021-02-15 09:13:09	1 bitflip in the header or early data can make an image completely unreadable
2021-02-15 09:13:44	while in a progressive image, deleting the last 20% of the file may not even have visible impact

Deleted User

2021-02-15 09:20:11	so maybe a small, quick to encode and to check error correcting code that is more geared at the start of the file would be a good option
2021-02-15 09:20:52	but for 32x32 emoji 2 bits for error checking would be enough 🙂

veluca

2021-02-15 10:19:40

I have to admit I don't really see why it should be up to an image format to solve what is, ultimately, a storage/transmission problem - I'd very much prefer if error correction was left to the proper layer 🙂

_wb_

2021-02-15 10:29:02	It might be useful to catch encoder / decoder bugs if the checksum is done on the pixels, not on the bitstream itself
2021-02-15 10:30:38	(but that only works for lossless, for lossy we have rounding errors that are allowed so you cannot really make a checksum on pixels, unless you ignore least significant bits or something)

veluca

2021-02-15 10:30:59	ANS does have some checksumming of sorts btw (I guess most arithmetic coders would)
2021-02-15 10:31:22	you can't do error correction, but you can do detection

_wb_

2021-02-15 10:31:30	Ah yes, that's a good point
2021-02-15 10:31:47	arithmetic coders don't have that

veluca

2021-02-15 10:32:09

you can make an arithmetic coder where the initial/final state is fixed, no?

_wb_

2021-02-15 10:32:32	in both cases, the initial state is fixed from the encoder perspective
2021-02-15 10:33:03	but in ANS that means the decoder gets that state as the final state and can use it to check all is OK
2021-02-15 10:33:27	in regular arithmetic coding the encoder and decoder are doing things in the same order

veluca

2021-02-15 10:33:49

nothing stops you from making an arithm. dec. that has a fixed *final* state and the initial state in the bitstream (at least I think)

_wb_

2021-02-15 10:34:32	I suppose, if you do the encoding in reverse
2021-02-15 10:34:56	but then you're just combining the disadvantages of ANS with those of AC 🙂
2021-02-15 10:36:34	but anyway, we do have a simple bitstream integrity check already with the ANS final state check – bitflips will be caught
2021-02-15 10:37:12	and we don't need PNG-like chunk CRCs to get that, it's just a side effect of the entropy coder choice
2021-02-15 10:37:52	who picked that ANS initial state btw?
2021-02-15 10:39:32	it's `0x13`

veluca

2021-02-15 10:41:00

it was there when I started working on JXL 😄 no idea

_wb_

2021-02-15 10:44:02	actually it's `0x130000`, right? the state is 24-bit so it's basically like a 24-bit checksum
2021-02-15 10:45:15	It looks like the 'lucky' or 'unlucky' number 13 (except it's in hex)

diskorduser

2021-02-15 11:47:28	jxl speed - tortoise & modular
2021-02-15 11:50:09	Why does lossless webp compresses better than lossless jxl?
2021-02-15 11:50:44

veluca

2021-02-15 11:50:50

it depends a lot on the kind of content - in <#803645746661425173> we have some discussions on that, tl;dr is that on synthetic content you might need some non-default options to get the best compression

diskorduser

2021-02-15 11:52:34

So. what are those options?

veluca

2021-02-15 11:54:39	some things to try: `-s 9 -E 3 -g 3 -I 1` `-s 9 -E 3 -g 0 -I 1` `-s 9 -P 0 -I 0` `-s 9 -P 4 -I 0` usually one of those 4 options gets you the best compression for synthetic content
2021-02-15 11:55:10	is it possible to have the image for some testing?

diskorduser

2021-02-15 11:55:52
2021-02-15 12:00:07	`-s 9 -m -E 3 -g 0 -I 1` gives better compression than webp. thanks.

veluca

2021-02-15 12:01:08

you're welcome! lossless compression is often a funny game...

diskorduser

2021-02-15 12:01:18

On default settings it takes more time and bigger size than webp. 😦

veluca

2021-02-15 12:02:36

there will always be some images that are just bad for *some* codec 🙂

diskorduser

2021-02-15 12:02:53

Yeah

OkyDooky

2021-02-15 12:13:23

jxl matrix channel. nice

_wb_

2021-02-15 12:16:37

```$ ../tools/cjxl vorbis.png vorbis.jxl -q 100 -E 3 -s 9 -I 1 -X 0 -Y 0 J P E G \/ | /\ |_ e n c o d e r [v0.3.1 | SIMD supported: SSE4,Scalar] Read 640x480 image, 31.3 MP/s Encoding [Modular, lossless, tortoise], 4 threads. Compressed to 143117 bytes (3.727 bpp). ```

veluca

	_wb_ ```$ ../tools/cjxl vorbis.png vorbis.jxl -q 100 -E 3 -s 9 -I 1 -X 0 -Y 0 J P E G \/ \| /\ \|_ e n c o d e r [v0.3.1 \| SIMD supported: SSE4,Scalar] Read 640x480 image, 31.3 MP/s Encoding [Modular, lossless, tortoise], 4 threads. Compressed to 143117 bytes (3.727 bpp). ```
2021-02-15 12:18:08	``` luca@desktop ~/jpeg-xlm/build rect-by-rect-part1 $ ./tools/cjxl -s 9 -m -E 3 -g 0 -I 1 -m -q 100 vorbis.png J P E G \/ \| /\ \|_ e n c o d e r [v0.3.1 \| SIMD supported: AVX2,SSE4,Scalar] Read 640x480 image, 46.5 MP/s Encoding [Modular, lossless, tortoise], 32 threads. Compressed to 142049 bytes (3.699 bpp). 640 x 480, 0.06 MP/s [0.06, 0.06], 1 reps, 32 threads. ```

_wb_

2021-02-15 12:19:23	there will always be a way to get a bit smaller
2021-02-15 12:20:05
2021-02-15 12:20:50	"webp and lossless webp are bad, look how much more bytes they need for this image"

diskorduser

2021-02-15 12:20:51	haha it looks funny
2021-02-15 12:23:34	665kb on webp 😮

_wb_

2021-02-15 12:23:58	well it is a 4 megapixel image with a lot of detail
2021-02-15 12:24:03	try doing a lossy JPEG

diskorduser

2021-02-15 12:33:47

jxl > png > jxl. Whyyy

_wb_

2021-02-15 12:39:34

you'll have to do `-g 3` for best compression on that one

veluca

	diskorduser jxl > png > jxl. Whyyy
2021-02-15 12:41:28	(but the PNG is 1.5 MB, and the other jxl is 9.3 kB :P)

diskorduser

2021-02-15 12:48:53

Probably it was made for jxl algorithm 😛

veluca

2021-02-15 12:51:03

yes, it was 🙂

Scope

2021-02-15 12:52:54

veluca

2021-02-15 12:55:31

I remember playing with that image

Scope

2021-02-15 01:00:08

One of the few images where even the lossless AVIF is better (as well as the PNG)

Crixis

2021-02-15 01:45:55

monocromatic pixelart seem hard for jxl

_wb_

2021-02-15 01:46:37	it's hard for current cjxl
2021-02-15 01:51:49	clever use of patches could probably help quite a bit for images like this
2021-02-15 01:54:09	(hard to do though, but e.g. those bricks and pillars are pretty repetitive, but not detected by current patch detection heuristics)
2021-02-15 01:56:09	I suspect aom is better at detecting stuff that can be copied – video inter is basically that

Scope

2021-02-15 01:56:41

FLIF is quite good on these images

_wb_

2021-02-15 01:59:34	it's interesting, on that image default FLIF is only 13407 bytes
2021-02-15 01:59:51	while flif -N (non interlaced) is 24558 bytes
2021-02-15 02:02:08	ah I see what is going on there
2021-02-15 02:02:46	this is a "progressive preview" of the default (interlaced) flif

Crixis

2021-02-15 02:46:28

lol, lucky interlace

_wb_

2021-02-15 03:01:07

yes, it gets lucky in the interlacing steps, and in the final steps it can basically store some of the patterns in the MA tree since it has a lot of context then (a.o. all neighboring pixels except East and SouthEast)

Crixis

2021-02-15 03:58:54

make interlaced also in jxl

_wb_

2021-02-15 04:08:31

flif's interlacing is pretty complicated and one of the reasons flif is slow to decode

spider-mario

2021-02-15 04:58:59	for what it’s worth, I would call this “bi-level” rather than “monochrome” — the term monochrome generally refers to multiple shades of one hue
2021-02-15 04:59:13	for example, wikipedia gives this as an example of monochrome green image: https://upload.wikimedia.org/wikipedia/commons/6/64/Afghan_National_Army_commandos_with_the_1st_Tolai%2C_6th_Special_Operations_Kandak_clear_a_compound_during_an_operation_in_Nejrab_district%2C_Kapisa_province%2C_Afghanistan%2C_Dec._16%2C_2013_131216-A-CL980-198.jpg

Info

JPEG XL

General chat

Voice Channels

Archived

jxl

Anything JPEG XL related