JPEG XL

they might do this for a bunch of patents. I was just thinking about the video format related ones :/

this organization actually pisses me off

I want to reduce the file size of images losslessly. In the case of the JXL convert error `libpng warning: iCCP: profile 'icc': 'GRAY': Gray color space not permitted on RGB PNG`, stripping PNG icc profiles seems to be fine, as the icc profile doesn't match the image for whatever reason. But what about for images downloaded off the internet (eg. artwork) that have working icc profiles? Will stripping the icc profile result in any noticeable difference for how the image is displayed? Also, for photos taken with a camera/phone, should the icc profile be kept? `oxipng -o max --strip tEXt,zTXt,iTXt,eXIf,tIME,iCCP --force`

the ICC should be kept in most cases. here's an extreme example of an image that doesn't look right without it's ICC:

don't think jpg has an equvialent, but at least on png you can have a cicp chunk nowadays (probably not supported by all software yet) that can essentially have the same information as the icc profile

e.g. see <https://github.com/w3c/png/blob/main/Third_Edition_Explainer.md#hdr-support>

probably the most common sdr, non-srgb profile you'd see is p3 d65, e.g. on photos taken on apple devices (don't know what android oems do nowadays, maybe the same)

it won't look completely broken if you strip the profile but it'll certainly not look as it should

