JPEG XL

Why is that? it is turned off. Is this ANOTHER one of the same software that millions use but no one has checked? 🥹

I also can't understand this, it says "Tune trellis optimization for ****" But if I write -notrellis and that's it. Then it will use "Tune trellis optimization for PSNR-HVS (default)". But. For what reason is it used if I am notrellis. I want to say that if I write -notrellis -tune-psnr - what does it mean? have I started using the psnr metric? to optimize trellis which I disabled? I wouldn't have any questions, but -notrellis-tune-psnr and -notrellis-tune-hvs-psnr give DIFFERENT results. This means that by setting -tune-psnr, I am not changing trellis optimization, but exactly what metric is used.... BUT here -notrellis -tune-ssim makes a literally identical file as -notrellis -tune-psnr. What does it mean? it's broken.

<:Thonk:805904896879493180>

now I see that even guetzli cannot do as I would like

I especially want to pay attention to the grid in the very first block. All algorithms do it

but -notrellis -tune-psnr did it perfectly.

it's a pity that I do not know how to make more quality on color channels. because I see that they the worst even on yuv444

interestingly, this are actually from 0 to 8, I will be necessary to check each

1 and 7 save pixels best. but 1 (flat) is better

and yet -baseline -optimize don't work together<:Thonk:805904896879493180>

Or I didn't understand. how to check it. because I didn't understand where the no-optimize parameter is

Because if -optimize is enabled by default, then why write it

https://www.cufonfonts.com/font/nevermind-nr

403

The font has already a copyright

I'm using the same name for a project by other people

At the moment it didn't got published

💀

https://nikonrumors.com/2023/05/02/nikon-z8-vs-nikon-z9-specifications-comparison.aspx/#more-180701 Nikon Z8 will support HEIF 10-bit I wonder if they will be willing to add JPEG XL in the future of just stick to HEIF.

Once hw jxl encoders are there, they could support jxl at enough precision to use it for most raw use cases...

https://research.nvidia.com/labs/rtr/neural_texture_compression/

Interesting. They're using an advanced form of psy grain synthesis.

Thank you fab for finding this.

Nice they have included jpegxl and avif 😄

they only mention jpeg xl

while with avif they mention it and include it in comparisons

Jxl is in comparison

I was looking here

do you have a link for this ?

See the video (bottom of the page)

https://research.nvidia.com/labs/rtr/neural_texture_compression/assets/ntc_video.mp4

thanks

Ugh, av2 now already? And they plan to just make libavif do av2 payloads too?

That is an interoperability nightmare... Expect "this avif image doesn't work!" soon...

well, If they intend it as a web-delivery format - the browsers got a frequent updates and autoupdate, so in that case it should work

Honestly I like the quality of YouTube vp9 encoder

Is pleasant for me

Av1 is too complex

Like few frame few movements for

It uses small movements of each freme

That's get incredibily slow to encode good and efficientluly

And if you want to be pleasant at medium speed it gets blurry instead of blocky

But is an artifact

Video have 49k views no av01

I understand frequent new format for final web delivery... Your CMS or framework or CDN can just reencode the image to all formats and use the best supported one... But for local storage on PC or in your CMS? Thats awful... You want long term solution. Some format that will be supported and improved for decades to come. Not something that will just make version 2.0 and leave the original behind.

At the moment there is nothing at 1700 kbps encoded with recent techniques at 167k views

Time to hack in libavif output support to djxl I guess 🤪

Likely we expect av2 to have 500 kbps and that appeal

https://www.instagram.com/p/Cr3iPc6oN7_/?igshid=YmMyMTA2M2Y=

But you know it won't happen

Compression artifacts will still be visible

sure, if you're Chrome and you can just push a new format every 2-3 years, and breaking other browsers is a feature not a bug, then this model kind of works... but it's not a nice way to advance the web platform imo

AV2 as far I know will be aualities lower than this

JPEG XL is failed

?

Ended up having to use ZBrush for a friend who wants a model put into Blender... Turns out it only supports TGA, TIFF, PSD or proprietary formats with EXR as an addon for only displacement maps. The entire thing is stuck in the 90s

I never thought that I would be able to make my personal discovery in the jpeg field in 2023. But I found that the parameter: MozJpeg ```cjpeg.exe -baseline -notrellis -sample 1x1 -quality 90 -tune-psnr -quant-table 1``` gives surprisingly good quality. I didn't know jpeg could work well at all. For the last 7 years I have been using jpegXR q95 to archive my photos. And I'm about to switch to Jpeg XL - But now I'll have to reconsider everything. and also make a comparison with webp and all other codecs

Good old jpeg is not to be underestimated.