also note, the icc profiles used to tag images are typically very small (just have a few parameters instead of huge 3d lookup tables, like you'd find on some display profiles). so you're not really saving a lot of space unless you have a ton of small images

Thanks, this is a good example

While I do have ~2tb of images, it is good to know that keeping the icc profile isn't taking too much space

https://themaister.net/blog/2025/06/16/i-designed-my-own-ridiculously-fast-game-streaming-video-codec-pyrowave/

Seems like a good choice for VR streaming IMO

Close enough, welcome back MJPEG

Quarter of the century too late.

> … VMAF, are you drunk? sounds about right

<:monkaMega:809252622900789269> uncompressed

apparently the Steam workshop just lets you upload arbitrary files as thumbnails: https://steamcommunity.com/sharedfiles/filedetails/?id=3384488018

arbitrary?

I mean it seems like it although I haven't fully checked myself. It could be some backend layer that accepts more formats then the rest of the layers recognize but idk

Yeah but... What's that one?

AVIF

Steam uses Akamai which has some sort of product similar to Cloudinary

Doesn't steamdeck capture in AVIF by default?

the MIME type that gets sent over by the servers is a fallback

so this doesn't really seem like something that's actually officially supported

could probably upload a JPEG 2000 file if you only want people on older versions of Safari on MacOS to see your thumbnail(s)

No, the steamdeck only captures in PNG, HDR games are also just tonemapped to SDR PNGs

the deck's settings have no options at all regarding screenshot capture

you can change settings on the desktop, but it didn't carry over for me

png v3 supports some form of (true non-gainmaped?) hdr so thats be a safer solution since png libs gonna be upgraded with that support everywhere anyway

Valve could just let the deck capture screenshots as AVIF, since this is the default for gamescope and also an option that can be enabled in the steam settings

I assume steam tonemaps HDR to SDR if AVIF capture is not enabled?

Right, that's what I was thinking of, with your tests showing it's awful compared to JXL

I actually included JXL capture into gamescope, but haven't shared it on here yet. I have been using it for over a week now

Oh?

Sadly I don't expect valve to accept a PR, even if the code conformed to their standards, which I assume it does not at this point in time. Maybe when Chrome, Electron and Firefox get support

probably worth posting a PR anyways

currently I just ripped out AVIF capture and replaced it with JXL. I am working on being able to capture AVIF and JXL, with AVIF being the default

Waiting another month or two for the browsers might not be a bad idea, they're both getting pretty close to finished

Will take a while anyways, since I am an absolute novice at coding

But my JXL inclusion works perfectly (as far as I can tell) for SDR as well as HDR

Critic and suggestions will very much be welcome when I get around to posting it

make a patch and even 3rdparty builds available to the willing if already produced. upstreaming is only ideal but not the only way

if JXL support becomes widespread enough you could probably switch the default to it

blogging with screenshots and numbers about your tentative to add jxl support could help drum up interest and support upstreaming effort

I will do some benchmarks when I find the time

Sisvel should feel impressive

https://fixupx.com/videolan/status/2009025832187252874

Feels weird knowing the same cone is sat behind me from the conference last year

if AVIF2 gets added to browsers within a few months of the AV2 announcement I will be on the news

"does not bring sufficient incremental benefits over AVIF2" https://chromium-review.googlesource.com/c/chromium/src/+/7416348

Hopefully it gets fixed up and merged before they get given yet another excuse

maybe AVIF2 should get shafted because it doesn't have enough incremental benefits over JXL <:KekDog:805390049033191445>

nah, I'm excited for AV2, but only for video (unless they somehow made AVIF2 (AV2F?) an appealing image format for much more than web delivery)

I wish JXL had the dev resources AV1 has <:SadCheems:890866831047417898>

Simultaneously having Adobe, Apple, Intel, Meta, Microsoft and more push for support, and yet giving almost no contact, making odd implementation decisions and not contributing to libjxl which they shipped to all their devices and software

We're desperately in need of fresh and skilled talent, there's just so many features of JXL to improve and implement

I think we have highly talented people working on it, but there just aren't a lot of them

I have high hopes for jxl-rs, I hope when the decode side is ready enough, some developer time will be allocated to an encoder side to it as well

hopefully with an architecture that makes it easy to experiment with different techniques. with how expressive JXL is, I think being able to add different encoding modes/tunes/heuristics relatively quickly, without too much risk of breaking the existing code, would be really good (but I'm not an expert on anything here so)

libjxl is nearing a decade old, with most of it spent on the private gitlab repo, so while it makes an easy base to change variables and enable different settings, it's hard to know *what* variables to change or if some settings work at all

imagine if testing a new tune/feature, like screen content detection and segmentation, could just be a submodule, or even its own crate, in the package

I have no idea if that's feasible, but it would be really really nice

libjxl has never been a particularly elegant or clean codebase, it was born by smashing together the pik and fuif code and then doing lots of experimental stuff on top of that. I think it was a bit too ambitious to try to be at the same time a reference implementation, cutting edge in terms of both speed and compression performance, and production ready. I mean, I think it kind of achieves all of that, but not in a way that is easy to maintain or contribute improvements to.

The fact it works, and it works well enough to be competitive against AVIF with all the money getting pumped into it, is a testament to JXL itself

I feel like what might happen is that AV2 gets shoved into AVIF and then they try to do a rollout similar to when they added YCgCo-R: https://github.com/AOMediaCodec/libavif/issues/2077

I really hope for an improvment in the avif tools, because it is currently not really possible to decode an HDR AVIF to PNG mathematically losslessly

_definitely_ not easy to maintain

especially after the chunked encoding changes, I think everyone on the jxl team is afraid to touch the encoder in substantial ways xD (at least me and Zoltan are, and I suspect everyone else at least as much)

first class support for glitch art in the reference implementation sounds like a boon to me :p

I'm not sure what you want lossless AVIF -> PNG is already mathematically lossless, and of course you can't decode a lossy AVIF to PNG losslessly

wut

source?

Should have been more specific, I am specifically talking about decoding lossless HDR AVIFs to PNG Decoding a 10 bit HDR AVIF to PNG via libavif's avifdec changes the checksum. Using FFmpeg does work if compiled from main at this time (recently a bug was fixed regarding this) but still results in a different checksum Using ImageMagick results in a identical checksum, but HDR metadata is lost (there are two open issues regarding this) Same thing for libvips libheif can be used to decode AVIFs, but guess what, the output also has a different checksum Bascially there is no library or tool that allows bitexact decode to other formats without either changing the checksum or losing HDR metadata

I opened an issue with libavif [here](https://github.com/AOMediaCodec/libavif/issues/2916)

If anyone here knows of anything that works in a bitexact manner without losing metadata, please let me know

[monkastop](https://cdn.discordapp.com/emojis/720662879367332001.webp?size=48&name=monkastop)

The main reason why libavif decodes like it does is because the color values are rounded apparently. And it does not seem like they intend to change that behaviour

This is the main reason why I got off my arse to include JXL encoding into gamescope lol

oh right, looked at the code, steamcompmgr should probably save in 16bit for HDR so you can save scrgb without truncation

well for jxl at least

gamescope by default does not seem to care about this, as screenshots are always saved as 10 bit AVIFs

I would have to check how gamescope handles it

They are not lossless AVIF though, both the SDR and HDR image have MC=9, which means they are stored in YUV not RGB

I have lots of gamescope AVIFs, which are actually GBRP Same issue with those

libavif detects them as YUV too btw FFmpeg built from main shows them as GBRP, as they actually are

Do you have any examples? I would be surprised if libavif doesn't detect the CICP correctly Maybe gamescope didn't write the right value

Here's an image you can test with

And since you will find that libavif and ImageMagick report this image as YUV, here's the offending code from gamescope which captured this image ``` pAvifImage->transferCharacteristics = bHDRScreenshot ? AVIF_TRANSFER_CHARACTERISTICS_SMPTE2084 : AVIF_TRANSFER_CHARACTERISTICS_SRGB; // We are not actually using YUV, but storing raw GBR (yes not RGB) data // This does not compress as well, but is always lossless! pAvifImage->matrixCoefficients = AVIF_MATRIX_COEFFICIENTS_IDENTITY; ```

From [here](https://github.com/ValveSoftware/gamescope/blob/221394fedaed213f9bce6d18f60242e3120b661f/src/steamcompmgr.cpp#L2976)

Yeah MC=0 means RGB, so gamescope did write the right value and libavif detected it correctly

The "Format: YUV444" from avifdec output only indicates whether it's subsampled, the CICP is for its color space

I did see the decoded PNG is not pixel identical though

i think rather than comparing the chroma-upsampled png to the avif it would make more sense to do an avif -> png -> avif round trip test to judge whether the conversion is "lossless"

libavif does not support encoding HDR PNG yet

Sure, it may be relevant if encode has similar issues, but I personally only care about decode

right but as mentioned in that thread, i would assume the difference in pixel data just comes from different chroma upsampling algorithms

as comparing the avif to the png requires chroma upsampling the avif first. and that's only guaranteed to match the png if the exact same algorithm was used in generating the png in the first place

No chroma subsampling here for the image above

PNG -> AVIF seems fine from a short test, the encoded AVIF has the same checksum as the 8 bit PNG I've used

sorry, had it switched up there

It's probably due to 10-bit -> 16-bit conversion I don't think there's a way to only use the low 10-bit in PNG?

it shouldnt matter unless there is processing issues

well, if you wanted to be sure it would be best to do 10->16->10 then hash

That may introduce some rounding difference

you can do whatever you want with the LSBs in png (using all 0s or 1s is better for compression), and ideally it should have an `sBIT` chunk indicating the real bit depth

how do you get a hash from `identify`?

I don't think it really matters though if it's just libavif and imagemagick using different algorithms for 10-bit -> 16-bit conversion

``` avifdec source_10bit_gbrp_hdr10_smpte2084_bt2020.avif the.png avifenc -l -d 10 --cicp 9/16/0 the.png the.avif compare -metric AE source_10bit_gbrp_hdr10_smpte2084_bt2020.avif the.avif null ``` it roundtrips perfectly so yeah, in this case since there's no subsampling the difference just comes from whatever is done to the padding LSBs

if you compared the avif to the png MSBs they should also be identical

identify -format "%m %#\n"

I literally have to look up how to use imagemagick commands every single time, the cli is not intuitive at all

This is why I have an unlimited bash history <:galaxybrain:821831336372338729>

lol

I've set my Bash history to load on startup, then unlink so I can add commands to `.bash_history` only manually <:KekDog:805390049033191445>

but then you can't count how many times you've run something!

https://github.com/MikuAuahDark/simplewebp

Today I learned: > The key to good GIF compression is making LZW algorithm lossy > https://github.com/ImageOptim/gifski/releases/tag/1.13.0

What's the AI link for? But yeah, it's been around for over a decade https://kornel.ski/lossygif

I never think entropy coding itself can be lossy <:Thonk:805904896879493180>

Anything lossless can inherently be lossy, it just depends what you store in it

anything lossless where the compressed size depends on the actual values (i.e. not something uncompressed like ppm) can be made lossy by replacing expensive-to-encode values with cheap-to-encode values

you can make ppm smaller by writing fewer values

downscaling the image you mean? yes, that would be a kind of lossy ppm, I guess

<@184373105588699137> If you didn't come accross a 128bpp JXR yet, I found one in my collection https://files.catbox.moe/vbnm0p.jxr it is 128bppRGBAFloat according to JxrDecApp Decoding it to EXR via magick only results in a 16 bit file, no idea why

I dont think magic does a supurbe job, I use jxrdecapp from libjxl directly and found that it will make a large tiff

I'll try that one too though ofc

I had to use libvips, which worked

but the resulting JXL was larger than the JXR

I did get an unsupported format with it so I'll add logic to it tonight

which is interesting since it should work

oh? your tool worked for me

``` height x width: 2160 x 3840 Pixel depth: ThirtyTwoF channels: 4 colorspace is: rgba128float, scRGB Pixel Arrangement: RGB image will be saved as a rgb 32fbpp jxl ```

what the fuck, jxrdecapp doesn't work for me at all, I think I downloaded the file corrupt lol

happens

lol I download the webpage one sec

yeah it works for me too lol, typod O instead of 0 for curl

ah

but still, sad that the JXL is much larger than the JXR

LMAO don't encode it to a png

Hadn't tried that, one second lol

Smaller, but of course PNG only supports 16 bit. A 16 bit JXL is also much smaller than the JXR

yeah, also that is one hot image, I wonder what the nit range is on this

But since the JXL is round 2x larger than the JXL with same image hash, I can even understand why Microsoft is keeping JXR in this case lol

tev shows ~50 over standard SDR

Does that scale linearly or like stops in a camera?

I can't remember off the top of my head, its been a while, but this image is a goof showcase of a place where jxl lossless is struggling, it shouldn't be loosing to jxr here

even at this bitdepth

I'll probably add a force 16bit flag or something to the tool

I wonder how much potential savings could be had here

hdrview shows ~12 over SDR instead of 50

Could try using an older libjxl version before the pallete was disabled, or just comment out the line

maybe it will depend on jpegxl-rs, what line to comment out? would be easiest route

wait a second, the JPEG XR wikipedia page says this: > 32 bits per component as fixed-point numbers or full-precision floating point numbers packed into 96 or 128 bits (for which lossless coding is not supported due to the excessively high precision)

so if the jxr is not actually lossless, then it's not surprising that it compresses better than jxl lossless

I thought jxr was lossless 0.0

could be that wikipedia is wrong, but probably it's correct and jxr does not actually support lossless float32

oh lol

well, no wonder that the lossless JXL is 2 times larger then

Should be correct, I get the same image hash when converting 8 bit integer TIFFs to JXR, but not when I convert a 128bit float image

Possibly better compression of float32 is possible by not disabling RCTs in case there are no negative input values. YCoCg expands the range by one bit, e.g. 0..255 becomes -255..255, which is why it is disabled when the image is already 32-bit since we don't have that spare bit. But if a float32 has only positive values, it's only an 31-bit number so we could apply YCoCg...

The thing is that you need to inspect the entire image to know that all values are indeed non-negative, and in case of chunked encoding you cannot do that. Though you could still do a per-group RCT.

so far all of the images I've tested have had at least a couple negative value pixels.

And, knowing now that these JXRs are actually lossy, JXLs performance compared to 16 bit float, which are lossless, is better than JXR

I need to check the exact ranges of things but probably if the float32 values are in some range like [-1, 2], that's good enough to ensure that YCoCg roundtrips.

https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_modular.cc#L893 you could try dropping that condition and see if it still roundtrips

could per-group channel palette first, YCoCg later

feels a bit weird but...

No idea if I did it right, but deleting the condition increases filesize a bit

I'm amazed by how hot some of these images are, just goes to show how some games just don't care and will send the display anything it can take.

I'm extremely late and now we know the data is lossy, but it might still work. I got a 4x reduction in the past <https://github.com/libjxl/libjxl/blob/53042ec537712e0df08709524f4df097d42174bc/lib/jxl/modular/transform/enc_palette.cc#L189>

Pallete was disabled for the same reason as that (I think?), in case it didn't reduce the effective bit depth enough to be lossless with the extra palette data I could be wrong though, the commit just said "prevent overflow" without any more details

how is this PNG able to load progressively? https://www.libpng.org/pub/png/img_png/pnglogo-grr.png

Adam7 interlacing

Those marbles describe it 🙂

oh! fun

I thought interlacing was a tool for better compression in certain instances, I didn't know it allowed for progressiveness. TIL

It usually makes compression around 25-50% worse

<https://www.libpng.org/pub/png/pngpic2.html> > Thousands of people ask Greg every day, "Just how does two-dimensional interlacing work in the Portable Network Graphics specification, and what does it mean to my sex life?"

There's some fun notes about how tech changed between the 90s and 2020, rendering the example image > The 320x240 images averaged about 40 minutes each on a 486-33; the 1024x768 monster required over 12 hours. > 3840x2160 - 175.8 seconds

for a second, I thought you meant “rendering” as in rendering the interlaced PNGs

ohhh

that's what I thought too... I was very confused

PNG's two-dimensional progressive interlacing is an improvement over GIF's one-dimensional progressive interlacing :p

Yes, but you lose a lot of prediction potential, since PNG applies prediction independently to each scan. In FLIF, you also do 2D interlacing but prediction can use all nearby already-decoded pixels, which is funky for the last pass where you can predict from 7 neighbors, all except East.

This funky interlacing was dropped in FUIF (and JXL) since it is not very nice for speed / memory access patterns, but it is fun.

"EnCodec" neural audio compression (2022) https://discord.com/channels/794206087879852103/806898911091753051/1466071895601582296

At 24 bitrate, it's pretty mediocre; AAC-HE and Opus might sound better in mono at that bitrate. But stereo music at 12 bitrate is absolutely unrivaled <:This:805404376658739230>

https://gitlab.com/AOMediaCodec/avm/-/issues/1258

am i reading this right? av1 has 12 bit support and av2 won't?

<:banding:804346788982030337>

anyway most HW do not support 12bit decode

never saw 12bit AV1 nor HEVC in the wild

isn't 12 bit support required for lossless 10 bit rgb images using ycocg-r?

hevc and av1 support 12 bit and it looks like h.266 goes up to 16, so it just seems like a strange decision if they want to compete with those

unless they just aren't intending it to be used as a high quality interchange format

also i'm curious why they're doing the implementation out in the open but the spec development happens on a private repo

maybe to prevent some patent troll situations?

or make it harder for them to do it?

iinm a big patent troll explicitly said theyre watching just to find ways to prey on anything implemented. i doubt aom feels its a threat, just an annoyance

I guess you're talking about sisvel

our favorite organization

recent paper with maybe interesting stuff https://arxiv.org/abs/2601.02712

funky partitioning scheme

laughs in JPEG XL where we can place blocks wherever we want ✨

on the other hand, lossless AV[1-2] might not be worth rescuing

hmm, I wonder if lossless AVIF uses PSNR tuning instead of some better metric

PSNR is worse for visual similarity, but when losslessly encoding residuals, all that matters is getting the values as close to the source as possible, and that's basically what PSNR checks for afaik

> lossless AVIF uses PSNR ....what

yeah, doesn't lossless AVIF work by lossy encoding a frame and losslessly encoding the residuals?

I think one of the core problems with lossless AVIF is that they are using a lossy codec for the purposes of lossless which AFAIK historically always produces mediocre results. the only formats that have noticeably good lossless compression are ones where lossless is the only mode or what WebP and JXL do where the lossless mode is kinda a separate codec in a way

Oh, wait, didn't you say lossless AV1 is just lossy mode with residuals stored lossle- Right

it seems like an easy oversight to continue using better visual similarity metrics, while you should actually be using PSNR, the most basic and least accurate one, for lossless :p

no idea whether they do or not, just a random thought

a massive screenshot of the Steam store page as a lossless webp that took 6 seconds to encode is the same size as an effort 9 lossless JXL (without patches) that took 30 seconds to encode <:SadCheems:890866831047417898>

actually I should have done more testing before posting that. it seems lower efforts produce about the same file size, but getting over that mark used exponentially more compute for smaller and smaller gains (for this specific image)

lossless webp is king for screenshots

it's really good

JXL is still better in general of course, but for mostly text webp is simply the best

afaik the only coding tool it has that JXL doesn't is a palette of recently used pixels that it can reference. JXL has static palettes

though not all the palette features in JXL are currently working, like delta palette just has an experimental implementation and doesn't always work at all

which is a bit surprising. isn't lossless JXL conceptually very similar to lossless WebP?

that's just the encoder not being good enough 😛

at least JXL has patches which do better still

So many improvements that can still be had, the potential is enormous

AFAIK the only time Delta Pallete is used is when you do `-d 0 --lossy_modular_palette`

effort 7: > (15.588 bpp) effort 8: > (1.639 bpp) it's experimental, alright :p

I'm not sure the delta palette encoder is in an especially good state

Effort levels only impact the lossless compression that encodes the delta residuals, the image always stays the same. Though, because it disables chunked anyway, you can do `-e 10 -g 3 -I 100 -E 11 --patches 0` for basically free

free by what measure

as someone that just spent 8 minutes encoding an image with delta palette at effort 9, I have some idea

i still don't

all I know is that delta palette took much much longer than I expected. presumably jonny meant that those extra parameters add relatively little encode time compared to the massive encode time the delta palette itself has

anyhoo I really need to sleep 👋

Yeah, it's already really slow, so relatively it's not much more expensive to go all the way

2x slowdown compared against normal encoding where those settings might be 20x

ok, I wouldn't consider 2x slower to be free. and what about decode cost? anyway, that kind of inefficiency just tells me delta palette isn't worth it, but I never tried it myself.

WebP is basically free on this scale, but for real.

WebP doesn't have a delta palette coding tool. JXL is just as free if you disable it

(it does – https://groups.google.com/a/webmproject.org/g/webp-discuss/c/QlTNOR2b7ak/m/ovfJdkvuAQAJ )

oh, huh. I didn't see that when I was reading about lossless WebP

does JPEG XL have something equivalent to WebP near lossless, by the way?

lossy modular?

from the description of how near-lossless works it doesn't seem like that's what lossy modular does by default

did* https://github.com/webmproject/libwebp/commit/0ec80aef3d96b95315577c3d121b771261a2274e

I understood “coding tool” to mean that the format allows it?

I guess it might still work but there's no encoder to do it anymore in practice

I think I found the post that introduced the idea https://groups.google.com/a/webmproject.org/g/webp-discuss/c/W-iFWM1jGh8

I'm not sure if this is also how the delta palette in JXL works. I'm a bit confused from the way it's been described, but it seems to be based on vectors in the palette's "color space" rather than encoding of quantized residuals to a palette entry. but maybe they're about the same in practice

I only just found out lossy modular without squeeze is pretty good...

I didn't know you could disable squeeze...

it looks like it's not a dedicated coding tool, rather the possibility for delta palette emerges from being able to reverse the order of palettization and spacial prediction in the codestream

hence why I didn't read about it in official papers

Gotcha, I was working within the context where JXL was 5x the cost of WebP.

what other discord servers exist for "general" data compression (images, archives, audio, ...) ?

meh, https://encode.su/forums/2-Data-Compression

I was specifically talking about discord

then there is hardly anything else like this, it is such a highly specialized topic, too few people are interested in anything other than the very basics

right thanks <:SadOrange:806131742636507177>

I just got in bed at a brisk 5am, and as my eyes adjusted to the dark I had an idea. VR headsets started to use foveated streaming to save bandwidth and improve clarity where the user is looking, but our eyes only have cone cells to receive color in the centre and rods surrounding it, so instead of just lowering the resolution/quality in the periphery, what if we weighted Luma and Chroma differently? Full chroma and reduced luma in the very centre, then full luma and significantly reduced chroma in the periphery I'd assume someone's already thought of it, and the quality reduction already lowers chroma more, but there might be some improvements by redistributing the spatial quality of the planes

I thought Steamframe was using some complex algorithm for this, but it's actually using the simplest algorithm possible, the simplest possible in principle: simple resolution reduction, quantization, interpolation, that's all. And it's all so simple solely for the sake of speed in calculating each frame. Your idea sounds reasonable, as if we were using a 256-color palette for the entire blurred space. BUT it's not feasible, given the current performance requirements for this algorithm, which is based on maximum simplicity.

any conversion to another color space or any algorithm for determining relative and reasonable Luma and Chroma would be too complex for all this, for the sake of saving a few bits

Hardware encoders support a region of interest map, it's feasible that could be extended to support independent Luma and Chroma weights

the original algorithm doesn't do any compression; it's pure data transmitted directly, without any DCT-like processing. The original pixels and the reduced pixels are out of view. This is technical RAW, since rendering a game involves a large number of different pixels, so compression is inappropriate. And any algorithm beyond that seems unnecessarily complex

missed opportunity to save 1 bit in some transform blocks in av2 https://gitlab.com/AOMediaCodec/avm/-/issues/1237

Quick someone check how much of a difference that makes

would 9 even have been the most judicious value to reduce to 1 bit out of the three?

good point actually

https://www.phoronix.com/news/Glycin-2.1-Beta-JPEG-2000

It's interesting that many compression formats—images, video, audio—are quite resilient to data, block, and byte corruption. But none can survive a byte shift. Except perhaps MP3, hmm, which was designed with CDs in mind, among other things. All the others require precise positional correspondence. mkv & webm containers have clusters that can be decoded separately, but they are usually 256 kilobytes in size, which is large, shift 1-byte enough after which the entire cluster dies.

JPEG and JPEG 2000 are in principle both able to re-sync after byte insertion/deletion corruption, since they're using markers (0xFFXX) to separate segments.

in JXL we didn't want to bother with having to escape 0xFF bytes and we wanted to be able to seek immediately to bitstream sections to dispatch parallel decode threads, so we use a TOC instead which is fragile for insertion/deletion corruption (the offsets will all become wrong)

most modern media don't really produce insertion/deletion corruption though, and in any case corruption protection is generally something handled at a different system layer because you cannot really do error protection effectively without having some model of the kinds of errors that will get introduced. E.g. an SSD drive or a wifi transfer will behave quite differently, and different error protection strategies are applicable in different scenarios

so it doesn't really seem like a good idea to try to solve it at the level of the file format

The best way to at least verify integrity is by implementing checksums the way FLAC does

You cannot recover the file, but at least you'll know, that it lost its integrity

Everybody ought to have backups anyway

This is precisely the approach I don't like ideologically. It's like "it's the 21st century, nothing breaks easily anymore, no damage, so we won't protect it at the format and container level" "But by the way, it's better to have copies, otherwise everything might break."

Just think how much better it would be if inside each 256x256 independent Jpeg XL block there were 2 bytes of Reed Salamon's recovery code.

Interesting information, does this mean that not a damaged byte, but a damaged single bit is enough to break the entire file?...Well, I actually just did that and it won't open anymore, oh wellp.

Most bitflips should get detected in jxl, and libjxl will then refuse to decode. Of course decoders could do other things when detecting corruption, e.g. see https://github.com/libjxl/libjxl/pull/4062

We kind of have that, in the sense that the final ANS state is used like a checksum.

That gives us free checksums for every bitstream section - free in both senses: it doesn't have to be explicitly signaled and it doesn't have to be computed, it's just a side effect of the entropy decode.

As I understand it, this is not in the current latest version?

that's an interesting property, like no side effects left at the end of decoding? like no remainders from division in

all the sums converge and the result is 0

In my personal tests, a 10-year-old HDD damaged 3 bytes when transferring 500 gigabytes from scratch. I'm not entirely happy with how jpeg xl completely dies like solid archive with a single-bit error

Not all formats actually suffer from 1-byte corruption, but there is an example, here it is, 1 byte, jpeg, webp, avif, but jxl just died

The lesson here should be that the data saved on more technologically advanced compression should be used for data recovery, but there is just no such thing, you saved data, and you have more risk

Looks like I'll have to write the recovery data to the picture description block heh

What I'm getting at is that using jpeg xl for archiving can have a very serious counterargument because of all this.

The format, by its architecture, does not imply any mechanism of damage control, even despite the block essence of the entire format. Although I was sure that unrelated superblocks of size 256x256 can be independent when decoding <:SadCheems:890866831047417898>

The need to "separate" stuff into the pretty theoretical categories at the expense of practicality _and_ parity with older formats is not something I like. I don't really care about checksums or corruption, but the absence of lossnessness indication (a single bit!) means that I always will prefer random PNG to a random JXL on the web when I want to save an image.

PNG does not have a losslessness indication bit, does it? At least I wouldn't know what chunk that info should go in when writing a lossy PNG.

Libjxl checks errors and refuses to decode corrupted files. It's trivial to make it produce corrupted output instead, if you prefer that behavior.

I checked and PNG also breaks when any bit is damaged

Yes, that's what I wanted to ask, libjxl refuses to decode even without performing any decoding, how can I force it?

Also depends on decoder implementation/settings in case of PNG. Nothing forces you to refuse to decode if the CRC doesn't match

Considering that png is line-based and is based on archive compression, I can assume that the limit to which decoding can be performed is the line up to the first error

The PR I linked earlier adds an option to make it decode corrupted files, at least if the corruption is in HF groups it will fall back gracefully and show upsampled LF instead for the corrupted HF groups.

and yet it is not accepted for a year

people just assume PNG is always lossless due to various factors such as most software and tools not doing any lossy transformations on the pixel data for the most part in most cases (although I still see people get tripped up with that *one* export option in Photoshop). In most cases online it's safe to assume that a PNG on a website will be the least lossy of the available formats since in most cases people and even some CDNs don't really think too much at all when exporting various formats so what you usually get/see is whatever the default settings are for the most common encoders which in PNG's case is 8bpc lossless

I wonder if you take a random sample of PNG files from the web, how many would be actually lossless. I suspect it may be less than half.

JPEGs saved as PNG, 16-bit images getting saved as 8-bit, 8-bit images getting saved as a color-reduced palette image, transparent images accidentally getting flattened, layered images by necessity getting merged, etc etc: there are many ways to get a PNG file that is not actually lossless wrt the original source image.

(not to mention downscaling and cropping)

<https://xkcd.com/1683/>

also PNGs that come from GIFs

interestingly, this is the only xkcd I've found where the responsive '2x' version of the image that you see if it's displayed large enough, actually has a lower 'real' resolution, like it was downscaled and then upscaled. could be a bug or a joke. probably a joke

That leads to a question: do you really need "true lossless" on the web? Honestly I think AVIF's lossless RGB mode might be a mistake

for regular website assets, probably not for the web as an application platform, definitely yes

using AVIF specifically, probably not

only advantage for (non-animated) lossless rgb avif i can think of is that i *think* it had better hdr support, at least before the new png standard

"the web" is not one thing. Typically lossy suffices. But something like an image editor on a Chromebook is arguably also "the web"...

Or a radiologist accessing a CT via some web interface, to give another example

for archiving you should be using storage solutions that apply Reed-Solomon to all data, regardless of what kinds of files you have. Like, I've logged hundreds of read errors from my NAS hard drives, but I've never had any file corruption. Why? Because I've got them in mirror and raid configurations that automatically fix errors.

For where lossless is needed, lossless YUV is almost always better than the RGB mode except for not being "true lossless"

Lossless YUV is essentially the same as RGB787, it's rather easy to improve compression if dropping some lsb is allowed...

many color values get shifted around with YUV, and it for example makes it impossible to get original intended color values out of reference sheets that don't put down hex codes

I persoanlly consider non-lossless lossless YUV to cause more problems then it solves

*personally

with ycgco-r you're not losing any data, at the cost of requiring an extra bit (and weirdly it seems like av2 will max out at 10 bit initially, so you can't use that for 10 bit rgb data anymore unlike with av1)

that didn't exist before for AVIF which means older decoders will fail on it and a lot of software is still outputting with the old raw RGB mode AFAIK

for example Valve's gamescope still outputs raw RGB lossless AVIFs when taking screenshots

Recently I found out Britain's biggest bakery chain uses lossy PNG for their food photos, presumably because it has transparency <https://www.greggs.com/menu/product/sausage-roll-1000446>

> When you need lossless, lossy is better I don't think most would agree with that

Last I checked, on my system Reddit was delivering reduced-palette PNG when the original was PNG.

Perceptually lossless is often what they actually need when people ask for "lossless". For the image editor case you probably need mathematically lossless, but AVIF is mostly served as a delivery format (for which many artists are already happy with high quality JPEG)

"High quality jpeg" kek

I wonder how many ppl see jpeg and think high quality fr

That meant literally high quality, often q > 95, some artists even export it with q 100

I suppose but even then dct artifacts everywhere

So even as a "delivery format" most would prefer webp

Eh... No? You can't get 4:4:4 with WebP

True but 444 doesn't magically make it immune to dct artifacts/ac errors

Of which jpeg is well known for, where as webp is mostly just blocking/loss of details

I doubt dct will be more of a problem than chroma subsampling at high quality. Chroma subsampling will destroy colors at edges (unless with sharp yuv, but that may introduce other artifacts)

Meanwhile most JPEGs I see are either q100 4:2:0 or q50 and only legible thanks to resolutions being so high nowadays

We wanted to add sharp YUV to jpegli, since that should give it yet another boost for relatively little cost, but we were running into some issues

I think Photoshop always uses 4:4:4 if you export with high quality preset

Not everyone uses photoshop

Interesting cause I could swear that even with jpeg 95 444, dotcrawl, chromatic aberration, ringing, chroma shift, occur, specifically around borders/edges

And especially with any kind of text

don't get me wrong jpeg is still a necessary evil, but if I ask for lossless, I mean lossless, if an artist gave me "perceptual lossless" I would ask for my money back xD

Well commissions and mass sales are different, some even provide PSDs for the former, while the latter usually only gets JPEGs

I mean for cdn's I get it their pipelines are fixed and their stubborn or lack the finances, but even for mass buys? Really?

I've helped half a dozen artists with their export formats, some not realising q100 JPEGs were lossy, others not knowing the compression level for PNG is lossless

Wild

Tho with "lossless" jpegs / lossy pngs out in the world I see the confusion

Well, lossless JPEG pretty much only exists as DNG files, most consumer software just throws an error. Lossy PNG generally has the reaction of "What do you mean lossy PNG?" followed by me telling them not to worry about it

Was my reaction to lossy png as well 😂

seems like someone has recently submitted a PR to fix this: https://github.com/mozilla/mozjpeg/pull/453

what's interesting about this to me is that you can clearly see AVIF and WebP are attempting to exploit spatial redundancy/similarity while the JPEG block is entirely self-contained I don't think JXL really does that? at least from what I've read in the paper

I know it does for the LF image, which is a Modular mode image and uses can use the predictors, but aside from that and Patches it has no spatial prediction mechanism I think?

it does do chroma from luma and something else I've forgotten the name of for inter-channel prediction, but that's still done on the block level. it makes me wonder if JXL could've compressed better yet if it had spatial prediction modes in VarDCT like WebP and AVIF do in their lossy modes

I suspect that in the high quality range, the contribution of these these spatial predictors to compression efficiency of the image as a whole becomes relatively small. I don't expect spatial prediction to work well at all for the higher frequency components as they'll be all over the place, and those probably take up the bulk of the data

I thought that jxl is self-sufficient in 256x256 blocks, but apparently this is not the case. In any case, there is currently no way to use the current decoder and decode the image; it rejects it even before it starts working if there are errors.

Here we go again: https://github.com/victorvde/jpeg2png

Yea I use it sometimes, needs to be tweaked per source tho

Same with quant smooth

It does start working, the errors can only be detected at the end of a section. But it will abort as soon as it detects error. In the branch I shared earlier, you can make it continue instead (as long as the error is not in a critical place like in the headers).

This is good, but it doesn't change the futility of this action at the moment in the latest version of the decoder. No one does like this; jpeg, webp, avif, they all create a file even if it is broken due to damage.

What to do with corrupted files is not a property of a codec but of an application. Some applications will also refuse to load broken jpegs or pngs.

Arguably it is better to know that a file is corrupted than to silently use corrupt data

Case in point: I remember a customer complaining that their images looked blurry when we served them, even when we served the original as-is! Turned out they were uploading truncated progressive jpegs where the final scans were just missing, and all browsers just happily show that and few software is showing even a warning that the data is truncated. After this, we made sure to check the integrity of uploaded images to make sure it's not truncated or otherwise corrupted.

I was playing with a truncated JPEG yesterday, DC only but the viewer still reported it as 4K, Quality 98, 4:4:4 naturally

I was going to say it might be possible to recover a lost bit semi-consistently using surrounding context, but of course the whole point of compression is to remove redundancies like that, so the better your compression, harder that's going to be to any extent

This is a good example, but I want to point out that in this case, JXL is corrupted and says the file is broken, and the user will just delete it because what else can they do with it? But in reality, it could be decoded, viewed, and even restored if the damage isn't critical.

A damaged regular JPEG is truly damaged, but that's no reason not to decode it if it's damaged, because the chances of getting damaged anywhere just like that are still not zero.

In the given example, you are to blame for creating a broken file, and not the decoder that decoded it. I don't see much point in not decoding even broken files.

A decoder that doesn't open a file is a bad decoder.

Rather, a decoder that rejects bad input is a good decoder.

It all depends on the use case, but in general it's a good idea to make a clear distinction between what is valid and what is not. Making decoders reject invalid input is generally the best way to force encoder compliance. Doesn't mean you cannot have decoders aimed at data recovery, but that shouldn't be default behavior or you are effectively generalizing what is, de facto, a valid bitstream.

Decoders do things strictly defined by the documentation. That's right. But decoder could...

the jxl specification is only concerned with how to decode conformant bitstreams

it says nothing about error handling for non-conformant bitstreams (such as corrupted ones)

I don't think that something like this exists in any data compression format, well, so

you don’t think what exists?

I think that when Webp was developed, nowhere in the specification was it written what to do in case of damage to 1 bit of data, and yet I can decode it

In formats with weak error detection (not sure about WebP but JPEG is an example), random bitflips can often turn a conformant bitstream in another conformant bitstream that just represents a different (corrupted) image. In JPEG for example (or JXL when using prefix codes instead of ANS), changing any prefix code into a different code of the same length will usually keep the bitstream conformant while changing the contents. If I recall correctly, in JPEG you can also change it in more ways as long as you don't cause overruns (but underruns are fine), since padding at the end is allowed to be arbitrary. In that case a decoder has no choice but to decode the file as-is since it cannot detect it is corrupt — it's still a valid bitstream, even if the image data is corrupt, so a decoder has to decode it.

JXL has somewhat stronger error detection, in the sense that in the typical case (ANS) it is very unlikely that a random bitflip will keep the bitstream conformant. So errors can be detected. What to do in case of error is up to the decoder implementation though; the spec only describes how to decode conformant bitstreams.

JPEG decoders in browsers tend to be very permissive (showing some image even when it can detect corruption), just like how they are with parsing technically invalid HTML. That's understandable, historically, but it is not a good practice: it basically means you are creating a de facto standard that extends and complicates the real standard, and everyone will be forced to comply with it.

The worst imo is PDF, I saw dozen of malformed/corrupted PDF that are still shown correctly not only by browsers by also other apps

hm

For experiments, I compiled libjxl https://discord.com/channels/794206087879852103/804324493420920833/1471165602130301073 to work more directly, I connected the library via Python, and also changed a lot of the source code using hard hand. I will continue the rest of the topic of Jpeg XL decoding broken ones in <#794206170445119489> It turned out to be so simple, and JPEG XL handles being turned into a byte field burned out by a nuclear explosion. Now I don't even know why all that whining about standards was said above.

https://www.androidauthority.com/android-17-beta-1-3639738/ I'm a bit salty that Android is getting VVC support before JXL, I guess it's at some OEMs' request

Can then come together with ECM /s

vvc still dead 🥹

I created a precise byte mask for JXL files. The bytes that must never be damaged are the head. The entire JPEG XL structure is located in the head, followed by the data. If the head is damaged, recovery is impossible. Only in theory can one understand the block grid stored in the head, but no image is present. The percentage of the head varies and depends on the image size, compression level, and block structure. For example, with e5 compression, the structure is more chaotic, leading to a large division of blocks into subblocks, creating a larger head. With e1-3, e9-10, the head is smaller due to a simple or very well-arranged block structure. The important thing here is that, unlike WebP and Avif, which completely break if a single byte within the stream is damaged, JPEG XL places the entire structure at the top of the file, allowing decoding. The main thing is that the head is intact, which is approximately 10% of the beginning of the file. Everything else can be completely destroyed, anywhere in any quantity. All white pixels are bytes that can be destroyed. I performed a binary search for decoding errors, about 50,000 decodes, to fully search for the exact structure. That is, JPEG XL has a greater technological advantage than any other codec, as long as the damage doesn't occur at the beginning of the file. While AVIF/Webp will be completely broken if the stream is damaged, all subsequent pixels will be damaged, and if the damage occurs at the beginning, everything after that will be damaged. This is because the AVIF structure is located in the same place as the data. (Of course, classic jpeg will always be better in this matter.) ~320 kb files e1 | e5 | e10

I’m starting to despise the SACD format more and more

just predict the noise, why didn't we think of that

ah they're using noise shaping

yes, very aggressive

DSD is basically 1-bit, 2.8 MHz audio

wikipedia: > DSD uses delta-sigma modulation, a form of pulse-density modulation encoding, a technique to represent audio signals in digital format, a sequence of single-bit values at a sampling rate of 2.8224 MHz. This is 64 times the CD audio sampling rate of 44.1 kHz, but with 1-bit samples instead of 16-bit samples.

and all of this for what?

(https://sjeng.org/ftp/SACD.pdf is a famous critique of this approach)

the paper doesn’t address DACs, only ADCs and the resulting signal

the problems they refer to are baked into the digital signal

the last time I needed a DAC, I hooked up an 8-bit PWM to a low pass filter. Very quality.

AVIF support, tell me about it <:KekDog:805390049033191445>

am i missing something or are OBS's bit depth/format settings wired up in an extremely confusing way? i'm using nvenc av1, and there doesn't seem to be any indication as to what color formats are supported. in the dropdown i can select anything like 16 bit 4:4:4 which isn't even part of the av1 spec, and it seems to just silently degrade to 8 bit 4:2:0

obs is dumb, but it uses standard making convention iirc, what options are there?

Looks like nvenc's AV1 is limited to 420 only https://developer.nvidia.com/video-encode-decode-support-matrix

It seems like 4:4:4 is h264/h265

is it ok to use ffmpeg as screen recording

maybe both for screenshot too

you can use ffv1 if you are not stressed in disk space, and re-encode it to any codec later

ffv1 is rather heavy on ressources for recording. I would recommend utvideo or magicyuv and encoding to ffv1 afterwards. If archival doesn't matter just use h265/h264 with 4:4:4

storage I/O is a resource too T.T

There is a GPU encoder for ffv1 now, however that might not be that helpful from resource consumption side if you're doing a whole lot of rendering on the GPU

ffv1_vulkan does not support full RGB, a common limitation with hardware accelerated encoding

And although I haven't checked if yuv444p is supported, if you are limited to yuv420p for example, you may as well discard the idea of lossless recording entirely IMO

There shouldn't be any fundamental limitation against fotmats, since it's just compute shaders, maybe just not implemented yet

I hope so

Hm, I dug some more and got it working with bgr0 for true lossless — but it is half the speed of CPU encoded FFV1. So I would still recommend a lighter codec

Maybe the performance would be better on a 5090. If someone here is rich they could try <:KekDog:805390049033191445>

Did they ever ask for lossless?

no, we just went there from the original question lol

https://www.phoronix.com/news/AOMedia-OAC-Open-Audio-Codec

if it's based on opus why not just contribute lol

It's not like opus isn't developed anymore after all

back in the days we used to call this a new encoder for existing format

it cant proclaim to be a 'successor' to a codebase thats active and is capable of even more than what the backward compatibility maximizing parameters only default to

if its serious about that, they should have some way to losslessly recompress already lossy opus audio (like with jxl's reversible lossless transcoding when source is an unmodified jpg)

they're probably planning to make changes to the format

looks like the main dev of OAC is Jean-Marc Valin, so might be that Opus isn't actually actively developed anymore if he's being paid to work on this instead 😄

From the man himself: > OAC is using Opus 1.6.1 as a starting point, but will keep evolving and will ultimately not be Opus-compatible, so we're not constrained in the changes we can make.

hoping that they'll remove or disable by default the stereo phase inversion

(see https://gstreamer-bugs.narkive.com/p9l7iv3z/bug-791771-new-opusenc-opusdec-add-option-to-disable-phase-inversion)

just fucks up any mono downmixing when the decoder (which can be far removed from the place where the downmixing happens) isn't explicitly told to ignore that flag

Youtube butchers sound and opus didn't help

Let's be fair, youtube audio quality is the least offensive while watching videos

I can at least agree that “Stable volume” (DRC) butchers sound

whether the encoding itself is bad is less obvious to me (but I have high-frequency hearing loss)

I upload in the highest quality I can, and as far as I can tell (from YT’s choice of codec, spectrograms, and what I can hear), the result seems okay

of course, it may be another story if the upload itself was already lossy and YouTube adds generation loss on top

example: https://youtu.be/ORffRIkY7O0 (for headphones) / https://youtu.be/IirnyKNJNiA (for speakers)

my issue with stable volume is that 9/10 times it's not available on videos that actually need it, whereas it is available on videos that get millions of views that have enough production quality to not need it...

On that note, is there a word that's like 'consequently' but in the opposite direction? and is there a word for relationships between words like that? > videos that get millions of views and __consequently__ have enough production quality Production quality is not a (direct) consequence of the amount of views, it's the other way around, but I couldn't think of a word to express that. It's not an antonym, because antonyms of 'consequently' are 'whereas' and 'despite that', but I'm not looking to negate it, I want to reverse it

“because”?

That's what I was gunna suggest too

I haven't done any precise measurements or tests but whenever listening to music on YouTube it always sounds worse than everywhere else like SoundCloud or Bandcamp

It's like listening to a jpeg

oh YEAH

does that apply to my [examples](https://discord.com/channels/794206087879852103/805176455658733570/1475448330103554118) as well?

julio intends on sending a pr for that

It was today I found out my Android phone can't play h264 4:4:4

most cant

HEVC 4:4:4 didn't even decode on my desktop, h264 10bit is non-existent, and AV1 is too new for all my devices 😔

~~Distance 25 animated JXL it is~~

amd gpu? reasonably new intel and nvidia gpus can do hevc 4:4:4 (but not av1)

An old 1070Ti, playing it went to software decoding

https://github.com/orgs/LizardByte/discussions/220#discussioncomment-8898271

seems like it should be supported?

nvidia's site says no though: https://developer.nvidia.com/video-encode-decode-support-matrix

so could just be misinformation

Yeah, says 20 series or newer

I recently got a pixel 10 pro xl, av1 decode is such a massive different vs my old s9+ lmao

Mine just crashes when it tries to play AV1 on Discord

Or 422 kek

Well technically just discord hw dec can't do it and fallback fails

Mpv tho, ofc no problem xD

tbf discord swdec seems funky performance wise

https://hydrogenaudio.org/index.php/topic,129191.0.html

lots of very uninformed people there for what's supposed to be an enthusiast forum 🤔

(not that there's something wrong with being uninformed, but here that doesn't seem to stop people from confidently posting things)

why in the actual fuck is there an Opus patent pool

to pool patents related to Opus

I think you mean: to pool patents of dubious relation to Opus, so as to scare companies into paying fees :p

you wouldn't believe the av1 off shoot thread

i was referring to that too actually

its wild

Someone give me a hand explaining to this guy https://github.com/google/jpegli/pull/135#issuecomment-3954307685

My brain hurts

APP14 marker is required to tell the decoder not to do the reverse YUV tranform.

It has nothing to do with the ICC profile

<:tfw:843857104439607327>

If you aren't using the jpeg YUV mode then always use app14, why is there an argument?

According to the jpeg specs, the decoder always applies the reverse transform if app14 isn't there to say not to, so the color would be fucked up if the app14 marker isn't there, because of the unnecessary reverse-transformation being performed by the decoder when the encoder never did that

It seems like a simple issue

Maybe the confusion is that it's sometimes called "RGB mode" when it really is "do nothing mode"

Idk it looks like you already explained it perfectly jonny

Github is a place to fix issues. Doesn't seem like the place to explain basic things like this. Is there any point in arguing?

The lack of app14 tag is a pretty major bug that needs fixing regardless

I thought it was fixed already

Hmm, I just realised FFMPEG is buffering all the PNGs from jxl-rs in-memory before encoding progressive videos, adding up to quite a lot for high res decodes. Don't suppose there's a way to make it lazy-load instead? The command makes the dimensions even for x264 and adds a checkerboard background for transparency `ffmpeg -hide_banner -r 10 -i Progressive.partial%05d.png -vf scale=trunc(min(3840\,iw)/2)*2:trunc(min(3840\,ih)/2)*2:force_original_aspect_ratio=decrease:alphablend=checkerboard -pix_fmt yuv420p -movflags +faststart -preset slow -crf 18 -y Progressive.mp4`

https://x.com/i/status/2027002298417774719

<@853026420792360980> you're the resident FFMPEG expert, I don't suppose you have any ideas? The video encode is using over twice as much memory as jxl-rs for what should be a simple chain

-preset veryfast

I'm not sure how you can say it's using twice as much memory as jxl-rs when you're encoding it with x264

x264 on preset:slow uses a lot of memory

preset=slow for example has an rc-lookahead of 50