It's a good thing that jxl is guaranteed to be at least as good as good old jpeg. You can always losslessly recompress a jpeg and it will be smaller.

That's sadly how the ecosystem looks at this time, with chrome having major share on both pc and mobile, reminiscent of when IE was a major browser. At least given that cdn image delivery can give flexible format to end-user there will be fallbacks for minor browsers.

But in the bigger picture regarding other web-technologies things may not go as smooth

This is true. It's just weird to see that.... What it seems to me.... This is my guess, but - jpeg was bad Spoiled in pursuit of the ability to compress more pixels but with worse quality. It just seems strange to me that in 2023 I literally see: That jpeg turns out to be not so bad.

well, nothing unusual happened, jpeg xl has a much pixel accuracy

on q98

https://videocardz.com/newz/nvidia-neural-texture-compression-offers-4-times-higher-resolution-than-standard-compression-with-30-less-memory

https://research.nvidia.com/labs/rtr/neural_texture_compression/

psnr <:Thonk:805904896879493180>

seems to be sort of predicting some texture layers from others and ai upscaling, so not surprisingly it will be better than traditional codecs for such cases

https://research.nvidia.com/labs/rtr/neural_texture_compression/assets/ntc_video.mp4

Only AVIF once again https://research.nvidia.com/labs/rtr/neural_texture_compression/assets/Results/results.html

Someone's a bit out of the loop

Doesn’t seem like it would be difficult to construct such an image. Even for lossless JPEG XL, I’d imagine. Compression is about compromise in some way. Any kind of lossless compression algorithm can be exploited to come to produce a larger output.

I don't have a reddit account but if someone is able to it would probably be good to bring these results to that post

optimized the PNG and made it around 30% smaller and I also made a optimized lossless WebP and JXL

the WebP actually ends up smaller then both with current encoders

original PNG = 66.3 KB optimized PNG = 45.7 KB lossless JXL = 42.2 KB lossless WebP = 36.8 KB

all of which are in file I posted above

Do you remember the options you used for jxl?

-q 100 -e 9

did you do this with effort 3‽ I haven't really explored how the options in cjxl effect things so this is interesting

nope, options in the filename

E3 is different from e3

oh I had no clue

(From cjxl --help -v -v)

With which settings?

Ah, okay

Then wait a moment~

I did the WebP like this ```cwebp -mt -lossless -noalpha -z 9 -metadata icc -progress -v```

I get a way bigger results with the options I usually use, huh.

I probably don't need to add "-noalpha" but I do it just in case, otherwise I would just do "-alpha_filter best"

(When converting <https://i.redd.it/1h1vrc800uya1.png>)

It's also interesting to see how long it takes for this one to convert

You can go down from 8530 to 8485 with those: `cjxl -q 100 -m 1 -e 9 --brotli_effort 11 -E 3 -I 100 -g 0 -j 1`

(not all parameters are necessary, I just took what I usually use and modified it a bit)

I guess -I 100 makes the difference

yeah, it's just a fast bruteforce, I think -e 10 can reduce the size even more, though it will take a significant amount of time, sadly we can't check which options have been applied

Yeah, -e 10 just finished a few seconds ago

8053 `jxl --allow_expert_options -q 100 -m 1 -e 10 --brotli_effort 11 -E 3 -I 100 -g 3 -j 1`

Maybe should have only used -q 100 -e 10 if it really just tries every combination (edit: made no difference for the size)

I wonder how small this could go if JXL art was used.

Pattern is pretty interesting; colored a bit of it

Iirc Sierpinsky triangle already appeared as jxl art... Can't find it but

https://www.reddit.com/r/AV1/comments/13cy9f2/comment/jjkpyqc/ Hm, copying the whole image and inverting 1/4 of it... I don't think that can be easily done with what is written here: https://jxl-art.surma.technology/wtf.html. And idea?

Ah, they just shared code: https://www.reddit.com/r/AV1/comments/13cy9f2/comment/jjn1s04/

https://developer.android.com/guide/topics/media/hdr-image-format

> **This document defines the behavior of a new file format that encodes a logarithmic range gain map image in a JPEG image file.** Legacy readers that don't support the new format read and display the conventional low dynamic range image from the image file. Readers that support the format combine the primary image with the gain map and render a high dynamic range image on compatible displays.

they're *really* squeezing every inch out of JPEG

Isn't this just JPEG XT reinvented?

Inb4 Google adding JXL features over time to new backwards-compatible JPEG formats they come up with

They'll do anything but implement JXL support, lmao

to be as generous as possible with this decision, gainmaps do have the advantage that you get to decide how the SDR image looks like

I still don't like them, but there's that

No fps no scale

Maybe av1 aom speed 0 -- 20%

Hi, I'm not sure this is correct place to ask, I just don't know where to go with it. I have bunch of videos compressed with h.264, but in CAVLC mode. So I'm curious, is it possible to 'recompress' it without decoding to pixels and compressing again? Something like unpack CAVLC compression and compress existing data with CABAC? There are some threads over the internet asking about this, but with no solution.

I believe it is technically possible but I don't know any tools to do so

In one of these threads there was suggestion to implement it as ffmpeg bitstream filter, but unfortunately my knowledge of C and (more important) h.264 specs is not enough to do it

original png my jpeg yuv444 mozjpeg yuv444 telegram yuv420

even at quality 70 it shows amazing quality when comparing images with the same file size

the only problem is the gradients, it does them poorly, so is not suitable for quality lower than 85.

I also want to say that Jpeg XL turned out to be inapplicable in some of my tasks due to the fact that the amount of data that needs to be downloaded to display the image, even with multi-layered progressive, is too much for it *to be felt visually*. In some cases, I preferred to use the JPEG because it loads line by line and it shows instantly.... I hope someday JPEG XL will make it possible to progressively decode 256x256 blocks line by line and show it immediately......

For compress -d 6+ need to load 50% of the entire image to see the first layer of progressive decoding.

Really?! I expected less indeed. Can't some encoding options change that?

Issue is when the overall image is that small, suddenly the '20KB' preview of a 1MB image is now half of the entire file

yes, JPEG XL itself is made to be a good codec for large and medium-compress images, but if you start compressing very much, the large size of the internal structures affects, because there are all sorts of block distribution tables, there is a lot of service information, and it turns out that on very compressed images this information can be half of the entire file

But I think any of the developments in can say more accurately ☝️

the lower the quality, the larger proportion of the file is LF, indeed

with an LF frame, the LF image itself can also be done progressively... but I don't think libjxl will currently show those previews (it will probably wait until the entire LF is available)

and yes, libjxl shows 256x256 groups only when they're fully available — probably that could be changed

I saw how 256x256 groups were shown as the image was progressively loaded. It would be nice to have the same mechanism for Standard images without progressive decoding

But it still like a problem. simple, it seems to me - If 256x256 is the largest and most independent block, then why not make the structure of a JPEG XL file so that all data is loaded first for the first block of 256x256, then for the second block of 256x256 and so on. But I have a feeling that such a permutation will completely break the format compatibility

The LF is encoded in 256x256 groups too, but since that data is 1:8 it corresponds to 2048x2048

in fact, I do not know the structure of jpeg XL, but since I work with it a lot, I can guess what it is. it would be nice to have some kind of image that completely disassembles the entire structure of a single Jpeg XL file. I know that there are those who write decoders here, maybe I should ask for help

You can permute the groups to do a full 2048x2048 region before anything else, mixing LF and HF. But the current libjxl encoder will always first send all LF, and only then start sending HF groups

This is really a problem for progressive loading of large but highly-compressed images, for transmission in a low-speed network.

For progressive loading (as opposed to sequential), it's better to do an LF frame so you can get a 1:128 preview fast, then 1:64, then 1:32, etc

But then we probably need to make libjxl actually render those stages of the LF frame. Currently it will wait until the whole LF frame is available

it would be nice if libjxl could display them

but yea

Even despite all this, the amount of structural data is too large. When the image is large but has little real data

I wanted to say that it would be better to have a different data structure that would solve this narrowly focused task. This is to have a Jpeg XL in which each 256x block is a completely independent image with its own structure that can be loaded separately and displayed immediately

For lossless it can be like that

only lossless or the modular mode?

ah the -g

For lossy, there's the LFgroups which contain data at 1:8 resolution (the LF itself plus the HF metadata such as block type selection and adaptive quantization) and then the HF groups at 1:1 resolution

Modular mode uses only HF groups, unless Squeeze is used

if you disable all webp filters, if image out to be of very low quality, it does not greatly surpass the usual JPEG. But it is the filters, as well as the new experimental function -af, that greatly correct the situation I also wanted to say about what kind of decoding speed breakup occurs between webp/ jpeg and avif/jxl, this is a very very strong difference in decoding. in tests on 8000x8000 images, this is noticeable right before our eyes. WEBP really decodes almost instantly, while JPEG XL takes almost half a minute. And only support for multithreaded decoding makes this problem only slightly less noticeable

Are you testing with a non avx cpu?

I don't think there can be any difference here since the test is fairly happening between the same set of architectures

I see what you want to tell me. Just if you continue, I have to remind you that working fast on AVX is Not advantage. but the low speed of work on SSE is disadvantage.

Because we live in a world where AVX is not forcible standard for anything at all anywhere

if WEBP could be in yuv444 and the dimensions are larger than 16k x 16k, And supported anything other than PNSR (or at least had other encoders that would do much better compression, like mozjpeg for jpeg), then I would consider it as a replacement for Jpeg XL. But webp is just some shit.

<@226977230121598977> I haven't tested this myself but do you know how is the Trellis quantization like in WebP and how does it compare to MozJPEG? "-m 5" enables partial Trellis while "-m 6" enables full Trellis in cwebp

For strong compression, WEBP prefers to use 4-by-4 blocks instead of quantization... On closer inspection, it seems that it destroys more information than Jpeg. but if the adaptive filter -af is activated in WEBP, then when viewed from a normal distance of 1:1 - webp seems to contain more details. I conducted webp quality tests and in fact I only saw that the highest quality 6 respectively makes the best quality. But nothing more. To be honest, I don't even know which sets of algorithms are used for each quality parameter. But I can say that in my last discovery I found out that mozjpeg Trellis does much worse on any parameter https://discord.com/channels/794206087879852103/805176455658733570/1104117048499519548 . But meanwhile. I think.... I would like someone to build guetzli with OFF-restrictions so that I could make a comparison between guetzli and WEBP on qualities of about 10-40. I have a feeling that WEBP is not so good.

It seems to me that in the accuracy of transmitting some information, "mozjpeg without Trellis" works even better than guetzli, especially on small pixel images. But I can't deny the fact that guetzli is the only JPEG solution that creates the best gradients from all JPEG encoders, as well as preserves colors. This can be a very weighty argument when compressing

but webp. For obvious reasons of using PSNR - it has just disgusting and unnecessary artifacts in color with strong compress. It creates colors where they shouldn't be, artifacts look exactly the same on a classic JPEG with strong compression. And only filters -af smooths it out strongly enough that it wouldn't be so noticeable.

https://web.dev/avif-updates-2023/

It's getting silly how they keep spreading deceptive information

> Compared to other modern still image formats, AVIF produces smaller files with similar visual quality (see the following graph, lower is better) but is also faster to encode.

they're citing the chromium team's claim that avif is faster to encode

which is propagating pretty weirdly

I might as well ask here in case anyone has some advice. Yesterday I spent about 5 hours messing with HEVC to save some storage for archiving video with my 1070TI. I know 10bit is meant to increase the compression since it reduces banding and dithering, which it did... But when I tested OBS set to record in it, it seems to add far more ringing and compression artefacts then just the base 8bit. Ended up just setting both to 8bit in case the ringing happens on the ffmpeg hardware encode too in certain cases, but it'd be nice to figure out why or if it's just a common issue no one has clocked yet

I also ended up with 8 bits rather than 10 because at least for synthetic videos (i.e. game recordings) it produces better looking results with the same bitrate. My routine is to record using lossless 4:4:4 h.265, and then convert it to h.264 using ffmpeg with `-c:v libx264 -preset:v veryslow -profile:v high444 -crf 18`

I'm mostly just aiming for low filesize because of my single SSD and apparent curse with any HDD I buy, under 200GB left so it's entered it's 'conservative' mode that lowers speeds

personally I just encode x265 with my CPU to get the best quality, but the videos I usually encode are shorter too

do I understand correctly that you are first recording (to 8 bits because OBS produces worse quality otherwise) and then reencoding that? I think I have seen people argue that 10-bit encoding can be advantageous even for 8-bit original material so have you tried 8-bit recording -> 10-bit encoding?

I started with setting up an ffmpeg command to do hardware re-encoding from 8-bit to HEVC 10-bit, then thought I'd try the same in OBS directly since it seemed to work well enough, but recording directly to 10-bit resulted in far worse quality than the re-encode. Bear in mind, I was still set to Rec 709 so it *should* have been SDR encoded by main10 from what I understand

it's so enraging !!!

This comparison is new — is this lossless GIF recompression with jxl versus lossy recompression with AVIF?

I mean, there's no doubt that AV1 is better for animation than JPEG XL, since it's a video codec after all. But why do they prove that point by comparing lossless to lossy?

plus, it’s so weird, for a lossy codec, to just say “look, we can make small files”

well, okay? how do they look?

Try it on some pixel art and it'd probably still be a lot closer with lossless

https://www.blue-dot.io/avif-speed-quality-benchmark/ is interesting data

though BD rates are deceiving, aggregating gains over a large range of qualities can be extremely deceiving, especially if a large part of that range is useless

as expected, the hardware (or rather, hw-accellerated) compression results are worse and faster than the software results

a bit strange that they only compare to default speed software though

it's "7-23" times as fast as libaom s6 with 8 threads

at the cost of compressing 4% worse than that or so

(according to bad metrics and aggregated over a probably mostly meaningless range)

the thing is, libaom s9 is also about an order of magnitude faster than libaom s6

s6 with 8 threads is about 4% worse than s6 with 1 thread

also they're using tv range yuv420 for some reason, which basically has the effect of using 7.5 bit instead of 8 bit, i.e. the qualities will all be a bit lower and the cap of maximum achievable quality will be a bit lower too

the thing with lossy hardware compression is this: if it can do very high quality (like camera jpeg files), then the suboptimal compression of hw (as opposed to sw) doesn't matter that much because for the actual delivery on the web, you will probably want to reduce resolution and quality anyway and use the best software encoder you can find

but hardware compression that cannot reach very high quality, what's the use case for that?

sacrificing ~10% compression (compared to, say, aom s6 1-thread full range 444) for some speedup that saves you some CPU costs but requires you to buy special hardware (which will cost something too, of course) is a questionable imo

what is the use case where you don't care about 10% compression and you are also fine with relatively low quality (capped by tv range yuv420)?

also they probably didn't do the speed measurement of the sw encoders in a very fair way. They used a 32-core machine and then either encoded 24 images simulaneously with -j 4, or 32 images simultaneously with -j 8

that sounds to me like putting way too much load on that poor machine, which will result in worse timings than if you keep the load reasonable and e.g. have only one job at a time per core

I mean, it is obvious why: speed. Faster than 4:4:4 just because of less to process and more optimizations available in 4:2:0 than 4:4:4 currently.

what about the tv range? (luma 16-235, chroma 16-240)

The limits on hardware acceleration always seemed odd to me. Surely it's not *that* more costly to allocate a few more bits, also surprised you can't accelerate the slowest operations then fallback to CPU for the rest, but I know most of the time it all runs simultaneously so that's not possible

Yes, 4:2:0 is clear why, that processes only half the data so of course it's faster. I wonder why tv range though — can they somehow exploit that to get cheaper transforms or something?

Generally for stupid metrics like psnr and ssim that don't see banding anyway, I would assume that lowering the effective bitdepth doesn't really hurt that much, while the range reduction does reduce the amount of entropy in the signal so it should help to improve compression...

Well, for TV range, that's because officially speaking, full range BT709 YCbCr isn't a thing 😛

https://www.nokia.com/blog/high-five-to-10-years-of-heif/

Officially according to what authority?

Let me look in my docs to see where I found this statement. It might take a while though 😅

Hmm, I can't seem to find the original statement that I based my reply on. I guess I was wrong, or just can't find the original statement.

Just curious why tv range is so ubiquitous still, I don't see any advantage to it

Of course all else being equal, files compressed with tv range will be smaller than with full range

Maybe it's that?

`cjxl -d 0 input.gif output.jxl` and `ffmpeg -i input.gif -crf 0 -b:v 0 output.avif` using <https://commons.wikimedia.org/wiki/File:(-)-menthol-3D-qutemol.anim.gif> as input

is tv range so that there's a range for wtw and btb

is libaom in ffmpeg performing badly, or did I get something wrong? ffmpeg took 30 seconds and gave me that

it's even bigger than the original gif

Citing from this site: <https://www.tvtechnology.com/miscellaneous/composite-digital-video> ``` The sync tip is assigned the value 16 decimal or 010 hexadecimal. The highest signal level, corresponding to yellow and cyan, is assigned the value of 972 decimal or 3CC hexadecimal. The standard provides for a small amount of bottom headroom (some call it foot-room), levels four to 16 decimal or 004 to 010 hexadecimal, and top headroom, levels 972 to 1019 decimal or 3CC to 3FB hexadecimal. The total headroom is on the order of 1dB and allows for mis-adjusted or drifting analog input signal levels. This reduces the S/QRMS (signal-to-RMS quantizing error) ratio by the same amount. The theoretical S/QRMS of a 4fSC product featuring analog in/out interfaces is 68.10dB for a 10-bit system and 56.06dB for an eight-bit system. This is considerably higher than any composite analog or component analog VTR. ``` So looks like it's a relic for analog equipment compatibility.

hmm for jxl `-e 3` creates smaller image than `-e 6` and `-e 7`

I've found `e 3` and `e 4` can make files smaller than anything below `e 8` in some cases

For lossless or lossy?

hm

it looks expected. I don't see the point in these tests - but where is webp

expected - AVIF doesn't make sense to use lossless compression. In addition, unlike the WEBP - AVIF , this is a full - AV1

In fact, the other day I tried an animated WEBP and it's terrible, every frame there is only a key one, it's not VP8 as I thought

Yeah it's not

Avif originally was intra only too

This also explains why WEBP animated decodes longer than AVIF animated

Then they decided to allow full av1 after all

lol

If you have av1 for video anyway, it makes a lot of sense

well, in my opinion this is initially a bad idea. Why do animation in a video-based codec WITHOUT using video technology

If you just want to support avif for still images, it might be a bit annoying though, since you have to implement the full av1

Why not just allow video formats in an img tag so you don't have to wrap your av1 in an avif but you can just use mp4 or mkv or whatever you want

But isn't that why firefox didn't support animated AVIF?

I dunno, but it could be, yes

Okay, actually, given the scope of the entire AV1 format and the number of companies, it doesn't look like a problem right now, because- well, look, all browsers support full AV1, there's no reason to cut the AVIF codec. And I think it was taken into account at the development stage

I agree that AV1 should not work in the IMG tag until it is made as an AVIF. After all, AV1 is always in some kind of container like mp4 webm mkv, but AVIF is a cleaner AV1 in HEIF format

true image format

Meh, safari allows mp4 in img tags, and why not?

Insisting on a specific container is kind of silly imo

That's nuts, lol

It's just the same as a video tag with looping, autoplay, no controls and muted

But more convenient since you can put both "gif" and still images in the same tag

Of course historically it was probably a mistake to allow non-still images in an img tag

But that ship has sailed 30 years ago or so, thanks to gif89

If animated gif is allowed, then why not mp4 or any other video container with any supported video codec payload in it

Making a still image container to contain a video codec and then forcing to use it whenever you want to use the video codec for video, I don't understand the logic in that

That makes sense

One of the only reasons for all that overhead of heif is so you can do alpha and icc color profiles

But it cannot even do it in a very good way afaik... I don't think it really has support for muxing the two bitstreams so you can do video-with-alpha in an interleaved way...

After all, it is made for still images where you have one frame of color and one frame of alpha

Video containers have solved the problem of muxing several long streams a long time ago

Just use that, and take the bonus points for allowing anyone to just use any old video software to create "gifs"

Usually lossy but there was an occasion recently where lossless was better at lower effort too. Unfortunately I don't remember the file though...

IIRC, lower effort on VarDCT => Fewer quality checks => The result may miss distance target and be of lower quality (and smaller) than the image encoded with higher effort.

Yeah

waiting for controls panel for animated pictures.

Today I did a lot of tests with very compressed Webp, indeed it is a unique format that allows you to compress so much. I made a small algorithm, the picture is compressed, if its weight is more than 4096 bytes, then it is compressed by q10 less. And so on until the weight is <. Then I compress it again use -pass 10 -af, which in practice, working with very strong compression turned out to be extremely inefficient, but still make the image better by about a couple of percentages. Well, that's it. q0 is a real meme, I do not know what parameters are set there inside the codec, but in some cases the image with q0 can be 3 times smaller than q1, it's very hilarious. So, I was thinking how to break the compression cycle, and then I realized that it does not matter at all, because impossible to any image reaches the compression level q0 with >4096. hah. ||But perhaps after reaching q10 it is necessary to make a separate function to compress q1, because q0 is really funny.||

<:VP8:973222137202610226>

those are massive distances tho

in such conditions, JXL does not demonstrate advantage

JXL is not designed for extremely low qualities

WEBP just like JXL has very little data on its personal container

this PNG has EXIF data that `cjxl` is including

ah, just 14 bytes

that's discord doing that

it adds that to all PNGs

it adds eXIf after IDAT iirc

that's how you can tell

what’s in it?

and yet, in the texts of advantages over AVIF, I saw bragging about the size of the container, and what does it turn out here

they add this to every PNG

I assume it's unintended behavior of whatever they shove PNGs through to strip stuff from them

that matters for progressive previews more than for actual filesize

It mostly matters for small files like icons, where people now resort to css sprite sheets to avoid the header overhead

I would like to say that there is quite a tangible example when jpeg xl is worse than webp. But again, I wanted to note that Jpeg xl uses very few of the possible block sizes, and also note that at the moment of development I am not satisfied with the reliability/quality of the VAR-block placement, so maybe it's all temporary, but as it is.

imo they are both equally terrible quality, they just have better/worse quality in different parts of the image

<:monkaMega:809252622900789269>

so powerful that they decided not to spend money on hardware decoding

Another thing of note in Apple news is Safari will now support HEIC/HEIF. Seems strange to me they would finally put it in their browser after 6 years. https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes

hilarious

It kind of makes sense, they want to embrace web apps, and then it could be useful to handle iPhone camera pictures directly...

They probably don't expect this to be a codec available in the broader web platform, just something that would help web-based photo apps to support their internal camera format

yeah that seems to be one of the main reasons

screenshot from here: https://webkit.org/blog/14205/news-from-wwdc23-webkit-features-in-safari-17-beta/

but considering that hevc has also started to be supported by chrome and other browsers if hw decoding is available, then adding heic even in other browsers is theoretically not that far off from reality

The patent mess will make it take at least until 2033 before heic can conceivably get universal support

Remember, chrome only has hevc support if your hardware happens to support it

Meaning you paid for the license as part of the hardware cost.

yeah, but hw hevc decoding is pretty common now, and it's already ubiquitous on mobiles

Do you have statistics on what kind of percentage?

like most gpu/igpu/apu from ~2015-2016 and also mobiles (even the very cheap ones on mediatek), older ones probably have no support, but especially for mobiles this means they are officially unsupported in general (unless some critical vulnerabilities) and some new formats for them will also be a problem

nvidia has it since 10 series

It's generally just sites/applications not tying into the hardware already available

I find it unlikely that Chrome will go thru the trouble to do HW decode of images just to support HEIC.

Also note that hw generally only supports 4:2:0

so does Apple anyway, though

Hardware in, hardware out. Or rather, the other way around

Lmao that article

SVT-AV1 preset 0, no wonder it's extremely slow <:KekDog:884736660376535040>

And the VMAF results look... off. In my experience speeds that slow should definitely get better VMAF scores compared with x265

I've heard AVIF has a lossless setting but when I tried using it via a particular program (can't remember off the top of my head), the results were definitively not lossless. Is there an actual lossless AVIF or did someone just wrongly label it as such?

Avif lossless is useless. Don't use it.

i was thinking as much but also i wanted to try it lol

Have to also set the colorspace to RGB if you want lossless. But then it doesn't do any color decorrelation, so it kind of sucks. I think they want to add YCoCg but that would not work on existing deployments, so it's a bit late for that...

But even with YCoCg it's probably not very good at lossless. It's entropy coding is designed for having lots of zero residuals, it's not great for high entropy stuff like lossless...

okay, maybe i wont bother then

its clearly not a lossless format

(one of the major reasons I'm so miffed at JXL getting snubbed in places... would be really nice if we had like a really solid widespread alternative to PNG)

is “AVIF also does lossless” sometimes used as an argument for why JXL would be unnecessary?

yes

so bizarre

https://github.com/AOMediaCodec/libavif/pull/1432

> Warning: This feature is experimental and forbidden by the current AVIF specification.

I don't like the sound of that

The point of standardization is that you don't change the spec all the time

I get it that they want to reduce that header overhead, but it's a bit late for that now...

maybe it could be used in AV2F

Ohh, they missed out on `AV1F`

AV1 isn't exactly a massive subreddit, wonder why they are going after them...

im pretty sure it's an automated bot going after any subreddit with `x amount of days` private at this point

Did jpegxl get a message?

not afaik

On AV1's Discord they announced they are moving from Reddit to Lemmy.

Hello! I'm not sure if this is the right place, if there's a better one, let me know! I'm trying to implement a compression algorithm (first time doing this!:) ), but I'm struggling a bit. The algorithm is LZSS, but the implementation of the server is very different than what I've found online! I've followed this guide to understand how it works and to glance how an implementation should be done: https://go-compression.github.io/algorithms/lzss/ However, the reference server varies *very* much: https://gitlab.freedesktop.org/spice/spice-common/-/blob/master/common/lz_decompress_tmpl.c They reference this paper, but I don't know enough maths to understand it: https://dl.acm.org/doi/10.1145/322344.322346 And other client implementations do aswell: https://github.com/Shells-com/spice/blob/master/lz.go https://github.com/eyeos/spice-web-client/blob/ddf5ea92a6dfb1434bc5d79f6a2f8c9bed53ae97/lib/images/lz.js#L25 https://gitlab.freedesktop.org/spice/spice-html5/-/blob/master/src/lz.js I'm really lost, could anyone point me to the right direction? Thanks! :)

LZSS is a primary example of "asymmetric" compression algorithms, where you have one way (in principle) to decompress the data but you can compress in so many ways with different characteristics

also LZSS itself is a concept, while all of them would implement a concrete compression file format which *will* greatly differ in details (and they won't use just LZSS but with other algorithms)

Hmmmm

I think I get it

have you ever implemented *decompressor*? I think you should do that first, because compression is more difficult than decompression in general

I just want to decompress, there doesn't need to be a compression part

back in time I implemented DEFLATE in Python and that gave many (but not all) insights

try DEFLATE then, I think it's most accessible

What's that?

one used by zip, png and so on

it's a standardized compression format

The compression algorithm has to be this one, as I'm writting a client for a protocol that uses this compression algo

https://www.rfc-editor.org/rfc/rfc1951.html

wait

that means you should have a compression format description

Can you link to an external library?

But I haven't started writting a decompressor, because I wanted to understand it correctly before

otherwise you should figure out gory details yourself, which is very hard

I'm writting it in TS, so no

can you reveal which protocol is in use? is it standardized?

https://www.spice-space.org/spice-protocol.html

The protocol itself is standarised

Often writing a deconpressor and debugging it is the best way to understand it

But the compression parts doesn't seem to be

oh it's a custom compression format...

(There's also their custom "QUIC" compression algorithm, that doesn't seem to be documented anywhere?)

(Check section 8 of the display channel, `Spice Image`

There are some of the compression formats that need to be implemented

And those are other client implementations, but there are 0 comments on the code, so I don't get how everything works: ``` https://gitlab.freedesktop.org/spice/spice-common/-/blob/master/common/lz_decompress_tmpl.c https://github.com/Shells-com/spice/blob/master/lz.go https://github.com/eyeos/spice-web-client/blob/ddf5ea92a6dfb1434bc5d79f6a2f8c9bed53ae97/lib/images/lz.js#L25 https://gitlab.freedesktop.org/spice/spice-html5/-/blob/master/src/lz.js ```

https://gitlab.freedesktop.org/spice/spice-common/-/blob/master/common/quic.c seems the definitive code

I agree it's really daunting for beginners

I guess I could link the `spice-common` library, but it would impact severely the application performance, because passing the whole arrays between JS and WASM is very slow

but at least it's open source, so in principle you can mindless translate C into JS

That's for the QUIC algorithm, but there's also their LZSS implemetation

in my understanding you don't need an actual source code to reconstruct their LZSS specifics, while you need one for QUIC

Why not for LZSS?

ah wait

hmm

yeah, you're correct, I thought LZPalette or similar gives much information about that

it didn't

They seem to switch between image type and do different things

anyway... yeah, you need to translate C to JS, there seems no other way if you don't want wasm

actually I would want to ask why you want to avoid wasm

This ^

did you measure?

Nope

while there is indeed some overhead, it might or might not matter for your use case

But if there needs to be allocation and copying for each frame I recieve, I'm guessing it's going to be way slower

you can make a simple proof of concept to prove if it's indeed the case or not

computer is really fast 🙂

Another question I had is if it makes sense / can be done implement those protocols using WebGL?

So the computations are on the GPU part?

(WebGL -> OpenGL on the browser)

and in fact, if you export the wasm memory you can directly access it as ArrayBuffer

https://www.w3.org/TR/wasm-js-api-1/#memories

You can have shared memory??????

while accessing *individual* elements from JS may be slow, you would want to copy it to other ArrayBuffer

and that wouldn't incur much overhead

note: I don't know if stock solutions like emscripten do support memory exports, but wasm proper does allow for that

Going back to the compression part, the only way to do it is copying it from C?

And also this

yes, you can directly send ArrayBuffer into webgl texture (https://developer.mozilla.org/en-US/docs/Web/API/WebGLRenderingContext/texImage2D) so it's not that hard

if you have other compositions going on webgl would be desirable, otherwise 2d canvas context might be enough

compositions like, color correction or palette indexing or general affine transforms

Nice, thank you very much!

It seems MS Edge now supports AVIF, but behind a flag, only on Win11 and only on Canary channel (it was on Canary 114, but it's not on Release 114).

AVM has a good quality like e9d1 already with cpu 8

Inter takes only 15 seconds

Like JPEG XL for Google you have to admit there's no need

Like with libjxl 0.7.0

You may say cjxl quality improved but how many people can see the difference?

The efficiency is too far from VVC

Vvenc

Current cjpegli at d 0.479 should match AVM

Does vvc even work well at such high qualities?

not sure if this is the right place to ask, but does something similar to JPG -> JXL lossless transcoding exist for older video codecs?

Closest would probably be JpegXT, but that's just backwards compatible to old Jpeg

I see, I was hoping more that something might exist for h264

Well mpeg1 is just motion jpeg so that would be convertible to jxl too. I think some medical stuff used that so it might be relevant for archives or something...

would that be converting the keyframes to jxl and keeping the rest the same then?

I don't think MJPEG has any interframe anything

Extend cjxl to take MJPEG input 🤔

does VVC have good lossless compression? or it's yuv lossless and weird source for this example?

<https://encode.su/threads/3397-JPEG-XL-vs-AVIF/page10>

wait what? mpeg-1 is just motion jpeg? that doesn't sound right

Yeah, mpeg-1 was the first intra-coded one, mjpeg was before that

do you mean inter-coded?

Yeah, sorry

No, not currently.